4 Configuring Security for Oracle Exadata System Software

This chapter explains how to configure security for Oracle Exadata System Software.

This chapter contains the following topics:

4.1 Understanding Data Security for Oracle Exadata System Software

Oracle Exadata System Software data security is implemented by controlling which Oracle Automatic Storage Management (Oracle ASM) clusters and database clients can access specific grid disks on storage cells. By default, all database and Oracle ASM instances have access to all storage cell grid disks.

  • To set up security so that all database clients of an Oracle ASM cluster have access to specific grid disks, configure Oracle ASM-scoped security.

  • To set up security so that specific database clients of an Oracle ASM cluster have access to specific grid disks, configure database-scoped security.

To have consistent Oracle Exadata System Software security, ensure the following:

  • All grid disks that belong to the same Oracle ASM disk group have the same cell-side grid disk security defined to avoid confusion and errors.

  • All Oracle Real Application Clusters (Oracle RAC) servers in an Oracle ASM cluster have the same content, ownership, and security for the Oracle ASM cellkey.ora file.

  • All Oracle RAC servers in a database cluster have the same content, ownership, and security for the database cellkey.ora file.

  • If database-scoped security is implemented, then ensure it is implemented for all databases accessing the grid disks. Do not mix Oracle ASM-scoped security and database-scoped security.

While setting up security, it is imperative that the configuration is the same across cells. Using the dcli utility to make configuration changes ensures consistency by eliminating the potential of user errors.

Oracle Exadata System Software security allows open security, Oracle ASM-scoped security, or database security. The following sections describe each mode:

To implement security, you must establish a security key.

Related Topics

4.1.1 About Open Security Mode

Open security mode enables access by any database client to a grid disk. Open security mode is useful for test or development databases where there are no security requirements. This is the default security mode after creating a new storage cell.

To use this security mode, you do not set up any security functionality for an Oracle ASM cluster or a database client for the grid disk. You do not set up any security key files.

4.1.2 About Oracle ASM-Scoped Security Mode

Oracle ASM-scoped security mode enables access by all the database clients of an Oracle ASM cluster to grid disks on cells.

Oracle ASM-scoped security is appropriate when you want all databases on a host cluster to have access to the cell grid disks in the Oracle ASM disk groups managed by the Oracle ASM cluster. This includes the case when there is only one database in an Oracle ASM cluster.

When Oracle ASM-scoped security is set up for an Oracle ASM cluster and grid disks, the grid disks are available only to the databases on the Oracle ASM cluster.

Starting with Oracle Exadata 12.2.1.1.0, you can define Oracle ASM-scoped security based on ASM clusters. Once you have set up your ASM clusters, you can use the same database unique name in one or more clusters. Within each ASM cluster, the database names still have to be unique. The ASM cluster name is used to qualify the database unique name.

4.1.3 About Database-Scoped Security Mode

Database-scoped security mode configures access to specific grid disks on cells for specific database clients of an Oracle ASM cluster.

Database-scoped security mode is appropriate when multiple databases are accessing cells, and you want to control which databases can access specific grid disks that compose Oracle ASM disk groups. Set up Oracle ASM-scoped security for your initial security mode, then set up database-scoped security for specific database clients and grid disks. After setting up database-scoped security among the database clients and grid disks, only those specific grid disks are available to the specified database clients.

When using database-scoped security, there is one key file per database per host, and one access control list (ACL) entry per database on each cell.

4.2 Understanding Operating System Security of Oracle Exadata Storage Servers

The security of the operating system on Oracle Exadata Storage Servers consists of the following:

  • Enforcing security policies

  • Protecting network access paths to the cells

  • Monitoring operating system-level activities

Oracle Exadata System Software includes security features to ensure the operating system and network access to the Oracle Exadata Storage Servers are secure.

4.2.1 Security Policies for Oracle Exadata Storage Servers

