Paradigm Installation Guide. With Epos 4.1 Data Management. EarthStudy 360 Echos Explorer GeoDepth GeoSec 2D Probe SeisEarth

Transcription

1 .2 Installation Guide EarthStudy 360 Echos Explorer GeoDepth GeoSec 2D Probe SeisEarth SKUA StratEarth Stratimagic Vanguard VoxelGeo WAM

2 Paradigm Ltd. or its affiliates and subsidiaries. All rights reserved. The information in this document is subject to change without notice and should not be construed as a commitment by Paradigm Ltd. or its affiliates and subsidiaries (collectively, "Paradigm"). Paradigm assumes no responsibility for any errors that may appear in this document. The Copyright Act of the United States, Title 17 of the United States Code, Section 501 prohibits the reproduction or transmission of Paradigm s copyrighted material in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage and retrieval system without permission in writing from Paradigm. Violators of this statute will be subject to civil and possible criminal liability. The infringing activity will be enjoined and the infringing articles will be impounded. Violators will be personally liable for Paradigm s actual damages and any additional profits of the infringer, or statutory damages in the amount of up to $150,000 per infringement. Paradigm will also seek all costs and attorney fees. In addition, any person who infringes this copyright willfully and for the purpose of commercial advantage or private financial gain, or by the reproduction or distribution of one or more copies of a copyrighted work with a total retail value of over $1,000 shall be punished under the criminal laws of the United States of America, including fines and possible imprisonment. The following are trademarks or registered trademarks of Paradigm Ltd. or its affiliates and subsidiaries (collectively, "Paradigm") in the United States or in other countries: Paradigm, Paradigm logo, and/or other Paradigm products referenced herein. For a complete list of Paradigm trademarks, visit our Web site at All other company or product names are the trademarks or registered trademarks of their respective holders. Alea and Jacta software under license from TOTAL. All rights reserved. Some components or processes may be licensed under one or more of U.S. Patent Numbers 5,570,106; 5,615,171; 6,765,570; and 6,690,820. Some components or processes are patented by Paradigm and/or one or more of its affiliates under U.S. Patent Numbers 5,563,949; 5,629,904; 5,838,564; 5,892,732; 5,930,730; 6,055,482; 6,092,026; 6,430,508; 6,819,628; 6,820,043; 6,859,734; 6,873,913; 7,095,677; 7,123,258; 7,295,929; 7,295,930; 7,328,139; 7,561,922; 7,584,056; 7,711,532; and 7,844,402. In addition, there may be patent protection in other foreign jurisdictions for these and other Paradigm products. All rights not expressly granted are reserved. Third-party software notices are located at

3 Contents 1 Introduction Overview Media Products Additional Product Information Documentation Epos Infrastructure Overview Selecting a License Server Host Selecting Server and Client Machines Selecting Installation Directories Upgrading from Epos 3.0 or Epos Overview Upgrading a Site from Epos 4.0 to Epos Upgrade Techniques Reuse PNS Segment Migrate PNS Settings Move Study Registrations Copy Epos Data Restore Epos Data Recommended Upgrade Workflow Stand-Alone Networked Windows Caveats Upgrading a Site from Epos 3 TE to Epos Upgrading from Paradigm Overview Backwards Compatibility Upgrade Strategy System Requirements Overview Required Disk Space Selecting EposAdm and EposDB Users Selecting Database Directories Supported Platforms Installation Guide iii

4 System Requirements and Recommendations Additional Requirements for VoxelGeo Manual System Configuration Installation Overview Preparation Starting the Installer Setting Up Epos Users Setting Up Data Paths and Security Setting Up Segment Groups Next Steps Licensing Overview Choosing a License Location Checking the Maintenance Expiration Date in Your License File Installing a New License File Site Configuration Epos Applications Control Panel Epos Services Control Panel Running Paradigm 2011 Applications Running Paradigm 2011 Applications Gnome Desktop Setup Upgrading from Epos Upgrading from Epos 3 TE Configuring and Running Echos Completing the Installation and Configuration of Echos Running Echos Running Stratimagic Starting Stratimagic with the Paradigm Product Manager Selecting Your PNS Group Running Stratimagic Stand-Alone Running Stratimagic in the Epos Environment Starting Stratimagic from the Command Line Options for Running the Sm Stratimagic Runtime Scripts Accessing Epos Data iv Installation Guide

5 Backward Compatibility Configuring WAM Overview WAM Administrator Prerequisites Launching the WAM Configuration Script Miscellaneous Issues Setting Up the WAM <--> PNS Connection Licensing WAM Running the Tomcat/WAM Server Running WAM in the Epos Environment Configuring Epos Seismic Data Access Backward Compatibility A Configuring Linux Clusters Prerequisites Cluster System Minimum Hardware Requirements Cluster System Configuration Software Installation File System Configuration User Configuration B Configuring the Network on Linux Overview Verifying Network Configuration Resolving Static IP Address Resolving Dynamic IP Address (DHCP) Host Name Resolution Order Case Study - Laptop Network Configuration Using DHCP C Multipipe Usage Overview Systems with nvidia Graphics Configuration D Windows Installation Installation Configuration Heterogeneous Environments Installation Guide v

6 vi Installation Guide

7 1 Introduction This chapter describes the organization of the.2 Installation Guide, the media, and documentation that comes with the Paradigm package, and the products included. Review this guide and plan the installation carefully. Paradigm is a major release with a broad offering of new functionality and features so it is important to plan ahead. Overview The Installation Guide describes the procedures for installing the Paradigm application software and the Epos 4.1 infrastructure software, and configuring your system. It is intended for use by your system administrator or other personnel familiar with your local systems and network configuration. Paradigm is available to be installed under Microsoft Windows and/or under Red Hat Enterprise Linux. The installation process is very similar whichever the operating system and this Installation Guide applies to both. The information in this guide is organized as follows: Chapter 1, Introduction describes the contents of this document and the contents of your Paradigm package. Chapter 2, Epos Infrastructure provides a concise overview of the Epos 4.1 infrastructure to provide sufficient information for understanding the installation. Chapter 3, Upgrading from Epos 3.0 or Epos 4.0 contains essential information for planning how to upgrade to Epos 4.1 from previous versions of Epos. Chapter 3, Upgrading from Paradigm 2011 contains essential information for planning how to upgrade to Paradigm from previous versions of Paradigm Chapter 5, System Requirements describes the hardware and software requirements for the Paradigm software. Chapter 6, Installation explains the procedure for installing PNS 4.1, Shared Services, and the Paradigm application software, and provides information about further configuration. Installation Guide 1

8 Introduction Chapter 7, Licensing provides information about installing and managing the licensing software, and on registering and activating your Paradigm product licenses. Chapter 8, Site Configuration provides information about running the site configuration utility and other information about configuring the software. Chapter 9, Running Paradigm 2011 Applications describes how to run the base application software and verify the installation. Chapter 10, Configuring and Running Echos has additional information about configuring and running the Echos application software. Chapter 11, Running Stratimagic has additional information about configuring and running the Stratimagic application software. Chapter 12, Configuring WAM has additional information about configuring and running the WAM server and browser. Appendix A, Configuring Linux Clusters describes configuring the runtime environment to run Epos parallel applications on Linux clusters. Appendix B, Configuring the Network on Linux provides basic information on how to configure host name resolution on Linux operating systems. Appendix C, Multipipe Usage describes multipipe usage for running and displaying in multiple graphics device environments. Appendix D, Windows Installation describes the fundamental procedures for Epos 4.1 software installation, configuration, and data management to be performed by the end users when Windows is part of their software runtime environment. Media This section lists the media and documentation in your Paradigm package. If you find that your package is incomplete, ontact your Paradigm sales representative. The Paradigm installation packages are available for download from the Paradigm Customer Support website. You will find the following Windows and Linux software versions: Paradigm Applications for Linux Paradigm Services for Linux Paradigm Applications for Windows Paradigm Services for Windows Third-party data servers for Paradigm (available for Linux only) Products The installation for Paradigm includes the following products: EarthStudy 360 Probe Vanguard Echos SeisEarth VoxelGeo Explorer SKUA WAM 2 Installation Guide

9 Introduction GeoDepth StratEarth GeoSec 2D Stratimagic Additional Product Information Visit the Paradigm Customer Support website and register if you have not already done so. You may be entitled to download and install further Paradigm software depending on your license purchases. For all Paradigm products, Support Packs containing the latest bug fixes are available for download providing your license maintenance is current. If you have licenses for Geolog, note that Geolog is downloaded and installed separately, and can be used either stand-alone or sharing the Epos infrastructure and third-party services with the other Epos applications. SKUA and GOCAD may be installed stand-alone but the SKUA software is also installed as part of the Paradigm application suite. If you have a license for High-Performance Reservoir Risk Assessment (Jacta Cluster) and you want to run Jacta simulations on a cluster network, you need to install and configure a batch management system. If you have a license for 3D Restoration (Kine3D -3) and you want to run restoration simulations, you need to install and configure Code_Aster, an external application required to perform finite-element processing. If you have a license for Reservoir Simulation Link and you want to launch flow simulations from SKUA or GOCAD, you need to create a run configuration file. Documentation The following documentation is provided online and on the Paradigm Customer Support site (Download and Documentation tab):.2 Installation Guide (this document) - Provides detailed installation and system administration information for Paradigm Release Notes - Describes new features and problem fixes for Paradigm Third-Party Data Servers Installation Guide. High-Performance Reservoir Risk Assessment (Jacta Cluster) Configuration Guide - Explains how to install and configure a batch management system for running Jacta simulations in SKUA or GOCAD on a cluster network. Reservoir Simulation Link Configuration Guide - Explains how to create a run configuration file for launching flow simulations from Reservoir Simulation Link in SKUA or GOCAD. Installation Guide 3

10 Introduction 4 Installation Guide

11 2 Epos Infrastructure This chapter gives a broad overview of the Epos Infrastructure and introduces some terminology that is related. It should be read before installing the Paradigm software for the first time. A full description of the Epos Infrastructure is found in Help > Infrastructure > Epos Infrastructure. Overview The Epos Infrastructure supports the suite of Epos application software, providing the user with a common database, a common look and feel to applications, and with shared access to software licenses, data services, plotting, and utility programs. Epos provides for either single-user or shared access to Epos project databases, and allows for software running with any of the following system configurations: A stand-alone machine A heterogeneous network A high performance cluster Epos Users An Epos User is a virtual user account with a name in the Epos system. An OS user will be able to run licensed Epos applications after being assigned to an Epos User account. Each Epos User account may comprise one or more single OS user names, one or more OS group names, or a combination of these. Two special OS user accounts should normally be created and set apart for administering Epos. EposAdm User - The EposAdm User is the Epos Administrator who carries out the installation and owns the installation files and directories comprising the installation trees. A username such as eposadm or pgadm for the EposAdm User role is recommended. EposDB User - The EposDB user is the Epos Database Administrator who owns the files and directories in the Epos databases that are accessed indirectly (via data services). A username such as eposdb or pgdb for the EposDB User role is recommended. These two OS users will use the administrative utilities to manage the software, but do not run the application software. They are not normally assigned an Epos User account. Installation Guide 5

12 Epos Infrastructure On a stand-alone system, and typically also under Windows, a single OS user may be used for administering and running the software. For example: a laptop installation where a single OS user account installs the software, administers the database, and runs the software. This user will act as the EposAdm, EposDB, and the Epos User. An Epos Project is used to store and organize data. Each Epos Project has a Project Administrator. This is an Epos User who has permissions to manage the data in the project. Other Epos Users may be assigned full or limited access to the project data as required. The Epos Administrator must set up at least one Epos User before anyone starts using the software. This is done using the service configuration tool (Epos Services Control Panel) in the PNS 4.1 installation: <Services>/bin/pns_config. Selecting a License Server Host The Paradigm license server daemons are supported on the same platforms as the other Paradigm server software. A new version of the vendor daemon "prdm_geo" is provided with all Paradigm applications, including GOCAD, SKUA, and StratEarth replacing use of the "gocadlmd" daemon seen in previous releases. Backwards compatibility allows the Paradigm version of our license server to serve the previous versions of clients of both prdm_geo and gocadlmd products. Note You will need to request a license file from Paradigm. You can proceed with the installation and get the services running even before this file is available, but the application software cannot be run until the license file is installed and the license server is running. Selecting Server and Client Machines In a stand-alone installation, the Epos Services run on the same machine as the Paradigm applications, but in an enterprise installation, only selected server machine(s) will run the Epos Services, while the applications can potentially be run on any and all suitable workstations. 6 Installation Guide

13 Epos Infrastructure Note When separate systems are being used for applications and for services, any graphics requirements mentioned below apply only to application workstations. The Epos Database Servers are started and stopped on demand by the Paradigm Name Service daemon that runs on each Epos Server machine. On a stand-alone system, the database servers are run as daemon processes in the background. In an enterprise installation, be sure to select a machine with sufficient resources to serve all the application users under conditions of normal and high usage. Ideally, a dedicated machine (or virtual machine) is selected. It would be unwise to select a machine that is already configured to be an application workstation, an Oracle database server, or a file server. If a server machine is also to provide connectivity to third-party databases then it is essential for the selected server machine to also be equipped as a client machine for the third-party software i.e., able to launch the third-party software and access the third-party data. (At some sites therefore, it is advisable to select one server machine to be dedicated to hosting Epos databases and services, and then to select one workstation that can double as an Epos server but hosting only the Epos third-party services.) Selecting Installation Directories The Epos Application software (including GeoDepth, Echos, VoxelGeo, SeisEarth, StratEarth, Explorer, Probe, Vanguard, Stratimagic, SKUA and WAM) is installed into a directory called Paradigm /Applications and should be accessible to all user workstations. Note In the previous releases of Paradigm 2011, the applications and services were installed into directories called Epos41 and PNS41 respectively. As of Paradigm the installation directories are called Paradigm /Applications and Paradigm /Services. The Geolog and Sysdrill suites of applications are installed into their own top level directories (but they all share the same Epos 4.1 infrastructure software installation). On a Linux network, the Epos Application software should be on a shared disk accessible to all workstations. On Windows workstations the Epos Application software should be installed locally. In an enterprise environment you can select to share settings files among all workstations even though the application software is on the local disk. The Epos Infrastructure software (including the Epos Database server) is always installed into a directory called Paradigm /Services and needs only be accessible on the selected server machines. The OS user who owns the Paradigm /Applications and Paradigm /Services directories is referred to as the EposAdm user, or the Epos Administrator. Control Panel Utilities Two control panel utilities provide the Epos Administrator with all the tools needed to manage the Epos Infrastructure and application settings. These can be started outside of an Epos environment by running pns_config (for the Epos Services Control Panel) or PG_epos_config (for the Epos Applications Control Panel). For a full description of these utilities, see: Help > Installation and Configuration > Epos Applications Control Panel Help > Infrastructure > Paradigm Name Service (PNS) and Other Shared Services > PNS User Guide > Epos Services Control Panel Installation Guide 7

14 Epos Infrastructure Client/Server Architecture Epos provides a common working environment for individuals or teams across disciplines, and provides the links from the Paradigm applications to all databases. The software is designed according to a client/server architecture which supports multiple users accessing multiple projects over a network. Each Epos Project is registered on one server or another. Each nominated server machine must run the Paradigm Name Service (PNS) which keeps a registry of all the projects that are handled by that server. The Epos Applications are the clients, and the Epos Infrastructure provides the services. Some Epos Services are data servers providing the connection between Epos Applications and Epos Databases. Other Epos Services are utility servers providing commonly shared functionality to the Epos Applications other than data services. Seismic data handing is based on direct data access rather than client/server access. Certain application data is also directly accessed by applications. For example VoxelGeo may read and write.vol files directly without going through the Epos data servers. Data Paths By default, users may create Epos Projects anywhere on the file system that they have OS write permissions. The Epos Administrator may use the Epos Services Control Panel from pns_config to set up Data Paths to restrict the creation of Epos Project data to those particular paths. When a project is created it is always registered on an Epos Server Host where PNS is installed and is running. Epos Data Services The Paradigm Name Service (PNS) is a part of Epos that provides overall control of all server-side activity. When an application presents a user with a choice of projects, it is the PNS that provides the list. It allows access only to those projects that the user has permissions to see. The PNS service manages all other services; starting and stopping them on demand, and providing the environment for them to operate on Epos Server Hosts. A number of Epos Data Services are provided: Project/Survey Service (ps_db_server) - Used indirectly by every Epos application to manage all the major data objects that define a Project or a Survey. Interpretation Data Service (i_db_server) - Manages access to all interpretation data using a client-server architecture. It also manages access to Cultural data. Vertical Function Data Service (vf2_db_server) - Manages access to vertical functions, mute functions, and pencil data using a client-server architecture. Well Data Service (log_db_server) - Manages all well data including Well header information, Location and Deviation Logs, Check Shots, Wireline Logs, Well Picks and Zones, and all other kinds of well-based data. Culture Data Service (c_db_server) - Manages access to culture data. Corser Epos Seismic Service (cseis_db_server) - Serves Epos seismic data to WAM. Drilling Data Service (dds_server) - Manages access to drilling data. File Access Service (file_server) - Implements generic file management operations performed using client-server architecture. 8 Installation Guide

