TeamSite 7.3 Admin Rev2 en
TeamSite 7.3 Admin Rev2 en
TeamSite 7.3 Admin Rev2 en
Administration Guide
Version 7.3
Document Revision 2
08 February 2013
Copyright Notice
Notice
This documentation is a proprietary product of Autonomy and is protected by copyright laws and international treaty. Information in this
documentation is subject to change without notice and does not represent a commitment on the part of Autonomy. While reasonable efforts have
been made to ensure the accuracy of the information contained herein, Autonomy assumes no liability for errors or omissions. No liability is
assumed for direct, incidental, or consequential damages resulting from the use of the information contained in this documentation.
The copyrighted software that accompanies this documentation is licensed to the End User for use only in strict accordance with the End User
License Agreement, which the Licensee should read carefully before commencing use of the software. No part of this publication may be
reproduced, transmitted, stored in a retrieval system, nor translated into any human or computer language, in any form or by any means,
electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of the copyright owner.
This documentation may use fictitious names for purposes of demonstration; references to actual persons, companies, or organizations are
strictly coincidental.
Acknowledgments
MediaBin 8 uses Sea Dragon Ajax Code provided by Microsoft Corporation for Deep Zoom feature. (License: http://
gallery.expression.microsoft.com/site/SeadragonAjax/eula?licenseType=None)
08 February 2013
Contents
Figures ............................................................................................................................................13
Tables ..............................................................................................................................................15
About This Document ...............................................................................................................17
Documentation Updates...............................................................................................................17
Conventions .................................................................................................................................19
Autonomy Customer Support .......................................................................................................21
Contact Autonomy........................................................................................................................22
Part 1 Introduction
Chapter 1
TeamSite Overview ................................................................................................................... 25
TeamSite Elements ......................................................................................................................25
Content Stores ......................................................................................................................25
Branches ..............................................................................................................................26
Workareas ............................................................................................................................26
Staging Areas .......................................................................................................................26
Editions .................................................................................................................................27
User Roles ...................................................................................................................................28
Reviewer ...............................................................................................................................29
Author ...................................................................................................................................29
Editor ....................................................................................................................................29
Administrator .........................................................................................................................29
Master ...................................................................................................................................30
WorkflowUser .......................................................................................................................30
WorkflowAdmin .....................................................................................................................30
Contents
Chapter 2
Configuration File Overview ................................................................................................. 39
The iw.cfg File ............................................................................................................................. 39
Location of iw.cfg ................................................................................................................. 40
The iw.cfg File Options ......................................................................................................... 41
Additional Configuration Files ..................................................................................................... 46
Contents
Chapter 4
Manage the TeamSite Server ................................................................................................ 75
Verify Server Operation................................................................................................................76
Start and Stop the TeamSite Server.............................................................................................77
Check for Multiple Servers ...........................................................................................................78
Check Request Handling..............................................................................................................78
Verify the Server Mount................................................................................................................79
Locate the Installation Directory ...................................................................................................80
Review TeamSite Log Files..........................................................................................................80
WFS Log ...............................................................................................................................80
Installation Log ......................................................................................................................81
Server Log ............................................................................................................................81
Trace Log .............................................................................................................................81
Events Log ............................................................................................................................81
Workflow Log ........................................................................................................................82
Windows Event Viewer .........................................................................................................83
Monitor the Server Load...............................................................................................................83
Reconfigure iwwebd to Recognize a New IP Address..................................................................84
Contents
Chapter 5
Work with Branches ................................................................................................................. 93
Overview ..................................................................................................................................... 94
Control Branch Ownership and Administration ............................................................................ 94
Create Branches ......................................................................................................................... 96
Integrate Content From Different Branches ................................................................................ 97
Manage Branches ...................................................................................................................... 98
Work with Branch Properties ....................................................................................................... 99
View Branch Users and Roles .................................................................................................... 99
Chapter 6
Manage TeamSite Access.................................................................................................... 101
Access Considerations .............................................................................................................. 101
Working with Permissions.......................................................................................................... 103
Workarea Access ............................................................................................................... 109
Branch and Workarea Security .......................................................................................... 109
Default Permissions ........................................................................................................... 110
View File Permissions ........................................................................................................ 110
Share TeamSite Assets using Windows Groups ........................................................................111
Group Usage with Native Mode Active Directory ................................................................ 112
Group Usage for Larger AD Networks ................................................................................ 113
Manage Windows Groups for Best Performance ............................................................... 114
Enable the User/Group/Role Disk Cache................................................................................... 116
Disable Group Nesting ....................................................................................................... 116
Enable the ADSI Debug Flag ............................................................................................. 116
Additional Tools for Debugging .......................................................................................... 117
Operate System Group Membership ......................................................................................... 117
Change Group Ownership of Workareas ............................................................................ 118
Example ....................................................................................................................... 119
Web Server Group/UID ...................................................................................................... 119
Group Remapping .............................................................................................................. 120
Contents
Chapter 7
Set Up TagUI .............................................................................................................................. 145
TagUI Features ..........................................................................................................................146
Using TagUI Rulesets ................................................................................................................146
TagUI Form Design ....................................................................................................................147
Configure TagUI.........................................................................................................................149
Map to Rulesets ..................................................................................................................149
Adjust Server Timeout ........................................................................................................152
Tag Large Numbers of Files ...............................................................................................152
Control the Search Function ...............................................................................................153
Revert to MetaData Capture Tagging .................................................................................153
Create Rulesets ........................................................................................................................153
Contents
Chapter 8
Configure the TeamSite Web Daemon and Proxy Server ....................................... 171
About the TeamSite Web Daemon ............................................................................................ 172
About the Proxy Server.............................................................................................................. 172
Apply Changes to Proxy Configuration ............................................................................... 174
Configure TeamSite Web Daemon and Proxy Server Operation ............................................... 174
Resolve Relative and Absolute Paths ................................................................................ 175
Document Roots ................................................................................................................ 176
Resolve Fully Qualified URLs .................................................................................................... 178
Redirect Fully Qualified URLs.................................................................................................... 178
Configure the Proxy Server to Redirect Fully Qualified URLs ............................................. 179
Configure your Web browsers to Use the TeamSite Web Daemon .................................... 179
Redirect TeamSite Views to Different Areas ............................................................................. 181
Using iwproxy_preconnect_remap .................................................................................... 181
Using iwproxy_preconnect_redirect .................................................................................. 182
Configure TeamSite to Use Different Web Servers.................................................................... 183
Configure External Remappings ................................................................................................ 183
Using iwproxy_preconnect_remap ..................................................................................... 184
Using iwproxy_external_remap .......................................................................................... 184
Host Header Remappings ......................................................................................................... 185
Enable iwproxy Access Control ................................................................................................. 185
Configure SSI Remapping ......................................................................................................... 186
Configure Proxy Failover ........................................................................................................... 186
Debug Your Proxy Server Configuration.................................................................................... 188
Contents
Chapter 9
MediaBin Connector ............................................................................................................... 191
Configure the MediaBin Connector ...........................................................................................192
Display the MediaBin Properties Screen .............................................................................192
Edit the MediaBin Connector Properties .............................................................................193
Connect to a Legacy MediaBin Server ................................................................................195
FormsPublisher Configuration Files ...........................................................................................197
datacapture.cfg ...................................................................................................................198
Presentation Template Files ...............................................................................................200
MetaData XML Record...............................................................................................................201
attribute Metadata Elements ...............................................................................................202
Representation of Data Types ............................................................................................202
Dublin Core Metadata Elements .........................................................................................203
Custom Metadata ...............................................................................................................204
MediaBin Configuration ..............................................................................................................205
Setting Anonymous Access ................................................................................................205
Configuring MediaBin Trusted Client and LDAP Authentication ..........................................205
Troubleshooting .........................................................................................................................205
Running MediaBin Connector 1.1 and 2.0 Toolkits Simultaneously ....................................205
Import from MediaBin Requires Anonymous Access to the Transfer Directory ...................206
Update Required When Using Microsoft Internet Explorer 6.0 SP1 ....................................206
Chapter 10
Back Up TeamSite ................................................................................................................... 209
Integrate with Third-Party Backup Solutions...............................................................................209
Suggested Strategies for Incremental Backups..........................................................................211
Appendixes
Appendix A
Internationalization ..................................................................................................................215
Overview ....................................................................................................................................216
Supported Client and Server Platforms ......................................................................................216
Supported Content .....................................................................................................................217
Limitations and Assumptions......................................................................................................217
Content Stores and Character Encoding ....................................................................................218
About UTF-8 ..............................................................................................................................218
URL Commands with Multibyte Characters................................................................................218
Contents
Appendix B
Specify Content Encoding.................................................................................................... 227
regex_map Defined ................................................................................................................... 228
Simple regex_map Example .............................................................................................. 228
The regex_map Format ............................................................................................................. 229
Rule Syntax ........................................................................................................................ 230
Regular Expression Syntax ................................................................................................ 230
Variables ............................................................................................................................ 231
Application Variables .......................................................................................................... 231
Intermediate Variables ....................................................................................................... 231
Interpolation of Variables and Captured Subexpressions ................................................... 232
Quoting .............................................................................................................................. 234
Strategies for Effective regex_maps .......................................................................................... 236
Internationalization and regex_maps ......................................................................................... 237
VisualPreview and file_encoding.cfg ......................................................................................... 238
Source Differencing and Merging and file_encoding.cfg ............................................................ 238
Sample file_encoding.cfg ................................................................................................... 239
Appendix C
Single Sign-On .......................................................................................................................... 241
Overview ................................................................................................................................... 242
10
Contents
Appendix D
Troubleshooting........................................................................................................................265
Index ..............................................................................................................................................281
11
Contents
12
Figures
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
13
Figures
14
Tables
Table 1
Table 2
Table 3
Table 4
Table 5
Table 6
Table 7
Table 8
Table 9
Table 10
Table 11
Table 12
Table 13
Table 14
Table 15
Realms...................................................................................................................... 246
Table 16
Rules......................................................................................................................... 246
Table 17
Response.................................................................................................................. 247
Table 18
Realm........................................................................................................................ 253
Table 19
Rules......................................................................................................................... 253
Table 20
Rules......................................................................................................................... 253
Table 21
Response.................................................................................................................. 254
Table 22
Response.................................................................................................................. 255
Table 23
Response.................................................................................................................. 255
Table 24
Response.................................................................................................................. 256
Table 25
Table 26
15
Tables
16
This document is for TeamSite Administrators and Master users, Web server
administrators, and system administrators.
Documentation Updates
Conventions
Contact Autonomy
Documentation Updates
The information in this document is current as of TeamSite version 7.3. The
content was last modified 08 February 2013.
You can retrieve the most current product documentation from Autonomys
Knowledge Base on the Customer Support Site.
A document in the Knowledge Base displays a version number in its name, such
as IDOL Server 7.5 Administration Guide. The version number applies to the
product that the document describes. The document may also have a revision
number in its name, such as IDOL Server 7.5 Administration Guide Revision 6.
The revision number applies to the document and indicates that there were
revisions to the document since its original release.
It is recommended that you periodically check the Knowledge Base for revisions
to documents for the products your enterprise is using.
To access Autonomy documentation
1. Go to the Autonomy Customer Support site at
https://customers.autonomy.com
2. Click Login.
17
3. Enter the login credentials that were given to you, and then click Submit.
The Knowledge Base Search page opens.
4. In the Search box, type a search term or phrase. To browse the Knowledge
Base using a navigation tree only, leave the Search box empty.
5. Ensure the Documentation check box is selected.
6. Click Search.
Documents that match the query display in a results list.
7. To refine the results list, select one or more of the categories in the Filter By
pane. You can restrict results by
Product Group. Filters the list by product suite or division. For example,
18
Conventions
Conventions
The following conventions are used in this document.
Notational Conventions
This document uses the following conventions.
Convention
Usage
Bold
Italics
monospace font
monospace bold
monospace italics
19
Usage
[ optional ]
{ required }
required
variable
<variable>
-merge filename1
(In some documents, angle brackets are used to denote
these items.)
...
20
Notices
This document uses the following notices:
21
Case Center: The Case Center is a central location to create, monitor, and
manage all your cases that are open with technical support.
Contact Autonomy
For general information about Autonomy, contact one of the following locations:
22
E-mail: autonomy@autonomy.com
E-mail: autonomy@autonomy.com
Autonomy, Inc.
One Market Plaza
Spear Tower, Suite 1900
San Francisco CA 94105
USA
PART 1
Introduction
TeamSite Overview
Part 1 Introduction
24
CHAPTER 1
TeamSite Overview
This chapter introduces three major TeamSite concepts and concludes with a
description of the TeamSite system architecture.
It includes the following topics:
TeamSite Elements
User Roles
TeamSite Workflow
TeamSite Architecture
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 Unix:/iw-store; Windows:C:\iw-store.
TeamSite 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 system administrator.
25
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 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.
26
TeamSite Elements
Editions
Editions are read-only snapshots of a branch, taken at sequential points in its
development. Contributors with appropriate permissions 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.
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. Figure 1 on
page 28 illustrates the use of TeamSite for Web site development.
27
User Roles
TeamSite ships with out-of-the-box user types, each with specific access
permissions and optimized user interfaces. These user types are known as roles.
The roles are:
28
Administrator
Author
Editor
Master
Reviewer
User Roles
Site Manager
WorkflowUser
WorkflowAdmin
These default roles are summarized in the following sections. Each installation
can create or modify roles to meet the needs of your organization.
Reviewer
Reviewers generally review work done by others. They may have approval
authority. They can browse workareas and review files and forms, search for
content, and work with tasks. Reviewers usually access TeamSite from the
browser-based ContentCenter Standard interface.
Author
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 usually 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.
Editor
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.
Administrator
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
29
Editors and groups and by creating subbranches of their own branch to explore
separate paths of development. They can assign TeamSite users to groups and
assign users to roles on the branch.
An Administrator is the supervisor of the project being developed on his branch.
Master
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.
They can create or modify roles. The Master user is generally involved in the
installation of TeamSite and can reconfigure TeamSite on a system-wide basis.
Users with the Master role have access to the Administration Console within
ContentCenter Professional. This allows them to add operating system users to
TeamSite, assign groups, create and edit roles, and perform other TeamSite
tasks. Most installations only have a few Master users.
WorkflowUser
By default, all TeamSite users should be able to use workflow models. To achieve
this, the workflowModels branch of the iwadmin store is shared for
iwEveryone with role as WorkflowUser. This role has the minimum privileges
required to instantiate a workflow.
WorkflowAdmin
The WorkflowAdmin role has privileges to design workflows using Interwoven
Workflow Modeler and upload them to TeamSite. They have privileges to manage,
configure, and debug the workflow models. Users who can perform these
operations include workflow developers or TeamSite administrators.
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 Client Services organization.
For more information about configuring different workflow models, consult the
TeamSite Workflow Developers Guide.
Figure 2 on page 31 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.
30
TeamSite Workflow
Task:
Email sent
to Author
Task:
Author
edits files
Task:
Email sent
to Author
Task:
Email sent
to Editor
Task:
Content
submitted
to the
staging area
Task:
Automated
deployment
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 on page 31 might be used to create the job in Figure 3
on page 31.
Figure 3 Example of a workflow for a job
Andre
initiates job
Task:
Email sent
to Pat
Task:
Pat edits
index.html
and
banner.gif
Task:
Email sent
to Pat
Task:
Email sent
to Andre
Task:
Content
submitted
to the
staging area
Task:
Automated
deployment
31
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
The TeamSite file system is composed of the TeamSite Content Server and
device driver kernel module, 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 TeamSite 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 TeamSite 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.
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 (TeamSite shared drive) (NFS mount/Samba)
and command-line tools, which do not go through the web server, are not routed
through a proxy server.
32
TeamSite Architecture
Client Computer
command
line
Command
Line Tools
RPC
CSSDK
Soap
Server
Web
Daemon
(port 80)
Servlet
Engine
TeamSite
Server
(iwserver)
CSSDK
TeamSite
Shared
Drive
Content
Web
Server
(port 81)
Browser
Interfaces
Local File
Manager
Content
Services
Applications
iwproxy
Workarea
Virtualization
(port 1080)
Local File
Manager
Device
Driver
SMB
Network
Share
33
Client Computer
Command
Line Tools
TeamSite
Content
Stores
TeamSite
RPC
Content
Server
(iwserver)
CSSDK
Soap
Server
Web
Daemon
Servlet
Engine
(port 80)
Browser
Interfaces
Local File
Manager
CSSDK
TeamSite
kernel
file system
driver
/.iwmnt
File system
mount
NFS
Content
Web
Server
(port 81)
iwproxy
Workarea
Virtualization
(port 1080)
/iwmnt
File system
mount
Content
Services
Applications
Local File
Manager
NFS mount
Samba
34
TeamSite Architecture
WORKAREA
STAGING
admin
development
EDITION
INITIAL
WORKAREA
Legend:
andre
pat
STAGING
chris
EDITION
INITIAL ed_0001
System-created
User-created
* Store name is user-assigned in
MultiStore implementations
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.
35
NFS Exports
Linux only
Exporting the TeamSite file system for NFS clients requires two steps:
1. The TeamSite file system entry in /etc/exports must use the fsid export
option.
2. The TeamSite file system must be unexported prior to stopping TeamSite.
Failure to specify the fsid option in /etc/exports causes NFS client mount
requests to fail with Permission denied errors. Failure to unexport the TeamSite
file system prevents the TeamSite file system from unmounting, which in turn
prevents a clean shutdown of TeamSite. An alternative to unexporting the
TeamSite file system is to stop the NFS services.
The following is an example entry in the /etc/exports file for the TeamSite file
system (see the UNIX man exports page for more information):
/iwmnt/default *(rw,fsid=1000)
The following command shows how to unexport just the TeamSite file system (see
the UNIX man exportfs page for more information):
# exportfs -u *:/iwmnt/default
Specify VPaths
The path describing a workarea is its workarea VPath. The path describing a files
location within an area is its area relative path. Combined together, a files full
VPath describes its precise location in the file system.
A vpath (version path) is a path within the TeamSite content repository,
specified as one of the following:
\store\branch+\EDITION\edition
\store\branch+\WORKAREA\area\directory*\file
\store\branch+\STAGING\directory*\file
where + indicates 1 or more; * indicates 0 or more, and a path may omit the
elements below it in order to specify just a directory, area, branch, or store.
A branch may not be named EDITION, WORKAREA, or STAGING.
STAGING is a special area that every branch has. Thus, an area is either a
workarea, specified as WORKAREA\area, or STAGING.
36
TeamSite Architecture
\default, a store.
\default\main\pubs\WORKAREA\uitk\guide\examples, a directory.
\default\main\pubs\WORKAREA\uitk\guide\examples/example1,
a file.
The path delimiter can be either / or \ when specifying a TeamSite path, but
will be output as: / (Unix) or \ (Windows).
Optionally, a vpath can include the server name by prepending //servername
to it, though doing so is generally not needed.
The maximum length of a vpath (including host name, branch, workarea, and
folders) is currently limited to about 600 bytes.The limitation is imposed by the
maximum length of a GET URL command supported by a browser. The 600-byte
requirement provides 30 folder levels with average 20-byte folder names.
For multi-byte languages (Chinese, Japanese, Korean), the maximum length is
reduced by a factor of 9 to about 67 bytes. Each CJK character, when used as
part of an URL, must be encoded. The encoding for UTF-8 expands each
character to a 9-byte sequence of the form %xx%xx%xx where xx is the
hexadecimal UTF-8 code.
Related Documentation
For information and preliminary configuration information, consult the TeamSite
Installation Guide.
For more information about configuring different workflow models, consult the
TeamSite Workflow Developers Guide.
For more information on specifying a vpath, see the TeamSite Command-Line
Tools Guide.
37
38
CHAPTER 2
<ProductNameFull> <DocumentType>
39
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:
Windows:
iw-home\local\etc\iw.cfg
iw-home\etc\iw.cfg
HKEY_LOCAL_MACHINE\Software\Interwoven\TeamSite\
iw-config (registry key)
Unix:
/etc/iw.cfg
iw-home/config/iw.cfg
iw-home/local/etc/iw.cfg
iw-home/etc/iw.cfg
If iw.cfg is not found in any of these places, TeamSite assumes the default
values for iw.cfg settings.
40
<ProductNameFull> <DocumentType>
iw.cfg option
Page
Enabling/disabling
VisualPreview
[iwproxy_smartcontextedit_all
owed]
Windows: Configuring
domain lists in the login
screen
domain_list
maildomain, mailserver,
use_mapping_file,
email_mapping_file,
debug_output
valid_domains
Configuring UI functionality
old_mod_times
force_EA_mod_times
encoding
servlet_port
main_lock_model
only_lock_owner_creator_submi
ts
Controlling behavior of
Mandatory Write and Optional
Write locking
lockmodel_compatibility
<ProductNameFull> <DocumentType>
41
iw.cfg option
Page
compare_search_limit
event_log_size
utild_ext_tasks_portnum
iwutild_runas_root
ew_enable
ew_rollover_threshhold
cachesize
Windows: Controlling
impersonation
disable_ext_task_impersonation,
impersonate_without_password
thruputmonitoring,
thruputmonitorx
Throughput Monitors on
page 69
disklow_mybtes,
disklowpercent,
disklow_knodes (Unix)
server_locale
[locations]
Setting FormsPublisher
default directory
data_root
preview_history_limit
preview_system_directory
Configuring FormsPublisher
42
<ProductNameFull> <DocumentType>
iw.cfg option
Page
pretty_print_dcrs
iwglobal_group
branch_owner_role
admin_roles
Windows: Specifying a
secondary master user
secondary_admin_account
main_owner, main_group
branch_security,
workarea_security
branch_default_perm, Unix:
workarea_default_perm,
file_default_perm,
directory_default_perm
Default Permissions on
page 110
domain_local_groups
use_adsi, debug_adsi
enable_user_group_disk_cache
windows_groups_for_users,
windows_groups_for_sharing,
include_nested_groups
(Unix) webserver_uid/
(Windows) webserver_group
<ProductNameFull> <DocumentType>
43
iw.cfg option
Page
mask_workarea_access
map_secondary_to_primary_gid
Group Remapping on
page 120
honor_setgid,
honor_setgid_on_rename
ldapcache_thread_delay,
log_ldap_sync, ldap_sync_retry
enumerate_os_users_thread_del
ay
LDAP Synchronization on
page 129
password_file
User Authentication on
page 131
authenticate_by
User Authentication on
page 131
pam_service, pam_do_acct_mgmt
domain_list
show_user_list
debug_event_handler
44
[iwproxy]
[iwproxy_remap]
Document Roots on
page 176
Resolving fully-qualified
URLs
[iwproxy_fullproxy_redirect]
<ProductNameFull> <DocumentType>
iw.cfg option
Page
[iwproxy_preconnect_remap]
[iwproxy_preconect_remap]
Configuring external
remappings
[iwproxy_external_remap]
Configure External
Remappings on page 183
[iwproxy_hostheader_remap]
[iwproxy_access_control_enabl
ed]
[iwproxy_plugin_remap]
[iwproxy_failover_remap]
store_directory_store-name,
store_comment_store-name
delete_jobs_on_completion
**
external_task_add_filelist
**
wftask_nesting_depth_allowed
**
external_task_retry_wait
**
presubmit_check
**
external_task_root_allowed
**
[iwproxy_preconnect_redirect]
[iwproxy_external_remap]
Configuring workflows
<ProductNameFull> <DocumentType>
45
iw.cfg option
Page
task_areavpath_file_access_ch
eck
**
permit_add_locked_files_to_
locking_tasks
**
46
Configuration File
Function
Unix: /etc/defaultiwhome
Unix: /etc/defaultiwstore
Unix: /etc/defaultiwmount
Unix: /etc/defaultiwlog
Unix: /etc/defaultiwelog
Unix: /etc/defaultiwtrace
iw-home\local\config\submit.cfg
iw-home\local\config\
autoprivate.cfg
<ProductNameFull> <DocumentType>
Function
iw-home\local\config\
file_encoding.cfg
iw-home\local\config\
templating.cfg
iw-home\conf\roles\tsusers.xml
iw-home\conf\roles\
user_databases.xml
iw-home\conf\roles\roles.xml
iw-home\conf\tsgroups.xml
iwsearch-home\etc\
search.properties
iwsearch-home\etc\branches.cfg
iwsearch-home\etc\FieldMapping.xml
iw-home\tsreport\conf\
spring-config.xml
iw-home\httpd\webapps\
eventsubsystem\
WEB-INF\iw_bridge_cfg.xml
iw-home\etc\iwutild.cfg
iw-home\local\config\
datacapture.cfg
iw-home\local\config\
metadata-rules.cfg
<ProductNameFull> <DocumentType>
47
48
<ProductNameFull> <DocumentType>
PART 2
Administrative Tasks
Set Up TagUI
MediaBin Connector
Back Up TeamSite
50
CHAPTER 3
Configure FormsPublisher
51
52
maildomain=domain.topleveldomain
Specifies the domain (for example, maildomain=Autonomy.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.
53
54
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
resolved by setting old_mod_times=false. 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.
cp1252
euc-jp
ISO-8859-1
shift_jis
utf-8
55
56
Submit. Enables users to ensure that their changes are submitted before
others can submit theirs. When a file is locked, users in different workareas
can edit their version of the file, but cannot submit it until the owner of the lock
submits his work or manually releases the lock. This option is selected by
Mandatory Write. Ensures that only one user can edit a file at a given time.
Users must lock files while editing them. While files are locked, no other users
in any workarea on the branch can edit their version of those files. This option
is suitable for environments where serial development is required.
Optional Write. Enables users to choose whether or not to lock a file. While
files are locked, no other users in any workarea on the branch can edit their
version of those files. This option is suitable for environments where serial
development is desired, but optional.
A branchs locking model is set when the branch 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. The type of locking a branch uses cannot be
changed after the branch has been created.
You can also set these locking models, plus the option None, when creating roles.
Since a branch and a role can have separate file locking, TeamSite uses the more
restrictive of the role locking and branch locking when determining what locking
model is in place for a particular user on that branch. TeamSite also evaluates
whether a user has multiple roles on the branch and uses the least restrictive
locking specified in a role. It then compares locking for the role with the branch
locking model and applies the most restrictive model.
Role locking is useful if you wanted to have a different locking model for users
having different roles on a given branch. For example, the author role may have
mandatory write locking, implying that users who are authors in a branch that has
submit locking should have the lock on the file and lock the file in their workarea
before editing the file. This lowers the need for authors to deal with conflict
resolution and merging while other roles enjoy a more lenient model.
Submit Locking is the least restrictive followed by Optional Write Lock and
Mandatory Write Lock.
ContentCenter configurations may impose additional restrictions on whether a
user needs to lock a file before being able to edit it.
57
Locking Behavior
The lockmodel_compatibility option in the iw.cfg file controls behavior of
Mandatory Write and Optional Write locking. When the option is set to true, all
users who have access to the same workarea can edit the locked file. When the
option is set to false, the file can be edited only by the lock owner in the
workarea where it was locked.
[iwserver]
lockmodel_compatibility=true|false
Compare 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
58
Autoprivate Feature
TeamSites Autoprivate feature enables you to prevent certain file types and
directories from being submitted to the staging area or copied during a Copy To
operation. Examples of these files may include temporary files, backup files and
Macintosh resource forks. 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.
Files and directories may also be specified Private by turning on the Do not submit
check box in the Properties screen in ContentCenter.
To activate Autoprivate, create a text file named autoprivate.cfg in your
iw-home\local\config\ directory. The Autoprivate file consists of two
sections:
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)(#_character
s to match_at_end))
59
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))
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.
Table 3 Autoprivate Encodings
60
Special Character
Autoprivate Encoding
\23
\5b
\5d
\28
\29
space (spacebar)
\20
Encoding examples:
((\23x\23)(1)(1))
((\23bbaax)(2)(0))
matches: #b*
((\28ab\29)(2)(2)) #(ab)
((a\5b\5db)(2)(2))
matches: a[]b
61
All iwat triggers and workflow external tasks are executed by iwutild.
However, the programs executed by iwat triggers and workflow external tasks
need not be specified in iwutild.cfg. The iwutild daemon replaces
iwprocessd (Unix).
The iwutild.cfg file can be edited to modify error logging, executed
commands, and file locations. The following code shows the default
iwutild.cfg file.
<?xml version="1.0" encoding="UTF-8"?>
<iwutild>
<!-- Logging options for the Teamsite utility daemon. -->
<!-- utild log level can be either "quiet", "error" or "debug" -->
<!-- hopi log level can be either "quiet", "panic", "error",
"warn", "info" or "debug" -->
<log
level="error"
path="/var/adm/iwutild.log"
cmdoutputpath="/var/adm/iwutild_cmdout.log"/>
<!-- optional -->
<!-- ipc tunables -->
<hopi
port-http="6688"
port-ssl="6689"
ssl-cert-dir="/usr/iw-home/local/config/ssl/iwutild"
log-level="error"/>
<!-- The list of commands executed by the utility daemon. -->
<!-- The servletd start up depends on iwstat. -->
<command-list>
<command
name="iwpt_compile"
path="/usr/iw-home/bin/iwpt_compile.ipl"/>
<command
name="iwstat"
impersonate="false"
path="/usr/iw-home/bin/iwstat"/>
</command-list>
<file-list>
<file
name="iwcfg"
path="/etc/iw.cfg"/>
<file
name="iwutildcfg"
path="/usr/iw-home/etc/iwutild.cfg"/>
62
<file
name="iwlicense"
path="/usr/iw-home/etc/TS.lic"/>
<file
name="useropsxml"
path="/usr/iw-home/private/etc/userops.xml"/>
<file
name="useropsuixml"
path="/usr/iw-home/private/etc/userops_ui.xml"/>
<file
name="iwutildclientcfg"
path="/usr/iw-home/servletd/conf/iwutild_client.cfg"/>
<file
name="cssdkcfg"
path="/usr/iw-home/cssdk/cssdk.cfg"/>
<file
name="iwserverlog"
path="/var/adm/iwserver.log"/>
<file
name="iwtracelog"
path="/var/adm/iwtrace.log"/>
<file
name="iweventslog"
path="/var/adm/iwevents.log"/>
<file
name="iwutildlog"
path="/var/adm/iwutild.log"/>
<file
name="transformcfg"
path="/usr/iw-home/local/config/transform.cfg"/>
<file
name="datasourceconfigxml"
path="/usr/iw-home/local/config/DataSourceConfig.xml"/>
<file
name="metadatarulescfg"
path="/usr/iw-home/local/config/metadata-rules.cfg"/>
<file
name="templatingcfg"
path="/usr/iw-home/local/config/templating.cfg"/>
<file
name="fileencodingcfg"
path="/usr/iw-home/local/config/file_encoding.cfg"/>
<file
name="availabletemplatescfg"
path="/usr/iw-home/local/config/wft/
available_templates.cfg"/>
</file-list>
</iwutild>
63
The iwutild.cfg file uses the port-ssl option to set the port number to be
used for the iwutild service. The default value is 6689. This value can be
changed during the TeamSite installation.
If you change the port number in iwutild.cfg after installation, you need to
update the cssdk.cfg file and set the following option in iw.cfg so that
iwserver can find the iwutild service.
[iwserver]
utild_ext_tasks_portnum=portnumber
The iwutild.cfg file allows you to select which commands or scripts use
impersonation and which are to run as System. The iwptcompiler is one of
these commands. Disable impersonation for a command by specifying
impersonate="false" for the command.
The iwutildreset CLT can force iwutild to re-read the iwutild.cfg file.
The iwutildstat CLT provides status information for the iwutild server.
Refer to the TeamSite Command-Line Tools for information on these CLTs.
You should be aware of the following areas that are impacted when iwutild is
invoked as a non-root user:
64
Files and directories created by customer scripts through the file system
interface (/iwmnt) may not have the correct ownership and permissions.
They will be owned by iwts.
The iwat triggers will not run as the user root; instead they run as the
non-root user iwts. If the triggers invoke scripts that create or delete files and
directories through the file system interface, ownership and permissions will
be for user iwts.
The existing external workflow task scripts will have to be re-written by the
customer to use the URL-based workflow feature.
If you are running the utility daemon as non-root and invoke any workflow
external tasks by mistake, the behavior of the task is not determined. The task
might end up creating files with incorrect ownership since the external tasks
will be run as the user iwts.
The templating scripts will have to be re-written using XLST, instead of the
current PT compiler implementation.
The TeamSite server (that is, iwserver) running on UNIX systems is run by the
process iwts rather than by root. As a result, after TeamSite is installed,
permissions on all Content Store files are reset to enable iwts, and all TeamSite
processes except iwauthend run as iwts or iwui. This conversion cannot be
undone, and the installer cannot opt out of it.
NOTE You must still log in as the user root to run the
TeamSite installation script and to perform administration
tasks.
65
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.
Event Subsystem
Subscribers
Search
Proxy Servlet
ReportCenter
Workflow
Modeler
OpenDeploy
DAS
If the line is not included, add it to the iw.cfg file. Save and close the file; issue
the iwreset CLT.
The default size of each default_log_location/iwevents/
TeamsiteEvents.x log file (before it rolls over) is 100 MB. This is specified in
iw.cfg under the [event_subsystem] section.
[event_subsystem]
66
ew_rollover_threshold=104587600
For example:
<iwovJMS classpath="_IW_HOME_/eventsubsystem/lib/
openjms-client-0.7.6.1.jar" initialContextFactory="org.exola
b.jms.jndi.InitialContextFactory" url="tcp://localhost:3035/
" factoryName="JmsTopicConnectionFactory" topic="Interwoven"
dasTopic="TeamSite_User" expiryTimeInDays="4"
waitTime="300000">
</iwovJMS>
Uncomment logFile tags with the name property value of
67
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.
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.
68
External tasks run as the task owner and are restricted to the permissions
associated with the task owner. If the impersonate_without_password
option in the iw.cfg file is set to false, the behavior from earlier TeamSite
versions in which the iwauth cookie carries the password is in effect. This
applies only to iwptcompile and CGIs and has no effect if impersonation is
turned off for a given command in the iwutild.cfg file.
[authentication]
impersonate_without_password=true|false
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.
[iwserver]
thruputmonitoring=on
thruputmonitor1=1
thruputmonitor2=15
thruputmonitor3=60
thruputmonitor4=480
thruputmonitor5=1440
thruputmonitor6=-1
thruputmonitor7
thruputmonitor8
#
#
#
#
#
#
1 minute
15 minutes
1 hour
8 hours
24 hours
forever
69
70
Solaris/AIX 5.1
SimplifiedChinese_China.MS936@Binary
zh/zh_CN
Korean_Korea.MS949@Binary
ko/ko_KR
Japanese_Japan.Shift_JIS@Binary
ja_JP.PCK/Ja_JP.IBM-932
Japanese_Japan.JapanEUC@Binary
ja/ja_JP
German_Germany.Latin1@Default
de/de_DE
English_UnitedStates.US-ASCII@Binary
C (C locale)
71
Windows Locale
SimplifiedChinese_China.MS936@Binary
Simplified Chinese
Korean_Korea.MS949@Binary
Korean
Japanese_Japan.MS932@Binary
Japanese
German_Germany.MS1252@Default
German
English_UnitedStates.MS1252@Binary
U.S. English
Configure FormsPublisher
The following sections describe how to configure FormsPublisher to provide an
example templating environment. After the initial setup is complete, you can:
72
Configure FormsPublisher
73
74
CHAPTER 4
75
If the iwserver process (that is, the TeamSite server) is running, you will see
a response similar to this:
iwts 643 638 0 Feb 08 ? 7:22 iwserver.sol -e /Interwoven/
TeamSite/local/logs/iwevents.log /iw-store
WARNING: messages.
76
2. If you determine that the TeamSite server stopped abnormally, stop the
TeamSite services with the following command:
% /etc/init.d/iw.server stop
77
Unix
To stop the TeamSite serve:
% /etc/init.d/iw.server stop
2. Verify that all server processes have stopped. If not, manually kill any
remaining processes. For more information on the kill command, consult a
UNIX reference manual.
3. Restart the server with the following command:
% /etc/init.d/iw.server start
If the TeamSite server is responding, you will see a response similar to this:
iwserver: 7.1.2 Build 61235 Interwoven 20101031
If the server does not respond or stops, then the server is not handling requests
correctly. Restart the server as described in Check for Multiple Servers on
page 78 for Unix and as described on Start and Stop the TeamSite Server on
page 77 for Windows.
78
Unix
Verify the server is mounted to the correct drive partition with the following
command:
% df -k | grep iwserver
kbytes
used
avail
capacity
Mounted on
server:/iwserver/default
3141968
1542472
1285336
55%
/iwmnt/default
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.
79
Unix
To locate the TeamSite installation directory, type iwgethome at a command
prompt. 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.
WFS Log
Unix
On system startup, the TeamSite kernel 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.
80
Installation Log
Unix
The TeamSite installation log records the prompts and your replies to them during
the execution of the TeamSite installation program. The file is called
installer.log and, by default, is located in <iw-home>/iwinstall/logs.
Server Log
The server log records the state of TeamSite over timeincluding, but not limited
towhen 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 using the CLT iwgetelog.
Master users can also view the server log from the Logs tab in the Administration
Console.
Trace Log
The trace log records any irregularities on the TeamSite server. It is primarily used
by 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 using the CLT iwgettrace.exe.
Master users can also view the trace log from the Logs tab in the Administration
Console.
Events Log
The iwevents.log records TeamSite activitiesincluding, but not limited to
file submits, edition, branch and workarea creation, and DiskLow, Freeze,
ShutDown, StartUp and Thaw events. It is used with certain TeamSite triggering
scripts. By default, the file is located in iw-home\local\logs. On Unix, if the file
is not in the default location, you can locate it by checking the /etc/
defaultiwelog file or by using the CLT iwgetelog. On Windows, if the file is
not in the default location, you can locate it using the CLT iwgetelog.exe. The
entries in your iwevents.log file will be similar to these:
Windows
timestamp
domain\user
role
event
StartUp
ModifyEntity
ModifyEntity
81
ModifyEntity
ModifyEntity
TaskGroupTaken
event-specific information
(the example line wrapped)
Unix
timestamp
[Thu Aug
[Thu Aug
[Thu Aug
[Thu Aug
[Fri Aug
Workflow
user
role
event
event-specific
information
event-specific information
(the example line wrapped)
The last sample line states that on Friday August 24, 2010, 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 0x3ffcf (or 262095) and is part of a
workflow named CPE Workflow. The user tom assigned ownership to the task to
tom (himself).
Master users can also view the event log from the Logs tab in the Administration
Console.
Workflow Log
The workflow log records the output from workflow runtime diagnostics. The file is
called iwjoberrors.log and, by default, is located in iw-home\local\logs.
The log file contains entries when the following events occur:
This does not include every workflow specification that has errorssome
errors occur on the client.
82
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.
DiskLow
Freeze
ShutDown
StartUp
Thaw
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
Status
Running
Running
Running
Running
Running
Running
Running
83
products
scratch
CIE
workflow
ID
0x28e33f4
0x28543a1
Running
Running
Running
Running
Thread
0x1a75
0x1e
User
dvallabh
-
Store: dev
Batch Jobs (running):
Queued
[Fri Jul 9 15:27:19 2010]
Minutes
1
5
15
60
Thruput
13
17
233
1792
Avg op
0.0000
0.0003
0.0041
0.0004
Duration
0.000
2529.446
User
root
Store
dev
Operation
GetServerStatus
BatchJobs
Job
Object ID
RemoveDuplicateData (Phase 1)
Load
0.00
0.00
0.95
0.71
See TeamSite Command-Line Tools for details about iwstat.exe usage and
output.
84
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. By
default, iw.cfg includes the following entries:
#[locations]
#iwhome=/usr/iw-home
#iwmount=/iwmnt
#iwcgimount=/.iwmnt
#iwstore=/local/iw-store
#iweventlog=/var/adm/iwevents.log
#iwtracelog=/var/adm/iwtrace.log
#iwserverlog=/var/adm/iwserver.log
To change the location of one of the entries, 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). For example:
[locations]
iwbin=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/)bin
iwmount=Y:/iwmnt
iwcgimount=Y:/.iwmnt
iwroles=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/
)local\/config\roles
iwstore=Window:C:\iw-store;Unix:local\iw-store
iwsubmitconfig=C:\Program Files\Interwoven\TeamSite\(Unix:usr/
iw-home/)local\config\submit.cfg
iwautoprivate=C:\Program Files\Interwoven\TeamSite\(Unix:usr/
iw-home/)local\config\autoprivate.cfg
iwlogs=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/
)local\logs
iwconfigs=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/
)local\config
iweventlog=C:\Program Files\Interwoven\TeamSite\local\logs\
(Unix:var/adm/)iwevents.log
iwtracelog=C:\Program Files\Interwoven\TeamSite\local\logs\
(Unix:var/adm/)iwtrace.log
iwserverlog=/var/adm/iwserver.log
iwdeploylog=C:\Program Files\Interwoven\TeamSite\Unix:usr/iw-home/
)local\logs\iwdeploy.log
After restarting, TeamSite looks for the specified file or directory in the new
location.
85
The default iw.cfg does not contain all applicable files. The following table lists
other files and directories controlled by [location] in iw.cfg, some of which
are included in the preceding example.
Table 6 Other files and directories controlled by [location]
Specifies the location of TeamSite binaries (by default Unix:/Interwoven/
iwbin
TeamSite/bin;Windows: iw-home\bin).
86
iwmount
iwcgimount
iwroles
iwstore
Specifies the location of the TeamSite Content Store (this setting can be
overridden by the Registry key on Windows).
iwsubmitconfig
iwautoprivate
iwlogs
iwconfigs
iweventlog
iwtracelog
Unix:
iwserverlog
iwdeploylog
On Unix, if you change the location of iwmount, you must edit its webserver
alias to point to the new location. Also make sure the values in /etc/
defaultiw* match 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.
On Windows, to change the location of the TeamSite Content Store, you must
edit the Registry.
87
When you browse the contents using the new mounted drive, you will notice
improved performance. Users accessing the TeamSite file system interface
remotely (over a network) are not affected.
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.
88
The amount of disk usage for your selection is shown in the bottom of the window:
Figure 11 Viewing the size of the iw-store
Size of C:\iw-store
kbytes
used
avail
capacity
Mo
17637068
9613319
7847379
56%
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.
Delete 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 is displayed.
3. Type YES in the confirmation field and then click Delete.
89
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.
You can also delete editions using the iwrmed CLT as described in the TeamSite
Command-Line Tools.
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 storename
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 TeamSite Command-Line
Tools.
90
91
92
CHAPTER 5
Overview
Create Branches
Manage Branches
93
Overview
Branches represent paths of content development. Branches contain exactly one
staging area, one or more editions, and one or more workareas. Newly created
branches are based on an edition of the parent branch. A staging area and an
INITIAL edition are created automatically when a new branch is added;
workareas must be created manually.
Content can be shared among branches. See Integrate Content From Different
Branches on page 97.
A locking model is one of the properties set when a branch is created. Locking
models specify locking behavior for all workareas on the branch and determine
whether users can edit files in different workareas at the same time. The role the
user has on a branch also sets locking behavior. The locking behavior for both the
branch and the role are combined to determine the locking behavior for a user in a
branch. See Set Locking Models on page 56.
All users can view public branches and their properties, but only users with a role
on the branch can view private branches. Only users in roles who have
authorization can reassign a branch to a new owner and update the branch
properties. Only some properties are editable after the branch is created.
Deleting branches removes them and their contents, including the version history,
from the system. Use caution when deleting branches.
To access branches
1. Select the Content tab.
2. Navigate to the store that contains the branches you want.
3. Open the main branch. If subbranches exist, navigate through them to the
branch you want.
94
To change this setting on an existing main branch, you must use the Windows File
Properties to take ownership, or the command-line tool iwchgrp to change the
group on Windows and chown and chgrp commands to change the ownership
on Unix 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 Web Solutions Authoring Components Installation
Guide.
You can specify the role that the owner of a branch has in the iw.cfg file. This
role will be added for the person who is the branch owner. This will be in effect
whenever a new branch is created. If nothing is specified, the Administrator role is
used.
[iwserver]
branch_owner_role=role_name
You can specify the role or roles that can administer branches (have access to the
Actions > Manage Branches menu item) with the following iw.cfg option:
[iwserver]
admin_roles=role_name, role_name
If a user has one of the roles specified in the admin_roles setting in the branch
being viewed, the Manage Branches menu item is enabled. This setting controls
whether the user sees the menu item; it does not give users in the roles any
additional privileges, such as adding users to a role on a branch. For that, you still
need to modify the role to have Delegate permission.
(Windows) You can specify a secondary master user other the local administrator
with the following iw.cfg option:
[iwserver]
secondary_admin_account=domain\user
95
Create Branches
Users with appropriate permissions can create subbranches within branches.
Figure 12 New Branch screen
To create a branch
1. Select the Content tab.
2. Navigate to the branch under which you want to create the new branch.
3. Click New Branch in the view pane title bar.
4. Enter a name for the branch.
5. Enter a general description of the branch (for example, if content for a product
catalog is to be developed on the branch, you might enter Branch established
for the development of product catalog content.).
6. Your user name is displayed in the Owner field by default. Enter a different
user name if you want to assign the branch to another person. By default, this
user will have the Administrator role on the branch (unless a different role has
been configured using the branch_owner_role option in the iw.cfg file).
7. Select a locking option. See Set Locking Models on page 56 for information
about those options.
8. Enter the name of the edition you want to use as a starting point. The edition
must be from the parent branch.
96
9. Specify whether you want to you want the branch to inherit access from the
parent branch.Turn on Inherit from Parent to indicate that the users and their
roles should initially be identical to those on the parent branch. You can add
additional users later. This is the recommended setting. If this setting is not
turned on, you select the users and groups for this branch separate from the
parent branch. It is recommended that individual users be added to a
TeamSite group rather than being added individually to a branch.
10. Select Restrict Access to set up this branch so it is only displayed for users
or the groups that have permission to work in the branch. By default, a
restricted branch is shown in general listings of all branches, but users without
a role on that branch cannot go into that branch. (The branch_security
option in iw.cfg controls whether the name of restricted branches can be
seen.)
11. Click OK.
The branch is created and contains no workareas, one edition named
INITIAL, and a staging area. The staging area and INITIAL edition contain
a copy of the content from the edition you chose as a starting point.
After a branch is created you can create workareas and base them on the
branchs INITIAL edition, or any other editions you create on the branch.
97
The view pane displays the Editions view. The Editions view lists the staging
area (top) and editions (most recent first).
4. Select the edition that contains the content you want, or navigate into the
edition and select the items you want to propagate if only a subset of the
editions content is desired.
5. Select a workarea.
6. Select an overwrite option.
7. Click OK.
The content is copied to the selected workarea.
After the content is copied to the workarea on the target branch, you can submit
the content and create new editions to meet your needs.
Manage Branches
If your role allows you to manage branches, you can use the Actions > Manage
Branches menu item from the Content tab to display the Manage Branches
screen. This screen lists the branches you can manage. From this screen, you
can delete or rename the branch. Each branch also has a Properties link so you
can modify the branch properties.
Figure 13 Manage Branches screen from the Actions menu
98
Description. The text entered to describe the branch. You can modify this
field if you have permission to manage branches.
Locking. The locking model that was selected when the branch was created.
Based on. The edition that was used to provide content for this branch.
Owner. The owner of the branch. You can modify this field if you have
permission to manage branches. You can use the Find link to search for the
user who will own the branch.
Private. The Restrict access check box determines whether the branch is
visible only for users with access to this branch or whether it can be viewed by
all TeamSite users.
Inherit from Parent. The Users and Roles check box controls whether users
and their roles should initially be identical to those on the parent branch.
Additional users can be added later. If this setting is not turned on, the users
and groups for this branch are selected separate from the parent branch.
If you make changes to the branch properties, click Save to save and close the
Branch Properties screen.
99
At times, you may come across the same user or group being listed multiple times
with various roles. In such cases, the user or group will have cumulative
permissions from all the roles.
To access the Users and Roles screen
1. Navigate to the branch or store where you want to assign users or groups.
2. Click Configuration.
3. Click Users and Roles.
The roles that have been assigned to a user or group are listed next to the user
and are comma-separated. If there are too many roles such that they cannot be
displayed in a single line next to the user, mouse over the Roles column next to
the user to see the entire list of roles as a tooltip.
Options from this screen enable you to:
Edit Roles. Modify the role that a user or group has in that branch.
Download List. Download a list of users and roles who have permission to
work on this branch.
For more information about working with users and roles, see the ContentCenter
Professional User Guide.
100
CHAPTER 6
Access Considerations
Authentication
Access Considerations
Access to TeamSite is governed by the following two factors:
Windows/UNIX file permissions control who has access to individual files and
directories. Windows/UNIX password authentication is used when logging in to
TeamSite. However, TeamSite access privileges govern the role a user has in
101
various 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 Windows/UNIX
permissions).
When adding a new user, you need to consider the following factors:
To decide what groups new users need to belong to and which workareas they
need to access, consider your existing groups and the content and workareas
they can access. Add new users to the groups that work on the same content that
they need to edit, 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 (Unix) access
to the files that they will be editing. To change ownership or group (Unix) access to
files, see Change Group Ownership of Workareas on page 118.
When creating a new workarea, you need to decide:
Who will need to access the workarea (On Unix, this can be one person or one
person and a group).
What content the workareas owner and group should and should not have
access to.
Set permissions on your files according to the latter consideration. Remember that
a file cannot have different permissions in different workareas.If a files
permissions differs across workareas, you will encounter conflicts when you
submit files to the staging area.
NOTE The TeamSite log-in screen accepts passwords of
virtually any length. If you are using multi-byte characters,
the maximum length is 64 characters. On Unix, other
underlying authentication operating system mechanisms
(including /etc/passwd, PAM, LDAP, and SecureID) may
have different policies.
102
User roles. If you are attempting to perform any of these actions through
ContentCenter, you must be a user or member of a group associated with a
role authorized to perform the action on the branch.
Not all of these factors apply to every action. TeamSite checks only the factors
that apply to the action being attempted. Generally, it checks as follows:
All the roles a user has on the branch are calculated. If any of these roles
allow the operation, permission is granted; otherwise the operation is not
allowed for the user on that object.
workarea.
The user must have the appropriate Windows/UNIX file directory
permissions.
The file must meet the appropriate locking constraints.
The user must be the owner of the job or task (if applicable).
If the user has a role on the branch that has permission overrides set, these
restrictions may not apply.
Table 7 lists all of the operations that can be specified when roles are being
created or edited. It also shows the scope of each of the operations and the
permissions that are checked before a user can perform the function.
103
Object Affected
Permissions Checked
Branch Administration
Create Branch
branch
Delete Branch
branch
Delete Edition
edition
Modify Branch
Properties
branch
Rename Branch
branch
Rename Edition
edition
Content Management
Compare
Publish Edition
branch
Submit
Update Workarea
External Triggers
Create or Delete
External Triggers
104
Object Affected
Permissions Checked
Download
file, folder
Edit
file, folder
Generate Form
Lock File
Mark Private
Merge File
file, symlink
105
Object Affected
Permissions Checked
file, symlink
Preview File
Preview Form
Workarea is readable.
Workarea is readable.
Revert File
Search
Undo Changes
Workarea is readable.
File is locked.
User/group is workarea owner or locked the file.
Unmark Private
106
Object Affected
Permissions Checked
folder
Create Folder
folder
Create Form
file, folder
Import
file, folder
Store Administration
Freeze Store
content store
Modify Store
Properties
content store
Thaw Store
content store
User Administration
Create TS Group
Create TS User
Delete TS User
Workarea Administration
Create Workarea
branch
Delete Workarea
workarea
107
Object Affected
Permissions Checked
Modify Workarea
Properties
workarea
Rename Workarea
workarea
Workflow
Add Task Comment
task
Assign
Attach to Task
task
task
Configure Workflow
Models
workflow
task
End Job
job
Manage Workflow
Models
workflow
Modify Job
Properties
job
Modify Task
Properties
task
Publish Workflow
Models
workflow
New Job
Read Job Properties
job
Read Task
Properties
task
Retry Task
task
task
task
task
108
Object Affected
Permissions Checked
job
View My Jobs
View My Tasks
Webview Workflow
Models
workflow
Workarea Access
By default, the workarea root file system permissions restrict any subdirectory
access. For example, the permissions on a subdirectory or a file specify that a
user can modify the subdirectory or file. However, permissions on the root
directory do not grant write permissions to the user. Therefore, TeamSite does not
allow the user to modify the file or subdirectory. To disable this check, set this
option to no.
[iwserver]
mask_workarea_access=no
When set to no, permissions on the workarea root directory affect only this
directory rather than the entire tree.
109
Default Permissions
Unix
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.
Windows
You can control branch permissions on Windows by adding the
branch_default_perm parameter to the [iwserver] section of the iw.cfg
file as follows:
[iwserver]
branch_default_perm=0
The default behavior creates all branches with read access for the group
Everyone. If you add branch_default_perm=0 as shown, the group
Everyone is not added to the ACL for new branches created after this
configuration setting is added.
110
Add Permissions. Click Add Permissions to display the Users and Groups
dialog box with the Permission field. Select the type of permission you are
granting (Read only, Full Control, Modify). Then search for and select users
and groups. Click Add or Add and Close when you finish.
Edit. Click Edit opposite a user to display the Edit Permissions screen. The
Name and User display. Select a Permission option and save the change.
Delete. Click Delete to remove the user from the permissions. You are
prompted to verify the deletion.
Unix
When you click the Permissions link on a File Properties screen, the Permissions
screen is displayed. It shows the permissions set for the file.
From this screen, you can perform the following operations:
Read Only
Write Only
No Access
111
groups has evolved with it. Best practice for using groups with TeamSite depends
on the Windows Operating System version, and on the size and complexity of the
network in which it works. There are two basic scenarios:
The following sections explain how Windows groups are typically used in each of
these environments, and describe in what circumstances the new Active Directory
System Interface (ADSI) and disk-caching code can be used to improve
performance.
112
numbers of users and groups. The groups for sharing must be domain local
groups rather than (machine) local groups. To select the ADSI code, specify the
following two lines in the iw.cfg file:
[iwserver]
use_adsi=yes
domain_local_groups=yes
For larger installations, TeamSite may be configured to use cached user and
group information to significantly reduce the server's startup time. This feature
may be used with or without enabling the ADSI code. See Enable the User/
Group/Role Disk Cache on page 116.
When TeamSite users are in tsusers.xml, the TeamSite server may take
several minutes to start up as it collects user and group information. This startup
time can be significantly reduced when the server is configured to use cached
user and group information at startup time (this is on by default). See Enabling
the User/Group/Role Disk Cache and information later in this section.
In networks that are spread over large geographic areas and where TeamSite
users are spread among different domains, network response times may
encounter unusual delays when the TeamSite service is first started. The
TeamSite service is usually configured to start automatically after a Windows
reboot. At startup, TeamSite reads a variety of user and group information from
the Active Directory. This process may take several minutes. In extreme cases,
the time required to start the server may result in a system timeout, which occurs
when the server requires more than 10 minutes to start. These are possible
solutions for this problem:
113
Increase the timeout period from the default value of 600, which denotes 600
seconds (10 minutes), to a larger value. The timeout period may be set to a
different value by changing a parameter in the Windows Registry. The key to
be changed is found in the Registry at HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\iwserver\Parameters\Start
Timeout. Its value is the number of seconds that Windows should wait for the
server to start.
If the server startup time is unacceptably long, consider limiting the number of
inquiries that TeamSite must make to remote AD controllers. This is done by
limiting the number of domains that TeamSite is required to search using the
domain_list parameter in the iwserver section of iw.cfg. If it is not
practical to limit the number of domains, the need to query remote AD
controllers for group membership information can be reduced or eliminated
completely by careful choice of Windows group type for various uses. These
possible changes may improve performance:
Use universal groups exclusively to group users. This is recommended
only, limit the TeamSite search for nested groups to groups nested in
domain local groups. This is done with the following iw.cfg setting:
[iwserver]
windows_groups_for_sharing=LOCAL
Use universal groups exclusively to share TeamSite resources.
114
While some of these factors may be outside your control, response times can
usually be improved by trying some of the following:
Where practical, limit the number and size of groups used for sharing
TeamSite assets. Create dedicated groups, composed solely of TeamSite
users, instead of using large existing groups. This is especially helpful if the
existing operating system groups contain many members that are not
TeamSite users.
Limit the number of domains that contain TeamSite users and Windows
groups used for sharing. The domain_list parameter in the [iwserver]
section of iw.cfg should be set to include only domains that contain
TeamSite users and groups; see Domains to Use for Group Authentication
on page 134. A short list of domains can be searched faster than a long one.
Where TeamSite users are in tsusers.xml and there are a lot of users,
groups or domains, leave the user/group/role disk cache enabled (the default
setting). This is a good practice for most large TeamSite installations.
In installations that do not include nested groups in the groups used for
sharing TeamSite assets, disable the nested group handling functions (see
Disable Group Nesting on page 116). This option is not frequently used, but
is sometimes chosen to improve response times where there are very large
numbers of TeamSite users.
115
116
The iwdebug command-line tool can be used to display the contents of the
TeamSite internal cache at any time the server is running. The output from
iwdebug commands is written to the iwtrace log. The -g option lists
group information, and the -u option lists each user in the cache and the
groups of which that user is a member. The two options can be used
together, if desired: iwdebug -g -u.
117
groupname:*:gid:username1,username2,username3
For example, the entry for the group allauthors might look like this:
allauthors:*:2000:pat,andre,chris
118
TeamSite only checks the primary group owner of a workarea and does not
rely on ACLs to determine workarea ownership.
You can also change ownership of workareas through ContentCenter
Professional in the Workarea Properties screen.
Example
Unix
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
drwxrwxr-x
3 andre
drwxrwxr-x
2 chris
nobody
demoauthor
demoauthor
119
On Windows, this sets a group of users, all of whom have full file system access.
If this line does not exist, the group Everyone is used.
Group Remapping
Unix
This option provides a workaround for a limitation of NFS. When NFS checks the
operating system 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 NFSs 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 files group to the
users 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 the file. To find the files
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
When a file is imported or renamed, the group for the target directory is applied to
the file. By default, this is set to true. If you do not wish the gid to be applied to
import and rename operations, set this option to false.
[iwserver]
honor_setgid_on_rename=true|false
To turn off all setgid functionality during a ContentCenter Import, you must set
honor_setgid_on_rename=false and honor_setgid=false.
120
Authentication
Authentication
Authentication involves determining whether users can access TeamSite
resources. The tsusers.xml file maintains information on TeamSite users.
Operating system users are usually identified as TeamSite users and added to
this file through the Manage Users option in the ContentCenter Professional
Administration Console that is available to Master users.
OS and non-OS users can be identified in LDAP or an external source.
The LDAP files can be set up in one of two ways:
Users in the LDAP file display in the Administration Console and can be
added through the Manage Users screen or with the iwuseradm CLT.
121
122
Authentication
Description
id
display_name
os
Boolean value that indicates whether the users from this LDAP server are OS
users (t) or non-OS users (f). The default value is f. Each LDAP
configuration can contain either OS users or non-OS users, but not both.
server
port
search_key
Name of the LDAP attribute that holds the user account names (default is
uid).
ssl_port
Port that the LDAP server uses to communicate when SSL is in use. This is
assumed to be port 636.
CAFile
The location of your CA certificate database file. This entry must be in the
Netscape cert7 format.
An example 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.
dnBase
account
password
attr_email
Used to query the LDAP server for email addresses. The default is mail. If
the value is specified with an empty string, LDAP will not be queried for this
attribute.
attr_display_name
Used to query the LDAP server for user display names or common names.
The default is cn. If the value is specified with an empty string, LDAP will not
be queried for this attribute.
123
Description
authentication_url
A URL that TeamSite uses to authenticate a user from the external source.
Username and password are included as URL parameters and the command
is posted to the external source server. Both HTTP and HTTPS protocols are
supported. If HTTPS protocol is used, the filepath for the Certificate Authority
file must be specified using the CAFile attribute.
param_username
param_password
timeout_value
Specifies how long (in ms) to wait for the HTTP response; default is 500 ms.
The CLT outputs a 64-bit password like the one shown below:
52616e646f6d4956c82bafa0f0070585907d439c34792e66c55ade1fd1e21fc
4
124
Authentication
The CLT outputs YES if the encrypted password matches the original password.
When you use the ContentCenter Professional Administration Console to
manage users, you can search for users in these databases.
will be known by in the database. The value for nickName is normally the
same as the CN of the issuer for your certificate.
For example:
certutil -A -i CA.crt -n "Acme Manufacturing, Inc. CA" -t
"C,C,C"
You will now have three new files in your directory: cert7.db, key3.db, and
secmodule.db. These files should all be copied to the same directory. They
should also match what is specified in the authentication section of iw.cfg
and, if used, in the XML files that specify user databases.
3. Verify that the new database exists and contains the CA certificate.
List all of the certificates in the database. Look for the name of the one you just
added. The utility adds a variety of standard CAs, so there will be other
certificates included with the one you added.
125
On the line that contains the name of the certificate you just added, you
should see C,C,C. (C is the code for a Certificate Authority; the three Cs
indicate that this authority can issue certificates for any purpose). The
command to list all of the certs is:
certutil -L
Next, verify that the certificate you added is valid. The command to show
Replace Acme Manufacturing, Inc. with the value you used for
nickName in Step 2. This command should result in the display of about
a page of information with the details of the certificate.
Check that the CN field for Issuer is the same as the one you typed
The Not after date should be some date in the future, preferably a
few years into the future. (The Not after date is the expiry date for the
certificate.)
126
Authentication
127
link at the top of the screen allows them to move between ContentCenter
Professional and ContentCenter Standard. When logging in later, the user
returns to the interface they were using when they logged out.
ccpro-only. ContentCenter Professional is displayed. The user cannot
128
Authentication
LDAP Synchronization
Synchronization is done with the iwldapsync CLT (refer to the TeamSite
Command-Line Tools for options on this CLT). This CLT is normally launched
when TeamSite starts up and is run periodically as defined by
ldapcache_thread_delay in the iw.cfg file. The default is every 24 hours.
The CLT can also be run manually.
You can enable logging of the LDAP synchronization process using the
log_ldap_sync option in the iw.cfg file; logging is on by default. The
ldap_sync_retry_count is used to specify the number of retries to connect to
the TeamSite server when the LDAP synchronization process runs. By default, the
retry count is 12, which means that TeamSite waits about 60 seconds to start
responding to client requests.
Set these options in the [authentication] section as:
[authentication]
ldapcache_thread_delay=1440
log_ldap_sync=yes
ldap_sync_retry=12
129
than the number of TeamSite users in the LDAP database, no LDAP users will be
found during the synchronization. Try the following options to address the issue
when using LDAP synchronization:
Divide the users under different LDAP subtrees (under different base DNs)
and define multiple LDAP databases in TeamSite such that the number of
TeamSite users under each LDAP database configuration is no more than the
LDAP search limit.
Increase you LDAP search limit to the number of TeamSite users configured in
LDAP.
The other option is to add LDAP users to TeamSite using either the Administration
Console or the iwuseradm CLT instead of using the LDAP synchronization
procedure.
130
The file system interface is not available for contents that belong to non-OS
users. An OS user, with the exception of the TeamSite global OS user
(iwguser), will not be able to view TeamSite content properties that belong to
a non-OS user through the file system interface.
File permissions cannot be set for multiple non-OS users or non-OS groups on
a single asset because non-OS users or groups are mapped to a single OS
user or group.
Non-OS user functionality is only available from sciface, CSSDK, and the
ContentCenter interfaces. There is no file system support for Non-OS users.
From the file system, all non-OS users appear as iwguser.
While LaunchPad works for non-OS users, the Direct Edit feature that uses
the file system interface will not be available on content belonging to non-OS
users.
Authentication
User Authentication
Unix
TeamSite can be configured to authenticate users by the following methods:
Local. Users credentials are passed to the UNIX 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).
131
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
authentication, you can either modify an existing attribute to represent TeamSite
users or create a new one; this procedure is described in Modify LDAP Schemas
to Store TeamSite User Interface Information on page 128.
132
auth
account
required
required
/usr/lib/security/pam_unix.so.1
/usr/lib/security/pam_unix.so.1
Authentication
Linux
Linux systems do not contain the file /etc/pam.conf. Instead, Linux systems
use individual PAM configuration files in the directory /etc/pam.d.
The following entry is required in the iw.cfg file to enable PAM on Linux:
[authentication]
pam_service=filename
The filename should be the name of a PAM configuration file located in /etc/
pam.d. For example, you would use the following entry to specify that TeamSite
use the PAM settings for sudo located in /etc/pam.d (assuming that a
configuration file named sudo already exists in /etc/pam.d):
pam_service=sudo
If this entry does not exist in the iw.cfg file, PAM does not default to any other
settings, and therefore is not enabled.
In many installations, the content of the sudo file is an acceptable starting point
for PAM configuration. The sudo file typically contains the following:
#%PAM-1.0
auth
account
password
session
required
required
required
required
pam_stack.so
pam_stack.so
pam_stack.so
pam_stack.so
service=system-auth
service=system-auth
service=system-auth
service=system-auth
The file named in the pam_service entry must be located in /etc/pam.d and
must be owned by root.
133
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.
134
Once this feature is activated, each time TeamSite is restarted, it logs all users in
the roles files and their associated groups in iw-home\local\logs\
iwtrace.log. Log files use the following format:
user: username [associated groups]
NOTE If this feature is left on for too long, your log files will
grow extremely large.
135
{
file_pattern3 { action5 action6 ... }
file_pattern4 { action7 action8 ... }
...
}
...
}
where:
136
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.
Windows:
owner = name (changes the owner of the file or directory)
group = name (changes the group of the file or directory)
setaccess = ACL (replaces the access control list for the file or directory)
changeaccess = ACL (modifies the access control list so that the specified
users have only the specified rights)
where name is one of:
username
groupname
domainname\username
domainname\groupname
and where ACL (Access Control List) contains one or more Access Control
137
For example:
setaccess={ andre:ALL, marketing\pat:RX }
would remove the existing ACL and grant andre full access and pat (in
the marketing domain) read and execute access to the specified files.
changeaccess={ chris:CHANGE, everyone:RX }
would remove any existing ACEs for the user chris and the group
everyone, and grant chris change access and the group everyone
read access to the specified files. Any other existing ACEs would remain
unchanged.
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.
138
group="DOMAIN\\web editors"
setaccess = {users:rx, "domain\\webeditors:change"}
}
/$
# all directories
{
group="DOMAIN\\web editors"
setaccess = {everyone:rwx/rx, "domain\\webeditors:change"}
}
}
}
Unix:
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
}
}
Notes
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 (/
).
139
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.
Windows:
For example, the following three specifications are equivalent:
owner = DOMAIN\andre
owner = 'DOMAIN\\andre'
owner = "DOMAIN\\andre"
You can use backslashes (\) or forward slashes (/) as the path delimiter in
regular expressions, but using forward slashes is more readable. This is
because the backslash is treated as a special character in regex(5) syntax,
and it is also treated as a special character by the configuration file parser
when the expression is enclosed in quotes or double quotes. Therefore, when
an expression using backslashes is contained in quotes or double quotes, the
backslashes must be escaped twice, for a total of four backslashes.
For example, the following are equivalent expressions for matching any file
whose name ends in .html in the \a\b directory:
^/a/b/.*\.html$
'^/a/b/.*\\.html$'
"^/a/b/.*\\.html$"
^\\a\\b\\.*\.html$
'^\\\\a\\\\b\\\\.*\\.html$'
"^\\\\a\\\\b\\\\.*\\.html$"
140
(Unix) 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).
(Unix) 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.
(Unix) The permission values must be specified as an octal number (using the
digits 0 to 7) and taking the structure XXXX.
Changes to submit.cfg do not take effect until the server is restarted or until
you use iwreset.
would return:
Matched
Matched
Actions
owner =
File name
141
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 Sample submit.cfg file on page 138), 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:
142
$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.
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$
*/
$Source$. The pathname of the file, relative to the root directory of the area.
$Locker$
$Name$
$RCSfile$
$State$
Escape Sequence
end-of-line
\n
\044
\\
143
144
CHAPTER 7
Set Up TagUI
TagUI provides a method for tagging files (that is, assigning metadata to files).
TagUI can be used to add metadata to a single file or to multiple files at one time.
The purpose of tagging is to add extended attributes to your content that can be
used later to generate more informative web sites. For example, an expiration
date can be used to specify when content is to be removed. You can also add tags
that are used to search for content.
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.
Adding metadata is a file-specific feature. That is, users must explicitly select the
files on which to set metadata. Metadata cannot be set globally for an entire area
or branch. For example, to set metadata on all files in a workarea, the user must
select each file in that workarea (by clicking Select All or by clicking the check
box next to each file) and then initiate a TagUI session. If the data meets all
necessary criteria, TagUI adds the new metadata (in the form of TeamSite
extended attributes) to the specified files.
When a user selects the tagging option from ContentCenter or within a workflow, a
form displays to obtain the metadata values. This form is designed using the data
capture framework described in the TeamSite FormsPublisher Developers Guide.
This chapter describes specific TagUI-form design issues.
This chapter describes how to set up and use TagUI. It then discusses how to
move Metadata Capture Tagging configuration files to TagUI.
This chapter includes the following topics:
TagUI Features
145
Configure TagUI
Create Rulesets
Merge Rulesets
Using FormAPI
TagUI Features
TagUI differs from the Metadata Capture Tagging in several key areas. Tagging
features provided by TagUI include:
Scripting through FormAPI. You can use FormAPI and the <script>
element to create dynamic TagUI input forms. See the TeamSite
FormsPublisher: FormAPI Developers Guide for details about using FormAPI.
Rich text editor support. You can configure data forms to use the TinyMCE
rich text editor for data entry. Values stored for these text fields will include rich
text formatting information.
Tab Support. You can use the <tab> element when defining the form to
divide content input onto multiple pages.
Additional replicant and container support. You can configure data forms
using combination=or for item replicants and containers. The
<replicant> element is no longer supported.
146
147
When a user selects multiple files, the form is rearranged. The metadata items are
listed in the left panel while the main screen lists the files and contains fields for
entering the metadata. The Copy to All link lets a user enter information for one
item in a file and then copy that information to the corresponding item in all files.
Figure 15 shows the Description tag for multiple file tagging.
Figure 15 TagUI screen for multiple file tagging with Description tab
148
Configure TagUI
Configure TagUI
To configure TagUI, you need to:
1. Create one or more ruleset files in the iw-home/local/config/tagui/
rulesets60 directory. Ruleset file names must end in .cfg, and the files
must conform to the DTD defined in iw-home/local/config/
datacapture6.0.dtd. Each ruleset file can contain only one ruleset. See
Create Rulesets on page 153.
2. Specify the name of the ruleset you created in the iw-home/local/config/
tagui/ rulesets60 directory to the iw-home/local/config/
metadata-rules.cfg file. See Map to Rulesets on page 149.
Map to Rulesets
The metadata-rules.cfg file maps vpaths to data capture rules that are
defined in the iw-home/local/config/tagui/rulesets60 directory. 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, possibly 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. Therefore, entries in this file
should have broader regex expressions at the bottom and more specific
expressions at the top.
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:
<!ELEMENT metadata-rules (cond)*>
<!ELEMENT cond (cond|rule)*>
<!ATTLIST cond
vpath-regex
CDATA
>
<!ELEMENT rule EMPTY>
<!ATTLIST rule
name
CDATA
>
#REQUIRED
#REQUIRED
149
International Encoding
Vpath Expression
Rule Identifier
Notes
International EncodingUTF-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.
Vpath Regular ExpressionNames the vpath (in this case, all files in all
directories) to which the rules named in the following subelements are applied.
Rule IdentifierNames the rule that applies to the preceding vpath. The rule
itself is defined in the <ruleset> element of a file contained in the iw-home/
local/config/tagui/rulesets60 directory. In this example, the Default
Rule rule always applies to all files in all directories.
150
Configure TagUI
<metadata-rules>
<cond vpath-regex="^/default/main/syndication">
<rule name="Default" />
<rule name="Syndication" />
<cond vpath-regex="\.pdf$">
<rule name="PDF Files" />
</cond>
<cond vpath-regex="\.doc$">
Vpath Expression1
Rule Identifiers2
Vpath Expression3
Rule Identifier4
Vpath Expression5
Rule Identifier6
<cond vpath-regex="^/default/main/www">
<rule name="Default" />
<rule name="Web Content" />
<cond vpath-regex="\.html$">
<rule name="HTML Files" />
<cond vpath-regex="/pr/">
Vpath Expression7
Rule Identifiers8
Vpath Expression9
Rule Identifier10
Vpath Expression11
Rule Identifier12
Rule Identifier14
Vpath Expression13
Table 9 shows the results of the vpath expressions identified in the example code.
It also identifies the rulesets that will be applied to each category of files. For
example, any file in the /default/main/syndication directory has the
Default and Syndicate rulesets because it is in the /default/main/
syndication directory. Additionally, files with a .pdf file extension in the /
default/main/syndication directory also have the PDF Files ruleset
applied while files with a .doc extension in the /default/main/syndication
directory also have the MS Word Files ruleset applied. The number in brackets
(such as [1]) shows the corresponding identifier in the example code.
151
The default is 60000, which is the connection timeout value in milliseconds (and
equivalent to 60 seconds).
152
Create Rulesets
Create Rulesets
A ruleset defines the form that is used for collecting metadata for a particular type
of file. You may have rulesets created especially for files with certain extensions
(such as .pdf, .html, .doc, .txt). The metadata collected for each of these types
may be different. A ruleset is actually a data capture template (DCT) similar to
those used for FormsPublisher. A .cfg file defines a ruleset for capturing data;
you specify the file name. Rules are referred to by name in
metadata-rules.cfg. You may create as many rulesets as you need.
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 instances. Each instance encapsulates
how to capture the data for the item. You can specify access control elements that
determine whether a field is applicable to a particular user.
The TeamSite installation program installs a sample file called
datacaptureExamplewithValidation.cfg in the iw-home/local/
config/tagui/rulesets60 directory. You can copy, rename, and edit the
example file to create your actual rules file. Use the datacapture6.0.dtd and
annotated examples described in the TeamSite FormsPublisher Developers
Guide as a reference to create your own site-specific configuration.
153
154
Create Rulesets
Tab Element
<tab name="Details">
<item name="Business_Unit" pathid="Business_Unit">
<label>Business Unit</label>
<description>
Unit that is responsible for the asset.
</description>
<select>
Select instance
<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="Legal"/>
<option label="Marketing" value="Marketing"/>
<option label="Sales" value="Sales"/>
<option label="Systems" value="Systems"/>
</select>
</item>
<item name="Creation_Date" pathid="Creation_Date">
<label>Creation Date</label>
item element
<description>
The date the asset was created, in the YYYY-MM-DD format.
</description>
<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]$"/>
</item>
<item name="Expiration_Date" pathid="Expiration_Date">
<label>Expiration Date</label>
<description>
The date the asset should be retired, in the YYYY-MM-DD format.
</description>
<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]$"/>
</item>
validation-regex
</tab>
</root-container>
155
Creation_Date","onItemChange",testCDate);
IWEventRegistry.addItemHandler("/Asset_metadata/Details/
Expiration_Date","onItemChange",testEDate);
IWEventRegistry.addFormHandler("onSave",testCombinedData);
script Element
// event handler for copyToAll
IWEventRegistry.addItemHandler("/Asset_metadata/Details/
Creation_Date","onAfterItemReplace",testCDate);
IWEventRegistry.addItemHandler("/Asset_metadata/Details/
Expiration_Date","onAfterItemReplace",testEDate);
function testCDate(itemCDate) {
// check build-in validations
itemCDate.setValid(null);
var itemEDate = IWDatacapture. getItem("/Asset_metadata/Details/Expiration_Date");
itemEDate.setValid(null);
if (itemCDate.isValid() && itemEDate.isValid()) {
if (!compareDates(itemCDate.getValue(), itemEDate.getValue())) {
//use item-specific messages instead of alert()
itemCDate.addErrorMessage("Creation Date must be before the Expiration Date");
itemEDate.addErrorMessage("Expiration Date must be after the Creation Date");
itemCDate.setValid(false);
itemEDate.setValid(false);
// alert("Expiration Date must be after the Creation Date");
return false;
} else {
itemCDate.clearErrorMessages();
itemCDate.setValid(true);
itemEDate.clearErrorMessages();
itemEDate.setValid(true);
return true;
}
}
itemCDate.setValid(false);
itemEDate.setValid(false);
return false;
}
function testEDate(itemEDate) {
//check build-in validations
itemEDate.setValid(null);
var itemCDate = IWDatacapture. getItem("/Asset_metadata/Details/Creation_Date");
itemCDate.setValid(null);
if (itemEDate.isValid() && itemCDate.isValid()) {
if (!compareDates(itemCDate.getValue(), itemEDate.getValue())) {
// use item-specific messages messages instead of alert()
itemCDate.addErrorMessage("Creation Date must be before the Expiration Date");
itemEDate.addErrorMessage("Expiration Date must be after the Creation Date");
156
Create Rulesets
itemCDate.setValid(false);
itemEDate.setValid(false);
// alert("Expiration Date must be after the Creation Date");
return false;
} else {
itemEDate.clearErrorMessages();
itemEDate.setValid(true);
itemCDate.clearErrorMessages();
itemCDate.setValid(true);
return true;
}
}
itemCDate.setValid(false);
itemEDate.setValid(false);
return false;
}
function compareDates(creationDateStr, expirationDateStr) {
if ((creationDateStr.length==0) || (expirationDateStr.length==0))
return true;
var creationYear = creationDateStr.substring(0,4);
var creationMonth = creationDateStr.substring(5,7);
var creationDay = creationDateStr.substring(8,10);
var creationDate = (new Date()).setFullYear(creationYear,
creationMonth,creationDay);
var expirationYear = expirationDateStr.substring(0,4);
var expirationMonth = expirationDateStr.substring(5,7);
var expirationDay = expirationDateStr.substring(8,10);
var expirationDate = (new Date()).setFullYear(expirationYear,
expirationMonth,expirationDay);
return (creationDate < expirationDate);
}
157
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.
158
Rule Identifier. The <ruleset> element contains all of the items define the
appearance and behavior of the TagUI form. The name attribute is required.
Tab Element. Each <tab> element groups the fields that are on that screen
of the form. It also provides the text on the tabs. In this form, there are two
tabs: 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.
Item Element. An item is a single set of data (that is, a single field on the
form) that is to be captured from a content contributor. Item names must be
unique within any given nesting level. An item does not require a label; the
field shows up without a caption. However, if you are tagging multiple files, the
label on the left will be the value specified with the name attribute.
Create Rulesets
Item Element. Specifies that data will be entered and captured using an
unformatted single-line text field. 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 data field
is used to hold a date or time with a specific format, 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 to enter a string between one and 60 characters in the text field.
Item Element with a specific format (date). If a value for date or time is
needed, specify a 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.
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. 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.
Script Element. Indicates that FormAPI calls are being used. This example
shows validation checking of the information the user entered in the form. It
uses the postMessage API call instead of alerts that were used in earlier
versions. This is preferred if the ruleset is used for tagging multiple files
because it eliminates the need for the user to click through an alert dialog box
once for every file.
The <replicant> attribute is not supported when designing forms for TagUI.
Use the <container> or <item> elements with the min and max attributes.
159
If at least one ruleset uses tabs, all rulesets that will be merged must also
contain tabs; otherwise a merge conflict error will occur.
Use the same root-container name, such as root, for rulesets that will be
merged. Otherwise, a FormAPI script that registers handlers in one
root-container will not work when scripts are merged. For example: Ruleset A
contains a root container named A, which contains item A1. Ruleset B
contains a root container named B, which contains item A1 and a FormAPI
script. The merged ruleset will contain root container A, with item A1 merged
with item A1 from container B; it will not include the script because it did not
get merged since it belongs to root container A.
Do not use a slash (/) in an item or tab name; the Copy to All link and
FormAPI will not work.
160
Merge Rulesets
Merge Rulesets
When a user selects a file or files to tag, multiple rulesets may need to be
combined before the form displays in a process known as ruleset merging.
When a single file is tagged, rulesets may need to be merged to find rules for
all the fields in the TagUI form.
When multiple files are being tagged, the rulesets for all files are merged to
include all fields from all rules. Depending on the files being tagged, there may
be fields that are identified as Not Applicable in the TagUI form for a
particular file. These are fields that would not appear if a file is tagged alone.
The following files illustrate a very simple example of how rulesets are merged.
The rulesets files RS1.cfg and RS2.cfg define the items being displayed in the
tagging form. The metadata-rules.cfg file defines the files that use each
ruleset.
RS1.cfg
<?xml version="1.0" encoding="UTF-8"?>
<data-capture-requirements>
<ruleset name="RS1">
<root-container name="root" location="root">
<item name="itemA" pathid="itemA" >
<label>Item A</label>
<textarea >
<default>Item A default value</default>
</textarea>
</item>
<item name="itemB" pathid="itemB" >
<label>Item B</label>
<textarea >
<default>Item B default value</default>
</textarea>
</item>
</root-container>
</ruleset>
</data-capture-requirements>
RS2.cfg
<?xml version="1.0" encoding="UTF-8"?>
<data-capture-requirements>
<ruleset name="RS2">
<root-container name="root" location="root">
<item name="itemA" pathid="itemA" >
<label>Item A</label>
<textarea >
161
metadata-rules.cfg
<?xml version="1.0" encoding="UTF-8" ?>
<metadata-rules>
<cond vpath-regex=".*file1\.txt">
<rule name="RS1" />
</cond>
<cond vpath-regex=".*file2\.txt">
<rule name="RS2" />
</cond>
<cond vpath-regex=".*file12\.txt">
<rule name="RS1" />
<rule name="RS2" />
</cond>
</metadata-rules>
The file RS1.cfg defines Item A and Item B. The file RS2.cfg defines Item A
and Item C. The metadata-rules.cfg indicates files with names or vpaths
containing the string file1.txt are to be tagged as defined in RS1.cfg while
files containing the string file2.txt are to be tagged as defined in RS2.cfg
and file with names or vpaths containing the string file12.txt are to be tagged
as defined in both RS1.cfg and RS2.cfg.
When the user selects Item A, all files will have fields for entering metadata for
that value. When the user selects Item B, file2 will be marked as not applicable
and the field will not display. Similarly, when the user selects Item C, file1 is
marked as not applicable. The user can view and add metadata in all values for
file12 since it uses both rulesets RS1 and RS2.
An example that would be used to tag one file would be if the user selected a file
that satisfied the condition for *file12.txt shown as the third condition in
metadata-rules.cfg. Rulesets RS1 and RS2 would be merged to create the
tagging form for the selected file.
162
Using FormAPI
Extended attributes from an old data capture template are not consistent with
what was specified in the new data capture template.
The values for the extended attribute are not valid. When a file that was
previously tagged has a value that is no longer an option, the value will be
added to the select box; however, the label for that value is not shown.
Multiple select drop-down values (have multi="t") are saved in a single
The list changes through a CGI callout, a CLT, or by FormAPI. For example, if
value4 is added as a select value through a CGI callout, a CLT, or by
FormAPI, the select box will contain this additional value, even though it was
not included in the original ruleset definition.
Using FormAPI
Event handlers can be specified in JavaScript in the ruleset through the use of the
FormAPI <script> element. This can specify form-level or item-level event
handlers and perform tasks such as custom validation.
When rulesets with a <script> element are merged, the content of the
<script> elements are also merged.
163
164
Unique function names across rulesets are recommended; you may want to
prepend the ruleset name to a function name. For example, a ruleset named
validateMyData in ruleset1 could be renamed
ruleset1_validateMyData.
Avoid the use of the JavaScript function alert in TagUI rulesets. When
rulesets are merged, multiple alerts may occur, requiring the user to click each
one.
The JavaScript code in each <script> element should only contain the
function declaration and the event handler registration. Any other executable
code could be executed before FormAPI finishes initialization and the results
would be unpredictable and unrepeatable.
Troubleshooting JavaScript
You can insert debugger statements inside a <script> tag to debug and trace
execution of the code.
If the file is being tagged for the first time, TeamSite displays the metadata
automatically.
If the file has already been tagged, the user clicks Suggest to request
metadata from the IDOL Taxonomy Solution, which overwrites existing
metadata.
Create a Ruleset
Use the sample rule set in this section as the basis for your own rule set. The file
that defines the rule set must:
contain the tagEngineConfig attribute, which points to the mapping file that
you will create as described in Create a Mapping File on page 168.
165
All IDOL Taxonomy Solution items become <select> items. The original item
type is not relevant. However, the drop-down list does not behave like a normal
drop-down list and the user does not need to select any of the items.
The following example shows a rule set file named PDF_Files.cfg. It defines a
data form named Asset_metadata. Code to enable the IDOL Taxonomy Solution
is shown in bold.
This data form has two tabsNew Default and Details. It collects input from a
user in five data entry areas (Title, Keywords, Description, Creation Date, and
Expiration Date); the first two are IDOL Taxonomy Solution-enabled items. It uses
the IDOL Taxonomy Solution when the user chooses to add metadata, using the
projects defined in MT_PDFTitle (see Create a Mapping File on page 168).
<?xml version="1.0" encoding="UTF-8"?>
<data-capture-requirements>
<ruleset name="PDF_Files">
<root-container name="Asset_metadata" location="Asset_metadata">
<tab name="New Default">
<item name="PDF_title" pathid="PDF_title"
tagEngineConfig="metatagger://MT_PDFTitle">
<label>Title</label>
<description>Title description</description>
<textarea required="f" size="32" maxlength="60"/>
</item>
<item name="PDF_Keywords"
pathid="PDF_Keywords"tagEngineConfig="metatagger://MT_PDFTitle">
<label>Keywords</label>
<description>
Keywords can include terms that are not in the asset
itself.
</description>
<textarea required="f" size="32" maxlength="60"/>
</item>
<item name="PDF_Description" pathid="PDF_Description">
<label>Description</label>
<description>
A brief summary of 250 characters or less.
</description>
<textarea required="f" rows="5" cols="72"
wrap="virtual"maxlength="250"/>
</item>
</tab>
<tab name="Details">
<item name="Creation_Date" pathid="Creation_Date">
166
<label>Creation Date</label>
<description>
The date the asset was created, in the YYYY-MM-DD
format.
</description>
<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]$"/>
</item>
<item name="Expiration_Date" pathid="Expiration_Date">
<label>Expiration Date</label>
<description>
The date the asset should be retired, in the YYYY-MM-DD
format.
</description>
<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]$"/>
</item>
</tab>
</root-container>
</ruleset>
</data-capture-requirements>
NOTE Ensure that the maxlength attribute is set to a value large enough
to display all results for metadata suggestions. If maxlength is too small,
the display field truncates the returned result, and users may lose some of
the data that was suggested or be unable to edit the information.
NOTE Be careful if you plan to set the textarea required attribute to
true. When set to true, every IDOL Taxonomy Solution-enabled field
must have at least one value generated using the Suggest button. If a value
is not available, users cannot save the entire set of files they are attempting
to tag.
The container/item replicant is not supported if the item or items inside the
replicant container are IDOL Taxonomy Solution-enabled.
167
The data entry areas of the Asset_metadata form are mapped to Metatagger
projects as follows:
168
169
170
CHAPTER 8
171
iwwebd
iwproxy
servletd
Customer
Web server
TeamSite
File System
172
Redirect fully qualified URLs into TeamSite areas (see Redirect Fully
Qualified URLs on page 178).
Redirect browsing in one branch or workarea into another area (see Redirect
TeamSite Views to Different Areas on page 181).
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. When a rule matches a URLdepending on
the section in which the rule was specifiedeither an HTTP redirect is sent back
to the browser to indicate the new location or the URL is rewritten and passed to
the new section. The first rule that matches in any section prevails; no other rules
in that section are applied.
Figure 18 Processing proxy requests through the iw.cfg file
See Configure the Proxy Server to
Redirect Fully Qualified URLs.
Applies only if the browsers proxy is
set to the TeamSite proxy server.
iwproxy_fullproxy_redirect
iwproxy_remap
See Document Roots.
iwproxy_external_remap
iwproxy_preconnect_redirect
iwproxy_preconnect_remap
No
Yes
The specified page is returned.
iwproxy_failover_remap
173
where:
iwproxy_host specifies the host where the TeamSite proxy daemon runs.
Usually this is the TeamSite server.
The settings in the [iwproxy] section are set during the TeamSite installation.
They can be manually edited if necessary.
174
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
On a typical Web server, this link reference would be mapped by the Web server
to its document root, for example:
/images/miles.gif
)images\miles.gif
D:\inetpub\wwwroot\(Unix:usr\httpd/
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 sites 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
Y:\(Unix:iw-mount)default\main\branchpath\
WORKAREA\workareaname\images\miles.gif
175
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.
176
The first line 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
file
The two docroot configuration sections also contain lines similar to the following:
/pictures/=/pictures/
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.
177
Configure your Web browsers proxy to use the TeamSite Web daemon
(iwwebd).
178
179
Step 5.
5. In the Exceptions field, enter the URLs that you want to access without using
the proxy server.
180
6. Click OK.
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]
_regex=source_regex=dest_ex
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
181
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.
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
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 Chriss
to the staging area of branch2.
See Configure Proxy Failover on page 186 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 Redirect TeamSite
Views to Different Areas on page 181), edit the
[iwproxy_preconnect_redirect] section of iw.cfg:
[iwproxy_preconnect_redirect]
_regex=source_regex=dest_ex
182
[iwproxy_preconnect_remap]
[iwproxy_external_remap]
183
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:
[iwproxy_preconnect_remap]
_regex=source_regex=dest_ex
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.
184
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
185
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. On IIS, this information is
stored in C:\temp\iw_isapi.log. This log file can grow extremely large over
time.
186
Yes
No
iwproxy_preconnect_remap
iwproxy_hostheader_remap
iwproxy_smartcontextedit_allowed
No
iwproxy_failover_remap
Yes
The specified page is returned, if found.
If it is not found, the proxy server returns a
File not found message.
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
187
-x
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
188
189
190
CHAPTER 9
MediaBin Connector
This chapter describes the configuration of the MediaBin Connector. MediaBin
Connector provides Web content developers seamless access to the business
and creative content managed in MediaBin repositories when using TeamSite for
performing Web content management tasks.
The chapter includes the following topics:
MediaBin Configuration
Troubleshooting
191
Each server connector exists independently of the other. For example, you can
configure a guest login connector between your TeamSite and MediaBin servers.
Configuration of the connection to DigitalSafe, MediaBin and Optimost servers is
performed through the Connectors tab in the Administration Console.
192
193
194
Login as the TeamSite user. Login to the MediaBin server using the
same user name that was used to login to the TeamSite server. An
entry for this TeamSite user must be present in the LDAP used by
MediaBin.
Login with a MediaBin guest account. Login with the guest user
account you set up on the MediaBin server for use with your TeamSite
server.
Trusted Client:
Enter the hint required for trusted client access in the Hint field. This is
the same value as is used in the MediaBin web.config files
TrustedClientHint value.
Guest User:
Enter the MediaBin user name of the account in the Name field.
Enter the password associated with the user name in the Password
field.
Enter the directory within your TeamSite workarea in which any files
imported from the MediaBin server when using content templates are
written. Note that when you are importing MediaBin assets using the
Import command, files are stored in your current working directory.
4. After you have entered the appropriate attributes, click one of the following:
Save and Test to save the MediaBin connector properties and to test the
window.
Cancel to cancel the changes.
195
Enter the name of the MediaBin server hosting the Web services.
Enter the appropriate URL to point to the MediaBin web services in the
Web Services URL field. In most cases you can simply change the
host name in the default value.
Login with a MediaBin guest account. Login with the guest user
account you set up on the MediaBin server for use with your TeamSite
server.
Trusted Client:
Complete the following attribute if either the Login as the TeamSite user
or Try to login as TeamSite user, use MediaBin if unsuccessful option
was selected as your User Authorization Settings option.
Enter the hint required for trusted client access in the Hint field. This is
the same value as is used in the MediaBin web.config files
TrustedClientHint value.
Guest User:
196
Enter the MediaBin user name of the account in the Name field.
Enter the password associated with the user name in the Password
field.
Connection Timeout Setting: Enter the time in seconds before which the
Enter the directory within your TeamSite workarea in which any files
imported from the MediaBin server when using content templates are
written. Note that when you are importing MediaBin assets using the
Import command, files are stored in your current working directory.
iw-home/examples/Templating/templatedata/MediaBin/
press-release
iw-home/examples/Templating/templatedata/MediaBin/
press-release-immediate
iw-home/examples/Templating/templatedata/MediaBin/
press-release-iwov
Refer to the README file residing at the following location for descriptions of each
of these samples:
iw-home/examples/Templating/templatedata
This chapter assumes the reader is familiar with creating FormsPublisher
datacapture.cfg files and presentation templates. Refer to the TeamSite
FormsPublisher Developers Guide for more information.
197
datacapture.cfg
You can incorporate MediaBin functionality in your FormsPublisher form by
including a dialog for either or both remote servers in your associated
datacapture.cfg file. In the datacapture.cfg file, dialogs are configured
using the dialog element. Each dialog has a set of named parameters that are
used to connect the FormsPublisher form fields to the dialogs inputs and outputs.
Each parameter can have an input, an output, or both. An input parameter can
have an actual value, or it can reference an item whose value will be obtained
when the dialog is activated. An output parameter can only reference an item
whose value will be set by the dialog. The set of output parameters can be
different depending on whether the form is configured to import files from the
remote server immediately upon selection, or whether to wait until the Web page
is actually generated.
Dialog parameters reference items by name, not by path. When a dialog
references an item, it first looks for an item with that name in the same container
as the dialog itself. If it is not found, then it looks in the enclosing (parent)
container, and so on up the hierarchy.
You can configure the dialog element anywhere that an item element can
appear. The dialog element has the following attributes:
type. Specify one of the following values to indicate what type of remote
server is being represented:
mediabin
label. Specify the text that appears on the button, for example MediaBin.
The following configuration inserts a MediaBin field into the form, and gives the
associated button the label MediaBin:
<dialog type="mediabin" label="MediaBin">
...
</dialog>
The dialog element can also include the optional rowcontinue and
window-features attributes, which are used elsewhere in the
datacapture.cfg file. Refer to the FormsPublisher documentation for more
information.
Each parameter associated with the dialog is configured within the dialog element
as a separate dialog-param element. The type of parameter is specified by the
dialog-param elements name attribute. For example:
<dialog type="mediabin" label="MediaBin">
<dialog-param name="path">
...
198
</dialog-param>
...
</dialog>
Inputs and outputs are configured within each dialog-param element using the
dialog-input and dialog-output elements, respectively. Both these types
of elements include the field-ref sub-element, which associates the item
reference to the input or output.
In the following example, the parameter path includes both an input and an
output, while the parameter label includes only an output.
<dialog type="mediabin" label="MediaBin">
<dialog-param name="path">
<dialog-input><field-ref name="path"/></dialog-input>
<dialog-output><field-ref name="path"/></dialog-output>
</dialog-param>
<dialog-param name="label">
<dialog-output><field-ref name="label"/></dialog-output>
</dialog-param>
asset-id. The MediaBin ID value for the selected digital asset. The value
can later be used by the presentation template import tags to import the
selected asset. When you specify an input value, it indicates a
previously-selected asset that allows the browser to open up in the context of
that asset.
label. The default file name of the MediaBin asset you selected, or a
user-defined label value. The value you use will appear as the hyperlink text to
the MediaBin asset in the generated Web page.
path. Displays a path on the MediaBin server where the document file can be
accessed.
format. The desired format for the asset rendition. Use of the following
values:
GIF
JPG
JPEG
199
task. The name of the desired retrieval task. This parameter only applies to
MediaBin version 7.x or lower.
taskId. The ID of the MediaBin retrieval task. This parameter only applies to
MediaBin version 8.0.3 or higher.
Refer to your sample presentation templates that were installed with MediaBin
Connector to get additional usage information.
These tags require the IW_AUTH environment variable to be set to a valid value.
This variable will be set when the presentation template is invoked from the user
interface or a workflow external task. If you want to test the presentation template
from the command line, you must set this variable before calling the
iwpt_compile CLT.
200
When these tags are used in a presentation template, the template may not
function if it is applied from the command line (for example, using iwgen or
iwregen) or in a nonstandard execution environment. These tags require access
to a valid TeamSite session string. The session string is provided by
ContentCenter when the Preview or Generate commands are performed and is
provided by the workflow engine if the template is applied in an external task.This
IW_AUTH environment variable can be set to a valid session string if one is not
already available
You can also run the perldoc program to get more information on these tags. To
run this program, navigate to the following location:
iw-home/iw-perl/bin
where tagname is one of the MediaBin Connector tags listed at the beginning of
this section, for example:
perdoc.bat TeamSite::PT::iwov_import_mediabin
201
<attribute>
<name>Asset Type</name>
<value type="xs:string">JPEG</value>
</attribute>
<attribute>
<name>Dimensions (pixels)</name>
<value type="xs:int">300</value>
<value type="xs:int">300</value>
</attribute>
<dc:date.created>2004-10-19T09:50:00</dc:date.created>
...
</metadata>
202
http://www.w3.org/2001/XMLSchema
The following data types are represented:
boolean
dateTime
double
float
int
long
string
Title
Creator
Subject
Description
Publisher
Contributor
Content
Date
Type
Format
Identifier
Source
Language
203
Relation
Coverage
Rights
For the Dublin Core Date metadata element there are two qualifiers applied:
Created
Modified
This example shows the two elements representing MediaBins Asset Type
metadata: a Dublin Core dc:type element and an attribute element.
<dc:type>JPEG</dc:type>
<attribute>
<name>Asset Type</name>
<value type="xs:string">JPEG</value>
</attribute>
The following table lists MediaBin metadata elements that correspond to Dublin
Core metadata elements:
Table 10 MediaBin metadata elements
MediaBin
Dublin Core
Name
Title
Asset Type
Type
Check In User
Creator
Insertion Time
Date Created
Modified Time
Date Modified
Custom Metadata
MediaBin supports the generation of custom metadata. MediaBin custom
metadata associated with an asset is captured along with the system and file
format specific metadata.
204
MediaBin Configuration
MediaBin Configuration
This section contains instructions for configuring your MediaBin server for use
with the MediaBin Connector. The instructions here are supplemental to the
MediaBin product documentation.
The MediaBin Web Service README file contains information on configuring
MediaBin. This file is named readme.txt and resides in the following location:
c:\InetPub\www\MediaBinWebService
Troubleshooting
This information may provide information on issues related to MediaBin
Connector.
205
206
Troubleshooting
You can obtain this update from the following Microsoft Web site:
http://www.microsoft.com/downloads/
details.aspx?amp;amp;amp;amp;displaylang=en&familyid=8C6560FC-297C
-4982-8BA5-DE7949043B17&displaylang=en
207
208
CHAPTER 10
Back 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.
This chapter includes the following topics:
209
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 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 theTeamSite file system mount (Y:/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 Store 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 TeamSite
Command-Line Tools for your platform.
210
211
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 days
backup, no history of the Content Store will be retained, but the amount of storage
space used by the backups is minimized.
212
Appendixes
Internationalization
Single Sign-On
Troubleshooting
Appendixes
214
APPENDIX A
Internationalization
This appendix includes the following topics:
Overview
Supported Content
About UTF-8
Usage Scenarios
215
Appendix A Internationalization
Overview
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, French, German, Korean,
Simplified Chinese, Traditional Chinese, and Japanese (one locale per
instance of iwserver).
Localized file names. You are no longer restricted to having file and directory
names in ASCII character encoding. For example, 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 so forth.
216
Supported Content
added files with names 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.
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 the TeamSite 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) before TeamSite server is started, the TeamSite
server would incorrectly interpret the imported file and directory names as
ja_JP.PCK 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, and child directories have file names encoded in ja is not
supported.
217
Appendix A Internationalization
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 locales encoding.
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.
218
.html
would be:
/iw/iw-cc/edit?vpath=/archive/main/WORKAREA/area/%e5%ba%9c.html
219
Appendix A Internationalization
220
Allowed Languages
(browser's settings)
Japanese or English
Korean or English
English only
utf-8, utf-16be,utf-16le
Default Code
Page
English
1252
437
German
1252
850
To avoid this issue, complete the following procedure before running any CLT on
SBCS systems.
1. Open the DOS command window.
2. Right-click on the command windows title bar and choose Properties from
the menu.
The Properties dialog box is displayed.
3. Click the Font tab.
4. Select Lucida Console font from the Font list, and click OK.
The Apply Properties dialog box is displayed.
5. Select Save properties for future windows with same title, and click OK.
6. At the DOS prompt, type chcp and press Enter.
The system returns the active code page number: 437 for English systems, or
850 for German systems. Record the code page number so you can revert to
the default code page for commands that require it.
7. Type chcp 1252 and press Enter to change the code page to 1252.
The system confirms the active code page is set to 1252. All command
window input and output will use this code page.
221
Appendix A Internationalization
222
Appendix A Internationalization
Platform
Notepad
Windows
Wordpad
Windows
Default
Encoding
To Save as UTF-8
Encoding:
ANSI (relative
to the localized
operating system)
vi
Solaris
Depends on the
locale of vis active
process.
emacs
Solaris
Depends on the
locale of emacs
active process.
Scenario 1
1. A Japanese user goes to a Japanese site which does not specify its encoding.
Netscape defaults to Japanese (Auto-Detect).
2. The Japanese user logs into TeamSite (UTF-8 pages). Netscape switches to
UTF-8.
3. The Japanese user opens a new window and returns to the Japanese site
which does not specify its encoding. Now Netscape defaults to UTF-8.
This would not happen if the site specified the encoding of its web pages.
223
Appendix A Internationalization
Scenario 2
1. A Japanese user logs into TeamSite (UTF-8 pages). Netscape switches to
UTF-8.
2. The Japanese users content in TeamSite does not include the Content-type
META tag.
3. Upon entering SmartContext QA, Netscape tries to render the content as
UTF-8, which is probably wrong. The solution to this problem is to always
specify the encoding for all HTML content.
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.
224
Usage Scenarios
Scenario 1
1. The TeamSite server is running in the Windows Japanese /ja_JP.PCK
(Shift-JIS)locale on Solaris.
2. You create a branch with a Japanese name using ContentCenter running on
Japanese Windows. This branch is created in the TeamSite File System with
Windows Japanese/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 (Windows Explorer).
Scenario 2
1. The TeamSite server is running in the Windows Japanese /ja_JP.PCK
(Shift-JIS)locale on Solaris.
2. Your TeamSite Administrator copies a directory from the Windows Explorer file
system into the TeamSite File System. This directory contains file and
directory names with Japanese encoded names.
3. Your TeamSite Administrator creates a file in the TeamSite 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.
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 is a Shift-JIS locale.
2. You create a branch with a Japanese name using ContentCenter.
This branch is displayed in /iwmnt as a directory with a Shift-JIS encoded
directory name and is displayed 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.
225
Appendix A Internationalization
The file and directory hierarchy display with Japanese directory and file names
and is correctly referenced in ContentCenter.
Scenario 5
1. Type an iwsubmit command in a shell window running on a Japanese
system.
2. Create submit comments in Japanese.
3. Execute the iwsubmit command. In ContentCenter, the Japanese submit
comments are displayed correctly with the corresponding entity submitted.
Scenario 6
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.
226
APPENDIX B
regex_map Defined
227
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:
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"
228
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
Each rule within <regex_map> is evaluated in order, 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.
229
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
rules 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.
When there are no reg_ conditions, the assignment always executes if the
rule is encountered. Any rules that occur after this statement are unused.
230
Variables
Variables store strings to be passed in the following ways:
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 236
contains an example of factoring.
Intermediate variables should have names that begin with x_ to avoid conflicts
with application variables that may be created in the future.
231
regex_map
<regex_map>
<subst val_french="${good}jour"/>
<match val_friend="copain"
val_french="$french, $my $friend!"/>
</regex_map>
Output Variables
good
my
friend =
french =
= "Bon"
= "mon"
"copain"
"Bonjour, mon ami"
In the <subst> rule, curly braces ({ }) are required to separate the variable
name good from the literal string jour that immediately follows.
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.
232
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!"
The first rule does not apply because the value of the text variable does not
match the regular expression in reg_text.
233
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
Quoting
Inside a val_ attribute, dollar signs ($) have special meaningthey 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.
234
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.
Table 14 XML Special Characters
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;"/>
235
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>
236
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.
237
ISO-8859-1
ISO-8859-15
windows-1252
Japanese:
238
Shift_JIS
EUC-JP
Korean:
EUC-KR
Simplified Chinese:
EUC-CN
GB2312
Unicode:
UTF-8
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
<?xml version="1.0" encoding="UTF-8"?>
<!-- Input variable: vpath -->
<!-- Output variable: encoding -->
<vpath_to_encoding_map>
<!-- Ignore upper and lower case when
evaluating reg_vpath and reg_encoding conditions. -->
<regex_map opt_case_insensitive="vpath encoding">
<!-- Set the default result. A default like this is highly
recommended. -->
<subst val_encoding="8859_1"/>
<!-- Make a note of Japanese files scattered about. -->
<subst reg_vpath="(?:_ja|_jp|_jpn)\."
val_x_lang="Asian:Japanese"/>
<!-- Likewise with Chinese files. -->
<subst reg_vpath=".*\.zh\.txt$"
val_x_lang="Asian:Chinese"/>
<!-- As site policy, our Japanese files are Shift-JIS -->
<subst reg_x_lang="Asian:Japanese"
val_encoding="Shift-JIS"/>
<!-- As site policy, our Chinese files are Big5 -->
<subst reg_x_lang="Asian:Chinese"
val_encoding="Big5"/>
239
240
APPENDIX C
Single Sign-On
This chapter describes the procedure for configuring TeamSite to integrate with
single sign-on (SSO) authentication products. These products include SiteMinder
from Computer Associates as well as authentication software from other vendors.
The integration enables:
A single sign-on where TeamSite users log in once against the SSO
authentication engine 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.
Overview
Troubleshooting
241
Overview
TeamSite provides a framework providing integration with SiteMinder. You can
also use this framework to integrate SSO products from other vendors. See the
TeamSite Release Notes for details about which SSO products are currently
supported.
After completing the integration described in this chapter, the SSO product
controls access to TeamSite by authenticating the user against its user database
and placing an authentication cookie in the browser. Three different integration
scenarios are described in detail:
242
Prerequisites
The following conditions must already be met before you start this procedure:
Overview
With this configuration, two credential verifications are performed when a user
signs on through the SiteMinder system. First, SiteMinder authenticates the user
and sets an SMSESSION authentication cookie. Upon successful authentication by
SiteMinder, the SiteMinder Policy Server opens an encrypted channel to the
TeamSite authentication service, and the user is authenticated by TeamSite.
Following successful authentication by TeamSite, a TeamSite IWAUTH
authentication cookie is set, and the user is able to access TeamSite.
Advantages to this configuration include the following:
It makes it possible set up a system that has some users that authenticate
using the SSO system and some that use standard TeamSite authentication.
Both authentications are controlled by SiteMinder, and are done in the context
of a secure SiteMinder server.
It can be used with various older TeamSite servers, as well as with current
products.
243
Browser
2
3
8
9
10
6
9
TeamSite servletd
(Content Services)
10
244
Integration Procedure
Performing this integration involves the following main steps:
Install and Configure the SiteMinder Web Agent on the TeamSite System.
245
Realm Type
Resource Filter
protected_iw
Protected
/iw
unprotected_iw
Unprotected
/iw/services/cm/2.0/
accessservice
Description
Authenticate_iw - iw*
Protected_iw - iw*
246
Table 17 Response
Field
Entry
WebAgent-OnAccept-Redirect
Attribute Kind
Active Response
Library Name
UNIX: full_path/iwtssmar.so
Windows: full_path\iwtssmar.dll
Function Name
activeResponse
247
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. If you are using an LDAP system and the UNIX account name is not a
component of the Distinguished Name (DN) of the systems users, you must
tell the Active Response module where to find a users UNIX account name.
To do this, set an additional environment variable called
INTERWOVEN_USER_ATTR to the LDAP attribute that holds the UNIX account
names. This is typically uid. For example:
export INTERWOVEN_USER_ATTR=uid
248
249
Prerequisites
The following conditions must already be met before you start this procedure:
Overview
This configuration does not require the installation of any proprietary software on
the SiteMinder Policy Server, and requires no connection between the Policy
Server and the TeamSite authentication service. With this approach, users are
authenticated solely by SiteMinder, and there is no additional TeamSite
authentication step. SiteMinder verifies the users password, sets an SMSESSION
authentication cookie, and passes the users identity to TeamSite through a
session cookie or HTML header parameter. TeamSite prepares an IWAUTH
access cookie based on the users identity, and does not perform any further
credential check.
The advantages of this approach are that there is no requirement to install an
authentication plug-in in the SiteMinder Policy Server, and there is no need to
open a communication channel between the Policy Server and the TeamSite
authentication service.
The typical sequence of data and operation flow following integration is depicted
in the following figure and described in the legend that follows.
250
Browser
2
3
6
7
8
TeamSite servletd
(Content Services)
8
251
Integration Procedure
Performing this integration involves the following main steps:
Configure TeamSite.
252
Realm Type
Resource Filter
protected_iw
Protected
/iw
Description
Action
iwCookieRule
Authentication event
onAuthAccept.
If you are using an HTTP header parameter instead of a session cookie, use
the following rule:
Table 20 Rules
Rule Name
Description
Action
iwHeaderVarRule
Sets a header
parameter upon
successful
authentication.
Authentication event
onAuthAccept.
253
Entry
Name
iwCookieResponse
Description
Agent Type
WebAgent-HTTP-Cookie-Variable
Attribute Kind
User Attribute
Attribute Name
uid
Variable Name
IW_UNAME
254
Table 22 Response
Field
Entry
Name
iwHeaderVarResponse
Description
Agent Type
WebAgent-HTTP-Header-Variable
Attribute Kind
User Attribute
Attribute Name
uid
Variable Name
IW_UNAME
Table 23 Response
Field
Entry
Name
iwDomainResponse
Description
Agent Type
WebAgent-HTTP-Cookie-Variable
255
Table 23 Response
Field
Entry
Attribute Kind
User Attribute
Attribute Name
domain
Variable Name
IW_UDOMAIN
If you are using an HTML header parameter for the domain name:
Table 24 Response
Field
Entry
Name
iwDomainResponse
Description
Agent Type
WebAgent-HTTP-Header-Variable
Attribute Kind
User Attribute
Attribute Name
domain
Variable Name
HTTP_IW_UDOMAIN
6. If the protected_iw realm does not already have a policy, create one with
the following settings:
.
Table 25 Policy
Policy Name
Enabled
iw-policy
Yes
If you configured the system to pass user information in the session cookie, in
the Rules tab select Add/Remove Rules. Select iwCookieVarRule that
you created earlier and add it to the policy. After you add the rule, select
Select Response to tie iwCookieVarResponse to the rule.
If you configured the system to pass user information in an HTML header
parameter (rather than in the session cookie), in the Rules tab select Add/
Remove Rules. Select iwHeaderVarRule that you created earlier and add
it to the policy. After you add the rule, select Select Response to tie
iwHeaderVarResponse to the rule.
256
Configure TeamSite
The TeamSite configuration described here is performed through the UI toolkit. All
of these Java parameters are customized by entering their values as
default-param subelements in the applications element of the
application_custom.xml file. See the TeamSite User Interface
Customization Guide for details about setting parameters in
application_custom.xml.
The default value for this parameter is false; to enable SSO, it must be set to
true.
2. Verify that the name of the SSO cookie set by the SSO package is already set
to SiteMinders default of SMSESSION. The setting should appear as shown
here. If it does not, reset it accordingly:
iw.common.authentication.ssoCookieName=SMSESSION
If you choose to set a cookie, set ssoUserCookie to the variable name that
you specified in Step 5 in the preceding section:
iw.common.authentication.ssoUserCookie=session_cookie_name
4. On Windows systems, if your user directory does not contain an attribute for
each TeamSite user in the form domain\user, domain/user, or
257
Prerequisites
The following conditions must already be met before you start this procedure:
TeamSite and the SSO product share the same user database.
Overview
This configuration does not require the installation of any proprietary software in
the SSO system. Authentication is delegated completely to the SSO system,
without TeamSite playing a role. This approach accommodates a variety of
different SSO products from different vendors. To use an SSO system with
TeamSite, it must be able to pass the authenticated users account name to
TeamSite upon completion of authentication. This may be done using an HTTL
header parameter or a browser session cookie.
The typical sequence of data and operation flow following integration is depicted
in the following figure and described in the legend that follows.
258
Browser
2
3
6
7
8
TeamSite servletd
(Content Services)
8
259
Integration Procedure
Performing this integration involves three main steps:
Configure TeamSite
domain\user
domain/user
user@domain.com
Configure TeamSite
TeamSite configuration is performed through the UI toolkit. All of the parameters
are located in the application_custom.xml file. See the TeamSite User
Interface Customization Guide for details about setting parameters in
application_custom.xml.
The default value for this parameter is false; to enable SSO, it must be set to
true.
260
Troubleshooting
2. Verify that the name of the SSO cookie set by the SSO package is already set
to SiteMinders default of SMSESSION. The setting should appear as shown
here. If it does not, reset it accordingly:
iw.common.authentication.ssoCookieName=SMSESSION
4. On Windows systems, if your user directory does not contain an attribute for
each TeamSite user in the form domain\user, domain/user, or
user@domain.com, you may need to send the domain information
separately in a different session cookie or HTTP header parameter.
If you choose to set a header parameter, set it as follows:
iw_common.authentication.ssoDomainParam=header_parameter_name
Troubleshooting
Troubleshooting the SiteMinder Web Agent
If the Web Agent is configured correctly, you should see the SiteMinder login
dialog when you attempt to visit a TeamSite web page. If the SiteMinder dialog
does not appear, it may be due to one of the following errors:
261
If the SiteMinder dialog appears correctly, then after entering the user name and
password for a valid TeamSite user, you should see the TeamSite page you
requested. If, instead, you see a TeamSite login page, then TeamSite did not
detect an IWAUTH session cookie, either because one was not created, or
because it was created in the wrong domain.
If the IWAUTH cookie is not present, it may be because the user is present in the
SiteMinder user database, but he is not a valid TeamSite user. Make sure that the
user is present in the tsusers.xml file.
Netscape and Mozilla Firefox web browsers provide a cookie manager option
that displays the value of all cookies, including session cookies. If an IWAUTH
cookie is present, but its domain does not match the path you typed for the
TeamSite web page, you may need to make changes to your Web Agent
configuration file, or to your systems DNS settings to correct this. If the IWAUTH
cookie is absent completely, and the user is a valid TeamSite user, then the
problem is probably due to a SiteMinder Policy Server configuration error. If you
are using a session cookie to pass the user name to TeamSite, make sure that the
cookie is set as expected, and that its name matches the name you have selected
in the TeamSite application.xml configuration file.
262
Troubleshooting
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.
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.
Failed to send query to server.
This message is written to the log file if the SSL channel to the TeamSite server
fails.
Failed to get session string from server.
This message appears if the supplied user name 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.
263
264
APPENDIX D
Troubleshooting
This appendix contains miscellaneous information regarding a variety of
troubleshooting issues. In addition to the suggestions that follow, Consulting
Services and Technical Support can assist you with any configuration issues you
might encounter.
265
Appendix D Troubleshooting
Install/Remove Programs
On
Unix:
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
The VisualAnnotate toolbar does not automatically display on Windows XP. Select View >
Toolbars> Visual Annotate to turn on the toolbar.
JVM
When editing a file in ContentCenter Professional, the editor goes to the background and the Local
File Manager is displayed. This applies when using a Sun JVM plug-in instead of the browsers
built-in JVM in Windows.
IIS (Windows)
266
Flexible Roles
If a logged-in user is assigned a new role in a branch, the user should refresh the ContentCenter
screen before attempting to open a workarea in the branch.
267
Appendix D Troubleshooting
268
Glossary
A
Administrator
An out-of-the box role configured for 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.
approve
assign
To lock a file for the use of a specific Author and attach comments. A list of
assigned files is displayed in the Authors Task list. Editors can also view a
list of files that they have assigned.
attribute search
Author
An out-of-the box role configured for 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 Authors Task list.
269
Autoprivate
branch
casual contributor
category
When editing roles, categories are groupings of operations that users can
perform within a role.
270
collection
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
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
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
ContentCenter
Professional
ContentCenter Standard
contributor
convert
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.
271
data record
delegated administration
edition
Editor
form
The form generated by a data capture template. A contributor fills out a form
to create a data record. A form is displayed 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 users workarea, and are available to recall and use as
necessary.
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.
272
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 Developers
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.
groups
TeamSite groups are a collection of users who can access branches and
share workareas. TeamSite groups complement the operating system
groups that may exist.
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.
273
L
locking
Restricting file access within a branch. Locking a file reduces the possibility
of conflicting edits but also reduces the teams 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 or for a specific role when the role is created.
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.
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
An out-of-the box role configured for 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,
creates roles, assigns operating system users, and can also perform all
functions on all branches. Master users have access to the ContentCenter
Professional Administration Console.
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 TeamSites Advanced File Merging.
metadata
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.
274
O
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. Under the Optional Write Lock model,
locking files ensures serial development of those files and reduces the risk of
conflicting edits.
output file
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.
275
preview
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
publisher
Reviewer
An out-of-the box role configured for users who are responsible for reviewing
content prepared by other users.
role
A collection of operations that are assigned to users. These are stored in the
roles.xml file. Master users configure roles to meet the needs of their
installation.
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 results
276
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
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
users 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 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
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 files tags, use search
functionality, or use a product such as MetaTagger.
277
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
type
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 person who has been set up to be a TeamSite user and is assigned specific
roles in various TeamSite branches. A Master user has additional
responsibilities for maintaining TeamSite and adding users, creating roles,
and so forth.
278
V
version
VisualPreview
A tab that is displayed on an output page that allows you to perform various
TeamSite functions.
279
Web site
workarea
workflow
workflow model
280
Index
A
absolute paths 175
access 132
branch 99
inherit 97
privileges, to TeamSite 101
restricting 97
to files 102
ACEs
about 137
changing at submit time 138
ACLs
about 137
changing at submit time 135
Active Directory 129
Active Response Module 249
adding
users to TeamSite 102
admin_roles 95
administration
creating branches 96
integrating content 97
Administrators
defined 29, 269
Advanced File Merging
defined 269
anonymous binds 129
application variables 231
approve
defined 269
area relative path 36
assign
defined 269
assigning files 29
attribute search
defined 269
attributes
filtering 135
in LDAP schemas 128
authenticate_by 131
authentication 133
external file 121, 131
LDAP 121, 131
local 131
modes 131
PAMs 131
password 101
setting type 121
users 131, 242
Authors
defined 29, 269
Autoprivate
defined 59, 270
matching
filenames 60
patterns 59
autoprivate.cfg
encoding 61
format 59
location 59
sample 61
special characters 60
available_templates.cfg 73
B
backups
Content Stores 209
multiple stores 211
of workareas 210
strategies 211
281
Index
branch_default_perm 110
branch_owner_role 95
branch_security 109
branches 94
administrator 95
creating 96
defined 26, 270
inherit access 97
locking models on 57, 94
managing 98
owner 95
private 94
properties 99
read access 109
remappings, configuring 176
restricting access 97
security 109
sharing content among 97
structure 35
browsers
clearing cache 40
C
cache size
configuring 68
cachesize 68
caching 267
captured subexpression 232
casual contributor
defined 270
changing
file attributes, on submission 135
group ownership of workareas 118
permissions, on directories 103
TeamSite file locations 85
TeamSite mount 86
characters
non-ASCII 217
charset parameter, content encoding 222
checking
disk space usage 88
for multiple servers 78
282
request handling 78
server status 76
chgrp command 118
CLTs
code page requirements 221
defined 270
iwchgrp 118
iwfsshrink 90
iwgetelog 81
iwgettrace 81
iwldapsync 129
iwstat 83
iwtestcfg 141
iwutildreset 64
iwutildstat 64
code pages 221
collection
defined 270
command trigger
defined 270
command-line tool
defined 270
comments
defined 270
compare_search_limit 58
comparing
defined 271
Composite search
defined 271
configuration files
available_templates.cfg 73
iw.cfg 39
list of 46
locations 85
configuring
Autoprivate 59
branch and workarea security 109
branch remappings 176
cache size 68
Content Store freezes 70
default permissions
on files 110
convert
defined 271
creating
branches 96
editions 29
workareas 102
customer_webserver_host 174
customer_webserver_port 174
D
DAS Publishing 67
data record
defined 272
printing 74
data_root 73
datacapture.cfg 153, 198
annotated example
rule identifier 158
UTF-8 encoding 158
validation-regex 159
configuring 153
DataDeploy
enabling DAS publishing 67
debug_adsi 116
debug_event_handler 141
debug_output 53
debugging
proxy server configuration 188
submit filtering 141
default
code pages 221
drive (Y:) 79
file permissions 110
user authentication 131
default_protocol 56
iwov_webdesk_url tag 56
iwsend_servlet_mail.ipl script 56
delegated administration
defined 272
deleting
branches 91
editions 89
283
Index
device drivers
kernel 80
directories
permissions 103
directory structure
copying 72
directory_default_perm 110
disable_ext_task_impersonation 69
disabling
VisualPreview 52
disk cache
users/group/role 116
disk space
checking usage 88
compression 89
conserving 90
file system mount 34
low 70
managing 88
moving the Content Store 91
recovery 89
removing old versions 91
removing unused branches 91
usage 89
disklow_knodes 70
disklow_mbytes 70
disklowpercent 70
document root
configuring 176
defined 176
mapping 176
domain local groups 114
domain_list 52, 134
domain_local_groups 112
domains
configuring, in the login screen 52
for group authentication 134
DTD
metadata-rules.cfg 149
E
editions
284
creating 29
defined 27, 272
deleting 89
initial, defined 273
see also publishing editions
Submit logs 90
Editors
defined 29, 272
email
corrupted 266
domains 53
incorrect display 266
mapping files 53
servers 53
settings, for workflow 53
tasks 53
email_mapping_file 53
Embedded Failsafe 74
enable_user_group_disk_cache 116
enabling
VisualPreview 52
encoding 55
charset parameter 222
file_encoding.cfg 222, 239
html files 227
IANA preferred names 238
Merge tool 238
META tag 222
setting in iw.cfg 55
Single Byte Character Sets 221
Source Differencing tool 238
specifying 222
text editors 223, 237
text files 227
Unicode 218
UTF-8 218, 237
valid charsets 238
visual differencing 239
vpaths 227
environment variables
LANG 71
SiteMinder 247
event subsystem 65
events 65
publishers 66
subscribers 66
event_log_size 59
events log 81
locating 81
example templating environment 72
copying 72
extended attributes 145
migrating 163
modifying 55
external remappings, configuring 183
F
failover see proxy server
file system
mount 34
performance, improving 87
structure 35
file_default_perm 110
file_encoding.cfg
content encoding 222
defined 227
Merge tool 238
sample file 239
Source Differencing tool 238
UTF-8 237
valid encodings 238
visual differencing 239
VisualPreview 238
files
access to 102
assigning 29
autoprivate.cfg 61
available_templates.cfg 73
changing attributes of 135
comparing 58
configuration 227
datacapture.cfg 153, 198
default permissions 110
editing 267
encoding 227
file_encoding.cfg 222, 227, 239
histories, defined 273
iw.cfg 39
iwauthend.log 134
iw-bridge_cfg 47
iwevents.log 81
iwinstall.log 81
iwjoberrors.log 82
iwserver.log 81
iwtrace.log 77, 81, 134
iwutild.cfg 61
log 134
metadata-rules.cfg 149, 150
modification time 54
pam.conf 132
permissions 103, 110
private 59
sample metadata-rules.cfg 150
sample submit.cfg 143
setting permissions on 102
sharing among branches 97
submit.cfg 135
submitting locked 58
tagging 146
timestamp 55
user_databases.xml 121
virtual 35
filtering, on file submission 135
finding the installation directory 80
font message 266
force_EA_mod_times 55
form entry
defined 272
form item
defined 272
FormsPublisher
configuring 72
freezing the Content Store 70
full-text search
defined 273
fully qualified paths
285
Index
G
Get Latest
defined 273
global_default_map 176
groups
adding user 118
authenticating domains 134
creating 117
defined 273
domain local 114
global 113
improving performance 114
membership 117
nested 116
NFS limitations 120
operating system 117
remapping 120
TeamSite 96
universal 113
UNIX 117
Windows 112
H
histories
defined 273
honor_setgid 120
honor_setgid_on_rename 120
host 56
host headers, remapping
see proxy server
http_port 56
https_port 56
I
IANA charset names 238
IFS volume 79
IIS
and the server mount 79
impersonate_without_password 69
286
include_nested_groups 116
inherit from parent 97
inode count 70
installation directory, locating 80
intermediate variables 231
internationalization
browser behavior 223
client and server 217
encoding setting in iw.cfg 55
file_encoding.cfg 227
IANA charset names 238
iw.cfg settings 70
recommendations 222
regex_map 237
server_locale setting 70
text editor encoding 223
Unicode 218
UTF-8 218, 237
VisualPreview 227
vpath encoding 227
Interwoven Merge tool 227
IP addresses, changing 84
iw_bridge_cfg.xml 47
iw.cfg 39, 70, 73, 132
about 39
access 43, 94, 95, 109, 112, 114, 116, 120, 129
admin_roles 95
and the proxy server 176
authenticate_by 131
authentication section 131
branch_default_perm 110
branch_owner_role 95
branch_security 109
cachesize 68
changing the templating directory 73
compare_search_limit 58
configuration options 40
Content Stores 45
customer_webserver_host 174
customer_webserver_port 174, 176
data_root 73
debug_adsi 116
debug_event_handler 141
debug_output 53
default_protocol 56
directory_default_perm 110
disable_ext_task_impersonation 69
disklow_knodes 70
disklow_mbytes 70
domain_list 52, 134
domain_local_groups 112
email_mapping_file 53
enable_user_group_disk_cache 116
encoding 55
event_log_size 59
file_default_perm 110
force_EA_mod_times 55
format 39
FormsPublisher 42, 73, 74
honor_setgid 120
honor_setgid_on_rename 120
host 56
http_port 56
https_port 56
impersonate_without_password 69
include_nested_groups 116
iwproxy_host 174
iwproxy_port 174
iwproxy_smartcontextedit_allowed 52
iwutild_runas_root 64
ldap_sync_retry 129
ldapcache_thread_delay 129
list of options 41
locating 40
lockmodel_compatibility 58
log_ldap_sync 129
maildomain 53
mailserver 53
main_group 94
main_lock_model 58
main_owner 94
maintaining preview files 73
map_secondary_to_primary_gid 120
mask_workarea_access 109
old_mod_times 54
only_lock_owner_creator_submits 58
pam_do_acct_mgmt 132
pam_service 132
password_file 131
pretty_print_dcrs 74
preview_history_limit 73
printing data records 74
proxy server 44
secondary_admin_account 95
server functionality 41, 54, 55, 56, 58, 59, 64
server performance 42, 68, 69, 70
server_locale 70
servlet_port 56
setting ports 56
show_user_list 134
specifying preview directory 73
submit filtering 44
thruputmonitoring 69
UI functionality 41, 52, 53, 54
use_adsi 113
use_mapping_file 53
utild_ext_tasks_portnum 64
valid_domains 54
webserver_group 119
webserver_uid 119
windows_groups_for_sharing 114
windows_groups_for_users 114
workarea_default_perm 110
workarea_security 109
workflow 45
iwauthend 133
iwauthend.log 134
iwchgrp 118
iwevents.log 81
iwfsshrink 90
iwgetelog 81
iwgettrace 81
iwinstall.log 81
iwjoberrors
log file 82
iwjoberrors.log 82
287
Index
J
Java servlet engine 56
jobs
defined 31, 273
K
kernel device driver 80
288
iwserver.log 81
iwtrace 134
iwtrace.log 81
reviewing 80
server 81
submit 59, 90
trace 81
update 59
workflow 82
log size 59
log_ldap_sync 129
logging
users and groups 134
logging in
authentication 101
login
screen, configuring domain lists 52
low disk space 70
low inode count, detecting 70
M
macro expansion 141, 143
macros 142
expansion 143
maildomain 53
mailserver 53
main branch
defined 274
locking model 57
ownership 94
main_group 94
main_lock_model 58
main_owner 94
Manage Branches screen 98
mandatory write locking 57
defined 274
map_secondary_to_primary_gid 120
mask_workarea_access 109
Master
defined 30, 274
secondary 95
MediaBin
289
Index
MultiStore
backing up 211
N
Native Mode Active Directory 112
Navigation Window
defined 274
nested groups
disabling 116
Netegrity 241
New Branch screen 96
new users
adding 102
NFS exports 36
NFS, group limitations 120
non-ASCII characters 217
non-OS users 121
impact 130
Notepad, saving documents as UTF-8 223
O
old_mod_times 54
only_lock_owner_creator_submits 58
operating system groups 117
optional write locking 57
defined 275
OS groups 118
output file
defined 275
override permissions 103
ownership
branch 94
workareas, changing 118
P
PAM
account management 132
and TeamSite 132
authentication 133
configuring 132
defined 131
290
defined 276
files 59
properties
branch 99
proxy server
about 172
configuring
applying changes 174
basic operation 174
overview 171
to use different webservers 183
debugging 188
document roots 177
external remappings 183
failover 186
fully qualified paths
Internet Explorer 180
resolving 178
server configuration 179
host header remappings 185
host name 174
port number 174
redirecting TeamSite views 181, 182
relative and absolute paths 175
remapping document roots
rules of precedence 173
SSI remapping 186
public
defined 276
public URL protection 53
publisher
defined 276
publishing
defined 276
publishing editions 29
R
RCS macro expansion
about 141
enabling 143
reconfiguring IP address 84
recovering disk space 89
S
SCE
see VisualPreview
schemas
291
Index
LDAP 132
search
composite 271
full-text 273
secondary_admin_account 95
server
load, monitoring 83
locales 70
mount errors 79
mount, verifying 79
multiple 78
operations
verifying 76
resources
disk space 88
managing 85, 87
starting 77
status, checking 76
stopping 77
server log
location 81
server mount
verifying 79
server performance
configuring 68
server shut down
unexpected 265
server_locale 70
servlet
engine 56
port 56
servlet_port 56
setgid behavior 120
settings
email, for workflow 53
encoding 55
server_locale 70
show_user_list 134
Single Byte Character Set (SBCS) 221
single sign-on 241
Site Rollback
defined 277
292
T
tag
defined 277
Tagger GUI
reverting to original 153
TagUI
configuring 149
features 146
next generation 146
select box entries 163
task list
defined 278
tasks
defined 32, 278
email 53
ownership 104
states 32
transitions
defined 278
TeamSite
architecture 32
configuration files 46
disk space usage 88
file locations, changing 85
groups 96
internationalized 216
mount, changing 86
proxy server
iwwebd 171
overview 172
see also proxy server
server
answering requests 78
enhancing performance 87
mounting 79
process 78
resetting 78
restarting 77, 78
starting 77
stopping 77, 78
UNIX permissions 103
web daemon 171
templatedata directory
copying to workarea 72
templates
defined 278
templating directory
changing 73
templating environment
example 72
templating.cfg
defined 278
text editor encodings 223, 237
throughput monitors 69
thruputmonitoring 69
timestamps 54
trace log
debugging information 141
location 81
troubleshooting 263, 265
Content Store 266
email 266
flexible roles 267
IIS 267
JVM 266
MediaBin Connector 205
navigating 267
permissions 268
server shut down 265
shared memory 266
SiteMinder Policy Server 263
Unix installation 266
virus scanning 267
trusted clients 61
U
Unicode 218
universal groups 113
UNIX permissions 103
unlock
defined 278
URL commands
multibyte characters 218
use_adsi 113
use_mapping_file 53
user interface
configuration 51
293
Index
V
valid_domains 53, 54
variables
application 231
captured subexpression 232
intermediate 231
naming convention 231
regex_map 231
verifying server mount 79
version path 36
versions 58
defined 279
viewing
branches and workareas 109
virtual files 35
virus scanning 267
VisualPreview
defined 279
disabling 52
294
enabling 52
encoding of text files 227
file_encoding.cfg 238
localizing 220
tool bar 52
vpath 36
defined 36
vpaths, encoding mappings 227
W
web browsers, interpreting encoding 223
web content, specifying encoding 222
web daemon
about 172
configuring 171, 174
setting defaults 56
web servers
configuring 183
group 119
host name 174
plugins 174
port number 174
starting and stopping 174
uid 119
Web site
defined 279
development 27
webserver_group 119
webserver_uid 119
Windows
Event Viewer 83
permissions and TeamSite 103
Task Manager 76
Windows groups 112
Windows network 113
windows_groups_for_sharing 114
windows_groups_for_users 114
Wordpad, saving documents as UTF-8 223
workarea_default_perm 110
workarea_security 109
workareas
changing group ownership 118
creating 102
defined 26, 279
locking files in 58
ownership changes 119
permissions 103
permissions on directory 109
read access 109
security 109
workflow
defined 279
jobs
defined 31
tasks
defined 32
workflow log
locating 82
workflow models
and jobs 31
assign-edit-approve 30
defined 30, 279
WorkflowAdmin
defined 30
WorkflowUser
defined 30
Write locking
see also Optional Write locking, Mandatory Write
locking
X
XML
datacapture.cfg 153
metadata-rules.cfg 149
regex_map language 227
special characters 235
Y
Y: drive (default TeamSite drive) 79
295
Index
296