Ts 650 Admin Unix

TeamSite®
Administration Guide
Release 6.5
UNIX®
© 1997-2004 Interwoven, Inc. All rights reserved.
No part of this publication (hardcopy or electronic form) may be reproduced or transmitted, in any form
or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written
consent of Interwoven. Information in this manual is furnished under license by Interwoven, Inc. and may
only be used in accordance with the terms of the license agreement. If this software or documentation
directs you to copy materials, you must first have permission from the copyright owner of the materials to
avoid violating the law which could result in damages or other remedies.
Interwoven, TeamSite, Content Networks, OpenDeploy, MetaTagger, DataDeploy, DeskSite, iManage,

MailSite, MediaBin, MetaCode, MetaFinder, MetaSource, OpenTransform, Primera, TeamPortal,
TeamXML, TeamXpress, VisualAnnotate, WorkKnowledge, WorkDocs, WorkPortal, WorkRoute,
WorkTeam, the respective taglines, logos and service marks are trademarks of Interwoven, Inc., which
may be registered in certain jurisdictions. All other trademarks are owned by their respective owners.
Some or all of the information contained herein may be protected by patent numbers: US # 6,505,212, EP
/ ATRA / BELG / DENM / FINL / FRAN / GBRI / GREC / IREL / ITAL / LUXE / NETH / PORT /
SPAI / SWED / SWIT # 1053523, US # 6,480,944, US# 5,845,270, US #5,384,867, US #5,430,812,
US #5,754,704, US #5,347,600, AUS #735365, GB #GB2333619, US #5,845,067, US #6,675,299,
US #5,835,037, AUS #632333, BEL #480941, BRAZ #PI9007504-8, CAN #2,062,965, DENM / EPC
/ FRAN / GRBI / ITAL / LUXE / NETH / SPAI / SWED / SWIT #480941, GERM #69020564.3,
JAPA #2968582, NORW #301860, US #5,065,447, US #6,609,184, US #6,141,017, US #5,990,950,
US #5,821,999, US #5,805,217, US #5,838,832, US #5,867,221, US #5,923,376, US #6,434,273,
US #5,867,603, US #4,941,193, US #5,822,721, US #5,845,270, US #5,923,785, US #5,982,938,
US #5,790,131, US #5,721,543, US #5,982,441, US #5,857,036, GERM #69902752.7 or other
patents pending application for Interwoven, Inc.
This Interwoven product utilizes third party components under the following copyrights with all rights
reserved: Copyright 1997 Eric Young; Copyright 2000-2003, Apache Software Foundation
(http://www.apache.org/); Copyright 1999, ExoLab Group; Copyright 1999-2001, Intalio, Inc. If you
are interested in using these components for other purposes, contact the appropriate vendor.
Interwoven, Inc.
803 11th Ave.
Sunnyvale, CA 94089
http://www.interwoven.com
Printed in the United States of America
Release 6.5
Part # 70-11-00-650-300
October 2004
Table of Contents
About This Book 9
Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Default Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Online Documentation Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
What’s in This Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 1: TeamSite Overview 13

TeamSite Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Content Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Workareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Staging Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Editions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
TeamSite User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Other Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
TeamSite Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
TeamSite Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Understanding the TeamSite File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 2: Configuration File Overview 21
Chapter 3: Configuring the TeamSite Server 25

Configuring User Interface Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Enabling and Disabling VisualPreview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configuring Email Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Configuring Server Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Controlling Modification Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Modifying Extended Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Specifying the Encoding of the iw.cfg File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Web Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Servlet Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Locking Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Comparing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Submit and Update Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Autoprivate Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Enabling the Event Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Configuring the Event Subsystem Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3
Configuring Server Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Cache Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
RPC Threadcount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
File System Threadcount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Hopi Threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Throughput Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Detecting Low Disk Space and Inode Count. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Configuring the TeamSite Server Locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Configuring FormsPublisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
FormsPublisher Settings in iw.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
TeamSite Embedded Failsafe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 4: Managing the TeamSite Server 43

Verifying Server Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Starting and Stopping the TeamSite Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Checking for Multiple Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Checking Request Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Verifying the Server Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Locating the Installation Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Reviewing TeamSite Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
WWFS Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Installation Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
ConfigurationServer Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Trace Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Events Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Workflow Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
iwprocessd and iwprocoutput Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Monitoring the Server Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Managing the OpenAPI Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Verifying that the OpenAPI Server is Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Starting and Stopping OpenAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Reconfiguring iwwebd to Recognize a New IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Enhancing Server Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
File Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Monitoring Disk Space Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Deleting Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Metadata Forking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Moving the Content Store and Removing Old Versions . . . . . . . . . . . . . . . . . . . . . . . 52
Chapter 5: Managing TeamSite Access 53

Access Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Adding TeamSite Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Deleting TeamSite Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Checking User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Changing Owner and Group of a Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Controlling Access to Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
TeamSite Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 TeamSite Administration Guide

Working with Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Group Membership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Changing Group Ownership of Workareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Webserver UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Group Remapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Workarea Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Branch and Workarea Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Disabling Editors Creating Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Default Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Role Authentication Using LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Modifying LDAP Schemas to Store TeamSite Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Re-Encrypting User Authentication Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
TeamSite and PAM Configuration File Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Configuring TeamSite and LDAP to Work Without an Anonymous Bind . . . . . . . . . . . 71
Configuring Submit Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Understanding the submit.cfg File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Submit Filtering Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Sample submit.cfg file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Testing and Debugging Submit Filtering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
RCS Macro Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Chapter 6: Configuring Interwoven Search 79

Search Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Working with Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Indexing Branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Searching Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Deleting Branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Configuring the Index and Search Managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Generic Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Generic Agent Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Index Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Index Agent Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Search Manager Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Search Agent Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Logging Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Field Mapping Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Configuring Date Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Example of FieldMapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The standardField.xml File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Types of Files Being Indexed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Determining Whether a Document will be Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Using CLTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Deleted Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Using the CustomDate Extended Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Deleted Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Changes to Content Store IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5
Bringing Down Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Running on Different Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Chapter 7: Configuring Metadata Capture 103

Introducing the Tagger GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Metadata Capture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Metadata Capture Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Metadata Capture and Extended Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Configuring Metadata Capture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
The metadata-rules.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Creating the datacapture.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Modifying the Tagger GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Localizing the Tagger GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Using the datacapture.cfg.example2 File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Metadata Capture and TeamSite Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Specifying Files in Workflow Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Initiating Metadata Capture from a Job Specification File . . . . . . . . . . . . . . . . . . . . . 121
Chapter 8: Configuring the TeamSite Web Daemon and Proxy Server 123
About the TeamSite Web Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
About the Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Applying Changes to Proxy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Configuring TeamSite Web Daemon and Proxy Server Operation. . . . . . . . . . . . . . . . . . . . . 125
Resolving Relative and Absolute Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Document Roots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Resolving Fully Qualified URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Redirecting Fully Qualified URLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring the Proxy Server to Redirect Fully Qualified URLs . . . . . . . . . . . . . . . . 129
Configuring your Web browsers to Use the TeamSite Web Daemon . . . . . . . . . . . . . 129
Redirecting TeamSite Views to Different Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Using iwproxy_preconnect_remap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Using iwproxy_preconnect_redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Configuring TeamSite to Use Different Web Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Configuring External Remappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Using iwproxy_preconnect_remap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Using iwproxy_external_remap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Host Header Remappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Enabling iwproxy Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Configuring SSI Remapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Configuring Proxy Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Debugging Your Proxy Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 9: Backing Up TeamSite 139

Integrating with Third-Party Backup Solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Suggested Strategies for Incremental Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Appendix A: TeamSite Configuration File Reference 143
Location of iw.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Location of Roles Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Appendix B: Configuring Reporting 147

Installing TeamSite Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Reporting Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Reporting Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
License key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
CSSDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Archived Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Database Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Crystal Enterprise Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Running on a Windows Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Database Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Displaying Reports in ContentCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Setting up Individual Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Error Messages Displayed in ContentCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Large Number of Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Restarting Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Appendix C: Specifying Content Encoding 161

regex_map Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Simple regex_map Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
The regex_map Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Rule Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Regular Expression Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Application Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Intermediate Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Interpolation of Variables and Captured Subexpressions . . . . . . . . . . . . . . . . . . . . . . 165
Quoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Strategies for Effective regex_maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Internationalization and regex_maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
VisualPreview and file_encoding.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Source Differencing and Merging and file_encoding.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Sample file_encoding.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Advanced regex_map Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7
Appendix D: Internationalization 175
Supported Client and Server Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Supported Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Limitations and Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Content Stores and Character Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
About UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
URL Commands with Multibyte Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Interfacing with Localized Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Accessing the Localized Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Language of the VisualPreview Tool Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Specifying File Encoding of Text Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Text Editor Encodings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Appendix E: Integrating with SiteMinder 183

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Authentication Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Integration Procedure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Setting Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Copying the iwtssmar.so File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Configuring SiteMinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Appendix F: Root Access to TeamSite 189
Appendix G: TeamSite Service Monitor 191

Service Monitor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
TeamSite Service Monitor Components and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Installing TeamSite Service Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Configuring TeamSite Service Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
iw.powerfail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
iw.processfail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Starting and Stopping iwserver Under Service Monitor . . . . . . . . . . . . . . . . . . . . . . 196
Uninstalling TeamSite Service Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Related Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Appendix H: Troubleshooting 197

Unexpected Server Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Other Server Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Installing/Removing Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Windows XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Glossary 201
Index 211

About This Book
The TeamSite Administration Guide is a guide for configuring, customizing, and maintaining
TeamSite. It is primarily intended for TeamSite Administrators and Master users, web server
administrators, and system administrators. Users of this manual should be familiar with
basic UNIX commands and be able to use an editor such as emacs or vi.
Many of the operations described in this manual require root access to the TeamSite server,
these operations are listed in Appendix F, “Root Access to TeamSite.” If you do not have
root access to the TeamSite server, consult your UNIX system administrator.
It is also very helpful to be familiar with regular expression syntax. If you are not familiar
with regular expressions, it is recommended that you consult a reference manual such as
Mastering Regular Expressions, by Jeffrey Friedl.
Some TeamSite configuration files make use of XML. For more information about XML,
consult a reference manual or the online specification at
http://www.xml.com/axml/testaxml.htm.
Notation Conventions
This manual uses the following notation conventions:
Convention Definition and Usage

Bold Text that appears in a GUI element (for example, a menu item,
button, or element of a dialog box) and command names are shown in
bold. For example:
Click Edit File in the Button Bar.

Italic Book titles appear in italics.
Terms are italicized the first time they are introduced. Important
information may be italicized for emphasis.
Monospaced Commands, command-line output, and file names are in monospaced
type. For example:
The iwextattr command-line tool allows you to set and look

up extended attributes on a file.
9
Convention Definition and Usage
Monospaced Monospaced italics are used for command-line variables.The most
italic
common example of this is iw-home, which refers to the directory
where TeamSite is installed. For example:
iw-home\etc\iw.cfg
is the path to the main TeamSite configuration file, iw.cfg, which is

located in the etc directory under the TeamSite installation directory.
iwckrole role user
means that you must insert the values of role and user yourself.
Monospaced Monospaced bold represents user input. The % character that appears
bold
before a line of user input represents the command prompt and should
not be typed. Your system may not use this command prompt. For
example:
% iwextattr -s project=proj1
//IWSERVER/default/main/dev/WORKAREA/andre/products
/index.html
Monospaced bold Monospaced bold italic text is used to indicate a variable in user input.
italic
For example:
% iwextattr -s project=projectname workareavpath
means that you must insert the values of projectname and
workareavpath when you enter this command.
[] Square brackets surrounding a command-line argument mean that the
argument is optional.
| Vertical bars separating command-line arguments mean that only one
of the arguments can be used.
Default Paths
During installation default paths are used unless the installer specifies otherwise. The default
path for Teamsite is:
Interwoven/TeamSite
The default path for TeamSite Search is:
Interwoven/Search
The installed paths are referred to in this document as iw-home and iwsearch-home.
Online Documentation Errata

Additions and corrections to this document (if necessary) can be downloaded in PDF format
from the following Web site: https://support.interwoven.com.

What’s in This Manual
What’s in This Manual

This manual contains information in the following areas:
! Chapter 1, “TeamSite Overview,” introduces TeamSite administrators to the
TeamSite architecture and to TeamSite users.
! Chapter 2, “Configuration File Overview,” describes the configuration files and
provides a table listing the various items to be configured.
! Chapter 3, “Configuring the TeamSite Server,” describes the various ways in which
the TeamSite server can be configured. Many of these configurations are made in
the iw.cfg file.
! Chapter 4, “Managing the TeamSite Server,” describes how to manage the TeamSite
server, including verifying operation, viewing log files, and starting and stopping
the server.
! Chapter 5, “Managing TeamSite Access,” describes how to set up and delete users in
specific roles, what permissions users in each role have, and establishing groups for
access.
! Chapter 6, “Configuring Interwoven Search,” describes the TeamSite Search
feature.
! Chapter 7, “Configuring Metadata Capture,” describes how to configure the Tagger
GUI to save metadata.
! Chapter 8, “Configuring the TeamSite Web Daemon and Proxy Server,” describes
how to configure the proxy server.
! Chapter 9, “Backing Up TeamSite,” suggests strategies for backing up TeamSite files.
! Appendix A, “TeamSite Configuration File Reference,” describes the various
configuration files used with TeamSite
! Appendix B, “Configuring Reporting,” describes the optional TeamSite Reporting
module.
! Appendix C, “Specifying Content Encoding,” provides information for encoding
content files.
! Appendix D, “Internationalization,” provides specific information regarding use of
TeamSite internationally.
! Appendix E, “Integrating with SiteMinder,” describes the Netegrity application and
its use with TeamSite.
! Appendix F, “Root Access to TeamSite,” describes the files for which the
administrator needs root access.
! Appendix G, “TeamSite Service Monitor,” describes TeamSite Service Monitor for
monitoring the TeamSite server.
! Appendix H, “Troubleshooting,” provides information on some issues you may
encounter using TeamSite.
! The “Glossary” contains definitions of TeamSite terms.
11
Chapter 1
TeamSite Overview
This chapter introduces the following three major TeamSite concepts and concludes with a
description of the TeamSite system architecture:
" TeamSite Elements
" TeamSite User Roles
" TeamSite Workflow
TeamSite Elements
The following sections describe some common TeamSite concepts that you should be
familiar with before beginning to configure TeamSite.
Content Stores
The Content Store is a large directory created by the TeamSite installation program that
contains TeamSite files and metadata. By default, the Content Store is located in /local/
iw-store.
In releases of TeamSite prior to 5.5, administrators were limited to one Content Store (then
known as the backing store) per TeamSite Content Server. TeamSite now supports as many as
eight Content Stores per TeamSite server (the first is created automatically by the
installation program, and the others are created as needed by the TeamSite administrator).
Branches
TeamSite provides branches for different paths of development for content. Branches can be
related to each other (for example, alternate language versions of the same Web site) or they
may be completely independent. Typically, each branch contains all the content for a Web
site or a major section of it (such as a department), or a collection of related content (such
as the program files for a software application or the image and text files for a book).
Branches can be indexed and searched.
A single branch contains archived copies of its content as editions, a staging area for content
integration, and individual workareas where users may develop content without disturbing
one another. Branches can also contain subbranches, so that teams may keep alternate paths of
development separate from each other. Content can be easily shared and synchronized
13
TeamSite Overview
across branches and subbranches. Users may work on one branch or on several, and the
number of branches on a system is not limited.
Branches facilitate distributed workflow because they allow separate teams to work
independently on different projects. Because all branches are located on the same TeamSite
server, it is easy for one team to incorporate the work of another into their project.
Workareas
Each workarea contains a virtual copy of all related content, which may be modified in any
way without affecting the work of other contributors. Users who have access to a workarea
may modify files within that workarea and view their changes within the context of all
related content before integrating their work with that of other contributors. Users can lock
files in each workarea, eliminating the possibility of conflicting edits.
All changes made to files in a workarea are kept completely separate from other workareas
and the staging area until the user chooses to submit his changes to the staging area. Within
a workarea, users may add, edit, or delete files, or revert to older versions of files without
affecting other users.
Staging Areas
Each branch contains one staging area where contributors incorporate their changes with the
work of others. Users submit files from their workareas to the staging area to integrate their
work with other contributions, and test the integrity of the resulting content. Because the
staging area is an integrated component of the system, conflicts are easily identified and
different versions of the same file can be merged, rather than overwritten.
Editions
Editions are read-only snapshots of a branch, taken at sequential points in its development.
Contributors can create new editions any time they feel their work is well integrated, or any
time they want to create an updated snapshot of all content for reference or deployment to a
production server. For Web site content development, each edition is a fully functional
version of the Web site, so that users can see the development of the Web site over time and
compare it with current work.
The following diagram illustrates the use of TeamSite for Web site development.

TeamSite User Roles
Edit
local
computer
Workarea A
Upload
Production Server
TeamSite Branch
TeamSite Branch
Client
Submit
Get Latest
Workarea B Staging Area Edition 3
Publish Deploy
Production
Server
Workarea C Edition 2
Edition 1
TeamSite Process Time
Figure 1: TeamSite branches contain private workareas, which contain complete virtual copies of the Web site; staging areas,
where contributors integrate their work; and editions, which are read-only snapshots of the Web site at various points in its
development. Each area contains a virtual copy of the entire Web site. Content is submitted from workareas to the staging
area, and the staging area is then published as an edition. Older editions are available for reference.
TeamSite User Roles

TeamSite defines four different user types, each with specific access limitations and
optimized user interfaces. These user types are known as roles. The four roles are:
" Authors
" Editors
" Administrators
" Masters
These roles are described in detail in the sections that follow.
15
TeamSite Overview
Authors
Authors are primary content creators. All work done by Authors goes through an explicit
approval step. They can receive assignments from Editors, which are displayed in task lists
when Authors log in to TeamSite. Authors access TeamSite from the browser-based
ContentCenter Standard interface and do not need to be sophisticated computer users.
In order to test their work, Authors have full access to the content in their Editors’
workareas, but do not need to concern themselves with the larger structure and
functionality of TeamSite. The Author role is appropriate for non-technical users or for
more technical contributors who do not need access to extended TeamSite functionality,
such as advanced version management features.
Editors
Editors own workareas. They create and edit content, just as Authors do, but they are
primarily responsible for managing the development taking place within their workareas.
This includes assigning files to Authors and submitting completed content to the staging
area, and it may include creating editions.
Editors have access to specialized TeamSite content and workflow management functions.
Editors are generally “managerial” users, who primarily supervise the work of Authors, or
self-managing “power” users, who need extended TeamSite functionality to manage their
own content.
Administrators
Administrators own branches. They have all the abilities of Editors, but they are primarily
responsible for the content and functioning of their branch. Administrators can manage
project workflow by creating new workareas for Editors and groups and by creating
subbranches of their own branch to explore separate paths of development.
An Administrator is the supervisor of the project being developed on his branch.
Masters
Master users own the entire TeamSite Content Server. They can create new stores and
perform all the functions of Editors and Administrators on any branch. For each store, the
Master user owns the main branch, from which all subbranches are created. The Master user
is generally involved in the installation of TeamSite and can reconfigure TeamSite on a
system-wide basis.

TeamSite Workflow
Other Roles
The TeamSite installation program also creates the following roles and corresponding uid
files:
" content-provider—Provides access to ContentProvider Integration Server
functionality.
" od-admin—Provides access to OpenDeploy administrator functionality.
" od-user—Provides access to OpenDeploy end-user functionality.
These roles are used by other Interwoven products and are described in their corresponding
documentation.
TeamSite Workflow
A workflow model is a general workflow configuration that can be used repeatedly. Each
workflow model describes a process that may include user tasks and a wide variety of
automated tasks. Workflow models are configured by the system administrator or by the
Interwoven Client Services organization.
For more information about configuring different workflow models, consult the TeamSite
Workflow Developer’s Guide.
Figure 2 is a diagram of a very simple assign-edit-approve workflow model. Email is sent to

the participants at every stage of the process, and some automated tasks are performed at
the end.
Editor Task: Task: Task:

initiates job Email sent Author Email sent
to Author edits files to Editor
Reject Task: Approve Task:

Task: Editor Task: Content
Email sent reviews Email sent submitted
to Author Author’s to Author to the
work staging area
Task:
Automated
deployment
Figure 2: Assign-edit-approve workflow model
17
TeamSite Overview
Jobs
A job is a set of interdependent tasks. One example of a TeamSite job would be the set of
tasks needed to prepare a new section in a marketing Web site to support a new product
launch.
Each job is a specific instance of a workflow model. When a job is created, the job creator
must supply all the specific information for that job. For example, the workflow model in
Figure 2 might be used to create the job in Figure 3.
Task:
Andre Task: Pat edits Task:
initiates job Email sent index.html Email sent
to Pat and to Andre
banner.gif
Reject Task: Approve Task:

Task: Andre Task: Content
Email sent reviews Email sent submitted
to Pat Pat’s to Pat to the
work staging area
Task:
Automated
deployment
Figure 3: Example of a job workflow
Because jobs follow predefined workflow models, tasks cannot be added to or removed
from individual jobs, although not every possible task may actually take place for a given
job.
Tasks
A task is a unit of work performed by a single user or process. Each task in a job is associated
with a particular TeamSite workarea and carries a set of files with it. The user or process
owning a task can modify, add files to, or remove files from the task.
Tasks have two possible states: active and inactive. A task becomes active when its
predecessor task signals it to do so (predecessor tasks and conditions for activation are all
configured as part of the workflow model). Once the task has been activated, users or
external programs can work on it. For example, once a user task has been activated, the
user can work on the files contained in the task. Once an external task has been activated,
the appropriate external program can run on the files contained in the task. Inactive tasks
are tasks that have been completed or that have not been activated yet.

TeamSite Architecture
TeamSite Architecture
The TeamSite Intelligent File System (IFS) is composed of the TeamSite Content Server and
kernel, the TeamSite Content Store of files and metadata, a suite of command-line tools,
TeamSite CGI, proxy servers for access through the TeamSite browser-based user interfaces
(ContentCenter), and file system mounts for access through the file system interface.
The Intelligent File System is the core of the TeamSite system, where detailed information
about the Web site, the Web assets, Web asset metadata, the production process and the
users is stored. The Intelligent File System collects and maintains metadata on TeamSite
files, directories, and areas, and allows TeamSite to process and present information
according to who is asking for the information, and under what conditions. By using an
object-oriented design within a file system architecture, TeamSite combines extensive
metadata tagging with open access and file system performance for Web content.
TeamSite Content Server Client Computer

Intelligent File System
TeamSite Command command

Content Line Tools line
Stores
CSSDK
Soap
Server Browser
TeamSite Web Interfaces
Content RPC Daemon
Server Servlet Local File
(port 80) Manager
(iwserver) Engine
CSSDK
Content Content
Services
Web Applications
/.iwmnt Server iwproxy
Filesystem (port 81)
TeamSite Workarea
mount
kernel NFS Virtualization
(wfs) (port 1080) Local File
/iwmnt Manager
Filesystem
mount
NFS mount
Samba
Figure 4: The client computer connects to the TeamSite server in several ways. Requests from the browser interfaces or Local
File Manager are routed through the TeamSite Web daemon, which allows consistent views of TeamSite areas. The double
proxy server redirects hard-coded links within the Web site. Requests through the file system interface (NFS mount/Samba)
and command-line tools, which do not go through the web server, are not routed through a proxy server.
Understanding the TeamSite File System

The TeamSite file system mount contains a file system view of all the Content Stores,
branches, workareas, staging areas, and editions on the TeamSite server. TeamSite areas do
not contain physical copies of the collection of content, but rather pointers to the files
19
TeamSite Overview
contained in the collection of content. The only physical files contained within TeamSite
areas are the files that have actually been modified in those areas. That is, the only files
actually contained in a workarea are those files that have been modified in that workarea but
not yet submitted to the staging area. The only files contained in the staging area are the files
that have been submitted since it was last published. The only files in an edition are the files
that have changed since the previous edition was published.
A simple TeamSite file system structure is shown in the following graphic:
default or
store name*
main
WORKAREA STAGING EDITION development
admin INITIAL
WORKAREA STAGING EDITION
INITIAL
Legend: andre pat
pat chris
chris
System-created ed_0001
User-created
* Store name is user-assigned in
MultiStore implementations
Figure 5: TeamSite file system structure
Each branch contains three system-generated directories:

" WORKAREA—Contains
an individual workarea for each contributor on the branch.
" STAGING—Staging area common to all workareas on the branch.
" EDITION—All published editions on the branch.
It may also contain directories that hold subbranches. In the example above, the main
branch (main) contains one workarea (admin), a staging area, an initial edition, and a
subbranch (development). The subbranch contains three user-defined workareas (andre,
pat, and chris), a staging area, and two editions, one of which is user-generated
(ed_0001).
Although many of the files contained within this file system structure are virtual, they can be
treated as if they were real. They appear to exist even when you run link checkers and
scripts against them. However, staging areas, editions, and container directories (for
example, WORKAREA, EDITION, main, or development) are all read-only. Only workareas
can be written to.

Chapter 2
Configuration File Overview
Most of the settings for the TeamSite server are configured in the main configuration file,
iw-home/etc/iw.cfg (default location).
A few settings are configured in the following files:

" iw-home/local/config/submit.cfg
" iw-home/local/config/autoprivate.cfg
" iw-home/local/config/templates.cfg
" iw-home/local/config/file_encoding.cfg
Configuration and customization of the ContentCenter interfaces is done through the UI

Toolkit; refer to the User Interface Customization Guide for details.
TeamSite configuration files are divided into sections that display in square brackets (the
iwwebd section isshown in the following example). The configurable parameter
(http_port) is to the left of the equal sign, and the current setting (80) is to the right, for
example:
[iwwebd]
http_port=80
To edit any of the settings:

1. Open the configuration file in a text editor.
2. Change the current setting.
You cannot have a space before or after the equal sign.
3. Save and close the file.
Changes to most of these configuration settings take effect within a few minutes (although
for options that affect a user interface, users may need to clear their browser cache in order
to see the changes). For these settings to take immediate effect, use the iwreset
command-line tool (CLT). Configuration options that require TeamSite to be restarted in
order to take effect are noted where appropriate.
Note: If section headings are duplicated in the iw.cfg file, some or all of the values given
for the parameters in one copy of the section will be ignored. Verify that a section
heading only appears once in your iw.cfg file.
21
For workflow-related configuration options, see the TeamSite Workflow Developer’s Guide. For
FormsPublisher configuration options, see “Configuring FormsPublisher” on page 39.
Table 1 lists the configurable options, the file where they are located, and the page that
describes the option.
Table 1: Configurable TeamSite Options
Option Configuration file Page
Configuring UI functionality
Enabling/disabling VisualPreview iw.cfg page 25
Configuring email settings iw.cfg page 26
Configuring server functionality
Controlling modification time iw.cfg page 26
Modifying extended attributes iw.cfg page 27
Setting the encoding of iw.cfg iw.cfg page 27
Configuring the Web daemon iw.cfg page 28
Configuring the servlet engine iw.cfg page 28
Locked file submission iw.cfg page 29
Setting the main branch locking model iw.cfg page 28
Specify the number of versions to check for the iw.cfg page 30
common ancestor of compared files
Configuring the events logged in the submit and iw.cfg page 30
update logs
Configuring Autoprivate autoprivate.cfg page 30
Enabling the Event Subsystem iw.cfg page 33
Configuring encoding rules for text files file_encoding.cfg page 161
Configuring server performance
Setting cache size iw.cfg page 35
Setting RPC thread count iw.cfg page 36
Setting file system threadcount iw.cfg page 36
Setting Hopi thread count iw.cfg page 36
Setting Hopi TCP/IP port number iw.cfg page 36
Setting Hopi maximum requests iw.cfg page 36
Setting Hopi thread idle time iw.cfg page 36
Setting throughput monitors iw.cfg page 37
Detecting low disk space and inodes iw.cfg page 38
Configuring the TeamSite server locale iw.cfg page 38
Setting TeamSite file locations iw.cfg page 49
Configuring FormsPublisher
Setting FormsPublisher default directory iw.cfg page 40
Setting number of previews iw.cfg page 40
Specify directory for preview files iw.cfg page 40

Table 1: Configurable TeamSite Options (Continued)
Option Configuration file Page
Formatting data record printing iw.cfg page 41
Configuring TeamSite access
Changing branch owner and group iw.cfg page 57
Using TeamSite Groups tsgroups.xml page 58
Setting the webserver UID iw.cfg page 65
Managing permissions on the workarea iw.cfg page 66
Configuring group remapping iw.cfg page 65
Setting branch and workarea security iw.cfg page 66
Disable edition creation by editors iw.cfg page 66
Setting default permissions iw.cfg page 67
User authentication iw.cfg page 67
Modifying LDAP schemas iw.cfg page 69
PAM Configuration iw.cfg page 70
Configuring without Anonymous Bind iw.cfg page 71
Setting authentication type iw.cfg page 71
Configuring submit filtering
Changing file attributes at submit time submit.cfg page 72
RCS macro expansion submit.cfg page 76
Configuring the TeamSite proxy server
Configuring proxy server operation iw.cfg page 125
Setting document roots iw.cfg page 126
Resolving fully-qualified URLs iw.cfg page 128
Redirecting TeamSite views to different areas iw.cfg page 131
Configuring TeamSite to use different Web iw.cfg page 133
servers
Configuring external remappings iw.cfg page 133
Host header remappings iw.cfg page 135
Enabling iwproxy Access Control iw.cfg page 135
Configuring SSI remappings iw.cfg page 136
Configuring proxy failover iw.cfg page 136
23

Chapter 3
Configuring the TeamSite Server
This chapter contains information on configuring the TeamSite server, including setting
functionality that impacts users and controlling file locking.
Configuring User Interface Functionality

The following sections describe the configuration settings that enable you to customize the
functionality displayed in the user interfaces.
Enabling and Disabling VisualPreview

You can selectively enable or disable VisualPreview for different workareas or files by adding
lines to the [iwproxy_smartcontextedit_allowed] section of iw.cfg. If this section
does not exist or contains no entries, VisualPreview is enabled by default.
The [iwproxy_smartcontextedit_allowed] section begins with one _default line,

which specifies whether VisualPreview is turned on or off in any area or for any file not
otherwise specified. This line is then followed by any number of _regex lines. Each _regex
line uses a case-insensitive regular expression to specify areas or files, and then specifies
whether VisualPreview is enabled or disabled for the specified items. A _regex line has the
following case-insensitive syntax:
_regex=regular-expression=yes|no
Lines in the [iwproxy_smartcontextedit_allowed] section are order-dependent. In

the following example, the _default=yes line turns VisualPreview on for all files managed
in TeamSite. The first regex line explicitly turns it on for all files in all of Andre’s workareas
on all branches. The second regex line turns VisualPreview off for all CGI files. But because
the line turning VisualPreview on for Andre’s workareas comes first, he can use
VisualPreview for CGI files in his workarea.
[iwproxy_smartcontextedit_allowed]
_default=yes
_regex=(.*)/WORKAREA/andre/.*=yes
_regex=\.cgi(\?.*)?$=no
25
Configuring Email Settings

The TeamSite Assign feature sends email to the recipient of a task. The following settings in
the [iwsend_mail] section of iw.cfg enable you to configure how this email is sent:
" maildomain=domain.topleveldomain
Specifies the domain (for example, maildomain=Interwoven.com)

" mailserver=servername.domain.topleveldomain
Specifies the mail server to use (for example,
mailserver=factotum.Interwoven.com).
" use_mapping_file=false|true
Optional entry that specifies whether or not to use a mapping file to configure
individual email addresses or aliases.
" email_mapping_file=path_to_file
Optional entry that specifies the location of the mapping file to use (a sample file is
located in iw-home/local/config/wft/email_map.cfg).
" debug_output=path_to_file
An optional entry that specifies that debug output will be sent to the file location
indicated.
Configuring Server Functionality

The following sections describe the configuration settings that determine the TeamSite
server functionality.
Controlling Modification Times

The old_mod_times setting controls what value is returned for the modification time of a
file through the file system interface.
[iwserver]
[old_mod_times=true]
By default, old_mod_times is set to true, and the modification time of a file is the time a
user last changed the file's contents. Submitting a file to the staging area or updating it into
your workarea through Get Latest does not affect the modification time; the modification
time will be the same as the modification time of the source file. If old_mod_times=false,
the modification time of a file is the later of the time (1) a user last changed its contents and
(2) the time the file was updated into the workarea (with get-latest, copy-to-area, or
iwupdate operations) or submitted if it is a file in the staging area or an edition).
This distinction is important when you are using TeamSite for SCM. A lot of build tools, like
UNIX make, rely on timestamps to determine whether it needs to regenerate object files.
They typically compare the modification time of the source file with the modification time
of the corresponding object file and decide to rebuild the object file only if the source file

has a later modification date. If you use such a build tool out of a TeamSite workarea with
old_mod_times=yes (the default), you could have problems if your workarea is not updated
before a build.
For example: You run make to recompile file1.c in your workarea. This generates object
file file1.o, with the current time as its modification time. However, yesterday another
user submitted another version of file1.c, but you did not update your workarea before
running make. This newer version of file.c has a modification time from yesterday (when
it was modified before being submitted). If you now update your workarea, you will get the
new version of file1.c, but its modification time would still be the time from yesterday. By
default, with old_mod_times=yes, the modification time of a file has no correlation to the
time you update your workarea. If you run make again, it would fail to recompile the new
version of file1.c, because the modification time of file1.o is later than the modification
time of the newer file1.c. This can be fixed by setting old_mod_times=no. The
modification time of file1.c would then show in your workarea with the time when you
did the get-latest procedure, and make would know to regenerate the object file.
The old_mod_times setting only affects the modification time displayed through the file
system interface and not through ContentCenter. The modification time of a file in a user
interface is always the time the contents changed.
Modifying Extended Attributes

Normally when extended attributes (EAs) are modified, the timestamp of the file is not
modified. You can set up TeamSite so that the timestamp is modified whenever the EAs are
modified using the force_EA_mod_times option in the iw.cfg file.
[iwserver]
[force_EA_mod_times=false]
Specifying the Encoding of the iw.cfg File

To facilitate the internationalization of TeamSite, you have the ability to use text editors that
save the iw.cfg file in various encodings. The encoding setting in the first section of the
iw.cfg file declares the encoding of the iw.cfg file itself. The default setting is ascii.
To change the encoding of the iw.cfg file, add the following lines to the beginning of the
file:
[iwcfg]
encoding=encoding_type
where encoding_type is one of the following:

" ascii (default setting)
" ISO-8859-1
" windows1252
" euc-cn
" euc-jp
27
" euc-kr
" shift_jis
" utf-8
Note: This must be the first section in the iw.cfg file—no other entry can precede it.
Web Daemon
To set Web daemon defaults, edit the [iwwebd] values in the iw.cfg file:
[iwwebd]
host=hostname.domain
http_port=80
https_port=443
default_protocol=http
The default_protocol setting is used by the following scripts when TeamSite generates
URLs:
" iwsend_servlet_mail.ipl script—uses it to embed URLs into the email messages it

sends.
" <iwov_webdesk_url> presentation template tag—uses it when generating hyperlinks
to the TeamSite server (see the FormsPublisher Developer’s Guide for more information).
For more settings in [iwwebd], refer to Chapter 8, “Configuring the TeamSite Web
Daemon and Proxy Server.”
Servlet Engine
By default, the servlet port is set to 8080. To change this setting, edit the servlet_port
value in the [teamsite_servlet_ui] section of the iw.cfg file.
[teamsite_servlet_ui]
servlet_port=8080
Locking Models
TeamSite supports three types of file locking:
" Submit Locking – Only users within the workarea where the file is locked may submit
the file (default); this is the least restrictive locking model.
" Optional Write Locking – Users choose whether to lock files they edit.
" Mandatory Write Locking – Users cannot edit a file without locking it.
A branch’s locking model is set when it is created. Different branches on one TeamSite
server may use different types of locking. All workareas on a branch use the same type of
locking.

When a file is locked, it is locked for a particular workarea. That is, all users who have
access to that workarea can edit the file. In addition, all users who have previously modified
the file can edit it in their workareas (but not lock it).
Locked File Submission

You can configure TeamSite to allow only the owner or creator of the lock to submit a
locked file to the staging area (as opposed to allowing any member of the workarea where
the file is locked). To configure this option, add the following line to the [iwserver]
section of iw.cfg:
[iwserver]
only_lock_owner_creator_submits=yes
Setting a Locking Model on a Branch

TeamSite enables you to specify the locking model of each branch at the time that it is
created. However, the main branch is created automatically by the TeamSite installation
program and it uses the default option of Submit locking.
Creating a new Content Store also creates a new main branch. You can specify which
locking model to use for the main branch of a new Content Store by completing the
following procedure:
1. Edit the main_lock_model line in the [iwserver] section of iw.cfg as follows:

[iwserver]
main_lock_model=locking_model
where locking_model is either of the non-default models:
! optional_write_lock (or o)
! mandatory_write_lock (or m)
2. Save and close the iw.cfg file.

3. Run the iwreset CLT to ensure the edit is recognized.
4. Create a new Content Store as described in the TeamSite Installation Guide.
The new Content Store uses the setting specified by the main_lock_model line when it
was created. The type of locking a branch uses cannot be changed after the branch has
been created.
Note: Using optional or mandatory write locking may significantly reduce system
performance.
29
Comparing Files
When TeamSite is comparing two versions of a file, it checks the version history chain to
determine a common ancestor for the two versions. You can specify the number of versions
to check using the compare_search_limit option in iw.cfg, as follows (the default is 20):
[iwserver]
compare_search_limit=20
Submit and Update Logs

By default, the Submit and Update logs contain the 64 most recent Submit or Get Latest
operations for a workarea (as opposed to the 64 most recent files that were submitted or
updated). You can change this number, by editing the event_log_size line in the
[iwserver] section of iw.cfg.
[iwserver]
event_log_size=64
The [iwserver] section also contains two lines that configure whether or not you want all
the files contained in new or deleted directories to be listed individually in the Submit and
Update logs. The default setting (no) as shown in the following lines only displays the
directory names:
[iwserver]
full_submitlog=no
full_updatelog=no
To show all the files that were contained within the directory that was added or deleted,
edit the appropriate line to specify yes.
Autoprivate Feature
TeamSite’s Autoprivate feature enables you to prevent certain file types (including
temporary files and Macintosh resource forks) and directories, from being submitted to the
staging area or copied during a Copy To operation. File types specified in the Autoprivate
configuration file automatically get marked Private.
Note: Changes to Autoprivate only apply to files or directories that are created or
renamed after the changes are made. Changes do not apply to existing files.
To activate Autoprivate, create a text file named autoprivate.cfg in your

iw-home/local/config/ directory. The Autoprivate file consists of two sections:
" files (or directories) matched by pattern
" files (or directories) matched by name
Each section is set off by parentheses on their own lines, and the file begins with a “ ( ”
(open parenthesis) on its own line and ends with a “ ) ” (close parenthesis) on its own line.