15 Epos Infrastructure GOCAD Epos Well Data Service (gocad_db_server) - Serves Well Data from GOCAD to Epos. Note For more details on these services, see Help > Infrastructure > Epos Infrastructure > Epos Software Architecture > Epos Services. These services are started and stopped by the Paradigm Name Server where the project is registered. In addition to Epos Data Servers, the following utility servers are available: Concurrency Service (lock_server) - Takes care of database locking and provides control of multi-user access. Event Service (event_server) - Responsible for channeling events among Epos 4.1 applications. Coordinate Systems Service (css_server) - Supports conversion between coordinate systems and units. Third-Party Databases In addition to providing Services for Epos Databases and applications, the Epos Infrastructure enables connectivity to Third-Party Databases, which are supplied by other exploration and production software vendors. These may be linked to Epos for access by Paradigm applications. For a full description of these utilities, their installations, and reference guides, see the PNS/Shared Services/ Third-Party Services help menu in <Services>/doc/pns_help_menu.pdf. Note Epos Server Hosts that are going to be used to connect to Third-Party Databases must already be valid client machines for those third-party systems. PNS Segments At a small site, a single server machine may be designated to run the PNS and all the Data Servers. At a larger site, several machines may be chosen to spread the load between multiple servers. On each PNS Server Host, the PNS server runs as three separate processes: The EposAdm administrator (controlling access to installation files). The EposDB database administrator (controlling access to database files). The EposDB database administrator to enable secure SSH access according to individual user permissions. Every PNS Server has its own separate Study Registry. Each Epos Project database is registered on exactly one PNS server. A PNS Segment is an explicitly specified group of PNS servers that exchange survey information. Note This is in contrast to Epos 3 where by default all PNS servers discover one another by network broadcast and share study information. The first PNS Segment at any site is created during the installation of the software. Additional PNS Segments may be introduced by the Epos Administrator. A natural use of PNS Segments would be to separate the Epos Projects used in two different departments within a company. At a small site or in a stand-alone installation, there is a single PNS Server comprising a single PNS Segment. It is only at larger sites that multiple PNS Servers may be running, grouped into one or more PNS Segments. However at a site where Epos applications are used on laptops that may be taken off Installation Guide 9

16 Epos Infrastructure the network, it is necessary to first have a PNS Segment comprising at least one PNS Server on the permanent network, and then have a single PNS Server comprising a single PNS Segment on each laptop. The Epos Administrator must set up Segment Groups before anyone starts using the software. If there is only one PNS Server, then setting up a single Segment Group is trivial. In more complex cases, the Segment Group is a list of PNS Servers, one from each on several PNS Segments. In other words, the administrator is allowing the users to connect to more than one PNS Segment at a time, and therefore to gain access to all the projects in all those segments. This is how a laptop user is assigned the option to connect to both the laptop single-pns segment and to the network segment at the same time, to access projects registered on each. A single NFS-mounted installation of the PNS software can support multiple PNS Servers (that may even belong to several different PNS Segments) running on different machines. All PNS servers in a PNS Segment work together to present users with unified access to all available surveys on all PNS machines. The PNS Servers in one PNS Segment share a common configuration directory. 10 Installation Guide

17 3 Upgrading from Epos 3.0 or Epos 4.0 This chapter is essential reading for administrators who are upgrading an Epos 3.0 or Epos 4.0 installation to Epos 4.1. Overview Epos 4.1 software implements numerous new features for its PNS and Epos Service components. The new functionality requires database upgrades for both PNS and Epos Service databases. As a result of this requirement, Epos 4.0 and Epos 4.1 software cannot interoperate. The existing Epos 4.0 data needs be adjusted to fit the new system requirements. Data model adjustment procedure is automatically performed by Epos Services when the database files are first accessed. This document describes Epos 4.0 to Epos 4.1 database upgrade scenarios relevant to the existing Epos 4.0 Rollup 3 software users. Upgrading a Site from Epos 4.0 to Epos 4.1 The Epos 4.1 software installs into different directories than Epos 4.0 so the two versions may be installed alongside one another (though note that the two versions have different operating system requirements). Furthermore there is no communication between Epos 4.0 and Epos 4.1 clients and servers so the two versions may be operated independently at the same time. However you cannot run both Epos 4.0 services and Epos 4.1 services on the same machine. Unlike previous upgrades, the Epos 4.0 to Epos 4.1 Database Upgrade is carried out automatically the first time that a database is opened in Epos 4.1. Upgraded databases cannot be downgraded from Epos 4.1 to Epos 4.0. The following technical constraints affect the options available to Epos 4.1 users when upgrading databases from Epos 4.0 Rollup 3: PNS 4.0 and PNS 4.1 cannot be run simultaneously on the same machine The same repository cannot be registered in PNS more than once (not even in PNS 4.0 and PNS 4.1) Installation Guide 11

18 Upgrading from Epos 3.0 or Epos 4.0 Upgraded databases can no longer be used by Epos 4.0 Epos Service components These restrictions dictate the database upgrade techniques supported by Paradigm. Upgrade Techniques The upgrade procedure requires careful planning to avoid data loss and minimize the system downtime. Epos 4.0 data should be backed up regardless of the upgrade technique chosen. Epos 4.1 administrators need to make the following system configuration choices: Reuse the existing PNS machine or allocate a new PNS machine for Epos 4.1 Reuse the existing Epos 4.0 data or duplicate it in the new system Sometimes, the configuration choices are dictated by the hardware restrictions. For example, laptop users can only reuse the same PNS machine. Also, disk space limitations may prevent the data duplication option. Bear in mind that an existing RHEL 4.x machine will not be able to run Epos 4.1 applications or services. Several upgrade methods are available to Epos 4.1 users as described in-depth in the following sections: PNS 4.0 database can be reused in place Some PNS 4.0 settings can be migrated to PNS 4.1 database PNS 4.0 study registrations may be moved to PNS 4.1 system Epos 4.0 data can be copied to Epos 4.1 system Backup of Epos 4.0 data can be restored in Epos 4.1 system Regardless of the upgrade method used, PNS and Epos Services in Epos 4.1 system automatically take care of data model adjustments when the repositories are first accessed. Reuse PNS Segment The existing PNS 4.0 segment data can be reused in place if PNS 4.1 is intended to run on the same host. If a segment is comprised by more than one host, all of them must run PNS 4.1 servers. It is mandatory to shut down all running PNS 4.0 and Epos Service processes before reusing the segment in place. The existing segment data must be backed up to allow for a fast fallback in case something goes wrong. To reuse the existing PNS 4.0 segment, users should point PNS 4.1 Segment Path to the existing PNS 4.0 segment data directory. This can be done either during PNS 4.1 installation or new segment creation procedures. When PNS 4.1 process starts using the existing PNS 4.0 segment databases, it performs automatic data model adjustments, so the databases can no longer be used by PNS 4.0 software. Successful database upgrade and PNS 4.1 startup should be verified in PNS log files. It is recommended to complete PNS 4.1 segment upgrade by adding the new information missing in PNS 4.0. This information includes Data Path, Data Path Permissions, Data Path Snapshots, and Database Administrators definitions. Once the segment configuration is complete, users may want to upgrade all the repositories from the segment hosts to Epos 4.1 data model. This procedure can be performed by using a command line <Applications>/bin/cli/PG_epos_start_services script. The script simply starts all the necessary services for projects, surveys and culture repositories, waits until the repositories are 12 Installation Guide

19 Upgrading from Epos 3.0 or Epos 4.0 updated and shuts the services down. It can be executed for a single study or for all projects, surveys and culture repositories registered on a PNS host. Migrate PNS Settings If PNS 4.0 and PNS 4.1 services are configured to run on different hosts, some data can be migrated to the new system to alleviate its configuration process. A special "Import Segment Settings" utility available in Segment Configuration application must be used to import segment settings. The utility allows for importing data from a running PNS 4.0 host as well as from a segment database file. The imported settings include the following types: Data paths Epos users Service owners Epos administrators Database creators The imported information can either be appended or replace the existing PNS 4.1 settings. Some types of information must be customized before the import takes place. Move Study Registrations Epos 4.1 Move Registration to Different Epos Server utility allows for selecting one or more source studies on PNS 4.0 host and moving their registrations to PNS 4.1 host. A PNS Group containing both 4.0 and 4.1 PNS hosts should be created and used to enable cross version registration move. Such PNS Group can only be used with utilities supporting cross-version operations. Both PNS 4.0 and PNS 4.1 servers need to be up and running to enable moving study registrations. The utility starts Epos 4.1 Services for the studies moved, so Epos databases are automatically upgraded to 4.1 data model before the utility terminates. Users can test data upgrade procedure before moving registrations to PNS 4.1. This procedure can be performed using a command line <Applications>/bin/cli/PG_epos_test_db_upgrade script. The script requires both PNS 4.0 and PNS 4.1 to be up and running. Database files registered on PNS 4.0 are copied to a temporary location and upgraded using facilities from PNS 4.1 installation. The same upgrade facilities are used by PNS 4.1 services on the original data. Therefore if the upgrade tests pass, there is a high probability for the real upgrade procedure to complete successfully. Contact Paradigm Support with the 6 information about the databases that failed the upgrade procedure tests. It is only necessary to provide database catalog files for investigating the reason for upgrade test failure. Copy Epos Data Epos 4.1 "Database Copy" utility allows for selecting one or more source studies on PNS 4.0 host and copying the data to PNS 4.1 host. A PNS Group containing both 4.0 and 4.1 PNS hosts should be created and used to enable cross version data copy. Such PNS Group can only be used with utilities supporting cross version operations. Both PNS 4.0 and PNS 4.1 servers need to be up and running to enable data copy. The utility starts Epos 4.1 Services after the data is copied, so Epos databases are automatically upgraded to 4.1 data model before the utility terminates. Installation Guide 13

20 Upgrading from Epos 3.0 or Epos 4.0 Restore Epos Data Epos 4.1 "Backup and Restore" utility allows for restoring data archives created in Epos 4.0 format. Both 4.0 and 4.1 header files are accepted in Restore File Selection dialog of the utility. Only PNS 4.1 server needs to be up and running to restore Epos 4.0 archive in Epos 4.1 system. The utility starts Epos 4.1 Services after the data is restored, so Epos databases are automatically upgraded to 4.1 data model before the utility terminates. Recommended Upgrade Workflow The workflow recommended by Paradigm depends on whether Epos is installed in a stand-alone or networked environment. Stand-alone environments assume single user (laptop or private workstations), while networked environments assume multiple users working with one or more instances of PNS and Epos Services. Stand-Alone Due to inability to run both PNS 4.0 and PNS 4.1 on the same machine at the same time, stand-alone environments must upgrade all data at once. The recommended procedure is to back up the existing PNS 4.0 segment data and reuse it in place for PNS 4.1 software. Stand-alone machines may not have the required disk space to store Epos 4.0 data backups locally. In that case, the backups should be stored on an attached storage or in the network. Paradigm recommends backing up Epos 4.0 data before moving to Epos 4.1 system. Networked Enterprise environments may choose to reuse PNS 4.0 database in place or set up a brand new PNS 4.1 database. Paradigm recommends performing Epos 4.1 software testing in a production environment using production data before proceeding with the commercial use of the new system. This necessitates setting up at least one dedicated PNS 4.1 host for the period of testing. The process of setting up the new configuration may be simplified by performing the migration of the existing PNS 4.0 settings to PNS 4.1 database. In addition, the new environment should be populated with data using Epos Data Copy or Epos Restore procedures. Paradigm recommends using Epos Restore to import data into Epos 4.1 system because it does not involve lockout on source studies like in Epos Data Copy. The data upgrade testing procedure should also include <Applications>/bin/cli/PG_epos_test_db_upgrade script execution on all the data to be migrated to Epos 4.1. If the upgrade tests pass, there is a high probability for the real upgrade procedure to complete successfully. The real upgrade procedure should never be attempted for databases that failed the upgrade test until Paradigm Support provides a solution for the upgrade failure. After the testing is completed, users may proceed to exploit the existing PNS 4.1 system by moving PNS 4.0 registrations, so the testing environment will become the production one. Alternatively, users may choose to reuse existing PNS 4.0 databases in place. Regardless of the upgrade choice, PNS 4.0 databases and Epos 4.0 data should be backed up to allow for fast fallback if something goes wrong. 14 Installation Guide

21 Upgrading from Epos 3.0 or Epos 4.0 Paradigm recommends reusing PNS 4.0 databases in place because it is the fastest and most resource saving workflow. Depending on user requirements, it may not be always possible to stop using Epos 4.0 at once, thus the alternative of gradual data migration with or without data duplication. Windows Caveats Epos 4.1 release introduces support for Windows operating system besides the traditional Linux support. The existing Epos 4.0 software users may choose to run Epos 4.1 system on Windows platform in addition or instead of the current Linux configurations. Paradigm supports both Linux and Windows PNS 4.1 setups, so the existing Epos 4.0 data may be upgraded and registered on Windows PNS 4.1 machine. Epos 4.1 Windows software may be configured to access PNS 4.1 running on Linux host. This allows for performing all Epos 4.0 to 4.1 data upgrades in Linux environment using the techniques mentioned above. Users may choose to run one or more PNS 4.1 instances on Windows hosts. Epos 4.1 Data Management utilities do not support cross platform operations. This constraint is dictated by differences between Linux and Windows environments, especially when it comes to accessing data residing on remote file servers. Paradigm only supports upgrading Epos 4.0 data on Windows PNS 4.1 system using Epos Restore technique. If cross platform data upgrade is required, the existing Epos 4.0 data should be backed up on Linux using Epos 4.0 Data Backup and restored on Windows using Epos 4.1 Data Restore utilities. It should be noted that Epos 4.0 data backups may contain VoxelGeo data not suitable for use on Windows due to file name limitations introduced by Windows NTFS file system. Since VoxelGeo data file names are entered by users, they may contain characters unsupported on Windows. This problem does not currently have a workaround. If such file names are encountered by Epos 4.1 Data Restore utility, they are simply skipped and errors are reported in the end of the procedure. Upgrading a Site from Epos 3 TE to Epos 4.1 Epos 3 TE projects may be upgraded directly into Epos 4.1 without having to upgrade them to Epos 4.0 first. (The procedure is the same as the procedure for upgrading projects from Epos 3 TE to Epos 4.0.) This upgrade procedure normally produces new copies of all data (including seismic data). There is an option to choose not to copy the seismic data. In this case links are created to the data in Epos 3 TE. When this option is used, you should no longer access this data with Epos 3 TE. Upgraded projects cannot be downgraded from Epos 4.1 to Epos 4.0 nor to Epos 3 TE. Installation Guide 15

22 Upgrading from Epos 3.0 or Epos Installation Guide

23 4 Upgrading from Paradigm 2011 This chapter explains the factors to be taken into consideration when upgrading from or.1 to.2. Overview Paradigm is packaged as a full release. It is installed using our new convention for installation paths, using Paradigm /Applications and Paradigm /Services installation paths. No previous Paradigm versions are required. Both Applications and Services are required to be upgraded to Paradigm Paradigm Applications cannot run with previous versions of Services. Backwards Compatibility Once you upgrade to , it is possible to revert, if needed, to previous Paradigm or Paradigm 2011 Applications. However, Paradigm and Paradigm 2011 Applications should remain connected to the Paradigm Services. Epos database backups created in Paradigm can only be restored using the Paradigm Services. The same hardware and system requirements apply to Paradigm 2011, Paradigm , and Paradigm We recommend that the Paradigm Applications and Services packages are installed and adopted at the same time, with older versions of the Services being shut down permanently. Upgrade Strategy Follow the instructions in Chapter 6, Installation taking into account the following additional notes related to existing installations of Paradigm You must shut down all PNS servers before beginning the installation of Paradigm Use PNS41/bin/pns_remove_service on each PNS server host. Installation Guide 17

24 Upgrading from Paradigm 2011 It is recommended to reuse the existing Segment directory(s) and the same EposDB usernames so that existing Segment settings (including all registered Epos Databases) will be immediately available. If you decide to use a new Segment directory, then be sure to create the directory owned by the EposDB user, before starting the installation process. Afterwards, you will need to configure the segment correctly, and import settings and database registrations from the old segment directory. Any desktop icons, launcher utilities, or startup scripts that refer to the Paradigm 2011 installation directories must be modified to point to the new style of installation directory name. Typically users should be given access to the two main entry points for Paradigm : Paradigm Product Manager launch command <Applications>/bin/PPM Paradigm Session Manager launch command <Applications>/bin/pg41 For Windows, an additional entry, Paradigm , will be automatically added to the Windows Start menu. 18 Installation Guide

25 5 System Requirements This chapter describes the prerequisites, supported platforms, required disk space, and hardware and software requirements for running.2. Overview Before beginning the installation, ensure that your system meets the software and hardware requirements for running Paradigm and Epos 4.1. Paradigm is available to be installed under Microsoft Windows and/or under Red Hat Enterprise Linux. The installation process is very similar whichever the operating system and this Installation Guide applies to both but there are some useful notes about Windows System considerations in Appendix D, Windows Installation. Required Disk Space Table 5-1: Required Disk Space for Installation Operating System Software Disk Space Linux Applications 4.6 GB Linux Services 850 MB Windows Applications 3.6 GB Windows Services 600 MB Selecting EposAdm and EposDB Users For best security, use a different OS user and a different OS group for EposAdm and for EposDB. On a single-user stand-alone system a single user can be used for everything. The Linux "root" user cannot be used for EposAdm, for EposDB nor to run the software. Installation Guide 19

