xan/awips2
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
awips2/cave/com.raytheon.viz.gfe/help/baseSiteUserConcept.html

823 lines
24 KiB
HTML
Raw Normal View History

Initial commit
2022-05-05 12:34:50 -05:00
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="GENERATOR"
content="Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13smp i686) [Netscape]">
<meta name="Author" content="Mark Mathewson">
<title>BASE SITE USER Concept</title>
</head>
<body bgcolor="#ffffff">
<h1 class="3Heading">
<a name="GFESuite"></a>GFESuite Configurability - BASE, SITE, USER
Concept</h1>
<div class="3Heading">February 17, 2012<br>
<br>
Table of Contents</div>
<div class="3Heading"><a href="#Overview">Overview</a></div>
<div class="3Heading"><a
href="#DataRetrievalUsingtheBASESITEUSERconcept">Data
Retrieval Using the BASE, SITE, USER Concept</a></div>
<div class="3Heading"><a href="#DataStorageUsingtheBASESITEUSERconcept">Data
Storage Using the BASE, SITE, USER Concept</a></div>
<a href="#TheEffectofMultipleUsers">The Effect of Multiple Users</a>
<br>
<a href="#WhatdatatypesdotheBASESITEUSERapplyto">What Data Types
Do the BASE, SITE, USER Apply To?</a>
<br>
<a href="#WherearetheseBASESITEandUSERfileslocated">Where are These
BASE, SITE, and USER Files Located?</a>
<br>
<a href="#HowdoIcontrolwhetherIamaUSERoraSITE">How Do I Control
Whether
I Am a USER or a SITE?</a>
<br>
<a href="#HowdoImakemodificationstotheSITEfiles">How Do I Make
Modifications
to the SITE Files?</a>
<br>
<a href="#HowdoImakemodificationstotheUSERfiles">How Do I Make
Modifications
to the USER Files?</a>
<br>
<a href="#HowdoIdefineaUSER">How Do I Define a New USER?</a>
<br>
<a href="#AreOtherProgramsAffectedbytheBASESITEUSERconcept">Are
Programs Other Than the GFE Affected by the BASE, SITE, USER Concept?</a>
<p class="3Heading"></p>
<hr width="100%">
<div class="3Heading">
<h1><a name="Overview"></a>Overview</h1>
The GFESuite software uses the concept of site and user overrides. This
permits the installed files from the software distribution to not
interfere
with local modifications. Installed files are called BASE
files.
A site can choose to make changes or override the BASE files by
installing
the sites's files in the SITE area. An individual user can
override
the BASE and SITE definitions by installing custom user files in the
USER
area. <font color="#ff0000">Files under the BASE directories
should
NEVER be modified by the site or they will be overwritten on the next
upgrade.</font>
<p>Upon request of data from EDEX, the server will first look
for data in the customized user directory. If the requested data
is found, it is returned. If not found, the server then looks in
the site directory. If the requested data is found there, it is
returned.
If not found, then the server looks in the base directory. If the
requested data is found in the base directory, it is returned. If
not found, an error is returned.
</p>
<p>Upon storage of data to EDEX, the server will always try to
write into the customized user directory. If it is successful,
subsequent
reads of the data will always be returned via the customized version of
the file.
</p>
<p>Data is retrieved from EDEX using different identifiers,
which
identify the name of an entity, but not its location (e.g., BASE, SITE,
USER). When that data is retrieved, the client can then determine
where the data was retrieved.
</p>
<p>There are some special cases:
</p>
<ul>
<li> <a href="serverConfiguration.html">Server configuration files</a>
are not
stored in the server, but still use the concept of BASE and SITE.
There are no USER-type files for the server configuration since there
is
only one server per site. See the server configuration information for
details.</li>
<li>Grids, topography, and map backgrounds data available through EDEX
are available at only one level. There is no override capability
for this type of data through the server. In other words, every
user of an EDEX will "see" the identical set of grids, topography, and
map backgrounds. There aren't separate databases for BASE
Forecast and SITE or USER Forecast.</li>
</ul>
Some of the files stored in the server are Python files, and others are
non-Python files. With the non-Python files, you get the choice of
a complete override of SITE and BASE files, i.e., you can't do a simple
merge. With the Python files, you can either do a complete
override
using SITE and BASE or you can use the Python "import" statement to do
partial overrides.
<br>
<hr width="100%">
<h1><a name="DataRetrievalUsingtheBASESITEUSERconcept"></a>Data
Retrieval
Using the BASE, SITE, USER Concept</h1>
The following illustration shows examples of the files that will be
retrieved
by a user. The search path for users will always be the USER
directory
first, then the SITE followed by the BASE. If the file is not
found,
an error will be returned. Files in the SITE override files in
the
BASE directory. Files in each USER directory override files in
the
BASE and SITE.
<br>
<h3>Non-Python Case</h3>
<p><br>
This example applies to <a
href="#WhatdatatypesdotheBASESITEUSERapplyto">non-Python
files stored in the server</a>.
</p>
<p>This table illustrates the different conditions and what file is
retrieved based on a USER, and based on SITE.
<br>
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr nosave="" align="center">
<td>File</td>
<td nosave="" align="center">Exists in BASE</td>
<td>Exists in SITE</td>
<td nosave="" align="center">Exists in USER</td>
<td>Returned File by USER</td>
<td>Returned File by SITE</td>
</tr>
<tr nosave="" align="center">
<td nosave="">a</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
<td>Base</td>
<td>Base</td>
</tr>
<tr nosave="" align="center">
<td nosave="">b</td>
<td>YES</td>
<td>YES</td>
<td>YES</td>
<td>User</td>
<td>Site</td>
</tr>
<tr nosave="" align="center">
<td nosave="">c</td>
<td>NO</td>
<td>YES</td>
<td>YES</td>
<td>User</td>
<td>Site</td>
</tr>
<tr nosave="" align="center">
<td nosave="">d</td>
<td>NO</td>
<td>YES</td>
<td>NO</td>
<td>Site</td>
<td>Site</td>
</tr>
<tr nosave="" align="center">
<td nosave="">e</td>
<td>NO</td>
<td>NO</td>
<td>YES</td>
<td>User</td>
<td>&lt;none&gt;</td>
</tr>
<tr nosave="" align="center">
<td nosave="">f</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>Site</td>
<td>Site</td>
</tr>
</tbody>
</table>
</p>
<p><img src="images/baseSiteUserRetrieval.jpg" nosave="" height="540"
width="720"><br>
</p>
<h3>Python Case</h3>
<p><br>
Data retrieval for Python files from the server work on essentially
the same principal, except that Python files can import other files as
shown in the following table and illustration illustration (the black
arrows
indicate the import path as defined in the actual files, the red arrows
indicate the final result):
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr nosave="" align="center">
<td>File</td>
<td nosave="" align="center">Exists in BASE</td>
<td>Exists in SITE</td>
<td nosave="" align="center">Exists in USER</td>
<td>Returned File by USER (considering imports)</td>
<td>Returned File by SITE (considering imports)</td>
</tr>
<tr nosave="" align="center">
<td nosave="">m</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
<td>Base m</td>
<td>Base m</td>
</tr>
<tr nosave="" align="center">
<td nosave="">n</td>
<td>YES</td>
<td>NO</td>
<td>YES - inports m</td>
<td>Base m + User n</td>
<td>Base n</td>
</tr>
<tr nosave="" align="center">
<td nosave="">o</td>
<td>NO</td>
<td>YES - imports m</td>
<td>NO</td>
<td>Base m + Site o</td>
<td>Base m + Site o</td>
</tr>
<tr nosave="" align="center">
<td nosave="">p</td>
<td>NO</td>
<td>YES - imports m</td>
<td>NO</td>
<td>Base m + Site p</td>
<td>Base m + Site p</td>
</tr>
<tr nosave="" align="center">
<td nosave="">q</td>
<td>NO</td>
<td>NO</td>
<td>YES - imports p</td>
<td>Base m + Site p + User q</td>
<td>&lt;none&gt;</td>
</tr>
<tr nosave="" align="center">
<td nosave="">r</td>
<td>NO</td>
<td>NO</td>
<td>YES</td>
<td>User r</td>
<td>&lt;none&gt;</td>
</tr>
<tr nosave="">
<td nosave="" align="center">s</td>
<td nosave="" align="center">NO</td>
<td nosave="" align="center">NO</td>
<td nosave="" align="center">YES - imports n</td>
<td nosave="" align="center">Base m + User n + User s</td>
<td nosave="" align="center">&lt;none&gt;</td>
</tr>
</tbody>
</table>
</p>
<p><img src="images/baseSiteUserPythonRetrieval.jpg" nosave=""
height="540" width="720"><br>
Note that for the Python "n" case, the BASE "n" is hidden from the
USER since there is already an "n" in USER. Therefore a USER who
uses an "import n" statement in one of the files will not see the BASE
"n", but will see the USER "n". There is no way to specify in an
import statement whether you want BASE or SITE or USER. In the case of
USER "r", no imports were performed at all.
<br>
</p>
<hr width="100%">
<h1><a name="DataStorageUsingtheBASESITEUSERconcept"></a>Data Storage
Using
the BASE, SITE, USER Concept</h1>
The following illustration shows examples of the files that will be
stored
by a user. The storage path for users is always the USER
directory.
If the file is read-only, attempts to store a file with the same name
will fail.
<p>This table illustrates the different conditions and what file is
stored
based on a USER, and based on SITE.
File "e" in USER is read-only in this example. Attempts to write
over "e" will fail. File "a" is located in BASE and a new one is
written to USER. Even though "a" in BASE is read-only, the user
may write a file into USER under the same name.
<br>
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr nosave="" align="center">
<td>File</td>
<td nosave="" align="center">Exists in BASE</td>
<td>Exists in SITE</td>
<td nosave="" align="center">Exists in USER</td>
<td>Storage Location for USER</td>
<td>Storage Location for SITE</td>
</tr>
<tr nosave="" align="center">
<td nosave="">a</td>
<td>YES (read-only)</td>
<td>NO</td>
<td>NO</td>
<td>User</td>
<td>Base</td>
</tr>
<tr nosave="" align="center">
<td nosave="">b</td>
<td>YES</td>
<td>YES</td>
<td>YES</td>
<td>User</td>
<td>Base</td>
</tr>
<tr nosave="" align="center">
<td nosave="">c</td>
<td>NO</td>
<td>YES</td>
<td>YES</td>
<td>User</td>
<td>Base</td>
</tr>
<tr nosave="" align="center">
<td nosave="">d</td>
<td>NO</td>
<td>YES</td>
<td>NO</td>
<td>User</td>
<td>Base</td>
</tr>
<tr nosave="" align="center">
<td nosave="">e</td>
<td>NO</td>
<td>NO</td>
<td>YES (read-only)</td>
<td>&lt;ERROR&gt;</td>
<td>Base</td>
</tr>
<tr nosave="" align="center">
<td nosave="">f</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>User</td>
<td>Base</td>
</tr>
</tbody>
</table>
</p>
<p><img src="images/baseSiteUserStorage.jpg" nosave="" height="540"
width="720"><br>
</p>
<hr width="100%">
<h1><a name="TheEffectofMultipleUsers"></a>The Effect of Multiple Users</h1>
Multiple users, as long as their login name or specified user name are
different, are isolated from each other. This allows individuals to
create
their own special set of edit areas, smart tools, and GFE
configurations
without affecting other users.
<p>It is quite possible, and probable, to have two different clients,
such
as GFEs, running under the same user login name. This case is not
treated as two different users.
</p>
<p>The following illustration shows examples of the files that will be
stored by two users with different login names. The storage path
for users is always the USER directory. If the file is read-only,
then attempts to store a file with the same name will fail.
</p>
<p>The table illustrates the different conditions and what file is
stored
based two users, USER1 and USER1. In this example, there are no
read-only
files in USER1 or USER2. Examples are shown for the<a
href="#WhatdatatypesdotheBASESITEUSERapplyto">
non-Python files</a>, which don't use the import facility.
<br>
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr nosave="" align="center">
<td>File</td>
<td nosave="" align="center">Exists in BASE</td>
<td>Exists in SITE</td>
<td nosave="" align="center">Exists in USER1</td>
<td>Exists in USER2</td>
<td>Storage Location for USER1</td>
<td>Storage Location for USER2</td>
</tr>
<tr nosave="" align="center">
<td nosave="">a</td>
<td>YES (read-only)</td>
<td>NO</td>
<td>NO</td>
<td>NO</td>
<td>User1</td>
<td>User2</td>
</tr>
<tr nosave="" align="center">
<td nosave="">b</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>YES</td>
<td>User1</td>
<td>User2</td>
</tr>
<tr nosave="" align="center">
<td nosave="">c</td>
<td>NO</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>User1</td>
<td>User2</td>
</tr>
<tr nosave="" align="center">
<td nosave="">d</td>
<td>NO</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
<td>User1</td>
<td>User2</td>
</tr>
<tr nosave="" align="center">
<td nosave="">e</td>
<td>NO</td>
<td>NO</td>
<td>NO</td>
<td>NO</td>
<td>User1</td>
<td>User2</td>
</tr>
<tr nosave="" align="center">
<td nosave="">f</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
<td>User1</td>
<td>User2</td>
</tr>
</tbody>
</table>
</p>
<p><img src="images/baseSiteUserMultipleStorage.jpg" nosave=""
height="540" width="720"></p>
<p>The following illustration shows examples of the files that will be
retrieved by two users. The search path for users is always the
USER
directory first, then the SITE followed by the BASE. If the file
is not found, then an error will be returned. Files in the SITE
override
files in the BASE directory. Files in each USER directory
override
files in the BASE and SITE.
</p>
<p>The files in the different USER directories are not seen by all
users,
just the user that matches the login name.
</p>
<p>The table illustrates the different conditions and what file is
retrieved
based on a user, and based on SITE.
<br>
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr nosave="" align="center">
<td>File</td>
<td nosave="" align="center">Exists in BASE</td>
<td>Exists in SITE</td>
<td nosave="" align="center">Exists in USER</td>
<td>Returned File by USER1</td>
<td>Returned File by USER2</td>
</tr>
<tr nosave="" align="center">
<td nosave="">a</td>
<td>YES</td>
<td>NO</td>
<td>NO</td>
<td>Base</td>
<td>Base</td>
</tr>
<tr nosave="" align="center">
<td nosave="">b</td>
<td>YES</td>
<td>YES</td>
<td>YES</td>
<td>Site</td>
<td>User</td>
</tr>
<tr nosave="" align="center">
<td nosave="">c</td>
<td>NO</td>
<td>YES</td>
<td>YES</td>
<td>User</td>
<td>User</td>
</tr>
<tr nosave="" align="center">
<td nosave="">d</td>
<td>NO</td>
<td>YES</td>
<td>NO</td>
<td>Site</td>
<td>Site</td>
</tr>
<tr nosave="" align="center">
<td nosave="">e</td>
<td>NO</td>
<td>NO</td>
<td>NO</td>
<td>&lt;none&gt;</td>
<td>&lt;none&gt;</td>
</tr>
<tr nosave="" align="center">
<td nosave="">f</td>
<td>YES</td>
<td>YES</td>
<td>NO</td>
<td>Site</td>
<td>Site</td>
</tr>
</tbody>
</table>
</p>
<p><img src="images/baseSiteUserMultipleRetrieval.jpg" nosave=""
height="540" width="720"></p>
<h1>
<hr width="100%"><a name="WhatdatatypesdotheBASESITEUSERapplyto"></a>What
Data Types Do the BASE, SITE, USER Apply To?</h1>
The BASE, SITE, and USER concepts apply to the types of data shown in
the
following table. If the BASE, SITE, USER concept is used, then the site
can override the initial installation files (BASE), and an individual
user
can override the sites's files. If there is a "Python 'import'
capability"
for a particular data type, that permits partial overrides by using the
Python "import" statement to pull in additional files.
<br>
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr>
<td><b>Data Type</b></td>
<td><b>Uses BASE, SITE, USER Concept</b></td>
<td>Python "import" capable</td>
</tr>
<tr>
<td>Sample Sets</td>
<td>YES</td>
<td>NO</td>
</tr>
<tr>
<td>Color Tables</td>
<td>YES</td>
<td>NO</td>
</tr>
<tr>
<td><a href="GFETrainingSpatialEditor.html#EditAreas">Edit areas</a>
(a.k.a.
REFERENCE sets)</td>
<td>YES</td>
<td>NO</td>
</tr>
<tr>
<td><a href="SmartTools.html">Edit Tools</a></td>
<td>YES</td>
<td>YES</td>
</tr>
<tr>
<td style="vertical-align: top;"><a href="SmartTools.html">Procedures</a></td>
<td style="vertical-align: top;">YES<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">Text Utilities<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">Utilities (e.g., Smart Scripts)<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
</tr>
<tr>
<td><a href="GFETrainingSpatialEditor.html#EditAreaGroups">Edit
Area Groups</a></td>
<td>YES</td>
<td>NO</td>
</tr>
<tr>
<td><a href="GFEMainMenu.html#WeatherElementGroups">Weather
Element Groups</a>
(BUNDLE)</td>
<td>YES</td>
<td>NO</td>
</tr>
<tr>
<td style="vertical-align: top;">Combo (Zone Combiner saved
configurations, and color table)<br>
</td>
<td style="vertical-align: top;">NO - this is a special case that
does not use the BASE/SITE/User concept. All files are written
into the SITE-level regardless of user.<br>
</td>
<td style="vertical-align: top;">NO<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">Combo (Zone Combinations used by
products)<br>
</td>
<td style="vertical-align: top;">NO - this is a special case that
does not use the BASE/SITE/User concept.
All files are written into the SITE-level regardless of user.</td>
<td style="vertical-align: top;">YES<br>
</td>
</tr>
<tr>
<td><a href="GFEMainMenu.html#Procedures">Text Formatters<br>
</a></td>
<td>YES</td>
<td>YES<br>
</td>
</tr>
<tr>
<td><a href="GFEMainMenu.html#DefineSelectTimeRanges...">Selection
Time
Range by name</a></td>
<td>YES</td>
<td>NO</td>
</tr>
<tr>
<td>Grid Data</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td>Map Background Data</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td>Topography Data</td>
<td>NO</td>
<td>NO</td>
</tr>
<tr>
<td><a href="serverConfiguration.html">Server Configurations</a></td>
<td>Partially. Base and Site are supported, but are implemented
in a different
technique than is described here. For information, see the <a
href="serverConfiguration.html">server
configuration guide</a>.</td>
<td>YES</td>
</tr>
<tr>
<td><a href="gfeConfiguration.html">GFE Configurations</a></td>
<td>YES. The implementation is done differently than described
here.
For information, see the <a href="gfeConfiguration.html">GFE
configuration
guide</a>.</td>
<td>YES</td>
</tr>
<tr>
<td style="vertical-align: top;">Virtual Parm Modules<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">GHG Monitor Configuration<br>
</td>
<td style="vertical-align: top;">YES<br>
</td>
<td style="vertical-align: top;">NO<br>
</td>
</tr>
</tbody>
</table>
<p>
</p>
<hr width="100%">
<h1><a name="WherearetheseBASESITEandUSERfileslocated"></a>Where are
These
BASE, SITE, and USER Files Located?</h1>
The location of the server configuration files are shown in the table
below:
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr>
<td><b>File Purpose</b></td>
<td><b>Part of Standard Release</b></td>
<td><b>AWIPS File Location</b></td>
</tr>
<tr>
<td>BASE files</td>
<td>
<center>yes</center>
</td>
<td>/awips2/edex/data/utility/common_static/base/gfe/*<br>
/awips2/cave/etc/gfe/userPython/*</td>
</tr>
<tr>
<td>SITE customized files</td>
<td>
<center>no</center>
</td>
<td>/awips2/edex/data/utility/common_static/site/<i>site</i>/gfe/*<br>
/awips2/edex/data/utility/cave_static/site/<i>site</i>/gfe/userPython/*</td>
</tr>
<tr>
<td>USER customized files</td>
<td>
<center>no</center>
</td>
<td>/awips2/edex/data/utility/common_static/user/<i>username</i>/gfe/*<br>
/awips2/edex/data/utility/cave_static/user/<i>username</i>/gfe/userPython/*</td>
</tr>
</tbody>
</table>
<p>The BASE files should never be modified. SITE modifications are
done in the SITE directories. User modifications are done in each
individual user directory structure.
<br>
</p>
<hr width="100%">
<h1><a name="HowdoIcontrolwhetherIamaUSERoraSITE"></a>How Do I Control
Whether
I Am a USER or a SITE?</h1>
Many of the files supported in this hierarchical scheme are
written/controlled
from the GFE. In AWIPS2, all users are logged in with their assigned
system user id. The software does not treat user vs. site as user
accounts. Site level modifications by users are permitted.
<hr width="100%">
<h1><a name="HowdoImakemodificationstotheSITEfiles"></a>How Do I Make
Modifications
to the SITE Files?</h1>
Making modifications to the SITE files can be accomplished two ways:
<ol>
<li>Start the <a href="LocalizationPerspective.html">Localization</a> perspective and make any changes.</li>
<li>Go to the UNIX file system and edit, copy, move, or delete files
from under
the SITE/* directory. You can copy files from the BASE/*
directories,
but make NO changes to the BASE/* directories or files.</li>
</ol>
<p>EDEX and CAVE must be restarted for any changes in common_static. CAVE must
be restarted for any changes in CAVE configuration.</p>
<hr width="100%">
<h1><a name="HowdoImakemodificationstotheUSERfiles"></a>How Do I Make
Modifications
to the USER Files?</h1>
Making modifications to the USER files are accomplished the same way
as SITE level modifications (see paragraph above).
<hr width="100%">
<h1><a name="AreOtherProgramsAffectedbytheBASESITEUSERconcept"></a>Are
Programs
Other Than the GFE Affected by the BASE, SITE, USER Concept?</h1>
All other GFESuite programs, including <a href="ifpIMAGE.html">ifpIMAGE</a>,
and <a href="ifpAG.html">ifpAG</a>, use the BASE, SITE, USER
concept.
These programs take a "-u" switch to specify the user name. By
default,
if the user name is not specified, in which case the SITE user name is
used.
<p>Since these other programs are typically product generation
programs,
it is unlikely that you would want individual user configurations to
affect
the output. Therefore the default is SITE.
<br>
</p>
<hr width="100%"><br>
<a href="#GFESuite">Back To Top</a>
<br>
<a href="GFESuite.html">Back To TOC</a>
<br>
<br>
</div>
<br>
</body>
</html>
Reference in a new issue Copy permalink