User access to the operating system can be secured by the use of secure, hardened passwords. The passwords for users who administer Oracle Exadata Storage Server Software adhere to the following security guidelines:

  • Passwords must be changed every 90 days.

  • Passwords cannot be changed within 24 hours of the last change.

  • Passwords must use at least three character classes. Character classes for passwords are digits, lowercase letters, uppercase letters, and other characters.

  • Minimum password length is 12 characters when using three character classes. Minimum password length is 8 characters when using four character classes.

    Note:

    Uppercase letters at the beginning of the password, and digits at the end of the password are not counted when calculating the number of character classes.

  • Passphrases are allowed. A passphrase should contain at least three words, be 16 to 40 characters in length, and contain different character classes.

  • Maximum password length is 40 characters.

  • A new password cannot be similar to the existing password.

  • A user account is temporarily locked for 10 minutes after one failed login attempt.

  • A user account is locked after five failed attempts.

  • A log in session will terminate after 14400 seconds of no input.

  • An SSH session will terminate after 7200 seconds of inactivity.

4.2.1.1 Changing a Password

Users are notified of the need to change their passwords 7 days before the expiration date. To change a password, use the following command:

passwd username

In the preceding command, username is the user name. The following is an example of the command:

passwd celladmin

4.2.1.2 Enabling the Security Policies

The/opt/oracle.cellos/RESECURED_NODE file enables the security policies. If the file does not exist, then do the following:

  1. Shut down the Oracle Grid Infrastructure services on all database servers.
  2. Shut down the cell services using the following command:
    cellcli -e alter cell shutdown services all
    
  3. Run the following script to set the security policies:
    /opt/oracle.SupportTools/harden_passwords_reset_root_ssh
    

    The preceding command restarts the cell. After the cell is up, you need to set a new password.

  4. Set a new password.

4.2.1.3 Viewing Failed Password Attempts

To view failed password attempts, use the following command:

/sbin/pam_tally2

4.2.1.4 Resetting a Locked User Account

If a user account has 5 failed login attempts, then the account is locked.

To reset an account, use the following command:

/sbin/pam_tally2 --user username --reset

In the preceding command, username is the name of the user that has the locked account.

4.2.1.5 Modifying Password Policies on the Database Servers

The password policies cannot be modified for Oracle Exadata Storage Servers. They can be modified for the database servers. The following procedure describes how to modify the database server password policies:

  1. Modify the settings in the /etc/login.defs file to change the aging policies. The following is an example of the policies:
    PASS_MAX_DAYS 90
    PASS_MIN_DAYS 1
    PASS_MIN_LEN 8
    PASS_WARN_AGE 7
    
  2. Modify the character class restrictions by changing the values for the min parameter in the /etc/pam.d/system-auth file. The current min values are min=disabled,disabled,16,12,8. These values are in place after running the /opt/oracle.SupportTools/harden_passwords_reset_root_ssh script. A setting of 5,5,5,5,5 allows passwords to be as short as five characters, and removes character class restrictions.
  3. Reboot the database servers.

See Also:

Refer to the login.defs and passwdqc.conf man pages for additional information

4.2.2 Network Access to Oracle Exadata Storage Servers

Oracle Exadata Storage Server Software includes the cellwall service that implements a firewall on each cell. The service is located in the /etc/init.d/cellwall directory, and implements iptables firewall on the cell. In addition, the SSH server is configured to respond to connection requests only on the management network (NET0), and the InfiniBand network (BONDIB0).

To review the firewall rules, run the following command as the root user:

iptables --list

Note:

There is no firewall automatically configured for the database servers. Implement a set of iptables on the database servers to meet your network requirements for Oracle Exadata Database Machine.

4.2.3 Operating System Activity Monitoring on Oracle Exadata Storage Servers

Each Oracle Exadata Storage Server is configured with auditd to audit system-level activity. To manage audits and generate reports use the auditctl command. The audit rules are in the /etc/audit/audit.rules file. Any changes are not preserved when applying a patch set.

4.3 Understanding the cellkey.ora File

To set up security on the host computers that contain clients that access an Oracle Exadata Storage Server, you must configure the cellkey.ora file, and place the file on all the computers.

One cellkey.ora file is required for Oracle ASM-scoped security, and another cellkey.ora file is required for each database client using database-scoped security. The key file for Oracle ASM-scoped security has the same contents on all database servers. However, the contents of the key file for database-scoped security are different for each database client.