26 System Requirements Selecting Database Directories Two types of database directory must be considered. Some Epos data is stored and managed by the Epos Data Servers and needs only to be accessible to the Epos Server host, but seismic bulk data and certain other application-specific data is stored and managed directly by the application software and should therefore be accessible from all workstations, on shared network disk space. Server data is accessed indirectly by the application software. Each of the following data types can be assigned to use different disk(s): Database directories managed by data servers: Project/Survey/Well/Culture/Drilling main database directories Interpretation data and Vertical Function data. Bulk data managed directly from applications: Seismic Application-specific data. Our database servers are more efficient when the indirect data files are stored on file systems that have not been set to use large block buffering. Our well database server makes use of file system locking. If you are using a file system optimized for HPC then you should not also use this file system for well databases. We support access to POSIX-compliant shared file systems via NFS. We support NTFS file systems on Windows, however we do not support Windows file-systems shared to Linux servers or workstations. Mounting Linux data on Windows is supported via CIFS only. Supported Platforms Paradigm applications and services can be run using the following processors and operating systems: Processors x64 architecture processors (x86_64) Note Note that some older CPU's are not supported your CPU must have support for SSE3 instructions, also known as the "Prescott New Instructions" (see To find out if your CPU supports SSE3/PNI, Linux users can simply run the command "cat /proc/cpuinfo", and then look in the flags section for "pni". Windows users will need to use a utility such as CPU-Z ( Operating Systems 64-bit Red Hat Enterprise Linux 5.3 and above latest version is recommended 64-bit Red Hat Enterprise Linux 6.0 and above latest version is recommended. In particular, customers using Echos on RHEL 6 should upgrade to at least version bit Windows 7 fully patched is recommended 20 Installation Guide

27 System Requirements Red Hat Device Name Issue Under RHEL 6 there is a new naming convention for the devices and the Ethernet device is now em1 instead of eth0. This particularly affects the current versions of FlexNet. Refer to our Knowledge Base on if you need information on how to circumvent the problem. Virtual Machines The Paradigm software is tested and supported on "virtual machine" solutions. However, note that applications require access to graphics drivers which is not provided by every virtual machine implementation. Thin Client/Remote Display The recommended configuration is that each user should run their applications on a local desktop or laptop machine with one of the supported NVIDIA graphics cards (see Supported Graphics Boards on page 22). The Paradigm applications are not tested or supported on remote display software except HP Remote Graphics Software (HP RGS). Other remote display systems may elicit problems in our 3D applications that we cannot address under standard support. Paradigm's 3D applications make demanding use of OpenGL graphics features and, when used with remote display software, may be impacted by the compression, encryption, decryption and decompression used in such software. When using remote display software, the network distance between the client and server machines will add latency that is not present when running on a local machine. The use of remote graphics software will introduce additional latency or delay. The combined latency and delay in interactive response will affect the interactive experience when Paradigm software is used with remote graphics software. Cluster Nodes Paradigm is additionally supported on Red Hat-compatible Linux operating systems on compute nodes for HPC work (i.e., batch or compute processes only). System Requirements and Recommendations Below is a list of hardware and software requirements and recommendations. (Graphics requirements are not relevant on any dedicated server machines that run the Epos Services but not the Epos Applications.) RAM - Minimum memory is 4 GB on each machine. Recommended memory is 4 GB per CPU core. Requirements may differ according to the application and the data. Linux Swap Space - Refer to the standard recommendations from Red Hat. See docs.redhat.com (look under Red Hat Enterprise Linux, Installation Guide). Note that Echos has additional swap space requirements refer to the Echos System Administrator s Guide. Windows Paging File Size - Refer to the technical notes on Microsoft site for any guidance you need on selecting an appropriate page file size for Windows. Installation Guide 21

28 System Requirements Graphics Support - NVIDIA GeForce/Quadro family graphics boards. Recommended graphics requirements may differ according to application and data. Manufacturers may also issue patches for their device drivers. See Vendor Patches (NVIDIA) on page 27. For a list of graphics boards required for VoxelGeo, see Additional Requirements for VoxelGeo on page 22. Linux Window Manager - Gnome is recommended. Browser - In a Windows environment, we support Microsoft Internet Explorer. In Linux environments, we support Mozilla Firefox. Whichever browser you use, JavaScript must be enabled. (Note: WAM has additional browser requirements.) PDF Viewer - We recommend Acrobat Reader for viewing the Portable Document Format (PDF) files included in this release. You can download Adobe Reader from DNS - IPv6 not supported, IPv4 assumed. Language/Locale - We recommend using the English locales (en-us, en-gb, etc.) under which the software has been validated. Paradigm is not validated to install or to run under non-english language settings. Display Color Settings - X Window System: 24-bit plane color graphic adapter with TrueColor visual mode ("Millions of Colors"). Windows Color Depth: "Highest (32-bit)". Display Resolution - No specific limitations. Minimum: 1280x1024. Dual Head Configuration - Supported. Shared Libraries - See Shared Libraries (Linux) on page 26. Vendor Patches - See Vendor Patches (Linux) on page 27 or Vendor Patches (Windows) on page 27. SCSI tape data load devices - Supported. For a site with many Epos users, we recommend allocation of a machine with at least a 1 Gigabit Ethernet (GbE) network connection to act as a dedicated machine for running PNS. Additional Requirements for VoxelGeo For the Paradigm release we have the following requirements for VoxelGeo: RAM At least 500 MB more than the largest volume you plan to load. Supported Graphics Boards NVIDIA Quadro FX 4800 NVIDIA Quadro FX 5800 NVIDIA Quadro 4000 NVIDIA Quadro 5000 NVIDIA Quadro Installation Guide

29 System Requirements VoxelGeo, SKUA, GOCAD, and StratEarth, make use of GPU rendering mode which is only available on the Quadro 4000, 5000, and 6000 boards to date. Be aware that GPU rendering will perform better if the volume can be completely contained on the board so this is a consideration for which board to use. Driver Version There is a minimum NVIDIA driver recommended level for the GPU rendering in VoxelGeo to be available currently version Manual System Configuration Some system settings can prevent Paradigm software from running properly. In these cases you may need to manually reconfigure the operating system or to install additional patches or libraries. Setting Descriptors (Linux) To check your current descriptors definition Type limit at the tcsh system prompt (or ulimit -a in bash). The following parameters with defined values are displayed, as shown in the example below: Parameter (tcsh) Parameter (bash) Value cputime cpu time unlimited filesize file size unlimited datasize data seg size kbytes stacksize stack size kbytes coredumpsize core file size 0 kbytes memoryuse max memory size unlimited vmemoryuse virtual memory unlimited descriptors open files 1024 memorylocked max locked memory 64 kbytes maxproc max user processes 1024 To increase the defined descriptors Some systems set the default to 1024 which may not be sufficient for Paradigm applications running on user workstations. Type limit descriptors <value> at the system prompt where <value> is the number of files that can be open at one time. For example: limit descriptors (In bash, the command is ulimit -n 65536) However you cannot increase the limit past the maximum that has been set within the operating system; only the local system administrator may increase this and other limits by editing the /etc/security/limits.conf file: To increase the default number to by editing /etc/security/limits.conf and add the line: Installation Guide 23

30 System Requirements * - nofile This allows up to open files and ports per process. To set the file system mount points Set the mount option actimeo to 5 or less. This ensures that the file and directory attributes are kept reasonably up to date, if they are changed frequently from various client locations. To change the number of SSH connections Epos may require a large number of ssh connections on the Epos Server host. Edit /etc/ssh/sshd_config and change the MaxStartups setting: MaxStartups to 1024 To prevent DNS lookup failures Too many ssh calls to the DNS server can result in DNS lookup failures. Edit /etc/ssh/sshd_config and change the UseDNS setting: UseDNS no To increase the maximum number of process and thread identifiers On Epos Server hosts, increase the maximum number of process and thread identifiers: sysctl -w kernel.pid_max=65536 Setting Descriptors (Windows) We have no specific information to provide regarding file descriptor limits under Windows. Shared Memory Configuration (Linux) Some versions of the Linux operating system allow applications a very small amount of shared memory. This may need to be expanded to allow you to load the volumes you plan to use. There are two system parameters related to large memory access. These can be set without requiring a reboot. They can also be added to the /etc/sysctl.conf file to be consistent from boot to boot. Set these parameters as follows: kernel.shmmax This parameter controls the allowable shared memory segment size. This must be larger than the largest volume you plan to load. Typically this is set equal to, or slightly less than physical memory. kernel.shmall This parameter controls the amount of memory all shared memory segments combined can take. This parameter is typically in pages, which are usually 4096 bytes for most systems. Typically shmall should be set to shmmax/pagesize (usually 4096). To view the current values: cat /proc/sys/kernel/shmmax cat /proc/sys/kernel/shmall 24 Installation Guide

31 System Requirements Dynamic example for 16 gigabytes: /sbin/sysctl -w kernel.shmmax= /sbin/sysctl -w kernel.shmall= Persistent example for 16 gigabytes: Add the following lines to the /etc/sysctl.conf file: kernel.shmmax = kernel.shmall = Swappiness (Linux) The swappiness kernel parameter is a value from 0 to 100 percent which can influence the way a system does memory page swapping. The default value in Red Hat Linux is 60% but a lower value may improve performance and give a more responsive feel to applications. We recommend a value of 10% for Epos workstations and servers. The system administrator should additionally monitor the workstation behavior and adjust the value appropriately. To change the swappiness temporarily: /sbin/sysctl -w vm.swappiness=10 To make it persistent, add the following line to the /etc/sysctl.conf file: vm.swappiness = 10 Shared Memory Configuration (Windows) There are no special instructions for setting up shared memory on Windows. Note that Paradigm applications on Windows use a utility program called VgToolsShm.exe to manage shared memory. Window Manager Settings (Linux only) Dual X screen, TwinView, and Xinerama configurations are supported. The recommended default desktop environment for running Paradigm 2011 is Gnome. (Paradigm previously recommended KDE for earlier versions of Epos.) Individual users should select a Gnome session from the login page options before logging in. We also recommend that every user is encouraged to make the following change to their settings so that the ALT key can be used for specific functionality in 3D Canvas and in VoxelGeo (otherwise it will move the windows). 1. Open the Gnome Panel. 2. Select System, then Preferences and then select Windows. 3. In the Window Preferences dialog box, set the To move a window... key to Super. Installation Guide 25

32 System Requirements Setting up Gnome Desktop Launcher Icons (Linux only) 1. From the third button menu on the desktop choose Create Launcher. 2. Set Type to "Application in Terminal", set Name to "Paradigm Product Manager", set the command to the full path of the PPM command <Applications>/bin/PPM, and set the icon to the name of the Paradigm logo file (PG_LogoLarge.png) which is located in <Applications>/config/graphics/Icons. 3. Repeat the above to create a similar icon for the session manager. In this case set Name to "Paradigm Session Manager" and set the command to the full path of the pg41 command <Applications>/bin/pg The resulting launcher definitions are stored in ~/Desktop in.desktop files which can be conveniently copied to other user s ~/Desktop directories. Shared Libraries (Linux) The default operating system installation is adequate for running Paradigm 2011 products. To check that all required libraries are installed, run <Applications>/bin/PG_epos_config after you have installed Epos and select the System Diagnostics option. Use your operating system vendor s instructions to install any missing required packages. In general, Paradigm products have been tested to run on workstations with the default manufacture operating system installation setup. However, some applications may require the installation of certain shared libraries which may not be part of the default operating system installation setup. The following RPMs may need to be installed using "yum". xterm kdegraphics (and packages on which it depends) libxp compat-libstdc (on RHEL 6) 26 Installation Guide

