Understanding the configuration parameters for installing Oracle on RHEL

No matter what version of Oracle you install, you need to configure the/etc/pam.d/login/etc/profile/etc/security/limits.conf three files before installing

So what exactly are these three files for? The answer is to set the shell limits for the Oracle user. Here's a closer look at these papers.

First you need to edit the/etc/security/limits.conf file (user restriction profile)

Oracle Soft Nproc 2047

Oracle Hard Nproc 16384

Oracle Soft Nofile 1024

Oracle Hard Nofile 65536

Then edit the/etc/pam.d/login file (add the configuration file to the Login verification module)

Session Required Pam_limits.so

Last edited/etc/profile file (environment variable file)

if [$USER = "Oracle"]; Then        if [$SHELL = "/bin/ksh"], then              ulimit-p 16384              ulimit-n 65536        else              ulimit-u 16384-n 65536
    fifi

To understand the role of these files, we first need to understand the PAM validation mechanism

I. Understanding the mechanism of PAM validation module

the origin and function of Pam

Linux PAM (Plug-in authentication module, pluggable authentication Modules)

For security reasons, a computer system can only be accessed by authorized legitimate users. This requires that the program provide the code that identifies the logged-on user identity information. The code that originally implemented the authentication function was part of the application, in which case the user had to rewrite and recompile the original entire program if it found that there were some flaws in the algorithm used or if it wanted to use another authentication method. It is clear that this type of identification lacks flexibility. As a result, people began to look for a better identification scheme: On the one hand, to separate the identification function code from the application, to form a separate module, maintenance alone, on the other hand, for these identification modules to establish a standard API, so that the application can easily use the various functions they provide. The modular design and plug-in functionality of the plug-in authentication module (PAM) allows us to easily insert new authentication modules or replace the original components in the application without any modifications to the application, making it easier to customize, maintain, and upgrade the software

In 1995, Sun introduced Pam to achieve the above requirements, to achieve the separation of application and authentication mechanism, and Pam can integrate a variety of authentication mechanisms, easy to implement the application of the identification part of the flexibility.

The framework for Pam on various versions of Unix systems is the same, except for the specific implementations, so the Linux Pam Framework Knowledge we introduce here is universal. So in the course of introducing the framework of this article, we can see that we have not deliberately differentiated the terms PAM and linux-pam.

the hierarchical architecture of Pam

In order to implement its plug-in functionality and ease of use, Pam has adopted a layered design concept: To separate the authentication modules from the application, and then use the PAM API as a link between the two, so that the application can "insert" the required authentication function modules in it as needed, thereby truly realizing the "authentication function, On demand ". The PAM architecture looks like this

In Rhel,

Pam verification module, storage location in/lib/security, such as pam_limits.so, pam_group.so, etc.

The configuration file of the PAM authentication module, which is stored in the location/etc/security, such as the pam_limits.so authentication module corresponding to the configuration file limits.conf,pam_group.so verify the module corresponding to the configuration file group.conf.

Pam verifies the correspondence between the module and the application, storing the location/ETC/PAM.D folder. By modifying the configuration file under this folder, you can select a specific validation module for your app

Second, understand the PAM authentication module and application of the corresponding relationship of the configuration file

For the/etc/security/limits.conf file configuration to take effect, you must make sure that the PAM validation module pam_limits.so file is added to the startup file. The view/etc/pam.d/login file has:
Session required/lib/security/pam_limits.so

The 64-bit address is:/lib64/security/pam_limits.so Otherwise, you cannot log on locally even if you enter the correct password.

Pam verifies that the module is associated with the application's configuration file, that is, the file under/ETC/PAM.D, where the syntax is parsed using/etc/pam.d/login as an example, and the syntax for all files in the/etc/pam.d/directory is the same.

The syntax for the configuration file under the Pam.d folder is

Service model_type control_flag model_path Options