The cellkey.ora file contains entries that configure security among Oracle ASM, database clients and cells. The key and asm values in the cellkey.ora files on the Oracle ASM and database host computers must match the values assigned to the clients on the cells.

The cellkey.ora file contains the following fields:

  • key — This field is required.

    • For Oracle ASM-scoped security, this key must match the value of the key assigned to the Oracle ASM cluster with the CellCLI ASSIGN KEY command.

    • For database-scoped security, this key must match the value of the key assigned to the database client with the CellCLI ASSIGN KEY command.

  • asm — This field is required.

    This field must be unique among all the clusters that access the storage servers in the storage grid. This value is used in the ASSIGN KEY command run on each cell, and the ALTER GRIDDISK and CREATE GRIDDISK commands used to configure grid disks to allow access from only a specific Oracle ASM cluster.

    Note:

    The asm field is used for both Oracle ASM-scoped security and database-scoped security.

Example 4-1 cellkey.ora File Entries

This example shows the entries for the cellkey.ora file.

key=66e12adb996805358bf82258587f5050
asm=cluster1

4.3.1 About Security Keys

A security key is used to authenticate and protect messages between cells and the clients of the cells. The CellCLI CREATE KEY command generates a random hexadecimal string for use as a security key.

The CREATE KEY command can be run on any cell and only must be run when you need to create a new unique key.

  • For Oracle ASM-scoped security, you only run CREATE KEY once to create the single key necessary in that security mode.

  • For database-scoped security, create one security key for Oracle ASM and one security key for each database that use database-scoped security.

Example 4-2 Creating a Security Key for Oracle ASM-Scoped Security

CellCLI> CREATE KEY

         66e12adb996805358bf82258587f5050

4.4 Setting Up Oracle ASM-Scoped Security on Oracle Exadata Storage Servers

You can configure Oracle ASM-scoped security for grid disks on Oracle Exadata Storage Servers.

  1. Shut down the database and Oracle ASM instances that will have their security configuration changed.
  2. Use the CellCLI CREATE KEY command to generate a random hexadecimal string. The command can be run on any cell.
    CellCLI> CREATE KEY
    
    66e12adb996805358bf82258587f5050
    

    This key is used for the Oracle ASM cluster client and for the key entry in the cellkey.ora file.

  3. Copy the key to the cellkey.ora file using the format shown in Example 4-1.
  4. Use the ASSIGN KEY command to assign the security key to the Oracle ASM cluster client on all the cells that you want the Oracle ASM cluster to access. The following is an example of the command:
    CellCLI> ASSIGN KEY FOR 'unique_name_across_all_clusters' -
             ='66e12adb996805358bf82258587f5050'
    

    In the preceding command, unique_name_across_all_clusters is a unique and consistent value on the cell and cluster. The Oracle Clusterware cluster name can be used if the clusters have a unique name. A unique name must be used when assigning a key.

    You add the ASMCLUSTER keyword if you are using Oracle ASM-scoped security based on Oracle ASM clusters. In this case, you specify the Oracle ASM cluster name for the unique name parameter. For example:

    CellCLI> ASSIGN KEY FOR ASMCLUSTER 'Oracle_ASM_cluster_name' -
             ='66e12adb996805358bf82258587f5050'
    
  5. Enter the same name as in step 4, in the availableTo attribute with the CREATE GRIDDISK or ALTER GRIDDISK command to configure security on the grid disks on all the cells that you want the Oracle ASM cluster to access. The following are examples of the commands to create a new grid disk with security and to change security on existing grid disks:
    • Create new grid disk with security:

      CellCLI> CREATE GRIDDISK ALL PREFIX=sales, size=75G, -
               availableTo='unique_name_across_all_clusters'
      
    • Change security on existing grid disks:

      CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01,           -
               sales_CD_03_cell01,  sales_CD_04_cell01, sales_CD_05_cell01,     -
               sales_CD_06_cell01                                               -
               availableTo='unique_name_across_all_clusters'
      

    In the preceding commands, the unique_name_across_all_clusters is a unique and consistent value on the cell and cluster. When a value is entered for availableTo, then only the specified clients have access to the grid disk. If a value is not entered, then any client has access.

  6. Copy the cellkey.ora files for each ASM cluster to /etc/oracle/cell/network-config on each database node.
  7. Setup the permissions for the cellkey.ora in /etc/oracle/cell/network-config.
    chown grid:oinstall /etc/oracle/cell/network-config/cellkey.ora 
    chmod 600 /etc/oracle/cell/network-config/cellkey.ora
    
  8. Restart the following:
    • database and Oracle ASM instances

    • clusterware. The commands to stop and start the clusterware are:

      • crsctl stop crs

      • crsctl start crs