33 System Requirements compat-libf2c openmotif (for libmrm.so.3, libxm.so.3) openmotif (for libmrm.so.4, libxm.so.4) GCC and X development libraries are required for Echos and for OpenGeo. The version of NetworkManager that ships with Red Hat 6.0 is el6.x86_64. That version has a bug (documented here: Use yum to update the NetworkManager package to el6_1.1.x86_64 or higher. (This is not a problem with RHEL 6.1 which ships with version el6.x86_64 by default.) To check if a specific package is installed on your system Type the following command: rpm -q <package name> Vendor Patches (Linux) The Linux community is continually improving the Linux O/S components and making updates and rpm packages available to the public. One commonly used mechanism is the up2date utility on systems with Red Hat Linux. This should be used with care since updates to the operating system could be incompatible with Paradigm Vendor Patches (Windows) Updates to Windows are regularly issued by Microsoft and automatically installed on each Windows computer or rolled out under the control of the local IT administrators. This should be used with care since updates to the operating system could be incompatible with Paradigm Vendor Patches (NVIDIA) The latest nvidia driver is recommended since newer drivers often include bug fixes that have been requested by Paradigm and there are frequent updates. If you have any concerns or questions contact Paradigm Customer Support for the latest information. Installation Guide 27

34 System Requirements 28 Installation Guide

35 6 Installation This chapter describes the procedure for installing.2. The installation procedure is intended for use by your system administrator or other personnel familiar with your local systems and network configuration. Overview The Paradigm application software and the Epos 4.1 infrastructure software can be downloaded from the Paradigm customer support website Paradigm software packages each contain a pgsetup command that you should find and run to begin the installation. Installation Guide 29

36 Installation 1. Preparation - Select Epos Server host(s) for running PNS and Epos Shared Services - Check system requirements for Epos servers and systems running Epos applications - Select the license file location - Select OS usernames for the Epos Administrator and the Epos Database Administrator - Select Installation and Data Directories 2. Install and Configure Epos Services - Install and Configure PNS including setup of PNS segment directory - Start PNS - Install Epos Shared Services and optional Third-Party Services 3. Install Epos Applications 4. Local Software Configuration - Setup Epos Users - Setup Data Paths - Setup Segment Groups 5. Upgrade Epos 3 TE Projects (Optional) Preparation Fig. 6-1: Installation Workflow Before you begin, check that you have a valid license file from Paradigm containing the features for the products that you expect to install. In particular, check that the expiration date of each feature line is in the future and that the maintenance date on each feature line is beyond the release date of the Paradigm 2011 software. Paradigm 2011 requires new license files using a higher level encryption. 30 Installation Guide

37 Installation Select one (or more) Epos hosts that will run the PNS server and other shared services. Make sure the server meets the system requirements for an Epos Server machine. (If you are installing on a standalone system, then the Epos Server machine is the same as the Epos application machine.) Make sure that all desktop or laptop computers that are to be used to run Epos application software meet the system requirements. Select OS usernames to be used for the EposAdm and EposDB administrative users, e.g., pgadm, pgdb. This can be ignored on a stand-alone system where you can use a single OS username for all activities. Select Installation and Data Directories. Create these directories in advance. The Paradigm / Services and Paradigm /Applications directories will be owned by the EposAdm user who is installing the software. The Segment directory and the data path directories should be owned by the EposDB user. To help with planning the installation, the following table is provided and it is advisable that you save this information for future reference.: License location (PRDM_GEO_LICENSE_FILE): Host to run PNS server: Hosts to run Application software (e.g., all networked Linux Red Hat 5 machines): Username of the "EposAdm" administrative user who will install and own the Epos software (e.g., pgadmin): Username of the "EposDB" administrative user who will own the Epos database files (e.g., pgdb): Directory for the installation of Epos application software e.g., /apps/pdgm/paradigm /applications or C:\Program Files\Paradigm\Paradigm \Applications Owner: The EposAdm user. Directory for the installation of Epos server software e.g., /apps/pdgm/paradigm /services or C:\Program Files\Paradigm\Paradigm \Services Owner: The EposAdm user. Directory for server settings i.e., PNS Segment Directory (e.g., /apps/pdgm/segment on Linux, or C:\ProgramData\Paradigm\PNS41\Segment on Windows): Owner: The EposDB user. Directories for storing Epos projects and surveys: (1) Seismic and Application Direct Access Bulk Data (e.g.,/data1/eposbulk/ on Linux, or C:\Program Files\Paradigm\BulkData on Windows): Owner: The EposDB user. Write permission for all Epos users. (2) Project, Interpretation and other Indirect Access Data (e.g., /data1/eposdata/ on Linux, or D:\Paradigm\Projects on Windows): Owner: The EposDB user. Installation Guide 31

38 Installation Starting the Installer In each top level package directory, you will find a utility called pgsetup that will start the installer and lead you through the package installation. For each package you should follow this pattern: 1. Log in as the EposAdm user who is going to install, own, and manage the software. 2. If the software package is in a compressed file then it needs to be extracted: In Windows Explorer, select the.zip file and use the third mouse button (right-click) and choose "Extract Here". (Note: The zip file should be extracted to a local disk for installation on a Windows machine.) In Linux Nautilus, select the.tar.gz file and use the third mouse button (right-click) and choose "Extract Here". Or, in a Linux command shell: tar zxf <filename.tar.gz> 3. Locate and run pgsetup: On Windows, use the Windows Explorer to locate the pgsetup.cmd file in the package folder. Double click to run the command. On Linux, use Nautilus to locate the pgsetup script in the package directory and double click to run it. Or, in a Linux command shell: cd <package directory>./pgsetup The splash screen appears and the installation proceeds. Paradigm Services Installation The first package to install is the Epos Services package containing the Paradigm Name Service (PNS) and other Epos Infrastructure software. In a networked environment it will be most convenient to carry out this installation while logged into (one of) the designated Epos Server hosts as the EposAdm user. 32 Installation Guide

39 Installation 1. Locate and run the pgsetup utility in the EposServices package directory. The splash screen appears: Installation Guide 33

40 Installation 2. Click Next. The Software License Agreement Reminder appears. 34 Installation Guide

41 Installation 3. As part of the installation, you are required to acknowledge that the use of the software you are installing will be governed by your License Agreement with Paradigm, then click Next. The Installation Path screen appears. 4. If the directory you specified does not exist, click Yes to the following prompt: Directory <the directory you specified> does not exist. Do you want to create it? Installation Guide 35

42 Installation 5. The Selected Settings screen appears, showing the amount of disk space required and the amount of disk space available: 36 Installation Guide

43 Installation 6. Click Next. The Epos Services Installation files are extracted and saved to disk. 7. The New Segment screen appears. All PNS Servers must belong to a PNS Segment in Epos 4.1. At this stage in the installation, the first PNS Segment is created. Additional segments may be added later. The segment directory must already exist and must be owned by the nominated EposDB user. If you are re-using a segment directory from Epos 4.0 then be sure to specify the existing segment directory and the correct EposDB username. Note For a stand-alone installation you can accept the defaults for the segment. For multiuser installations, you should enter a suitable name for the segment (e.g., "Geology Department"), enter your previously created segment directory path (owned by the EposDB User) for storing PNS settings, enter the username of your chosen EposDB User, and enter a list that includes the hosts (at least one) that are going to run PNS. Installation Guide 37

44 Installation 8. Click Save. At this point, the installer will attempt to install PNS as an Operating System Service. Under Linux you will be required to enter a root account name and password in order to do this part of the installation. 38 Installation Guide

45 Installation The Epos Services installation is now complete. Third-Party Services The optional Third-Party Services (GeoFrame 4.5, OpenWorks , OpenWorks 5000, and GOCAD) may be installed at a later time and are not required to complete the installation immediately. A separate installation guide is included for the Third-Party services and you should review this guide if you intend to install the Third-Party Services now. See Help > Installation and Configuration > Installation Guides > Third-Party Data Servers. Paradigm Applications Installation Note This does not depend on any other packages, but it requires an Epos Shared Services installation in order to run. Installation Guide 39

46 Installation 1. Launch the pgsetup utility as described above. After visiting the splash screen and accepting the Paradigm License Agreement, the Installation Path screen appears. 2. If the directory you specified does not exist, click Yes to the following prompt: Directory <the directory you specified> does not exist. Do you want to create it?. 40 Installation Guide

47 Installation 3. Click Next. The Runtime Environment Variables screen appears. Installation Guide 41

48 Installation 4. Edit the runtime variables if necessary, including the path of your license file if you know it. The variables can all be reconfigured later if necessary using the PG_epos_config utility. See Chapter 8, Site Configuration. Note You can move the mouse over the variables for more information. Table 6-1: Environment Variables to be checked/set during installation Environment Variable PG_RUNTIME_ENV_DIR PRDM_GEO_LICENSE_FILE SM_UMASK SM_DEFAULT_PRJ_DIR STRATIMAGIC_PLOT_DIR DEX_FORMAT_DB_DIR Notes Environment variable settings are normally saved under the config subdirectory within the software installation but the administrator may specify an alternative path here if desired. Specify the FlexNet license file or use the convention to point to the license manager. Permissions UMASK for Stratimagic file creation. Predefines the default Stratimagic project path proposed upon project creation. There is no default project path. If this variable is not defined, Stratimagic proposes the user s home directory when creating a project. We recommend defining it into a directory outside of the Stratimagic installation. Predefines the default CGM plot path proposed when using the plotting option. The CGM plots are saved in the directory defined by this variable. Points to the directory in which all the Stratimagic Data Exchange export/ import formats are saved. 42 Installation Guide

49 Installation Table 6-1: Environment Variables to be checked/set during installation Environment Variable PG_SITE_PREF PG_WAM_LINK PG_WEB_BROWSER Notes Site-wide shared preferences are normally saved under the config subdirectory within the software installation but the administrator may specify an alternative path here if desired. This variable can be set to the URL of the local WAM web server. A typical example would be This is the browser in which the WAM will be launched. Typical value: /<firefox directory>/firefox 5. Click Next. The Paradigm Applications are installed. Installation Guide 43

50 Installation 6. After the installation is completed, click Next. The Post-install program is launched. 7. If you have previously used Stratimagic stand-alone then choose this option and specify the existing "studies" file which will be copied to the new installation to make all existing stand-alone Stratimagic studies available in the new version. 44 Installation Guide

51 Installation Installation Guide 45

52 Installation Setting Up Epos Users Epos cannot run without an Epos User account in the PNS Segment. To review Epos Administrator, Epos Database Administrator, and Epos User roles, see Chapter 2, Epos Infrastructure. To run the application software, you must run under an Epos User account. The following brief overview describes how an Epos User is created: While still logged in as the EposAdm User, run the Epos Services Control Panel. (Under Windows this is found on the Start Menu; under Linux use the command <Services>/bin/pns_config. Click Segment Configuration. Create at least one Epos User account and assign at least one OS username to the account. Note Epos Users are managed through security settings in the PNS server. For complete details about PNS server configuration settings see Help > Infrastructure > Paradigm Name Service (PNS) and Other Shared Services > PNS User Guide > Epos Services Control Panel. Note For complete details about Epos User account management, see Help > Infrastructure > Epos Infrastructure > Epos Users and Permissions. Example of setting up a single user 1. Login as the EposAdm User, and choose Epos Services Control Panel from the Start Menu or type <Services>/bin/pns_config from the PNS4 installation tree. 46 Installation Guide

53 Installation 2. In the Administration tab select Segment Configuration. The PNS Segments Configuration wizard appears. Installation Guide 47

54 Installation 3. From the Action menu, select Configure Segment Security, and click Next. The Select Security Settings screen appears. 48 Installation Guide

55 Installation 4. Verify that Epos User Settings is selected and click Next. The Epos User Configuration screen appears. Installation Guide 49

56 Installation 5. From the Action menu, select Create New Epos User and click Next. The Create New Epos User screen appears. 6. In the Epos User Name text box, type the name of the Epos User that you wish to create. 7. For this Epos User you have the choice of adding OS Users, OS Groups or other Epos Users to this new Epos User. Add choices by highlighting items and adding them with the right arrow or removing them with the left arrow. 8. After making your selections, click Save. You may create more Epos Users at this point or you may exit the current screen by clicking Cancel. 9. Exit the pns_config tool by clicking End. The newly createdepos User account is ready to be used by the selected OS user(s) when they first run Epos. Consider whether to change the list of authorized database creators from ALL_USERS to a shorter list of Epos Users in order to control who is able to create new Epos projects. For complete details concerning Epos User account management, see Help > Infrastructure > Epos Infrastructure > Epos Users and Permissions. Setting Up Data Paths and Security An Epos Segment may be managed or unmanaged. By default, an Epos User can create databases that store Epos data in any directory path this is the unmanaged case. You may wish to use the security features of Epos 4.1 to control this by specifying some managed data paths. This step may be skipped for a stand-alone installation. 50 Installation Guide

57 Installation While still logged in as the EposAdm user, run the Epos Services Control Panel (this is found on the Windows Start Menu or on Linux by typing the command <Services>/bin/pns_config) and choose Segment Configuration, then in the Action menu, select Configure Segment Settings, and select Data Path Settings. There are more that six data types that can be assigned different data paths. Two of these (Seismic and Application data) are direct-access data paths that must be mounted on Epos Application workstations. The others (Project, Interpretation, Vertical Function, Well, Culture and Drilling) are used for indirectly accessed data and may be mounted on the Epos Server machine(s) only. Before assigning these data paths you should create the directories. The owner should be set to the EposDB user s username. The two directly accessed paths need suitable permissions for all database creators to be able to create subdirectories whereas the indirectly accessed data is only ever accessed by the EposDB user. Note Epos Users are managed through security settings in the PNS server. For complete details about PNS server configuration settings, see Help > Infrastructure > Paradigm Name Service (PNS) and Other Shared Services > PNS User Guide > Epos Services Control Panel. Setting Up Segment Groups The final requirement for the administrator is to run the PNS Group Management tool to provide a list of PNS segments that users can choose from when starting the Epos Applications and connecting to Epos Services. This step must be completed, and at least one PNS group must be configured in order to run the Epos application software. Installation Guide 51

58 Installation 1. While still logged in as the EposAdm user, run the Epos Applications Control Panel (from the Windows Start menu or by typing the command <Applications>/bin/ PG_epos_config) and from the Administrator tab, select PNS Group Management. 52 Installation Guide

59 Installation 2. To get started, create a single PNS Group comprising the main PNS server of your PNS Segment. Supply the PNS host name and a comment, then save it. Note For complete details about PNS Group Management, see Help > Installation and Configuration > Epos Applications Control Panel > Administrator Tools > PNS Group Management. Next Steps After you have completed the installation procedure, proceed as follows. On Windows, these entry points have shortcuts in the Start menu under the Paradigm folder): 1. Set up your license for running Epos 4.1. See Chapter 7, Licensing. 2. Run the Site Configuration utility for Epos 4.1. See Chapter 8, Site Configuration. 3. Run base Epos 4.1 applications and verify the installation. See Chapter 9, Running Paradigm 2011 Applications. 4. Run Stratimagic Paradigm and verify the installation. See Chapter 11, Running Stratimagic. 5. Run WAM and verify the installation. See Chapter 12, Configuring WAM. Installation Guide 53

60 Installation 54 Installation Guide

61 7 Licensing After the.2 software is installed, the Paradigm License Manager must be running before the software can be started. Overview Paradigm products are licensed and managed by means of the FlexNet Publisher License Server Manager (formerly known as FLEXlm) version The installation and administration of the license server is described in the FlexNet Publisher License Administration Guide from Flexera Software. For your convenience Paradigm comes with tools for installing and setting up your license server. Windows users may use the lmtools utility that is included with the software. (See C:\Program Files\Paradigm \Applications\util\FLEXnet\Win_x64_XP_v10\lmtools.exe.) The License Manager utility can be found in the Epos Application Control Panel > Administrator tab. A command line version of the license manager utility (PG_lm) may be found in the <Applications>/bin directory. Installation Guide 55

62 Licensing Fig. 7-1: Paradigm License Manager Utility The License Manager utility assists you to: Install a license file. Start the license server manager on the chosen machine. Create a license server manager startup script for automatically starting the license server manager whenever the machine is booted. Run diagnostic tools for troubleshooting licensing problems. Choosing a License Location The license server manager may be located on any convenient host on the local area network. Note that there is a certain amount of continuous network traffic between the Epos applications and the license server manager, so while Paradigm does supply WAN licenses, these would substantially slow down the software for end users even on a relatively responsive network. Normally a single host is selected to run the license server manager. The hostid (or lmhostid or mac address) of this machine should be sent to Paradigm Customer Support. From this key, a license file will be generated and ed to the main contact at your site. PG_lm can be used to obtain the lmhostid on the selected license host after the software has been installed. When the license file arrives from Paradigm Customer Support, it will take the form of an ASCII file and may have a long name such as fr2133_oilco_marseilles_host17_epos4_ lic. Make a copy of this file: we suggest you call it license.lic. Check that the file begins with a SERVER line and 56 Installation Guide

63 Licensing a DAEMON line (ignoring any comment lines beginning with the "#" character). Check that the hostname in the SERVER line is correct. Under Linux, if the file has been transferred from Windows to Linux you may need to convert it using the dos2unix utility. Choose and create a suitable directory where the license file will reside: The most straightforward choice is to create a directory called licenses in the top level directory of the same file system where the Paradigm software was installed. If you are setting up an isolated license server manager then select/create a local directory on the license server manager host. Put your license.lic file into the chosen directory. Both the Epos Applications and the Epos Services keep a record of the license location so they can connect to the license server manager and obtain a license key when needed. You can change the settings for the Epos Applications using the Epos Applications Control Panel and altering the Runtime Variable PRDM_GEO_LICENSE_FILE. (You must be logged in as the EposAdm user to change this setting.) Then you can change the license setting for the Epos Services using the Epos Services Control Panel. In both cases you can either specify the path to the license file or you can use the port@host notation to specify a network connection to the license server manager. The default port for the Paradigm license server manager is Checking the Maintenance Expiration Date in Your License File Contact Paradigm customer support if the release date of Paradigm exceeds the maintenance expiration date in your license file. You can check the maintenance expiration date in your current license file: An example of a typical INCREMENT line from a license file: INCREMENT product prdm_geo dec BCCB36AD52985B20667D ck=63 SIGN=BCCB36AD5298 The maintenance expiration date is which is 31 December In this example, only software released before this date can be used; not to be confused with the license expiry date ( 31-dec-2030 in this example). Installing a New License File Note Check that the host name is correctly defined in the license file. 1. Log in as the EposAdm user. 2. Use the Epos Applications Control Panel (PG_epos_config) and set the Runtime Variable PRDM_GEO_LICENSE_FILE to the full path name of the license.lic file or use the port@host notation as described above. 3. You can optionally also set the PG_LICENSE_LOG_LOCATION to license.log in the same directory where the license.lic file is. Installation Guide 57

64 Licensing 4. Run the License Manager utility. 58 Installation Guide

65 Licensing 5. Select the option "Create License Manager Startup Script". 6. Under Linux you can use the "cat" command to display the new startup script. Installation Guide 59

66 Licensing 7. Select the option to Run the License Manager Startup Script on Boot i.e., whenever the server machine is restarted. 8. You will have to supply the root password for the license server machine. The startup script will be copied into the /etc/init.d directory and installed as an OS service. 60 Installation Guide

67 Licensing 9. Select the option to Run the License Manager. Installation Guide 61

68 Licensing 10. Click Start. 62 Installation Guide

69 Licensing 11. The license manager is started and you are prompted to check the license manager status to make sure that it is running Installation Guide 63

70 Licensing 12. Select Display License Manager Status. 64 Installation Guide

71 Licensing 13. You may leave "Individual Feature" and "Individual Daemon" blank for a full status report. Installation Guide 65

72 Licensing 14. You should see that both daemons are up and running: "license server UP" and "prdm_geo: UP". For more information on license files, refer to the "FlexNet End User Manual." 66 Installation Guide

73 8 Site Configuration This chapter summarizes site configuration options that can be performed after the installation has been completed. Site configuration is performed using the Epos Applications Control Panel (the PG_epos_config tool) and the Epos Services Control Panel (the pns_config tool). Epos Applications Control Panel Administrator Tab PNS Group Management - Used to configure user access to the Epos Services. Runtime variables - Use to configure runtime environment variables used by Epos. Uninstall - Primarily used to uninstall added support packs. Root terminal Update Site Preferences - Allows the administrator to promote a user s preferences to become the shared preferences for all the users at the site. License Manager - For configuring the FlexNet license manager. Configuration Editor - Editor for Well Database configuration files. Epos Database Tab Backup & Restore Database Copy - Create a copy (clone) of an Epos database. Move Registration to Different Epos Server - Used for moving projects and surveys from one PNS host to another PNS host. Database Delete - Used to delete projects or surveys and remove all associated files. Move Epos Data - Helps the user to relocate physical data files to different data paths. Change Project Administrator - Sign a database over to another Epos User who becomes the Project Administrator of the database. Installation Guide 67

74 Site Configuration Recover Data from Snapshot - Utilize a local file system snapshot facility to recover lost database files. Update Seismic Paths to Epos 4 Convention - This is used on databases that were originally upgraded from Epos 3 without copying seismic data, when it becomes desirable to consolidate all seismic data in designated Epos 4 data paths. Condense and Analyze SQL Database - Database maintenance tools. Project Accessibility Check - Test access to databases. Display Users Connected to Database - A list of current users. Find Back References - For a survey or other database, show which Epos Project databases it forms a part of. Database Disk Space - Calculate physical disk space using by databases. Retagging Data - Global replacement of Epos User names for when a user name is no longer working on the database. Diagnostics/Information Tab Collect Information - Used to collect systems and software data for support purposes. Install Information - Provides a list of installed software packages (client side). System Diagnostics - Runs various diagnostics tests for support purposes. PNS Group Selection - Used to select the Epos Server(s) on which a user s databases may be stored. Cluster tools - Tools for configuring the Cluster Performance Monitor and tools for creating SSH keys needed by parallel applications. User authentication - Is used for SSH authentication for a user. QT Config - Is used to change QT settings used by Epos to customize the interface in terms of style, fonts, appearance, etc. For more detailed information about each configuration option, see Help > Installation and Configuration > Epos Applications Control Panel. Epos Services Control Panel Administrator Tab Maintenance Operations - Prevent/Release access to services during maintenance operations. PNS DB Manager - A set of database internal management tools. PNS Reset - Allows a PNS server to be soft-restarted. Segment Configuration - All the functionality for controlling the organizing of users, disks, and database security and access. Root Terminal. Service Setup - Revisit the configuration stages of the Epos Services (including Third-Party Services) installation procedure. 68 Installation Guide

75 Site Configuration User Tab Uninstall - For removing Support Patches. User Authentication - Apply SSH authentication for use by Third-Party Data Services. CSS Manager - Utility for managing Coordinate Systems and geodetics. Install Information - Provides a list of installed software packages (server side). Diagnostics - Perform various diagnostics tests for support purposes PNS Manager - Utility for interrogating and managing the internal state of PNS daemons. For more detailed information about each configuration option, see Help > Infrastructure > Paradigm Name Service (PNS) and Other Shared Services > PNS User Guide > > Epos Services Control Panel. Installation Guide 69

76 Site Configuration 70 Installation Guide

77 9 Running Paradigm 2011 Applications This chapter describes the procedure for running the Paradigm 2011 applications and verifying that the installation has been carried out correctly. Running Paradigm 2011 Applications The first time you run the Paradigm 2011 applications you have to select your product(s) using the Paradigm Product Manager (PPM). See Fig Afterwards, you can run Paradigm 2011 applications for all subsequent work sessions without invoking the PPM. To run Epos applications from Paradigm Product Manager 1. If Paradigm Product Manager is available on the Start menu or from a Desktop icon you can click on that to run PPM, otherwise you will need to locate and run <Applications>/ bin/ppm. 2. Follow the instructions in Selecting your Product Configuration in the Paradigm Product Manager documentation, Help > Getting Started and Interface Basics > Paradigm Product Manager (PPM) > Selecting Your Product Configuration. 3. Click the Start Session button. Installation Guide 71

78 Running Paradigm 2011 Applications Fig. 9-1: The Paradigm Product Manager After PPM has been used to set up and save a session, it is possible to run Epos starting with the Paradigm Session Manager (skipping steps 1 and 2 above). If Paradigm Session Manager is available on the Start Menu or as a Desktop icon then you can click on that, otherwise you will need to locate and run the command <Applications>/ bin/pg Installation Guide

79 Running Paradigm 2011 Applications Fig. 9-2: The Paradigm Session Manager Gnome Desktop Setup The two commands described above (PPM and pg4) can be used in local menu systems or to create desktop shortcuts so that users may conveniently launch Epos from the desktop. A Paradigm icon is also provided in <Applications>/config/graphics/Icons should you wish to use it. For Epos administrators it may also be appropriate to also set up desktop shortcuts for the two control panel utilities. Here are the correct names for the four entry points: Table 9-1: Label Paradigm Product Manager Paradigm Session Manager Epos Applications Control Panel Epos Services Control Panel Command <Applications>/bin/PPM <Applications>/bin/pg41 <Applications>/bin/PG_epos_config <Services>/bin/pns_config Upgrading from Epos 4.0 The first time you access a project using the Paradigm 2011 software applications, it will be automatically upgraded from Epos 4.0 to Epos 4.1 format. Installation Guide 73

80 Running Paradigm 2011 Applications Upgrading from Epos 3 TE In order to work on project data created in Epos 3 TE, you need to upgrade your databases from Epos 3 TE format to Epos 4.1 format. For information on how to upgrade surveys from Epos 3 TE to Epos 4.1, see Help > Getting Started and Interface Basics > Getting Started > Upgrading an Epos 3 TE Project Survey to Epos Installation Guide

81 10 Configuring and Running Echos This chapter describes the procedure for configuring and running Echos. Completing the Installation and Configuration of Echos Note The Echos system utilities of previous versions (pgver, pgboot, pgroot, and pg_servicesd) are all superseded and no longer available as of Paradigm After installing Paradigm 2011, echos_servicesd may be optionally installed on any machines where Echos Network Services are required. It is only required if you intend to perform a remote plotting, tape, or job monitoring function. The Echos_servicesd_install script is run (as root) on any relevant machines to configure the system startup sequence to start echos_servicesd at boot time. There is no interaction between Echos Network Services and the Paradigm Name Service so echos_servicesd may be installed on the same machine(s) as PNS, yet it doesn t have to be. Before running Echos_servicesd_install an entry in the system services file (/etc/services) is needed. The recommended configuration is shown below. In the example, the echos_servicesd port used is 30458, but another port number may be used if this port is already in use at your site. echos_servicesd # Echos servicesd daemon If previous versions of Focus or Echos have been installed, but are no longer being being used, then you should remove any redundant entries in the services file for pginetd or for pg_servicesd. If you are still using older releases of Echos and using the remote plot or tape functionality, you will need to continue running the older services daemons for that release. It is not necessary for pg_servicesd to be running to monitor jobs from an older Echos release. It is safe to have both pg_servicesd and echos_servicesd running on the same machine, but they must use different port numbers. The same echos_servicesd port number will be needed for all hosts in the network that may run Echos components. This must be a unique port number and different from previous Echos releases. The system services file can be exported to hosts in the network by NIS. For example, the /etc/ nsswitch.conf file may need to include nis or nis+ on the services line. This allows a single entry to be made which is exported to all hosts in the network. For a full description, refer to the Echos System Administrator s Guide. Installation Guide 75

82 Configuring and Running Echos Running Echos Note Echos is no longer started using pgver as in previous versions. Echos can be started using one of the methods below: Launch Echos from PPM (the Paradigm Product Manager). <Applications>/bin/pg41 -cmd=echos -echos from a command line. pg41 -cmd=csh -echos from an Echos shell. 76 Installation Guide

83 11 Running Stratimagic This chapter describes the procedure for running Stratimagic. Installation Guide 77

84 Running Stratimagic Starting Stratimagic with the Paradigm Product Manager Stratimagic can be launched using the Paradigm Product Manager (PPM). You can launch Stratimagic in stand-alone mode by selecting Stratimagic Seismic Facies Classification (standalone) or launch Stratimagic integrated into Epos by selecting Stratimagic Seismic Facies Classification (Epos enabled). To open Stratimagic using the PPM 1. Open the PPM by entering the following commands: cd <Applications>/bin./PPM The PPM opens. 2. Click on Stratimagic Seismic Facies Classification (stand-alone) or Stratimagic Seismic Facies Classification (Epos enabled) in the Products list. 3. Select any embedded add-ons, stand-alone add-ons and/or companion products. 4. Click on the arrow to move your selections into the Settings column. You can save this setting with the Save Settings menu option. They are saved into your user preferences (PG_PREF4). 5. Click on the Save and Start Session button to save your settings and launch the Stratimagic session manager. From now on, you can just enter the Sm Stratimagic command to start a new session of Stratimagic. 78 Installation Guide

85 Running Stratimagic Note For more information, refer to the PPM documentation. Selecting Your PNS Group When you launch Stratimagic for the first time, you must select the PNS group (machine network containing your data) with which you want to work. The Select PNS Group dialog box automatically opens if no PNS preferences have been detected in your user settings. To select your PNS group 1. Select the PNS segment which you want to work with by highlighting it. 2. Validate with Next. A message is displayed telling you that your selection has been saved into your user preferences (PG_PREF4). Acknowledge by clicking on OK. Note You can modify the PNS segments using the PNS Group Selection tool in the Diagnostics/Information tab of the Epos Applications Control Panel opened with the Administration > Configuration Manager option in the Stratimagic Session Manager or with the Options > Epos Applications Control Panel option in the Paradigm Session Manager. Installation Guide 79

86 Running Stratimagic Running Stratimagic Stand-Alone The stand-alone version accesses: GeoFrame and OpenWorks projects via CorSer Native Stratimagic data directly. Note Stratimagic stand-alone uses a studies file to save project information. To verify the installation 1. Move down into the <Applications>/bin directory. 2. If you want to select and save your Stratimagic configuration for future uses, launch the PPM by typing in:./ppm and select Stratimagic Standalone. See To open Stratimagic using the PPM on page 78. Or If you want to launch Stratimagic directly, type:./sm Stratimagic at the system prompt. The first time you launch Stratimagic, the Select PNS Group dialog box opens. See Selecting Your PNS Group on page Once you have selected your PNS group, the Stratimagic Session Manager opens. 4. Select Help > Contents. The Stratimagic online help opens (if you installed online help). 5. In the Stratimagic Contents tab, click on Stratimagic Release Notes. The Stratimagic Release Notes opens. 80 Installation Guide

87 Running Stratimagic Running Stratimagic in the Epos Environment The Epos enabled version accesses: GeoFrame and OpenWorks projects via ULA native Stratimagic data and Epos data directly. Note Stratimagic (Epos enabled) does not use a studies file despite a studies file being requested to complete the installation procedure. To verify the installation 1. Move down into the <Applications>/bin directory. 2. Launch the PPM by typing in:./ppm 3. Select Stratimagic (Epos enabled) and the other Epos applications you require. See To open Stratimagic using the PPM on page 78. The Paradigm Session Manager opens. 4. In the Paradigm Session Manager workbench, click the Stratimagic icon. The Open Project/Survey dialog box opens. 5. Select a project and click on Open. Installation Guide 81

88 Running Stratimagic 6. The Stratimagic main window opens. 82 Installation Guide

89 Running Stratimagic 7. Each Stratimagic application (Stratimagic, NexModel, Data Exchange) has a current domain per Epos project and user stored in the user preferences. The first time the application is launched (no current domain), the domain is automatically set to Time- Migrated. 8. Select Help > Contents. The Stratimagic online help opens (if you installed online help). 9. In the Stratimagic Contents tab, click on Stratimagic Release Notes. The Stratimagic Paradigm 2011 Release Notes opens. Starting Stratimagic from the Command Line To restore the last settings, Stratimagic first looks for a pnm option recorded at launch time, then it looks for a PG_PNM variable set by the user in the environment containing a list of features (eg., Installation Guide 83

90 Running Stratimagic STRATIMAGIC+Fastqc+Attributes_ALL) and finally it reads the PG_PREF4 file that stores your PPM preferences. To set up the Stratimagic command 1. Run the PPM the first time you want to start Stratimagic and/or NexModel and/or StratQC. 2. Use the Save and Start Session button to start Stratimagic and save your settings. Table 11-1: License Key STRATIMAGIC STRATIMAGIC2D STRATIMAGIC_CP SM _ SEISFACIES SM _ TRACKER NX_COMMON Fastqc Comet Seismic Attributes: Attributes_CT or Attributes_ALL Attributes_DA or Attributes_ALL Attributes_DSC or Attributes_ALL Attributes_SD or Attributes_ALL controls access to... Generic key which controls Seismic Facies Classification and Analysis Generic key which controls Epos 2D access in Stratimagic (only available in Epos-enabled mode) To use Stratimagic as a companion product Multi Attribute Volume Classification 3D Propagator Seismic Facies Well Log Calibration: NexModel Application (Supplementary Product) Geoscience Mapping: StratQC application (Stand-alone Addon) NN Log Prediction Complex Trace & Time Series (i.e., Instantaneous) Directional Attributes - LightScape (includes Azimuth & Dip) Discontinuity Spectral Decomposition 3rd Party and Gocad Data Access: DataServer_OW OpenWorks seismic, horizon and well data links DataServer_GF GeoFrame/IESX seismic, horizon, well data links DataServer_GC Gocad data links To run Stratimagic from the command line You can run Stratimagic directly without running the PPM using a pnm option. If no settings exist for Stratimagic, you need to specify them yourself by adding them after the -pnm variable. 1. Move down into the <Applications>/bin directory. 2. Enter the Sm Stratimagic launch script suffixed by pnm and all the add-ons you want to use. For example:./sm Stratimagic -pnm STRATIMAGIC+Attributes_ALL+SM_SEISFACIES+NX_COMMON+Fastqc+Comet 84 Installation Guide

91 Running Stratimagic Options for Running the Sm Stratimagic Runtime Scripts Stratimagic Paradigm 2011 must not be installed in the same directory as a previous Stratimagic installation. By default, the Sm Stratimagic command runs Stratimagic Paradigm The table below gives the options for running the Sm Stratimagic runtime scripts. Table 11-2: Options for running the Sm Stratimagic runtime scripts Command Input Value and Options Description -pnm product1+product2 Invokes the Stratimagic Session Manager with the selected licenses. -pns_select Enables you to modify your PNS group selection. See To select your PNS group on page 79. -test Enables you to launch a prototype which has been installed with the application. Accessing Epos Data Stratimagic Paradigm 2011 exists in two configurations: Epos enabled and stand-alone. If it has been installed on top of Epos, you should launch the Stratimagic Epos Enabled configuration. To populate your project, you must use the Open Epos options in the File menu of Stratimagic s main window. Backward Compatibility Stratimagic projects upgraded to Stratimagic Paradigm 2011 can no longer be used by previous versions of Stratimagic. Installation Guide 85

92 Running Stratimagic 86 Installation Guide

93 12 Configuring WAM Note WAM is not compatible with WAM 4.0. All indexes and saved queries will be lost. In a typical installation, WAM is installed on the server host and consulted via an internet browser from a client. Three types of authentication can be implemented to verify user identity. Basic authentication: The WAM administrator must have a user account defined in NIS or in /etc/passwd. Once he has installed the WAM, he then creates the user accounts. LDAP authentication: The WAM administrator authorizes user access. User access is then controlled by the LDAP authentication mode which verifies the user name and password in the internal directory. Custom authentication: The WAM administrator authorizes user access. User access can be customized via an external module such as a security card. For each of the above authentication modes, you can also activate the HTTPS protocol which crypts communication between the WAM browser and the WAM server. The HTTPS service either uses preexisting certificates or creates certificates one per server, to authenticate server access to data. The following diagram illustrates this configuration. Installation Guide 87

94 Configuring WAM CLIENT PostgreSQL database 5432 HTTPD WAM Tomcat Map Server GIS PNS The Paradigm Name Service provides a gateway to data access: Epos, GeoFrame, OpenWorks, GOCAD etc. Available Data Servers Epos 4.1 Landmark OpenWorks and R5000 GeoFrame 4.5 Supported Data Seismic, interpretation data, and well data Well data Note The Browser, WAM application, FLEXlm, and PNS may all run on the same host or all on distinct hosts, as appropriate. 88 Installation Guide

95 Configuring WAM Overview The WAM installation is carried out in two steps: first the extraction during the Epos installation and secondly the WAM instance(s) configuration. This chapter explains the instance configuration. WAM Administrator The WAM administrator is the OS user who configures the instance. His other roles include (amongst others) indexation and database administration. To successfully perform these roles, his OS user or Epos user group: Must be declared on all the third-party databases accessed for indexation or browse purposes. He must also be a service owner and SSH authenticated for the PNS segment. See Authorizing Third-Party Database Access to the WAM Administrator on page 89. Must be included in the Epos user group defined as the PNS segment database administrator. See Defining the Database Administrator on page 89. Must be a database creator for the PNS segment. This is performed in the Epos Services Control panel using the Segment Configuration > Configure Segment Security > Service Owners Definition option. Prerequisites Authorizing Third-Party Database Access to the WAM Administrator The WAM administrator must have access to third-party databases to be able to index them and also enable users to browse projects. To access OpenWorks R5000 databases, the WAM administrator must have a wallet directory in his home directory. The Wallet directory is created the first time the R5000 application is launched. The WAM administrator s OS user must be defined as a service owner for the PNS segment and then be SSH authenticated for that segment. If his directory is shared by all the PNS hosts he wants to access, this configuration needs only to be performed once. If he has different home directories on each PNS host, the configuration must be redone on each PNS host. This is performed in the Epos Services Control Panel using the Segment Configuration > Configure Segment Security > Service Owners Definition option. Defining the Database Administrator Before launching the WAM instance configuration, you should define the database administrator. One of the main functions of the WAM administrator is project indexation. He must therefore belong to an Epos user group declared as a database administrator for the PNS segments you want to index. To differentiate the WAM administration Epos user group from other existing Epos user groups, we recommend creating a new Epos user group in which the WAM administrator is declared. The default name proposed during the instance configuration is WAM_ADMIN. Creating Epos user groups and defining the database administrator for the PNS segments is carried out using the Epos Services Control Panel. Installation Guide 89

96 Configuring WAM To define the database administrator 1. Open the Epos Services Control Panel by typing in./pns_config under the PNS tree bin directory. You should be Epos administrator to carry out this task. 2. Select Segment Configuration > Configure Segment Security. You can define both the Epos user and the Database Administrator with this tool: 3. Select EPOS User Settings to create the WAM_ADMIN Epos user. Ensure that the user configuring the WAM instance is included in the Epos user group which will be defined as the database administrator for the segment in the next step. In our example, eposuser is the WAM administrator for the instance configuration on Iris. eposuser must therefore belong to the WAM_ADMIN Epos user group: 90 Installation Guide

97 Configuring WAM Once the WAM_ADMIN Epos user group has been created, it must be defined as the database administrator for the PNS segments selected during the WAM instance configuration. Select Database Administrators Definition to define the WAM_ADMIN Epos user as the dbadmin for the segment. For more information, refer to the PNS User Guide (Help > Infrastructure > Paradigm Name Service (PNS) and Other Shared Services > PNS User Guide). Installation Guide 91

98 Configuring WAM Launching the WAM Configuration Script The WAM configuration script must be launched on each host that you want to configure as a WAM server instance. It is located in the <Applications>/WAM/bin directory. Move down into this directory and type in./configure_wam.sh. The script is interactive and is composed of a series of steps which vary according to the type of installation you want to implement namely concerning the security options. The steps are the following: Confirming the Host and WAM Administrator on page 92 Initializing the Runtime Directory on page 92 Selecting PNS Segments on page 93 Initializing Server Port Numbers on page 93 Initializing HTTPS on page 94 Initializing LDAP Authentication on page 94 Initializing Custom Authentication on page 95 Initializing WAM Index Database on page 97 Configuring the WAM GIS Basemaps on page 97 Defining the WAM Server Startup Mode on page 98 Confirming the Host and WAM Administrator The unix username that launches the configuration script assumes the function of WAM administrator. The host on which it is launched becomes a WAM server instance. To confirm the host and WAM administrator You must validate the host and WAM administrator details by typing in y. Initializing the Runtime Directory The script proposes a directory in which all the configuration information will be saved. To initialize the runtime directory Validate the directory by hitting return or enter another directory. 92 Installation Guide

99 Configuring WAM Selecting PNS Segments These are the PNS segments containing the projects you want to index. Only the WAM administrator can generate the index and to do so he must have read access on the PNS segments that you define in this step. The WAM administrator must therefore belong to the Epos user defined for the segment, read To define the database administrator on page 90. The default Epos user name proposed is WAM_ADMIN. You can modify this name by entering another Epos user. To select the list of PNS segments 1. Enter the PNS segments respecting the same list order as in Epos. WAM and Epos applications can only communicate if they share the same host/segment in the first position of their PNS_HOST variable. Hit return. 2. For each PNS segment specify the Epos user by accepting the default WAM_ADMIN or by entering a predefined Epos user. Hit return. Initializing Server Port Numbers WAM used only exist with a basic HTTP protocol. You can now encrypt information using the SSL protocol that activates an HTTPS port. WAM proposes the 8080 port for HTTP and 8443 for HTTPS. If these ports are already occupied you should provide other port numbers Installation Guide 93

100 Configuring WAM To initialize the server port numbers Validate the port numbers by hitting return or entering another port. Initializing HTTPS Note This step is optional. HTTPS protocol crypts communication between the WAM browser and the WAM server. The HTTPS service either uses pre-existing certificates or creates certificates one per instance, to authenticate server access to data. WAM can generate a PEM-encoded X509 certificate file for you. To initialize HTTPS You can either let the system generate certificate files or use your own certificates (issued by an Certificate Authority). In the latter case, the two files are required... Initializing LDAP Authentication Note This step is optional. User access can be controlled by the LDAP authentication mode which verifies the user name and password in the internal directory To initialize LDAP For the LDAP, you are asked to enter the Server Host Name, the Alternative Server Host Name (in case of a system failure on the primary server), the Server Port Number, a Distinguished Name Tree Root, the Attribute to be used as an identifier, the User Full Distinguished Name and the User Password. 94 Installation Guide

101 Configuring WAM Initializing Custom Authentication Note This step is optional. The WAM administrator authorizes user access. User access can be customized via an external module such as a security card. To provide custom authentication For a custom authentication, you are asked to enter the Apache module name and all its parameters. Installation Guide 95

102 Configuring WAM 96 Installation Guide

103 Configuring WAM Initializing WAM Index Database The WAM database port number is used by POSTGRESQL. To initialize the WAM index database 1. Leave the default number unless another application already uses it. 2. WAM administrator is then requested to enter a password to initialize the WAM Index database. The password defined is uniquely used for the WAM database. Configuring the WAM GIS Basemaps You can select Google and/or Bing for use as background layers in the GIS application. You must have licensed these applications beforehand. To configure the GIS basemaps For each application, enter yes or no. Once all the answers have been given the wam properties file is generated. Installation Guide 97

104 Configuring WAM Defining the WAM Server Startup Mode You are then asked if you want to configure the WAM server to start at boot time. We recommend that you enter y. The server will start upon the next boot. If you do not want to reboot the WAM server right away, you can start it manually using the following commands: % su <user account> (the one used for installation) % cd <Applications>/WAM/bin %./wam_server start Note The WAM instance directory is the one entered during the Initializing the Runtime Directory on page 92 step The following summary screen is displayed at the end of the instance configuration process: 98 Installation Guide

105 Configuring WAM Miscellaneous Issues This section covers the following points: Setting Up the WAM <--> PNS Connection on page 99 Licensing WAM on page 99 Running the Tomcat/WAM Server on page 99 Running WAM in the Epos Environment on page 100 Configuring Epos Seismic Data Access on page 100 Backward Compatibility on page 100 Setting Up the WAM <--> PNS Connection You do not need a local PNS installation. This means that WAM can connect to any PNS running on the local network (i.e., the local subnet). WAM searches for a PNS on the local subnet. To modify the PNS WAM contacts 1. Go to the <Applications>/WAM directory. There is a file called wam.properties. 2. Edit the file and change the wam.pns.hostname and wam.pns.eposusers values. For each PNS listed in the wam.pns.hostname, a corresponding Epos user must be entered. For example: wam.pns.hostname=vm-mach1-pns-1 wam.pns.eposusers=wam The next time the WAM server starts, it will contact this remote machine to get project information. Licensing WAM If you are using an existing Paradigm FLEXlm installation, make sure that it serves valid WAM_SERVER and WAM licences. If not you should request valid WAM licences from your local support and merge them into the existing installation. Running the Tomcat/WAM Server To start the server 1. Login as the WAM administrator. 2. Start the Tomcat/WAM server by using the command <Applications>/WAM/bin/wam_server start. Wait a few minutes for server initialization. If you have selected to start the WAM Server at bootup, it will start automatically at machine startup. Installation Guide 99

106 Configuring WAM To stop the server Stop the Tomcat/WAM Server by using the command <Applications>/WAM/bin/wam_server stop. Running WAM in the Epos Environment If the WAM environment variables have not been defined during the installation, they must be set before launching the PPM. The PPM retrieves these variables to launch the WAM. To set up the Epos environment 1. Launch the Epos Applications Control Panel by typing./pg_epos_config from the <Applications>/bin directory. 2. Select Administrator > Runtime Variables to open the Runtime Variables Configuration dialog box. 3. Set the following variables as shown: PG_WAM_LINK server>:8080/wam PG_WEB_BROWSER /<firefox directory>/firefox and save the values. Note The firefox version must support java plug-ins. On Linux, the selected Web browser must be a 32 bit browser with Java plug-in correctly configured. Configuring Epos Seismic Data Access To visualize Epos Seismic data, both the user and the Epos database administrator (EposDB) must have read access OS permissions on the seismic files. If the EposDB does not have read permissions on the files, no-one will be able to access the seismic details. Backward Compatibility WAM - is not compatible with WAM 4.0. This means that indexes and saved queries will be lost when upgrading. 100 Installation Guide

107 A Configuring Linux Clusters This appendix describes how to configure the runtime environment for Paradigm 2011 applications to run parallel applications on Linux cluster systems. System administration skills are required to proceed with the system configuration and the installation of Epos software on Linux cluster. Prerequisites Networking must be configured to allow each cluster node to communicate with all the other nodes belonging to the cluster. Many tools are available to ease the process of installation and configuration of Linux clusters. Most of the tools are offered together with the cluster hardware by the hardware vendors. Usually, cluster configuration involves defining a so called "master node". Depending on the cluster size, there can be several master nodes on the cluster. The responsibility of the master node(s) is coordinating cluster operation by defining common user, network, and file system settings for all the cluster nodes. Thus, master nodes usually provide NIS (Yellow Pages) as well as file server services. We recommend configuring NIS services on the cluster to provide common definitions to all the cluster nodes. Cluster System Minimum Hardware Requirements Cluster systems are usually built using a commodity hardware, which dramatically reduces the price of such a configuration. However, most of the default hardware configurations assembled by the hardware vendors are not suitable for fully exploiting the power of Paradigm 2011 software. This section presents the recommended hardware configuration, which maintains the balance between fully exploiting cluster systems capabilities and the price of the final configuration. These recommendations help to achieve the optimal price-performance ratio when deploying Linux cluster systems, but note Installation Guide 101

108 Configuring Linux Clusters that hardware is rapidly evolving and the tables presented below represent recommended minimum requirements today. Hardware Components Head Nodes Compute Nodes Comments CPU 2x Intel 64 architecture or AMD AMD64 architecture processors 2x Intel 64 architecture or AMD AMD64 architecture processors The faster the better. Recent tests show Paradigm software is better optimized for Intel processors over AMD. RAM 8GB per node 8GB per node 64 bit hardware Hard Disk Speed 250GB minimum 7200 RPM minimum 250GB minimum 7200 RPM minimum Used by operating system and local cache for some migrations Network Card 1Gbit/sec Ethernet 1 Gbit/sec Ethernet To improve performance of migrations, we recommend that each node has 2x1 Gbit/sec Ethernet cards one of the networks to be used for massive parallel I/O traffic and the other network for the direct node-to-node communications. Peripherals CD-ROM, DVD-ROM, VGA graphics card Head node only Paradigm 2011 supports configurations with multiple CPUs per cluster node. The recommended amount of memory is 4GB of RAM per CPU core. For example, a single socket quadcore system should be configured with 16GB of RAM. Hard disks are used for operating system installation, Paradigm 2011 software installation and storing temporary files during applications runtime. Data is usually stored on a remote file server since the data amounts are measured in terabytes for large volumes. For these reasons, relatively small disks can be installed on each node. We recommend at least 250GB of disk space per node, which should be enough for deploying all the required software components and utilizing local cache for storing temporary files. Cluster configurations usually include two network cards per node. This design has the following advantages: One network card is used exclusively for inter-node communications, which makes it possible to configure a very efficient private network for clusters. The other network card is used for connecting each node with the outside network, which helps to avoid bottleneck when accessing data from remote file servers. Obviously, file servers must be accessible via a Gigabit network to provide the required bandwidth to all the cluster nodes. Data flow among the cluster nodes (required for the application internal communications) is completely separated from the data flow from the outside network (required for loading data from remote file servers). Internal and external networks can be tuned independently, depending on the problems encountered during the cluster software operation. According to internal benchmarks conducted by Paradigm, 1 Gbit/sec network cards are sufficient for both internal and external connections on clusters of up to 102 Installation Guide

109 Configuring Linux Clusters 64. Although sufficient applications will benefit from the use of InfiniBand even on small clusters with only 64 nodes. Hardware vendors typically provide so called "management consoles" to enable easy cluster configuration since cluster nodes are not usually equipped with keyboards and VGA cards. If management consoles are not the part of the cluster, each node must be equipped with the mentioned peripheral components to allow their configuration. Cluster System Configuration Cluster systems are composed of many separate computers running applications simultaneously. Applications expect a certain operating system configuration and runtime environment on all the cluster nodes. Paradigm 2011 uses its own proprietary message passing interface. Some of the procedures described below are common for all Linux systems. However, we describe the full set of these procedures to ensure that cluster systems are configured properly to successfully run parallel applications. Cluster Host Names If NIS is not available to the cluster nodes, then to allow access to cluster nodes using a host name instead of IP addresses, the /etc/hosts file must be altered to list all the nodes forming the cluster. A typical /etc/hosts file looks like this: localhost shark node node node node node node node1-7 Fig. A-1: Typical /etc/hosts file Host named shark is the hostname of the master node and others are the names of the slave nodes except localhost. Notice that this change has to be done on nodes from where all the parallel applications are to be launched. Remote Shell Configuration Epos runs with rsh or ssh (ssh is recommended because it allows a greater number of connections). The system administrator should configure these to run without a password. Epos uses its own proprietary message passing interface. Installation Guide 103

110 Configuring Linux Clusters A typical /etc/hosts.equiv file looks like this: shark node node node node node node node1-7 Root Login Configuration Fig. A-2: Typical /etc/hosts.equiv file The file /etc/securetty contains the list of terminals from which root can log in. This allows an easier administration of cluster nodes and is highly recommended. Simply add rsh, rlogin and rexec to the end of the file on every cluster node. Service Logins Configuration The directory /etc/pam.d contains configuration files that affect logins of the various services defined in the directory. Modify the /etc/pam.d/rsh, /etc/pam.d/rlogin and /etc/pam.d/rexec files on every cluster node by rearranging the lines to have the line with rhosts as the first line and the line with securetty as the second line. An example of these files after the modifications is shown below. auth required /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_nologin.so auth required /lib/security/pam_env.so account required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth System Limits Configuration Fig. A-3: Typical /etc/pam.d/rsh file Linux operating systems are shipped with default settings, which are not fully compatible with Paradigm 2011 software requirements. This section describes how to change system limits on the maximum number of open files, maximum number of file descriptors, and maximum process stack size. To increase the maximum number of open files and process stack size, edit the /etc/security/ limits.conf file by adding the lines shown below. * soft nofile * hard nofile * soft stack 8192 * hard stack The asterisk means that the setting is relevant for all the operating system users. For more information on how to set per-user settings, read comments from the /etc/security/limits.conf file. Notice that the values are given in kilobytes. 104 Installation Guide

111 Configuring Linux Clusters To make these settings activate on user login, the following line must be added to the /etc/pam.d/ login file: session required /lib/security/pam_limits.so The system file descriptor limit is set in /proc/sys/fs/file-max file. The following command, run from the root account, will increase the limit to KB: # echo > /proc/sys/fs/file-max Some of the changes described in this section will not activate without the proper user account configuration. Make sure you read and follow the instructions in User Configuration on page 106 to fully complete the configuration of both system and user settings. Software Installation Operating System Software Components It is a common practice to omit the installation of different operating system software components from cluster slave nodes. X Windows can serve as an example for such a software component. Typical cluster configuration implies that monitors are connected to a master node only, making it unnecessary to install X Windows components on slave nodes. Most of Paradigm 2011 software (including parallel applications) depends on X Windows libraries for providing the graphical user interface. As parallel applications are simultaneously launched on cluster nodes, the latter require having X Windows components installed even if there is no usage of these components directly during the runtime of a parallel application. Parallel applications fail on startup if X Windows components are not installed on the target cluster nodes. Red Hat Linux distribution ships with an implementation of X Windows. This software component must be installed on all cluster nodes configured to run Paradigm 2011 software. Paradigm 2011 Software Paradigm 2011 software must be installed in a common location for all the cluster nodes (e.g.,/usr/software directory on all the nodes). A commonly accepted way to provide such a configuration is having the software installed on the master node (or an external software server machine), while the cluster nodes access the software via NFS mounted directories. Whereas it is possible to duplicate Paradigm 2011 software on all cluster nodes locally, it is not recommended since the process is rather time consuming and the installation is difficult to maintain because of the hardships when applying software patches. The software duplication requirement may emerge because of the limitations of Network File System implementation. Launching an application on all cluster nodes involves simultaneous requests to all the nodes to load and run the application. If Paradigm 2011 software installation is NFS mounted on a remote drive, the NFS server gets overloaded by a large number of requests and the loading of the application may fail on some nodes. The problem described depends on many factors including the network bandwidth, Network File System configuration, and files server capabilities. Different combinations of the above features will cause different behavior, which is difficult to predict. It should be stressed that duplicating the software on all cluster nodes must be the last resort for solving NFS problems because of the overhead related to the maintenance of such a configuration. Installation Guide 105

112 Configuring Linux Clusters File System Configuration Most Paradigm 2011 applications currently perform data access via the file system. Remote file systems must be NFS mounted to all the cluster nodes. Users must ensure that the access paths to the data are the same on all the cluster nodes. All direct-access directories have to be NFS mounted on all the cluster nodes since all parallel processes on all the nodes access them. Good performance can be achieved when data directories are NFS mounted directly on the file server. Moreover, using separate network cards is recommended for the outside data access to separate internode messages passing from external data access. The above-mentioned configuration requires hooking up all the cluster nodes to the outside network directly. Whereas system administrators may consider this recommendation as a problematic one on large clusters, the performance benefits are significant to justify the recommended configuration. User Configuration We recommend having separate users dedicated to running cluster applications. This section describes the way to correctly configure the users runtime environment to allow Paradigm 2011 applications to function properly. This step finalizes the installation and configuration of cluster systems to operate Paradigm 2011 parallel software. Depending on the size of the job to be executed on Linux cluster, different configuration steps must be taken to configure the proper environment for Paradigm 2011 parallel applications. To provide support for Linux clusters larger than 128 nodes, the system can be configured to use Secure Shell (SSH), which can be deployed on up to a thousand nodes. The sections which follow provide descriptions for configuring the user environment for both RSH and SSH usage. Users must switch the environment appropriately depending on the size of the job to be executed on Linux cluster. Configuring User Environment for RSH Usage Paradigm 2011 parallel applications must have a similar environment on all the cluster nodes to be able to function properly. To correctly initialize the runtime environment, the following command must be executed from a user s account for every architecture used to run Paradigm 2011 migrations. As the generated files contain full path references, the environment initialization must be redone if the software installation path changes or major software patches altering binary files location are installed. $ <Applications>/bin/pg4 -cmd="tcsh -f" The files named _env and _env.<architecture> are created in that user s home directory as the result of this command. This environment will be used by the migration startup script to correctly initialize itself during the startup procedure. The user.cshrc file must not contain references to the generated environment initialization files since the settings in those files may conflict with the requirements of other applications run by the user. We encourage editing the _env.<architecture> file to remove settings that are not relevant to all the cluster nodes. These setting may include the following: PWD - Current working directory HOSTNAME - The name of the current host (this can appear both in capital and lower case) If the _env_user file exists in the user home directory it will be used to set user specific environment variables to be passed to the migration applications. Note that users cannot override settings in _env.<architecture> file by redefining them in _env_user file. 106 Installation Guide

113 Configuring Linux Clusters The final configuration step is to allow a user to use RSH on every cluster node without supplying the password. A file named ".rhosts" must be created in the user s home directory. Notice the "." in the beginning of the file name this means that the file will be hidden. The file must contain the names of all cluster nodes open for remote login. Using the "+" character to open access for all hosts on the network may not work and is not recommended for security reasons. shark <username> node1-1 <username> node1-2 <username> node1-3 <username> node1-4 <username> node1-5 <username> node1-6 <username> node1-7 <username> Fig. A-4: Typical ".rhosts" user file Configuring User Environment for SSH Usage Paradigm 2011 parallel applications must have a similar environment on all the cluster nodes to be able to function properly. The final configuration step is to configure SSH in a way allowing a user to login to every cluster node without supplying the password. The first SSH configuration step is to create the authentication key for a user by executing the following command. $ ssh-keygen -t rsa Fig. A-5: Creating the authentication key The above command queries the user and generates the public/private key pair. Make sure to accept the defaults and enter an empty pass phrase. The private and public keys will be saved in the following files respectively: ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. The user needs to authorize access by copying the public key into ~/.ssh/authorized_keys file. All keys listed in that file are allowed for the user access. If the remote machine does not share a common file system with the host where the SSH configuration is performed (e.g., user home directory is not NFS mounted among all cluster nodes), the ~/.ssh/authorized_keys file must be copied over to all machines the current user will connect. SSH requires that ~/.ssh/authorized_keys file has its permissions set so that it s not group accessible. The following figure demonstrates the command required to be run on each ~/.ssh/ authorized_keys file. $ chmod go-rwx ~/.ssh/authorized_keys Fig. A-6: Setting authorization file permissions Installation Guide 107

114 Configuring Linux Clusters In order to avoid typing the pass phase each time SSH is invoked, an SSH-agent needs to be created by running the following commands: $ ssh-agent $SHELL $ ssh-add Fig. A-7: Creating the SSH agent The user needs to logout before the settings take effect and add the cluster hosts to the list of known hosts in ~/.ssh/known_hosts file by invoking SSH to those hosts and agreeing to accept the connection once. Subsequent SSH invocations will not request a password. 108 Installation Guide

115 Configuring the Network on Linux B This appendix provides basic information on how to configure host name resolution on Linux operating systems. Overview Paradigm 2011 software requires proper network configuration, since it often operates in client-server mode. One of the basic requirements for a properly configured network is to have a correct resolution of the machine host name to the right IP address. Many operating systems as well as Paradigm 2011 services depend on this requirement to be fulfilled. Proper network configuration is especially critical for mobile laptops, especially when plugging laptops into different networks. It is less of an issue for a stationary workstation or server machines. Usually, system administrators assign static IP addresses to these machines and correctly resolve them in the network using standard protocols like NIS or DNS. Various operating systems take care of host name resolution differently. For example, most Linux operating systems require special configuration for correct mapping of host names to current IP addresses, whereas this is not an issue for MS Windows operating systems. Note We recommend that you consult your system administrator before making network configuration related changes on user workstations or laptops. Verifying Network Configuration Network configuration verification can be done by a non-experienced user to determine whether Paradigm software would encounter any problems related to improper network configuration. There are several steps in verifying network configuration that need to be followed: 1. Determine all machines on the network that are involved in running Paradigm software. 2. Verify that the machine running Paradigm client software correctly resolves network information of the machine running Paradigm services. 3. Verify that the machine running Paradigm services correctly resolves network information of the machine running Paradigm client software. More than one host on the network can be involved in running Paradigm client-server software. The client side is comprised of applications launched by end users including GUI, migrations, command line utilities, etc. The server side is comprised of Paradigm Name Service (PNS) and various services launched transparently to end users on machines running PNS. Installation Guide 109

116 Configuring the Network on Linux After determining the hosts involved in running Paradigm software, users should verify network configuration on each host by running the ping command. $ ping chico PING chico ( ) 56(84) bytes of data. 64 bytes from chico ( ): icmp_seq=0 ttl=64 time=0.055 ms 64 bytes from chico ( ): icmp_seq=1 ttl=64 time=0.026 ms --- chico ping statistics packets transmitted, 2 received, 0% packet loss, time 1013ms rtt min/avg/max/mdev = 0.026/0.040/0.055/0.015 ms, pipe 2 $ ping pnssrv PING pnssrv ( ) 56(84) bytes of data. 64 bytes from pnssrv ( ): icmp_seq=0 ttl=64 time=0.270 ms 64 bytes from pnssrv ( ): icmp_seq=1 ttl=64 time=0.134 ms --- pnssrv ping statistics packets transmitted, 2 received, 0% packet loss, time 1007ms rtt min/avg/max/mdev = 0.134/0.202/0.270/0.068 ms, pipe 2 Fig. B-1: Pinging Client and Server Hosts The ping command resolves names of the hosts in question in a way similar to Paradigm software by returning IP addresses. Users need to verify that the IP address is correct and contains the same value when run on either client or server machines. In the example above, the host name chico should resolve into IP address when run on either chico or pnssrv machines. This procedure alone does not guarantee that the user network is properly configured. However, it provides a starting point for troubleshooting Paradigm software basic network configuration requirements. More advanced configuration problems should be discussed with your system administrator. Resolving Static IP Address If users choose to assign static IP addresses to a workstation or laptop, they have to make sure the host name is correctly resolved by adding an entry in the /etc/hosts file. Fig. B-2 demonstrates how a machine named chico is assigned a static IP address. # Do not remove the following line, or various programs # that require network functionality will fail localhost.localdomain localhost chico Fig. B-2: Assigning Static IP Address in /etc/hosts It should be mentioned that whenever the machine network configuration is changed, users need to update the /etc/hosts file appropriately. Rebooting the operating system is required after changing host name or IP configuration. This configuration alone is only sufficient for local operation mode. If users wish to utilize Paradigm 2011 services located elsewhere on the network, chico host name has to be correctly resolved from the rest of the network as well. We recommend that your system administrator performs 110 Installation Guide

117 Configuring the Network on Linux this task. You can verify the network configuration as described in Verifying Network Configuration on page 109. Resolving Dynamic IP Address (DHCP) If users choose to assign dynamic IP addresses to workstations or laptops using (Dynamic Host Configuration Protocol) DHCP, they have to make sure the host name is correctly resolved every time the machine is reassigned an IP address. Usually, an IP is reassigned every time after rebooting the machine. To resolve host name information in accordance to a dynamic IP address obtained from the DHCP server, user machine network configuration should contain a special option for this purpose. Various Linux distributions may need to be configured in a different manner to use the mentioned DHCP feature. Red Hat Enterprise Linux distribution requires updating the /etc/sysconfig/network file to contain DHCP_HOSTNAME=<desired_hostname> line. Fig. B-3 presents a typical /etc/sysconfig/ network file contents for Red Hat Enterprise Linux. NETWORKING=yes HOSTNAME=chico DHCP_HOSTNAME=chico Fig. B-3: Typical /etc/sysconfig/network on Red Hat Linux Other Linux distributions may have different configuration requirements compared to what is presented above. It is mandatory to reboot computers after changing network configuration. Host Name Resolution Order To finalize host name configuration resolution on user workstations or laptops, users need to make sure that host name resolution order is correct. The order is defined in the /etc/nsswitch.conf file in the line starting with hosts: string. In case of static IP address assignment and resolution from the /etc/hosts file, users need to make sure that "files" is specified at the first place in the list of host name resolution sources. This would make the host name resolved from the /etc/hosts file, bypassing network services. In case of dynamic IP address assignment (DHCP), users need to make sure that the source of network hostname resolution is present in the /etc/nsswitch.conf file. The exact pattern of the file may vary depending on the site network configuration. Fig. B-4 depicts the most commonly encountered settings. hosts:files nisplus dns Fig. B-4: Host name resolution order in /etc/nsswitch.conf Installation Guide 111

118 Configuring the Network on Linux Case Study - Laptop Network Configuration Using DHCP This section contains recommendations on how to configure mobile laptops to make the transition between stand-alone and networked states painless for laptop users running Paradigm software. If a laptop network configuration uses DHCP to obtain an IP address, the transition from networked state to stand-alone should be as easy as unplugging the network cable and rebooting the machine. Laptops should be configured to use DHCP as previously described, with several changes to allow straightforward transition between stand-alone and networked operation modes without user intervention. The changes include editing the /etc/hosts and /etc/nsswitch.conf files. hosts:nisplus dns files Fig. B-5: Host Name Resolution Order in /etc/nsswitch.conf The idea behind these changes is to allow seamless resolution of laptop host name from /etc/hosts when not connected to the network and from DHCP when connected to the network. This is achieved by specifying "files" in the end of the host name resolution sources list. The configuration causes the operating system to first try to resolve the machine host name from the network sources. If the machine is connected to the network and configured properly, the host name resolution will be obtained from the network. # Do not remove the following line, or various programs # that require network functionality will fail localhost.localdomain localhost chico Fig. B-6: Assigning static loop back IP address in /etc/hosts When a machine is disconnected from the network, the external network services cannot be reached and the host name is resolved from the /etc/hosts file, resulting in a loop back address which is the only valid address when a machine is disconnected from the network. While the configuration presented above allows correct operation of host name resolution when switching stand-alone and networked operation modes, there may be some other operating system components that require additional configuration. These system components may include various network services mostly related to the way users access remote file systems from their mobile laptops. Network File System (NFS) and Auto Mounter Daemon (AMD) are examples of such network services. When laptops are not connected to the network, all network services depending on external resources are unavailable. Users may experience difficulties using operating system services that depend on network resources in stand-alone operation mode. 112 Installation Guide

119 C Multipipe Usage This appendix describes multipipe usage for running and displaying certain Epos 4.1 applications in multiple graphics device environments. Overview Epos 4.1 supports running and displaying in multiple graphics device environments, commonly referred to as Visionariums. An MPP license (for example VoxelGeo_XV_MPP) is required for more than 2 graphics devices (pipes). Remote display is not supported. Xinerama is used on all platforms to stretch the workspace across multiple graphics boards. Projectors will play a very important role. You will need the expertise of the vendor to know what these can handle for resolution and refresh rate. They should also set up the edge blending, if any. Systems running Linux operating systems are capable of driving visualization environments. This includes environments with three projection devices or more. These configurations require multiple graphics boards. In general, Paradigm supports single systems with multiple graphics boards. Systems with nvidia Graphics nvidia supports synchronized stereo displays across three or more display devices with several of their highest performance graphics boards. Two or more graphics boards are required for this type of configuration. At the time of the writing of this document, this includes the Quadro FX 4800 and the Quadro FX 5800 boards, and the NVIDIA Quadro 4000, 5000 and 6000 boards. nvidia also produces the Quadro Plex which can house multiple graphics boards and be connected to a system's PCIe express slot. Systems from several vendors support two nvidia graphics boards. Paradigm requires the two boards to be the same type and that they occupy PCIe slots of the same bandwidth. An additional PCI board, named a G-Sync board, is required to synchronize and frame lock the stereo signal between the two graphics boards. Graphics driver requirements and configuration details are provided by nvidia. Installation Guide 113

120 Multipipe Usage Configuration The nvidia driver README file contains detailed description and configuration information. The interactive tool /sbin/nvidia-settings provides a convenient interface for performing most configuration tasks. If you are considering a system to drive a visionarium, contact your Paradigm sales office for updated information. 114 Installation Guide

121 D Windows Installation The Paradigm 2011 release introduced support for the Epos 4.1 Infrastructure and Interpretation Applications Suite on Microsoft Windows 7 operating system alongside the existing Red Hat Enterprise Linux operating system support. This appendix describes the fundamental procedures for Epos 4.1 software installation, configuration and data management to be performed by the end users when Windows is part of their software runtime environment. Readers are assumed to have knowledge on how to configure and run Epos Services and Applications. Full information can be found in the Paradigm 2011 Online Help. Installation Two installation packages are delivered, including Epos Services and Epos Application software. The Paradigm EUI (Easy User Installer) tool is used to deploy the software on both Linux and Windows platforms, such that the installation processes are very similar, except for the details described in this section. Windows requires local administrative permissions for installing any software, so the OS user performing the installation must possess local administrator rights. The installation process is commenced using pgsetup.cmd startup script, which automatically elevates its privileges to administrator. Depending on the operating system configuration, users may need to answer a User Account Control security dialog box in order to proceed with the installation process. The dialog box allows for selecting another user if the current one does not possess local administrator rights. Installation Guide 115

122 Windows Installation The default, the installation path for Paradigm software is C:\Program Files\Paradigm directory followed by the software release and package names. For example, Epos 4.1 Services are installed in C:\Program Files\Paradigm\Paradigm \Services directory. It is recommended to keep the default installation paths as presented by EUI. The software can only be installed on a local drive. The installation directory is read-only and it cannot be used for storing software configuration information. The User Information dialog box is displayed in the initial stage of the installation, prompting you to select between a shared (Anyone who uses this computer) or personal (Only for me) installation type. 116 Installation Guide

123 Windows Installation The selection determines the location of the software configuration and program shortcuts created during the installation process. The program shortcuts are created differently depending on whether the installation is shared or personal. The location of shortcuts determines whether all local users have access to Paradigm software from the Start Menu, or just the user performing the installation. Epos Services The Windows setup does not allow for selecting different EposAdm (software installer) and EposDB (database owner) OS users. The installer OS user is assumed to be both EposAdm and EposDB. The initial segment configuration procedure allows for selecting segment description, PNS host name and license file. Other settings can be configured from the Epos Services Control Panel after the installation is completed. Installation Guide 117

124 Windows Installation The segment data path is automatically selected depending on the shared or personal installation type, and it cannot be changed: %ProgramData%/Paradigm/PNS41/Segment %LOCALAPPDATA%/Paradigm/PNS41/Segment The next stage is to configure the startup of PNS, which runs as a Windows Service. Services may run from the default Local System account or any other user account provided the appropriate user credentials. The following dialog box appears when configuring the PNS startup on Windows. The Local System account is the default selection, but it is only appropriate when data to be accessed by Epos Services resides solely on local drives. The problem is that Windows Services from Local System account are running with elevated permissions in a special environment, which prevents them from accessing mapped drives or shared network locations. Alternatively, PNS can be started from the account of the OS user running the installation procedure. If this option is selected in the Log on Service as dialog box, the user password must be entered twice 118 Installation Guide

125 Windows Installation without errors. The user password is not saved anywhere by Paradigm software, so it must be reentered every time the <Services>/bin/pns_install_service.cmd script is run. The installation creates an Epos Services Control Panel shortcut in the Start\All Programs\Paradigm\<Release> menu folder. Epos Applications The initial configuration procedure allows for selecting an Epos license, Web browser and WAM link. Other settings can be configured from the Epos Application Control Panel after the installation is completed. The location of the Epos configuration directory is automatically selected depending on the shared or personal installation type. These settings are not displayed during the installation and cannot be changed. %ProgramData%/Paradigm/Epos41/config %LOCALAPPDATA%/Paradigm/Epos41/config Like the PNS segment path, the Epos configuration directory location cannot be changed. If different instances of the Epos Application package are installed on the same machine, they will all use the same configuration area. Unlike PNS, users can simultaneously run Epos applications from different installation directories. The installation creates the following shortcuts in the Start\All Programs\Paradigm\<Release> menu folder: Epos Applications Control Panel Paradigm Product Manager Paradigm Session Manager Installation Guide 119

126 Windows Installation Unattended Install EUI provides support for unattended installation mode on Linux and Windows platforms. Users need to prepare input files for the installation and run it in console mode with special --console and -- unattended-input=file command line arguments. The input file name must be specified using a full path. Users must go through the console installation procedure once to prepare the unattended installation input file. This text file should contain user responses terminated by the new line. An empty line means the default response. Epos Services The Epos Services installation on Windows may require specifying user name and password for PNS startup procedure if the service is not configured to run from the Local System account. The password has to appear in open text inside the unattended input file. Users should take proper care of protecting such files so as not to compromise their passwords. The following figure shows an example of the unattended input file contents for Epos Services installation on Windows. Note that the PNS installation sequence is different when the segment is already created. Epos Applications The following figure shows an example of the unattended input file contents for Epos Applications installation on Windows. All options are default except the address of Epos software license server. 120 Installation Guide

127 Windows Installation Uninstall Epos service and application packages can be uninstalled using standard Windows procedure from the Control Panel\Programs and Features dialog box. Windows prevents deletion of files that are currently used by running processes. EUI uninstall procedure tries to stop running Epos services. Users must close all running Epos applications before uninstalling the client software. The uninstall procedure only deletes program files and not configuration data. This allows for subsequent Epos installations to reuse the existing configuration. Users must explicitly delete configuration files to recreate them during the next installation. Individual software patches can be uninstalled using Uninstall utility in Epos Services or Applications Control Panels. The utility can be run from the OS user account that performed the initial software installation and it automatically tries to elevate to administrative privileges required to successfully complete the uninstall procedure. Configuration Epos Services and Applications software must be configured before it can be used. The configuration tools are similar to what is used on Linux, accessible from Epos Services and Epos Applications control panels. Some Linux specific tools and utilities are not part of the Windows software suite. Multiple Users vs. Single User Paradigm 2011Windows software can only be installed on local drives. The configuration data is also stored locally to the installation machine. Due to this design limitation, there can only be one PNS-persegment on the Windows platform. Epos infrastructure design does not prevent Epos applications from accessing data registered on remote PNS, allowing the creation of multi-user configurations on Windows. In this scenario, multiuser is depicted by more than one user sharing the same data. The data may be local to some users and remote to others operating the software. Installation Guide 121

128 Windows Installation The connection to a remote PNS host may be restricted if users purchase so called single-user licenses. If users select such a license, the Epos Applications software forcefully resets the PNS host setting to the local host name. This effectively limits the scope of data access in single-user mode of operation. Some Windows 7 operating system workstation configurations allow multiple users to be logged on the same physical host at the same time. However, Windows 7 workstations do not allow running more than one session simultaneously, even if users are connected via Remote Desktop. Multiple Remote Desktop connections are only supported for Windows Server operating systems. Paradigm 2011 software does not support running Epos OpenGL applications over Remote Desktop connections. Applications not using OpenGL can be run in Remote Desktop sessions, so system administrators may log on remotely to Windows Server or Workstation and configure locally installed Epos Services and Applications software settings. Similar limitation also exists on Linux when it comes to supporting Epos OpenGL applications over remote X11 connections. Epos Services Epos Services configuration includes mandatory Epos User creation and some other optional settings. Users may choose to configure advanced data path and security settings for multi-user configurations. PNS on Windows supports a wide range of configuration scenarios, covering almost all options available on the Linux platform. Epos Users At least one Epos User must be created using Epos Services Control Panel before starting to use Epos Applications software. The creation of Epos Users is performed in Segment Configuration > Configure Segment Security EPOS Users Settings dialog box. The list of Windows OS users and groups available for selection is not currently obtained from the domain. Only local groups and users that are defined as members of a local group are visible to PNS. Windows OS users working with Epos must be members of a local group on PNS host to enable Epos User creation. Data Paths It is recommended to predefine Epos data locations using Segment Configuration > Configure Segment Settings Data Path Settings dialog box. This mode of operation ensures controlled Epos data locations together with more convenient application usage when it comes to data path selection dialogs. If PNS is configured in this so called managed mode, users are prompted with the predefined list of paths instead of directory browse dialog box. Epos Infrastructure is client-server architecture that allows remote data access over the network for most of the data types. Some data types must be accessed by applications directly from file systems. In both cases, Epos data can reside on local or remote file systems. Local file systems are accessed via drive letter, while remote file systems should be accessed using UNC path notation. In both cases, Epos requires usage of forward slashes and does not support spaces: D:/EposData/Seismic //server/share/eposdata/seismic Windows allows for mapping remote file systems to drive letters using the Map Network Drive dialog box. Such paths cannot be accessed by PNS running as privileged Windows Service process. Epos Services started by PNS cannot access mapped drives as well, which means that UNC paths must be used for data accessed by Epos Services. 122 Installation Guide

129 Windows Installation If PNS is configured to run from Local System account, Epos Services can only access data residing on local drives. This limitation is imposed by Windows operating system not allowing remote share access from this special local account. New Segment The location of the PNS segment on Windows is predefined and can only point to directories residing on local drives. The functionality of the new segment creation can only be useful if users want to recreate existing segment from scratch without reinstalling Epos Services package. PNS on Windows will not be able to make use of segment directories created in arbitrary locations. Users will be forced to choose the appropriate segment location depending on shared or personal installation types: %ProgramData%/Paradigm/PNS41/Segment %LOCALAPPDATA%/Paradigm/PNS41/Segment Epos Applications Epos Applications configuration includes mandatory PNS Group and License definitions together with some other optional settings. Some utilities require administrator privileges to run. Runtime Variables The utility for adjusting Runtime Variables may need to be run with administrator privileges for shared installation types because the configuration files are otherwise not editable. Users must have a valid PRDM_GEO_LICENSE_FILE definition for the software to run properly. Users can reference Windows environment variables by prefixing them with dollar sign as depicted in the following figure. For example, %ProgramFiles% environment variable is referenced as $ProgramFiles in the utility. Installation Guide 123

130 Windows Installation User preferences are created under %APPDATA%/.PG_PREF4 directory, which usually points to a peruser location on a local drive. So the user preferences will not be shared by default if the same user works on multiple machines. Heterogeneous Environments Paradigm 2011 applications can work with remote PNS in heterogeneous environments requiring special configuration as discussed in this section. The configuration is mostly about properly setting up data paths and their permissions so that access from Windows and Linux platforms works in an effective and secure manner. Remote File Access Paradigm 2011 software only supports CIFS protocol for remote file access on Windows. The techniques for accessing remote data differ depending on the nature of the file server operating systems. Windows Data partitions or individual directories residing on Windows servers or workstations must be shared to enable remote access. Such shares can be then accessed from Windows using //server/share notation. Linux Data directories residing on Linux servers or workstations must be exported using Samba, which is the standard Windows interoperability suite of programs for Linux. Samba allows for exporting data via CIFS protocol required to access remote data on Windows using the usual //server/share notation. 124 Installation Guide

131 Windows Installation Network Appliances The most effective configuration for remote data access on Windows can be established using dedicated network appliances providing file services via CIFS protocol. Such devices usually run operating systems optimized for serving files, offering advanced data management facilities high-availability, snapshot, mirroring, etc. Data partitions exported from such devices can be accessed using the usual //server/share notation. NFS Data partitions exported via NFS protocol can still be accessed from Windows in one of the following ways: Using Microsoft or 3rd party NFS Client Windows software Using Samba server to re-export the data via CIFS The first technique is not supported by Paradigm 2011 software. The second configuration is supported, but it usually delivers inferior performance due to overhead incurred by Samba serving as a middle-man to re-export the data via CIFS. Data Security Different types of security styles usually supported by the storage systems include UNIX, NTFS or Mixed. UNIX security style is applicable if the data is only to be accessed from Linux operating systems. NTFS security style is applicable if the data is only to be accessed from Windows operating systems. Mixed security style is not supported by Paradigm 2011software. The implementation of security depends on the file server used to manage the data. It is usually implemented with the following guidelines. UNIX The user's UID and GID, and the UNIX-style permission bits of the file or directory determine user access. The storage system uses the same method for determining access for both NFS and CIFS requests. NTFS For CIFS requests, Windows NT permissions determine user access. For NFS requests, the storage system generates and stores a set of UNIX-style permissions bits that are at least as restrictive as the Windows NT permissions. The storage system grants NFS access only if the UNIX-style permission bits allow the user access. Mixed Some files have the UNIX security style and some have the NTFS security style. A file's security style depends on whether the permission was last set from CIFS or NFS. Data Paths A sample configuration of PNS server running on Windows operating system and using remote file server for storing data is presented in the following sections. File Server The file server used for remote data storage is NetApps FAS2040 running Data ONTAP operating system. The server is configured with a QTree as follows: unixshare using UNIX security style Installation Guide 125

132 Windows Installation The QTree is exported via CIFS. The export is accessible from Windows machines by \\files11\unixshare path and from Linux machines by /home/gtdata/files11-unix path. User names are defined in the Windows Active directory for Windows machines and NIS server for Linux machines. The file server performs automatic user name mapping from Windows to Linux and vice-versa. It is possible to define a special mapping when user names do not match. The file server is configured to use SMB2 protocol for CIFS exports, which is more effective for data access compared to its previous implementations. The following SMB2 options are enabled on the file server: files11> options cifs.smb2 cifs.smb2.client.enable on cifs.smb2.durable_handle.enable on cifs.smb2.durable_handle.timeout 16m cifs.smb2.enable on cifs.smb2.signing.required off File Client Windows 7 is pre-configured with suboptimal settings for accessing remote files over CIFS shares. Microsoft published a document describing optimizations that may be applied on the operating system settings to improve performance. The document is available online at The following options are set on PNS host to improve the remote file system access performance. All options are applied under HKLM\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters key in the Windows Registry. The same options are suitable for Windows 7 machines running Paradigm client software to improve application performance for directly accessed data. "EnablePlainTextPassword"=dword: "EnableSecuritySignature"=dword: "RequireSecuritySignature"=dword: "DisableBandwidthThrottling"=dword: "EnableWsd"=dword: "FileInfoCacheEntriesMax"=dword: ""DirectoryCacheEntriesMax"=dword: "FileNotFoundCacheEntriesMax"=dword: UNIX The following presents the contents of the /home/gtdata/files11-unix directory from the Linux machine. The backup and tmp directories have 1777 permissions not to allow regular users to delete other users data. They will be used for storing Epos backup data and temporary files created by Epos Data Management utilities. 126 Installation Guide

133 Windows Installation files11-unix]# echo $cwd /home/gtdata/files11-unix files11-unix]# ls -l total 12 drwxrwxrwt 2 root root 4096 Sep 1 14:27 backup drwxrwxrwt 3 root root 4096 Sep 1 19:55 tmp drwxr-xr-x 7 root root 4096 Sep 1 15:40 vm-tlv-wpns41-1 The following presents the contents of the \\files11\unixshare directory from the Windows machine. Note that the vm-tlv-wpns41-1 Properties dialog box is missing the Security tab. This is because the security of this directory is managed by the file server using UNIX semantics. The /home/gtdata/files11-unix/vm-tlv-wpns41-1 directory will be used for storing Epos Data registered on Windows PNS machine. It is configured in a standard manner with the Epos database directory belonging to the EposDB user called eposuser and seismic data directories opened to UNIX group access with set-group-id bit to inherit security settings. The rest is open to all users with 1777 permissions not to allow regular users to delete others users data. Installation Guide 127