Individual entries in the first section are in the following format:
((filenamepattern)(#_characters_to_match_at_beginning)
(#_characters to match_at_end))
where both #_characters_to_match_at_beginning and

#_characters_to_match_at_end are in hexadecimal.
For example, to have Autoprivate detect any file or directory that ends with .frk, add the
following entry:
((x.frk)(0)(4))
meaning to match zero characters at the beginning of the name and the four characters
(.frk) specified at the end of the name.
To set Autoprivate to detect any filename that ends in .backup.fm, add the following
entry:
((x.backup.fm)(0)(a))
where 0 specifies not to match any characters at the beginning, and a (hexidecimal 10)
specifies to match ten characters at the end of the filename.
Entries in the second section specify exact filename matches, set off by double parentheses.
These filename matches apply across all directories in all workareas on the TeamSite server.
For example, if autoprivate.cfg includes:
((test))
then all files and directories named test that are created after this line is added, in all
directories in all workareas in TeamSite, will be marked private.
The autoprivate.cfg file recognizes the following six special characters: ( ) [ ] # and
a space (spacebar). If your file names contain any of these characters, you must encode
these values when specifying them as a pattern. For example, to have Autoprivate detect a
file name that includes spaces, encode the spaces with a \20, for example, to match
“Network Trash Folder” include:
((Network\20Trash\20Folder))
31
Encodings are represented as \xx where xx is the hex value of the corresponding ASCII
character. The following table shows the mappings for the six special characters.
Special Character Autoprivate Encoding

# \23
[ \5b
] \5d
( \28
) \29
space (spacebar) \20
Encoding examples:
((\23x\23)(1)(1)) matches file names of the form: #*#

((\23bbaax)(2)(0)) matches: #b*
((\28ab\29)(2)(2)) #(ab) matches the file name: (ab), the #(ab) is a comment
((a\5b\5db)(2)(2)) matches: a[]b
The following sample autoprivate.cfg file includes a few common entries:

(
(
((x.o)(0)(2))
((x.a)(0)(2))
((x~)(0)(1))
((.nfsXXX)(4)(0))
((x.bak)(0)(4))
((x.tmp)(0)(4))
)
(
((network\20trash\20folder))
((Network\20Trash\20Folder))
((.HSAncillary))
((.HSResource))
((.hsancillary))
((.hsresource))
((.tnatr:intf))
((.tnatr:reso-fork))
((resource.frk))
((trash))
)
)
For changes to autoprivate.cfg to take effect, restart the TeamSite server or use the
iwreset command-line tool.

Enabling the Event Subsystem
Enabling the Event Subsystem

The Event Subsystem is packaged and installed with TeamSite and can be used to deliver
messages (events) to and from Search or Reporting with TeamSite as an event publisher and
Search and Reporting as subscribers. To do this, the Event Subsystem stores and queues
events.
The Event Subsystem uses a JMS (Java Message Service)-compliant model of message
delivery, which is based on three concepts:
" Events – Synonymous with message. Events are the result of changes, end-user actions, or
occurrences in a Publisher program. For example, TeamSite server events include (but
are not limited to):
! CreateBranch
! Submit
! TaskActivate
Events have names and properties, such as user, role, and timestamp, that are
represented in the Event Subsystem as attribute/value pairs.
A subscriber can be set up to perform functions after a TeamSite event occurs. For
example, an index can be updated after files are submitted.
" Publishers – Applications that send events to the Event Subsystem. The Event Subsystem
then passes the events to Subscribers that have registered to receive them.
" Subscribers – Applications that register with the Event Subsystem to receive events.
Subscribers can filter events so that they receive only the ones they need.
Figure 6 illustrates how the Event Subsystem works:
Publishers Event Subsystem Subscribers
TeamSite Search
Server Proxy Servlet
Reporting
Message Service Interface
Message Service
Implementation
Figure 6: How the Event Subsystem Works
The Event Subsystem is configured by the TeamSite installer. Refer to the TeamSite
Installation Guide for information.
33
Configuring the Event Subsystem Manually

The Event Subsystem is normally enabled during the TeamSite installation. You can verify
that the Event Subsystem was enabled by checking the iw-home/etc/iw.cfg file. Look for
the following line in the [event_subsystem] section:
ew_enable=true
If the line is not included, add it to the iw.cfg file. Save and close the file; issue the
iwreset CLT.
Note: The iw.cfg file may contain other commented-out settings in the
[event_subsystem] section; ignore these settings.
When you installed TeamSite, you were asked for information about your database system.
If that process was successful and no warning messages were issued, your database system is
active. If that information was not provided or if the database system was not configured
properly, perform the following steps to set up RDBMS-based event persistence:
1. Make a copy of the following file:
iw-home/eventsubsystem/conf/jmsconfignew_rdbms.xml.example
and give the copied file the following name:

iw-home/eventsubsystem/conf/jmsconfignew.xml
2. Open the copied file using a text or XML editor.

3. Remove the comment tags from the RdbmsDatabaseConfiguration section that corre-
sponds to the RDBMS to use. The RdbmsDatabaseConfiguration section is located in
the DatabaseConfiguration section of that file.
The following code sample shows the commented RdbmsDatabaseConfiguration
section for an Oracle database:

Change the values for the driver, url, username, and password attributes according
to your needs.
4. Copy the appropriate JDBC drivers into iw-home/eventsubsystem/lib.
Oracle classes12.2.p
(shipped with TeamSite Reporting)
DB2 db2jcc.jar
MsSQL mssqlserver.jar
msbase.jar
msutil.jar

Configuring Server Performance
5. Create and register database tables before you start the Event Subsystem. A number of
SQL scripts that let you create and register the tables are included with TeamSite and
reside in the following location:
iw-home/eventsubsystem/conf/ddl/create_dbvendor.sql
Run the script that corresponds with the database to use. You can execute the SQL
script using a client utility supplied by the database vendor. For example, if you are
using an Oracle database, use SQL*Plus. If you are using Microsoft SQL Server, use
Query Analyzer.
If you are running this script for the first time, the Event Subsystem tables may not be
present and you will receive an error message. Ignore the error message and continue
executing the script.
6. Configure Event Subsystem logging by editing the log4j.xml file in
iw-home/eventsubsystem/conf. Only the location and name of the configuration file
need to be specified. The Event Subsystem uses log4j for logging. More information
about this can be found at www.apache.org/log4j.
7. Start the Event Subsystem byrunning the iw-home/private/bin/iweventsubd script.
8. Restart JmsProxyServlet to ensure that the servlet engine starts publishing to the
Event Subsystem by entering the following commands at the prompt.
iwreset
iwreset -ui

The following sections describe the configuration settings that enable you to maximize the
performance of TeamSite relative to your unique environment.
Cache Size
To set the TeamSite cache size, edit the cachesize line in the [iwserver] section of
iw.cfg. If a comment symbol (#) begins the line, remove it. If this line does not appear in
your iw.cfg file, add it as shown below. The initial cache size setting should be
approximately three times the number of files and directories on the largest branch.
For example, if the largest branch contains 15,000 files and directories, you should set cache
size to 45000 as follows:
[iwserver]
cachesize=45000
Minimum cache size is 1000; maximum is 400,000 entries. Each cache line takes a
maximum of 1KB of physical memory. Recommended physical memory is cache size times
1KB plus an additional 25% as a safety margin. In the example shown below, physical
memory would be (45,000 * 1KB) + 11MB = 56MB. If you encounter a great deal of
memory swapping, you should either reduce the cache size or install more memory.
35
Note: The value of cachesize is not the amount of memory that is used, but the number
of objects kept in the cache.
You must restart the TeamSite server for this change to take effect.
RPC Threadcount
The RPC threadcount setting determines how many simultaneous requests TeamSite can
handle from RPC clients. These requests are very short-lived, so that threads are quickly
freed for other users. If all threads are currently being used, TeamSite starts to serialize
requests.
[iwserver]
rpc_threadcount=64
Note: This setting should not be altered.
File System Threadcount

The file system threadcount should be set to twice the number of CPUs on your TeamSite
server. To change the file system threadcount, edit the fs_threadcount line in the
[iwserver] section of iw.cfg. For example, if the system hosting the TeamSite server has
two CPUs, set fs_threadcount as follows:
[iwserver]
fs_threadcount=4
You must restart the TeamSite server for this change to take effect.
Hopi Threads
Hopi is a file transport mechanism for making remote procedure calls between client and
server programs. It has several configuration settings; however, you most likely will not
need to modify these settings.
To control the number of threads that the server creates for handling client requests, set
hopi_threads:
[iwserver]
hopi_threads=256
The default value is 256. Increase this value if the system starts to refuse connections under
heavy loading, indicating it is out of threads). A guideline is to set this to four times the
maximum number of concurrent users, up to a maximum of 1024.
To set the TCP/IP port on which requests are received, set hopi_port:
[iwserver]
hopi_port=8898

The default setting is 8898. You need to change this value if the default setting conflicts with
another application on the same system. The port number can be between 1 and 65535.
To set the maximum number of requests that can be sent to iwserver over the same TCP/IP
connection, use hopi_max_requests_per_connection:
[iwserver]
hopi_max_requests_per_connection=500
The default setting is 500. If a system has a large number of concurrent users and is running
out of threads or connections, it may help to reduce this value so that threads/connections
become available for new clients more quickly. On the other hand, if an application
legitimately and routinely makes more than 500 requests in a short period of time, it may
help to increase this value in order to reduce the overhead of having to reconnect each time
the limit is reached.
To set the maximum amount of time a request thread can be idle waiting for a new request
before it closes the connection, use hopi_idle_session_timeout:
[iwserver]
hopi_idle_session_timeout=5
The time is specified in seconds and the default is 5. Systems with a large number of
concurrent users may need to reduce this value if they find they are running out of threads
or TCP/IP connections frequently.
Throughput Monitors
Throughput monitors can be used in conjunction with the iwstat CLT to monitor system
status and performance. By default, the throughput monitoring is set to off. To turn on
throughput monitoring edit the thruputmonitoring line in the [iwserver] section of
iw.cfg as follows:
[iwserver]
thruputmonitoring=on
After turning monitoring on, the five default throughput monitors are activated. They
return system statistics over the previous minute, 15 minutes, hour, eight hours, 24 hours,
and for the entire time that the system has been running.
You can deactivate any of the default monitors by adding a comment mark (#) to the
beginning of the line. The last two throughput monitors can be configured with custom
time intervals.
37
[iwserver]
thruputmonitoring=on
thruputmonitor1=1 # 1 minute
thruputmonitor2=15 # 15 minutes
thruputmonitor3=60 # 1 hour
thruputmonitor4=480 # 8 hours
thruputmonitor5=1440 # 24 hours
thruputmonitor6=-1 # forever
thruputmonitor7
thruputmonitor8
Detecting Low Disk Space and Inode Count

TeamSite is configured to freeze the Content Store when it detects that free disk space or
inode count is low. The Content Store remains frozen until sufficient disk space or inode
count is restored, at which point the server returns to its normal running state. This feature
helps prevent possible corruption of the Content Store. While the Content Store is frozen,
users cannot write to the TeamSite Content Store. Users can still perform read-only
operations. The CLT iwfreeze can be used to manually freeze the Content Store.
The three disklow lines in the [iwserver] section of iw.cfg control the behavior of
disk/inode low detection. They are shown here with their default settings:
[iwserver]
disklow_mbytes=50
disklowpercent=10
disklow_knodes=50
" disklow_mbytes—Defines the freeze threshold in MB for the TeamSite server. The
TeamSite server does not allow any write operations if the disk space falls below this
setting.
" disklowpercent—Defines the percentage of free disk space that is considered low. If
the server detects a low-disk state based on the threshold set in iw.cfg, it does not
allow you to manually unfreeze the Content Store with the iwfreeze command. The
TeamSite server does not allow disklowpercent to go below 2 percent.
" disklow_knodes—Defines a freeze threshold in thousands of inodes for the TeamSite
server.
To change these settings, edit the setting on any of these lines.
Configuring the TeamSite Server Locale

The iw.cfg file contains a server_locale entry in the [iwserver] section. The entry
specifies the locale in which current execution of the TeamSite server (iwserver) runs. For
example:
[iwserver]
server_locale=English_UnitedStates.US-ASCII@Binary;

This setting is automatically created in the iw.cfg file when iwserver is started. The native
locale is determined by reading the LANG environment variable. Once the server_locale
setting exists in the iw.cfg file, it is used to determine the TeamSite server’s native locale
at every invocation of iwserver. If this setting is not present, iwserver determines its locale
from the LANG environment variable.
Note: While this setting can be user-modified, it is designed to serve as reference as to the
locale in which iwserver is currently running. If you have a situation where you
want to force iwserver to run in a particular locale (independent of the LANG
environment variable) you can stop the TeamSite server, manually edit the
server_locale line, then restart the TeamSite server.
The locale in which the server operates (as defined by the server_locale entry),
effectively determines the locale of the TeamSite IFS. For example, if iwserver runs under
the Japanese_Japan.Shift_JIS@Binary locale, all file and directory names are encoded
in Shift_JIS encoding.
The server_locale setting in the iw.cfg file can contain any of the locales listed in the
following table (note that these settings are Interwoven naming conventions—the operating
system locales to which they map are also contained in the table):
iw.cfg server_locale Setting Solaris

SimplifiedChinese_China.MS936@Binary zh
Korean_Korea.MS949@Binary ko
Japanese_Japan.Shift_JIS@Binary ja_JP.PCK
Japanese_Japan.JapanEUC@Binary ja
German_Germany.Latin1@Default de
English_UnitedStates.US-ASCII@Binary C (“C” locale)
The following sections describe how to configure TeamSite FormsPublisher to provide an
example templating environment. After the initial setup is complete, you can:
" Use the example templating environment to become familiar with the TeamSite
FormsPublisher end-user features.
" Customize the example environment to create your site-specific configuration.
Perform the following steps to set up the example FormsPublisher environment. You must
copy these files and directories to locations that are specific to your site.
1. Decide which workarea you will use for the initial TeamSite FormsPublisher setup.
39
Ideally, this workarea should be on a temporary test branch where you can submit and
publish without affecting the rest of your TeamSite installation. After TeamSite
FormsPublisher is configured in a workarea on this test branch, you can copy the
workarea to a permanent branch. You can then submit the workarea to the staging area
and use Get Latest to propagate the setup to other workareas on the branch.
2. Read the iw-home/examples/Templating/README file (and README files in the each
subdirectory) for details about directory contents and last-minute information that
might not be documented elsewhere.
3. Copy the contents of iw-home/examples/Templating/templatedata (including the
templatedata directory itself) to the workarea determined in step 1.
Note:
! Ensure all users have read and write permission for each file.
! Do not change any directory or file names.
! The end result should be workarea_name/templatedata/...
4. Edit the templating.cfg file to specify the branches where FormsPublisher is used.
5. Optionally, edit the available_templates.cfg file as described in the Workflow
Developer’s Guide.
FormsPublisher Settings in iw.cfg

You may need to configure the following FormsPublisher settings in your TeamSite iw.cfg
file:
Identifying the Templating Directory

To change the directory in your workareas where templating content will reside, modify the
/etc/iw.cfg file. The default directory is templatedata.
[teamsite_templating]
data_root=directory
Maintaining Preview Files

A manifest file is created at the top of the user’s workarea when a preview is performed.
Included in the manifest file is a list of files created during a preview. When a new preview is
requested, the manifest file is checked and the temporary files listed in it are deleted. The
manifest file is also deleted. The preview is then generated and a new manifest file is
created.
The preview_history_limit parameter in the iw.cfg file lets a user do multiple

previews and compare the results of previews without the preview files being deleted. For
example, if preview_history_limit=2, two temporary preview files would be
maintained. When the user does a third preview in the same workarea, the oldest set of
preview and manifest files are deleted and replaced with preview files that are created by
the current preview. As a result, a user's workarea always contains two manifest files and

TeamSite Embedded Failsafe
the corresponding preview files. These files are marked private so they will not be
submitted to the staging area or shown in a TeamSite directory listing.
preview_history_limit=value
The preview_system_directory parameter in the iw.cfg file puts preview system files,
such as manifest files, in a directory other than data_root (templatedata).
preview_system_directory=directory
Controlling Printing of Data Records

Data records are normally written so that all content appears on a single line. You have the
option to print so that each new XML element in a data record starts on a new line,
indented. To enable this type of printing, include the following line in the /etc/iw.cfg file.
pretty_print_dcrs=true
TeamSite Embedded Failsafe

The TeamSite Failsafe functionality has been automated to improve the ability to protect
your assets against unexpected server outages. Unlike previous versions of TeamSite, there
is no need to modify your iw.cfg file to benefit from what is now known as Embedded
Failsafe.
Embedded Failsafe improves reliability by automatically flushing the cache at clean flush
points, thereby reducing the possibility of on-disc metadata inconsistencies caused by
abnormal server termination.
41

Chapter 4
Managing the TeamSite Server
This chapter describes configuration settings and procedures that can be used to manage and
enhance your server performance. While there are many variables that contribute to your
TeamSite server performance, the information contained in this section should prove useful
to most TeamSite administrators.
Verifying Server Operation

To verify that the TeamSite server is running, complete the following procedure:
1. Type the following command:
% /bin/ps -ef | grep iwserver | grep -v grep
If the iwserver process (that is, the TeamSite server) is running, you will see a response
similar to this:
root 18309 18304 1 08:03:10 ? 2:56 /usr/iw-home/bin/iwserver
local/iw-store
If you do not see a similar response, iwserver is not running. To troubleshoot your
installation:
! Solaris—Check the iwtrace.log file to see if TeamSite stopped abnormally
producing an EXITED: message.
2. If you determine that the TeamSite server stopped abnormally, stop the Teamsite ser-
vices with the following command:
% /etc/init.d/iw.server stop
3. Start TeamSite by running the following command:

% /etc/init.d/iw.server start
Starting and Stopping the TeamSite Server

To stop the TeamSite server:
To restart the TeamSite server:
43
Note: If you stop the TeamSite server while there are open handles (for example,
someone has a file from the Content Store open, or is exploring it, or it is remotely
mounted), either of the following entries may be written to iwtrace.log:
ERROR: DrvUnMountDevice - Lock volume failed Access Denied
or:
Trying to delete non-existent vnode 0xXXXXXXXX
These messages can be ignored.
Checking for Multiple Servers

One server process should be running at any given time. If there are no processes running,
then the server is not running. If more than one server process is running, there is a problem
with the server and it should be stopped and restarted.
To reset the server to ensure that only one server process is running:
1. Issue the following command to stop the server:

2. Verify that all server processes have stopped. If not, manually kill any remaining pro-
cesses. For more information on the kill command, consult a UNIX reference manual.
3. Restart the server with the following command:
Checking Request Handling

To ensure that the TeamSite server is answering requests correctly, type the following
command:
% iw-home/bin/iwversion
If the TeamSite server is responding, you will see a response similar to this:
iwserver: 6.5.0 Build 35489 Interwoven 20040930
If the server does not respond or stops, then the server is not handling requests correctly.
Restart the server as described in “Checking for Multiple Servers” on page 44.

Verifying the Server Mount
Verifying the Server Mount

Verify the server is mounted to the correct drive partition with the following command:
% df -k | grep iwserver
The output should contain a line similar to this:
Filesystem kbytes used avail capacity Mounted on

server:/iwserver/default 3141968 1542472 1285336 55% /iwmnt/default
If the server does not respond properly, stop and restart it with:
/etc/init.d/iw.server stop then /etc/init.d/iw.server start.
Locating the Installation Directory

To locate the TeamSite installation directory, type iwgethome at a command prompt and
press Return. TeamSite displays the installation directory:
% iwgethome
/local/iw-home
For detailed information about iwgethome and all TeamSite CLTs, refer to the TeamSite
Command-Line Tools manual for your platform.
Reviewing TeamSite Log Files

TeamSite records events in various TeamSite log files. These files, their contents, and default
locations are described in the following sections.
Note: The default locations of files is iw-home\local\logs when TeamSite is installed on
a Windows server or is installed on a Solaris server using the GUI. If TeamSite is
installed on a Solaris server from the console, the default location is /var/adm.
WWFS Log
On system startup, the TeamSite kernal device driver (iwovwfs) is installed. This occurs
before most other services are up. Messages from this installation are logged into
/var/adm/iwwfs.log, and an error message is printed to the console instructing you to
look at this log file. The location of this file cannot be changed.
Installation Log
The TeamSite installation log records the prompts and your replies to them during the
execution of the TeamSite installation program. The file is called iwinstall.log and by
default, is located in iw-home/install/.
45
ConfigurationServer Log
The server log records the state of TeamSite over time—including, but not limited to—
when the TeamSite server is started, stopped, and mounted. The file is called
iwserver.log and by default, is located in iw-home\local\logs. If the file is not in the
default location, you can locate it by checking the /etc/defaultiwtrace file.
You can also find this file using the CLT iwgetlog.
Trace Log
The trace log records any irregularities on the TeamSite server. It is primarily used by
Interwoven Consulting Services to diagnose system performance issues. The file is called
iwtrace.log and by default, is located in iw-home\local\logs. If the file is not in the
default location, you can locate it by checking the /etc/defaultiwtrace file.
You can also find this file using the CLT iwgettrace.
Events Log
The iwevents.log records TeamSite activities—including, but not limited to—file
submits, edition, branch and workarea creation, and DiskLow, Freeze, ShutDown, StartUp
and Thaw events. It is used with TeamSite triggering scripts. By default, the file is located in
iw-home\local\logs.If the file is not in the default location, you can locate it by checking
the /etc/defaultiwelog file. You can also find this file using the CLT iwgetelog. The
entries in your iwevents.log file will be similar to these:
event-specific
timestamp user role event information
[Thu Aug 21 19:44:57 2004] root master StartUp

[Thu Aug 21 20:47:27 2004] root master Freeze 60
[Thu Aug 21 20:47:29 2004] root master ShutDown
[Thu Aug 21 20:50:15 2004] root master StartUp
[Fri Aug 22 11:47:47 2004] tom editor TaskGroupTaken CPE
Workflow 0x3ffcf Editor Review 0x3ffd8 tom
event-specific information
(the example line wrapped)
The last sample line states that on Friday August 22, 2004, the user tom, who is logged in
with the role of editor, took ownership of task 0x3ffd8 (or 262104). The task is labeled
Editor Review in job 262095 and is part of a workflow named CPE Workflow. The user
tom assigned ownership to the task to tom (himself).

Monitoring the Server Load
Workflow Log
The workflow log records the output from workflow runtime diagnostics. It is located in
iw-home\local\logs\iwjoberrors.log. The log file contains entries when the following
events occur:
" When the TeamSite server encounters an error compiling a workflow, including:
! a task’s named owner has insufficient privileges to its areavpath
! an areavpath does not exist
This does not include every workflow specification that has errors—some errors occur
on the client.
" When the workflow engine has problems while running tasks in a job, including:
! attempting to create a task variable that already exists.
! attempting to add a file to a task that is already in its file list.
iwprocessd and iwprocoutput Logs

TeamSite for UNIX includes a daemon called iwprocessd that runs certain tasks on behalf
of the TeamSite server. All iwat triggers and workflow external tasks are now executed by
iwprocessd, rather than iwserver. This prevents some file descriptor inheritance issues
and lowers the virtual memory footprint of the child process.
The iwprocessd daemon is automatically installed by the TeamSite installation program

and is started with TeamSite. It requires no configuration and logs its internal issues to the
iwprocessd.log file.
A new log file, iwprocoutput.log, contains the standard output and standard error from
processes spawned from iwprocessd. This data was formerly logged to iwtrace.log.
Monitoring the Server Load

The TeamSite CLT iwstat returns a list of all current TeamSite processes, for example:
" While the TeamSite server is not running (as the result of iwfreeze), iwstat returns:
*** SERVER FROZEN: 55 SECONDS REMAINING ***
ID Thread User Duration Operation
0x9d 0xf root 0.000 GetArchiveStatus
" While the TeamSite server is running, iwstat returns:
Status: Server running
ID Thread User Duration Operation
0x3f4e 0x17 mroot 0.000 GetArchiveStatus
Minutes Thruput Avg op Load
1 27 0.0189 0.51
15 14 0.0219 0.30
29 9 0.0233 0.20
See TeamSite Command-Line Tools for details about iwstat usage and output.
47
Managing the OpenAPI Server

The OpenAPI server is an RMI service and is no longer part of the Interwoven Servlet
Engine. It is automatically installed and started by the TeamSite installation program.
Additionally, an OpenAPI configuration file, openapi.cfg, is also installed by the TeamSite

installation program. It does not need to be modified. I18N requirements are also
automatically handled by the installation program, which creates the iwopenapi/locale
directory.
Verifying that the OpenAPI Server is Running

To verify that the OpenAPI server is running, issue the following command:
% ps -ef | grep openapi
The system confirms that the Interwoven OpenAPI daemon is running:
bgunn 14495 1 0 01:47:58 ? 6:53

iwopenapi -server -Xss4000000 -Djava.library.path=/usr/teamSite/iwopenapi
-D jav
If it is not running, restart it as described in the next section.
Starting and Stopping OpenAPI

To manually start the Interwoven OpenAPI daemon, issue the following command from the
iw-home/private/bin directory as a user with root privileges:
# iwopenapiboot start
You can also stop and restart the OpenAPI daemon with the following commands:
" iwopenapiboot stop
" iwopenapiboot restart
Note: Do not use the obsolete OpenAPI startup script /etc/init.d/iw.openapi.
For more information about OpenAPI, consult the administration chapter of the OpenAPI
Developer’s Guide, available online as part of the OpenAPI SDK.
Reconfiguring iwwebd to Recognize a New IP Address

If you change the IP address of the server hosting TeamSite, complete the following
procedure to reconfigure iwwebd to recognize the new address.
1. Go to the iwwebd.bin directory.
2. Run iwwebd_conf.ipl from the command line.
3. Restart iwwebd.

Enhancing Server Performance
Enhancing Server Performance

The following sections describe procedures you can use to enhance the performance of
TeamSite.
File Locations
The [locations] section of iw.cfg must be updated if you change the locations of certain
TeamSite files and directories from their default locations. To change the location of one of
the following files, remove the comment (#) marks from its line and edit the line to point to
the new location (ensure that the [locations] line is not also commented out). After
restarting, TeamSite looks for the specified file or directory in the new location.
[locations]
iwbin=/usr/iw-home/bin
iwmount=/iwmnt
iwcgimount=/.iwmnt
iwroles=/usr/iw-home/local/config/roles
iwstore=/local/iw-store
iwsubmitconfig=/usr/iw-home/local/config/submit.cfg
iwautoprivate=/usr/iw-home/local/config/autoprivate.cfg
iwlogs=/usr/iw-home/local/logs
iwconfigs=/usr/iw-home/local/config
iweventlog=/var/adm/iwevents.log
iwtracelog=/var/adm/iwtrace.log
iwserverlog=/var/adm/iwserver.log
iwdeploylog=/usr/iw-home/local/logs/iwdeploy.log
where:
iwbin Specifies the location of TeamSite binaries (by default
/Interwoven/TeamSite/bin).
iwmount Specifies the location of the TeamSite mount point.
iwcgimount Specifies the location of the TeamSite mount point.
iwroles Specifies the directory containing the TeamSite roles files.
iwstore Specifies the location of the TeamSite Content Store.
iwsubmitconfig Specifies the location of the Submit Filtering configuration file.
iwautoprivate Specifies the location of the Autoprivate configuration file.
iwlogs Specifies the directory containing TeamSite logs.
iwconfigs Specifies the default configuration file directory.
iweventlog Specifies the location of the TeamSite event log.
iwtracelog Specifies the location of the TeamSite trace log.
iwserverlog Specifies the location of the TeamSite server log.
iwdeploylog Specifies the location of the deployment log.
49
Note:
" If you change the location of iwmount, you must edit its webserver alias to point to the
new location. In addition, any existing files in /etc/defaultiw* take precedence over
these settings.
" If you change the location of one of the logs and no file with the specified name is
present in the new location, a new file is created.
Monitoring Disk Space Usage

You have two options for checking the amount of disk space used by the files being managed
by TeamSite, either:
" The size of the Content Store—Actual disk space being used.
" The size of the mount point—Contains many virtual copies of files in workareas,
staging areas, and editions.
To check the amount of disk space used by files managed by TeamSite, issue the following
command:
% df -k `cat /etc/defaultiwstore`
The system will return something similar to the following:
Filesystem kbytes used avail capacity Mounted on

/dev/dsk/c0t2d0s2 17637068 9613319 7847379 56% /local
Although the mount point contains many virtual copies of files in workareas, staging areas,
and editions, df -k only checks the actual disk space used.
Deleting Editions
To reclaim some disk space, you can delete old editions, which also deletes all files
contained in that edition and all intermediate submissions between publication of editions.
You should be aware that if a file is contained in more than one edition and not all of these
editions are deleted, the file is not deleted; only the pointer to the file in the deleted edition
is deleted. Therefore, you may not save as much space as you anticipate.
To delete an edition using the ContentCenter Professional interface:

1. In the branch view, click the check box next to the edition you want to delete.
2. Select File > Delete.
A confirmation window displays.
3. Type YES in the confirmation field and then click Delete.

Monitoring Disk Space Usage
The edition and all versions of the files contained within that edition are deleted.
Additionally, all Submit Log entries are transferred to the next most recent edition. If
the edition you have deleted is the newest one, the Submit Log entries are transferred to
the Staging area.
Note: You can also delete editions using the iwrmed CLT as described in the Command-Line
Tools manual.
Metadata Forking
Metadata forking conserves disk space by reducing the number of files whose content is
duplicated throughout the TeamSite Content Store. That is, if you have an old version of a
file in one branch, and an identical version on another branch, the same data may appear
twice in the Content Store. Metadata forking is accomplished by running the iwfsshrink
CLT and results in no user-visible changes to the TeamSite virtual file system (for example,
file histories are not changed).
The iwfsshrink utility must be run while the TeamSite server is running; however,
TeamSite may experience some performance degradation while it is running. Also,
iwfsshrink may not remove all duplicates (for example, it does not remove any duplicates
created by TeamSite users while the utility is running). The iwfsshrink utility should be
run every few months.
1. Start the iwfsshrink utility from the command line:

% iwfsshrink run
The utility may take several hours to run.

2. Issue the command again using the status option to view the current status:
% iwfsshrink status
when iwfsshrink finishes running, it returns a message similar to:

Not currently running.
Last started Mon Jun 26 15:47:53 2002
Last completed Tue Jun 27 00:40:04 2002
Files examined: 317974
Bytes examined: 75936814830
Files found to be duplicates: 233430
Files converted: 198352
Bytes removed: 23455046531
3. Optionally, you can pause the operation with the pause option, then restart it with the
run option.
For more details about the iwfsshrink utility, see the Command-Line Tools manual.
51
Moving the Content Store and Removing Old Versions

If you are running out of disk space and iwfsshrink does not recover enough extra space,
you may need to move the TeamSite Content Store. The TeamSite Content Store must
reside on a single logical volume, for example, a single disk or an array of disks.
Alternatively, if you have unused branches in TeamSite, you can delete these branches to
recover disk space. Over time, individual branches take up an increasing amount disk space,
as the number of versions and files on the branch grows. If you do not need any of your old
version history, you can create a new (empty) branch, create a workarea, copy all the old
content into the workarea, then delete the old branch. Exercise extreme caution when
doing this, as all version and metadata information will be irrevocably lost.

Chapter 5
Managing TeamSite Access
This chapter discusses various procedures for managing access to TeamSite, including
assigning user roles, user authentication, and filtering user submissions.
Access Considerations
Access to TeamSite is governed by the following two factors:
" UNIX-related permissions
" TeamSite access privileges
UNIX file permissions control who has access to individual files and directories. UNIX
password authentication is used when logging in to TeamSite. However, TeamSite access
privileges govern who can log in under various roles, and who has access to branches and
workareas. For example, to edit a file in a workarea, a user must both be able to access that
workarea (through TeamSite access privileges), and have permissions for that file and its
parent directory (through UNIX permissions). For a complete list of the TeamSite and
UNIX permissions needed to perform any action in TeamSite, see page 58.
When adding a new user, you need to consider the following three factors:
" Whether the user will have access to the server.
" The role the user will play in your TeamSite operations.
" The content the user will be editing.
If the user does not have access to the TeamSite server, he or she needs to be added as
described on page 55. To decide what TeamSite role best corresponds to the new user’s
role in your organization’s operations, see page 54.
To decide what groups the new users need to belong to and which workareas they need to
access, consider your existing groups and which content and which workareas they can
access. Add new users to the groups that work on the same content that they will be editing,
and they will automatically have access to their workareas and to their content files. If the
new users need their own workarea, create a private or shared workarea, but make sure that
they own or have group-level access to the files that they will be editing. To change
ownership or group access of files, see page 57.
53
When creating a new workarea, you need to decide:

" What the name of the workarea should be.
" Who will need to access the workarea (this can be one person or one person and a
group).
" What content the workarea’s owner and group should and should not have access to.
Set permissions on your files according to the latter consideration. Remember that
permissions cannot be set differently for different workareas. If the permissions for
corresponding files are set differently in different workareas, you will encounter conflicts
when you submit files to the staging area. It is often useful to keep a chart that shows what
users and groups have access to content. This is particularly useful when managing a
complex Web site.
Note: The TeamSite log-in screen accepts passwords up to 14 characters, but other
underlying authentication operating system mechanisms (including /etc/passwd,
PAM, LDAP, and SecureID) may have different policies. The UNIX default password
is a maximum of eight characters.
User Roles
To facilitate workflow and security, TeamSite defines the following four user roles, each
with varying levels of access to TeamSite:
" Master
" Administrator
" Editor
" Author
To determine which role a user should have, consult the following table and find the role
that best fits the user’s work.
Table 2: Roles and Associated Tasks
Author Editor Administrator Master
Owns content Owns workareas Owns branches Owns main branch
Edits and creates files Edits and creates files Edits and creates files Edits and creates files
Receives assignments Assigns files Assigns files Assigns files
Work is approved by Approves and rejects Approves and rejects Approves and rejects
workarea owner work of Authors work of Authors work of Authors
Uses advanced Uses advanced Uses advanced
version management version management version management
features features features
Maintains content of Manages branch Manages entire
workarea content area
Submits files to the Submits files to the Submits files to the
staging area staging area staging area

User Roles
Table 2: Roles and Associated Tasks (Continued)

Publishes editions Publishes editions Publishes editions
(optional)
Creates and deletes Creates and deletes
workareas workareas
Creates and deletes Creates and deletes
subbranches subbranches
In addition, Administrators can perform all the functions that Editors can. Master users can
perform all the functions that Administrators and Editors can.
Adding TeamSite Users

Before you can add a user to TeamSite, this person must be a UNIX user on the TeamSite
server. Always consult your system administrator before adding a system user.
Complete the following procedure to add a user to TeamSite (this procedure will vary if
you store user information in LDAP):
4. Ensure the user has a UNIX username and password. Add the user’s UNIX login name
to the appropriate TeamSite role files.
The following four TeamSite role files are located in the iw-home/conf/roles
directory (this directory may also contain role files for other Interwoven products):
master.uid
admin.uid
editor.uid
author.uid
Each file contains a list of the users who have privileges for that role, one user to a line.
Users can be added to multiple role files, for example, an Editor may also need to log in
as an Author. Master users should be able to log in with any role, therefore, include the
name of each Master user in each .uid file.
TeamSite users’ passwords are the same as their UNIX password.
5. Save and close the modified TeamSite role files.
6. Use the following CLT to ensure TeamSite is reading the modified role files:
% iwreset
The new user can now log in to TeamSite but does not have access to any branches or
workareas.
7. Optionally, add the user to the appropriate UNIX group files or TeamSite group if you
want the user to have access to a shared workarea (see “Group Membership” on
page 64).
55
8. Optionally, create a workarea for the user on the subbranch where he or she will be
working (see the ContentCenter Professional online help).
Deleting TeamSite Users

Complete the following procedure to remove a user from TeamSite:
1. Do one of the following:
! If your installation stores TeamSite role information in .uid (role) files, delete the
user’s name from each of these files.
! If your installation uses LDAP to store role information, delete all the TeamSite
roles from the user’s LDAP entry.
2. Use the following CLT to ensure TeamSite is reading the modified role files or the
updated LDAP database:
% iwreset
3. Use the following CLT to remove the user from the TeamSite entity database:
% iwuser -d username
where username is the username of the user you want to remove.

If you do not perform this step, you will not be able to create another user with the
same name.
To remove the user’s UNIX user account for the TeamSite server:
1. Delete the username from any group to which the user belongs.
2. Remove the user from the /etc/passwd file.
Always consult your system administrator before altering the /etc/passwd file.
Checking User Roles

The iwckrole CLT enables you to check whether or not a user can log in with a certain
role.
Usage
iwckrole [-h|-v] role user
-h Displays usage message.

-v Displays version.
role author, editor, admin or master.
user Username of the person whose role you are checking.
Exits with YES on successful authorization, NO on failure.

Changing Owner and Group of a Branch
Example
% iwckrole admin andre
returns:
YES
indicating that user andre can log in as an Administrator.
Changing Owner and Group of a Branch

You can specify the owner and group of the main branch of a new Content Store by editing
the main_owner and main_group lines in the [iwserver] section of iw.cfg. When
TeamSite is first installed, it uses the default option of root for main branch ownership as
follows.
[iwserver]
main_owner=root
main_group=root
To change this setting on an existing main branch, you must use the chown and chgrp
commands to change the ownership of the root directory of the main branch. However, if
you edit the main_owner and main_group lines and then create a new Content Store, the
new settings take effect on the new Content Store. For information about creating a new
Content Store, see the TeamSite Installation Guide.
Controlling Access to Files and Directories

To control access to individual files or directories, use chmod to change the permission
mode. Use chown to change the ownership of files or directories, and chgrp to change the
group. For more information on chmod, chown, and chgrp, consult a UNIX reference
manual.
You can also use a submit filter to automatically change and enforce permissions on files or
directories (see “Configuring Submit Filtering” on page 72).
Note that chmod, chown, and chgrp commands, when used recursively, affect every file in
the directory, whether they need to or not. This may generate excess TeamSite versions.
Instead, target the command using find:
% find . ! -group webedit -exec chgrp webedit {} \;

% find . ! -perm -g+w -exec chmod g+w {} \;
This affects only the necessary files and does not generate unnecessary versions.
57
TeamSite Groups
TeamSite also provides managed groups and group membership (referred to as TeamSite
groups) to complement the OS groups that TeamSite uses as groups for sharing branches and
workareas. This feature allows groups other than the OS groups to be specified for sharing.
When a branch is created, the TeamSite group can be entered in the Add Group field. When
a workarea is created and Group is selected for the Sharing field, the TeamSite group can be
entered.
NFS has the limitation of not being able to enumerate more than 16 groups for a user. If
such a group is used for branch or workarea sharing, it gives incorrect permissions.
TeamSite groups can be used in this case.
TeamSite uses the iw-home/conf/tsgroups.xml file, which is similar to the roles

(author.uid, editor.uid, and so forth) files. The tsgroups.xml file is created and
maintained by the iwgroup CLT. While the file can be modified by administrators, it is
recommended that modifications to the file be made through the iwgroup CLT. The
TeamSite server reads this file into memory and allows branches and workareas created
with group for sharing options to use these groups.
The iwgroup CLT manipulates Interwoven group information as follows:

" Adds a TeamSite group.
" Delete a TeamSite group.
" Adds a user or an OS or TeamSite group to a TeamSite group.
" Deletes a user or an OS or TeamSite group from a TeamSite group.
" Lists all TeamSite groups or groups of a user.
" Lists members of an TeamSite group.
" Modifies the name or ID of an TeamSite group.
Refer to the Command-Line Tools Reference for usage information on the iwgroup CLT.
More information on working with groups generally is provided in “Working with

Permissions” on page 58.
Working with Permissions

When users try to perform any action in TeamSite, the TeamSite server automatically
checks to see whether or not they have permission to perform that action. TeamSite checks
the following factors:
" User roles—If you are attempting to perform any of these actions through
ContentCenter, you must be logged in with the role specified. If you are using the file
system interface, you must be able to log in with the specified role.

" Branch permissions—A user has branch permissions if he is either the primary owner
of the branch or a parent branch, or if he belongs to the group that owns the branch or a
parent branch. Master users automatically have branch permissions for all branches.
Only Administrators and Master users can have branch permissions.
" Workarea permissions—A user has workarea permissions if he is either the primary
owner of a workarea, or if he belongs to the group that has access to the workarea.
Workarea permissions are usually synonymous with read-write-access to the root
directory of the workarea—the default setting for workarea permissions is 775. If
different permissions are specified for the owner and group, some sections of Table 3
will not apply. If “world” is given read-write-execute permissions, then all users are
considered members of the workarea for those conditions indicated with asterisks (*).
" File permissions—File permissions are UNIX read-write-execute permissions (unless
otherwise specified) to a file.
" Directory permissions—Directory permissions are UNIX read-write permissions
(unless otherwise specified) to a directory.
Not all of these factors apply to every action. TeamSite checks only the factors that apply to
the action being attempted.
Table 3 lists which privileges a user must have in order to perform an action in TeamSite.
To find out whether a user is able to perform a specific action, check the entry for that
action under the user’s role and determine whether or not the specified conditions apply.
All conditions listed in each box below must apply in order for a user to perform an action,
unless otherwise specified.
Note: TeamSite workflow tasks may require users to perform actions such as editing a
file, submitting it to the staging area, or taking ownership of a group task. To
perform the task, the user must have the ability to perform the action as specified in
the following table. For example, if you assign a task that requires an Author to edit
a file, the Author must have workarea permissions, parent directory permissions,
and file permissions for that file as specified in the table.
59
Table 3: Permissions for TeamSite Roles

Edit file 1 workarea workarea workarea workarea
permissions* permissions* permissions* permissions*
parent directory parent directory parent directory parent directory
permissions permissions permissions permissions
(read/execute) (read/execute) (read/execute) (read/execute)
file permissions file permissions file permissions file permissions
(write) (write) (write) (write)
View file workarea workarea workarea Yes
permissions* permissions* permissions*
parent directory parent directory parent directory
permissions permissions permissions
(read/execute) (read/execute) (read/execute)
file permissions file permissions file permissions
(read) (read) (read)
New file2 workarea workarea workarea workarea
(read/write/ (read/write/ (read/write/ (read/write/
execute) execute) execute) execute)
Move file workarea workarea workarea Yes
permissions* permissions* permissions*
Rename file3
(read/write/ (read/write/ (read/write/
execute) execute) execute)
or
branch
permissions
New directory workarea workarea workarea workarea
(read/write/ (read/write/ (read/write/ (read/write/
execute) execute) execute) execute)
Move workarea workarea workarea Yes
directory permissions* permissions* permissions*
Rename parent directory parent directory parent directory
directory permissions permissions permissions
(read/write/ (read/write/ (read/write/
execute) execute) execute)
or
branch
permissions

Table 3: Permissions for TeamSite Roles (Continued)

Delete file 4
No5 workarea workarea Yes
permissions* permissions*
parent directory parent directory
permissions permissions
(read/write/ (read/write/
execute) execute)
or
branch
permissions
Delete No workarea workarea Yes
directory permissions* permissions*
parent directory parent directory
(read/write/ (read/write/
execute) execute)
or
branch
permissions
Copy6 file permissions file permissions file permissions Yes
(through (read) (read) (read)
Content- directory directory directory
Center) permissions permissions permissions
(destination (destination (destination
directory) directory) directory)
workarea workarea workarea
Lock file7 No8 workarea workarea workarea
(read/execute) (read/execute) (read/execute)
file permissions file permissions file permissions
(write or (write or (write or
ownership) ownership) ownership)
Unlock file No creator of lock creator of lock Yes
or or
owner of owner of
workarea workarea
or
branch
permissions
Revert No workarea workarea Yes
or
branch
permissions
61

Get Latest No workarea workarea Yes
or
branch
permissions
Copy To No workarea workarea Yes
(destination (destination
workarea) workarea)
or
branch
permissions
(destination)
Set Public/ No workarea workarea Yes
Private permissions permissions
or
branch
permissions
View History No workarea workarea Yes
(read) (read)
Compare No workarea workarea Yes
(read) (read)
List Modified No workarea workarea Yes
(read) (read)
List Locks No workarea workarea Yes
(read) (read)
View Submit No workarea workarea Yes
Log permissions permissions
(read) (read)
View Update No workarea workarea Yes
Log permissions permissions
(read) (read)
Create branch No No branch Yes
permissions
Delete branch No No branch Yes
permissions
Rename No No branch Yes
branch permissions
Submit files No9 workarea workarea Yes
or
branch
permissions


Create edition No workarea workarea Yes
permissions for permissions for
any workarea on any workarea on
the branch the branch
or
branch
permissions
Delete edition No No branch Yes
permissions
edition permissions
Create No No branch Yes
workarea permissions
Delete No No branch Yes
View reports No No Yes Yes
Assign file No workarea workarea or Yes
permissions branch
permissions
View task task ownership job or task job or task job or task
ownership ownership ownership
View job ownership of a job ownership job ownership job ownership
information task within the ownership of a ownership of a ownership of a
job task within the job task within the task within the
job job
Create new No available_temp available_tem available_temp
job lates.cfg setup plates.cfg lates.cfg setup
setup
Transition task job or task job or task job or task job or task
ownership ownership ownership ownership
Add/remove job or task job or task job or task job or task
files from ownership ownership ownership ownership
existing task
View task job or task job or task job or task job or task
changes ownership ownership ownership ownership
Compare task job or task job or task job or task job or task
files (with ownership ownership ownership ownership
staging area)
Revert task job or task job or task job or task job or task
files (to ownership ownership ownership ownership
staging area
version)
1. The ability to edit a file only applies to files that are not already write-locked. If the file is write-locked, then only the
lock owner can edit it. Note that if an Author edits a file through the ContentCenter, TeamSite will lock the file.
2. The ability to create a file only applies to files that are not already write-locked. You cannot create a file with the same
name as a file that is already write-locked. If an Author creates a file, the new file will be assigned to him.
63
3. The ability to rename or move a file only applies to files that are not already write-locked. If the file is write-locked,
then only the lock owner can rename it. A file cannot be renamed with the name of a file that is locked. If an Author
renames or moves a file, the renamed or moved version of the file are assigned to him.
4. For Authors and Editors, the ability to delete a file only applies to files that are not already write-locked. If the file is
write-locked, then only the lock owner can delete it.
5. Authors can delete files through ContentCenter only.
6. If an Author copies a file, the copied version of the file will be assigned to him.
7. The ability to lock a file only applies to files that are not already locked.
8. Authors can lock files through ContentCenter only.
9. Authors cannot submit files directly. All work done by Authors must go through an approval process prior to
submission. The approver must have the ability to submit files.
Group Membership
Many workareas are shared by groups. For users to have access to a particular workarea,
they must either be the owner of the workarea or a member of the workarea’s group.
TeamSite uses UNIX groups for access control; it also uses TeamSite groups as described on
page 58. The UNIX groups can be managed with standard UNIX commands.
To create a group:
1. Open the /etc/group file in a text editor.
2. Add a new line to the file using the following format:
groupname:*:gid:username1,username2,username3
For example, the entry for the group allauthors might look like this:
allauthors:*:2000:pat,andre,chris
To add a user to a group:

1. Open the /etc/group file.
2. Locate the group that has access to the workarea to which you want to add the user.
3. Add the name to the list of usernames that follows it. Usernames must be separated by
commas.
If the user is an Administrator (that is, has an entry in the admin.uid file) and you want
that user to have Administrator privileges for a branch, add the user to the group of
Administrators for that branch.
You can add any number of users to a group.
Changing Group Ownership of Workareas

To change which group has access to a workarea:
1. Navigate into the directory containing the workarea.
2. Use the chgrp command to change the workarea’s group.

For more information on the chgrp command, consult a UNIX reference manual.

Example
In this example, user Chris changes the group for one of the workareas on the sales
subbranch. First, he navigates into the directory containing the workareas. Then, he looks at
the existing workareas and learns that Andre has two workareas, one private (andre1) and
one shared with the group demoauthor (andre2). Chris has one private workarea (wa1). He
uses the chgrp command to change the group on his workarea, then checks the results.
After this change, all members of the group demoauthor can access all files and directories
in the andre2 and wa1 workareas.
% cd /.iwmnt/default/main/sales/WORKAREA
% ls -la
total 3
drwxrwxr-x 27 andre nobody 512 Apr 23 17:07 andre1
drwxrwxr-x 3 andre demoauthor 512 Apr 17 11:52 andre2
drwxrwxr-x 2 chris nobody 512 Apr 17 11:37 wa1
% chgrp demoauthor wa1

% ls -la
total 3
drwxrwxr-x 27 andre nobody 512 Apr 23 17:07 andre1
drwxrwxr-x 3 andre demoauthor 512 Apr 17 11:52 andre2
drwxrwxr-x 2 chris demoauthor 512 Apr 17 11:37 wa1
Webserver UID
The webserver uid setting should be set to any uid that allows the web server to see the web
content as an outside viewer would see it, in order for users to be able to preview the Web
site like any external user would.Specify a single user ID. Because many external browsers
access the web server as nobody, this is used as the default.To improve security, you are
encouraged to change your web server to another user other than nobody and change the
value of webserver_uid. To change the web server uid setting, edit the webserver_uid line
in the [iwserver] section of iw.cfg. If iw.cfg does not contain this line, add it as shown
below:
[iwserver]
webserver_uid=nobody
Group Remapping
This option provides a workaround for a limitation of NFS. When NFS checks the group
that can access a file against the groups that a user belongs to, it only checks the first sixteen
groups that the user belongs to. Therefore, if the group on the file is the seventeenth (or
higher) group that the user belongs to, NFS will incorrectly deny the user access to the file
(this applies only to operations performed through the file system).
The map_secondary_to_primary option in iw.cfg works around this problem. Because

TeamSite does not have NFS’s sixteen-group limitation, it first determines whether a user
should have group-level access to the file. Then, if the map_secondary_to_primary option
is turned on, it maps the file’s group to the user’s primary group. Therefore, if you check
the gid on a file using the file system, it could return a gid different from the true gid of
65
the file. To find the file’s true gid, use the File > File Properties menu item in TeamSite or
the iwattrib CLT.
By default, map_secondary_to_primary_gid=no, to turn group remapping on, edit the

line in the [iwserver] section of iw.cfg to read as follows:
[iwserver]
map_secondary_to_primary_gid=yes
Workarea Access
By default, the workarea root file system permissions override any subdirectory permissions
(mask_workarea_access=yes). To set different permissions on subdirectories within your
workarea and disable access to the workarea root directory, set this option to no.
[iwserver]
mask_workarea_access=no
Permissions on the workarea root directory affect only this directory rather than the entire
tree.
Branch and Workarea Security

Branch and workarea security determines whether or not users can see the names of
branches and workareas they do not have access to. By default, the branch_security and
workarea_security lines in the [iwserver] section of iw.cfg are set to off. This means
that all branch and workarea names are displayed to users even if they do not have
permission to access them (they see the name of the branch or workarea, but it is not linked
and [N/A] displays next to it).
You can configure TeamSite to not display the names of branches and workareas in the
TeamSite GUIs if the user does not have read permissions by editing the branch_security
and workarea_security lines in the section of iw.cfg as follows:
[iwserver]
branch_security=on
workarea_security=on
Disabling Editors Creating Editions

By default, TeamSite allows users logged in as Editors to create editions. To restrict Editors
from publishing editions, edit the editor_publish line in the iw.cfg file as follows:
[main]
editor_publish=no
When editor_publish=no, the New Edition link does not display in the ContentCenter
Professional branches view for users logged in as Editors.
Note: This setting applies to all Editors on all branches.

Authentication
Default Permissions
You can configure the default permissions for branches, workareas, directories, and files
created using ContentCenter. Permissions on files created through the file system interface
are determined by your file system interface configuration (for example, the Samba
configuration).
To change the permissions, edit any or all of the four permission lines in the [iwserver]
section of iw.cfg to specify the octal values of the default permission bits for newly created
branches, workareas, directories, and files. The default settings are as follows:
[iwserver]
branch_default_perm=775
workarea_default_perm=775
file_default_perm=664
directory_default_perm=775
The new settings only apply to branches, workareas, directories, and files created after you
have edited these lines and run iwreset.
Authentication
Authentication involves determining whether users can access TeamSite resources. Methods
for doing this are described in this section.
User Authentication
TeamSite can be configured to authenticate users by the following methods:
" LDAP—Users’ credentials are passed to an LDAP server for verification. This requires
an external LDAP server which can also be used for TeamSite role authentication.
" External file—Users’ credentials are checked against a customer-specified file that is in
the same format as /etc/passwd or a shadow password file. The file name is specified in
the [authentication] section of iw.cfg using the password_file=fileName
parameter.
" Local—Users’ credentials are passed to the Solaris user authentication. If there is a
shadow password file, it is used to verify the credentials. If no shadow password file is
available, use the /etc/passwd file (this is the default method).
" Pluggable authentication modules (PAM)—Users’ credentials are passed to a PAM for
verification (Solaris 2.7 or later).
Complete the following procedure to specify the type of authentication used by TeamSite:
1. Add the following line to the [authentication] section of iw.cfg:
authenticate_by=mode
where mode specifies one or more of file, ldap, local, or pam.
67
You can separate multiple entries by commas or spaces, and you can specify precedence.
For example, if you specify authenticate_by = file pam, the file is checked first.
If this check fails, pam is checked next.
When TeamSite roles are stored in LDAP, it is not possible to use multiple
authentication methods: the authenticate_by parameter must be set to only ldap.
2. If ldap is specified in step 1, add the following lines to the [authentication] section
of iw.cfg:
ldap_server=ldap-server
ldap_port=ldap-port
ldap_dnbase=search-base-location
ldap_key=key
ldap_ssl_port=ssl-port
ldap_cafile=cafile-location
where:
! ldap_server is the name or IP address of the LDAP server
! ldap_port is the port for the LDAP server (optional; the default value is 389)
! search-base-location is the specification of DN base location according to
LDAP search syntax (for example, ldap_dnbase=ou=people,o=example.com)
! key is the name of the LDAP attribute that holds the user account names (optional;
the default value is uid).
Note: When user authentication is done using LDAP, the communication between
TeamSite and the LDAP server may optionally use SSL. This requires setting the
last two parameters.
! ssl-port is the port that the LDAP server uses to communicate when SSL is in use.
This is assumed to be port 636.
! cafile-location specifies the location of your CA certificate database file. This
file is expected to be in Netscape “cert7” format. A default “cert7.db file” that
contains the certifications for a variety of Certification Authorities is found in the
TeamSite installation in the directory iw-home\tools\db\netscape\cert7.db.
Note: If you are using LDAP, you must reset the TeamSite server with the iwreset
command after you make changes to the LDAP database. This command causes the
TeamSite server to replace existing user information in its local cache with new
data from the LDAP server.
Role Authentication Using LDAP

TeamSite role information is often stored separately from user authentication data.
However, TeamSite enables you to store role information in an LDAP database along with
user authentication data.
Note: TeamSite roles within your LDAP server can be queried and manipulated directly
using your LDAP tool or programmatically using an LDAP server programming
interface supplied by other vendors, not by Interwoven.

Authentication
Every LDAP directory has a schema that describes the objects and attributes that are found
in the directory. For example, you could have an object called user and an attribute
postaladdress. To configure TeamSite to perform user and role authentication, you can
either modify an existing attribute to represent TeamSite roles or create a new one.
Complete the following procedure to use your LDAP database to authenticate TeamSite
roles:
1. Add the following line to the [authentication] section:
ldap_roles=role-attribute-name
where role-attribute-name is the attribute name from the LDAP schema that stores
TeamSite roles.
2. If file is specified as one of the possible authentication modes (that is the
[authentication] section contains the line authenticate_by=file), add the
following line:
password_file=absolute-path-to-file
where absolute-path-to-file is the absolute path to a file containing encrypted user

passwords using the same format found in /etc/shadow. The section should look like
this:
[authenticate]
authenticate_by=file,pam
password_file=absolute-path-to-file
If pam is specified as one of the authentication modes (as shown), TeamSite

communicates with pam to perform account management functions on the
authenticated user. Account management functions include—but are not limited to—
controlling expired passwords and login time restrictions.
3. To configure TeamSite not to perform account management functions, add the
following line to the [authentication] section of iw.cfg:
pam_do_acct_mgmt=no
4. Complete the PAM-specific configuration procedure described in page 70.
Modifying LDAP Schemas to Store TeamSite Roles

If you do not have an existing attribute in your LDAP schema where you can store TeamSite
roles, add a new attribute to your LDAP schema as described in this section. If you already
have an attribute where you can store TeamSite roles, start the procedure with step 3.
1. Add an auxiliary class to an existing object in the schema.
2. Add a new attribute to that object named tsrolesattribute.
3. Edit the [authentication] section of iw.cfg to include:
ldap_roles=tsrolesattribute
4. Your LDAP administrator can now assign TeamSite roles to users configured in your
LDAP server using the server’s administration tools.
69
The following are the valid values (they are case-sensitive):

! master
! admin
! editor
! author

Note:
" TeamSite roles within your LDAP server can be queried and manipulated directly using
your LDAP tool or programmatically using an LDAP server programming interface
supplied by other vendors, not by Interwoven.
" You cannot store TeamSite role information in your LDAP database if you want to use
operating system authentication. If you want to store role information in your LDAP
database, also use LDAP for authentication.
" For detailed instructions for modifying schemas and adding attributes for the Sun ONE
(iPlanet) Directory Server, see Chapter 9 of the Sun ONE Directory Server Administration
Guide (http://docs.sun.com/source/816-6698-10).
Re-Encrypting User Authentication Information

The TeamSite CLT iwsessionkeygen generates the key used to encrypt user authentication
information. Running this command invalidates all current user sessions and generates a
new key. You may want to run iwsessionkeygen periodically to protect system security.
Complete the following procedure to generate a new encryption key for user
authentication information.
1. Log in to TeamSite as root.
2. Have all end users log out of TeamSite.
TeamSite does not allow users to easily resume interrupted sessions. Therefore, you
should not run iwsessionkeygen while end users are working. If you do run
iwsessionkeygen while end users are working, these users may experience a variety of
errors (for example, failure to connect to the TeamSite server or invalid session
strings).
3. Run the iwsessionkeygen CLT.
All users will need to log in again to continue working in any TeamSite interface.
TeamSite and PAM Configuration File Interaction

By default, on TeamSite for Solaris, PAM controls authentication by using entries tagged
with the teamsite service name stored in the /etc/pam.conf file. You can specify that
PAM use /etc/pam.conf entries tagged with something other than teamsite by changing
the pam_service line in the [authentication] section of iw.cfg.

Authentication
For example, to specify that TeamSite instead use the lines in /etc/pam.conf that also
control the telnet program, edit the pam_service line in iw.cfg so that it reads as
follows:
[authentication]
pam_service=telnet
The format of /etc/pam.conf is described in detail in the pam.conf(4) man page. You
should configure TeamSite with its own entries in /etc/pam.conf using the service name
teamsite (or whatever service name you specify for pam_service in iw.cfg). Only the
auth and account modules in /etc/pam.conf are used for TeamSite authentication. If no
entries are present for TeamSite in /etc/pam.conf, PAM uses whatever settings are
specified for the other service. Note that this scenario is not recommended.
On Solaris 2.7 or later, the following lines in /etc/pam.conf produce behavior equivalent
to the traditional TeamSite authentication method:
teamsite auth required /usr/lib/security/pam_unix.so.1
teamsite account required /usr/lib/security/pam_unix.so.1
To use a third-party PAM module, specify its path instead of /usr/lib/security/

pam_unix.so.1. For more information about PAM, see http://www.sun.com/software/
solaris/pam/.
Note: TeamSite is tested with the pam_ldap and pam_unix modules that ship with Solaris
8. No other testing or certification of any vendor's PAM modules is performed. If
you want to use PAM with TeamSite, you should do a proof-of-concept to verify
that the particular PAM module will work satisfactorily with TeamSite in your
environment.
Configuring TeamSite and LDAP to Work Without an Anonymous Bind

In some installations, anonymous binds to LDAP are not permitted for security reasons. If
you cannot use an anonymous bind to LDAP to read user names, you can establish a
dedicated LDAP user account to use for user authentication. All searches for users’
Distinguished Names are done using this account instead of an anonymous bind. For this
mode of operation, you must add two additional parameters to the [authentication]
section of iw.cfg.
[authentication]
ldap_account=DistinguishedName
ldap_pwd=password
where:
" DistinguishedName specifies the Distinguished Name of the LDAP user account to be
used for LDAP searches. Note that this is not a simple account name, but a complete
Distinguished Name (DN) for a user. For example:
ldap_account=cn=TeamSite,cn=Users,ou=myCompany,c=us.
71
" password specifies the clear text password of the LDAP user account that matches
ldap_account.
Note: The user name and password are in clear text, so it is important to limit who has
read permission for iw.cfg. You can change the account name and password at any
time. The changes take effect the next time the server is restarted or reset.
You can explicitly specify domain controller that should be used for a particular domain.
[iwserver]
domain_list=domain1, domain2:domain_controllerA, domain3
In this example, the primary domain controller would be used for first and third domains,
while domain_controllerA would be used for the second domain.
Configuring Submit Filtering

The TeamSite server enables you to automatically change file attributes, including uid, gid,
and permissions, at the time that you submit a file. This functionality enables you to
automate the task of defining the permissions associated with each file stored in TeamSite.
The submit filter performs the specified operation on files immediately before they are
submitted, so that changes are made to the files in the workarea, which are then submitted.
Understanding the submit.cfg File

On startup, the TeamSite server reads a configuration file named submit.cfg in the
iw-home/local/config/ directory (unless the location of this file is otherwise specified in
the [locations] section of iw.cfg). The submit.cfg file contains rules to match file and
workarea patterns to specific actions to perform when files and directories are submitted.
The submit.cfg file uses the following format:
case-sensitive = [yes|no]
rules
{
workarea1_pattern
{
file_pattern1 { action1 action2 ... }
file_pattern2 { action3 action4 ...
...
}
workarea2_pattern
{
...
}
...
}

where:
" The case-sensitive statement specifies whether or not the rules matching should
ignore the case of the path names. If case-sensitive is not specified, the value is assumed
to be yes, so that rules matching does not ignore the case of the path names.
" workarea#_pattern is used to match a workarea to the set of file rules to apply when a
submit is done from that workarea. Each pattern can only be specified once, and the
first match is used. For Solaris, the syntax of the pattern is regex(5) (extended syntax).
For AIX, use the POSIX 1003.2 extended regular expression syntax. For more
information on regular expressions, consult a reference manual such as Mastering Regular
Expressions, by Jeffrey Friedl, or read the man page (Solaris only):
% man -s 5 regex
The match is done against the path name of the workarea, starting with /default/
main.
" file_pattern# is used to match a file or directory to the set of actions to perform on it
when it is submitted. Each file or directory pattern can only be specified once, and the
first match is used. The syntax of the pattern is regex(5) (extended syntax) for Solaris,
or the POSIX 1003.2 extended regular expression syntax for AIX.
The match is done against the path name of the file or directory relative to the
workarea.
" action# is one of:
uid=name
gid=name
perm=octal number
amask=octal number
omask=octal number
expand_rcs_macros=[yes|no] (see page 77)
and specifies the operation to perform on the file or directory being submitted. uid=,
gid=, and perm= specify new values for these attributes. amask= specifies a bit mask to
“and” to the existing mode of the file or directory. omask= specifies a bit mask to “or”
with the existing mode of the file or directory.
Submit Filtering Sequence

When you submit files or directories, the following sequence is initiated:
1. The server determines what files and directories have changed and need to be
submitted. It also verifies that none of them are in conflict with the staging area or
locked in other workareas.
2. The path name of the workarea from which the submit is being done is matched against
the workarea patterns in the submit.cfg file.
3. If the workarea matches one of the workarea patterns, then, for each file and directory
that needs to be submitted (as determined in step 1), the file’s path name is matched
against the file patterns in the matching workarea’s section.
73
4. If a match is found, the server performs the specified set of actions (defined in
submit.cfg) to the file or directory in the workarea.
5. The server submits the transformed files and directories to the staging area.
Sample submit.cfg file

CASE-SENSITIVE = YES
RULES
{
# SECTION 1
^/default/main/WORKAREA/.*$ # any workarea in the main branch
{
^/index\.html$ { gid=test perm=0664 uid=andre }
# attributes fixed for /index.html
.*\.sh$ { omask=0111 } # execute bits on all .sh files
/$ { uid=andre } # andre owns all the directories
.* { amask=0775 } # don't allow world write access
}
# SECTION 2
^/default/main/TeamSite/WORKAREA/chris$ # just for chris
{
^/html/chris/.*$ { uid=chris gid=iw } # under /html/chris/
.* { amask=0775 } # don't allow world write access
}
# SECTION 3
.* # any other workarea on any other branch
{
.* { amask=0775 gid=test } # no world write access
}
}
Note:
" Only the first match is applied. That is, the first match is used if multiple rules match
the file or directory. The submit.cfg file should be ordered so that the most specific
workarea patterns are closer to the top and the most specific file patterns are earlier in
each section. You may need to duplicate some actions for them to apply to multiple
rules.
" For purposes of matching, the path name of a directory must end in a slash (/).
" Single or double quotes around patterns are optional, but they must be used around
workarea and file patterns that contain spaces or the following special characters:
#, {, }, =, or ,.
Backslashes (\) are special characters when used within patterns surrounded by quotes;
a backslash followed by any character is replaced by the single character. For example,
to embed a single quote, double quote, or backslash in a pattern, precede the character
with a backslash (\', \", or \\). Backslashes are not special characters in patterns that
are not quoted.
" Do not specify duplicate workarea patterns multiple times, duplicate file patterns
multiple times within a workarea section, or the same action multiple times within a file
rule.

" Because of client-side attribute caching, the modes, uid, and gid may not reflect the
changes in the workarea immediately after a submit. The correct attributes are displayed
after a sufficient time-out interval (usually about 30 seconds).
" You cannot change the permissions for a symbolic link. The perm, amask, and omask
actions are not performed on a submitted symbolic link. The uid and gid actions are
performed on a submitted link, not on the actual file.
" The permission values must be specified as an octal number (starting with a 0), between
0 and 0777.
" Changes to submit.cfg do not take effect until the server is restarted or until you use
iwreset.
Testing and Debugging Submit Filtering

The iwtestcfg CLT can be used to determine which workarea and file patterns are applied
to a file at the time of submission. For example:
% iwtestcfg /default/main/WORKAREA/andre/cgi/test.sh
would return:
Matched area pattern "^/default/main/WORKAREA/.*$"
Matched file pattern ".*\.sh$"
Actions to do are:
omask=0111
Matched area pattern and Matched file pattern are the case-insensitive regular
expressions found in submit.cfg that match the workarea and file. Actions to do are the
actions (specified in submit.cfg) that will be applied to the file.
Refer to the TeamSite Command-Line Tools manual for more information about this CLT.
You can also get debugging information on the submit handling configuration printed to
iwtrace.log by adding the following line to the [server] section of iw.cfg:
[server]
debug_event_handler=yes
This configures the TeamSite server to print:

" A configuration map of submit.cfg.
" Which actions are performed as files are submitted.
75
RCS Macro Expansion

TeamSite provides RCS-style macro substitution at submit time. These macros enable you to
embed version information into files, including:
" File name
" Revision string
" Last modifier
" Last modified
" Submit comments
To use the macro facility, you must add new rules to the submit.cfg configuration file (see
page 74), then manually insert the macros into files in your workarea. When the files are
submitted, the TeamSite server replaces the macros with the appropriate information, and
rewrites the file in your workarea and the staging area.
Available Macros
The macros are a subset of those used in RCS (called keywords in the RCS documentation).
The following description is taken from the UNIX co(1) man page, modified for TeamSite
semantics.
Strings of the form $keyword$ and $keyword:...$ embedded in the text are replaced with
strings of the form $keyword:value$ where keyword and value are pairs listed below.
Keywords can be embedded in literal strings or comments to identify a revision.
Initially, the user enters strings of the form $keyword$. On submit, the server replaces
these strings with strings of the form $keyword:value$. On subsequent submits, the value
fields will be replaced automatically with updated values.
The following keywords (macros) and their corresponding values are recognized by
TeamSite:
" $Author$—The login name of the user who last modified the file. This is a standard
RCS keyword and does not refer to the TeamSite Author role.
" $Date$—The date and time the file was last modified.
" $Header$—A standard header containing the path name of the file, the revision string,
the date and time, the author. The path is relative to the area root.
" $Id$—Same as $Header$, except that the filename does not include the path.
" $Log$—The comment supplied during submit, preceded by a header containing the
filename, the revision string, the date and time when the file was last modified, and the
author. The comment is either the submit comment supplied for the individual file or, if
this is empty, the comment supplied for the all the files associated with the submit.
Existing log messages are not replaced. Instead, the new log message is inserted after
$Log:...$. This is useful for accumulating a complete change log in a file.

Each inserted line is prefixed by the string that prefixes the $Log$ line. For example, if
the $Log$ line is // $Log:tan.cc $, RCS prefixes each line of the log with //. This is
useful for languages with comments that go to the end of the line. The convention for
other languages is to use a * prefix inside a multiline comment. For example, the initial
log comment of a C program is conventionally of the following form:
/*
* $Log$
*/
" $Revision$—The
revision string.
" $Source$—The pathname of the file, relative to the root directory of the area.
The following RCS keywords (macros) are ignored by TeamSite:
" $Locker$
" $Name$
" $RCSfile$
" $State$
The following characters in keyword values are represented by escape sequences:
Character Escape Sequence

end-of-line \n
$ \044
\ \\
Enabling Macro Expansion

To enable RCS macro expansion for a particular set of files, you must include the following
action in the submit.cfg rules that apply to those files:
expand_rcs_macros=yes
Here is a sample submit.cfg file:
CASE-SENSITIVE = YES
RULES
{
"." # any workarea
{
".*\.[ch]$" { gid=iw, expand_rcs_macros=yes }
# files ending in .c or .h
".*" { gid=iw } # all other files/directories
}
}
77

Chapter 6
Configuring Interwoven Search
The Interwoven Search function allows users to search common document types and data
records from TeamSite. Users can search for text within a file or for values specified by
metadata. Users enter search criteria using the search user interface from ContentCenter;
refer to the online help for details. CLTs are also available for system administrators to
perform queries and to set up index and search functionality; refer to the Command-Line Tools
Reference.
Search Overview
The primary uses for Interwove search are to:
" Find files for viewing, editing, copying, and tagging.
" Find outdated files for removal.
" Find files for reuse.
" Find files for reporting purposes (regulation and auditing compliance).
" Find files for recovery purposes (restore older versions of deleted files).
The Interwoven Search function is made up of two parts—the index manager and the search
manager. The index manager controls the indexing of content. The search manager
performs queries on indices and returns the results to the user. Both the index manager and
the search manager use agents, which are processes that access the search engine for either
indexing or querying documents. The index manager also uses a document cracker that
cracks a file or a data record and provides metadata and full-search content on the
document. TeamSite CLTs are used to issue commands to either the index manager and the
search manager. The ContentCenter interfaces communicate with the search manager to
request searches and to view the search results.
Note: Within files, you may find references to index server or search service or search
server. These terms are used interchangeably with index manager and search
manager.
79
TeamSite
Search Index
Manager Manager
Query Query Index Index Document

Agent Agent Agent ... Agent Cracker
...
Figure 7: High-level design of search system
Working with Branches

TeamSite search is done on a branch basis. This section explains how to index and search on
branches.
Indexing Branches
When a new TeamSite branch is to be indexed, the branch can be indexed in two ways.
" The branch may be specified in the iwsearch_home/etc/branches.cfg file and then
the index manager may be started. The index manager picks up the branch name during
startup time and indexes the branch.
" The branch can be specified in a CLT that specifies to the index manager that the
relevant branch that is to be indexed.
Whenever a branch that is specified to the index manager to be indexed has been
successfully indexed, the index manager creates a collection of data and indices about the
documents in the branch that is optimized for subsequent searching.
In addition to indexing an entire branch, the index manager also has a listener that listens to
any submit event on a previously indexed branch. When a user submits a set of files through
TeamSite, the index manager recognizes that a submission has occurred and instructs the
indexing to occur on that set of files. Indexing can be tuned based on a set of parameters in
the iwsearch_home/etc/search.properties file.
When an index manager is shut down, relevant information about all the branches that it has
indexed is stored in a file. When the index manager subsequently comes back up, it sets the
appropriate context by reading the information from this file.

Configuring the Index and Search Managers
Searching Branches
A ContentCenter user issues a search query. This query is sent to the search server. Results
are returned to the ContentCenter screen, arranged in relevancy order determined by the
search engine.
A CLT can also be used to issue a query. Queries are written in XML format and may be
saved in a file. The name of the file is provided with a CLT flag. Refer to the Command-Line
Tool Reference for details on using CLTs for queries.
Deleting Branches
When a TeamSite branch has to be deleted, you need to issue the appropriate index server
CLTs so that the collections maintained by the index server for that branch are handled
correctly.
To purge the branch’s collection from the index manager and from the disk, issue the
iwndxpurgebr CLT for that branch. Otherwise, issue the iwndxrmbr CLT to remove the
collection from the index manager. Refer to the Command-Line Tools Reference for an
explanation of the differences between the two CLTs.
After issuing one of these CLTs, you can delete the branch from TeamSite. Refer to page 99
for troubleshooting information if collections or branches are not deleted correctly.

The iwsearch-home/etc/search.properties file is used to configure the index manager
and the search server. This file is used to set parameters in the following areas:
" Generic configuration
" Generic agent configuration
" Index manager configuration
" Index agent configuration
" Search manager configuration
" Query agent configuration
" Logging information
This section shows the configuration parameters in each area and describes the information
that can be modified.
Generic Configuration
This section identifies the TeamSite server. It is normally set by the installation program.
However, if your TeamSite server changes, you need to modify this section.
81
######################################################################
# Generic configuration items (common for index server and search)
######################################################################
# TeamSite host
iw.teamsite.server.host=_IW_TS_HOST_NAME_
Generic Agent Configuration

This section specifies the maximum times to wait for agent response and initialization. If
timeouts are occurring because of a loaded system or a slow machine, you may want to
increase these numbers.
When an agent fails to respond to a command from its server, the server automatically
restarts it. However, if the agent has a persistent problem, it can go through rapid restarts,
which can slow the system down. To limit this behavior, you can specify the number of
times the server is allowed to restart its agent within a specific time period. If the restart
limit is exceeded, the server takes the agent out of operation, which is called taking the
agent offline. Once an agent has been taken offline, the only way to start it is to restart the
server.
The iw.agent.windows.systemroot item in this section is used for Windows servers to

identify where the Windows operating system is located. If your Windows operating system
is in a different location, change the value.
The iw.agent.logs.agentlogs.enable item and the iw.agent.logs.toserverlogs

control whether agent logs are logged to separate files or to the logs of the server that
started the agent.
####################################
# Generic agent configuration items
####################################
# The maximum time (ms) to wait for agent response

iw.agent.timeout=1000000
# The maximum time (ms) to wait for agent initialization

iw.agent.init.timeout=20000
# If agent restarts more than iw.agent.restart.limit times during an

# iw.agent.restart.interval (ms), it is taken offline.
iw.agent.restart.limit=2
iw.agent.restart.interval=1000
iw.agent.windows.systemroot=c:\\winnt
# If iw.agent.logs.toserverlogs is true, the agents logs are logged to the

# log file of the server that started them.
iw.agent.logs.toserverlogs=false
# The iw.agent.logs.toserverlogs determines whether agents logs are

# logged to the log file of the server that started them. This property
# determines whether agents logs should go to their separate log files.

# The agent log files are in agentlogs subdir of the log directory and are
# named agent_<agent_pid>.log.
iw.agent.logs.agentlogs.enable=false
Index Manager Configuration

This section is used to configure the index manager.
Change the value for iw.index.server.port to reflect your actual TCP port. This is the
TCP port that the index manager monitors for API requests, such as requests from CLTs
and the user interface.
The three threadpool settings are used to tune the index manager behavior in terms of
processing API requests. You probably do not need to change these values.
You need to specify the value for java.naming.provider.url. Do not change the other
values in the JMS producer details section.
The iw.index.markpartial.duration=24 parameter specifies how old (in hours) an

index can be before it is considered to be a partial (or out-of-date) index. Search compares
the last indexed edition with the current edition; if they are not the same, this value is used
to determine whether the index is partial.
The iw.index.maxbifsize=4000 parameter controls how many files are optimally

submitted to be indexed at a time. Once the value is exceeded, an index job starts. BIF
refers to Bulk Insert File; BIFs are generated per branch so this refers to the optimal number
of changes per branch to be processed at one time.
The session pooling parameters control the number of connections open to TeamSite. The
iw.index.scipool.max parameter specifies the maximum number of connections that can
be opened. The iw.index.scipool.warm parameter specifies the number of connections
that are always open, whether or not they are used. The other two parameters are
placeholders and should not be adjusted.
The iw.index.binaryextension parameter is used to indicate types of files that will not
have the content indexed. For example, graphics files do not have content that can be
indexed. Any metadata set for these files will, however, be indexed. See page 97 for more
details.
The iw.index.maxfilesizetoindex parameter indicates the maximum size of the file in

megabytes that will be indexed by the index manager. If the size of the file is larger than the
value specified by this parameter, then the contents of this file will not be indexed.
The iw.index.events.enable parameter indicates whether the index should be updated

whenever a file is submitted. By default, it is set to true.
You can control the number of times the index manager attempts to listen to the TeamSite
Event Subsystem before giving up using the iw.index.events.listen.attempts
83
parameter. You can also specify the number of seconds the index manager waits between
attempts to listen to the TeamSite Event Subsystem using the
iw.index.events.listen.wait parameter.
When the iw.index.events.enable parameter the setting is set to true, the

iw.index.optimalWaitMins parameter indicates that events should be queued before
being indexed and specifies the number of minutes to wait before starting the index job.
Using this feature allows grouping submits so multiple files are indexed at once. If a lot of
updates are occurring, you may want to set a higher value to get maximum performance;
however, your index may become slightly out-of-date.
######################################################################
# Index server configuration
######################################################################
# Server configuration
iw.index.server.port=_IW_INDEX_PORT_
iw.index.server.threadpool.maxthreads=50
iw.index.server.threadpool.warmthreads=10
iw.index.server.threadpool.keepalivetime=60000
# TeamSite JMS producer side details

java.naming.factory.initial=org.exolab.jms.jndi.mipc.
IpcJndiInitialContextFactory
java.naming.provider.url=tcp://_IW_TS_HOST_NAME_:_IW_EVENT_PORT_/
TopicConnectionFactory=JmsTopicConnectionFactory
iw.index.topic.1=Interwoven
#iw.index.topic.2=TeamSite_System
# How old (hours) the index needs to be (relative to current edition)

# for it to be considered partial
iw.index.markpartial.duration=24
# Max number of files for BIF

iw.index.maxbifsize=4000
# TeamSite session pooling

iw.index.scipool.max=10
iw.index.scipool.warm=1
iw.index.scipool.idleTime=-1
iw.index.scipool.maxLife=-1
# Binary extensions. The content in these files will not be indexed,

although metadata will be.
iw.index.binaryextensions=exe,jpg,gif,psd,tif,tiff,au,wav,bmp,rif
# Maximum size of the file in Mbytes to be indexed.
iw.index.maxfilesizetoindex=20
# Event-based updates are enabled

iw.index.events.enable=true
# Number of times Index server attempts to listen to

# TeamSite event system before giving up

iw.index.events.listen.attempts=10
# Number of seconds Index server waits between attempts to listen to

# TeamSite event system
iw.index.events.listen.wait=12
# Optimal wait time before received events are processed (in minutes)
iw.index.optimalWaitMins=1
# For interwoven only. Do not change this unless interwoven support

# asks you to
iw.index.leave.gen.files=false
Index Agent Configuration

This section is used to configure the index agent. Do not change the first group of
parameters as these are for future enhancements.
The iw.index.agent.mainport parameter specifies the TCP port number on which the
index manager listens to its agent. This connection is used by the index manager to dispatch
commands to its agents. The iw.index.agent.callbackport parameter specifies the TCP
port on which the index manager listens to its agents for a callback connection. The callback
connection is used by the agents to send their log messages to the server.
The iw.index.agent.idxdir parameter sets the directory on the index manager server
that holds the indexes for all branches.
######################################################################
# Index agent configuration
######################################################################
# Number of index agents

iw.index.agent.count=3
# Note: the sum of the number of bulk and incremental threads
# must always be one less than the agent count.
iw.index.bulk.threads=1
iw.index.incremental.threads=1
# Port number on which index server listens for connections from its
agents
iw.index.agent.mainport=_IW_INDEX_AGENT_MAIN_PORT_
# Port number on which index server listens for callbacks from its agents
iw.index.agent.callbackport=_IW_INDEX_AGENT_CALLBACK_PORT_
# Collections directory for index agents

iw.index.agent.idxdir=_IW_INDEX_SHARED_FILESYSTEM_
85
Search Manager Configuration

This section contains parameters that control the search manager.
Change the value for iw.search.server.port to reflect your actual TCP port. This is the
TCP port that the search manager monitors for API requests, such as requests from CLTs
and the user interface.
The search manager uses a pool of worker threads for servicing client requests. Each client
connection, whether from a CLT or the user interface, is served by its own worker thread.
When the search manager starts, it creates threads specified by the value of the
iw.search.server.threadpool.warmthreads parameter. If a new client connection is
made and none of these threads is available to service the connection, a new thread is
created, thus growing the thread pool.
The thread pool growth is capped by the value of the

iw.search.server.threadpool.maxthreads parameter. This value determines the
maximum number of simultaneous client connections that can be serviced by the server.
When a thread has been idle for longer than the millisecond time out specified by the value
of the iw.search.server.threadpool.keepalivetime parameter, it is terminated by
the server to conserve resources. If iw.search.server.threadpool.keepalivetime is set
to a value of -1, the threads are never reclaimed.
When a user issues a query, it is valid for the number of minutes specified by the
iw.search.query.validity.mins parameter. This means the user can use the query ID
issued with each query to scan the results of the query. After the time specified, the query
must be reissued. This parameter is reserved for future enhancements and does not
currently impact queries.
The iw.search.query.maxOpenQueriesPerUser parameter indicates the maximum

number of queries an individual user can have open. If they exceed that number of queries,
the earliest ones are no longer valid, even if the validity time parameter has not been met.
Change the value for the iw.index.server.host parameter if the index manager is on a
different host computer than the search manager.
You can modify the cache configuration. The raw cache contains the results of a query as
they are retrieved. Post-processing filters the results from the raw cache and writes the
results to the processed cache until enough results are found to return the first page of
results. The value for iw.search.cache.raw.validity.mins should be the same as the
value for iw.search.query.validity.mins. The values for
iw.search.cache.raw.entries.capacity and iw.search.cache.raw.entries.grace
are used to control the total number of queries kept in the system and the extra capacity that

can be used when managing the number of queries. For example, the default settings
indicate 100 queries are kept in the system, but that number can go to 110 (10 grace
queries) and then 10 queries would be deleted at one time to return to the 100-query
capacity. This is more efficient than deleting one extra query at a time. The
iw.search.cache.processed.size parameter specifies the size of the processed cache.
The session pooling parameters control the number of connections open to TeamSite. The
iw.search.scipool.max parameter specifies the maximum number of connections that
can be opened. The iw.search.scipool.warm parameter specifies the number of
connections that are open, whether they are used or not. The other two parameters are
placeholders and should not be adjusted. The value for iw.search.scipool.max should be
less than half the value of iw.search.server.threadpool.maxthreads, but should not
generally exceed 25 for the best performance.
The iw.search.tsfilter.optimalBatchSize denotes the number of results from the

raw cache that will be sent to TeamSite at a time to check for permissions, validity, and so
forth, before sending it to the processed cache. You probably do not need to change these
values.
######################################################################
# Search server configuration
######################################################################
iw.search.server.port=_IW_SEARCH_PORT_
iw.search.server.threadpool.maxthreads=50
iw.search.server.threadpool.warmthreads=10
iw.search.server.threadpool.keepalivetime=60000
iw.search.query.validity.mins=240
iw.search.query.maxOpenQueriesPerUser=2
# tweaks how long requests wait for an agent before failing due to
# high system load.
iw.search.query.maxAgentTries=5
iw.search.query.agentRetryTimeoutMillis=2000
# change this if the index server is on a different host than the

# search server
iw.index.server.host=_IW_SEARCH_HOST_
#Cache configuration
#Raw cache
iw.search.cache.raw.entries.capacity=100
iw.search.cache.raw.entries.grace=10
iw.search.cache.raw.validity.mins=240
#Processed cache
iw.search.cache.processed.size=100
87
# TeamSite session pooling. Note that the optimal behavior is to have

# the same max number of connections as there are agents.
iw.search.scipool.max=10
iw.search.scipool.warm=1
iw.search.scipool.idleTime=-1
iw.search.scipool.maxLife=-1
# The number of results sent to TeamSite for filtering at a time

iw.search.tsfilter.optimalBatchSize = 100
Search Agent Configuration

This section is used to configure the search agent. Do not change the first group of
parameters as these are for future enhancements.
The iw.search.agent.mainport parameter specifies the TCP port on which the search
manager listens to its agents. This connection is used by the search manager to dispatch
commands to its agents. The iw.search.agent.callbackport parameter specifies the
TCP port on which the search manager listens to its agents for a callback connection. The
callback connection is used by the agents to send their log messages to the server.
The iw.search.agent.idxdir parameter sets the directory on the search manager that
holds the indexes for all branches.
######################################################################
# Search Agent configuration
######################################################################
iw.search.agent.count=10
# Port number on which search server listens for connections from its
# agents
iw.search.agent.mainport=_IW_SEARCH_AGENT_MAIN_PORT_
# Port number on which search server listens for callbacks from its agents
iw.search.agent.callbackport=_IW_SEARCH_AGENT_CALLBACK_PORT_
# Collections directory for search agents

iw.search.agent.idxdir=_IW_SEARCH_SHARED_FILESYSTEM_
Logging Configuration
The logging configuration refers to both the index manager and the search manager. The
first part of the value for the log4j.logger.com.interwoven parameter specifies the log
level for the server. The set of possible log levels are in increasing order of verbosity are
FATAL, ERROR, WARN, INFO, and DEBUG. Normally, the server should be run with the log
level of INFO. You can control the maximum log file size using
log4j.appender.mainLogger.MaxFileSize and specify the number of archived or
backup log files using log4j.appender.mainLogger.MaxBackupIndex. The other logging
configuration settings should normally not be modified.

Field Mapping Configuration
#######################################################
# Logging configuration
#######################################################
log4j.rootLogger=WARN, stdout
log4j.logger.com.interwoven=INFO, mainLogger
log4j.additivity.com.interwoven=false
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n
# Logger configuration
log4j.appender.mainLogger=org.apache.log4j.RollingFileAppender
log4j.appender.mainLogger.MaxFileSize=1000KB
log4j.appender.mainLogger.MaxBackupIndex=1
log4j.appender.mainLogger.layout=org.apache.log4j.PatternLayout
log4j.appender.mainLogger.layout.ConversionPattern=[%d{DATE}] %p %c (%t)
- %m%n

The field mapping configuration file:
" Defines the extended attributes that will be indexed by the index manager.
" Defines the templating attributes for the specified template type that will be indexed by
the index manager.
The FieldMapping schema (http://www.interwoven.com/products/teamsite/search/

config/FieldMapping.xsd) provides the schema for creating the iwsearch_home/etc/
FieldMapping.xml configuration file.
In addition to these extended and templating attributes that are defined in the field mapping
configuration file, there are a set of attributes and file properties that will always be
indexed. These are defined in an internal standard field mapping configuration file. The
StandardFields schema (http://www.interwoven.com/products/teamsite/search/
config/StandardFields.xsd) defines these fields and they cannot be changed.
In the field mapping configuration file, the globalFields element contains

extendedAttributeFields that contain the fieldSpecification element for each field
that will be indexed.
The templates element contains a template element for each FormsPublisher template
used. The template element includes a templateType element that identifies the
FormsPublisher template (or form). The fields within the form that will be indexed are
identified in the templatingFields element, which contains one or more
templatingField elements. Each templatingField element contains a xpath element
and a fieldSpecification element. The templatingField element defines a mapping
from the xpath of a templating entry to the field definition that is used to store it.
89
A fieldSpecification element has three parts as follows:

" A fieldName element: Any typical name can be chosen for this element. This name is
used for building queries that are submitted to the search manager. This name should be
unique across all fieldName entries in the FieldMapping.xml and
StandardFields.xml files.
" A fieldType element: The possible values are string, int, float, and date.
" An optional formatString element: This element is relevant only if the fieldType
element has a value of date. This element specifies the date-time format for the
relevant EA in one of the JDK-defined standard forms. For example it could be,
yyyy-MM-dd (see “Configuring Date Fields”).
" A fieldStorage element:
! If the fieldType element is a string, then this element needs to be of the form
zone:variable-name. The variable-name specified here should be unique across
all fieldStorage entries in the FieldMapping.xml and StandardFields.xml
files.
! If the fieldType element is an int, float, or date, then the fieldStorage
element should respectively be one of CustomInt1 through CustomInt5,
CustomFloat1 through CustomFloat5, or CustomDate1 through CustomDate5.
This entry should be unique across all fieldStorage entries in the
FieldMapping.xml and StandardFields.xml files.
Note: The fieldName and fieldStorage elements defined in globalFields must be

unique. The fieldName and fieldStorage elements defined for a single template
type may be reused in other template types. This means two different templates
could have fields that share names or storage; however, these cannot conflict with a
global field.
The value for a zone name must be a valid XML name; it cannot have spaces. Names are
character insensitive. They can consist of all alphabetic characters (upper and lower case),
numeric characters, the dash (-), the underscore character (_), or the number sign (#).
Configuring Date Fields

If a custom field is of type date, the formatString corresponding to the field must be
configured in FieldMapping.xml. The formatString tells the index manager how to parse
dates during the indexing process. The index manager and search manager will not start
without formatString for date fields. As shown in this example, the value of
formatString specifies the pattern of the data and time strings.
<fieldSpecification>
<fieldName>TeamSite/Metadata/Launch Date</fieldName>
<fieldType>date</fieldType>
<formatString>yyyy-MM-dd</formatString>
<fieldStorage>CustomDate1</fieldStorage>
</fieldSpecification>

Explanation of pattern letters:
y year
M Month (in numeric form)
d Day in month
a|p AM or PM marker
h Hour
m Minute
The following examples show how Index Manager interprets the date and time patterns.
Pattern Date Interpretation

MM/dd/yyyy 08/30/2004 30 Aug 2004
yyyy-MM-dd hh:mm a 2004-08-30 06:30 AM 30 Aug 2004 06:30 AM
yyyy-MM-dd hh:mm a 2004-08-30 30 Aug 2004 12:00 AM
91
Example of FieldMapping File

The following code is an example of a FieldMapping.xml file. It includes some of the
default FormsPublisher forms that ship with TeamSite. This file is located at
iwsearch-home/etc/FieldMapping.xml.example. If desired, you can use snippets of this
file to create your FieldMapping.xml file.
<?xml version="1.0" encoding="UTF-8"?>

<searchFieldMapping xmlns="http://www.interwoven.com/products/teamsite/
search/config/FieldMapping.xsd" xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance" xsi:schemaLocation="http://www.interwoven.com/
products/teamsite/search/config/FieldMapping.xsd
FieldMapping.xsd">
Schema location <globalFields>

<extendedAttributeFields>
globalFields section
that lists
ExtendedAttributeFields 
that contain one or more <fieldSpecification>
fieldSpecification <fieldName>TeamSite/Metadata/Description</fieldName>
elements
<fieldType>string</fieldType>
<fieldStorage>zone:Description</fieldStorage>
<fieldName>TeamSite/Metadata/Business Unit</fieldName>
<fieldStorage>zone:Business Unit</fieldStorage>


<fieldName>TeamSite/Metadata/Expiration Date</fieldName>
<formatString>yyyy-MM-dd</formatString>
<fieldStorage>CustomDate2</fieldStorage>
</extendedAttributeFields>
</globalFields>
<templates>

<template>
The templates section <templateType>intranet/weather</templateType>
begins by defining
intranet/weather.
<templatingFields>
<templatingField>
<xpath>/Announcement</xpath>
<fieldName>Announcement</fieldName>
<fieldStorage>zone:WeatherAnnouncement</fieldStorage>
</templatingField>
</templatingFields>
</template>

<template>
This section defines <templateType>internet/yacht</templateType>
internet/yacht. <templatingFields>

<templatingField>
<xpath>/General Info/Length</xpath>
<fieldName>YachtLength</fieldName>
<fieldType>int</fieldType>
<fieldStorage>CustomInt1</fieldStorage>
</templatingField>
</templatingFields>
</template>
<template>
Another template <templateType>internet/auction</templateType>
category and type.
It defines
<templatingFields>
internet/auction. 
<templatingField>
<xpath>/Minimum Bid Amount</xpath>
<fieldName>MinBidAmount</fieldName>
<fieldType>float</fieldType>
<fieldStorage>CustomFloat1</fieldStorage>
</templatingField>
</templatingFields>
</template>
<template>

This element defines <templateType>internet/careers</templateType>
internet/careers. <templatingFields>
<templatingField>
<xpath>/Responsibilities List</xpath>
<fieldName>Responsibilities</fieldName>
<fieldStorage>zone:Responsibilities</fieldStorage>
</templatingField>
</templatingFields>
</template>
93
<template>

This section defines
internet/pr. <templateType>internet/pr</templateType>
<templatingFields>
<templatingField>
<xpath>/Story[1]/Section Paragraphs[1]/Paragraphs</xpath>
<fieldName>FirstStoryParagraph</fieldName>
<fieldStorage>zone:FirstStoryParagraph</fieldStorage>
</templatingField>
</templatingFields>
</template>


<template>
This section defines
<templateType>xml/press-release</templateType>
xml/press-release.
<templatingFields>
<templatingField>
<xpath>/press-release/head/byline/@author</xpath>
<fieldName>PR_Author</fieldName>
<fieldStorage>zone:PR_Author</fieldStorage>
</templatingField>
<templatingField>
<xpath>/press-release/body/section/subheading</xpath>
<fieldName>Subheading</fieldName>
<fieldStorage>zone:PR_Subheading</fieldStorage>
</templatingField>
</templatingFields>
</template>
</templates>
</searchFieldMapping>

The standardField.xml File

The standardFields.xml file is based on the standardFields.xsd schema and defines
fields for extendedAttributes and fileAttributes elements. This file cannot be edited.
You cannot redefine the fields in FieldMapping.xml that are defined in
standardFields.xml. The entries in bold in the StandardFields.xml are the relevant
extended attributes and file attributes that a search query may be issued against. The other
entries are indexed but are for Interwoven internal use only.

<standardFields xmlns="http://www.interwoven.com/products/teamsite/
search/config/StandardFields.xsd" xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance" xsi:schemaLocation="http://www.interwoven.com/
products/teamsite/search/config/StandardFields.xsd StandardFields.xsd">
<extendedAttributes>
<field>
<fieldName>TeamSite/Templating/PrimaryDCR</fieldName>
<fieldStorage>zone:IWTemplatingPrimaryDCR</fieldStorage>
</field>
<field>
<fieldName>TeamSite/Templating/PrimaryDocumentType</fieldName>
<fieldStorage>zone:IWTemplatingPrimaryDocuemntType</fieldStorage>
</field>
<field>
<fieldName>TeamSite/Templating/DCR/Type</fieldName>
<fieldStorage>ContentType</fieldStorage>
</field>
</extendedAttributes>
<fileAttributes>
<field>
<fieldName>Creator</fieldName>
<fieldStorage>zone:Creator</fieldStorage>
</field>
<field>
<fieldName>CreateDate</fieldName>
<fieldStorage>CreateDate</fieldStorage>
</field>
<field>
<fieldName>AreaRelativePath</fieldName>
<fieldStorage>AreaRelativePath</fieldStorage>
</field>
<field>
<fieldName>Version</fieldName>
<fieldStorage>Version</fieldStorage>
</field>
95
<field>
<fieldName>BranchId</fieldName>
<fieldType>long</fieldType>
<fieldStorage>BranchId</fieldStorage>
</field>
<field>
<fieldName>OwningAreaId</fieldName>
<fieldType>long</fieldType>
<fieldStorage>OwningAreaId</fieldStorage>
</field>
<field>
<fieldName>LastModifier</fieldName>
<fieldStorage>zone:LastModifier</fieldStorage>
</field>
<field>
<fieldName>LastModifiedDate</fieldName>
<fieldStorage>LastModifiedDate</fieldStorage>
</field>
<field>
<fieldName>Indexed</fieldName>
<fieldStorage>Indexed</fieldStorage>
</field>
<field>
<fieldName>IndexedDate</fieldName>
<fieldStorage>IndexedDate</fieldStorage>
</field>
<field>
<fieldName>Size</fieldName>
<fieldStorage>FileSize</fieldStorage>
</field>

<field>
<fieldName>Title</fieldName>
<fieldStorage>zone:DocMetadataTitle</fieldStorage>
</field>
<field>
<fieldName>Author</fieldName>
<fieldStorage>zone:DocMetadataAuthor</fieldStorage>
</field>
<field>
<fieldName>Keywords</fieldName>
<fieldStorage>zone:DocMetadataKeywords</fieldStorage>
</field>
</fileAttributes>
</standardFields>

Types of Files Being Indexed
Types of Files Being Indexed

Content is extracted only from documents belonging to these general classifications:
" Word processor documents
" Spreadsheet documents
" Presentation documents
Only TeamSite EAs (if there are any) and file properties are extracted from most other
types of documents, such as:
" Raster image documents
" Vector graphic documents
" Executable files
" Encapsulation formats
" Sound file formats
" Planning/outline formats
" Scheduling/planning formats
" Movie files
" Animation files
You can specify other types of files for which content is not extracted using the
iw.index.binaryextensions parameter in the search.properties file (see page 83).
Determining Whether a Document will be Found

Based on how the indexer is implemented, the following summary indicates whether a
document in an area will be “hit” when a search is performed, assuming the index is up-to-
date.
" If the item in the workarea is modified, it is a hit if the most recent checked-in
predecessor matches the search criteria.
" If the item in the workarea is not modified, it is a hit if the item matches the search
criteria.
" When searching the staging area or editions, the hit is dependent only on the version in
the area being searched.
" Modified items in a workarea will never be indexed and will never contribute to
whether the search returns a hit or not.
97
Using CLTs
CLTs have been created to manage the index and search servers. Refer to the Command-Line
Tools Reference for details on usage.
CLT Description
iwsrchgethome Displays the location of the TeamSite Search home directory.
iwndxmgrfreeze Freezes and unfreezes the index manager.
iwndxmgrstatus Determines the current status of the index manager (active or
frozen).
iwndxmgrstop Shuts down the index manager.
iwndxstatus Displays the index status for branches.
iwndxlistbr Lists all the indexed branches.
iwdxpurgebr Removes the index collection associated with the branch.
iwndxaddbr Adds a branch to be indexed by the index manager.
iwndxrmbr Removes a branch so it is no longer indexed by the index manager.
iwndxfreezebr Freezes or unfreezes a branch that is being indexed by the index
manager.
iwndxrefreshbr Reindex the branch using either the bulk or incremental queue.
iwndxregsrchsvr Register a search server with the index manager.
iwsrchndxstatus Displays the index status for branches from the search server.
iwsrchquery Returns the first page of the query output in XML format.
iwsrchgetpage Displays a page of results from a previously performed query.
iwsrchmgrstop Shuts down the search server.
iwsrchmgrping Pings the search server.
iwsrchndxstatuschg Notifies the search server of changes in the index manager status.
iwsrchattrib Displays a list of field specifications for indexed attributes.

Troubleshooting
Troubleshooting
The following topics provide additional information you may need regarding index and
search functionality.
Deleted Edition
If you delete the initial edition of a branch or the last indexed edition of a branch, indexing
of further assets on the branch cannot be done. You may obtain the last indexed edition of a
branch by using one of the Index Manager CLTs that provides the detailed branch status.
If you delete the last edition of a branch before the index server has started indexing it, you
need to create a new edition; doing so ensures that the indexing of assets on the branch
work when the index server starts indexing it.
Using the CustomDate Extended Attribute

When attempting to search on the CustomDate extended attribute, a document may not be
found. This problem occurs when the date format specified in FieldMapping.xml is not
consistent with the format in which the EA is stored in TeamSite. The
fieldSpecification element in FieldMapping.xml may contain an optional
formatString element that can specify the date format. If this specified format is consistent
with the way the EA is stored in TeamSite, the indexing and searching should work fine. If
no formatString element is specified in the fieldSpecification element in
FieldMapping.xml, then the default format of dd-MMM-yyyy hh:mm a is used.
Deleted Branches
If a TeamSite branch was deleted without issuing the iwndxpurgebr CLT or the iwndxrmbr
CLT on that branch (see page 81), perform the following steps to clean the state of the
index server and search server for that branch:
1. Issue the iwndxstatus -a CLT to list information about all the branches the index
server knows about, including the deleted branch. From this list find the vpath of the
deleted branch exactly as it appears.
2. To purge the collection for the deleted branch from disk, issue the iwndxpurgebr CLT
and provide the branch vpath exactly as it appeared in the iwndxstatus output. Alter-
nately, issue the iwndxrmbr CLT and provide the branch vpath exactly as it appeared in
the iwndxstatus output.
These CLTs may issue an error message indicating that the specified branch does not
exist in TeamSite, but they will clean the state of the index server.
Changes to Content Store IDs

If a store ID changes because a Content Store is deactivated and activated (using the
iwstoreadm CLT), the search indexes for all branches in that store need to be purged. Then
the branch indexes should be rebuilt.
99
Bringing Down Servers

If the index manager and search manager are restarted or brought down, you need to keep
them synchronized. If the index manager is brought down or restarted, restart the search
manager after restarting the index manager. If the search manager is brought down or
restarted, it is not necessary to restart the index manager.
Running on Different Hosts

If the index manager and search manager are running on different hosts, they may not be
able to access the other’s resources. To work around this:
1. Always run search manager and index manager under the same account.
2. If the search manager is on a different host than Teamsite, the account must belong to
the Teamsite domain group and must also be a privileged user on the search host.
3. Change the iw.search.agent.idxdir parameter in the search.properties file to
use the UNC path (for example, \\newlywed\Search\Index).
4. The index directory must be shared with full permissions given to the same account.
Error Messages
This section provides index manager and server manager error codes.
Index Manager Error Codes

Error Number Error Message
10000 The relevant branch br-vpath does not exist.
10001 The relevant branch br-vpath has not been indexed.
10002 The collection for branch br-vpath could not be purged
10003 Incorrect parameters were supplied to the command.
10004 Unknown command [command-name].
10005 The branch br-vpath cannot be refreshed because it is frozen.
10006 The branch br-vpath either does not exist or has not been indexed.
-1 Unknown

Troubleshooting
Search Manager Error Codes

Error Number Error Message
20000 Generic query processing exception.
20001 Query is malformed.
20002 The query specified with id=query-id does not exist in the system.
20003 The query cannot be issued because the relevant branches were
unindexed.
20004 A very high load on the system prevents the query from being processed.
20005 Incorrect parameters were supplied to the command.
20006 Unknown command [command-name].
20007 The search manager is unable to contact the index manager.
20008 The branch br-vpath does not exist.
20009 One or more of the areas specified in area-list do not exist.
20010 The user userid does not exist in the system.
20011 The number of query results returned on each page is specified
incorrectly.
20012 The index of the first query result to be returned cannot be less than zero.
-1 Unknown
101

Chapter 7
Configuring Metadata Capture
TeamSite metadata capture enables TeamSite users to add metadata information to files.
Metadata is a structured way to describe data in your files allowing you to organize and
manage it.
The ContentCenter Standard and ContentCenter Professional interfaces include a default

data capture form known as the Tagger GUI.
Introducing the Tagger GUI

TeamSite uses the following default ContentCenter form, known as the Tagger GUI. This
form, with two tabs, enables your TeamSite end-users (using either ContentCenter
Standard or ContentCenter Professional) to add metadata information to the content files
they create or edit.
103
Figure 8: Tagger GUI screens
End users can access information describing a field by clicking on the question mark next to
the field name.
In addition to the convenience of having a default metadata capture form, the form is easy to
modify to reflect the categorization of metadata in your organization.
Metadata Capture Overview

Metadata capture is a file-specific feature. That is, you must explicitly select the files on
which you intend to set metadata. You cannot globally set metadata for an entire area or
branch. For example, to set metadata on all files in a workarea, you must select each file in
that workarea (by clicking Select All or by clicking the checkbox next to each file) and then
initiate a metadata capture session. See the online help for more information.
Metadata capture can be initiated in the following ways:

" From the Tag menu item in ContentCenter.
" Submitting a file that is part of a Solutions workflow (as described in the Workflow
Developer’s Guide).
" Clicking the Tag link any time you view a file’s properties or differences. These links
might be deactivated (grayed out) depending on access controls including user role and
file ownership.
" Clicking More > Tag in the VisualPreview screen.
" Importing a file into TeamSite.
" Through a job as part of a <cgitask> element (as described in “Initiating Metadata
Capture from a Job Specification File” on page 121)

Metadata Capture Overview
Metadata Capture Components

Regardless of how metadata capture is initiated, it uses the following components:
" datacapture.cfg—Configuration file that defines rule sets for capturing data. By
default, it is located in the iw-home/local/config directory.
" metadata-rules.cfg—Configuration file that maps vpaths to the data capture rules
defined in datacapture.cfg. By default, it is located in the iw-home/local/config
directory.
" iwmetadata.cgi—Metadata capture CGI that interprets data from end-users and rules
in datacapture.cfg and metadata-rules.cfg, produces browser graphics and
prompts, and acts as an interface with workflow configuration files (if metadata capture
is running as part of a job).
" Tagger GUI—Browser-based form for end-user input.
" Metadata capture subsystem (part of the TeamSite Content Server) processes the data
entered in the Tagger GUI and stores it in the TeamSite Content Store as extended
attributes.
The two configuration files (metadata-rules.cfg and datacapture.cfg) enable you to

configure the following on a per-user or per-vpath basis:
" The metadata item name that displays in the metadata entry form.
" The interface element through which the end-user enters input (for example, a
checkbox or a data field).
" The type of data that is acceptable or unacceptable in any given field.
" Whether input is required for any given field.
The following diagram shows how these components work together. Sections following the
diagram explain each diagram step and component in detail.
105
metadata-rules.cfg datacapture.cfg
References Defines rule sets for
datacapture.cfg capturing data
Maps vpaths to rule sets
(Server Side) (Server Side)
2 2
5 5
Browser iwmetadata.cgi
1 (1)
Job Specification
" Reads configuration File
Displays Tagger files
GUI metadata " Generates forms Can run metadata
entry form 3 " Checks validity of end- capture using
user data via rule sets <cgitask> element
" Follows rules to add
metadata to specific files
(Client Side) 4 " Signals successor
tasks (WF only)
(7) (Server Side)
iw-store
Files saved with new

metadata
Figure 9: Metadata Capture components
Diagram Key
1. The metadata CGI receives a list containing the names of the files that can have metadata
added to them. The list can come from an instantiated job (if metadata capture is
initiated from a job) or from the browser (if initiated from a TeamSite user interface).
2. The metadata CGI reads both configuration files (metadata-rules.cfg and
datacapture.cfg) to determine what information it should display in the Tagger GUI.
It makes this determination on a per-file basis, so that the entry form can contain
different prompts and actions for different files.
3. The metadata CGI displays the Tagger GUI on the client system.
4. An end-user enters and submits the data using the metadata entry form and the
metadata CGI.
5. The metadata CGI consults the rules in both configuration files to verify the validity of
the data entered by the user. If the data does not meet all necessary criteria, notification
is sent to the user so that data can be re-entered.

6. If the data meets all necessary criteria, the metadata CGI adds the new metadata (in the
form of TeamSite extended attributes) to the specified files. The metadata CGI
interfaces directly with the Content Store to update the files with the new metadata.
7. If metadata capture was initiated from a job, the metadata CGI notifies the workflow
subsystem, which starts successor task 0 (zero) as defined in the job specification file.
Metadata Capture and Extended Attributes

When end-users set metadata on files (that is, tag them), the metadata is added to files as
TeamSite extended attributes and stored in the TeamSite Content Store. The metadata can
be viewed in the following ways:
" By displaying the Tagger GUI for a file by clicking:
! File > Tag in the file browser screen for any file managed in TeamSite.
! The Tag link when viewing a file’s properties or differences.
! More > Tag in the VisualPreview screen.
The metadata that has been set for a file populates the same fields in the Tagger GUI in
which it was originally entered.
" Using the iwextattr CLT as described in the TeamSite Command-Line Tools manual. You
can use this CLT to get a specific value, or all a list of all the attributes for the file.
You can deploy these extended attributes to a database using Interwoven DataDeploy. The
deployment can be manual, or automatic using Database Auto-Synchronization (DAS). See
the DataDeploy Administration Guide for more information.

You must perform two main activities to configure metadata capture:
" Create a metadata-rules.cfg file in iw-home/local/config for your site.
" Create a datacapture.cfg file in iw-home/local/config for your site.
The following sections describe these steps in detail.
The metadata-rules.cfg File

The metadata-rules.cfg file maps vpaths to data capture rules that are defined in
datacapture.cfg. The metadata-rules.cfg file consists of a series of <cond>
(conditional) elements. A <cond> element can contain <rule> elements and other <cond>
elements. Each vpath is run through metadata-rules.cfg, resulting in a one-to-many
mapping from vpaths to named rules. Whenever a list of <cond> elements is found, the first
to match the current vpath takes effect, and the rest of the elements in the list are discarded.
The TeamSite installation program installs the metadata-rules.cfg in the iw-home/

local/config/ directory. The metadata-rules.cfg file uses the following DTD:
107
<!ELEMENT metadata-rules (cond)*>

<!ELEMENT cond (cond|rule)*>
<!ATTLIST cond
vpath-regex CDATA #REQUIRED
>
<!ELEMENT rule EMPTY>
<!ATTLIST rule
name CDATA #REQUIRED
>
The contents of the metadata-rules.cfg file are as follows:
<?xml version="1.0" encoding="UTF-8" ?> International Encoding
<metadata-rules>
<cond vpath-regex="."> Vpath Identifier
<rule name="Default Rule" /> Rule Identifier
</cond>
</metadata-rules>
Notes:
" International Encoding—UTF-8 is an encoding of Unicode, a standard for encoding the

character sets of international languages. All of your content should specify their
encoding as UTF-8. For details about encoding, see Appendix D, “Internationalization.”
" Vpath Identifier—Names the vpath (in this case, all directories) to which the rules
named in the following subelements are applied.
" Rule Identifier—Names the rule that applies to the preceding vpath. The rule itself is
defined in the <ruleset> element in iw-home/local/config/datacapture.cfg. In
this example, the Default Rule rule defined in datacapture.cfg always applies to all
directories.
The following metadata-rules.cfg file illustrates a more sophisticated example:

<metadata-rules>
<cond vpath-regex="^/default/main/syndication"> Vpath Identifier1
<rule name="Default" /> Rule Identifiers2
<rule name="Syndication" />
<cond vpath-regex="\.pdf$"> Vpath Identifier3
<rule name="PDF Files" /> Rule Identifier4
</cond>
<cond vpath-regex="\.doc$"> Vpath Identifier5
<rule name="MS Word Files" /> Rule Identifier6
</cond>
</cond>
<cond vpath-regex="^/default/main/www"> Vpath Identifier7

<rule name="Default" /> Rule Identifiers8
<rule name="Web Content" />
<cond vpath-regex="\.html$"> Vpath Identifier9
<rule name="HTML Files" /> Rule Identifier10
<cond vpath-regex="/pr/"> Vpath Identifier11
<rule name="PR" /> Rule Identifier12
</cond>
<cond vpath-regex="/corp/"> Vpath Identifier13
<rule name="Corporate" /> Rule Identifier14
</cond>
</cond>
</cond>
</metadata-rules>
Notes:
" Vpath Identifier1—Files on the/syndication branch always receive the rules named in
the following subelements.
" Rule Identifier2—The Default and Syndication rules defined in datacapture.cfg
always apply to the /main/syndication branch.
" Vpath Identifier3—Files ending in .pdf on the /main/syndication branch receive
rules in addition to those defined by Default and Syndication.
" Rule Identifier4—The PDF Files rule defined in datacapture.cfg applies to files
ending in .pdf on the /main/syndication branch.
" Vpath Identifier5—Files ending in .doc on the /main/syndication branch receive
rules in addition to those defined by Default and Syndication.
" Rule Identifier6—The MS Word Files rule defined in datacapture.cfg applies to
files ending in .doc on the /main/syndication branch.
" Vpath Identifier7—The /main/www branch always receives the rules named in the
following subelements.
" Rule Identifier8—The Default and Web Content rules defined in datacapture.cfg
apply to the /main/www branch.
109
" Vpath Identifier9—Files ending in .html on the /main/www branch receive rules in
addition to those defined by Default and Web Content.
" Rule Identifies10—The HTML Files rule defined in datacapture.cfg apply to files
ending in .html on the /main/www branch.
" Vpath Identifier11—Files ending in .html in the pr directory on the /main/www branch
receive rules in addition to those defined by Default and Web Content.
" Rule Identifies12—The PR rule defined in datacapture.cfg applies to files ending in
.html in the pr directory on the /main/www branch.
" Vpath Identifier13—Files ending in .html in the corp directory on the /main/www
branch receive rules in addition to those defined by Default and Web Content.
" Rule Identifiers14—The Corporate rule defined in datacapture.cfg applies to files
ending in .html in the corp directory on the /main/www branch.
Creating the datacapture.cfg File

The datacapture.cfg file defines rule sets for capturing data. Rules are referred to by
name in metadata-rules.cfg (see “The metadata-rules.cfg File” on page 107).
Rules contain items, where each item is a single set of data that is to be captured from the
end-user. An item consists of one or more instances. Each instance encapsulates how to
capture the data for the item, and each instance defines an ACL that determines which (if
any) instance a particular user is allowed to use to enter the data.
The metadata capture form is a data capture template (DCT) that is configured specifically
for metadata capture. The data capture subsystem that generates the metadata capture form
is the same subsystem that generates data capture templates for FormsPublisher. A major
difference between the two implementations is the location of the datacapture.cfg file.
FormsPublisher relies on multiple datacapture.cfg files (one for each data type), while
metadata capture relies on a single datacapture.cfg file (in iw-home/local/config).
See “Setting Up Data Capture Templates” in the FormsPublisher Developer’s Guide for a
complete explanation of datacapture.cfg files, including annotated examples and
explanations of elements and attributes. Even though the examples in the
FormsPublisher Developer’s Guide are specific to FormsPublisher, they are a useful reference for
configuring datacapture.cfg for metadata capture.
The TeamSite installation program installs a sample file called datacapture.cfg.example

in the iw-home/local/config/ directory.You can copy, rename, and edit the example file
to create your actual datacapture.cfg file. Use the following DTD and annotated
examples as a reference to create your own site-specific configuration.
The datacapture.cfg file uses the following DTD (it is also installed by the TeamSite
installation program in iw-home/local/config/). The datacapture.cfg files must have
been created using metadatacapture6.0.dtd.




<!ENTITY % data-capture-requirements-contentspec "(ruleset+)*">
<!ENTITY % items "container|view-container|view|item">
<!ENTITY % chooser-options "option|inline">
<!ELEMENT data-capture-requirements
(%data-capture-requirements-contentspec;)>
<!ATTLIST data-capture-requirements
name CDATA #IMPLIED
type (metadata) #REQUIRED
dtd-system-identifier CDATA #IMPLIED
>

<!ELEMENT ruleset (label?, description?, (%items;)*)>

<!ATTLIST ruleset
>
<!ELEMENT container (label?, description?, (%items;)*)>

<!ATTLIST container
>
<!ELEMENT item (label?, description?, database?, (checkbox | radio | text

| textarea | select | replicant | browser | readonly | hidden)+)>
<!ATTLIST item
>
<!ELEMENT label (#PCDATA)>
<!ELEMENT description (#PCDATA)>
<!ELEMENT text (allowed?,cgi-callout?,default?) >

<!ATTLIST text
required (t | f) "f"
maxlength CDATA "0"
size CDATA "0"
validation-regex CDATA #IMPLIED
>

<!ELEMENT textarea (allowed?,cgi-callout?,default?) >

<!ATTLIST textarea
rows CDATA "0"
cols CDATA "0"
wrap (off | virtual | physical) "off"
validation-regex CDATA #IMPLIED
>

111
<!ELEMENT browser (allowed?,cgi-callout?)>

<!ATTLIST browser
initial-dir CDATA #IMPLIED
extns CDATA #IMPLIED
>
<!ELEMENT readonly (allowed?,cgi-callout?)>
<!ELEMENT hidden (allowed?,cgi-callout?)>

<!ATTLIST hidden
>
<!ELEMENT checkbox (allowed?, cgi-callout?, (%chooser-options;)+)>

<!ATTLIST checkbox
>
<!ELEMENT radio (allowed?, cgi-callout?, (%chooser-options;)+)>

<!ATTLIST radio
>
<!ELEMENT select (allowed?, cgi-callout?, (%chooser-options;)+)>

<!ATTLIST select
size CDATA "0"
multiple (t | f) "f"
>
<!ELEMENT option EMPTY>

<!ATTLIST option
selected (t | f) "f"
value CDATA #IMPLIED
label CDATA #REQUIRED
>
<!ELEMENT replicant (allowed?, (%items;)*)>

<!ATTLIST replicant
min CDATA "0"
max CDATA "1"
default CDATA "1"
>
<!ELEMENT allowed (cred | and | or | not)>
<!ELEMENT cred EMPTY>

<!ATTLIST cred
role CDATA #IMPLIED
user CDATA #IMPLIED
>
<!ELEMENT and ((cred | and | or | not)+)>

<!ELEMENT or ((cred | and | or | not)+)>
<!ELEMENT not (cred | and | or | not)>
<!ELEMENT default (#PCDATA)>


<!ELEMENT cgi-callout EMPTY>
<!ATTLIST cgi-callout
label CDATA #REQUIRED
url CDATA #REQUIRED
window-features CDATA #IMPLIED
>
<!ELEMENT database EMPTY>

<!ATTLIST database
deploy-column (t | f) "t"
searchable (t | f) "t"
data-type CDATA "VARCHAR(255)"
data-format CDATA #IMPLIED
>

<!ELEMENT inline EMPTY>
<!ATTLIST inline
command CDATA #REQUIRED
>
113
The contents of the datacapture.cfg.example are as follows; the section immediately

following the file explains the callouts.
International Encoding
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE data-capture-requirements SYSTEM "metadatacapture6.0.dtd">

<data-capture-requirements type="metadata"> Metadata Identifier

<ruleset name="Default Rule"> Rule Identifier
<description>
This rule applies to all files on all branches.
</description>
<view-container name="Asset metadata"> View-container Element
<view name="Description"> View Element

<description>
Metadata that describes the topic of the asset.
</description>
<item name="Title">
<database data-type="VARCHAR(100)" /> Database Element
<text required="f" size="32" maxlength="60" />
</item> Instance (text)
<item name="Keywords">
<description>
Keywords can include terms that are not in the asset itself.
</description>
<database data-type="VARCHAR(100)" />
<text required="f" size="32" maxlength="60" />
</item>

<item name="Description">
<description> Description Element
A brief summary of 250 characters or less.
</description>
<textarea required="f" rows="5" cols="72" wrap="virtual"
maxlength="250" />
</item>
</view>
<view name="Details"> View Element

<description>
Metadata that records attributes of the asset.
</description>
<item name="Business Unit">
<description>
Unit that is responsible for the asset.
</description>
<select>
<option label="Administration" value="Admin" />
<option label="Facilities" value="Facilities" />
<option label="Finance" value="Finance" />
<option label="Human Resources" value="HR" />
<option label="Legal" value="Marketing" />
<option label="Marketing" value="Legal" />
<option label="Sales" value="Sales" />
<option label="Systems" value="Systems" />
</select>
</item>
<item name="Creation Date">

<description>
The date the asset was created, in the YYYY-MM-DD format.
</description>
<database data-type="DATE" data-format="yyyy-MM-dd" />
<text required="f" maxlength="10" size="32" validation-regex=
"^[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]$">
</text>
</item>
<item name="Expiration Date">

<description>
The date the asset should be retired, in the YYYY-MM-DD
format. DATE element
</description>
<database data-type="DATE" data-format="yyyy-MM-dd" />
<text required="f" maxlength="10" size="32" validation-regex=
"^[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]$">
</text> validation-regex
</item>
</view>
</view-container>
</ruleset>
</data-capture-requirements>
115
Notes:
" International Encoding—UTF-8 is an encoding of Unicode, a standard for encoding the

character sets of international languages. All web assets should specify their encoding as
UTF-8. For details about encoding, see Appendix D, “Internationalization.”
" Metadata Identifier—When configuring datacapture.cfg for metadata capture, you
must specify "type=metadata" in the <data-capture-requirements> element as
shown here.
" Rule Identifier—The <ruleset> element contains all of the items that make up the rule
set defining the appearance and behavior of the data capture form. A datacapture.cfg
file that is configured for metadata capture can contain any number of <ruleset>
elements (as opposed to FormsPublisher datacapture.cfg files, which can contain just
one <ruleset> element). This example file happens to contain just one <ruleset>
element; it could contain more if necessary. The rule defined here is named Default
Rule and is referenced by the metadata-rules.cfg file shown on page 107. The name
attribute is required and its value appears in the TeamSite user interfaces as the name of
the data capture form. More than one form can be displayed on a single page. Optional
subelements include <label>, <description>, <item>, and <itemref>. The <label>
subelement is used to provide a label on the data capture form. The <itemref>
subelement requires the name attribute and is used as a stand-in for the <item>
subelement in a <symbol-table> element.
" View-container Element—The <view-container> element specifies that the form has
multiple screens that are accessed by selecting the tabs at the top of the form.
" View Element—The <view> element encloses the fields that are on each screen of the
form. It also provides the text on the tabs. In this form, there are two screens: the first
is named Description and contains the Title, Keyword, and Description fields, and
the second is named Details and contains the Business Unit, Creation Date, and
Expiration Date fields.
" database Element—The optional <database> element facilitates the use of the
appropriate data type in DataDeploy and is used only for generation of the mdc_dd.cfg
file. It does not control any aspects of the metadata capture form. The <data-type>
and <searchable> information in the <database> element are passed on to
mdc_dd.cfg, which in turn uses that information to control how metadata is deployed
to a database by DAS. The <database> element has four attributes. Because attribute
order in XML documents is important; these attributes should occur in the following
order:
! deploy-column can be either "t" (true, the default) or "f" (false) and determines
whether or not data entered for the item is deployed to a database column.
! searchable can be either "t" (default) or "f" and determines whether or not users
can search against this item.
! data-type is required and is any JDBC database type. If you do not set the
data-type attribute, a default datatype of VARCHAR (255) is set in mdc_dd.cfg.

! data-format describes the format if date or time is specified for the data-type
attribute (see the DATE datatype description that follows). If a value for data-
format is specified, the instance should contain a validation regex to force a valid
entry in the field (see the validation-regex description that follows).
In this example, deploy-column would be the first attribute if it were set. Seeing as it is
not, all input for this item is deployed to a database column. Next, the searchable
attribute is specified as "t"; however, because this is the default value for the
attribute, searchable does not need to be included. Following searchable is
data-type, here specifying the input to be stored as a string. If date or time is set as the
value for the data-type, a data-format attribute should end the element.
" Instance (text)—The optional <text> element controls the length of text entry fields in
metadata capture and search forms. It also controls whether an end-user is required to
enter text in a field. If the datatype is date or time and a format has been specified, it is
best to include a validation-regex to force users to input data in the correct format
(see the validation-regex description that follows). In this example the user is
required enter a string between one and 60 characters in the text field. The data entered
for this item is stored in the database as VARCHAR and is searchable.
" Description—The <description> element is used to provide the information that
displays when a user clicks on the question mark next to a field on a form.
" DATE datatype—If the datatype is set to date or time, you should specify a
data-format and include a validation. Because there are many formats for date and
time, specifying a format forces the user to enter data in that format and reduces the
chance of user error. The value for data-format can be any valid Java format for a date
or time.
" validation-regex—The user can be forced to enter a date or time in the format you
specify by including a validation regex. The value for the validation-regex attribute
must match the format specified in for data-format. The regex in this example
specifies the range of digits that can be entered for yyyy-mm-dd and that dashes must
separate year, month and day. The following table shows validation regex examples for
several supported datatypes.
117
The <database> and <text> elements shown in the table are subelements of the
<item> element. Some regex lines are wrapped due to page constraints. You should
enter them all on one line in your configuration file.
Datatype Description and Example

DATE If data-type is DATE, the data-format must be a format string that is valid
for the Java simple date format class. Formats do not have to be year-
month-day, any valid format will work.
<database data-type="DATE" data- format="yyyy-mm-dd" />
<text maxlength="10"
validation-regex="^[0-9][0-9][0-9][0-9]-[0-1] [0-9]-[0-3]
[0-9]$" />
INT Allows any integer up to 7 digits. This example assumes that you want to
store data as integers, not dollars and cents.
<database data-type="INT" />
<text maxlength="7"
validation-regex="^[0-9]\{0,\}$" />
REAL Allows any decimal up to 8 digits (including decimal). The regex allows 0
or more digits, followed by a decimal point, followed by zero or more
digits.
<database data-type="REAL" />
<text required="t" maxlength="8"
validation-regex="^[0-9]\{0,\}\.[0-9]\{0,\}$" />
If users encounter an error with the Tagger GUI, an error message tells them to contact
their system administrator. The system administrator should check the servletd log file for
more information on the configuration problem.
Modifying the Tagger GUI

You may wish to use the data capture form provided with the TeamSite installation but you
need other fields or additional fields for the Business Unit drop-down list. Open the
datacapture.cfg file and find the section identifying the Business Unit item. The name
shown in quotation marks following label= is the name that displays in the Business Unit
list. The name shown following value= is the value stored in the TeamSite Content Store as
an extended attribute. Simply change these values or add additional <option> elements to
modify this section of the form.

Modifying the Tagger GUI
<item name">
<description>Unit that is responsible for the asset.</description>
<select>
<option label="Administration" value="Admin" />
<option label="Facilities" value="Facilities" />
<option label="Finance" value="Finance" />
<option label="Human Resources" value="HR" />
<option label="Legal" value="Marketing" />
<option label="Marketing" value="Legal" />
<option label="Sales" value="Sales" />
<option label="Systems" value="Systems" />
</select>
</item>
You could also modify the item names or view names to modify these forms for your use.
For more extensive form design, refer to the FormsPublisher Developer’s Guide for guidance.
Localizing the Tagger GUI

To display a localized version of the Tagger GUI (when applicable), perform the following
steps:
1. In the iw-home/local/config directory, locate the following Tagger GUI
configuration files for localization:
! datacapture.cfg.example.de (German)
! datacapture.cfg.example.ja (Japanese)
! datacapture.cfg.example.ko (Korean)
! datacapture.cfg.example.zh (Simplified Chinese)
2. Depending on the localized system, rename the appropriate file to datacapture.cfg.
The localized version of the Tagger GUI will be enabled.
Using the datacapture.cfg.example2 File

The TeamSite Installation program also installs another example data capture file that can be
used if it better fits the needs of your organization. The file is called
datacapture.cfg.example2 and is installed in the iw-home/local/config directory. The
data capture form generated by this file is as follows:
119
Figure 10: Alternate Tagger GUI form
To replace the default datacapture.cfg file with the datacapture.cfg.example2,

complete the following procedure:
1. Go to the iw-home/local/config directory.

2. Rename (or move) the datacapture.cfg file, for example rename it
original_datacapture.cfg. Even if you choose to move the file, it is a good idea to
rename it to avoid possible confusion.
3. Rename the datacapture.cfg.example2 file to datacapture.cfg.
Metadata Capture and TeamSite Workflow

The following sections describe key interactions between metadata capture and TeamSite
workflow.
Specifying Files in Workflow Tasks

Metadata capture includes the ability to self-filter a list of files on which to capture
metadata. For example, a user task or a job task can name a set of files upon which metadata
will be set. All symlinks, directories, and deleted files that are part of the file set will be
filtered out and ignored. Only actual files will have metadata set.

Metadata Capture and TeamSite Workflow
Initiating Metadata Capture from a Job Specification File

The following sample <cgitask> section from a job specification file shows the syntax
necessary to initiate a typical metadata capture process from within a job. The task owner in
this example is jk. The task in this example is associated with the area shown in areavpath.
See the TeamSite Workflow Developer’s Guide for information about the <cgitask> DTD and
other general information.
<cgitask name="metadata" owner="jk">
<description>apply metadata.</description>
<areavpath v="/default/main/test/WORKAREA/jk" immediate="+"/>
<successors>
successorset description="set">
<succ v="confirm" />
</successorset>
</successors>
<command v="iwmetadata.cgi" />
<activation>
<or>
<pred v="start" />
</or>
</activation>
</cgitask>
121

Chapter 8
Configuring the TeamSite Web

Daemon and Proxy Server
The following sections describe the configuration settings for the TeamSite web daemon and
the TeamSite proxy server. They begin with an overview of each of these features, and then
are followed by sections on specific configuration settings.
About the TeamSite Web Daemon

TeamSite uses a web daemon, iwwebd, to provide SSL support for the TeamSite browser
GUI. Remote contributors can use TeamSite securely without having to establish a Virtual
Private Network (VPN). The iwwebd web daemon also serves the non-servlet-based parts
of the TeamSite GUI. For an illustration of how requests are processed, see “The TeamSite
Intelligent File System (IFS) is composed of the TeamSite Content Server and kernel, the
TeamSite Content Store of files and metadata, a suite of command-line tools, TeamSite
CGI, proxy servers for access through the TeamSite browser-based user interfaces
(ContentCenter), and file system mounts for access through the file system interface.” on
page 19.
Note: The log directory must be on a lockable file system, typically local.
About the Proxy Server

TeamSite uses a proxy server to perform the following functions:
" Resolve relative and absolute URL names in TeamSite areas in order to present users
with a virtualized view of the Web site contained within an area (see page 125).
" Redirect fully qualified URLs into TeamSite areas (see page 128).
" Redirect browsing in one branch or workarea into another area (see page 131).
" Redirect individual workareas to use different Web servers (see page 133).
" Remap links to external Web servers (see page 133).
" Modify Host: headers (see page 135).
" Remap SSI requests (see page 136).
Each time a request is made through the TeamSite proxy server, the following sections of
iw.cfg are processed as shown in the following graphic. More than one rule may be applied
to a request. As a URL gets rewritten by a rule, the rewritten URL is passed to the next
123
Configuring the TeamSite Web Daemon and Proxy Server
section. The first rule that matches in any section prevails; no other rules in that section are
applied.
See Configuring TeamSite to Redirect

iwproxy_fullproxy_redirect
Fully Qualified Paths. Applies only if
the browser’s proxy has been set to
iwproxy_remap
the TeamSite proxy server.
See Document Roots.
iwproxy_external_remap See Configuring External Remappings.
Applies only if none of the
preceding rules has matched.
iwproxy_preconnect_redirect
iwproxy_preconnect_remap See Redirecting TeamSite Views to
Different Areas.
iwproxy_hostheader_remap
See Host Header Remappings.
iwproxy_smartcontextedit_allowed See Enabling and Disabling

VisualPreview.
No
Can the rewritten path iwproxy_failover_remap
be found? See Configuring Proxy Failover.
Yes Sends the rewritten path to be
reprocessed.
The specified page is returned.
Applying Changes to Proxy Configuration

If you change any of the iwproxy mappings in iw.cfg, you must use the iwreset -a CLT
to ensure that TeamSite recognizes the changes.
Note: iwreset -a does not apply changes to the [iwproxy_remap] or
[iwproxy_plugin_remap] sections of iw.cfg if you are using Web server
plug-ins. If you make changes to these sections and you are using Web server
plug-ins, you must restart the Web server to apply the changes.

Configuring TeamSite Web Daemon and Proxy Server Operation

The [iwproxy] section of iw.cfg is used to configure the operation of the TeamSite proxy
server. By default, your [iwproxy] section reads as follows:
[iwproxy]
customer_webserver_host=hostname or IP_address
iwproxy_host=proxy_hostname
iwproxy_port=1080
customer_webserver_port=81
where:
" customer_webserver_host is the host name of the content Web server. The value
must be set to the host name of the Web server that serves the content of your Web
sites.
" iwproxy_host specifies the host where the TeamSite proxy daemon runs. Usually this is
the TeamSite server.
" iwproxy_port is the port on which the TeamSite proxy server operates. It should be set
to an open port value.
" customer_webserver_port is the port through which the TeamSite proxy server
communicates with the Web server. It must be set to the value of the port used by the
Web server.
The settings in the [iwproxy] section are set during the TeamSite installation. They can be
manually edited if necessary.
Resolving Relative and Absolute Paths

Relative paths specify file locations relative to the referencing file’s directory location.
Absolute paths specify file locations relative to the Web site’s document root directory.
For example, the file whose directory path (rooted in a TeamSite area) is
/main/index.html might contain a link to the file /images/banner.gif. This link can be
specified as either a relative or an absolute path as follows:
" As a relative path:
../images/banner.gif
" As an absolute path:
/images/banner.gif
Note: The proxy server does not allow you to remap the document root directory for
Content Store branches other than the default Content Store.
Links in HTML documents are often specified with relative or absolute path names. For
example, in a link to an image, the file name might appear as:
/images/miles.gif
125
On a typical Web server, this link reference would be mapped by the Web server to its
document root, for example:
/images/miles.gif /usr/httpd/images/miles.gif
All users that attempt to access the file using the absolute path name are mapped to the same
file location on the Web server.
However, TeamSite supports a system of private workareas, giving each user access to the
Web site’s files from within their own personal, virtual version of the Web site. TeamSite
uses a proxy server to manage mapping of files to workareas with relative and absolute path
references. Using the previous example, the TeamSite proxy server enables all users
attempting to access /images/miles.gif from within TeamSite to be mapped to the copy
of miles.gif in their own workareas. The redirected mapping would look like:
/images/pic.gif /iw-mount/default/main/branchpath/WORKAREA/workarea
name/images/miles.gif
Document Roots
TeamSite maps the initial Web server directory structure (the document root) of workareas to
the top level of the workarea directory by default. You may, however, want to move the
document root, or group types of files together for improved clarity, convenience, or
efficiency. On a branch-by-branch basis, the TeamSite proxy server allows you to remap the
document root anywhere within the workarea directory. It also allows you to define
mappings directly to subdirectories within workareas.
Note: The proxy server does not allow you to remap the document root directory for
Content Store branches other than the default Content Store.
Document roots are defined in the [iwproxy_remap] section of iw.cfg. The default
setting is as follows:
[iwproxy_remap]
global_default_map=/
Note that iw.cfg also contains a section called [global_default_map]. There must be a
corresponding section for each parameter defined in the [iwproxy_remap] section.
To configure document roots for individual branches:
1. For each branch that you want to configure, add a line to the [iwproxy_remap] section
of iw.cfg as follows:
[iwproxy_remap]
configSectionName=vpath
where configSectionName is the name of the section of the configuration file that
defines the branch remappings, and vpath is the vpath to the branch you are
configuring.

2. For each line that you added to [iwproxy_remap] section, create a section in iw.cfg
named [configSectionName].
3. Add a line to this new section that defines the document root:
_docroot=dirpath
where dirpath is a directory path rooted in a workarea.

You can also add lines that bypass the document root, as follows:
path=path
For example, if you added the following lines to [iwproxy_remap]:
[iwproxy_remap]
branchrewrite_1=/main
branchrewrite_2=/main/training
The first line of tells TeamSite to use the section [branchrewrite_1] to set the document
root configuration for the /main branch. The second line tells TeamSite to use the
[branchrewrite_2] section to set the document root configuration for the
/main/training branch.
You would then create two new sections in iw.cfg corresponding to the lines in
[iwproxy_remap]:
[branchrewrite_1]
_docroot=/htdocs
/pictures/=/pictures/
/html/=/html/
[branchrewrite_2]
_docroot=/htdocs
/images/=/images/
Note that the first line of both the new sections contains _docroot=/htdocs. This defines a
special directive that sets the mapping of the document root. Any requests from workareas
on the main branch or the main/training branch to the root level directory (/) now start
at:
.../workareaname/htdocs/
Thus, the request for file /miles.gif will now be mapped to:
.../workareaname/htdocs/miles.gif
newly defined docroot file
The two docroot configuration sections also contain lines similar to the following:
/pictures/=/pictures/
127
This line maps file requests directly to the listed directory /pictures/, bypassing the
document root defined in the first line. Thus, a request for the file /pictures/mingus.gif
gets mapped to:
.../workareaname/pictures/mingus.gif
not:
.../workareaname/htdocs/pictures/mingus.gif
The TeamSite proxy server operates using literal string matches and substitutions in path
names. To avoid inadvertently rewriting names, always use trailing slashes in your remap
definitions.
Note: Do not use trailing slashes in your remap definitions for _docroot directories.
Resolving Fully Qualified URLs

TeamSite’s proxy server can also be configured to resolve fully qualified paths. For example,
a link to the main page of a Web site might appear as: http://www.name.com.
If such a link appears in an HTML file in a TeamSite workarea, and you follow that link
while performing in-context QA, you will be taken out of the workarea and to the actual
referenced Web site.
Therefore, if you use fully qualified URLs to reference pages within your own Web site,
clicking on these links will take you out of the in-context view of the current workarea,
staging area, or edition and into your own currently deployed Web site. To solve this
problem, TeamSite enables you to configure your proxy server to redirect fully qualified
links within your Web site, then pass them to the regular proxy server to ensure the
integrity of the in-context view in a workarea, staging area, or edition.
Note: Only configure this setting if your Web site uses fully qualified URLs that you need
to view in-context. This setting requires you to manually configure your browser,
so that you cannot view the actual Web site without reconfiguring your browser.
This also slows the TeamSite server by sending every request through iwwebd and
iwproxy.
Redirecting Fully Qualified URLs

There are two major steps you must complete to configure TeamSite to redirect fully
qualified URLs:
" Configure your proxy server by editing the [iwproxy_fullproxy_redirect] section
of iw.cfg.
" Configure your Web browser’s proxy to use the TeamSite Web daemon (iwwebd).
These procedures are described in detail in the next two sections.

Redirecting Fully Qualified URLs
Configuring the Proxy Server to Redirect Fully Qualified URLs

This feature allows fully qualified URLs in a Web page to be redirected back into workarea-
virtualized paths if users set their browser’s proxy to iwproxy. This feature must be
specifically enabled (enabled=yes) to prevent it from being abused. If you enable this
feature, be sure you understand the security implications and properly secure the HTTP and
HTTPS ports of your TeamSite server using a firewall and VPN where needed.
Edit the [iwproxy_fullproxy_redirect] section of iw.cfg. to include any number of

_regex lines as follows:
_regex=source_regex=dest_ex
where source_regex is a case-insensitive regular expression specifying a fully qualified

URL that might appear in a page, and dest_ex is an expression specifying the path that the
link will be redirected to. This expression should always be the path to the file specified in
source_regex, but rooted in a TeamSite area. For example:
[iwproxy_fullproxy_redirect]
enabled=yes
_regex=http://www(\.example\.com)?/(.*)=/$2
enables the feature and redirects links that specify http://www.example.com in the URL
and sends them to the corresponding location in the current TeamSite area.
Note: If your iw.cfg file’s [iwwebd] section defines the host as host=hostname.domain,
and your browser's proxy server is set to hostname.domain:port, when you start
TeamSite, you must enter http://hostname.domain/iw/ in your browser rather
than http://hostname/iw/.
Continue the configuration by completing the procedures described in the next sections.
The TeamSite web daemon can be used as a proxy server to connect to any outside address
and access content. You can create a regex in the [iwproxy_fullproxy_redirect]
section of iw.cfg to disable this functionality. Refer to the
[iwproxy_fullproxy_redirect] section of iw.cfg.example for details.
Configuring your Web browsers to Use the TeamSite Web Daemon

You must modify your Web browser to use the TeamSite proxy server as described in either
of the next browser-specific sections (each section also contains instructions for
reconfiguring the browser to not use the proxy server).
Internet Explorer
1. In Internet Explorer, select Tools > Internet Options.

The Internet Options window displays.
2. Select the Connections tab.
129
3. Click LAN Settings.

The Local Area Network (LAN) Settings window displays.
Figure 11: Local Area Network settings dialog box
4. Click the Use a proxy server check box.

5. Type the name of your TeamSite server (for example, teamsite1.example.com) in the
Address section.
6. Type the http-port specified in the [iwwebd] section of iw.cfg (for example, 80) in
the Port section.
7. Click OK.
To configure Internet Explorer to not use the TeamSite proxy server:

1. In Internet Explorer, select Tools > Internet Options.
The Internet Options window displays.
2. Select the Connections tab.
3. Click LAN Settings.
The Local Area Network (LAN) Settings window displays.
4. Either:
! Clear the Use a proxy server check box, and click OK.
! Click Advanced. The Proxy Settings window displays. Continue with step 5.
5. In the Exceptions field, enter the URLs that you want to access without using the proxy
server.
6. Click OK.

Redirecting TeamSite Views to Different Areas
Redirecting TeamSite Views to Different Areas

TeamSite’s proxy server enables web teams to work on branches of development that are
populated only with the portion of the content that they are developing, but still maintain a
full in-context view of the entire content collection by referencing the staging area or a
known edition on another branch of development.
This feature is very flexible in that it can be configured on a per-branch or per-workarea

basis, and the redirected view can be configured to take the user to any TeamSite area on
any branch. Redirection can occur in one of two ways:
" Through [iwproxy_preconnect_remap], which retains your original area as the

current working area and directs files there from another area. In this scenario, docroot
is based on the original area’s parent branch.
" Through [iwproxy_preconnect_redirect], which causes the area you redirect into
to become the current working area (and that area’s parent branch becomes the basis of
docroot).
Using iwproxy_preconnect_remap
To configure TeamSite to redirect workarea views and retain your original area as the
current working area (as described in the first bullet), edit the
[iwproxy_preconnect_remap] section of iw.cfg as follows:
[iwproxy_preconnect_remap]
where source_regex is a case-insensitive regular expression describing the area to be

mapped from, and dest_ex is an expression describing the area to be mapped to. These
areas are most commonly workareas or staging areas, but you can map to and from any
workarea, staging area, or edition. You can add any number of _regex lines to this section.
For example:
_regex=(.*)/branch1/WORKAREA/[^/]+/products/(.*)=$1/branch2/
STAGING/products/$2
tells the proxy server to remap the products directory of any workarea on any branch
named branch1 to the products directory of the staging area on its sister branch, branch2.
In the source regular expression, (.*) is used to specify an arbitrary path, and $1 in the
destination expression means that it must follow the same path (and therefore branch1 can
be anywhere in the branch structure, but branch2 is a sister branch of branch1). Also in the
source regular expression, [^/]+ is used to specify a single directory level, of any name
(which in this case would be the workarea name, and therefore all workareas on branch1
are specified). Finally, the source regular expression uses (.*) to specify another arbitrary
path, and $2 in the destination expression tells it to follow the same path.
131
You can also specify the exact location of the areas you want to remap:
_regex=^/
iw-mount/default/main/branch1/WORKAREA/[^/]+/products/(.*)=/
iw-mount/default/main/branch2/STAGING/products/$1
Or, you can specify an individual workarea to remap:
_regex=^/
iw-mount/default/main/dev/branch1/WORKAREA/andre/coolstuff/(.*)=/
iw-mount/default/main/branch2/STAGING/coolstuff/$1
The TeamSite proxy server applies the first match it finds, so you can exclude a particular
area from a more general rule by creating a separate rule for that area and placing it before
the more general rule. For example:
_regex=(.*)/branch1/WORKAREA/chris/products/(.*)=$1/branch1/
STAGING/products/$2
_regex=(.*)/branch1/WORKAREA/[^/]+/products/(.*)=$1/branch2/
STAGING/products/$2
remaps the products directory in all workareas on branch1 except for Chris’s to the
staging area of branch2.
See “Configuring Proxy Failover” on page 136 for more details about configuration rule
precedence.
Using iwproxy_preconnect_redirect
To configure TeamSite to redirect workarea views and cause the area you redirect into to
become the current working area (as described in the second bullet on page 131), edit the
[iwproxy_preconnect_redirect] section of iw.cfg:
[iwproxy_preconnect_redirect]
where source_regex and dest_ex are as described in “Using iwproxy_preconnect_remap”

on page 134. If you set [iwproxy_preconnect_redirect] and then click on a link defined
by an absolute path name, the docroot of that link is based on the branch you redirected
into (as opposed to the branch of the area you redirected from, which would be the behavior
if you had set [iwproxy_preconnect_remap]). See “Configuring Proxy Failover” on
page 136 for a details about configuration rule precedence.

Configuring TeamSite to Use Different Web Servers
Configuring TeamSite to Use Different Web Servers

You can configure TeamSite to use different Web servers for different workareas or different
types of content. For example, Andre might want to make all under-development CGIs in
his workarea on branch1 be served by test1.example.com:1234. This would let Andre
test different Web server configurations for his CGIs on branch1 without disturbing anyone
else.
To configure TeamSite to use different Web servers, edit the

[iwproxy_preconnect_remap] section of iw.cfg:
where source_regex is a case-insensitive regular expression describing the area and files to
be served by the other Web server, and dest_ex is an expression describing the area and
files on the other Web server. This expression must include the port number.
For this to work properly, the other Web server must have the appropriate NFS TeamSite
directory mounts and privileges. The Web server alias used by httpd on port 1234 of
test1.example.com must be configured with the TeamSite alias as well (/iw-mount/).
The following example would allow Andre to test all CGIs in his workarea on
test1.example.com, as previously described:
_regex=^/iw-mount/default/main/branch1/WORKAREA/andre/(.*)\.cgi
(\?.*)?$=http://test1.example.com:1234/iw-mount/default/main/branch1/
WORKAREA/andre/$1.cgi$2
Configuring External Remappings

The TeamSite proxy server enables you to define mappings to directories outside of the
TeamSite system or on different computers altogether. You can define these mappings using
either of the following methods:
" [iwproxy_preconnect_remap]
" [iwproxy_external_remap]
If you use [iwproxy_preconnect_remap], the mappings follow normal

[iwproxy_preconnect_remap] precedence rules. However,
[iwproxy_external_remap] mappings apply only if no other remapping rule has been
applied.
133
Using iwproxy_preconnect_remap
To configure TeamSite to redirect workarea views to external Web servers, edit the
[iwproxy_preconnect_remap] section of iw.cfg as follows:

mapped from, and dest_ex is an expression describing the area to be mapped to. These
areas are most commonly workareas or staging areas, but you can map to and from any
workarea, staging area, or edition. For example:
_regex=(.*)/branch1/WORKAREA/[^/]+/logos/(.*)=http://corporateidserver
.example.com/logos/$2
sends all requests for files in the /logos directory in all workareas on branch1 to another
server, corporateidserver.example.com.
Using iwproxy_external_remap
You can also use [iwproxy_external_remap] rules for external remappings, although
[iwproxy_preconnect_remap] is the preferred methodology.
For example, if all your corporate logo files reside on a separate server, you can use
[iwproxy_external_remap] to create a mapping to the directory where they reside:
[iwproxy_external_remap]
/logos/=http://corporateidserver.example.com/logos/
This remapping sends all requests for /logos/ to a directory on another server,
corporateidserver.example.com/logos/. You can also create associations using
case-insensitive regular expression mapping.
The [iwproxy_external_remap] section is read after the [iwproxy_remap] section, and

is only applied if none of the [iwproxy_remap] rules were invoked. For example, if you
create a mapping for /logos/ in one of the [branchrewrite] sections, all requests on that
branch for files in the /logos/ directory will use that mapping instead of the external
mapping. Requests on other branches will still be sent to the corporateidserver.

Host Header Remappings
Host Header Remappings

If your Web server manipulates Host: headers (for example, virtual domains), you can
configure TeamSite to replicate that behavior. To configure Host: header remapping, edit
the [iwproxy_hostheader_remap] section of iw.cfg.
[iwproxy_hostheader_remap]

mapped from, and dest_ex is an expression describing the new Host: header. For
example:
_regex=^/iw-mount/default/main/branch1/WORKAREA/.*=example.com:1234
will change the Host: header that the source server gets from the TeamSite proxy server to
read:
Host: example.com:1234
whenever content in a workarea on branch1 is accessed.
Enabling iwproxy Access Control

By default, iwproxy allows any authenticated TeamSite user to view any file in TeamSite. To
configure iwproxy to verify the users’ ability to read certain files in the file system, add an
[iwproxy_access_control_enabled] section to your iw.cfg file based on the example that
follows.
This example implements the following policy:
" All users should be able to read any document on the intranet, except for files in the
/hr/ directory, which require specific read access.
" All users should be able to read any document on the internet site.
" For all other branches, iwproxy should check to ensure the current user has read access.
[iwproxy_access_control_enabled]
_default=yes
_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/)]+)|STAGING)/hr/=yes
_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/]+)|STAGING)/=no
_regex=^/iw-mount/dc/main/www%20external/(((WORKAREA|EDITION)/[^/]+)|STAGING)/=no
135
Configuring SSI Remapping