4.5 Setting Up Database-Scoped Security on Oracle Exadata Storage Servers

This section describes the database-scoped security configuration required for Oracle Exadata Storage Servers.

Before making updates to the security setups on cells, you must shut down the database and Oracle ASM instances. After you complete the steps in this section, you must ensure the key is formatted correctly, as described in "Understanding the cellkey.ora File". After the cellkey.ora file configuration is complete, start the database and Oracle ASM instances.

To set up database-scoped security, perform the following procedure:

Note:

You should only set up database-scoped security after configuring and testing Oracle ASM-scoped security.

When there is only one Oracle ASM cluster, then using availableTo=+asm is acceptable. If there is more than one cluster, then refer to "Setting Up Oracle ASM-Scoped Security on Oracle Exadata Storage Servers" to see how to set unique clusters.

  1. Get the database unique name (DB_UNIQUE_NAME) for each database. Note that the names are case-sensitive.
  2. Shut down the database and Oracle ASM instances that will have their security configuration changed.
  3. Use the CellCLI CREATE KEY command to create security keys for those database clients that you want to access specific grid disks. The command can be run on any cell. After running the command, the system displays the new key.
    CellCLI> CREATE KEY
    
    66e12adb996805358bf82258587f5050
    
  4. Copy the key to the cellkey.ora file using the format shown in Example 4-1.
  5. Use the ASSIGN KEY command to assign the keys to database clients on the cells that contain the grid disks, as shown in Example 4-3.
  6. Use the availableTo attribute with the CREATE GRIDDISK or ALTER GRIDIDISK command to configure security on grid disks. You must include the Oracle ASM cluster name with the database clients names when setting the value of the availableTo attribute. The names must be unique and consistent, usually the Oracle Clusterware cluster name.

    In Example 4-4, database-scoped security is configured when the grid disks are created with the use of the availableTo attribute. This attribute determines which specific clients are configured to access the grid disks.

    You can change security on existing grid disks with the ALTER GRIDDISK command, as shown in Example 4-5.

    Note:

    The availableTo='+asm' argument is mandatory.

  7. After the cellkey.ora file configuration is complete for all computers, restart the database and Oracle ASM instances.

    Refer to "Setting Up the cellkey.ora File on the Client Computers" for information about configuring the cellkey.ora file on the client computers.

Example 4-3 Assigning Keys to Database Clients

CellCLI> ASSIGN KEY FOR  'db1'='51a826646ebe1f29e33c6ed7c4965c9a',
                         'db2'='bd0843beeed5e18e6664576cf9805b69',
                         'db3'='6679ef9ec02fa664582c3464d4b0191f'

Example 4-4 Creating Grid Disks with Database-Scoped Security

CellCLI> CREATE GRIDDISK sales_CD_00_cell01, sales_CD_01_cell01 size=75G, -
         availableTo='+asm,db1'

CellCLI> CREATE GRIDDISK sales_CD_02_cell01, sales_CD_03_cell01 size=75G, -
         availableTo='+asm,db2'

CellCLI> CREATE GRIDDISK sales_CD_04_cell01, sales_CD_05_cell01 size=75G, -
         availableTo='+asm,db3'

Example 4-5 Altering Grid Disks to Configure Database-Scoped Security

CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01 -
         availableTo='+asm,db1'

CellCLI> ALTER GRIDDISK sales_CD_03_cell01, sales_CD_04_cell01 -
         availableTo='+asm,db2'

CellCLI> ALTER GRIDDISK sales_CD_05_cell01, sales_CD_06_cell01 -
         availableTo='+asm,db3'

See Also:

4.6 Setting Up the cellkey.ora File on the Client Computers