134 Windows Installation vm-tlv-wpns41-1]# echo $cwd /home/gtdata/files11-unix/vm-tlv-wpns41-1 vm-tlv-wpns41-1]# ls -l total 20 drwxrwxrwt 2 root root 4096 Sep 2 12:03 application drwx eposuser eposuser 4096 Sep 2 12:02 database drwxrwsr-x 2 root develop 4096 Sep 2 12:02 seismic_develop drwxrwsr-x 2 root ninjas 4096 Sep 1 13:55 seismic_ninjas drwxrwxrwt 2 root root 4096 Sep 1 15:40 seismic_scratch PNS running on vm-tlv-wpns41-1 host is configured with the following data path settings. Note that all, with the exception of the database paths, are configured to have access from both Windows and Linux platforms. The database path is only accessed by PNS and Epos Services from vm-tlv-wpns41-1 Windows host. Data Management The Paradigm 2011 software release on Windows includes the comprehensive data management suite available from the Epos Database tab of the Epos Applications Control Panel. The suite covers almost all functionality available on Linux platform. Data Management tools can only work with PNS running on the same platform. This constraint is dictated by the differences between Linux and Windows environments, especially when it comes to accessing data residing on remote file servers. The existing Epos databases can be copied to Windows environment using the Backup and Restore utility. If cross platform data transfer is required, the existing Epos data should be backed up on one platform using the Epos Data Backup utility, and restored on another, using the Epos Data Restore utility. Maximum Path Length Limitation The maximum length of a path supported by the Windows operating system does not exceed 260 characters with the exception of paths specified using a special format. The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of characters. This type of path is composed of components separated by backslashes, each up to the length of 255 characters. Specifying an extended-length path is possible using the \\?\ prefix, for example \\?\C:\Very Long Path. 128 Installation Guide

