Changes between Version 1 and Version 2 of Installation_and_Configuration


Ignore:
Timestamp:
11/11/11 11:36:32 (10 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Installation_and_Configuration

    v1 v2  
     1[[PageOutline]] 
     2 
    13= Installation and Configuration = 
    24The following notes are intended to be a general guide to installing an Automatic Earthworm system. Note that, the Earthworm project consists of the Automatic and Interactive portions of Earthworm. As described in Section1,"Overview", the Automatic portion consists of the "real-time", rapid-response modules, and the Interactive portion consists of the DBMS and web-page codes. These notes deal with the installation of the Automatic portion of Earthworm. 
     
    1012  
    1113 
    12 1. DETERMINE THE DESIRED FUNCTIONS 
     14== 1. DETERMINE THE DESIRED FUNCTIONS == 
    1315 
    1416The main body of documentation is available on the web (http://folkworm.ceri.memphis.edu/ew-doc), and additional features are being continuously developed. New processing modules are initially documented in the release notes and subsequently integrated into the documentation set at the above web site. However, for planning purposes, Earthworm currently offers the following general features: 
     
    4244  
    4345 
    44 2. ESTIMATE THE HARDWARE REQUIREMENTS: 
     46== 2. ESTIMATE THE HARDWARE REQUIREMENTS == 
    4547 
    4648Earthworm has been developed under the mandate of speed and reliability. It therefore tends to use fast, low-level operating system services rather than high-level end-user packages. A side effect of this is that Earthworm is fairly economical in terms of hardware requirements. In general, a contemporary Pentium- or Ultra- class machine is adequate for most regional network loads. Specifically, the hardware requirements can be divided into four categories: 
     
    6466  
    6567 
    66 3. PRODUCE A TEST EVENT 
     68== 3. PRODUCE A TEST EVENT == 
    6769 
    6870This is an optional step which has proven to be extremely useful in rapidly producing a reliable configuration in low-seismicity areas. It will not be needed until testing, but the effort should be initiated early to produce a timely result. The procedure is to find a suitable past event recorded on digital media, and to convert this to an Earthworm 'player' file. Earthworm includes a 'player' module ("waveserver") which can be used to repeatedly inject the trace data of the event to test the operation of the system. 
     
    7274  
    7375 
    74 4. PRODUCE A NETWORK STATION LIST 
     76== 4. PRODUCE A NETWORK STATION LIST == 
    7577 
    7678* Request an FDSN network code by submitting the form at http://fdsn.org/getcode.html. This two-letter code is used throughout the system as part of the trace data naming convention. It is also essential if any data exchange with other networks is contemplated. 
     
    8486  
    8587 
    86 5. CREATE THE EARTHWORM SOFTWARE DIAGRAMS 
     88== 5. CREATE THE EARTHWORM SOFTWARE DIAGRAMS == 
    8789 
    8890For each node, draw a diagram showing modules, message rings, and message paths. Examples are shown in Examples. The diagram should include: 
     
    126128  
    127129 
    128 6. LOAD THE EARTHWORM SOFTWARE 
     130== 6. LOAD THE EARTHWORM SOFTWARE == 
    129131 
    130132The Earthworm Directory Structure: 
     
    172174  
    173175 
    174 7. CREATE THE RUN DIRECTORIES 
     176== 7. CREATE THE RUN DIRECTORIES == 
    175177 
    176178It is recommended that each node have the same directory structure. This is not required, but has been found useful in simplifying maintenance and updates. 
     
    184186  
    185187 
    186 8. CONFIGURE THE EARTHWORM ENVIRONMENT FILES 
     188== 8. CONFIGURE THE EARTHWORM ENVIRONMENT FILES == 
    187189 
    188190* The earthworm_global.d file should contain your Installation Id. Contact Mitch Withers, CERI, Memphis, who acts as control for this file. Local editing of this file is possible, but will prevent the installation form exchanging data with other sites. 
     
    206208  
    207209 
    208 9. MODULE CONFIGURATION 
     210== 9. MODULE CONFIGURATION == 
    209211 
    210212For each module within a node you will need to create a parameter (.d) and an error processing file (.desc). Samples of these files are in the source directory for each module (e.g. c:\earthworm\v#.#\src). 
     
    214216"startstop" and "statmgr" are required to run in all nodes an an earthworm system. Since the "startstop" and "statmgr" module's parameter and error processing files contain settings that control and effect the overall node it is advised to first configure these modules. "startstop" is the module which starts first, and brings up the system by creating the specified rings and starting each module. "statmgr" is responsible for processing error messages created by other modules, monitoring their heartbeats, and issuing restart requests when a module's heartbeat ceases (see below). 
    215217 
    216 9.1 STARTSTOP 
     218=== 9.1 STARTSTOP === 
    217219 
    218220This module is system-specific. Therefore, there are system-specific configuration files (startstop_nt.d and startstop_sol.d) It's configuration file contains the substance of the earthworm configuration diagram (Sect.4). It first lists the rings required for this construction, and then lists a paragraph for each module to be started. This paragraph lists the name of the module's executable, the configuration file it is to read when starting, the priority it is to run at, and (in the Windows 2000 case) whether the module is to have its own window. 
    219221 
    220 9.2 STATMGR 
     222=== 9.2 STATMGR === 
    221223 
    222224This module's configuration file (statmgr.d) lists the error processing files (.desc) of all modules which it is to keep track of. Here are listed the procedures to be followed for the various error types which a client module may issue (email, page, etc), as well as the token "restartMe". If this token appears in a module's .desc file, statmgr will initiate the restart procedure for that module if it's heartbeat should not appear within the stated time period. This procedure involves issuing a 'kill' to the offending module's process id, and "startstop" will then restart the module in a manner identical to that used at startup. 
     
    226228  
    227229 
    228 9.3 OTHER MODULES 
     230=== 9.3 OTHER MODULES === 
    229231 
    230232The Earthworm release currently includes over 50 modules. These are described on the Earthworm web site (http://folkworm.ceri.memphis.edu/ew-doc). However, several key modules are discussed below: 
     
    256258  
    257259 
    258 10. INITIAL STARTUP 
     260== 10. INITIAL STARTUP ==  
    259261 
    260262After all modules are configured, the system can be started. 
     
    268270* The window should display a list of modules and their status, as produced by "startstop" presssing 'enter' will re-display this list. The window will also display any error messages from modules which are sharing this window (see below). 
    269271 
    270 11. DEBUGGING TOOLS AND HINTS: 
     272== 11. DEBUGGING TOOLS AND HINTS == 
    271273 
    272274In the startstop configuration file (startstop_nt.d), each module which is to be run has a "NewConsole" / "NoNewConsole" specification. This determines whether the module's standard output is written to its own command window or into the window used to start the system. For initial testing, it is recommended to set all these to "NoNewConsole". In routine operation, individual windows are convenient for checking on system status. During initial debugging, however, modules tend to exit due to gross configuration errors (typical are invalid "Module Id" and "Ring Name" values). Under Windows 2000 this causes the window of the deceased module to vanish, carrying with it the module's error messages. The "NoNewConsole" setting permits the user to analyze terminal error messages. 
     
    284286  
    285287 
    286 12. COMMON CONFIUGRATION ERRORS: 
     288== 12. COMMON CONFIUGRATION ERRORS == 
    287289 
    288290* Module ID: 
     
    308310  
    309311 
    310 13. INCREASING THE NUMBER OF SHARED MEMORY RINGS UNDER SOLARIS 
     312== 13. INCREASING THE NUMBER OF SHARED MEMORY RINGS UNDER SOLARIS == 
    311313 
    312314Under Solaris 2.6 (and probably other versions as well), the maximum number of shared memory segments is six. This means that on an out-of-the-box machine you can only configure six rings. If you try to configure more than that, you will see a cryptic message from tport_create about too many open files. The fix to this problem is to add the following lines to the /etc/system file, and then reboot the system.