You can configure the cellkey.ora file on client computers.

Caution:

If file permissions are not set correctly for the cellkey.ora file, then access to the file is open and anyone can read it.

  1. Set up the cellkey.ora file on the Oracle ASM cluster for ASM-scoped security.
    1. Put the cellkey.ora file in the /etc/oracle/cell/network-config/ directory.
    2. Set the permissions on the file to be read-only.
      • If you use a single installation user for all Oracle software, then set the permissions on the file to be read-only by the owner.

      • If you use role-separated management, then set the permissions on the file to be read-only by the oinstall group that contains the installation users for both Oracle Grid Infrastructure (grid) and Oracle Database (oracle).

      chmod 600 /etc/oracle/cell/network-config/cellkey.ora
      
    3. Set the group to the Oracle ASM administration group.
      chown grid:oinstall /etc/oracle/cell/network-config/cellkey.ora
      
  2. Set up the cellkey.ora file for database-based security.

    You need a cellkey.ora file for each database, and the file would be different for each database. For example, if you have three databases, you would have four different cellkey.ora files: one for each database, plus another one for ASM.

    1. Put the cellkey.ora file in the $ORACLE_HOME/admin/db_unique_name/pfile directory.
    2. Change the ownership of the cellkey.ora file to the same user that owns the Oracle home for that database. The file should not be owned by the oinstall group, or any other global operating system group.
  3. If the database or Oracle ASM instances are started, then shut them down before proceeding.
  4. Create the cellkey.ora file on the client computers.

    A database client cellkey.ora must be located in the $ORACLE_HOME/admin/db_unique_name/pfile/ directory of the database client that you want to restrict access.

    The key value in this file must match the value of the key assigned to the database client. See Example 4-1 for an example of the file contents.

    The cellkey.ora key file must be only readable by the database client that owns the Oracle home.

  5. Restart the instances after you have created and edited the cellkey.ora files.

4.7 Enabling Cell-to-Cell Operations

If you have configured Oracle ASM-scoped security or database-scoped security in your Exadata environment, direct cell-to-cell operations may not work due to access control restrictions. To ensure cells have access to other cells when they need to communicate directly with one another, for example, for offload operations, you need to set up “cell keys” for each cell.

The following steps show how to create a cell key and assign the key to cells:

  1. Generate a random hexadecimal string. The command can be run on any cell.

    CellCLI> CREATE KEY
          fa292e11b31b210c4b7a24c5f1bb4d32
    
  2. Assign the key to each cell.

    CellCLI> ASSIGN KEY FOR CELL 'fa292e11b31b210c4b7a24c5f1bb4d32'
    

It is not necessary to make any grid disks “availableTo” the new key. The cells use the existing access control policy by making sure the originating client is identified at the remote target cell.

The steps above use a single key that is used for both inbound and outbound cell-to-cell traffic. The simple version of the ASSIGN KEY command is used.

You can configure your cells to accept multiple remote cell keys. This might be the case temporarily during rekeying, or perhaps you want to assign a unique key to each cell. In this case, you need to specify LOCAL or REMOTE in the ASSIGN KEY command.

The following command sets the cell key for the local cell:

CellCLI> ASSIGN KEY FOR LOCAL CELL mykey='fa292e11b31b210c4b7a24c5f1bb4d32'

The following command sets the cell keys that the local cell will accept:

CellCLI> ASSIGN KEY FOR REMOTE CELL -
          'cellkey1'='b67d5587fe728118af47c57ab8da650a', -
          'cellkey2'='118af47c57ab8da650ab67d5587fe728'

The name parameter does not have to be “cellkey1”, “cellkey2”, or “mykey”. You can specify any value for the name parameter, as long as it matches the name in the client’s cellkey.ora file.

Switching Between the Simple Format and the LOCAL/REMOTE Format

If you attempt to assign a LOCAL or REMOTE key to an existing cell key (that is, you have run the simple ASSIGN KEY FOR CELL format, and you want to switch to the explicit LOCAL or REMOTE format), you will get the following error: “CELL-02911: Remove existing CELL key before assigning LOCAL CELL key”. You must remove the cell key before assigning any new keys with the explicit LOCAL or REMOTE format. This is to protect you from inadvertently breaking your configuration by having different remote and local keys.

