Interstage Application and Service Management V10.0. Administration Guide

Transcription

1 Interstage Application and Service Management V10.0 Administration Guide B1WD ENZ0(00) October 2008

2 Trademarks Interstage and Enabler are trademarks of Fujitsu Limited in Japan and/or other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. UNIX is a registered trademark of the Open Group in the United States and in other countries. Linux is a registered trademark of Linus Torvalds. Other company names and product names are trademarks or registered trademarks of their respective owners. Copyright FUJITSU LIMITED 2008 All rights reserved, including those of translation into other languages. No part of this manual may be reproduced in any form whatsoever without the written permission of Fujitsu Limited. [High Risk Activity] The Customer acknowledges and agrees that the Product is designed, developed and manufactured as contemplated for general use, including without limitation, general office use, personal use, household use, and ordinary industrial use, but is not designed, developed and manufactured as contemplated for use accompanying fatal risks or dangers that, unless extremely high safety is secured, could lead directly to death, personal injury, severe physical damage or other loss (hereinafter "High Safety Required Use"), including without limitation, nuclear reaction control in nuclear facility, aircraft flight control, air traffic control, mass transport control, medical life support system, missile launch control in weapon system. The Customer shall not use the Product without securing the sufficient safety required for the High Safety Required Use. In addition, Fujitsu (or other affiliate's name) shall not be liable against the Customer and/or any third party for any claims or damages arising in connection with the High Safety Required Use of the Product. Interstage ASM Administration Guide 2

3 Contents 1 Introduction Administration in Interstage ASM Users in Interstage ASM Architecture and Interfaces Usage and Installation Scenarios General Operation Prerequisites Enabler Server Administration Installing an Enabler Server Starting and Stopping an Enabler Server Configuring User Authentication Administering Users and User Groups Backing up and Restoring Enabler Data Repository Administration Distribution of Data to Repositories Resource Requirements Creating Repositories Datastore Parameters Repository Settings...27 General Settings Mail Settings Search Settings Starting and Stopping Repositories Backing up and Restoring Repositories Backup and Restore of Multiple Repositories Client Access and Synchronization After Repository Restore...31 Interstage ASM Administration Guide 3

4 3.8 Checking and Reorganizing Datastores Handling Log Files Maintaining the Data Model of Repositories Deleting Repositories SCA Server Administration Resource Requirements Installing and Running an SCA Server Setting Scan Source Directories Backing up and Restoring SCA Data Scheduling Source Code Scans Scheduling QAM Measurements Search Server Administration Resource Requirements Installing and Running a Search Server Creating and Maintaining Search Indices...42 Creating and Updating Search Indices Optimizing Search Indices Deleting Search Index Entries and Indices esindex Backing up and Restoring Search Indices Web/Application Server Administration Overview of the Interstage ASM Web Applications Context Names and URLs Installing and Deploying Web Applications Deploying with Interstage Application Server Deploying with Apache Tomcat Configuring SSL Access Configuring SSL Access in Interstage Application Server Configuring SSL Access in Apache Tomcat...52 Interstage ASM Administration Guide 4

5 6.4.3 Configuring Interstage ASM Clients for SSL Access Setting the Language for the Web Applications Configuring Web Applications Overview of Configuration Settings Configuring the SCM Web Interface CentraSite Administration Installing and Deploying the Web Applications Basic CentraSite Settings Executing CentraSite Administration Functions Creating a CentraSite Registry and Repository Administering the Registry and Repository Administering the CentraSite Password Store Enabling Change Notifications Configuring the UDDI Interface Setting up Registry Federations WebDAV Interface Configuration Installing and Deploying the WebDAV Interface General Configuration of the WebDAV Interface Defining WebDAV Shares Defining a WebDAV Share for CentraSite Defining WebDAV Shares for SCM Configurations Working with WebDAV Shares Deleting WebDAV Shares Interstage BPM Integration Installing the LCM/BPM Integration Software Integrating LCM Definitions and Libraries in BPM Deploying the LCM/BPM Integration Web Application...77 Interstage ASM Administration Guide 5

6 9.4 Maintaining Host Names, User IDs and Passwords Bugzilla Integration Mapping of Bugzilla Actions and Data to LCM Preparations Configuring Applications and Services for Bugzilla...81 Specifying Connection Data Mapping Products, Components, Versions, and Milestones Specifying Addresses for Users Synchronizing Change Requests with Bugzilla Customizing the Bugzilla Integration Client Administration Client Interface...84 Installing the Client Interface Configuring the Client Interface Command Line Interface Installing the Command Line Interface Configuring the Command Line Interface General Administration Tasks Changing the Password of asmuser Changing Ports of Server Components Commands of the Command Line Interface Using the Command Line Interface esca scan Scan Source Code esca disassemblejar Disassemble Java Archives eqam collect Create QAM Measurement esindex Create/Maintain Search Index elcmbug Synchronize LCM with Bugzilla Interstage ASM Administration Guide 6

7 14 Troubleshooting Repository List Incomplete Insufficient Memory Errors Appendix: Interstage ASM Eclipse Plug-ins Glossary Interstage ASM Administration Guide 7

8 About this Manual This manual describes the administration of the Fujitsu Interstage Application and Service Management suite hereafter referred to as Interstage ASM. The manual is structured as follows: Title Description Chapter 1 Introduction Provides an introduction to the administration of Interstage ASM and gives an overview of the Interstage ASM users, architecture, interfaces, usage and installation scenarios. Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Enabler Server Administration Repository Administration SCA Server Administration Search Server Administration Web/Application Server Administration CentraSite Administration WebDAV Interface Configuration Interstage BPM Integration Bugzilla Integration Describes administrative tasks related to the Enabler servers where Interstage ASM repositories are located. Describes concepts and administrative tasks related to Interstage ASM repositories. Describes the administration of SCA servers, where scanning of source code takes place and SCA cubes are maintained. Describes the administration of Interstage ASM search servers, where search indices for repositories are created and maintained. Describes the installation and deployment of the Interstage ASM Web applications as well as administrative tasks related to Web/application servers. Describes the configuration and administration of the CentraSite Web applications, registries and repositories. Describes the deployment of the WebDAV interface and the definition and usage of WebDAV shares in CentraSite and SCM. Describes the installation and setup of the LCM definitions, libraries and Web applications required for the integration of Interstage BPM processes. Describes concepts and administrative tasks related to the integration of Bugzilla into Interstage ASM. Interstage ASM Administration Guide 8

9 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Appendix Client Administration General Administration Tasks Commands of the Command Line Interface Troubleshooting Interstage ASM Eclipse Plug-ins Describes the installation and configuration of the Interstage ASM client interface and command line interface. Describes administrative tasks that relate to Interstage ASM as a whole. Describes commands of the Interstage ASM command line interface which are important for executing the tasks described in this manual. Provides information on problems you may encounter in Interstage ASM operation, and describes appropriate solutions. Provides an overview of the Eclipse plug-ins that make up the Interstage ASM client interface and its documentation. Readers of this Manual This manual is directed to system administrators who are responsible for preparing and maintaining Interstage ASM for the end users. Basic knowledge of the following is required: Interstage ASM concepts. Administration of the operating systems in use. Java. Web server and application server administration. Notational Conventions This manual uses the following notational conventions: Add The names of graphical user interface elements like menu options are shown in bold case. init <variable> [option] one two System names, for example, command names, and text that is entered from the keyboard are shown in Courier font. Variables for which values must be entered are enclosed in angle brackets. Optional items, for example, optional command parameters, are enclosed in square brackets. Alternative entries are separated by a vertical bar. Interstage ASM Administration Guide 9

10 Abbreviations This manual uses the following abbreviations for Interstage products and components: Interstage ASM Interstage BPM Interstage ADM Interstage SQA CHM COC DMS LCM QAM RLM RQM SCA SCM Interstage Application and Service Management suite Interstage Business Process Manager Interstage Application Development Cycle Manager product of Interstage ASM Interstage Software Quality Analyzer product of Interstage ASM Change Management component of Interstage ASM Control Center component of Interstage ASM Document Management component of Interstage ASM Lifecycle management components (CHM, RLM, RQM) of Interstage ASM Quality Assessment component of Interstage ASM Release Management component of Interstage ASM Requirements Management component of Interstage ASM Source Code Analysis component of Interstage ASM Software Configuration Management component of Interstage ASM The term "Windows" is used to denote the different Microsoft Windows operating systems supported by Interstage ASM. Related Documentation Apart from this manual, the following documentation on Interstage ASM is available: Interstage ASM Overview: A PDF manual introducing Interstage ASM and describing its main features and basic concepts. Interstage ADM Installation Instructions: A PDF manual describing the installation and uninstallation of Interstage ADM. Interstage SQA Installation Instructions: A PDF manual describing the installation and uninstallation of Interstage SQA. CentraSite Installation Instructions: A PDF manual describing the installation and uninstallation of CentraSite. Interstage ADM Lifecycle Management User Guide: An online manual describing how to work with the lifecycle management (LCM) components of Interstage ASM from the client interface. Interstage ASM Administration Guide 10

11 Interstage ADM Software Configuration Management User Guide: An online manual describing how to work with the Software Configuration Management (SCM) component of Interstage ASM from the client interface. Interstage ADM Document Management User Guide: An online manual describing how to work with the Document Management (DMS) component of Interstage ASM from the client interface. Interstage SQA Source Code Analysis User Guide: An online manual describing how to work with the Source Code Analysis (SCA) component of Interstage ASM from the client interface. Interstage SQA Quality Assessment User Guide: An online manual describing how to work with the Quality Assessment (QAM) component of Interstage ASM from the client interface. CentraSite User Guide: An online manual describing how to work with the SOA Asset Management (CentraSite) component of Interstage ASM from the client interface. Interstage ASM Control Center User Guide: An online manual describing how to work with the Control Center (COC) component of Interstage ASM from the client interface. Interstage ASM Customization Guide: A PDF manual describing how to extend, localize and customize Interstage ASM. Interstage ADM Software Configuration Management Migration Guide: A PDF manual describing how to migrate projects from other source code management systems to the SCM component of Interstage ASM. Interstage ADM Command Line Interface: A PDF manual describing the Interstage ADM command line interface. Additionally, the following documents of Fujitsu Enabler are of relevance: Enabler Administration: A PDF manual describing the administration of Enabler servers and repositories. Enabler WebDAV Interface: A PDF manual describing how to set up the working environment for accessing files managed in a repository using WebDAV clients. Interstage ASM Administration Guide 11

12 1 Introduction Interstage Application and Service Management (Interstage ASM) is a suite of products, components and tools that support you in managing the services, software products and applications of your company. Interstage ASM covers the entire lifecycle of services and applications, ranging from requirements and change management through software development, maintenance, and quality assessment to release and asset management. With its features, Interstage ASM helps you control your development processes, improve the quality of your software, reduce development and maintenance costs, comply with regulatory acts and govern your company's services and applications. Repository-based technology and a wide range of interfaces make Interstage ASM very scalable, reliable, flexible and customizable. Interstage ASM consists of the following products and components. The white boxes show the products, the dark grey boxes the components they consist of: Lifecycle Management Interstage ADM Requirements Management (RQM) (RQM) Software and Documentation Management Document Management (DMS) (DMS) Analysis and Assessment Interstage SQA Source Code Code Analysis (SCA) (SCA) Change Management (CHM) (CHM) Software Configuration Management (SCM) (SCM) Quality Assessment (QAM) (QAM) Release Management (RLM) (RLM) CentraSite SOA SOA Asset Asset Management (CentraSite) Common Components (Enabler Repository, Control Center Center (COC)) (COC)) Interstage ASM Administration Guide 12

13 1.1 Administration in Interstage ASM As a system administrator, you are responsible for installing Interstage ASM and for preparing and maintaining the working environment for the end users. You make modifications to the system environment and manage the operation of all system components involved. Administration in Interstage ASM includes the following tasks: Creating and maintaining repositories, and configuring and administering the Enabler servers on which the repositories are located. Administering SCA servers where scanning of source code takes place and SCA cubes are maintained. Creating and maintaining search indices for repositories, and administering the search servers where the indices are located. Deploying and configuring the Interstage ASM Web applications. Installing, configuring and administering Interstage ASM clients. Integrating Bugzilla and Interstage BPM with Interstage ASM. The following tools and interfaces are available to perform these tasks: For carrying out Interstage ASM specific administration tasks, you can use the Interstage ASM client interface or command line interface. Specific CentraSite administration functions can be carried out in a Web browser. For user and repository administration, you can use the Enabler tools or command line interface. For specific tasks like starting and stopping services, standard tools of the underlying operating system are used. 1.2 Users in Interstage ASM Basically, any users who have access to the Interstage ASM servers and clients can work with the Interstage ASM components. These are typically users who have real user accounts in your environment. The users are authenticated when they access a repository and its data. The sophisticated access concept of Interstage ASM allows you to define exactly which data each authenticated user can access and which actions the user can carry out. For details on user authentication and recommendations related to user administration, refer to Section 2.3 and 2.4. In addition to the real users working with Interstage ASM, you will be dealing with the Interstage ASM system user, asmuser. Interstage ASM uses asmuser for interrepository and inter-system communication. asmuser does not have a real user account in any operating system, but it has a password (specified at server installation time) and can be authenticated with each repository. Interstage ASM Administration Guide 13

14 asmuser is an administrator of all repositories and thus has full access rights to them. Its user ID and password are also registered with some of the server and Web components of Interstage ASM. 1.3 Architecture and Interfaces The following illustration provides an overview of the Interstage ASM architecture and interfaces: Client Interface Command Line Interface Web Interface WebDAV Interface UDDI Interface Functionality and Java API RQM CHM RLM SCM DMS SCA QAM Centra Site Site COC Search Server SCA Server The functionality of Interstage ASM is implemented in Java and exposed at the Java API. The Interstage ASM components store their data in Enabler repositories, which are located on one or more Enabler servers. For scanning source code and obtaining the required analysis data, SCA uses a highperformance code analyzer based on OLAP (Online Analytical Processing) technology. This is referred to as the SCA server. SCM and DMS provide full text search which is based on search indices. These indices are created and maintained on one or more search servers. Interstage ASM Administration Guide 14

15 The users of Interstage ASM can work with the following interfaces: Client interface The client interface is a graphical user interface that offers the complete Interstage ASM functionality. The client interface is based on Eclipse technology and implemented as Eclipse plug-ins. As such, it can be installed and operated in the following ways: Stand-alone variant: The stand-alone variant is based on the Eclipse RCP (rich client platform) technology. It includes the Eclipse plug-ins of the Interstage ASM components you have installed as well as all features of the Eclipse Workbench required to operate them. This means there is no need to separately install Eclipse. The stand-alone variant of the client interface is the main interface for all Interstage ASM users and components. Existing Eclipse environment: You can install and use the plug-ins of the Interstage ASM components within an existing Eclipse environment. This is particularly suitable for SCM: If you use Eclipse for software development, the SCM functionality can be integrated seamlessly with it. In a similar way, you can add the analysis features of SCA or CentraSite to your development environment. Command line interface The command line interface consists of batch files for Windows and shell scripts for UNIX/Linux. It offers the complete SCM functionality as well as basic functionality of other components. You can use the command line interface for batch processing (e.g. create builds in SCM or perform regular source code scans in SCA) as well as for integrating Interstage ASM functionality into third-party tools and solutions without the need for programming. Web interface SCM and DMS offer a Web interface in addition to the client interface. The Web interface is servlet-based and allows for performing specific SCM and DMS activities from a Web browser. WebDAV interface The WebDAV interface is made available by the Enabler WebDAV services and used in SCM and CentraSite. The Enabler WebDAV services provide folder/file views of the data stored in a repository. Via WebDAV shares, the folders and files can be accessed from any WebDAV-compatible client (e.g. Microsoft Internet Explorer or Microsoft Office) in any Internet location. In SCM, you can define a WebDAV share for each protected configuration and access the folders and files in read-only mode. CentraSite uses WebDAV shares to provide its repository functionality. UDDI interface In addition to its JAXR-compliant Java API, CentraSite offers a UDDI (Universal Description, Discovery and Integration) interface, which allows you to integrate it in your SOA environment and use it like any standard UDDI registry. The UDDI interface can be deployed as a Web application on any Web/application server of your choice. Interstage ASM Administration Guide 15

16 1.4 Usage and Installation Scenarios Interstage ASM is implemented as a three-tier application involving clients, Web/application servers and the Interstage ASM server components. SCM and DMS support a pure client/server scenario in addition. The following illustration provides an overview of the installation and usage scenarios: Interstage ASM client Client Command line interface interface Web client WebDAV client Interstage ASM functionality and API HTTP / HTTPS HTTP / HTTPS Firewall Web/application server TCP/IP Interstage ASM Web applications (remote interface) WebDAV interface UDDI interface Interstage ASM functionality and API Search server SCA server TCP/IP LAN TCP/IP TCP/IP TCP/IP TCP/IP Enabler server Repository Interstage ASM Administration Guide 16

17 Users can work with the Interstage ASM components and interfaces in the following way: Client and command line interfaces: Users work from Interstage ASM clients, where the client and/or command line interface including all the Interstage ASM client functionality are installed. The clients access the repositories and Interstage ASM servers by HTTP or HTTPS via a Web/application server where the Interstage ASM Web applications are installed. The Web applications include the Interstage ASM API and functionality. They forward requests and data to the repositories and server components and return the responses to the clients. The Web applications are also referred to as the remote interface of Interstage ASM. SCM and DMS users can also work directly with repositories from their clients by TCP/IP without using the remote interface. The same is true for access to SCA servers when carrying out analyses. CentraSite users access repositories from the client interface both directly by TCP/IP and via the WebDAV interface, which runs on a Web/application server. On the same or a different Web/application server, the CentraSite UDDI interface may be deployed. Web interface of SCM and DMS: Users can work from any Web browser. They connect to the repositories via HTTP or HTTPS and a Web/application server where the Interstage ASM Web applications are installed. WebDAV interface: Users can access CentraSite repositories and protected configurations of SCM from any WebDAV client via the WebDAV interface. 1.5 General Operation Prerequisites The following general prerequisites must be fulfilled for operating Interstage ASM: The machines where the following Interstage ASM components are installed must be in the same LAN, and direct connection between them must be possible via TCP/IP without any firewall between them: Enabler servers, SCA servers, search servers, Web/application servers where the Interstage ASM Web applications are installed. Interstage ASM clients from which you work with CentraSite must also be in this same LAN. For the Interstage ASM client interface, at least version 5.0 of the Sun J2SE Runtime Environment (JRE) or Sun J2SE Development Kit (JDK) must be available. For the other components and interfaces of Interstage ASM, at least version is required. The Interstage ASM client and server installers for Windows install an appropriate JRE to the jre subdirectory of the Interstage ASM installation directory. This is used by default by the stand-alone variant of the Interstage ASM client interface and by the server components. It is also used by the command line interface if no different JRE/JDK is found by the setting of the JAVA_HOME environment variable. If you are using a JRE/JDK other than Sun s, it must be fully compatible with the Sun JRE/JDK and provide the same functionality (e.g. JAAS, JSSE). This is not the case, for example, for the IBM JRE or the JRE that comes with Red Hat Enterprise Linux. In such a case, it may help to add the rt.jar of the Sun JRE/JDK to your own JRE/JDK and include it in the CLASSPATH. Interstage ASM Administration Guide 17

18 2 Enabler Server Administration Interstage ASM stores and manages data in one or more repositories. A repository contains the actual data as well as the underlying data model, which determines how the information is organized. Each repository is based on an Enabler datastore. The repository is the logical unit for storing information, the datastore is the physical unit. Interstage ASM users can work with multiple repositories and their underlying datastores. The repositories may be located on one or more Windows, UNIX, or Linux systems where the Enabler server software is installed. When it comes to administering Enabler servers, repositories and user access to them, Interstage ASM mostly relies on the native Enabler features and functions. The following sections outline concepts and tasks related to Enabler server administration that are relevant for Interstage ASM: Installing an Enabler server Starting and stopping an Enabler server Configuring user authentication Administering users and user groups Backing up and restoring Enabler data Details about these concepts and tasks are described in the Enabler Administration manual. It is important that you read and understand at least those sections of the Enabler Administration manual that are mentioned in the descriptions below. 2.1 Installing an Enabler Server Relevant sections of the Enabler Administration manual: 2.1, 2.2, 2.3, 3.2, and 3.4. For installing an Enabler server on Windows or UNIX/Linux, you use one of the Interstage ASM server installers, which prepare and set up the software as required by Interstage ASM (for details, refer to the Installation Instructions of the Interstage ASM products you are using): The service broker port for addressing the Enabler server is set to 9500 or as specified in the setup. User authentication is configured for authentication against a user_ident file, and an appropriate user_ident file is created in the directory for datastores. See Section 2.3 for details on user authentication. The Interstage ASM system user, asmuser, is added to the Enabler server s list of valid users. It is also added to the user_ident file with a default password or the password specified in the setup. Interstage ASM Administration Guide 18

19 An existing Enabler server installation can be used for Interstage ASM if it is configured in an analogous way, particularly as to user authentication and the Interstage ASM system user. 2.2 Starting and Stopping an Enabler Server Relevant sections of the Enabler Administration manual: 2.3 and 2.6. Before repositories on a server can be accessed, the Enabler service broker (program name: omsservd) must be running. The Enabler service broker is started automatically when the underlying Windows or UNIX/Linux system is started. It is stopped automatically when the Windows or UNIX/Linux system is stopped. To start the Enabler service broker manually: On Windows: Start the Windows service, Interstage ASM Enabler, using standard Windows interfaces and procedures, for example, the Computer Management console. On UNIX/Linux: Execute the enablerstart <port> command in the <ena_inst_dir>/server/bin directory; <ena_inst_dir> is the Enabler installation directory, <port> is the port number assigned to the Enabler service broker. To stop the Enabler service broker manually: On Windows: First stop all repositories. Then stop the Windows service, Interstage ASM Enabler, using standard Windows interfaces and procedures, for example, the Computer Management console. On UNIX/Linux: Execute the enablerstop <port> command in the <ena_inst_dir>/server/bin directory; <ena_inst_dir> is the Enabler installation directory, <port> is the port number assigned to the Enabler service broker. Interstage ASM Administration Guide 19

20 2.3 Configuring User Authentication Relevant sections of the Enabler Administration manual: 3.1 and 3.4. All users trying to access repositories on an Enabler server must be authenticated. The user must provide at least his/her name and password. This information is checked against an authentication system that is determined by the Enabler server and repository to be accessed. The following authentication methods and systems are available for Interstage ASM: Authentication against a user_ident file Authentication against an Active Directory Authentication against an LDAP server After installation, Enabler servers for Interstage ASM are initially configured for authentication against a user_ident file only. The Interstage ASM server installers create an appropriate user_ident file in the directory for datastores. The Interstage ASM system user, asmuser, is automatically added to this user_ident file with a default password or the password specified in the setup. For proper Interstage ASM operation, it is vital that asmuser can always be authenticated against a user_ident file and that its ID is not changed in any way in this file or elsewhere. You can use the user_ident file authentication mechanism also for the other users of Interstage ASM. In this case, you have to enter their IDs and passwords in the user_ident file. See Section of the Enabler Administration manual for details on how this is done. Note that in recent releases, Enabler provides a command, omsuserident, that supports you in maintaining user_ident files. This command is not yet described in the Enabler Administration manual. Contact your support organization if you want to use this command. In most environments, authentication against a user_ident file for standard Interstage ASM users will not be suitable, because it duplicates the effort of maintaining user IDs and passwords. Therefore, you can configure the user authentication to an existing Active Directory or LDAP server in your environment. To do this, adapt the JAAS configuration file, jaas.conf, of the Enabler server accordingly: Add the required login module with its configuration to the default JAAS context BELOW the entry for the ELoginModuleUserIdent. Interstage ASM Administration Guide 20

21 For example, for user authentication against an Active Directory, the default JAAS context would then look as follows: default { com.fujitsu.enabler.jena.eloginmoduleuserident sufficient; com.fujitsu.enabler.jena.eloginmoduleads sufficient HostName="myhost" Port="389" ; }; Do not remove the entry for ELoginModuleUserIdent from the default JAAS context. It is required for authentication of the Interstage ASM system user, asmuser. For details on the JAAS configuration file, jaas.conf, and login modules, see Section and of the Enabler Administration manual. 2.4 Administering Users and User Groups Relevant sections of the Enabler Administration manual: 3.1, 3.2 and 3.3. Users and user groups who are to work with Interstage ASM and be granted access rights in Interstage ASM repositories must be users and user groups known to and accepted by Enabler. Basically, any users and user groups can be granted access to Enabler and Interstage ASM, independent on whether corresponding accounts exist in your environment. However, to facilitate maintenance of users, user groups and group memberships, we recommend you follow these rules: Define and maintain all users and user groups, who are to work with Interstage ASM, at the operating system level of your environment, for example, in an Active Directory, on an LDAP server or in the user and groups files of your UNIX/Linux systems. Make sure that each user and user group is unique and used throughout your entire environment. If you are using an Active Directory or LDAP server for user authentication, this should be the system where you maintain your users and groups. Make sure that each Enabler server in your environment collects the appropriate users and user groups in its lists of valid users and groups. If you use your own procedures for maintaining these lists, make sure that the entry for the Interstage ASM system user, asmuser, is never removed from the list of valid users. For details on the valid users and groups of an Enabler server, see Section 3.2 of the Enabler Administration manual. Make sure that the following settings are activated for your Interstage ASM repositories: 'ID check' and 'update group members'. This ensures that only users and user groups contained in the Enabler server's valid users and groups lists can work with the repositories and be assigned access rights, and that group memberships are to some extent maintained automatically by Enabler. For details, see Section 3.2 and 3.3 of the Enabler Administration manual. Interstage ASM Administration Guide 21

22 When following the above rules, new users, user groups and changed group assignments in your company can easily be made known to Interstage ASM and reflected in the repositories as follows: 1. Add or change the users and user groups at the operating system level of your environment using standard tools. 2. Update the valid users and groups lists on all Enabler servers, for example, by executing the omsuserinit command. 3. Synchronize the group memberships in the Enabler repositories by executing the corresponding function from the Enabler tools (Synchronize Members in the Enabler User and Group Manager) or the command line interface (omsgroupmemupd), or by stopping and restarting the repositories. There is no need to explicitly add new users and user groups to the repositories since this is done automatically as required. Obsolete users and groups can be deleted from the repositories using the corresponding Enabler functions. 2.5 Backing up and Restoring Enabler Data In order to avoid loss of data in the event of system or disk crashes, you should back up your repositories on a regular basis. For backing up repositories and restoring them, if required, you use the Enabler functions for backing up and restoring datastores. For details, refer to Section 3.7. In addition to repositories, you should make a regular backup of the following Enabler directories and files using a backup tool of your choice: server\control, server\etc and server\param subdirectories of the Enabler server software installation directory. These subdirectories contain all the configuration and log files of the Enabler server, for example, datastore and broker event logs, omscreate and jaas.conf files. user_ident file(s) for user authentication. In case your Enabler installation is destroyed, you can re-install the Enabler server software and restore the required configuration files from the backup. Interstage ASM Administration Guide 22

23 3 Repository Administration The following sections describe concepts and tasks related to the administration of repositories and their underlying Enabler datastores: Distribution of data to repositories Resource requirements Creating repositories Datastore parameters Repository settings Starting and stopping repositories Backing up and restoring repositories Checking and reorganizing datastores Handling log files Maintaining the data model of repositories Deleting repositories Details about Enabler datastores and their administration are described in the Enabler Administration manual. It is important that you read and understand at least those sections of the Enabler Administration manual that are mentioned in the descriptions below. 3.1 Distribution of Data to Repositories You can use one repository for managing all your Interstage ASM data. However, you will usually distribute the information to several repositories, particularly when many users and large amounts of data are involved. A typical Interstage ASM installation could use repositories as follows: One or more repositories for hosting software development projects and document libraries managed with SCM and DMS, depending on the number of projects and libraries, the amount of data and the number of users. For example, you may want to use separate repositories for each of your SCM projects. This has the following advantages: While some repositories are not available because of maintenance work, users can still work in the other repositories. Additionally, more users can work in parallel on the projects as when using one repository only, because the number of connections to one repository is limited to 500. One repository for SOA asset management with CentraSite. One repository for LCM, SCA, QAM and COC. Since the amount of data created and maintained with these components is not very high, one repository is usually sufficient. However, you may just as well use different repositories, for example, for different departments or components. Interstage ASM Administration Guide 23

24 3.2 Resource Requirements The number of repositories a server can hold is limited mainly by the server's available memory and disk space. The following rules can help you determine how to dimension your Enabler servers and/or distribute repositories across multiple servers: Memory Minimum 40 MB per datastore. Details on how to calculate the memory requirements for datastores are provided in Appendix A.4 of the Enabler Administration manual. Disk Space Minimum 2 GB per datastore. Particularly in repositories used for SCM and DMS, the required disk space may be much more, depending on the number and size of files and the number of versions. For example, a medium-sized SCM project consisting of about files with 40 versions each and an average size of 75 KB will require about 4 GB. A larger project containing about files with 50 versions and 100 KB each will require about 50 GB. With this document, a Microsoft Excel spreadsheet, DiskSpaceCalculation.xls, is provided, which you can use to calculate the disk space requirements of SCM and DMS repositories. CPU and Disk Performance As a general rule, you should use the fastest CPUs and disks. The more repositories are running at the same time on a server, the more CPU is needed. Connections Interstage ASM limits the number of simultaneous connections to one repository to 500. This must be taken into account in particular when working with direct client/repository connections in SCM, DMS or CentraSite without using the remote interface. 3.3 Creating Repositories Creating a repository consists of creating an Enabler datastore and initializing it with the appropriate data model. Repositories can be created in the following ways: Implicitly create a datastore and initialize it with the required data model. In CentraSite, a datastore and its data model are created implicitly with the first start of the csconfig Web application. See Section 7.4 for details. In the other Interstage ASM components, you can create a datastore implicitly by specifying the name of a repository that does not yet exist when logging on at the client interface. Interstage ASM Administration Guide 24

25 If the prerequisites are fulfilled, a datastore with the specified name is created automatically on the given server, started in read/write mode and initialized with the data model of the Interstage ASM component in question. The parameters described in Section 3.4 are used for the datastore. For details on creating Enabler datastores and the prerequisites, see Section 6.3 of the Enabler Administration manual. Initialize an existing datastore with the appropriate data model: In all Interstage ASM components except for CentraSite, you can specify the name of an existing datastore when logging on at the client interface. If this datastore does not yet contain the required data model of the Interstage ASM component you log on to, the model is inserted automatically. Explicitly create and initialize a datastore with the required data model: From the Interstage ASM command line interface, you can explicitly initialize a datastore with an SCM or DMS data model (escm init). If the datastore does not exist, the command creates it with the parameters described in Section 3.4 and starts it. For details, refer to the Interstage ADM Command Line Interface manual. The following minimum prerequisites must be fulfilled for successfully initializing an existing datastore with an Interstage ASM data model: The datastore must be running in read/write mode. The name check setting of the datastore must be switched off. You must be a datastore administrator or a data modeler. The Interstage ASM system user, asmuser, must be one of the datastore administrators. The Interstage ASM users can immediately start to work with the repositories which you create and initialize with the required data model. In CentraSite, an appropriate WebDAV share must be configured in order to use the full repository functionality; see Section 7.4 for details. Interstage ASM Administration Guide 25

26 3.4 Datastore Parameters When an Interstage ASM component creates a datastore for a repository automatically, it uses the Enabler default values for the datastore parameters except for the following. For details on datastore parameters, see Chapter 4 and 5 of the Enabler Administration manual. Datastore Parameter Automatic start ID check Update group members at datastore start Name check Value On On On Off Recovery log file size 100,000 Restore logging Automatic recovery Off On Number of worker threads 3 Datastore port numbers in Enabler server installations of Interstage ASM are in the range of The above values and the Enabler defaults for the remaining parameters are suitable for most environments. In some cases, however, it may be desirable or required to change datastore parameters. For example, you can: Increase the number of worker threads depending on the number of CPUs your Enabler server has. Switch on restore logging, depending on your backup strategy. Increase the transaction timeout and the maximum number of locks that can be set in the repository at a time. This may be necessary for SCM, DMS and CentraSite repositories if you want to import or check in huge resource or object structures. As a basic rule, the maximum number of locks should be at least 5-6 times the number of resources or objects you want to check in or import in one operation. The following table shows some examples for SCM and DMS: Number of files to import Number of folders to import Number of locks required 10,000 2,500 50,000 (=default) 20,000 3, ,000 30,000 4, ,000 Interstage ASM Administration Guide 26

27 The following datastores parameter settings are vital for Interstage ASM operation: The name check setting of the datastore must be switched off. The Interstage ASM system user, asmuser, must be a datastore administrator. Other datastore administrators can be changed as required. You can update datastore parameters at any time using the Enabler tools (Properties for datastores) or command line interface (omsupd). For details, see Section 6.7 of the Enabler Administration manual. Additional hints and recommendations for parameter settings are given in Chapter 4 and 5 of the Enabler Administration manual. 3.5 Repository Settings LCM, SCM and DMS repositories have several administrative settings that allow you to configure them to suit your requirements. You can change these settings using the Interstage ASM client interface (Properties of repository in SCM and DMS, or Properties of Applications and Services node in LCM) or command line interface (several escm commands). As a prerequisite, you must have datastore administrator rights to the datastore on which the repository is based. In addition, you can customize the default values for several settings which are used when repositories are created. For details, refer to the Interstage ASM Customization Guide. The following sections describe the administrative settings you can make: General settings Mail settings Search settings General Settings For each SCM and DMS repository, you can make the following general settings: Users allowed to create new projects or document libraries You can specify that only datastore administrators and/or members of specific access groups are allowed to create new projects or document libraries in the repository. As access groups, you can specify up to eight user groups, separated by semicolons (;), which are known to the Enabler server hosting the repository (see Section 2.4). By default, every user known to the Enabler server is allowed to create new projects or document libraries. Users allowed to access the repository You can restrict access to the repository to the members of up to eight access groups. As access groups, you can specify up to eight user groups, separated by semicolons (;), which are known to the Enabler server hosting the repository (see Section 2.4). By default, every user known to the Enabler server is allowed to access the repository. Interstage ASM Administration Guide 27

28 Delta storage of file versions This setting specifies whether only the differences between file versions are stored in the repository, or the entire contents of each version. When using deltas, the contents of specific versions are constructed from all the relevant deltas at runtime when the versions are accessed. For performance and technical reasons, SCM and DMS store the complete contents for specific file versions (e.g. newest versions, versions contained in snapshots or library editions) even if delta storage is enabled. Delta storage of file versions may allow you to reduce the disk space required for your repositories. This depends on the types of file you are using. For example, for plain ASCII text files, the disk space requirements may decrease to a great extent, while for Microsoft Office documents even more disk space may be necessary as when storing full versions. Delta storage of file versions has some drawbacks due to which it is not recommended: The creation of deltas and even more important the reconstruction of each version when it is accessed impacts the performance of the overall system. If any of the deltas is missing or damaged, the contents of all versions are lost and cannot be reconstructed. Instead of delta storage, you can use other features and functions of SCM and DMS to reduce disk space requirements. For example, you can delete intermediate versions in SCM. Moreover, SCM and DMS save disk space by not creating new files if there are no changes when a new version is created. When you switch on delta storage of file versions, it becomes effective for new versions; existing versions remain unchanged. When switching the setting off, all existing delta versions are converted to full versions. By default, the setting is off. Recording of any read access to file content in the project/library log SCM and DMS by default record all write operations carried out in their repositories in log files (see Section 3.9 for details). With this setting, you can enable also the recording of any read access to the data, i.e. to the files managed in SCM and DMS. Be aware that the recording of read operations has a major impact on performance and heavily increases the disk space requirements for the log files. You should therefore enable this setting only if absolutely necessary, for example, in highly controlled environments or for auditing purposes. Interstage ASM Administration Guide 28

29 3.5.2 Mail Settings LCM, SCM and DMS support user notification by for specific actions. As a prerequisite, the following settings are required: Mail enabled The sending of s must be enabled explicitly. By default, it is disabled. SMTP Server The name or IP address of the mail server to be used. Sender ID and Sender Password The user ID under which s are to be sent. By default, this is LCM.Mailer in LCM, or SCM.Mailer in SCM and DMS. For mail systems, which require password authentication of the sender, the password can be specified. Your environment may require different mail settings for different developers who access the same repository. In this case, you can define individual mail settings on the individual Interstage ASM clients. These settings override the ones made centrally in the repository for the corresponding client. For details, refer to the Interstage ASM Customization Guide Search Settings SCM and DMS provide sophisticated search features, including full-text search across multiple projects and libraries in a repository. For each repository where searching is to be allowed, the settings below must be made. As a prerequisite, a full-text search index must have been created for the repository on a system where the Interstage ASM search service is installed. For details, refer to Chapter 5. Search enabled Searching must be enabled explicitly for a repository. By default, it is disabled. Server URL The URL of the Interstage ASM search server in the following format: http[s]://<server>[:<port>] <server> is the Web/application server where the iscm<version> Web application has been deployed and where the search index for this repository is located. <port> is the port to address the Web/application server (default: 80 for HTTP, 443 for HTTPS). If users specify a proxy server when connecting to the SCM or DMS repository, this proxy is used automatically for access to the search server. Index path The absolute path and name of the directory on the search server where the search index for this repository is located. Interstage ASM Administration Guide 29