135 Windows Installation The Paradigm 2011software does not support extended-length path format, which introduces limitation of the path length usable by Epos 4.1 applications and data management utilities. Users should set up Epos 4.1 data repositories trying to minimize the length of the repository root directory so that maximum path length limit is not reached. Unsupported File Names Epos 4.0 data backup created on Linux may contain VoxelGeo or Well data not suitable for use on Windows due to file name limitations introduced by Windows NTFS file system. Since VoxelGeo and Well data file names are sometimes created based on user input, they may contain characters unsupported on Windows. This problem does not currently have a workaround. If such file names are encountered by Epos 4.1 Data Restore utility, they are simply skipped and errors are reported at the end of the procedure. Third-Party Data Access The Paradigm 2011 release does not support accessing OpenWorks and GeoFrame data on Windows using Epos Third-Party Services. However, Paradigm 2011applications can be configured to access third-party repositories registered on Linux PNS host. Epos 4.1 requires SSH client available on machines running applications if access to third-party data is necessary. Microsoft Windows operating system does not include SSH client software, thus thirdparty SSH client software suites must be used for OpenWorks and GeoFrame data access from Windows. The following topics present the installation and configuration examples of Cygwin based OpenSSH open-source SSH client software for Windows. Users may choose to install and configure other SSH client solutions suitable for cross-platform SSH access. Installation OpenSSH for Windows can be downloaded from site. It contains both SSH server and client functionality, but only SSH client is required by Paradigm 2011 software. The installation procedure needs to be run from an account with local administrative privileges. Default installation options must be selected so that the package is installed in C:\Program Files (x86)\openssh directory. Configuration The configuration procedure should be started from the Windows Command Prompt window running with administrator privileges. Group and password files should be created using mkgroup.exe and mkpasswd.exe utilities supplied with OpenSSH installation. The utilities support local and domain users depending on command line options specified. C:\Program Files (x86)\openssh\bin>set CYGWIN=ntea C:\Program Files (x86)\openssh\bin>mkgroup.exe -l >>..\etc\groups C:\Program Files (x86)\openssh\bin>mkpasswd.exe -d -u eposuser >>..\etc\passwd The next stage is to create an authorized SSH private-public key pair for the current user, allowing the user to execute SSH commands without specifying passwords. Before the keys are created, users must edit the HKLM\SOFTWARE\Wow6432Node\Cygnus Solutions\Cygwin\mounts v2\/home registry key and fix the value of the /home directory mapping for OpenSSH. Windows 7 operating system stores user home directories in C:\Users location by default. Installation Guide 129