If you attempt to go the other way and run ASSIGN KEY FOR CELL when there is more than one existing remote cell key, you will get the following error: “CELL-02912: Remove all existing LOCAL and REMOTE CELL keys before assigning a CELL key. Use LIST KEY FOR CELL to show all LOCAL and REMOTE CELL keys, then use ASSIGN KEY to assign an empty value to each.” You must remove all existing LOCAL and REMOTE cell keys before assigning a simple cell key.

A key that is designated as LOCAL is implicitly also accepted from REMOTE cells, for ease of use and simpler configuration.

Listing the Cell Keys for a Cell

You use the LIST KEY command to show all the keys assigned to a cell:

CellCLI> LIST KEY
         db1    b67d5587fe728118af47c57ab8da650a
         asm1   118af47c57ab8da650ab67d5587fe728    ASMCLUSTER
         cell   fa292e11b31b210c4b7a24c5f1bb4d32    CELL

To show only cell keys, you can specify “FOR CELL” in the LIST KEY command:

CellCLI> LIST KEY FOR CELL DETAIL
         key:   fa292e11b31b210c4b7a24c5f1bb4d32
         type:  CELL

CellCLI> LIST KEY FOR CELL
       mykey     fa292e11b31b210c4b7a24c5f1bb4d32    LOCAL-CELL
       cellkey1  b67d5587fe728118af47c57ab8da650a    REMOTE-CELL
       cellkey2  118af47c57ab8da650ab67d5587fe728    REMOTE-CELL

4.8 Removing Security

This section discusses the removal of security from Oracle Exadata Storage Servers.

Note:

You must remove database-scoped security on a grid disk before removing Oracle ASM-scoped security.

Before making updates to the security on cells, you must shut down the database and Oracle ASM instances. After all of the changes to security configuration are complete, start the database and Oracle ASM instances.

4.8.1 Removing Database-Scoped Security

To remove database-scoped security on grid disks, perform the following procedure:

  1. Shut down the database and Oracle ASM instances.
  2. Remove any database clients named in the availableTo attribute of the grid disks for which you want to remove database-scoped security. Example 4-6 shows how to do this for a group of grid disks.
  3. If a database client is not configured for security with any other grid disks, then you can remove the key assigned to a database client with the CellCLI ASSIGN KEY command as follows:
    CellCLI> ASSIGN KEY FOR 'db_client'=''
    

    In the preceding command, db_client is the name of the database client. To the right of the equal sign are two single quote characters with no space between them.

  4. Remove the cellkey.ora file located in the $ORACLE_HOME/admin/db_unique_name/pfile/ directory for the database client.
  5. Remove the database from the from the availableTo attribute using the following command:
    ALTER GRIDDISK ALL availableTo='+asm'
    
  6. Restart the database and Oracle ASM instances.

Example 4-6 Removing Database Clients from Grid Disks

The following command removes all database clients from a group of grid disks:

CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01,                  -
         sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01,             -
         sales_CD_06_cell01                                                      -
         availableTo='+asm'

The following command removes specific database clients from a group of grid disks:

CellCLI> ALTER GRIDDISK sales_CD_04_cell01, sales_CD_05_cell01,                  -
         sales_CD_06_cell01, sales_CD_07_cell01, sales_CD_08_cell01,             -
         sales_CD_09_cell01,                                                     -
         availableTo='+asm,db2,db3'

Note:

If you want open security for the grid disks, then you must remove Oracle ASM-scoped security after removing the database-scoped security,

4.8.2 Removing Oracle ASM-Scoped Security

After you have removed database-scoped security, you can remove Oracle ASM-scoped security if you want open security for grid disks on cells.

  1. Shut down the database and Oracle ASM instances.
  2. Remove the Oracle ASM cluster client named in the availableTo attribute of the grid disks on cells, as shown in Example 4-7.
  3. If the Oracle ASM cluster client is not configured for security with any other grid disks, then you can remove the key assigned to the Oracle ASM cluster client with the CellCLI ASSIGN KEY command, as follows:
    CellCLI> ASSIGN KEY FOR 'asm_cluster'=''
    

    In the preceding command, asm_cluster is the name of the Oracle ASM cluster client.

  4. Remove the cellkey.ora file located in the /etc/oracle/cell/network-config/ directory on each computer host in the Oracle ASM cluster.
  5. Remove Oracle ASM from the availableTo attribute using the following command:
    ALTER GRIDDISK ALL availableTo=''
    
  6. Restart the database and Oracle ASM instances.

