Operating System and Administrative User Setup
In order to install Oracle Utilities Network Management System software, you must have your system administrator configure a Linux/Unix environment and setup the environment for the Oracle Utilities Network Management System administrative user.
Topics in this section include the following:
Dual-Environment Configuration
In a dual-environment configuration (used to reduce downtime when installing patches), two administrative users are needed on the same host. This is an implementation of a patching strategy that is more commonly called blue/green patching. While the "blue" environment is active, the "green" environment can be staged to minimize the time it takes to make it active - and vice-versa. Both of these users must be members of the same Unix group. Follow the instructions in the
Administrative User Configuration section for both users.
Administrative User Configuration
The administrative user (for example, nmsadmin) owns and controls the services. The administrative user also owns and maintains the binaries, and all the configuration standards.
The Administrative Unix user:
• Owns the Isis release directories.
• Starts and stops Isis processes.
• Performs installs.
• Owns the executable directories.
• Has read-write permissions to the production database.
• Owns the service processes (DBService, MTService, etc.) and performs all sms‑start commands.
Creating an Administrative User
The administrative user, as the name implies, has central control over many critical aspects of the Oracle Utilities Network Management System. This user is the central controller of:
• Isis: configuration and starting and stopping of the Isis processes. See the Oracle Utilities Network Management System Configuration Guide for information on configuring Isis.
• Oracle Utilities Network Management System services: stopping and starting services and administering service logs.
• Oracle Utilities Network Management System files: binaries, configuration files.
• Database connection for example, read/write privileges.
• Model-building data.
It should be noted that for data security, Oracle Utilities Network Management System tools that can be used to directly modify data are installed with permissions set so that only the administrative user is allowed to execute them.
The administrative user has access to critical components of the system. This user owns and maintains the services, the starting of the services, model building, binaries, the database, and the configuration standards. The administrative user maintains the Oracle Utilities Network Management System Unix-based configuration and executables in one location.
A given NMS instance requires at least one NMS admin Unix user/account. For a single NMS admin environment this could be something like nmsadmin but for a dual NMS environment (to support expedited NMS patching) there are two NMS Unix admin accounts (nmsadmin-1 and nmsadmin-2 – for example). In either case there is only one NMS RDBMS admin user/schema (nms_prod – for example). The NMS Unix admin account is where NMS Services will execute. The NMS RDBMS admin schema is used to construct and maintain the NMS RDBMS schema.
• The NMS RDBMS admin schema handles the SQL Data Definition Language (DDL) statements necessary to construct and maintain (patch) the NMS schema. The RDBMS admin schema/account is NOT generally used directly by NMS Services for a running NMS production instance – only for patching. Once the Unix admin account is setup according to this document the “ISQL –admin” shortcut uses the $RDBMS_ADMIN environment variable to access the admin schema.
• ISQL -admin
• The $RDBMS_ADMIN environment variable must be different from the $RDBMS_HOST environment variable as they are used to look up and access different credentials for different schemas in the $NMS_HOME/etc/wallet. The $RDBMS_ADMIN and $RDBMS_HOST variables CAN (ultimately) be two alternate “net_service_name” entries in a local tnsnames.ora configuration file – as noted in the example above (PRODSERV01ADM and PRODSERV01).
• NMS Services (and WebLogic) use an “access” schema to perform routine SQL Data Manipulation Language (DML) updates to a production NMS instance. There are generally two NMS RDBMS access schemas (nms_prod_1 and nms_prod_2 – for example). These “access” schemas contain only synonyms that point to desired tables within the nms_prod (admin) schema.
• Only one access schema is fully utilized at a given time for a given NMS instance. One is for production and the other for staging an NMS patch – and they alternate purposes (sometimes called blue/green patching). For example, the nmsadmin-1 Unix account would typically have $NMS_ENVIRONMENT=1 and would leverage the nms_prod_1 access schema for operations and vice-versa for the nmsadmin-2 Unix account (it would have $NMS_ENVIRONMENT=2 and would leverage the nms_prod_2 access schema) – by convention.
Note: Even if dual NMS admin environments are NOT desired an NMS access schema is still required (typically $NMS_ENVIRONMENT=1). From a NMS Unix admin and RDBMS schema perspective the only difference between a single NMS admin installation and a dual NMS admin installation is the lack of a second NMS Unix admin account and its associated second RDBMS access schema.
• The ISQL utility (with no options) uses the $RDBMS_HOST environment variable to locate a similarly named RDBMS net_service_name entry in the tnsnames.ora file to determine which RDBMS access schema and credentials to use for a given NMS Unix admin environment. Each NMS admin environment manages its own set of Oracle wallets and credentials so the associated access schema will be as well. The RDBMS access schema that a given NMS admin environment uses will be identified by the $ORACLE_READ_WRITE_USER environment variable within a given NMS Services environment. Once an NMS admin environment is properly configured the ISQL utility will allow access to the default $ORACLE_READ_WRITE_USER access schema within that environment.
• ISQL
For more information on the dual NMS admin account scheme see the NMS Configuration Guide.
Korn Shell Configuration
Oracle Utilities Network Management System uses the Korn Shell to set environment variables and provide the command line interface to the operating system. The Korn Shell, also referred to as ksh, standardizes command line execution and requests, such as running scripts, executing applications, and operating the services. The Korn Shell uses a file called .profile to configure itself. The administrative account needs to have:
• Its default shell set to ksh.
• Its .profile configured to source the Oracle Utilities Network Management System configuration file (.nmsrc).
For your convenience, templates of a generic .profile and .nmsrc file are included in the Oracle Utilities Network Management System software distribution, under $NMS_BASE/templates. These files can be copied to $NMS_HOME/.profile and $NMS_HOME/.nmsrc and then modified to suit your installation.
.profile Configuration
The Korn Shell .profile is a hidden file that exists in the user’s home directory. When a user logs in, this file executes, setting environment variables and defining terminal configuration. The following is required for setting up .profile or the Oracle Utilities Network Management System administrative user.
Edit the .profile file to source the user environment configuration file (.nmsrc) by adding the following line to the end of the file (using any text editor).
. ~/.nmsrc
This runs .nmsrc in the current shell and initializes all of the environment variables within the .nmsrc file in the current working environment.
The .profile file must also execute correctly when called from another script, as well as when the user logs in at a terminal. Anything in .profile that is terminal-specific should be placed in an “if” clause to suppress execution if the .profile is not being run from a terminal.
# Set a variable to be true when .profile is
# being run from a terminal rather than a script.
#
if tty -s
then
TTY=true;
else
TTY=false;
fi
#
# Protect items that must only be run from a
# terminal and not from a script.
#
if $TTY
then
stty Compaq
tset -I -Q
PS1="`hostname`>"
fi
Executables/Run-Times
The Oracle Utilities Network Management System Unix-based software is installed in the product home directory ($NMS_BASE/bin). When commands are entered at the prompt, the shell looks for the appropriate bin directory for a matching program. The PATH environment variable determines where the shell looks for the bin directory, so PATH must be modified to include the location of the Oracle Utilities Network Management System software. It is defined in the .nmsrc file located in the user’s home directory and it may contain multiple path names, each separated with a colon (:). The shell parses each path name until the corresponding program is located or each path name is exhausted.
Note: The .nmsrc file sets up the PATH environment variable to ensure that the correct executables are discovered in the correct order. If you need to modify the PATH environment variable, it should be done in the .profile, after the .nmsrc is run, and you should only append directories to the end of the list. Doing otherwise could cause problems with your system.
Operating System Configuration
A standard operating system installation will often not be optimally configured to work with an Oracle Utilities Network Management System. Sometimes the user will spawn more processes than allowed by the standard kernel configuration. Other times, a map file may require a larger data segment than the average user. Due to problems like these, you may find that you will have to tweak the operating system configuration, which may include reconfiguring the kernel or some other part of your Unix system.
The values that are specified in this guide are examples only, as the correct values depend on how large your operating model is, how you use the system (for example, as a server, app-server, or client) and what kind of a load is placed on the system. This section should give you an idea of how to change components of the operating system that frequently become a problem running Oracle Utilities Network Management System.
Note on Oracle Support Policy on VMWare: Refer to My Oracle Support knowledge base article 249212.1 for Oracle’s support policy on VMWare.
Linux
In Linux, limits to data segment size and the number of files available to the user are defined by the ulimit command. For the most part, these parameters do not need to be tweaked, but should you need to, you can run:
Ensure your host has appropriately sized kernel buffers to support high volumes of NMS UDP messaging. For example, on Linux, you can run the following to see current configuration:
/sbin/sysctl -q net.core
For a large or very active NMS system ensure the following parameters are set reasonably - below are suggested values:
net.core.rmem_default = 8388608
net.core.rmem_max = 8388608
net.core.wmem_default = 524288
net.core.wmem_max = 1048576
net.core.netdev_max_backlog = 2000
net.core.optmem_max = 2524287
You need to be root to update the Linux /etc/sysctl.conf file and reboot after changing it (safest if changes are made). Note you can generally change the above parameters on the fly, but they will NOT be retained on reboot unless you update the /etc/sysctl.conf file to match.
Example of how to change one of the noted config values on the fly:
sysctl -w net.core.rmem_default=8388608
Note: The values above are examples that have been tested and shown to generally yield reasonable results. It is entirely possible that other values may be appropriate for your NMS model and hardware.
Solaris
In Solaris, limits to data segment size and the number of files available to the user are defined by the ulimit command. For the most part, these parameters do not need to be tweaked, but should you need to, you can run:
Core File Naming Configuration
Standard Unix configuration generally names core files as “core” and places it in the directory where the executable was executed. This is problematic because the core file will get overwritten if another core file is generated, which will destroy information that could possibly be used to better track down the source of the problem. Fortunately, there are operating specific steps to have core files be saved with process specific names.
Linux
Note the following may be the default on the Linux distributions supported by Oracle Utilities Network Management System.
echo “1” > /proc/sys/kernel/core_uses_pid
You should also verify that the ulimit for core files is set to unlimited; otherwise, core or truncated core files may not be created:
ulimit -c unlimited
Solaris
As the root user, edit /etc/coreadm.conf:
(COREADM_INIT_PATTERN=core.%p)
Or run:
coreadm -i "core.%p"
You should also verify that the ulimit for core files is set to unlimited; otherwise, core or truncated core files may not be created:
ulimit -c unlimited