The TeamSite Web server plug-in supports the ability to both remap and virtualize SSI
requests. To enable SSI request virtualization, you must install the necessary redirector
module (iwproxy_nsapi.solaris.so) in addition to the Web server plug-in.
After installing the necessary redirector module as described on as described in the TeamSite
Installation Guide, you can configure TeamSite to remap SSI requests by adding or modifying
the [iwproxy_plugin_remap] section of iw.cfg. In the following example, any SSI
request containing the string /forms/ is mapped to
/iw-mount/default/main/Branch2/STAGING/forms instead of being referred to the root
of the user’s workarea:
[iwproxy_plugin_remap]
_regex=(.*)/forms/(.*)=/iw-mount/default/main/Branch2/STAGING/forms/$2
If you want to debug regular expressions, set the value for _debug in the
[iwproxy_plugin_remap] section to true. On NES and Apache, debugging information is
stored in the Web server error log file. This log file can grow extremely large over time.
Configuring Proxy Failover

If a requested page does not exist, the [iwproxy_failover_remap] section of iw.cfg can
be used to specify an alternate location. This section enables you to specify both alternate
locations and the number of times to process an URL in an attempt to find a valid location.
The figure below illustrates the process by which proxy failover remaps URLs.

Configuring Proxy Failover
The proxy server rewrites the URL according to