Example 4-7 Removing the Oracle ASM Cluster Client from Grid Disks

The following command removes the ASM cluster client from all grid disks on a cell:

CellCLI> ALTER GRIDDISK ALL availableTo=''

The following command removes the ASM cluster client from a group of grid disks:

CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01,       -
         sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01,  -
         sales_CD_06_cell01                                          
         availableTo=''

Related Topics

4.9 Creating Users and Roles

You can control which commands users can run by granting privileges to roles, and granting roles to users.

For example, you can specify that a user can run the list griddisk command but not alter griddisk. This level of control is useful in Cloud environments, where you might want to allow full access to the system to only a few users.

In Cloud environments, to run ExaCLI, users need to log in with a user name and password. Exadata's Management System (MS) authenticates the user credentials, then performs authorization checks on the commands issued by the user. If the user does not have the proper privileges to run a command, MS returns an error.

Users are required when running ExaCLI. ExaCLI enables you to manage cells remotely from compute nodes. When you run ExaCLI on a compute node, you need to specify a user name to use to connect to the cell node.

Password security key is encrypted using Password-Based Key Derivation Function 2 (PBKDF2) with HMAC-SHA1.

To set up users and roles, you would perform these steps:

  1. Create roles using the CREATE ROLE command.

  2. Grant privileges to roles using the GRANT PRIVILEGE command.

  3. Create users using the CREATE USER command.

  4. Grant roles to users using the GRANT ROLE command.

You can also revoke privileges from roles using the REVOKE PRIVILEGE command. To revoke roles from users, use the REVOKE ROLE command.

Related Topics

4.9.1 Creating Roles and Getting Information about Roles

Use the CREATE ROLE command to create roles. For example:

CellCLI> CREATE ROLE admin

To get detailed information about a role, use the LIST ROLE command. For example, the following command returns all the attributes for the admin role.

CellCLI> LIST ROLE admin ALL DETAIL

Related Topics

4.9.2 Granting and Revoking Privileges

  • Use the GRANT PRIVILEGE command to grant privileges to roles.

    The following example grants all privileges to users with the admin role.

    CellCLI> GRANT PRIVILEGE ALL ACTIONS ON ALL OBJECTS TO ROLE admin
    
  • You can revoke privileges from roles using the REVOKE PRIVILEGE command.

4.9.3 Creating Users

Use the CREATE USER command to create users.

The following command creates a user called "fred" with password "changeME123".

CellCLI> CREATE USER fred PASSWORD = "changeME123"

A newly created user does not have any privileges. You have to grant roles for the user to have any privileges.

Related Topics

4.9.4 Granting and Revoking Roles

  • Use the GRANT ROLE command to grant roles to users.

    The following example grants the admin role to user fred.

    CellCLI> GRANT ROLE admin TO USER fred
    
  • You can revoke roles from users using the REVOKE ROLE command.

Related Topics

4.10 Disabling SSH on Storage Servers

By default, SSH is enabled on storage servers. If required, you can "lock" the storage servers to block SSH access. You can still perform operations on the cell using exacli, which runs on compute nodes and communicates using https and REST APIs to a web service running on the cell.

When you need to perform operations that require you to log in to the cell, you can temporarily unlock the cell. After the operation is complete, you can relock the cell.

Two new cell attributes control cell locking:

  • accessLevelPerm : This attribute specifies the access level at which the cell runs by default. It is either remoteLoginEnabled or remoteLoginDisabled.

    • remoteLoginEnabled: SSH service is enabled. You can access the cell using ssh or exacli. This is the default value for accessLevelPerm.

    • remoteLoginDisabled: SSH service is disabled. You can access the cell only through exacli.

  • accessLevelTemp: The access level can be changed temporarily for a specified duration. Once the duration has expired, the access level reverts back to the accessLevelPerm value. You typically change the cell's access level when the cell needs a software update.