136 Windows Installation The following commands should now be executed from Windows Command Prompt window running with regular user privileges. Empty passphrase must be specified when prompted. C:\Program Files (x86)\openssh\bin>set CYGWIN=ntea C:\Program Files (x86)\openssh\bin>ssh-keygen.exe -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/eposuser/.ssh/id_rsa): Created directory '/home/eposuser/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/eposuser/.ssh/id_rsa. Your public key has been saved in /home/eposuser/.ssh/id_rsa.pub. The key fingerprint is: e7:bd:6d:b3:d4:35:95:74:b4:b7:90:fb:a5:92:c8:99 Note the CYGWIN=ntea setting before running OpenSSH commands. This is required so that UNIX permissions are simulated by Cygwin when accessing the /home/<username>/.ssh directory. It is recommended to add this setting to user environment, or SSH client will not work without specifying the user password. The final stage includes the authorization of the generated SSH public key in the user home directory visible from Linux PNS host. The contents of C:\Users\<username>\.ssh\id_rsa.pub file should be appended to.ssh/authorized_keys file in the user Linux home directory. The resulting configuration should be tested by executing the following commands from Windows Command Prompt window running with regular user privileges. C:\Program Files (x86)\openssh\bin>set CYGWIN=ntea C:\Program Files (x86)\openssh\bin>ssh vm-tlv-pns41-1 -l eposuser hostname The authenticity of host 'vm-tlv-pns41-1 ( )' can't be established. RSA key fingerprint is fb:59:d0:15:31:18:fb:5c:9d:76:4e:64:85:74:5f:f9. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'vm-tlv-pns41-1, ' (RSA) to the list of known hosts. vm-tlv-pns41-1 C:\Program Files (x86)\openssh\bin>ssh vm-tlv-pns41-1 -l eposuser hostname vm-tlv-pns41-1 Note that first invocation of SSH client asks to verify the authenticity of the specified Linux PNS host. Once the host is verified, subsequent SSH client invocations do not prompt the user. The specified command will be executed on Linux host without requiring the user to enter password. Shared Home Directories Cygwin may be configured to access Linux home directory of the current user via CIFS share. Users must edit HKLM\SOFTWARE\Wow6432Node\Cygnus Solutions\Cygwin\mounts v2\/home registry key by setting its value to a shared path, not including the user name. When running SSH client, the CYGWIN=ntea setting is not required for shares managed using UNIX security style. 130 Installation Guide