rules specified in iwproxy_fullproxy_redirect,
iwproxy_remap, iwproxy_external_remap
iwproxy_preconnect_redirect
Can the rewritten Yes

path be found?
No
iwproxy_preconnect_remap
iwproxy_hostheader_remap
iwproxy_smartcontextedit_allowed
Can the rewritten No iwproxy_failover_remap

path be found? remaps the rewritten URL and
Has maxfail been increments maxfail.
reached?
Yes
The specified page is returned, if found.

If it is not found, the proxy server returns a
File not found message.
Figure 12: Proxy failover remap diagram
The [iwproxy_failover_remap] section has the following structure:
[iwproxy_failover_remap]
_maxfail=#
To specify the number of times to try to remap a URL, edit the _maxfail line of the
[iwproxy_failover_remap] section of iw.cfg. The default value of this line is
_maxfail=0, which turns off proxy failover. Note that proxy failover is seldom needed
because files are almost always in locations that can be specified using static, case-insensitive
regular expressions during configuration. If you need to enable proxy failover, it is
137
recommended that you do not set _maxfail to more than 1 or 2 due to the impact on
system performance.
To specify expressions to remap, add _regex lines to [iwproxy_failover_remap]. These

lines specify an incoming pattern to match, and an expression that they should be mapped
to. The proxy server will take the first match it finds, remap it as specified, then try to
locate the page. If it cannot find the new location, it will try to match the remapped
expression to a regular expression specified in [iwproxy_failover_remap]. This process
will continue until a match is found or the number of iterations specified by the _maxfail
line is reached.
_regex lines in the [iwproxy_failover_remap] section follow the same syntax as _regex
lines specified in the [iwproxy_preconnect_remap] section of iw.cfg, where
source_regex is a case-insensitive regular expression describing the area to be mapped
from, and dest_ex is an expression describing the area to be mapped to. For examples of
_regex syntax, see “Resolving Relative and Absolute Paths” on page 125.
Debugging Your Proxy Server Configuration