The access level persists across cell reboots.

4.10.1 Locking a Cell

You lock a cell by setting its accessLevelPerm attribute to remoteLoginDisabled.

You must use a user that has the privilege to alter the accessLevelPerm attribute.

  1. Grant the necessary privileges to a user.

    On the storage server, run these commands:

    cellcli> create role administrator
    cellcli> grant privilege all actions on all objects all attributes with all options to role administrator
    cellcli> create user celladministrator password=*
    cellcli> grant role administrator to user celladministrator
    
  2. Run ExaCLI as the celladministrator user and run the ALTER CELL command:
    $ exacli -l celladministrator -c exam08cel01
    Password=********
    
    exacli> alter cell accessLevelPerm = remoteLoginDisabled
    

4.10.2 Unlocking a Cell Temporarily

You can unlock a locked cell for a short period of time to perform operations such as maintenance or upgrades that require SSH login to the cell. You can specify the start time of this "temporary access window" and how long it should last by setting the cell's accessLevelTemp attribute. This attribute has the following properties:

Table 4-1 Properties of accessLevelTemp

Property Description

accessLevel

Specifies whether SSH is enabled (remoteLoginEnabled) or disabled (remoteLoginDisabled).

This value needs to be specified. There is no default value.

startTime

Specifies when the specified access level starts. The time is specified in the ISO 8601 format: "yyyy-MM-ddTHH:mm:ssZ".

You can also specify the keyword "now" to indicate that the specified access level should start immediately.

Default value: now

duration

Specifies how long the access level should last. The duration is specified in the following format:

[any number of digits, followed by d (for days)]

[any number of digits followed by h (for hours)]

[any number of digits followed by m (for minutes)]

Examples:

To specify 1 hour: 1h

To specify 90 minutes: 90m

To specify 1 day: 1d

To specify 1 day and 12 hours: 1d12h

Default value: 2h (2 hours)

reason

Specifies a reason for changing the access level, for example: performing an upgrade.

Default value: "none"

Examples:

1. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        duration="2h",                                                 -
        reason="Quarterly maintenance"))

2. The following example creates a two-hour temporary access window that starts immediately. The command uses the default values for start time and duration.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        reason="Quarterly maintenance"))

3. The following example creates a 30-minute temporary access window that starts immediately

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="now",                                               -
        duration="30m",                                                -
        reason="Quarterly maintenance"))

4. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM. The command uses the default duration value.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        reason="Quarterly maintenance"))

5. The following example extends the temporary access window created in example 4 above to 5 hours. Note that the start time has to match the window that is being adjusted.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        duration="5h",                                                 -
        reason="Quarterly maintenance window extended to 5 hrs - Joe"))

6. The following example deletes the temporary access window. If the temporary access window is currently active, it is closed immediately and the access level will be set back to the permanent access level. If the temporary access window is in the future and not yet active, it is cancelled.

exacli> alter cell accessLevelTemp=''

 

Note the following:

  • Only one temporary access window is allowed at any time. You will get an error message if you try to create a new temporary access window when one is already in effect.

    If the temporary access window is not yet active and is in the future, the newly created temporary access window will replace the one that is in the future.

  • To modify a temporary access window that is in the future and not yet active, simply run the "alter cell" command again with the new values.

  • To modify a temporary access window that is already in progress (for example, to extend the duration or to change the reason), run the "alter cell" command again with the updated duration and/or reason. The command must provide the exact start time of the existing temporary access window to modify. The (start time + duration) must be in the future.

4.10.3 Checking the Current Access Level

To see what the current access level is, run the following command:

exacli> list cell detail

Look at the values for the accessLevelPerm and accessLevelTemp attributes.

You can also run the following commands:

exacli> list cell attributes accessLevelPerm

exacli> list cell attributes accessLevelTemp

4.10.4 Alerts from the Management Server

A stateless alert is generated when the accessLevelPerm attribute is modified.

A stateful alert is generated when the accessLevelTemp window is created. An alert email is sent out when the accessLevelTemp window is activated. The alert is cleared when the window expires.