Service : An application that uses Pam to validate the module, such as FTP, Telnet, login, and so on. Where other line refers to other applications that are not listed separately in this file

model_type : The type of Pam authentication module used by the application, mainly has the following several

Auth: Identification class module account: Accounts class module

Session: Conversation class module Password: Password class module

Only one type of module can be specified per line, and if the application requires multiple modules to be combined, it needs to be specified separately in multiple lines.

control_flag: Processing of successful or failed module validation

Required: This module verifies that success is a necessary condition for user identification. The application will be authenticated only if all modules with the required tag for the application are successful. Also, if any module with the required tag has an error, Pam does not immediately return the error message to the application, but instead returns the error message to the application that called it after all the modules have been called.

requisite: Similar to required, only when a module with this tag returns successfully can the user authenticate, except that the other modules later in the heap are no longer executed once the failure is completed, and the authentication process ends.

Optiona: Even if the module fails validation, the user can still pass the identification. In the PAM system, when the module with this tag fails, the next module continues to be processed.

Sufficiet: The success of this module is a sufficient condition for the user to authenticate, that is, once the module labeled sufficient succeeds, Pam returns to the application successfully without having to try any other modules. When a module marked as sufficient fails, the sufficient module treats as optional.

Model_path: Indicates the location of the PAM module.

Options : used to pass related options to a specific module, which is then interpreted by module analysis. For example, use this bar to turn on module debugging, or to pass parameters such as timeout values to a module. In addition, it is used to support password mapping techniques.

Third, understand the PAM authentication module configuration file

The configuration file for the PAM validation module is placed under/etc/security/, which only describes the limits.conf file.

Limits file limits User process resolution

The PAM authentication module/lib/security/pam_limits.so mainly restricts the use of various system resources during the user session. Its corresponding configuration file/etc/security/limits.conf its format as

Domain Type Item

User name/group name soft/hard Limit items

Domain: Refers to a restricted user name or group

Type:

Soft: The current system is in effect setting value (Soft limit can not be higher than hard limit)

Hard: The maximum value that can be set in the system

-: Soft and hard values are also set

Item: Restricting the user's resource type

Core--core file Size (KB)

data--Maximum data size (KB)

fsize--Maximum file size (KB)

memlock--Maximum free memory space (KB)

nofile--maximum number of files that can be opened

rss--maximum space to reside in kilobytes (KB)

stack--Maximum stack space (KB)

cpu--Maximum CPU usage time (MIN)

nproc--maximum number of running processes

as--Address Space Limitations

maxlogins--the maximum number of times a user can log on to a system

locks--maximum number of locked files

Iv. Understanding Environment Variables file User process limits

The last change to the environment variable file/etc/profile is also to modify the process limit for the current user.

Ulimit: Sets the resource occupied by the shell startup process.

-N: Sets the maximum value of the file descriptor that the kernel can open at the same time.

-P: Sets the maximum value of the pipe buffer.

-U: Sets the maximum number of programs a user can open.

Linux defaults to limit the maximum number of processes for a system user. To improve performance, you can set the maximum number of processes for each Linux user based on the device resource situation. Some of these settings can also be set to unlimited, that is, unlimited. Such as

Data segment Length: ulimit-d Unlimited
Maximum memory size: Ulimit-m Unlimited
Stack size: Ulimit-s Unlimited
CPU time: Ulimit-t Unlimited.
Virtual Memory: Ulimit-v Unlimited

In addition, if you set some parameters for the user unilaterally at this location, you may encounter the following error message:

Ulimit:max user Processes:cannot Modifylimit: Operations not allowed

Ulimit:open Files:cannot Modify limit: Operations not allowed

This is because Liunx has a default ulimits limit for the user, which is saved in/etc/security/limits.conf, where the hard configuration is the upper limit, and changes beyond the limit will cause "disallowed operations" errors. That's why the limits.conf file was previously modified

Understanding the configuration parameters for installing Oracle on RHEL