If your proxy server does not seem to be configured correctly, use the iwproxy CLT’s debug
option to list all the translations being made by the proxy server:
iwproxy [-d|-x]
-d Debug mode (outputs client & server headers)

-x Extended (verbose) debug mode (outputs client body text as well)
iwproxy returns debug output which you can redirect to a file. Note that the iwproxy
debug mode is single-threaded; it therefore slows the TeamSite server down significantly.
Use the debug mode for diagnostic purposes only.
One common source of proxy configuration problems is the inclusion of any character or
blank space past the end of a branch name in any line in any [iwproxy*] section in iw.cfg.
For example, the following line in the [iwproxy_remap] section is illegal because it
contains blank spaces and characters after the branch name:
[iwproxy-remap]
tag_engspecs=/main/engspecs #This is the engineering spec site
Note: iwproxy needs to run as root.

Chapter 9
Backing Up TeamSite
Your TeamSite Content Stores represent a tremendous investment in resources and are a
valuable corporate asset. As such, they should be backed up daily, or even more frequently,
to minimize the possibility of damaged or lost data. Any third-party backup solution that can
guarantee exact time and state directory content recovery can be used.
Integrating with Third-Party Backup Solutions

Interwoven recommends using a high-quality third-party backup solution for protecting the
Content Store data. When evaluating a backup solution, the following criteria are essential:
" The backup method must provide a way to perform an iwfreeze operation prior to
performing the backup. This must be done to assure that the Content Store does not
change during the backup. The backup method must then perform an iwfreeze --
operation to allow writes to the Content Store when the backup is finished.
" The backup method must be fast enough to perform a full or incremental backup of the
Content Store within a reasonable length of time. The maximum allowable length of
time depends on the requirements of the particular installation, but should probably be
less than 12 hours.
" The restore method must provide a way to do a complete state-restore of a directory as
of a given time. This means that when a directory is recovered, the contents must match
exactly what was in the directory at the time the backup was performed. Only files that
were present at the time of the backup must be present in the restore. That is, if a file
was deleted from the original directory between backups, it should not be present in
the restore. Some backup and restore products regard all backed-up files to be “sticky,”
that is, as long as a file ever existed, it is present in the restoration regardless of whether
it was deleted prior to the last backup.
Additional criteria to consider are:

" An automated backup execution facility capable of performing full backups followed by
level (preferred) or incremental backups to provide a customizable backup strategy.
" Automated backup media management and manipulation (for example, a tape jukebox
or silo).
" The ability to make copies of completed backups for off-site storage.
If the available backup method is efficient and inexpensive (compared to the value of the
data being protected), the TeamSite workareas can also be backed up to allow users to
139
Backing Up TeamSite
recover individual files or directories from their workareas, rather than having to recover
the entire Content Store. This is a very convenient feature for users, but can come at a
relatively high price in terms of extra time and space needed for these redundant backups.
Although the virtual files which comprise much of TeamSite’s file system mount (/iwmnt)
take up no extra space on the TeamSite server, if the actual TeamSite workareas are backed
up, the virtual files in the workareas will be treated as actual files and will take up space in
the backup media.
You must freeze the TeamSite Content Store (with the iwfreeze command) while you are
backing up your Content Stores or workareas. Failure to freeze the Content Store while you
are backing up can result in possible data loss and corruption. For details about the
iwfreeze CLT, refer to the Command-Line Tools manual for your platform.
Note: If you are using multiple Content Stores, you can back up each store independently.
The iw-store directory should be backed up if you have in-progress workflows or
batch jobs that you do not want to lose. You can freeze and unfreeze the workflow
store just like any other store, but you cannot move it outside of iw-store.
Backing up workareas alone is not a substitute for backing up the TeamSite Content Store. If
you only back up the files that appear in the TeamSite file system mount, you will lose
important metadata such as version histories and file status. Always back up the actual
TeamSite Content Store whether or not you back up individual workareas.

Suggested Strategies for Incremental Backups
Suggested Strategies for Incremental Backups

It is possible to implement a “level-oriented” backup if a sufficiently sophisticated backup
solution is available. For example, a full backup can be performed on the first Saturday of
the month, then incremental backups that build on each other can be performed for the rest
of the week. On the second Saturday of the month, a “super-incremental” backup based on
the original full backup done on the first Saturday is performed. The super-incremental
backup supersedes all of the previous incremental backups. Only the first full backup and
super-incremental are needed to completely recover the Content Store. For the subsequent
week, incremental backups are again performed based on the super-incremental backup
done on the second Saturday. The following Saturday, another super-incremental backup
based on the previous super-incremental file is performed, again eliminating the need for
the previous week’s incrementals to recreate the Content Store. To perform a recovery at
this point, restore the original full backup, then each super-incremental in sequence, and
finally the balance (if any) of the current week’s incrementals.
This tiered, or level-oriented backup can be repeated on a monthly basis to produce a

week-by-week record of the Content Store. To reproduce the Content Store as of any
particular Saturday, recover the full backup from the beginning of the month, then apply
each Saturday backup in turn until the desired Saturday is reached.
To determine your optimal backup strategy, you must analyze the trade-offs of convenience
and speed in backing up versus simplicity and speed of restoration, and decide what best
suits your needs. A strategy using a single full backup and an indefinite string of
incrementals is optimized for backup speed, but the amount of time required to perform a
full recover of the Content Store grows with each passing day as a new incremental is added
to the list. Every backup must be preserved to be able to recover the Content Store. One
benefit of this method is that a complete daily record of the Content Store will be
preserved.
The opposite extreme is to perform a full backup every day. Each backup will take the
maximum amount of time to perform, but only one recover needs to be done to completely
recreate the Content Store. If you only preserve the previous day’s backup, no history of the
Content Store will be retained, but the amount of storage space used by the backups is
minimized.
141
Backing Up TeamSite

Appendix A
TeamSite Configuration File Reference
The following files contain information about your TeamSite server configuration:
Table 4: Functions of Configuration Files
Configuration File Function
/etc/defaultiwhome Describes the location of the TeamSite
application software. The default
location is /usr/iw-home.
/etc/defaultiwstore Describes the location of the TeamSite
Content Store directory. The default
location is /usr/iw-store.
/etc/defaultiwmount Describes the location of the TeamSite
virtual mount point. The default
location is /iwmnt.
/etc/defaultiwlog Describes the location of the
iwserver.log file. The default
location is /var/adm/iwserver.log.
/etc/defaultiwelog Describes the location of the
iwevents.log file. The default
location is /var/adm/iwevents.log.
/etc/defaultiwtrace Describes the location of the
iwtrace.log file. The default
location is /var/adm/iwtrace.log.
iw-home/etc/iw.cfg (default location—see Contains various parameters necessary
“Location of iw.cfg” on page 144 for more for the operation of TeamSite, as
information) described in the Chapter 3,
“Configuring the TeamSite Server.”
iw-home/iw-samba/lib/iw.smb.conf Contains Samba configuration.
iw-home/local/config/submit.cfg Specifies all file permissions that are
automatically changed at submit time.
iw-home/local/config/autoprivate.cfg Specifies what types of files are
automatically marked private.
143
Table 4: Functions of Configuration Files (Continued)

Configuration File Function
iw-home/local/config/file_encoding.cfg Contains rules that determine the
character encoding of the contents of
files that do not specify their
encoding. See page 161 for
information about creating these
rules.
iw-home/local/config/templates.cfg Specifies the forms that are used in
which TeamSite areas and how the
forms map to presentation templates
as well as setting form display options.
iw-home/conf/roles/master.uid Contains a list of all users who can log
in as a Master user.
iw-home/conf/roles/admin.uid Contains a list of all users who can log
in as an Administrator.
iw-home/conf/roles/editor.uid Contains a list of all users who can log
in as an Editor.
iw-home/conf/roles/author.uid Contains a list of all users who can log
in as an Author.
iw-home/conf/tsgroups.xml Contains information on TeamSite
groups.
iwsearch-home/etc/search.properties Configures the index server and
search server.
iwsearch_home/etc/branches.cfg Lists the branches to be indexed by the
index server.
iwsearch_home/etc/FieldMapping.xml Defines extended attributes and
templating attributes to be indexed.
iw-home/tsreport/conf/tsreport.xml Configures the EAs to be used by
TeamSite reporting.
The locations of many of these files can be changed (see See “File Locations” on page 49).
Location of iw.cfg
If iw.cfg does not exist in the default location, TeamSite looks for it in the following
locations, in the following order:
" /etc/iw.cfg
" iw-home/config/iw.cfg
" iw-home/local/etc/iw.cfg
" iw-home/etc/iw.cfg

Location of Roles Files
If iw.cfg is not found in any of these places, TeamSite assumes the default values for
iw.cfg settings.
Location of Roles Files

TeamSite looks for the roles files (author.uid, editor.uid, admin.uid, master.uid) in
the following locations, in the following order:
" The value in the iwroles field in the [locations] section of iw.cfg
" iw-home/conf/roles
" iw-home/local/config/roles
" iw-home/config/roles
" iw-home/local/config/roles
145

Appendix B
Configuring Reporting
TeamSite Reporting integrates with Crystal Enterprises to allow you to run standard
reports and to create additional reports. When TeamSite Reporting is installed, users of
ContentCenter Professional have a Reporting tab that provides access to available reports
and displays the results of requested reports.
Installing TeamSite Reporting

The TeamSite Reporting module is an add-on module that is available for TeamSite. It has a
separate installation program and requires a license key. You can install Reporting during the
TeamSite installation or add it to an existing TeamSite 6.5 installation. The installer module
for TeamSite Reporting does the following:
" Sets up the database schema.
" Sets up the UI configuration file.
" Configures the TeamSite Reporting Server.
Refer to the TeamSite Installation Guide for details on installing TeamSite Reporting.
Reporting Overview
TeamSite Reporting obtains information from the Event Subsystem (page 33). Information
is stored in a relational database and can be read by Crystal Enterprises software to obtain
reporting information.
147
Event
subsystem
TeamSite
Report
Module
RDBMS TSReport
or
flat file
Reporting
Messaging RDBMS
UI
library
Event
Proxy Crystal
Enterprises
Figure 13: Reporting System Overview
The reporting service infrastructure consists of the following modules:

" A new messaging library. This library is used by the TeamSite server to publish events.
" A new proxy service that subscribes to the messages published by TeamSite and
publishes them to the Interwoven Event Subsystem. The proxy service referred to here
is not related to iwproxy in any way.
" Interwoven Event Subsystem.
" A report module that subscribes to the Interwoven Event Subsystem for Teamsite events
and archives the data into a reporting database.
" The Reporting UI that queries Crystal Enterprise and displays Crystal Enterprise
reports.
The new messaging library provides TeamSite with a reliable method of publishing events.
This library exports a write/read interface, which can be used by event publishers and
subscribers. The TeamSite server uses the message library to write events and the new
proxy service reads such events and propagates them to the Interwoven Event Subsystem.
The Teamsite report server subscribes to events published by the TeamSite core server
engine, the workflow engine, and the templating engine. On receiving events from the
Interwoven Event Subsystem, the report server archives these events into the reporting
database. In some cases, the report server will query the engine that generated the event
for additional information. Some examples of this are:
" Query the core server for all files submitted as part of a submit event.
" Query the workflow engine for all files associated with a task.

Reporting Configuration Files
To query on workflow events, modify the iw.cfg file so jobs are not deleted from the
content store when they complete, as follows:
[workflow]
delete_jobs_on_complete=false
The Teamsite report server archives the event-related information into a relational database
provided by the customer. The report server adheres to the JDBC standard while accessing
and modifying a database. The reporting service supports the following databases:
Oracle 8i, Oracle 9i, MS SQL Server 2000 and IBM DB2 8.1. The database schema should
be created prior to starting the TeamSite report server. The necessary DDL scripts will be
provided with the reporting server package.

The iw-home/tsreport/conf/tsreport.xml file is used to configure reporting.
This section shows complete file and then describes the configuration parameters in each
area and specifies the information to be modified. Most of the information in this file is
entered during the installation. You should make generally make changes to this file using
the iwconfigtsreport CLT.
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<License key="_LICENSE_KEY_"/>

<Logging>

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" >
<appender name="tsreport" class="org.apache.log4j.FileAppender">
<param name="File" value="_IWLOGDIR_/tsreport.log" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%d{HH:mm:ss.SSS} %-5p [%t] - %m\n"/>
</layout>
</appender>
<root>
<priority value="ERROR"/>
<appender-ref ref="tsreport"/>
</root>
<category name="com.interwoven">
<priority value="INFO"/>
<appender-ref ref="tsreport"/>
</category>
</log4j:configuration>
</Logging>
149


<Database
poolsize="1"
driver="_JDBC_DRIVER_NAME_"
url="_JDBC_CONNECT_STRING_"
user="_DB_USER_" />


<Cssdk
poolsize="1"
server="localhost"
configfile="_CSSDK_CFGFILE_"
locale="en" />




Product>
<param name="type" value="teamsite" />
<param name="name" value="Product : TeamSite" />
<param name="ref-id" value="1" />
<param name="database-id" value="42" />

</Product>


<Receiver>
<EventServer> 
<param name="java.naming.factory.initial"
value="org.exolab.jms.jndi.InitialContextFactory"/>
<param name="java.naming.provider.url"
value="tcp://localhost:_JNDI_PORT_/"/>
<param name="TopicConnectionFactory"
value="JmsTopicConnectionFactory"/>


<Listener class="com.interwoven.tsreport.server.TeamsiteListener"
topic="Interwoven" product-ref="1">
<param name="Reportable Extended Attributes">
<value name="key"/>
<value name="key1"/>
<value name="key2"/>
</param>
</Listener>
</EventServer>
</Receiver>
</configuration>
License key
The license key is added to this file during installation. If you do not have the license key
when you install TeamSite, rerun the reporting installation module.

Logging
The <param> element describes where the log file is written; the directory where the file is
located may be changed during installation.
The <priority> element within the <category> element can be changed to reflect the
level of debugging. The levels of debugging are ERROR, WARN, INFO, and DEBUG. Refer to
http://logging.apache.org/log4j/docs/ for details.
Database
The installation software enters this information into this file.
" The <poolsize> element describes the number of threads to connect to the database;
leave this at one.
" The <driver> element refers to the database driver required.
" The <URL> element is the URL connect string.
" The <user> element refers to the database user. During installation, you are also asked
for this user’s password; it is stored in a different file.
CSSDK
If the report server is being run under an account other than root, you must also add the
user and role. The user account under which the reporting server is running must be in the
TeamSite roles file with sufficient privileges.
" The <poolsize> element describes the number of threads to connect to the database;
leave this at one.
" The <server> element identifies the server where TeamSite is running.
" The <configfile> element provides the location of the configuration file.
" The <locale> element identifies the language of the server.
Product
This section is currently a placeholder for future release; you do not need to make changes.
Receiver
This section should be manually edited. You need to specify values for the <param> element
named Reportable Extended Attributes at the end of the file. Replace key, key1, and
key2 with the names of extended attributes to be reported on. Add additional value
elements as needed. If the EAs in metadata.cfg are to be reported on, the full name
should be specified, such as TeamSite/Metadata/EAName. Restart the report server.
151
Archived Events
The following server events are archived in the reporting database.
Event Name Attribute Names

ResetConfig timestamp | user | role
ShutDown timestamp | user | role
StartUp timestamp | user | role
ThawAll timestamp | user | role
Thaw timestamp | user | role | archive
FreezeAll timestamp | user | role | seconds
Freeze timestamp | user | role | seconds | archive
DiskLow timestamp | user | role | directory | message
DiskFail timestamp | user | role | directory | message
BlockBatchJobs timestamp | user | role | seconds | archive
UnblockBatchJobs timestamp | user | role | archive
The following user events are archived in the reporting database. The events SetEA through
DestroyFSE are only available when turned on by iwat scripts as described in the TeamSite
Command-Line Reference.

ModifyEntity timestamp | user | role
Update timestamp | user | role | area | objectId
Submit timestamp | user | role | area | objectId
Lock timestamp | user | role | area | path | objectId |
owner | comments
Unlock timestamp | user | role | area | path | objectId |
owner | comments
DestroyWorkarea timestamp | user | role | area
CreateWorkarea timestamp | user | role | area
PublishStagingArea timestamp | user | role | edition | area
DestroyEdition timestamp | user | role | edition
DestroyBranch timestamp | user | role | branch
CreateBranch timestamp | user | role | branch
SetEA timestamp | user | role | area | path | eaKey
DeleteEA timestamp | user | role | area | path | eaKey
SyncModify timestamp | user | role | area | path | fseType
SyncDestroy timestamp | user | role | area | path | fseType
SyncRevert timestamp | user | role | area | path | fseType |
revertType
RenameFSE timestamp | user | role | area | path1 | path2
CreateFSE timestamp | user | role | area | path
ModifyFSE timestamp | user | role | area | path
DestroyFSE timestamp | user | role | area | path

Archived Events
The following workflow events are archived in the reporting database:

WorkflowActivate timestamp | user | role | type ("workflow") | wfName
| workflowId
WorkflowInactivate timestamp | user | role | type ("workflow") |
wfName| workflowId
ChooseTransition timestamp | user | role | wfName | workflowId | task
| taskId | choice
TaskTimedOut timestamp | user | role | wfName | workflowId | task
| taskId
TaskUndoChoice timestamp | user | role | wfName | workflowId | task
| taskId | choice
TaskActivate timestamp | user | role | wfName | workflowId | task
| taskId | other | otherId
TaskInactivate timestamp | user | role | wfName | workflowId | task
| taskId
TaskGoActive timestamp | user | role | wfName | workflowId | task
| taskId
TaskInvokeExternal timestamp | user | role | wfName | workflowId | task
| taskId
TaskCalledBack timestamp | user | role | wfName | workflowId |
taskId | returnCode
TaskAddFile timestamp | user | role | wfName | workflowId | task
| taskId | path
TaskRemoveFile timestamp | user | role | wfName | workflowId | task
| taskId | path
TaskDeleteFile timestamp | user | role | wfName | workflowId | task
| taskId | path
TaskGroupTaken timestamp | user | role | wfName | workflowId | task
| taskId | taker
TaskMoveFile timestamp | user | role | wfName | workflowId | task
| taskId | path1 | path2
153
Database Schema
The iw-home/tsreport/conf/ddl/tables.xml schema lists the available tables in
reporting.
<?xml version="1.0"?>

<database>
<schema name="teamsite_report_schema">
<table name="EventsSummary"/>
<table name="WFEventsSummary"/>
<table name="Files"/>
<table name="FileVersions"/>
<table name="WFTaskEventComments"/>
<table name="ExtendedAttributes"/>
<table name="VersionedFileEAs"/>
<table name="DataCaptureTemplates"/>
<table name="report5_view"/>
<table name="report6_view"/>
</schema>
</database>
Every table has a schema that describes the columns. Most of the columns are self-
explanatory and use basic data types as described in the schema. All tables in the reporting
database schema have an ID column. This column is used to uniquely identify a row in each
table. This ID is globally unique across the entire schema. The ID column is also the primary
key in each case.
For example, the following code from a schema describes the FileVersions table. Each row
in this table represents a particular version of a file or directory in Teamsite. Each time a
submit event is generated, each file associated with the submit is entered as one row in this
table.
- <table name="FileVersions">
<attribute name="ID" type="char(40)" not_null="true" />
<attribute name="EventID" type="char(40)" not_null="true" />
<attribute name="SubmitType" type="varchar(32)" not_null="true" />
<attribute name="FileID" type="char(40)" not_null="true" />
<attribute name="FileType" type="varchar(32)" not_null="true" />
<attribute name="LastModifier" type="varchar(32)" not_null="true" />
<attribute name="ContentModificationTime" type="datetime"
not_null="true" />
<attribute name="AttributeModificationTime" type="datetime"
not_null="true" />
<attribute name="Comments" type="blob" not_null="false" />
<attribute name="Version" type="varchar(255)" not_null="true" />
<attribute name="DctId" type="char(40)" not_null="false" />
<attribute name="DcrId" type="char(40)" not_null="false" />
</table>

Database Schema
This table has four columns that serve as foreign keys indexing into the other reporting
tables (as illustrated in Figure 14):
a. EventID: This column maps to the ID columns in WFEventsSummary table and

EventsSummary table. Since the ID column is a globally unique identifier, it is
safe to use one column to map to two separate tables. This column identifies the
event associated with this file version.
b. FileID: This column maps to the ID column in the Files table. This provides the file
name and path information for this particular file version.
c. DctID: This column maps to the ID column in the DataCaptureTemplates table
and provides the category and type information of the data capture template used to
create this data record. If a particular file version is not a data record, then this col-
umn has a null value.
d. DcrID: This column maps to the ID column in the FileVersions table itself. This
column identifies the particular version of the data record used to generate the
applicable output file.
Each database type has its own schema. The schemas are located in the iw-home/tsreport/
conf/ddl directory and are named: db2_schema, mssql.xml, mysql_schema.xml, and
oracle_schema.xml. Except for the attributes and values for the <jdbc> element, the files
are identical.
The other reports defined in the tables.xml schema are described here and the mapping
relationships are illustrated in Figure 14:
" EventsSummary—Every TeamSite event, with the exception of workflow-related

events, is archived in this table. Each event is persisted as a separate row in this table.
" WFEventsSummary—All events generated by the TeamSite workflow engine are
archived in this table.
" Files—This table contains all files in the TeamSite repository that are either versioned
or were at any time part of a workflow task. The entries in this table are vpaths and do
not by themselves provide any version information.
" ExtendedAttributes—This table contains a list of all extended attribute key/value
pairs. Each row in the table is a unique extended attribute name and value.
" DataCaptureTemplates—This table contains all the category and type information
for all the templates defined in TeamSite. Each row in the table uniquely represents a
particular category and type.
" WFTaskEventComments—This table contains all comments associated with a
particular task or job event. Any job or task transition to a particular state generates an
event, which could potentially have comments associated with it. All these comments
are archived in this table. The table has a column EventID that serves as a foreign key
and maps to the ID column in the WFEventsSummary table.
155
" VersionedFileEAs—This table establishes a many-to-many relationship between the

FileVersions table and the ExtendedAttributes table. In TeamSite, one file can have
many extended attributes and a single key/value pair can be an extended attribute on
multiple files. The two main columns in this table are:
a. VersionedFileID: This foreign key maps to the ID column in the FileVersions table
and represents a particular file version.
b. EAID: This columns maps to the ID column in the ExtendedAttributes table and
represents one particular extended attribute.

Database Schema
Events_Summary
Data Capture Templates
PK ID
PK ID
Event_Name
Event_Type Category
Time Stamp Type
UserID
Role FileVersions
Server
Backing Store PK ID
Store
Branch Time stamp Files
Area Submit Type
Freeze Duration FK1 File ID PK ID
File Path 1 Version
File Path 2 File Type Directory Path
Owner FK2 Dct ID Name
Comments FK4 Dcr ID Server
Edition FK3,FK5 Event ID Store
Object ID Last Modifier Branch
FseType Content Change Time
RevertType Attribute Change Time
Versioned File EAs
WFEvents_Summary PK ID
PK ID FK1 Version File

FK2 EA
Event_Name
Event_Type
Time Stamp
User
Role
Extended Attributes
Server
Workflow Name PK ID
Workflow ID
Task Name Key
Task ID Value
Task AreaVPath
Other Task Name
Other Task ID WFTaskEventComments
File Path
PK ID
File Path 1
File Path 2
FK1 Event ID
Transition Name
Comments
Transition ID
Grouptask Taker
Duration
Choice
Return Code
Figure 14: Relationship of reporting database schemas
157
Crystal Enterprise Configuration

This section provides information on issues related to configuring Crystal Enterprise
software for use with TeamSite Reporting.
Running on a Windows Server

Crystal Enterprise and TeamSite do not run on the same computer when using Windows
operating systems. Crystal Enterprise 10 installs a version of libeay32.dll under the
SYSTEM32 directory which is incompatible with CSSDK. A workaround for this problem is
to move the offending dll from SYSTEM32 to the Crystal Enterprise executable directory. By
default, this directory is c:\Program Files\Crystal Decisions\Enterprise
10\win32_x86.
Database Drivers
The Crystal Enterprise server must have the appropriate database client drivers installed and
configured. Because Crystal Enterprise accesses the TeamSite Events database when
rendering the TeamSite reports, the Crystal Enterprise server must be configured
appropriately to have access to this database. For example, it may be required to have an
ODBC System DSN entry referring to the TeamSite events database on a Crystal Enterprise
server. In the case of Oracle, it may be required to install an Oracle client with the
appropriate TNS setup on the Crystal Enterprise server. Please refer to the Crystal Enterprise
Administrative Guide and the appropriate database manuals for details.
Displaying Reports in ContentCenter

The ContentCenter Reporting tab is designed to display only those reports residing under a
specified directory. The name of the directory is configured by the TeamSite administrator
in the TeamSite Reporting installer module. The administrator should install the TeamSite
reports under this directory on the Crystal Enterprise server. Please refer to the Crystal
Enterprise Administrative Guide for more details on creating directories and deploying reports.
To create a folder under Crystal Enterprise:

1. Open the Admin Launchpad. From the Launchpad, open the Crystal Management
Console (CMC).
2. Log in as Administrator.
3. Select Organize > Folders.
4. Click New Folder. Enter the new folder name (for example, TeamSite Reports).
To import reports under Crystal Enterprise:

1. Open the Admin Launchpad. From the Launchpad, open CMC.
2. Log in as Administrator.

Troubleshooting
3. Under Organize > Folders.

4. Select the folder and/or subfolder where the report is to reside. Repeat until the
desired location is reached.
5. Click New Object.
6. Browse for the report on the local system. Click OK.
Repeat steps 4-6 for all other reports.
Setting up Individual Users

Individual users need to be configured on Crystal Enterprise, since Crystal Enterprise has its
own authentication mechanisms. Please refer to the Crystal Enterprise Administrative Guide for
more details.
Although Crystal Enterprise natively supports NT login as an authentication method, the

ContentCenter Professional Reporting tab only supports login through the Crystal
Enterprise or LDAP authentication methods.
Reports on Crystal Enterprise have Crystal-proprietary ACLs associated with them. For a
user to view a TeamSite report, the users should have “View on Demand” rights granted to
them on the reports (or the folder that contains these reports).
To set the View On Demand ACL on the TeamSite Reports folder:

1. Open the Admin Launchpad. From the Launchpad, open CMC. Navigate to the
TeamSite reports root folder.
2. Click on the Rights tab.
3. Grant all relevant users and groups View On Demand access level.
Clicking the ContentCenter Logout link will also log the user out of Crystal Enterprise if
the user has logged into reporting during the TeamSite session. Only the session created
within ContentCenter is logged out. Crystal Enterprise sessions in other windows,
including those pointed to the Crystal Enterprise user interface, are not affected.
Troubleshooting
This section contains troubleshooting issues related to reporting.
Error Messages Displayed in ContentCenter

If generating a report from ContentCenter results in an error message from Crystal
Enterprises, the message displays in ContentCenter. Check the Crystal Enterprises
documentation and online knowledge base for details.
159
Large Number of Files

If you have a large number of files submitted, such that a report may return more than
20,000 files, you need to change the Crystal Enterprises configuration to allow the larger
number of files. Otherwise, ContentCenter users will see an error message. Refer to the
Crystal Enterprises online knowledge base.
Restarting Reporting
If the server containing the reporting database files goes down or is rebooted, the link
between Reporting and the database file is broken. Check the log files to determine whether
the link is broken. If it is, you must restart TeamSite Reporting after bringing the server
back up.

Appendix C
Specifying Content Encoding
TeamSite now includes a configuration file called file_encoding.cfg that enables you to
create rules to determine the character encoding of the contents of files that do not specify
their encoding. The file_encoding.cfg file (located by default in iw-home/local/
config) uses an XML-based language called regex_map. The regex_map format is designed
to be structured enough for maintainability, and extensible so that the same format may be
used in future configuration files. This file contains a <regex_map> element, which contains
rules to map vpaths (directory paths) to the character encoding specification of file
contents.
For TeamSite to correctly interpret a text document, it is necessary to know the character
encoding in which its contents are represented. Unlike an HTML document that can declare
the encoding of its contents using an <HTTP META="Content-Type" CONTENT="text/
html; charset=charsetname"> tag, a plain text file has no mechanism for storing this
information. The encoding is required for certain TeamSite functionality including
VisualPreview and the Source Differencing and Interwoven Merge tools.
In previous releases, VisualPreview relied on the Content-Type header from the content
Web server to specify the encoding of plain text files. This required you to configure the
encoding at your content Web server which may limit flexibility and scalability. By default,
the Source Differencing and Interwoven Merge tools assumed that text files are encoded in
ISO-8859-1, which is not suitable for content in eastern Asian languages.
The sections that follow describe the regex_map language, and how it is used to specify the
character encodings of text files used by TeamSite.
regex_map Defined
A regex_map is a filter that transforms a set of input variable values into a set of output
variable values through a set of rules written in XML using the following form:
161
Input Variables
var1 = "original value1"
var2 = "original value2"
regex_map
<regex_map>
<match .../>
<subst .../>
<subst .../>
<match .../>
</regex_map>
Output Variables
var1 = "transformed value1"

var2 = "transformed value2"
var3 = "new value3"
Simple regex_map Example
The following regex_map determines the character encoding of TeamSite files. Each
reg_vpath means that a match is to be performed on the vpath variable, and each
val_encoding assigns a result if the match succeeded.
Input Variable
vpath = path of a TeamSite file
regex_map
<regex_map>
<match reg_vpath= "/web/techsupport/jp/" val_encoding= "Shift_JIS"/>
<match reg_vpath= "\.txt$" val_encoding= "8859_1"/>
<match reg_vpath= ".*" val_encoding= "UTF8"/>
</regex_map>
Output Variable
encoding = character encoding

for the given vpath
In the preceding regex_map example:

" If the input vpath variable is "/x/y/z.txt", the resulting encoding variable is set to
"8859_1" because "/x/y/z.txt" ends with ".txt".

The regex_map Format
" All files in the /web/techsupport/jp branch are encoded in Shift-JIS, because their
vpath begins with "/web/techsupport/jp/".
" If the input vpath variable does not contain "/web/techsupport/jp/", the output
encoding variable is set to "UTF8" because ".*" matches any string.
Note that each rule within <regex_map> is evaluated in order, and that the first <match> tag
with a regular expression that matches the input variable vpath is used and subsequent rules
are ignored. Therefore, it is important for the <match reg_vpath= ".*" val_encoding=
"UTF8"/> rule to appear last.

A regex_map consists of a <regex_map> element that contains substitution and match rules
expressed by using <subst> and <match> tags. Substitution and match rules are consulted
in the order in which they are listed within the <regex_map> element. Each rule may assign
values to variables.
Rule Syntax
Every <subst> or <match> rule expresses the following logical operation:
" If all the regular expressions within this rule match, then perform all of this rule’s
variable assignments; otherwise, ignore this rule and consult the next rule.
Execution terminates when the first <match> rule has been applied, or when there are no
more rules. A <subst> rule that has been satisfied does not terminate execution (unless it is
the last rule).
All attributes of rules use the form reg_varname or val_varname.

" reg_varname attribute—Applies a regular expression to varname.
" val_varname attribute—Assigns a value to varname if all of the regular expressions in
the current rule are satisfied.
The following are some simple examples of rules.

" If vpath starts with /default/main/ set the encoding to 8859_1 and continue
processing:
<subst reg_vpath="^/default/main/" val_encoding="8859_1"/>
" The encoding of all files named index_zh_TW.html anywhere in the /web branch is
Big5. There are no exceptions to this rule, so stop processing if it applies.
<match reg_vpath= "^/web/(STAGING|WORKAREA|EDITION).*/

index_zh_TW.html" val_encoding= "Big5"/>
Note that the “or” capability of regular expressions, expressed by the pipe character ( | ),
enables this single rule handle three cases at once (STAGING or WORKAREA or EDITION).
163
" The encoding is always "Shift_JIS".

<match val_encoding="Shift_JIS"/>
When there are no reg_ conditions, the assignment always executes if the rule is
encountered. Any rules that occur after this statement are unused.
Regular Expression Syntax
The regex_map interpreter uses Perl-Compatible Regular Expressions (PCRE) as its regular
expression engine. The PCRE is similar to the Perl regular expression engine and includes
advanced features such as “lookahead” assertions.
Regular expressions in regex_map are case-sensitive by default. If a variable is listed in the

opt_case_insensitive attribute of <regex_map>, all regular expressions applied to that
variable in the regex_map are case-insensitive.
For example, because filenames and URLs are case-insensitive on Microsoft Windows, the
following declaration would be recommended when writing a regex_map for a TeamSite
server on Microsoft Windows:
<regex_map opt_case_insensitive="vpath url">

<subst reg_vpath="..." .../>
<match reg_url="..." .../>
</regex_map>
Variables
Variables store strings to be passed in the following ways:

" as input to a regex_map from an application
" from rule to rule within a regex_map
" as results from a regex_map to the application
Variable names are case-sensitive and must begin with a letter and may contain any sequence
of alphanumeric characters and the underscore character (“_” ). References to any variable
whose value is not set by the application or by rules in the regex_map evaluates to an empty
string.
Application Variables
Any application that uses a regex_map gives it a set of inputs before execution and inspects a
set of output variables when the regex_map processing completes. These input and output
variables are known as application variables.

Intermediate Variables
You may find it helpful to assign intermediate results to your variables in regex_map rules
before arriving at final output values. These intermediate variables can help make a complex
set of rules more manageable by factoring out several separate conditions into one
condensed case. You can then write one rule to act on the condensed case, instead of
repetitively writing the same actions for the individual initial conditions. “Strategies for
Effective regex_maps” on page 169 contains an example of factoring.
Intermediate variables should have names that begin with x_ to avoid conflicts with
application variables that Interwoven may create in the future.
Interpolation of Variables and Captured Subexpressions

When assigning a value to a variable, the values of other variables can be included. In
val_attributes, each occurrence of ${varname} or $varname causes the value of
varname to be inserted instead, as shown in the following example:
Input Variables
good = "Bon"
my = "mon"
friend = "ami"
regex_map
<regex_map>
<subst val_french="${good}jour"/>
<match val_friend="copain"
val_french="$french, $my $friend!"/>
</regex_map>
Output Variables
good = "Bon"
my = "mon"
friend = "copain"
french = "Bonjour, mon ami"
In the preceding example:

" In the <subst> rule, curly braces ({ }) are required to separate the variable name good
from the literal string jour that immediately follows.
" In the <match> rule, there is no need to disambiguate the three variables because the
variable names french, my, and friend are followed by a comma, a space, and an
exclamation point, none of which can be confused as being part of a variable name.
165
" In the second rule, the values of friend and french are taken from the time at which
the rule was encountered. All assignments in a rule appear to occur simultaneously and
do not affect each other.
It is also possible to include just portions of variables. Placing parentheses around portions
of a regular expression applied to varname creates a captured subexpression variable that
can be used when assigning values. The longhand form of a captured subexpression variable
is ${varname:n}, which refers to the string captured by the nth pair of parentheses in
reg_varname.
Note: Pairs of parentheses are numbered according to the order in which their left
parenthesis occurs within the regular expression. Parentheses of the form
(?:some_expression) are used solely for grouping characters in the regular
expression, not for capturing text during matching, and are excluded from the
count.
The shorthand version of a captured subexpression variables is $n. Note that the shorthand
notation can only be used when the variable being modified is the same as the variable from
which the subexpression was captured.
Unlike application and intermediate variables, captured subexpression variables are scoped
to the <subst> or <match> rule that created them. If a captured subexpression variable
needs to be used in a subsequent rule, it should be stored in an intermediate variable.
For example, the pair of rules in the following regex_map makes the assignment
message="regex_maps are awesome maps!" in an inefficient way:

Input Variables
text = "My, how large your eyes are!"

message = "regards some maps with awe"
regex_map
<regex_map>
<subst reg_text="This regular expression match fails"
reg_message="some (m[aeiou]ps)"
val_text="so this assignment never occurs..."
val_message="... and the $1 capture is wasted."/>
<subst reg_text="(?:(bloop)|([a-z]+)(!))"
reg_message="(...)ards ((.{4}) (.{4})) with (.*)"
val_message="$1ex_${4} ${text:2} ${message:5}$2${text:3}"/>
</regex_map>
Output Variables
text = "My, how large your eyes are"

message = "regex_maps are awesome maps!"
In the previous example:

" The first rule does not apply because the value of the text variable does not match the
regular expression in reg_text.
" While performing the regular expression match for message, the special variable
${message:1} (the $1 variable associated with message) takes on the value maps within
the scope of the rule. However, since the entire rule is inapplicable, it has no effect.
Neither of the two val_assignments happens, and the temporary
${message:1}="maps" binding is discarded.
" The second rule does apply, since both of the reg_text and reg_message matches
succeed. The parentheses also capture the text in the strings, resulting in the following
temporary bindings:
${text:1} = empty string
${text:2} = are
${text:3} = !
${message:1} = reg
${message:2} = some maps
${message:3} = some
${message:4} = maps
${message:5} = awe
" Finally, variable interpolation occurs for the val_message assignment. Since the $1,
${4}, and $2 occur in a val_message context, they are treated as shorthand for
${message:1}, ${message:4}, and ${message:2}, respectively. The curly braces for
${4} are optional in this case, and could be used in other situations to clarify where the
variable name ends and literal text begins.
167
Quoting
Inside a val_ attribute, dollar signs ($) have special meaning—they mark the start of
captured subexpression names. To force a dollar sign to lose this special meaning (and be
treated as a literal dollar sign), it must be escaped by preceding it with a backslash. Similarly,
a backslash is treated as a special quoting character unless it is escaped by a preceding
backslash.
Input Variable
hello = "Hi"
regex_map
<regex_map>
<subst reg_hello="(.*)"
val_hello="$1! Parking costs \$1\\hr."
</regex_map>
Output Variable
hello = "Hi Parking costs $1\hr."
In the preceding example, hello is assigned the value "Hi! Parking costs $1\hr."
(with the deliberately “wrong” backslash used instead of a forward slash for demonstration
purposes).
Also, because regex_map is written in XML, characters with special meaning in XML need
to be represented using XML entities. These special characters are described in the
following table.
Special XML Character Visual Representation XML Entry

Double quote ” "
Apostrophe ’ '
Ampersand & &
Greater than > >
Less than < <
For example,
<subst val_statement="Programmers think "1 & 1 is 1.quot;"/>
assigns the following value to the statement variable:

Programmers think “1 & 1 is 1.”

Strategies for Effective regex_maps
Strategies for Effective regex_maps

The regex_map grammar is a powerful string manipulation language yet still allows simple
configurations to be expressed simply. This is due to:
" the ability to work with multiple variables
" the use of regular expressions with the capability to reference captured subexpressions
" the option to chain rules with <subst> or stop processing with <match>
By taking advantage of these features, you can write configuration files that are compact and
manageable.
The following example demonstrates how factoring and intermediate variables can make a
regex_map configuration scale to handle complex situations. Suppose that a system-wide
reorganization forced you to rename all files named README to README.TXT and relocate all
files under the /a/b branch to the /c/d branch. You could list all of the possibilities as
follows:
<regex_map>
<!- Handle both branch move and file extension addition ->
<match reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)README$"
val_vpath= "/c/d/$1README.TXT"/>
<!- Handle branch move only ->

<match reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)"
val_vpath= "/c/d/$1"/>
<!- Handle file extension addition only ->

<match reg_vpath= "(.*)/README$"
val_vpath= "$1/README.TXT"/>
</regex_map>
But this strategy could become extremely complicated if there were more combinations. A
factored set of rules can handle each change independently:
<regex_map>
<!- Handle a possible branch move ->
<subst reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)"
val_vpath= "/c/d/$1"/>
<!- Handle a possible file extension addition ->

<subst reg_vpath= "(.*)/README$"
val_vpath= "$1/README.TXT"/>
</regex_map>
169
A complicated set of rules could be clarified with intermediate variables, for example:
<regex_map>



<subst reg_vpath="^(.*?)/((?:WORKAREA|EDITION|STAGING).*)"
val_x_branch="${vpath:1}"
val_x_rest="${vpath:2}"/>
<subst reg_x_rest="((?:WORKAREA|EDITION)/[^/]+|STAGING)(.*)"
val_x_area="${x_rest:1}"
val_x_rest="${x_rest:2}/>
<subst reg_x_rest="(.*)(/.*)"
val_x_dir="${x_rest:1}"
val_x_file="${x_rest:2}"/>



<subst reg_x_branch="^/a/b$"
val_x_branch="/c/d"/>
<subst reg_x_file="^/README$"
val_x_file="/README.TXT"/>



<subst val_vpath="$x_branch$x_area$x_dir$x_file"/>
</regex_map>
In the preceding example, factoring out the vpath decomposition logic simplifies the actual
transformation rules. In a complex situation with many transformation rules, adding a few
standardized rules at the beginning and end of the regex_map is worthwhile.
“Advanced regex_map Example” on page 173 demonstrates of the expressiveness of

regex_maps by showing how a Roman numeral can be incremented with sequential string
substitution rules.
Internationalization and regex_maps

TeamSite regex_maps should be written in UTF-8 and should provide UTF-8 input values
and expect UTF-8 output values for all variables. The regular expression engine is
UTF-8-aware. For example, a period (.) in a regular expression matches a single character,
regardless of the number of bytes needed to represent that character.
Note: If you need to specify non-ASCII literal characters in your regex_maps, ensure the
text editor you are using can edit and save the file_encoding.cfg in UTF-8
encoding. Refer to page 179 for details about text editor encodings.

VisualPreview and file_encoding.cfg
VisualPreview and file_encoding.cfg

To determine the encoding of a text file, VisualPreview mimics the behavior of your web
browser by performing the following series of checks:
" First, VisualPreview checks the Content-Type header from the content webserver. If
the MIME type (text/html or text/plain) is followed by a character encoding
declaration (for example, Content-Type: text/plain; charset=UTF-8), it uses the
specified encoding.
" If the file is an HTML document, VisualPreview searches for a character encoding
declaration in an HTML META tag (for example, <META HTTP-EQUIV="Content-
Type" CONTENT="text/html; charset=Big5">), which it uses if found.
" If the aforementioned methods do not return the encoding, VisualPreview computes
the encoding using the regex_map configuration in the file_encoding.cfg file. It uses
the vpath as the input variable and the encoding as the expected output.
Source Differencing and Merging and file_encoding.cfg

Unlike VisualPreview, the Source Differencing and Interwoven Merge tools do not mimic
your web browser. Instead, they rely entirely on the file_encoding.cfg file to determine
the character encoding of text documents. The Source Differencing and Interwoven Merge
tools assume that the “other” file and the “common ancestor” file share the character
encoding of the workarea file.
The following list of encodings are the IANA preferred charset names (http://
www.iana.org/assignments/character-sets) and are valid entries for the
file_encoding.cfg file:
English, German:
" ISO-8859-1
" ISO-8859-15
" windows-1252
Japanese:
" Shift_JIS
" EUC-JP
Korean:
" EUC-KR
Simplified Chinese:
" EUC-CN
" GB2312
Unicode:
" UTF-8
171
Note: file_encoding.cfg has no effect on the file encoding seen in visual differencing.
This is so that what is seen in the visual differencing tool most closely approximates
what will be seen in the production environment.
Sample file_encoding.cfg



<vpath_to_encoding_map>

<regex_map opt_case_insensitive="vpath encoding">

<subst val_encoding="8859_1"/>


<subst reg_vpath="(?:_ja|_jp|_jpn)\."
val_x_lang="Asian:Japanese"/>


<subst reg_vpath=".*\.zh\.txt$"
val_x_lang="Asian:Chinese"/>


<subst reg_x_lang="Asian:Japanese"
val_encoding="Shift-JIS"/>


<subst reg_x_lang="Asian:Chinese"
val_encoding="Big5"/>

<subst reg_vpath="(?:(?:WORKAREA|EDITION)/[^/]+|STAGING)/([^/]+)/"
val_encoding="${vpath:1}"/>


<match reg_encoding="(sjis|shift[_-]jis)"
val_encoding="Shift_JIS"/>
</regex_map>
</vpath_to_encoding_map>

Advanced regex_map Example
Advanced regex_map Example

This example regex_map, which adds one to a Roman numeral, demonstrates the power of
chained substitution rules. It uses num as both the input and the output variable. The
example below shows 49 being transformed into 50.
Input Variable
num = "XLIX"
regex_map
<regex_map>
<!- Add one the "dirty" way: Append "I" ->
<subst reg_num="(.*)" val_num="$1I"/>
<!- ... then do the carrying ->

<subst reg_num="(.*)IIII$" val_num="$1IV"/> 
<subst reg_num="(.*)IVI$" val_num="$1V"/> 
<subst reg_num="(.*)VIV$" val_num="$1IX"/> 
<subst reg_num="(.*)IXI$" val_num="$1X"/> 
<subst reg_num="(.*)XXXX$" val_num="$1XL"/> 
<subst reg_num="(.*)XLX$" val_num="$1L"/> 
<subst reg_num="(.*)LXL$" val_num="$1XC"/> 
<subst reg_num="(.*)XCX$" val_num="$1C"/> 
<subst reg_num="(.*)CCCC$" val_num="$1CD"/> 
<subst reg_num="(.*)CDC$" val_num="$1D"/> 
<subst reg_num="(.*)DCD$" val_num="$1CM"/> 
<subst reg_num="(.*)CMC$" val_num="$1M"/> 
</regex_map>
Output Variable
num = "L"
The regex_map language works well with Roman numerals because it is designed for string
manipulation. It would be much more difficult to write a regex_map that increments Arabic
numerals, due to the larger set of rules needed to increment a single digit and the lack of
looping capability to perform the carrying operation.
173

Appendix D
Internationalization
TeamSite is engineered with your global enterprise in mind. This includes internationalizing
the TeamSite server to support multibyte languages and locales at the operating system, and
localizing the ContentCenter user interface and documentation. Internationalized TeamSite
supports the following needs:
" International user data—Enables users to enter data, content, and field values in
English, Korean, Traditional Chinese, Simplified Chinese, French, German, and
Japanese.
" Localized operating system—The TeamSite server runs on any one of the following
localized operating systems: English, German, Korean, Simplified Chinese, and
Japanese (one locale per instance of iwserver).
" Localized user interfaces—The ContentCenter Professional and ContentCenter
Standard interfaces have been localized into French, German, Japanese, Korean, and
Simplified Chinese.
" Localized file names—You are no longer restricted to having file and directory names in
ASCII character encoding. File, directory, branch, workarea, and edition names can
have Japanese names on Japanese servers, German names on German servers,
Simplified Chinese names on Simplified Chinese servers, and Korean names on Korean
servers.
" Continued support for processing of non-English metadata and FormsPublisher content
(available since TeamSite 4.2.1 and 4.5.1).
Note: Information on localized servers contained in this chapter is only valid with
localized TeamSite versions. Check the Release Notes to determine whether
localized servers are supported in your TeamSite version.
Supported Client and Server Platforms

The client connecting to the TeamSite server must use the same language as the server (they
can be different locales of the same language). For example, running ContentCenter on
German Windows 2000 connected to a Solaris 2.8 TeamSite server running in the German
Latin 1 locale (de) is supported. However, if that same German Windows 2000 client
logged into a Windows 2000 Japanese TeamSite server and added files with names
175
containing German High ASCII characters, those files would not be supported by the
TeamSite server due to limitations with the native file system and handling of characters
outside of its code pages.
Supported Content
TeamSite supports non-ASCII characters in branch, area, directory, vpath, and file names
in addition to the contents of a file.
Limitations and Assumptions

" An internationalized TeamSite server does not mean that your TeamSite server can be
run in multiple locales concurrently. The TeamSite server can run in any supported
locale, but one locale at a time.
" It is expected that the locale in which the TeamSite server runs is the same locale as the
rest of file system and server operating systems. Consider the following scenario:
a. You have a file server which runs in ja (Japanese Extended UNIX Code) locale,
with a hierarchy of file and directory structures with names encoded in Japanese
EUC.
b. You install and run your TeamSite server on this file server.
c. You use the file system interface to migrate your existing hierarchy of files and
directories into TeamSite’s Intelligent File System (/iwmnt).
d. The TeamSite server must run in the ja locale for these file and directory names to
be processed correctly. If you change the locale to ja_JP.PCK (Japanese Shift-JIS or
Ja_JP.IBM-932 on AIX) before TeamSite server is started, the TeamSite server
would incorrectly interpret the imported file and directory names as ja_JP.PCK
(or Ja_JP.IBM-932) encoded. This is not a supported scenario.
" Mixed-locale file systems are not supported. For example, a scenario where a parent
directory has directory names encoded in ja_JP.PCK (Japanese Shift-JIS,
Ja_JP.IBM-932 on AIX), and child directories have file names encoded in ja (ja_JP on
AIX) is not supported.
" If TeamSite server is running on a German operating system using a German Latin1
locale, it is possible to create a branch or workarea on the TeamSite Intelligent File
System with Japanese names using ContentCenter. However, when viewed with the file
system interface, these Japanese names would appear as illegible characters because the
server is running in a Latin1 locale and does not include the Japanese character set.
This is not a supported scenario.

Content Stores and Character Encoding
This scenario is supported for Metadata because Metadata entered using the
ContentCenter does not interact with server operating system. Any data that is
interchanged with the server operating system (including VPATHs) are only meaningful if
they are within the server locale’s encoding.
" If TeamSite Intelligent File System is functioning as a networked file server, it is
expected that all other networked file system clients (for example, NFS clients) are
operating in the same locale as the TeamSite Intelligent File System file server.
Currently, NFS does not enforce this restriction and therefore enables NFS clients to be
in a different locale than the NFS server. However, NFS protocol does not do encoding
conversion. Therefore, file and directory attributes (including names) are passed
through in binary format. This would not work for TeamSite IFS functioning as file
server because it does encoding conversion from and into UTF-8 based on the server
file system’s locale.
Content Stores and Character Encoding

User-defined Content Stores that are named using multibyte characters must have a
corresponding entry in the iw.cfg file. Refer to the TeamSite Installation Guide for detailed
information on creating Content Stores.
About UTF-8
UTF-8 is the 8-bit encoding format for Unicode. Unicode is a system for exchanging,
processing, and displaying diverse written languages. Unicode supports the principal
written languages of the world as well as many classical languages.
URL Commands with Multibyte Characters

When constructing URL commands when parameters contain multibyte characters, make
sure that these parameters are URL- and UTF-8--encoded. Multibyte characters should be
URL-encoded based on their Unicode representation in UTF-8.
For example, the URL to edit the file:
/archive/main/WORKAREA/area/ .html
would be:
/iw/iw-cc/edit?vpath=/archive/main/WORKAREA/area/%e5%ba%9c.html
since the Japanese character is Unicode character U+30D5, which is encoded as the
bytes 0xe5 0xba 0x9c in the UTF-8 format.
177
Interfacing with Localized Operating Systems

The internationalized TeamSite server’s virtualized Intelligent File System (IFS) functions
the same way a regular file system does on localized operating systems. For example, if
TeamSite runs on a server that is running in the EUC-JP locale, the TeamSite IFS displays
and functions as an EUC-JP encoded file system.
To achieve this, TeamSite system calls to the operating system are converted from UTF-8
encoded textual data (for example, VPATH information) into the locale of iwserver (as
defined by the server_locale setting in iw.cfg). In most cases, this is the same as the
operating system’s native locale. The conversion is also required when operating system
information is returned to TeamSite.
Note: If the TeamSite server is run in a different locale than the host operating system’s
locale, the TeamSite virtual file system would use a different encoding locale
compared to the rest of host server’s file systems. By default, the TeamSite server
locale uses the native locale of the host operating system.
Accessing the Localized Interface

To display the localized (French, German, Japanese, Korean, or Simplified Chinese)
ContentCenter interface, you must change your browser’s language settings to the
appropriate language.
To display the localized (French, German, Japanese, Korean, or Simplified Chinese) Local
File Manager interface, your client operating system must be in the same language as the
interface you want to display.
Language of the VisualPreview Tool Bar

The language of the VisualPreview tool bar normally follows the browser's language
settings, as does the rest of ContentCenter user interface. The exception is when the
character encoding of the document being worked on through VisualPreview conflicts with
the chosen user interface language (browser's settings).
For example, an HTML document being worked on through VisualPreview has a specified
charset of “Shift_JIS”, but the chosen user interface language is “German”. In this case, the
VisualPreview tool bar cannot appear in German. Instead, the tool bar appears in English. If
the document being worked on through VisualPreview is in ISO-8859-1 encoding, then the
Visual Preview tool bar appears in German. Whenever there is a conflict, the tool bar

Specifying File Encoding of Text Files
appears in English. The following table lists the encodings that are allowed for specific
browser's language settings.
Allowed Languages (browser's

Encoding of document (charsets)
settings)
shift_jis, shift-jis, x-ms-cp932, x-sjis, Japanese or English
ms-Kanji, cp932, euc-jp, x-euc-jp, x-euc
gb2312, chinese, GB2312-80, GB231280, Simplified Chinese (PRC) or English
GBK, euc-cn, x-euc-cn, cp936
ks_c_5601-1987, euc-kr, korean, KSC5601, Korean or English
KSC_5601, cp949
iso-8859-1, Windows-1252, Latin1, latin1, German, French, or English
iso_8859-1
us-ascii, us, x-ansi, ISO646-US, ascii English only
utf-8 Japanese, Simplified Chinese,
Korean, German, French, or English
Specifying File Encoding of Text Files

All browsers rely on default settings to “guess” the encoding of web pages whose encoding is
not explicitly declared. If the browser’s default setting is different than that of the actual
encoding of the page passed to the browser, the browser may render the page incorrectly.
Therefore, the best practice is for your web pages to always declare their encoding. This
prevents your browser from guessing incorrectly when you use TeamSite, and ensures that
your web site viewers’ browsers will not have to guess which encoding they should use.
For HTML documents, VisualPreview honors the encoding specified by the charset
parameter in either a Content-Type HTTP header or in an HTML META tag. For example:
" Content-Type: text/plain; charset=UTF-8
" <META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=UTF-8">
To display multibyte characters in non-HTML text documents in VisualPreview with the

desired character encoding, the content webserver must be configured to return a
Content-Type HTTP header that specifies the encoding, for example:
Content-Type: text/plain; charset=UTF-8
If the charset is not specified—either by the content webserver’s Content-type HTTP

header, or by the charset tag within the file—VisualPreview assumes that the document is
encoded in ISO-8859-1, which may cause the document to be displayed with “garbage”
characters.
Note: To solve the issue of text files that do not specify their encoding, TeamSite 5.5.2
has introduced a new configuration file called file_encoding.cfg. Please refer to
Appendix C, “Specifying Content Encoding” for detailed information about creating
configuring settings in file_encoding.cfg.
179
Text Editor Encodings

The following table shows the default settings for various text editors.
Text Editor Platform Default Encoding To Save as UTF-8 Encoding:

vi Solaris Depends on the Cannot save or render text as
locale of vi’s active UTF-8.
process.
emacs Solaris Depends on the Cannot save or render text as
locale of emac’s UTF-8.
active process.
Usage Scenarios
The following examples illustrate some of the advantages of using TeamSite in a global
enterprise. Note that a branch scenario could also apply to a workarea, directory, or file
operation (for example, New Branch, New Workarea, and Import File). Scenarios can also
be applied to other locales.
Scenario 1
1. The TeamSite server is running in the ja_JP.PCK (Shift-JIS)locale on Solaris 8.

2. You create a branch with a Japanese name using ContentCenter running on Japanese
Windows 2000. This branch is created in the TeamSite Intelligent File System with
Shift-JIS encoding.
3. You can navigate this branch with the Japanese name using ContentCenter.
4. You can also log on to the server machine and access this branch with Japanese name
using the file system interface.
Scenario 2
1. The TeamSite server is running in the ja_JP.PCK (Shift-JIS)locale on Solaris 2.8.

2. Your TeamSite Administrator copies a directory from the file system into the TeamSite
Intelligent File System. This directory contains file and directory names with Japanese
encoded names.
3. Your TeamSite Administrator creates a file in the TeamSite Intelligent File System with a
Japanese (Shift-JIS) encoded name.
4. ContentCenter users (on any client platform) can view and access this directory (and
corresponding files) with a Japanese name.

Usage Scenarios
Scenario 3
1. You install and run TeamSite on a Japanese Solaris system in the ja_JP.PCK locale. The
file server for this system operates in the Shift-JIS locale (ja_JP.PCK locale on
Solaris 2.8 is a Shift-JIS locale.
2. You create a branch with a Japanese name using ContentCenter.
This branch displays in /iwmnt as a directory with a Shift-JIS encoded directory name
and displays in all typical file system operations with a Shift-JIS encoded directory
name just like the other files and directories in the file system.
Scenario 4
1. You install and run TeamSite on a Japanese Solaris system in a ja_JP.PCK locale. The
file server for this system operates in the Shift-JIS locale.
2. You copy an existing hierarchy of files and directory structures into a workarea called
isuzuki within /iwmnt.
3. You use ContentCenter to access the isuzuki workarea.

The file and directory hierarchy display with Japanese directory and file names and is
correctly referenced in ContentCenter.
Scenario 5
1. You install and run TeamSite on a Japanese Solaris system in a ja_JP.PCK locale.
2. Using ContentCenter, you submit a file and comments in Japanese.
3. You use the iwsubmit CLT to view the extended attributes of the file.
The Japanese submit comments are displayed correctly on the command-line. After
executing the submit, the same submit comments are displayed correctly in history log
of the file submitted.
181

Appendix E
Integrating with SiteMinder
This appendix describes the procedure for configuring TeamSite to integrate with the
Netegrity SiteMinder Policy Server. The integration enables:
" The TeamSite server to act as another web server in a portal environment controlled by
SiteMinder.
" A single sign-on where TeamSite users log in once against SiteMinder and are authorized
to access all of its resources (TeamSite and the other web servers in the portal) without
having to log in to TeamSite explicitly.
Note: TeamSite for AIX does not support SiteMinder Policy Server integration.
Requirements
" TeamSite 6.1 or above installed and configured.
" Netegrity SiteMinder Policy Server 5.5 installed and configured.
" Netegrity Web Agent 5.0 QMR5 or above installed.
" TeamSite and SiteMinder must share the same user database.
" Some familiarity with TeamSite and Netegrity SiteMinder Policy Server and Web Agent
products.
Authentication Overview
After completing the integration described in this appendix, SiteMinder controls access to
TeamSite by authenticating the user against its user database and placing an Interwoven
IWAUTH cookie in the browser. The typical sequence of data and operation flow is depicted
in the graphic and described in the legend that follows.
183
SiteMinder Policy Server

8 Active Response Module
7
5
4
1
2 iw-webd with SiteMinder web agent
3
Browser
9 6
10 10
TeamSite servletd
(Content Services)
11 11
Figure 15: SiteMinder Flow
1. TeamSite users access the TeamSite server as usual (by entering hostname/iw-cc/ in
their browser).
2. The web agent intercepts the request and prompts for users for a user name and
password.
3. Users enter their user name and password.
4. The Netegrity Web agent passes the login information to the SiteMinder Policy Server,
which authenticates the user. The Policy Server then calls the Interwoven Active
Response function in the iwtssmar.so file.
5. The Interwoven Active Response module makes an SSL connection to the TeamSite
Access Service and sends the user’s login credentials in a SOAP message using HTTP.
6. The TeamSite Access Service authenticates the user and returns a session string that the
Active Response module uses to create an IWAUTH cookie.
7. The Active Response module then writes the IWAUTH persistent cookie to the user’s
browser, which is checked each time the user visits a page served by TeamSite.

Integration Procedure Overview
Integration Procedure Overview

The integration procedure contains four major steps:
" Setting values for the INTERWOVEN_AUTH_HOST and INTERWOVEN_RAND_FILE
environment variables.
" Copying the Active Response module (iwtssmar.so) to your SiteMinder Policy Server.
" Configuring SiteMinder to recognize TeamSite users.
The detailed procedures associated with these steps are described in the sections that follow.
Setting Environment Variables

The Interwoven Active Response module uses two environment variables. One of these
specifies the host computer and port that will be used to talk to the TeamSite Access
Service. The other specifies the location of a text file that will be used to seed the pseudo-
random number generated used by the SSL encryption libraries. This may be any file,
preferably one that changes randomly.
Perform this procedure on the system where the SiteMinder Policy Server is running.
1. Change to the /usr/home/smuser directory.

2. Open the .profile file in your text editor.
3. Create an environment variable called INTERWOVEN_AUTH_HOST, for example:
export INTERWOVEN_AUTH_HOST=server.interwoven.com:443
This environment variable provides the name of the TeamSite server and optional port.
If no port number is specified, the default port number 443 is used.
4. Create an environment variable called INTERWOVEN_RAND_FILE. This variable
specifies the complete path of a file containing random text. For example:
export INTERWOVEN_RAND_File=/var/adm/random.txt
5. Save and close the .profile file.
Copying the iwtssmar.so File

The installation program automatically places the Active Response module needed to
integrate TeamSite and SiteMinder in the iw-home/lib directory on your TeamSite server.
The module is in a file is called iwtssmar.so and must be copied to your SiteMinder Policy
Server.
1. Stop all SiteMinder Policy Server daemons.
Refer to the SiteMinder Operations Guide for detailed instructions.
185
2. Copy the iwtssmar.so file from iw-home/lib to where the policyserver_home/

bin/smservauth executable can find it.
For example:
%cp iw-home/lib/iwtssmar.so /var/siteminder/bin/
Configuring SiteMinder
1. Open the SiteMinder Policy Server user interface where you will create Realms and
Rules to protect TeamSite resources.
2. Create the following Netegrity Realms:
Realm Realm Type Resource Filter
protect_iw Protected /iw
unprotected_iw Unprotected /iw/services/cm/2.0/accessservice
3. Under the protected_iw Realm, create the following Rules:

Rule Description
Authenticate_iw - iw* Configured for authenticating event actions.
Protect_iw - iw* Configured for GET, PUT, POST actions.
The other Realm does not require any rules.

4. Create a Netegrity Response with the name IWResponse and the following details:
Field Entry
Attribute of the Response WebAgent-OnAccept-Redirect
Attribute Kind Active Response
Library Name full_path/iwtssmar.so
Function Name activeResponse
Note: Leave the Parameters field empty.

5. Create a Netegrity Policy with the following label:
Add TeamSite users
6. In the Rules tab, add the following Rules:

! Authenticate_iw
! Protect_iw
7. For the Authenticate_iw Rule, set the Response to IWResponse.

Troubleshooting
Troubleshooting
Normally, if SiteMinder successfully authenticates a user, the Interwoven Active Response
module will also authenticate the user successfully. If SiteMinder successfully authenticates
a user and the Interwoven authentication fails, one of the following messages will be logged
to the SiteMinder access log file:
Interwoven: Failed to read INTERWOVEN_AUTH_HOST value.
This message is logged if the INTERWOVEN_AUTH_HOST environment variable has not

been set.
Interwoven: Failed to read random seed data.
This message is logged if the INTERWOVEN_RAND_FILE environment variable is

missing or does not point to a file that can be read by SiteMinder.
Interwoven: TCP socket connection error.
This message is written to the log file if the SiteMinder computer is unable to open
a TCP/IP socket connection to the TeamSite server. A possible reason for this
might be that the TeamSite server is unreachable or that the
INTERWOVEN_AUTH_HOST environment variable contains an incorrect host name or
port number. This message will also be seen if the Interwoven Access Service on
the TeamSite server is not configured with a valid SOAP license key.
Interwoven: SSL Connection error.
This message is written to the log file if SiteMinder is able to open a socket
connection to the TeamSite server but is unable to establish an SSL session over the
channel. Possible reasons include a misconfigured TeamSite server whose X.509
certificate is missing or corrupt.
Interwoven: Failed to send query to server.
This message is written to the log file if the SSL channel to the TeamSite server fails.
Interwoven: Failed to get session string from server.
This message appears if the supplied username and password are valid, but no
TeamSite role is associated with the user. This message does not necessarily denote
an error if there are some SiteMinder users that are intentionally not given access to
TeamSite.
187

Appendix F
Root Access to TeamSite
TeamSite is system-level software that is tightly integrated with the operating system. There
are four main reasons why TeamSite runs as root:
" To be able to read configuration files that may be owned by other users.
" To be able to impersonate users to perform operations on their behalf.
" To access the TeamSite content stores that are normally set to read only
" To run critical helper programs to provide the TeamSite file system interface.
The following tables describe the TeamSite files that need to be owned by, executed by, or
setuid root:
Table 5: TeamSite Files Needing Root Access
Setuid root Comments

iw-home/httpd/iw-bin/iwcgi.cgi For the Set Home Page feature, needs to
write to iw-home/local/iwprofiles,
which is owned and writable only by root.
Also needs to impersonate users to copy
files on their behalf.
iw-home/httpd/iw-bin/ Needs to be able to do setuid/setgid to
iw_cgi_wrapper.cgi
iw-home/httpd/iw-bin/nph- impersonate users while running
iw_cgi_wrapper.cgi downstream CGI.
iw-home/httpd/iw-bin/iwmerge.cgi Needs to impersonate users to write files
on their behalf.
iw-home/httpd/iw-bin/ Needs to impersonate users to write files
iwfileupdownload.cgi
on their behalf.
iw-home/bin/iwgetldapusers This CLT is used within TeamSite Workflow
to get lists of users and roles when LDAP or
ActiveDirectory is used instead of TeamSite
.uid files.
iw-home/httpd/iw-bin/iwfsckcgi.cgi Needs to access the Content Store directory
and files underneath which are accessible
only by user root. Only root can run this
program, and it requires a password.
189
Root Access to TeamSite
Executed by root Comments

iw-home/bin/iwserver Needs to access the Content Store, which is
owned by root.
start scripts such as /etc/init.d/ Needs to load the wfs kernel module.
iw.server and the scripts in
iw-home/private/bin
iw-home/private/bin/iwfsfix Needs to access the Content Store, which is
iw-home/private/bin/iwfsck
owned by root.
These tools are intended for use only on the
advice of Interwoven Support or CSO staff.
These tools are not part of the day-to-day
operation of TeamSite.
iw-home/bin/iwconvert Needs to access the Content Store, which is
iw-home/bin/iwmigrate
iw-home/bin/iwcpwa owned by root.
iw-home/bin/iwcpfile These tools are related to the conversion of
pre-5.5 backing stores to the new high-
performance Content Store format.
iw-home/bin/iwwfconvert This tool converts in-process workflows
from pre-5.5 versions of TeamSite.
It reads the source backing store (for which
it needs to be root) and writes to the
destination Content Store.
Read by iwserver Comments

All TeamSite configuration files iwserver needs to be able to read TeamSite
configuration files, but they can be owned
by another user.
Other Comments
iw-home/httpd/iw-bin/iwbs.cgi These Content Store tools are not shipped
iw-home/httpd/iw-bin/iwbsdiff
iw-home/httpd/iw-bin/iwbsdir with setuid turned on. However, these tools
iw-home/httpd/iw-bin/iwbsls do need to be setuid root to operate
iw-home/httpd/iw-bin/iwbspeek properly.
These tools are intended for use only on the
advice of Interwoven Support or CSO staff.
These tools are not part of the day-to-day
operation of TeamSite.
Though most of the CGIs are installed by default with the read and write bits on, these CGIs
do not necessarily need to be world-readable. Though some of these CGI programs are
setuid root, they perform specific and limited functions. The CGIs contain no embedded
shell interpreters or similar software that allows general operations.

Appendix G
TeamSite Service Monitor
This appendix describes the TeamSite Service Monitor. The TeamSite Service Monitor is
comprised of a “watchdog” daemon that monitors the TeamSite server (iwserver). You
must purchase TeamSite Service Monitor in addition to the base version of TeamSite to use
the features described in this appendix.
Service Monitor Overview

The TeamSite Service Monitor uses a daemon known as the watchdog and a set of associated
tools and scripts to monitor the TeamSite server, detect process and power failures, log
failure events, and optionally take corrective action. After TeamSite Service Monitor is
installed and configured, it is transparent to end users, performing all user-visible
operations identically to the base version of TeamSite.
Note: The Service Monitor only monitors iwserver; it does not monitor any other
Interwoven services. Additionally, it does not monitor TeamSite in a cluster
environment.
You can configure the Service Monitor in several ways. For example, you can instruct it to:
" Shut down the TeamSite server and notify a specified system user that a power or
process failure was detected.
" Stop the TeamSite server after detecting a failure even if all post-failure system checks
are normal.
" Perform a different action depending on whether a power failure or a process failure
was detected.
" Perform any other Perl script-defined action automatically upon failure detection.
For any failure, you must execute a file system check (use the iwfsck CLT described in the
TeamSite Command-Line Tools Reference) to ensure that data inconsistencies have not been
introduced.
You can also turn off the Service Monitor completely, in which case the base version of
TeamSite continues to run.
191
TeamSite Service Monitor Components and Processes

The following flowchart shows the TeamSite Service Monitor components and processes.
See the section immediately following the flowchart for an explanation of each item.
Start
iwtock
Previous
No Run Diagnostics No Stop
shutdown
iw.powerfail OK? iwtock
normal?
Yes Yes
Start iwserver
Yes (Solaris)
iwserver No Run Diagnostics No Stop

running? iw.processfail OK? iwtock
Yes Yes (Windows)

Continue
monitoring
iwserver
Figure 16: TeamSite Service Monitor components and processes
The main TeamSite Service Monitor component is the iwtock watchdog daemon, which
starts the iwserver process and tracks iwserver execution for as long as the TeamSite
server is running. When iwtock first starts, it determines whether the previous TeamSite
shutdown was abnormal or normal. If it detects an abnormal shutdown, iwtock runs the
iw-home/ha/conf/iw.powerfail script, which can be configured either to stop iwtock or
to perform a variety of system checks or other actions as described in “Configuring
TeamSite Service Monitor” on page 193. If the system meets the passing criteria defined in
iw.powerfail, iwtock starts iwserver. If the system does not meet the passing criteria,
iwtock stops and iwserver is not started. All output from iw.powerfail is logged in
iwserver.log.

Installing TeamSite Service Monitor
If iwtock determines that the previous TeamSite shutdown was normal, it starts iwserver.
From this point on, iwtock continues to monitor iwserver. If at any time iwtock detects
that iwserver is not running and there is no evidence of an explicit shutdown, it assumes
that an unexpected shutdown or system interruption has occurred. In this situation, iwtock
runs the iw-home/ha/conf/iw.processfail script, which can be configured either to stop
iwtock or to perform a variety of system checks or other actions as described in
“Configuring TeamSite Service Monitor” on page 193. If the system meets the passing
criteria defined in iw.processfail, iwtock starts iwserver. If the system does not meet
one or more passing criteria, iwtock stops and iwserver is not restarted.
All output from iwtock, iw.powerfail, and iw.processfail is logged in iwserver.log.
Note: If iwserver attempts to spawn more than once within 30 seconds of initial startup
or a restart, iwtock will exit.
Installing TeamSite Service Monitor

Complete the following steps to install the TeamSite Service Monitor:
1. Log in as root.
2. Stop iwserver:
% /etc/init.d/iwserver stop
3. Copy the TeamSite Service Monitor installation file ha.x.x.x.BuildXXXX.tar.gz

from the distribution media into iw-home.
4. Uncompress the installation file:
% gunzip -c IWOVha-sol.x.x.x.BuildXXXX.tar.gz | (tar xvpf -)
This creates several HA-specific subdirectories in iw-home.

5. Go to iw-home/ha/install and run the iwinstallha command:
% iwinstallha
6. Restart iwserver:
Configuring TeamSite Service Monitor

Configuring TeamSite Service Monitor requires that you edit the iw.powerfail and
iw.processfail scripts to execute tasks that are relevant and specific to your installation.
The configuration procedures are described in the following sections.
193
iw.powerfail
The default iw.powerfail script shown here is shipped with TeamSite. In its current form,
it only logs its own name (iw.powerfail) when executed. It also contains a commented
example of how you could configure the script to run the iwsi program to send email to a
system administrator when the script executes. You can configure this script to perform any
action upon execution; the only requirement is that you use Perl syntax compatible with
Perl Release 5.00503. All results returned by iw.powerfail are logged in iwserver.log.
Note: Review the current best practices related to recovering from a failure that posted at
https://support.interwoven.com. For any failure, you must execute a file
system check (use the iwfsck CLT described in the TeamSite Command-Line Tools
Reference) to ensure that data inconsistencies have not been introduced.To force
iwtock to exit rather than start the TeamSite server after iw.powerfail executes,
specify an iw.powerfail exit value of 127. This feature is included for scenarios in
which TeamSite should not restart automatically following a power failure.
use File::Basename;
print( basename( $0 ) . "\n" );
#
# Use this script to execute processes that can clean up after a powerfail
# crash.
#
# This script is executed when the Watchdog daemon determines that the
# system was not taken down cleanly, and the daemon is itself beginning
# execution.
# Some of the things that might be tried:
# Run the iwfsck CLT
#
# You may also want to mail your system administrator at this point:
#
#use Mail::Send;
#$msg = new Mail::Send Subject=>'TeamSite problem', To=>'admin,root';
#$mfh = $msg->open;
#print $mfh "Please address TeamSite issues at your earliest convenience";
#$mfh->close;
#
# If you do not wish to continue bringing up the system, then exit this
# script with a 127.
# 127 indicates to the daemon that it is not to continue with the bringup.
#
#exit 127

Configuring TeamSite Service Monitor
iw.processfail
The default iw.processfail script shown here is shipped with TeamSite. In its current
form, it only logs its own name (iw.processfail) when executed. It also contains a
commented example of how you could configure the script to run the iwsi program to send
email to a system administrator when the script executes. You can configure this script to
perform any action upon execution; the only requirement is that you use Perl syntax
compatible with Perl Release 5.00503. All results returned by iw.processfail are logged
in iwserver.log.
Note: To force iwtock to exit rather than restart the TeamSite server after
iw.processfail executes, specify an iw.processfail exit value of 127. This
feature is included for scenarios in which TeamSite should not restart automatically
following a process failure.
use File::Basename;
print( basename( $0 ) . "\n" );
#
# Use this script to execute processes that can clean up after a TeamSite
# crash after the system has begun processing data.
#
# This script is executed when the Service Monitor daemon determines that
# the system was not taken down cleanly, and the daemon has already begun
# observing the execution of TeamSite. Some of the things that might be
# tried:
#
#
# You may also want to mail your system administrator at this point:
#
#use Mail::Send;
#$msg = new Mail::Send Subject=>'TeamSite problem', To=>'admin,root';
#$mfh = $msg->open;
#print $mfh "Please address TeamSite issues at your earliest convenience";
#$mfh->close;
#
# If you do not wish to restart the system, then exit this script
# with a 127. 127 indicates to the daemon that it is not to restart
# the server. The server will not restart at all.
#
#exit 127
195
Starting and Stopping iwserver Under Service Monitor

You can manually start and stop iwserver under the TeamSite Service Monitor just as you
would under the base version of TeamSite. See Chapter 4, “Managing the TeamSite Server”
for more information. On any list of active system processes, iwtock appears as iwperl
(you will not see a list entry called iwtock).
Uninstalling TeamSite Service Monitor

Complete the following procedure to uninstall the TeamSite Service Monitor and revert to
the base version of TeamSite.
Note: The following procedure deletes the entire ha subdirectory. If you plan to restart
TeamSite Service Monitor later, you should back up the contents of ha to a
different location before you start this procedure.
1. Log in as root.
2. Stop iwserver:
% /etc/init.d/iwserver stop
3. Go to iw-home/ha/install and run the iwuninstallha command:

% iwuninstallha
You will be prompted to confirm that you want to uninstall TeamSite Service Monitor.
Answer yes to continue uninstalling.
4. Restart iwserver after iwuninstallha finishes executing:
Related Documentation
See the iwsi documentation in TeamSite Command-Line Tools for more information about the
TeamSite Service Monitor.

Appendix H
Troubleshooting
This appendix contains miscellaneous information regarding a variety of troubleshooting

issues. In addition to the suggestions that follow, Interwoven’s Consulting Services and
Technical Support can assist you with any configuration issues you might encounter. You
can also check the Interwoven Support Knowledge Base at
https://support.interwoven.com.
Note: Reporting and Search both have troubleshooting sections in the chapters describing
those features.
Unexpected Server Shutdown

After an unexpected server shutdown (such as a power outage or system failure),
if the server does not start properly when the system is brought back up,
immediately contact Interwoven Technical Support.
Do not attempt to restart the server by manually modifying or deleting
Interwoven system files. Doing so may cause irreparable damage to the Content
Store.
Only run the iwfsfix CLT under the supervision of Interwoven Technical
Support. Conducting any of the suggested repairs without first confirming the
action with Interwoven is not recommended because it could result in
inadvertent damage to the Content Store.
Other Server Issues
NTCSFsdClaimASharedMemoryChannel: No shared memory communication
channel available message appears in Windows System Log.
The code is trying to get a buffer and is not successful. However, it retries and
succeeds. The workaround is to add the following registry setting HKLM \SYSTEM
\CurrentControlSet \Services \iwfsd \Parameters Value:
CoreCommRetryCount REG_DWORD 0x100
File operations on task files may not return clear warnings if the store in which
the task files reside is deactivated. If you attempt to perform an operation on a
file whose store is deactivated, one of the following messages may appear:
Internal Server Error
TeamSite FileEdit
Error:Call to sciLocateObjectWithVersionPath()returned an error
SCI Error
No archive found
TeamSite iwdirnav.cgi
Error:iwdirnav.cgi could not open path "/s1/main/WORKAREA/w1"
You should not disable stores if users are actively working on those stores.
197
Troubleshooting
You may see submit.cfg errors in iwconvert output. These errors are
harmless. In the output of iwconvert, you may see errors such as:
ERROR:no valid submit config file found in the current
configuration
(/data/iw-home/conf/events/submit.conf,
/data/iw-home/local/config/submit.cfg,/data/iw-home/config/
submit.cfg,
/data/iw-home/local/config/submit.cfg)(2)
ERROR:no valid autoprivate file found in the current
configuration
(/data/iw-home/conf/events/autoprv.txt,
/data/iw-home/local/config/autoprivate.cfg,
/data/iw-home/config/autoprivate.cfg,
/data/iw-home/local/config/autoprivate.cfg)(2)
Installing/Removing Programs
VisualFormat may not appear in the Add/Remove Programs on Windows.
(You should be aware that it may be listed as eWebEditPro.) If you install
VisualFormat on a Windows computer by running visualformatclient.exe,
you can uninstall the product from the Add/Remove Programs window in the
Control Panel. However, if you installed it from a Web page, no listing for
VisualFormat will be present in the Add/Remove Programs window.
Instructions on how to uninstall the software under these conditions can be
found at the following Web site: www.ektron.com//support/
ewebeditprokb.cfm?doc_id=1628.
When the TeamSite installation is started, the following warning is displayed:

“Cannot convert string ‘monotype-arial-regular-normal--*-140-*-
*-p-*-iso8859-1’ to type FontStruct”. The installation program
substitutes a font; therefore, this warning can be ignored.
Email
HTML format email notifications do not display correctly with Eudora 6.01 on a
Macintosh client; however, the email is still usable. The user can choose Open in
browser to see the email properly.
The Exchange 2000 server may corrupt the workflow emails. Use Exchange
2003.
Windows XP
On Windows XP with Internet Explorer 6.0, the VisualAnnotate toolbar may
issue a popup message indicating the toolbar is obscured even when it is visible.
Set the Don’t ask again field so you do not get this message repeatedly.
The VisualAnnotate toolbar does not automatically display on Windows XP.
Select View > Toolbars> Interwoven Visual Annotate to turn on the toolbar.
JVM
When using Internet Explorer 6, occasionally in ContentCenter Professional you
can edit a file but not view the source. In Internet Explorer 6, you can select
Tools > Internet Options > Advanced. Scroll to the Microsoft VM section and
turn off Java console enabled and JIT compiler for virtual machine enabled. Then
turn these two items back on. Another alternative is to use the Sun plug-in
instead of Microsoft JVM.

When editing a file in ContentCenter Professional, the editor goes to the
background and the Local File Manager displays. This applies when using a Sun
JVM plug-in instead of the browser’s built-in JVM in Windows.
IIS
Content may not refresh after an edit. The solution is to turn off caching in IIS, as
follows:
1. Run the Internet Services Manager (Start > Programs > Administrative
Tools > Internet Services Manager) and expand the icon for my computer.
2. Click Default Web Site.
3. Right-click on the iw-mount icon and select Properties.
4. In the properties dialog, select the HTTP Header tab.
5. Turn on the Enable Content Expiration check box and made sure that the
expiration setting is Expire Immediately.
VisualPreview/Local File Manager: When used with some editors, you may see
the “accessed by another process” message (does allow save). When you edit a file
using these editors through the VisualPreview tab, you may get the message “The
document name is in use by another application and cannot be accessed.” This
does not happen with NotePad. This a known IIS problem, which occurs because
IIS keeps a file open for a while after it is requested in an http transaction.
Workarounds are waiting for a while (20-30 seconds), not using IIS in
combination with VisualPreview (since normally VisualPreview accesses the file
just before it is being edited), or using a different Web server.
If a branch, directory, or filename contains .com or .exe, navigating to that
location results in 404 page not found error. This applies when using IIS on
Windows and is an IIS mechanism to prevent worms and viruses.
IIS caching can cause cached versions of files to be displayed during a preview
operation. If users do not see recent modifications when previewing documents
from My Local Files, turn off global caching from the IIS control panel. Select
the machine name, then select Action > Properties. In the Server Extensions
tab of the Properties dialog box, select Use Custom Settings from the
Performance drop-down menu. Then, click the corresponding Settings button.
Set In-memory document cache, Include file cache and Image file cache
each to 0.
199
Troubleshooting

Glossary
Administrator
The owner of a branch, responsible for the project being developed on it. An Administrator can
perform all the functions that an Author or an Editor can, and can also create and delete new
subbranches and workareas on his branch. Administrators exercise control over workflow by giving
workareas to editors and subbranches to other administrators.
Advanced File Merging

TeamSite can automatically merge two separately modified versions of a file, producing a new file
containing the changes made by both users. Advanced File Merging is completely automatic if the
edits were made to different parts of the file (non-conflicting edits).
approve
When an Editor approves a file returned by an Author, the file is submitted to the staging area.
Approving a file automatically unlocks it and removes it from the Author’s Task list.
assign
To lock a file for the use of a specific Author and attach comments. A list of assigned files displays in
the Author’s Task list. Editors can also view a list of files that they have assigned.
Attribute Search
A basic parametric search that involves single-level value-pairs AND/OR search criteria. The
supported operators for parametric search are: equal (=), less than (<), less than or equal (<=),
greater than (>), greater than or equal (>=), not equal (<>).
Author
A primary web content contributor with limited access to the TeamSite system, usually using
ContentCenter Standard. Authors can access, create, and modify web content through their
Editors’ workareas. An Editor can assign specific files to an Author, which will appear in the
Author’s Task list.
Autoprivate
The Autoprivate feature helps minimize clutter on the development server. Autoprivate
automatically identifies file types that should not be submitted to the staging area and marks them as
Private. These files typically include Microsoft temporary files (.TMP), various backup files
(.BAK), and Macintosh resource forks (.FRK).
201
branch
A path of development for a body of content developed and maintained by a team. Each branch
contains one or more workareas, a staging area, and a published edition and may contain
subbranches and previous editions.
casual contributor
A person who modifies or creates content using TeamSite, usually on an infrequent or sporadic basis.
“Contributor” is a generic term that does not designate any specific TeamSite role such as Author,
Editor, Administrator, or Master.
category
In TeamSite FormsPublisher, a category is a grouping of types of templates. Category directories are
the first division of the templatedata directory. Each category has its own directory, which
contains subdirectories for each type within it. An example of a category would be beverages,
which may contain tea, coffee, milk, and soda types.
collection
The metadata for a set of documents with optimized architecture for searching.
command-line tool (CLT)

TeamSite has many command-line tools that make TeamSite functionality available from the
command line. Consult the Command-Line Tool Reference.
command trigger
A type of command-line tool that can trigger scripts when specific TeamSite events occur. An
example is the use the iwatsub command trigger to trigger an event when files are submitted.
comment
A note attached to a file, directory, workarea, branch, edition, job, or task. Comments can be
attached to workareas, branches and editions when they are created. Comments can be attached to
files and directories when they are assigned, returned, rejected, locked or submitted. Global
comments can be set when these functions involve multiple files.
Compare
A function that displays a list of the differences between any two TeamSite objects. Objects that can
be compared include workareas, staging areas, or editions.
Composite search
An advanced search feature that allows multiple search criteria to be specified. These criteria can be
a mixture of full text, form entry, and metadata parameters.
conflict
Occurs when multiple users make changes to the same file in multiple locations, for example, when
a file has been changed in two different workareas.

conflicting edits
Occur when multiple users make changes to the same parts of the same file, producing two
versions of the file that cannot be automatically merged. Conflicting edits require users to specify
which individual changes will go into the merged version.
content
A set of information contained within a text document, vocabulary, file, or database record. See also
data record.
ContentCenter Professional
A user interface for experienced TeamSite users, technical users, or users who have some
familiarity with content management systems. It is intended for “power users,” and users who must
administer content development projects. It includes integrated administrative functions for easy,
contextual TeamSite administration and fully customizable menus, tabs, and more.
ContentCenter Standard
A user interface for business users—that is, non-technical subject matter experts and infrequent
users of a content management system. It includes an initial customizable “home page” containing
module UI components displaying areas for a user's tasks, favorites, work in progress, and forms,
wizards for common functions, and out-of-box email messages for workflow task notification.
contributor
A person who modifies or creates content using TeamSite. “Contributor” is a generic term that does
not designate any specific TeamSite role such as Author, Editor, Administrator, or Master.
data capture template

An XML file, datacapture.cfg, that defines the form used to capture data from content
contributors. A data capture template is associated with a category and type. The category and type
define the type of data required by the data capture template. The data that a content contributor
enters in a data capture template is saved on the TeamSite file system as an XML file in the form of a
data record.
data record
An XML file containing formatting information interspersed with data captured from a contributor or
through other means. A data record is named when a content contributor saves the record. Content
contributors can edit a data record by reopening it in the form that created it. Several different data
records can also be matched to a single presentation template to create one or many output files. Data
records can also be deployed to a database by Interwoven DataDeploy.
edition
A frozen, read-only snapshot of a branch of development. An edition contains a copy of all the files
in the staging area at the time it was published. New editions can be released to production servers
as complete, functional Web sites. Editions also serve as rollback points for projects in
development, and they provide permanent archives of the Web site for Site Rollback.
203
Editor
The owner of a workarea or workareas. Editors assign files to Authors, manage files, and edit and
create files, submit content to the staging area, and may create editions. Editors may have access to
workareas that they do not own, but they cannot assign files in these workareas.
form
The form generated by a data capture template. A contributor fills out a form to create a data record. A
form displays in the FormsPublisher window so that a user can enter and format data, select options,
and access menu items.
Form Entry
The information a user enters in a blank form. Form entry files are stored in locations selected
within the templatedata/form_category/form_type/data folder in the user’s workarea, and
are available to recall and use as necessary.
Form Entry Search

Ability to search on specified fields within a form entry.
form item
An element in a data capture template that defines a form field, such as a text field, text area, check
box, combo box, or option button.
FormsPublisher
A TeamSite module that allows you to configure the look and feel of your web pages. Use it to
generate forms used within ContentCenter for capturing data. For more information, consult
TeamSite FormsPublisher Developer’s Guide.
Full-text search
Ability to search by entering one or more keywords from any document and applying AND/OR
operators on the keywords.
Get Latest
A command that brings staging area content that is different from the workarea content into the
workarea.
history
A complete record of all changes that have been made to a file through time. A user can see the
complete history of a file by selecting it and selecting History from the View menu.
initial edition
The first edition on a newly created branch. The initial edition serves as the original source of
content for all workareas on a new branch. This edition may be empty, or it may be a copy of an
edition from another branch.
job
A set of interdependent tasks assigned to one or more people. All jobs are based on predefined
workflows, and each job is a specific instance of a workflow model. When a user starts a job based on

a workflow, the user specifies who should perform each task, and then initiates the job. The person
who is to perform each task is notified through the Tasks section of the ContentCenter interface
(and optionally through email) that there is a task to perform. After a task is completed, the job
proceeds to the next task in its sequence that was defined by the workflow. When all of the tasks in
a job are done, the job is complete.
locking
Restricting file access within a branch. Locking a file reduces the possibility of conflicting edits but
also reduces the team’s ability to work on files simultaneously. Every time a file is locked, the
version in the workarea is compared with the version in the staging area and the latest is taken
(although this behavior can be overridden). TeamSite supports three types of locking, or locking
models: Submit Locking, Optional Write Locking, and Mandatory Write locking. The locking
model is defined at the branch level by the Administrator.
main branch
The first branch created when TeamSite is installed. The Main Branch is owned by the Master user.
All branches in the TeamSite system are subordinate to the main branch.
Mandatory Write locking

A type of locking where users are required to lock a file in order to edit it. Until a user locks a file,
all files in his workarea are read-only. Taking the write lock allows only a single person to modify
the file at a given time, ensuring serial development and eliminating conflicting edits.
Master
The owner of the main branch. The Master user is responsible for the entire Web site. The Master
organizes the structure of the TeamSite system and coordinates the activities of all users, and can
also perform all functions on all branches.
merge
The process of reconciling conflicts between versions of a file that have been edited by two people.
The two versions can be merged in the staging area to produce a new version of the file,
incorporating changes made by both users. Merging can be automated with TeamSite’s Advanced
File Merging.
Metadata
There are 4 types of metadata: file properties, user-specified metadata, system-provided metadata
(such as FormsPublisher extended attributes), and derived metadata from Metatagger operations.
Navigation Window
The left-hand side of the TeamSite window, which allows you to navigate through TeamSite by
clicking on the underlined names of branches, workareas, staging areas, editions, or directories.
Optional Write Locking

A type of locking in which users can choose to lock a file to ensure no other users edit the file, even
within their own workareas. When a user locks a file, it becomes read-only to all other users.
205
Under the Optional Write Lock model, locking files ensures serial development of those files and
reduces the risk of conflicting edits.
Output File
A file that a user generates by combining form entries with a presentation template. The output file is
typically in HTML format for use as a Web page, although it can be other file types. The user can
generate output pages using any combination of form entries and presentation templates that the
ContentCenter developer has made available. Multiple output files can optionally be generated
using different presentation templates.
presentation template
A template that defines how form entries will appear when displayed. For example, a presentation
template could specify the size, color, and layout of a Web page.
A presentation template is populated with data from one or more of the following sources:
" Data record

" Queries to databases
FormsPublisher can be configured to populate any presentation template with any data record plus
additional information as required from a relational database.
A contributor can match a single data record with several presentation templates to create multiple
output files containing the same or similar information, each suitable for a different Web site, each
with a different look and feel.
Presentation templates can be used with component templates. A component template is a

presentation template nested within another presentation template. Multiple data records of the
same type can use a single presentation template to create multiple output files in the same format.
Preview
Viewing content prior to submitting, deploying, or generating an output file from it. Previewing
typically pertains to Web sites that being working on. For example, before beginning work on a
Web site, a user may preview it to assess its current look and feel. Previewing is also useful after
you have finished working on a Web site to ensure that your changes appear as you intended prior
to making the Web site publicly available. Previewing within FormsPublisher is limited to
displaying the output of the form being worked on using a specific presentation template.
Private
Within a workarea, a user can mark a file as Private, which prevents the file from being submitted to
the staging area if the file is a part of a workarea or directory that is submitted. It also prevents the
file from being copied to another workarea during a Copy To operation.
Public
The opposite of Private, the Public function removes the private marking on a file. All files are public
by default.

publish
The publishing of finished content to environments beyond the one where it was created. For
example, a user could create a press release from within ContentCenter, submit the final version for
approval and inclusion in the staging area, and then publish the finished version to a production
system that lets the general population access it. Not all ContentCenter users have the ability to
deploy content; permission to do so is controlled by the ContentCenter administrator.
publisher
An application that sends events to the Event subsystem.
Search Field Type

Available, indexed fields within the search project dictate the possible values for the user to search.
For example, a date field would provide a calendar for the use to select a date to be searched.
Search index
Search is enabled by building an index of searchable content and metadata.
Search Results
The returned set of assets that adhere to the specified criteria.
Site Rollback
The process of deploying a previous edition in place of the current Web site. Because TeamSite
editions are complete copies of the entire Web site at the time of publication, they can be
referenced to revert to prior versions of files, directories, or the entire Web site.
staging area
The area where users integrate the contents of their workareas. Users submit read-only copies of
files from their workareas to the staging area to integrate with other contributions, and test the
integrity of the resulting Web site.
subbranch
A branch subordinate to a major branch. To separate development efforts among teams or team
members, an Administrator can create subbranches. The subbranch receives its own unique staging
area and workareas and generates its own editions. Editions published on a subbranch can be
integrated back into work on the higher branch, or released as stand-alone Web sites.
submit
The act of transferring Web site content from a workarea to the staging area. After a user performs
an action on a file, the user must submit the file so that it can be approved and integrated into the
staging area. For example, if a user edits a file in a workarea, the file must be submitted so that the
changes can be reviewed and promoted to the staging area when approved. When a user’s work
reaches the staging area it is integrated with the work of other contributors into publishable,
deployable content.
Submit Locking
A type of locking in which users can choose to lock a file to insure that their changes are submitted
to the staging area. While a file is locked, other users can edit their own version of the locked file
207
within their workarea, but they cannot submit to the staging area. Once the lock holder has
released the file lock, other users can merge their modifications with the new file version.
subscriber
An application that registers with the Event Subsystem to receive events.
tag
When users tag a file, they specify additional descriptive information that remains with the file
indefinitely (this information is also called metadata). For example, a user could tag a press release
file by adding a title such as “Press Release,” key words such as “July” and “Acquisition,” a region
such as “California,” and so on. These tags do not appear in the text of the file, so they are not
displayed when the file is viewed through a browser or editing application. Instead, they appear
when you view the file’s tags, use search functionality, or use a product such as Interwoven
MetaTagger.
task
A unit of work performed by a single user or process that is part of a job. Each task in a job is
associated with a particular TeamSite workarea and carries a set of files with it. There are two types
of tasks: individual and group.
" Individual tasks are assigned to a specific person. When an individual task is assigned to
a user, it appears under Tasks > My Tasks view in the Workflow tab. From there the
user can take whatever action is necessary to complete the task.
" Group tasks are assigned to a group of people, any one of whom can perform the task.
(Groups are defined and maintained by ContentCenter administrators and other
maintainers of your ContentCenter system.) If a group task is assigned to your group, it
appears under the Workflow tab > Tasks > Unassigned Group Tasks view. From there a
user can take ownership of the task and complete it.
After you perform a task, the job proceeds to the next task in its predefined sequence. When all of
the tasks in a job are done, the job is complete.
Task list
The Task list shows the user which tasks and jobs he is responsible for and allows the user to do the
necessary work to complete the tasks.
task transition
Selecting a task transition moves the job along the workflow process by activating successor task(s).
template
A file that specifies attributes of another file, such as look and feel. When you create a file, you can
choose to base that file on a template.
templating.cfg
A configuration file that controls what presentation templates are available to TeamSite users, and in
what category they appear. It is located in the <iw-home>/local/config/ directory.

type
A division within a category in FormsPublisher. Each type has a corresponding data capture template so
that users can enter information for that type. Examples of types could be tea, coffee, milk, and
soda, which are part of the beverages category.
unlock
To remove a lock from a file. If an Editor has locked a file, the branch Administrator or Master user
can also remove the lock. The Master user can remove any lock from any file.
user
A TeamSite Author, Editor, Administrator, or Master.
Version
A numbered iteration of a content file. Whenever users submit a file and it is approved,
ContentCenter saves the new version of the file containing the changes and retains the original, pre-
edited version. Because previous versions are not deleted, users can view all previous versions of
the file, see when and by whom each version was modified, and if necessary revert the current file
back to an earlier version. Note that versioning only occurs when a file is submitted to the staging
area. If a user just edits a file and saves the changes, a new version is not created until the file enters
the staging area.
VisualPreview
A tab that displays on an output page that allows you to perform various TeamSite functions.
Web site
A generic term, meaning a set of interrelated files viewed through a browser. In TeamSite, the
term “Web site” generally refers to all the contents on a branch of development, though these may
be a superset or a subset of an organization’s actual Web site.
workarea
A virtual copy of a Web site, which may be worked on independently without affecting the actual
site or the work of other contributors. A workarea can be owned by a single user or a number of
users together. Editors and Administrators can own workareas, but Authors cannot.
workflow
A sequence of tasks that can be assigned to one or more people. For example, a workflow could
define three tasks: to edit some text, to add an image, and to review the work. Whenever users
start a job, it must be based on a predefined workflow. Workflows are defined by ContentCenter
administrators and other maintainers of the ContentCenter system. See also “workflow model,”
“job,” and “task.”
workflow model
A general workflow configuration that can be used repeatedly. Each workflow model describes a
process which may include user tasks and a wide variety of automated tasks.
209
Index
Symbols autoprivate.cfg
.uid files, location of 55 about 21, 143
encoding 32
A format 30
absolute paths 125 location 30, 143
access sample 32
files read by iwserver 190 special characters 31
privileges, to TeamSite 53 available_templates.cfg 40
required for root 189
to files 53 B
ACLs backup Content Stores 139
reporting 159 backups
adding multiple stores 140
users to TeamSite 53, 55 of workareas 139
Administrators strategies 141
abilities 60 branch_default_perm 67
about 54 branch_security 66
defined 16, 201 branches
anonymous binds 71 defined 13, 202
application variables 164 indexing 80
assigning files 16 locking models on 28
attributes permissions 59
filtering 72 read access 66
in LDAP schemas 69 remappings, configuring 126
authentication searching 81
external file 67 security 66
LDAP 67 structure 20
local 67 browsers
PAMs 67 clearing cache 21
password 53
roles 67 C
setting type 67 cache size 35
users 67 caching 199
Authors captured subexpression 166
abilities 60 changing
about 54 file attributes, on submission 72
defined 16, 201 group ownership of workareas 64
Autoprivate TeamSite file locations 49
defined 30, 201 charset parameter, content encoding 179
matching
filenames 31
patterns 31
211
checking PAMs 69, 70
disk space usage 50 proxy server 125
for multiple servers 44 reporting 149
request handling 44 restarting after changes 21
server status 43 RPC threadcount 36
chgrp command 64 rule sets for metadata capture 110
CLT search 81
iwconvert output 198 Submit and Update logs 30
CLTs submit filtering 72
index and search 98 throughput monitors 37
iwgetelog 46 user authentication 67
iwgetlog 46 user interface 25
iwgettrace 46 web server uid 65
iwgroup 58 conflicting edits
comments defined 203
defined 202 conflicts
compare_search_limit 30 defined 202
comparing conserving disk space 51
defined 202 Consulting Services 197
configuration files Content Store 13
available_templates.cfg 40 backing up 139, 140
iw.cfg 21 deactivated 197
list of 143 freezing 38
locations 49 ContentCenter
configuring localized interface 178
Autoprivate 30 ContentCenter Reporting error messages 159
branch and workarea security 66 content-provider user role 17
branch remappings 126 conventions
cache size 35 notation 9
Content Store freezes 38 creating
Crystal Reports 158 workareas 54
default permissions creating editions 16, 66
on files 67 customer_webserver_host 125
different web servers 133 customer_webserver_port 125
disabling Editor edition creation 66
encoding of text files 179 D
external remappings 133 data record
field mapping 89 defined 203
file locations 49 printing 41
file system threadcount 36 data_root 40
group remapping 65 database schema 154
Hopi 36 database, LDAP 69
IP addresses 48 datacapture.cfg
iw.cfg 21 about 105
LDAP 69 annotated example
lock behavior 29 database element 116
main branch 29 DATE datatype 117
metadata capture 107 instance 117
options in iw.cfg 21 metadata identifier 116

rule identifier 116 domain_list 72
UTF-8 encoding 116 DTD
validation-regex 117 datacapture.cfg 110
configuring 110 metadata-rules.cfg 107
DTD 110
location of 105 E
datacapture.cfg.example 114 editions
db2_schema 155 allowing Editors to create 66
debug_event_handler 75 creating 16, 66
debug_output 26 defined 14, 203
debugging deleting 50
proxy server configuration 138 deleting indexed 99
submit filtering 75 see also publishing editions
default Submit logs 51
file permissions 67 editor_publish 66
user authentication 67 Editors
delete_jobs_on_complete 149 abilities 60
deleting about 54
branches 52 defined 16, 204
editions 50 disabling edition creation 66
indexed edition 99 email
device drivers corrupted 198
kernal 45 domains 26
directories incorrect display 198
permissions 59 mapping files 26
directory structure servers 26
copying 40 settings, for workflow 26
directory_default_perm 67 tasks 26
disabling email_mapping_file 26
VisualPreview 25 Embedded Failsafe 41
disk space enabling
checking usage 50 VisualPreview 25
compression 50 encoding 27
conserving 51 charset parameter 179
file system mount 19 file_encoding.cfg 172, 179
low 38 html files 161
managing 50 IANA preferred names 171
moving the Content Store 52 Merge tool 171
recovery 50 META tag 179
removing old versions 52 setting in iw.cfg 27
removing unused branches 52 Source Differencing tool 171
usage 50 specifying 179
disklow_knodes 38 text editors 170, 180
disklow_mbytes 38 text files 161
disklowpercent 38 Unicode 177
document root UTF-8 170, 177
configuring 126 valid charsets 171
defined 126 visual differencing 172
mapping 126 vpaths 161
213
environment variables, LANG 39 datacapture.cfg.example 110, 114
errata 10 db2_schema 155
error messages default permissions 67
reporting 159 editing 199
event subsystem 33 encoding 21, 161
configuring 34 FieldMapping.xml 89
events 33 file_encoding.cfg 21, 161, 172, 179
publishers 33 histories
subscribers 33 defined 204
event_log_size 30 iw.cfg 40
events log iwevents.log 46
locating 46 iwinstall.log 45
example templating environment 39 iwjoberrors.log 47
copying 40 iwmetadata.cgi 105
extended attributes 107 iwprocessd.log 47
modifying 27 iwprocoutput.log 47
search 99 iwserver.log 46
external remappings, configuring 133 iwtrace.log 44, 46, 47
log 45, 47
F mdc_dd.cfg 116
failover see proxy server metadata-rules.cfg 105, 107, 108
FieldMapping.xml file 89 modification time 26
file OpenAPI configuration 48
timestamp 27 openapi.cfg 48
file system pam.conf 70
mount 19 permissions 59
threadcount 36 private 30
file system threadcount sample metadata-rules.cfg 108
configuring 36 sample submit.cfg 77
file_default_perm 67 search.properties 81
file_encoding.cfg setting permissions on 54
content encoding 179 standardFields.xml 95
default location of 21 submit.cfg 72
defined 161 submitting locked 29
Merge tool 171 tables.xml 154
sample file 172 tsgroups.xml 58
Source Differencing tool 171 tsreport.xml 149
UTF-8 170 virtual 20
valid encodings 171 workflow log 47
visual differencing 172 filtering, on file submission 72
VisualPreview 171 finding the installation directory 45
files font message 198
access to 53 force_EA_mod_times 27
assigning 16 freezing the Content Store 38
available_templates.cfg 40 fs_threadcount 36
changing attributes of 72 full_submitlog 30
comparing 30 full_updatelog 30
configuration 21, 161 fully qualified paths
datacapture.cfg 105, 110 see proxy server

G branch_security 66
generating new encryption keys 70 changing the templating directory 40
global_default_map 126 compare_search_limit 30
groups configuration options 21
creating 64 customer_webserver_host 125
files 55 customer_webserver_port 125, 126
membership 64 data_root 40
NFS limitations 65 debug_output 26
remapping 65 delete_jobs_on_complete 149
TeamSite 58 directory_default_perm 67
disklow_knodes 38
H disklow_mbytes 38
histories domain_list 72
defined 204 editor_publish 66
Hopi configuring 36 email_mapping_file 26
host headers, remapping encoding 27
see proxy server encoding setting 27
event_log_size 30
I file_default_perm 67
IANA charset names 171 force_EA_mod_times 27
index CLTs 98 fs_threadcount 36
index manager 79 full_submitlog 30
configuring 81 full_updatelog 30
inode count 38 host 28
installation directory, locating 45 iwproxy_host 125
Intelligent File System 19 iwproxy_port 125
intermediate variables 164 ldap_cafile 68
internationalization ldap_dnbase 68
browser behavior 180 ldap_key 68
encoding setting in iw.cfg 27 ldap_port 68
file_encoding.cfg 161 ldap_pwd 71
IANA charset names 171 ldap_roles 69
iw.cfg settings 38 ldap_server 68
recommendations 179 ldap_ssl_port 68
regex_map 170 locating 144
server_locale setting 38 maildomain 26
text editor encoding 180 mailserver 26
Unicode 177 main_group 57
UTF-8 170, 177 main_lock_model 29
VisualPreview 161 main_owner 57
vpath encoding 161 maintaining preview files 40
Interwoven Merge tool 161 map_secondary_to_primary_gid 66
invalidating user sessions 70 old_mod_times 26
IP addresses, changing 48 only_lock_owner_creator_submits 29
iw.cfg 38, 41, 71 pam_do_acct_mgmt 69
about 21 pam_service 71
and the proxy server 126 pretty_print_dcrs 41
authentication section 67 preview_history_limit 41
branch_default_perm 67 printing data records 41
215
rpc_threadcount 36 J
server_locale 38 Java servlet engine 28
servlet_port 28 jobs
setting ports 28 defined 18, 204
show_user_list 75
specifying preview directory 41 K
thruputmonitoring 37 kernal device driver 45
use_mapping_file 26
webserver_uid 65 L
workarea_default_perm 67 LANG environment variable 39
workarea_security 66 languages, browser behavior 180
iw.openapi 48 LDAP 70
iwckrole 56 68
iwevents.log 46 and operating system authentication 70
iwfsshrink anonymous binds 71
running 51 authentication 67
iwgetelog 46 configuring 69
iwgetlog 46 database 69
iwgettrace 46 modifying schemas 69
iwgroup 58 OpenAPI 70
iwinstall.log 45 schemas 69
iwjoberrors.log 47 servers 67
iwmetadata.cgi 105 TeamSite role authentication 67
iwprocessd 47 user authentication 67
iwprocessd.log 47 ldap_account 71
iwprocoutput.log 47 ldap_cafile 68
iwproxy ldap_dnbase 68
configuring 125 ldap_key 68
debug option 138 ldap_port 68
iwwebd 123 ldap_pwd 71
performance considerations 128 ldap_roles 69
SSL support 123 ldap_server 68
iwproxy_host 125 ldap_ssl_port 68
iwproxy_port 125 listener 80
iwserver Local File Manager
checking 43 localized GUI 178
locating 45 locales
log file 46 native 38
monitoring 191 TeamSite server setting 38
starting 43 locations
iwserver.log 46 installation directory 45
iwsessionkeygen 70 iw.cfg 144
iwstat 47 roles files 145
iwtrace.log 44, 46, 47 TeamSite files
iwwebd 123, 128 changing 49
iwwfs.log 45

locking Mandatory Write locking
configuring submits 29 defined 205
defined 205 map_secondary_to_primary_gid 66
in workareas 29 Masters
on the main branch 29 abilities 60
types of 28 about 16, 54
log files defined 205
contents of 30 mdc_dd.cfg 116
event 46 memory
installation 45 shared 197
iwevents.log 46 Merge tool 161, 171
iwinstall.log 45 merging files
iwprocessd 47 defined 205
iwprocessd.log 47 META tag 179
iwprocoutput 47 metadata capture
iwprocoutput.log 47 about 103, 104
iwserver.log 46 components 105
iwtrace.log 46 configuration files 105
list of 45 configuring
reviewing 45 appearance 105
server 46 names 105
submit 30, 51 rules 107
trace 46 DTD 107, 110
update 30 extended attributes 107
workflow 47 form 110
log size 30 initiating from within a job 121
logging required input 105
in results of 107
authentication 53 rule sets 110
out schematic 106
Crystal Enterprise 159 validating input 105
users 70 workflow 120
login metadata search
names 55 about 103
low disk space 38 metadata-rules.cfg
low inode count, detecting 38 about 105
configuring 107
M DTD 107
macro expansion 76, 77 examples 108
maildomain 26 location of 105
mailserver 26 rule identifier 108
main branch sample file 108
defined 205 UTF-8 encoding 108
locking model 29 vpath identifier 108
ownership 57 modification time 26
main_group 57 monitoring
main_lock_model 29 iwserver 191
main_owner 57 system status 37
mounting the TeamSite server 45
217
mssql.xml 155 paths
multibyte characters absolute 125
browser behavior when interpreting encoding 180 relative 125
multiple servers 44 resolving see also proxy server
MultiStore performance monitoring 37
backing up 140 permissions
mysql_schema.xml 155 branch 53, 59
directory 59
N file 53, 54, 59
Navigation Window required for actions 58
defined 205 types of 58
new users, adding 53 workarea 53, 59
NFS, group limitations 65 port number
notation conventions 9 proxy server 125
servlet 28
O web server 125
od-admin user role 17 pretty_print_dcrs 41
od-user user role 17 preview
old_mod_times 26 maintaining files 40
only_lock_owner_creator_submits 29 specifying directory for 41
OpenAPI preview_history_limit 41
configuration file 48 preview_system_directory 41
documentation 48 private
LDAP 70 defined 206
manually starting and stopping 48 private files 30
obsolete startup script 48 proxy server
server about 123
about 48 configuring
servlet engine 48 applying changes 124, 125
starting and stopping 48 basic operation 125
verifying 48 overview 123
Optional Write locking to use different webservers 133
defined 205 debugging 138
oracle_schema.xml 155 document roots 128
ownership of workareas, changing 64 external remappings 133
failover 136
P fully qualified paths
PAM Internet Explorer 129
account management 69 resolving 128
and TeamSite 69 server configuration 129
host header remappings 135
configuring 69, 70
host name 125
defined 67
port number 125
third-party modules 71
redirecting TeamSite views 131, 132
pam.conf 70
relative and absolute paths 125
pam_do_acct_mgmt 69
remapping document roots
pam_service 71
passwords 53 rules of precedence 123
SSI remapping 136
limitations 54
setting 55

public files
defined 206 adding users to 55
publishing locating 145
defined 207 location of 55
publishing editions 16 introduced 54
TeamSite 53
R root access
RCS macro expansion about 189
about 76 files executed by root 190
enabling 77 files setuid root 189, 190
reconfiguring IP address 48 required for TeamSite 189
recovering disk space 50 RPC threadcount, configuring 36
redirecting TeamSite views see proxy server rpc_threadcount 36
regex_map rule sets, configuring 110
element 161, 163
illustrated 161 S
internationalization 170 SCE
introduced 161 see VisualPreview
regular expression syntax 164 schemas, LDAP 69
UTF-8 170 search
variables 164 CLTs 98
regular expressions error codes 100
about 9, 73 finding documents 97
case-sensitivity 164 purposes 79
expression engine 164 submitted files 80
file encoding 161 search manager 79
in regex_maps 164 configuring 81
in Submit filters 73 search query 81
relative paths 125 search.properties file 81
see also proxy server server
remote contributors 123 LDAP 67
removing load, monitoring 47
users 55, 56 locales 38
reporting mount, verifying 45
configuring 158 multiple 44
files 154 operations
modules 148 verifying 43
overview 147 resources
request handling 44 disk space 50
resolving path names see proxy server managing 49
starting and stopping 48
restart server 197
status, checking 43
reviewing TeamSite logs
log files 45 server events 152
server log
overview 45
roles location 46
server mount
authenticating with LDAP 67
verifying 45
defined 15
server shut down
unexpected 197
219
server_locale setting 38 submit.cfg
Service Monitor about 21, 72
about 191 format of 72
components 192 location 72
configuring 191, 193 sample 74, 77
installing 193 submitting
iw.powerfail 192, 194 defined 207
iw.processfail 193, 195 system information
iwtock 192 monitoring 37
logging 194, 195
starting and stopping the server 196 T
uninstalling 196 tables.xml 154
servlet Tagger GUI 103
engine 28 localizing 119
port 28 tasks
servlet_port 28 defined 18, 208
settings email 26
email, for workflow 26 ownership 59
encoding 27 states 18
server_locale 38 transitions
shared defined 208
workareas 55 TeamSite
Site Rollback architecture 19
defined 207 configuration files 143
Source Differencing tool 161, 171 file locations, changing 49
SSIs, remapping see proxy server groups 58
SSL support 123 proxy server
staging area iwwebd 123
defined 14, 207 overview 123
standardFields.xml file 95 see also proxy server
starting TeamSite server 43 roles 53
stopping TeamSite server 43 server
subbranches answering requests 44
defined 207 mounting 45
submit process 44
starting 43
changing file attributes 72 stopping 43
filtering Service Monitor 191
debugging 75 UNIX permissions 59
introduced 72 user roles 54
RCS macro expansion 76, 77
sequence of events 73 web daemon 123
locked files 29 TeamSite server
log file 30, 51 resetting 44
monitoring for indexing 80 restarting 43
Submit locking stopping 43
defined 207 TeamSite Templating, defined
see also Using and Configuring TeamSite Templating

Technical Support 197 users
templatedata directory adding 55
copying to workarea 40 authentication
templates re-encrypting 70
defined 208 types of 67
templates.cfg using LDAP 67
about 21 defined 209
location 144 invalidating sessions 70
templating directory removing 55, 56
changing 40 roles
templating environment about 54
example 39 Administrator 54
text editor encodings 170, 180 Author 54
checking 56
throughput monitors 37 content-provider 17
thruputmonitoring 37 Editor 54
timestamps 26 Master 54
trace log od-admin 17
debugging information 75 od-user 17
location 46 permitted actions 58, 60
troubleshooting 197 UTF-8
Content Store 197 about 177
email 198 file_encoding.cfg 170
IIS 199 recommendations 179
iwconvert 198 regex_map 170
JVM 198, 199
navigating 199 V
overview 49 variables
removing VisualFormat 198 application 164
server shut down 197 captured subexpression 166
shared memory 197 intermediate 164
Unix installation 198 naming convention 165
view file source 198 regex_map 164
VisualAnnotate 198 verifying server mount 45
Windows XP 198 versions 30
tsgroups.xml 58 viewing
tsreport.xml 149 branches and workareas 66
virtual files 20
U VisualFormat
Unicode 177 removing software 198
UNIX permissions 59 VisualPreview
use_mapping_file 26 disabling 25
user events 152 enabling 25
user interface configuration 25 encoding of text files 161
file_encoding.cfg 171
localizing 178
toolbar 25
vpaths, encoding mappings 161
221
W workflow models
watchdog 191 defined 209
web browsers, interpreting encoding 180 Write locking
web content, specifying encoding 179 see also Optional Write locking, Mandatory Write
web daemon locking
about 123
configuring 123, 125 X
setting defaults 28 XML
web servers about 9
configuring 133 datacapture.cfg 110
host name 125 metadata-rules.cfg 107
plugins 124 regex_map language 161
port number 125 special characters 168
starting and stopping 124
uid 65
Web site development 14
webserver_uid 65
workarea_default_perm 67
workarea_security 66
workareas
changing group ownership 64
creating 54
defined 14, 209
locking files in 29
permissions 59
read access 66
security 66
shared 55
workflow
defined 209
jobs
defined 18
log file 47
metadata capture 120
models
and jobs 18
assign-edit-approve 17
defined 17
query events 149
tasks
defined 18
specifying files in 120
workflow events 153
workflow log
locating 47

Ts 650 Admin Unix

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ts 650 Admin Unix

Hochgeladen von

Copyright:

Verfügbare Formate

TeamSite®

Interwoven, TeamSite, Content Networks, OpenDeploy, MetaTagger, DataDeploy, DeskSite, iManage,

Chapter 1: TeamSite Overview 13

Chapter 2: Configuration File Overview 21

Chapter 3: Configuring the TeamSite Server 25

Chapter 4: Managing the TeamSite Server 43

Chapter 5: Managing TeamSite Access 53

4 TeamSite Administration Guide

Chapter 6: Configuring Interwoven Search 79

Chapter 7: Configuring Metadata Capture 103

Chapter 9: Backing Up TeamSite 139

6 TeamSite Administration Guide

Appendix B: Configuring Reporting 147

Appendix C: Specifying Content Encoding 161

Appendix E: Integrating with SiteMinder 183

Appendix F: Root Access to TeamSite 189

Appendix G: TeamSite Service Monitor 191

Appendix H: Troubleshooting 197

8 TeamSite Administration Guide

Convention Definition and Usage

Click Edit File in the Button Bar.

The iwextattr command-line tool allows you to set and look

is the path to the main TeamSite configuration file, iw.cfg, which is

The default path for TeamSite Search is:

Online Documentation Errata

10 TeamSite Administration Guide

What’s in This Manual

14 TeamSite Administration Guide

TeamSite Process Time

TeamSite User Roles

These roles are described in detail in the sections that follow.

An Administrator is the supervisor of the project being developed on his branch.

16 TeamSite Administration Guide

Figure 2 is a diagram of a very simple assign-edit-approve workflow model. Email is sent to

Editor Task: Task: Task:

Reject Task: Approve Task:

Figure 2: Assign-edit-approve workflow model

Reject Task: Approve Task:

Figure 3: Example of a job workflow

18 TeamSite Administration Guide

TeamSite Content Server Client Computer

TeamSite Command command

Understanding the TeamSite File System

A simple TeamSite file system structure is shown in the following graphic:

WORKAREA STAGING EDITION development

Figure 5: TeamSite file system structure

Each branch contains three system-generated directories:

20 TeamSite Administration Guide

Configuration File Overview

A few settings are configured in the following files:

Configuration and customization of the ContentCenter interfaces is done through the UI

To edit any of the settings:

22 TeamSite Administration Guide

24 TeamSite Administration Guide

Configuring the TeamSite Server

Configuring User Interface Functionality

Enabling and Disabling VisualPreview

The [iwproxy_smartcontextedit_allowed] section begins with one _default line,

Lines in the [iwproxy_smartcontextedit_allowed] section are order-dependent. In

Configuring Email Settings

Specifies the domain (for example, maildomain=Interwoven.com)

Configuring Server Functionality