This chapter describes how to install ACSLS Release 8.5 in a Linux environment.
Topics include:
Note:
Logical libraries are not supported in the Linux environment.Perform the following tasks to prepare for ACSLS installation. Once you have completed these tasks, you are ready to install ACSLS 8.5.
If you are upgrading from a previous release and plan to use existing database and control files, you must export these files.
As user acsss, enter the following command:
db_export.sh -f /path/myExport
where myExport is the name of your export file.
Save both myExport and myExport.misc files to a non-volatile location.
If you are updating your operating system, then transfer these files to a remote machine for safe keeping.
For more information, refer to the ”Database Administration” chapter in the StorageTek ACSLS Administrator's Guide.
Remove any previous version of ACSLS. If this is a new installation with no previous version of ACSLS, then skip this step.
Ensure that you have exported the database, using the db_export.sh utility command.
Log in as user acsss.
Shut down all ACSLS services:
acsss shutdown
Remove any acsss, acssa, and acsdb crontab entries:
Login as user acsss; Execute a crontab -r; logout
Login as user acssa; Execute a crontab -r; logout
Login as user acsdb; Execute a crontab -r; logout
Remove the previous version of ACSLS for Linux:
yum remove ACSLS.x86_64
Remove the postgreSQL database:
yum remove PostgreSQL.x86_64
As user root, remove previously populated directories:
rm -rf /export/home/ACSSS (or other directory where you installed ACSLS)
rm -rf /export/home/SSLM (or other direcrtory)
rm -rf /export/home/Oracle (or other directory)
rm -rf /var/tmp/acsls
rm -rf /opt/ACSLS_8.4.0
rm -rf /opt/ACSLS_8.5.0
rm -rf /opt/oracle/postgresql-10
Reboot.
Ensure that a compatible version of Linux is installed.
ACSLS Release 8.5.0 is designed to run under Oracle Enterprise Linux releases 6.8 and 7.3
ACSLS Release 8.5.1 is designed to run under Oracle Enterprise Linux releases 6.8, 6.10, 7.3, 7.6, and 7.8
The Oracle Enterprise Linux Product Pack can be obtained from the Oracle Software Delivery Cloud:
Before installing a new version of Linux, check with your IT system administrator to obtain the following information. The graphical installer requires the kdelibs package, which is included in the Oracle Enterprise Linux Product Pack.
Hostname and IP address for the ACSLS server.
Gateway IP address and netmask for your network, as well as the primary and secondary DNS.
IP address.
Network proxy information, if available.
During the installation, several key software components are installed:
In this procedure, you install key software components, including the following:
GNOME desktop environment.
Internet support.
X Windows.
Resource Package Manager (RPM), Yellowdog Updater, and Modified (yum).
Java 7 or 8. If you are installing the ACSLS GUI, use the latest Java JDK/SE version. Refer to the ACSLS Product Information document for specific required Java versions.
Do not install (or enable) the following:
Software Development
Web Server
Database
Dial-up network
Note:
If your Oracle Linux install is missing a standard Oracle Linux package required for correct ACSLS operation, please acquire and install that package. Linux packages can be obtained fromhttps://yum.oracle.com.For example, to find and install a missing unixodbc package:
Visit https://yum.oracle.com.
Select the link corresponding to your Oracle Linux release. For example, Oracle Linux 6.
Select Latest i386 (for 32-bit ACSLS compliant packages), or other appropriate link to get a list of packages.
Type Ctrl-F to search the page, and then type unixodbc in the Search field.
Click the package name link to download an RPM of that package.
Install the RPM package.
Note:
There are alternative ways to acquire and install packages using yum on the command line.
If packages contain shared object libraries required by ACSLS, you must install 32-bit versions (for example, unixODBC).
If packages run a standalone process required by ACSLS, either 32-bit or 64-bit versions will work (for example, rpcbind).
If a package is not working as expected, or causes faults, you may need to install a different version of the package. Examples include:
rpcbind (Some versions don't restart after reboot. For example, rpcbind.x86_64 on Oracle Linux 7.3 uses the version 0.2.0-48.el7.)
Java (ACSLS has specific minimum supported versions for this and other packages. Refer to the ACSLS Product Information document for specific required Java versions.)
unixODBC (may have installed the 64-bit version instead of the required 32-bit version)
ACSLS 8.5 is designed to run in optional Security Enhanced Linux (SELinux) environments.
SELinux was merged into the Linux kernel in response to initiatives by the US National Security Agency. It provides access control to files, directories, and other system resources that go beyond the traditional protection found standard in UNIX environments. In addition to owner-group-public permission access, SELinux includes access control based on user role, domain, and context. The agent that enforces access control over all system resources is the Linux kernel.
To set SELinux enforcement:
As user root, use the setenforce command to enable or disable SELinux enforcement.
setenforce [Enforcing | Permissive | 1 | 0 ]
Specify Enforcing or 1 to enable enforcement.
Specify Permissive or 0 to disable enforcement.
Verify the SELinux enforcement status:
getenforce
Note:
This command requires that SELinux is enabled. Use the command sestatus to view the status of SELinux.
To view the current system enforcement status, use the command getenforce.
Three SELinux policy modules are loaded into the kernel when you install ACSLS: allowPostgr, acsdb, and acsdb1. These modules provide the definitions and enforcement exceptions that are necessary for ACSLS to access its own database and other system resources while SELinux enforcement is active. With these modules installed, you should be able to run normal ACSLS operations, including database operations such as bdb.acsss, rdb.acsss, db_export.sh and db_import.sh without the need to disable SELinux enforcement.
If problems occur, you may need to disable SELinux or run in permissive mode. For more information, refer to the "Troubleshooting" appendix in the StorageTek ACSLS Administrator's Guide.
Specific automated schedules known as crontabs are created for users acsss and acsdb when you run the install.sh utility. These crontabs are provided for ACSLS database maintenance backup activities.
An optional file, /etc/cron.allow (or /etc/cron.d/cron.allow on some systems) may exist on the system. This file controls which users are allowed to run the crontab command. If cron.allow exists, then user IDs for acsss and acsdb must be included in that file before you run install.sh. Otherwise, crontab creation for these users fails.
The file cron.deny exists by default on most systems. Any users listed in this file are explicitly denied access to the crontab command. Make sure that users acsss and acsdb are not contained in the cron.deny file.
Note the following access privilege considerations:
ACSLS 8.5 may be installed in any local file system. The ACSLS base directory and backup directories (for example, /export/home and /export/backup) must be mounted to allow SETUID so that user acsss can run as root. Super user access is required for scripts that start and stop ACSLS services and for scripts that collect diagnostic information for a support call.
The acsss umask is set to 027 during installation.
Network services, specifically rpcbind, must be enabled to allow ACSLS client communication unless the firewall security on ACSLS and all ACSAPI clients is configured without the need for the portmapper. For more information, refer to "Firewall Security" in the StorageTek ACSLS Administrator's Guide.
Adjust Linux tuning settings for your configuration. See "Linux and ACSLS Tuning Settings".
To download and unzip the ACSLS 8.5 package:
Start a web browser on the system and visit the Oracle Software Delivery Cloud:
Click Sign In and enter the user name and password provided by your Oracle Support representative.
In the search field, enter acsls and select StorageTek Automated Cartridge System Library Software (ACSLS).
In the search results, select ACSLS release level 8.5.0.0.0 or 8.5.1.0.0 to add it to the cart.
Click Selected Software to view the cart.
On the Selected Software screen, select your desired platform and click Continue.
On the Oracle Terms and Restrictions screen, review and accept the terms of the licenses. Click Continue.
Click Download and save the zip file to a common installation directory, typically /opt.
Before extracting the ZIP file, remove any previously installed versions of ACSLS installation directories. For example:
rm -rf /opt/ACSLS_8.4.0 rm -rf /opt/ACSLS_8.5.0
Unzip the compressed file. The extracted package set is found in the resulting ACSLS_8.5.0 or ACSLS_8.5.1 subdirectory.
After Linux installation, add specific packages required for ACSLS from the Oracle yum repository.
If your ACSLS server is behind a firewall, you may need to configure your ACSLS Linux system to use a local proxy server.
Edit /etc/yum.conf to update the local proxy server:
yum/conf
Proxy=http://your local proxy server
http_caching=packages
Edit /etc/wgetrc to update proxy and caching parameters:
wgetrc
#You can set the default proxies for wget to use for http, https, and ftp.
#They will override the value in the environment.
http_proxy=http://your local proxy server
# Remove the comment sign (#) from this line:
#use_proxy=on
Configure yum to use the Oracle repository for the correct architecture.
Linux 6.8 or 6.10:
Copy the provided yum repository file to /etc/yum.repos.d/.
Note:
There should be only one file in this directory,public-yum-ol6.repo.Linux 7.3, 7.6, or 7.8:
Copy the provided yum repository file to /etc/yum.repos.d/.
Note:
There should be only one file in this directory,public-yum-ol7.repo.Edit the file /etc/yum/pluginconf.d/refresh-packagekit.conf and set enabled=0 to disable the yum packagekit refresh (Linux 6.8 or 6.10 only).
With these pre-requisites completed, you are now ready to install the ACSLS 8.5 package.
Create the user accounts and associated groups described in Table 3-1. For command examples, see Appendix A.
ACSLS 8.5 allows for a user-defined home directory for the ACSLS application. The parent directory of each user home directory is referenced by the variable, $installDir.
Note:
It is your responsibility to define any required user account attributes such as passwords, based upon your specific configuration and processes.
ACSLS user accounts (acsss, acsdb, and acssa) must execute .profile when logging in. In some instances, .bash_profile will override .profile for bash shell user accounts.
If you use directories that cross external NFS or ZFS mount points, ensure that root level privileges extend across the mount points. Without these root level privileges, ACSLS installation may fail, or post-installation functionality issues may occur.
Table 3-1 Required ACSLS User Accounts (Linux)
| User Account | Group Assignment | Home Directory | Command Shell | Description |
|---|---|---|---|---|
|
acsss |
acsls |
Default example: Ownership/Permissions:
|
/bin/bash |
ACSLS control user |
|
acssa |
acsls |
Default example: Ownership/Permissions:
|
/bin/bash |
ACSLS SA user |
|
acsdb |
acsls |
Default example: Ownership/Permissions:
|
/bin/bash |
ACSLS DB user |
|
postgres |
postgres |
Ownership/Permissions:
Note: Ensure that permissions for directory |
/bin/bash |
postgres user |
|
root |
no requirement |
standard root Ownership/Permissions: |
/bin/bash |
root user |
If the user accounts already exist and are locked, you must unlock each account before you install the package.
For example, to check if the acsss account is locked:
# passwd -S acsss acsss LK
LK indicates that the account is locked. To unlock the account:
# passwd -u acsss
If these user accounts exist on an LDAP or NIS server and the root user on the local machine lacks usermod authority on the LDAP or NIS server, then manual intervention by the system administrator is required to complete the ACSLS installation. Make sure the users are reassigned to the acsls group and their home directories conform as stated above. The user shell should be bin/bash.
Perform the following tasks to install ACSLS:
Ensure that you have completed all pre-installation tasks described in "Preparing for Installation".
Log in as user root.
From the /opt/ACSLS/ACSLS_8.5.0 or /opt/ACSLS/ACSLS_8.5.1 directory, run the pkg_install.sh utility:
./pkg_install.sh
The utility prompts you to enter the full path directory for the installation.
Enter a desired directory path, or press Enter to accept the default path (/export/home). If the directory you specify does not exist, the script prompts for permission create the directory.
The utility lists additional packages required by ACSLS and asks:
OK to install (y/n):
Enter y to install the additional packages and continue with installation, or n to terminate the installation.
When you enter y, installation begins. Progress is displayed on screen. Installation may take significant time based on network and server configuration settings. pkg_install.sh relies on yum to install ACSLS and various dependencies. In addition to installing additional required packages, the utility also verifies the required user accounts and groups.
Once pkg_install.sh has completed, enter the following command to inherit the ACSLS environment:
. /var/tmp/acsls/.acsls.env
As user root, enter the following commands to run the ACSLS install.sh utility:
cd $ACS_HOME/install ./install.sh
The install.sh utility asks:
Core dump files help diagnose issues when they occur. To do this the following will be modified: - File permissions /var/crash will be changed - core_pipe_list,core_uses_pid, core_pattern, suid_dumpable will be modified - sysctl.conf will be modified, original one stored as .orig - limits.conf will be modified, original one stored as .orig - ulimit core updated - service abrtd will be started Can we make the above changes to enable core dump files on your server? (y or n):
Enter y to enable the core dump feature. with this feature enabled, ACSLS processes that encounter a SEGV fault will generate a core dump and place it in the /var/crash directory. These core dump files are helpful in diagnosing issues with ACSLS. Provide these files to Oracle Support when they become available.
If you enter n, core dumps will not be generated.
To disable the core dump feature, enter the following commands:
ulimit -c 0 cp /etc/security/limits.conf.orig /etc/security/limits.conf cp /etc/sysctl.conf.orig /etc/sysctl.conf
To enable the core dump feature at a later time, re-run install.sh or use the following procedure:
Log in as user root.
Enter the following commands:
. /var/tmp/acsls/.acsls_env cd /export/home/ACSSS/bin ./enableLinuxDumps.sh
Note:
If you choose to enable the core dump feature, you must regularly monitor and manage your core dump files to ensure that they do not consume all available disk space on the ACSLS server.The utility asks:
Do you wish to host the ACSLS Graphical User Interface? (y/n)
The ACSLS GUI is an optional feature. If you are co-hosting ACSLS with another application that uses WebLogic, enter n and then proceed with ACSLS installation.
Otherwise, enter y to install the GUI.
Note:
Ensure that you have installed the latest version of the Java Development Kit (JDK) on your ACSLS server. See "ACSLS GUI Requirements".
If ACSLS installation fails during installation of the GUI, review the logs in ACSSS/log/sslm. These logs provide information as to why the GUI failed, in particular the weblogic.log.
If this is a minor update or configuration change (not a new installation) your ACSLS GUI may already be installed.
In this case, you have the option to re-install the GUI or to skip this section and retain the current ACSLS GUI domain.
The utility asks:
The Acsls GUI Domain exists. Do you want to re-install it? (y/n)
Enter y if you are installing a new ACSLS release.
The WebLogic server package is extracted and the default GUI admin user account is created with the user name, acsls_admin.
You are then asked to assign a password for the admin user. The password must be between eight and sixteen characters using both alpha and numeric characters.
The installation procedure unpacks and deploys the ACSLS GUI application and then creates the Acsls user group. At a later time, you can add GUI users to this group using the administrative tool, userAdmin.sh.
If you enter n, you have the option to remove the existing GUI configuration.
When you install WebLogic on your ACSLS server, a simple 512-bit public key is automatically available to support basic https exchanges with client browsers. Normally, no further configuration should be necessary. However, some browsers, notably the Microsoft Internet Explorer, require a lengthier key of no less than 1024 bits. See "Configuring a Self-Signed Digital Certificate for HTTPS" for a description of and procedures for configuring an SSL encryption key.
The utility asks:
Which file system will be used to store database backups? [/export/backup]
Enter a desired directory path where you intend for database backup files to reside, or press Enter to accept the default path.
If your desired directory does not exist, you must first create it. The directory must be owned by root with permissions set to 755.
Note:
Ensure that permissions for directory/opt/oracle are set to 755 to avoid ACSLS database installation failures related to postgreSQL.The utility asks:
Shall we install the mchanger driver for fibre-attached libraries? (y/n)
Enter y if your library environment includes a fibre-attached library such as the SL500 or SL150 library. Otherwise, enter n.
If you enter y, the routine scans the attached SAN environment, looking for any StorageTek library devices. It reports the devices it finds and asks whether any additional libraries are attached. If you have an older SCSI attached L700 or L180 library, respond y to the prompt.
For SCSI attached libraries, simply enter the target:lun address for each library, separating them by a space. For example:
==> 4:0 5:0 5:1
If you choose not to install the GUI or logical library support features, then the utility asks:
Shall we install the optional lib_cmd interface (y or n):
This optional feature is a command-line interface that performs many of the same operations available in the ACSLS GUI. While many lib_cmd operations apply to logical library functions, this feature is also useful for displaying the status of physical libraries, volumes and drives.
The lib_cmd feature installs automatically when you choose to install either the GUI or logical library support.
Enter y if you wish to install this feature.
Depending on the set of features that you have selected in the above installation dialog, this final step installs Linux init.d services to control the automatic start, stop, and status functions for each selected ACSLS feature.
The service list includes any subset of the following:
acsdb acsls rmi-registry surrogate weblogic
When the install.sh utility exits, ACSLS installation is complete.
Once ACSLS is installed, you can perform the following post-installation tasks:
Set recommended ACSLS tuning settings for your configuration. See "ACSLS Tuning Settings".
The optional XML API (XAPI) service is an API that enables Enterprise level mainframe clients and servers to communicate using a common Enterprise Library Software (ELS) protocol over TCP/IP. ACSLS 8.5 and later releases can be configured with XAPI support.
To install the XAPI component:
Ensure you have installed the ACSLS package and run install.sh to finish the ACSLS installation.
Ensure you are logged in to the ACSLS server as root.
Source key ACSLS environment variables:
. /var/tmp/acsls/.acsls_env
(Note the required period and space before /var/tmp/acsls/.acsls_env).
Install the XAPI component:
cd $ACS_HOME/install ./install_xapi.sh Installing the XAPI component for Oracle IBM mainframe clients. Continue? (y)
Database and control files are customized files, user preferences, and local configuration files that are unique to your specific ACSLS environment.
If you exported existing database and control files before installing ACSLS 8.5, as described in "Step 1: Export Existing Database and Control Files", you can use the db_import.sh utility to import them once ACSLS 8.5 is installed.
Refer to the "Database Administration" chapter in the StorageTek ACSLS Administrator's Guide for this procedure.
After installing a new ACSLS release, you want to test it before using it to manage production libraries. If a test library environment is not available, this can be difficult because normally ACSLS must be configured to a library, and the library must be online for ACSLS to come up.
If you do not have a configured library or library partition available in a test environment, you can test a new ACSLS release in a limited way without having a test library for ACSLS to access. To do this:
Install the new ACSLS release on a separate server.
Export the database and control files from a production library environment using the db_export.sh utility. Refer to the StorageTek ACSLS Administrator's Guide for details.
Note:
ACSLS must be down to export the database and control files.Import the database and control files into your new ACSLS release using db_import.sh.
On your new ACSLS system, ensure that ACSLS does not try to connect to the imported library configuration. The ACSs and ports must stay offline to ACSLS.
Otherwise, both the new ACSLS system and production system try to connect to the library, disconnecting the other system, and then in turn being disconnected by the other system. This repeats until one of the ACSLS systems is shut down.
To keep all ACSs and port connections offline:
Modify the acsls_startup_policy file, in $ACS_HOME/data/external/.
Uncomment the line for each ACS that is configured in the imported database. Look at the comment header of acsls_startup_policy for details.
For example, to prevent ACSLS from trying to bring ACS 0 online, change:
# ACS0_desired_startup_state_is_offline
to
ACS0_desired_startup_state_is_offline
Test to ensure that ACSLS comes up and runs, exercising a limited set of commands.
Do not vary ports or ACSs online. If you do, you will halt library communication from your production ACSLS system.
Commands that send requests to the library will fail because the library is offline. However, ACSLS will continue to run and process requests.
Commands that do not rely on library resources work. These include submitting these commands using the ACSAPI from host applications:
query
display
define pool and delete pool
idle and start
lock and unlock
set commands, except for set cap mode which will fail because the library is offline.
Utilities that do not rely on library resources work. These include:
acsss commands such as acsss enable, acsss disable, acsss status.
bdb.acsss and rdb.acsss
db_export.sh and db_import.sh
Note:
db_import.sh overlays the acsls_startup_policy file. If this is a production system, this allows libraries to come online. Modify the acsls_startup_policy file before starting ACSLS.dv_config
drives_media.sh
free_cells.sh
userAdmin.sh
volrpt
watch_vols
The ACSLS GUI will display library resources. However, commands such as mount, dismount, enter, and eject which requires library resources will fail.
To verify the ACSLS installation:
Ensure that your library is configured.
Follow the instructions provided in the ACSLS Administrator's Guide to use
acsss_config to configure ACSLS and create a database image of your library.
Note:
If you plan to use the SL4000 library, before runningacsss_config, ensure that you have completed the following library configuration tasks using the SL4000 GUI:
Define an SL4000 library certificate, including the Library Name (CN). This name must match that used in acsss_config and config new acs. If using a host name (DN), not an IP address, it must also resolve to the same exact name.
Define an SL4000 user that the ACSLS SCI interface can use to connect to the SL4000 library.
Ensure that the SL4000 library is SCI capable, or has an SCI capable partition.
Ensure ACSLS server time and SL4000 library time are synced within a couple minutes of each other.
Refer to the ACSLS Administrator's Guide for more information about these tasks.
Log in as user acsss.
Run the acsss enable command to start ACSLS.
Run cmd_proc.
From cmd_proc, query the server:
Verify that the following are online:
query port all query acs all query lsm all query cap all query drive all
At least one of each must be online. If necessary, use the vary command to bring them online.
Audit the library.
Refer to "Auditing the Library" in the StorageTek ACSLS Administrator's Guide.
Do you have at least one cartridge in an LSM?
YES - Continue with the procedure.
NO - Enter a cartridge into an LSM.
List available volume and drive IDs.
query vol all query drive all
Mount a volume:
mount vol_id drive_id
where vol_id is the volume ID and drive_id is the drive ID.
Refer to the StorageTek ACSLS Administrator's Guide for more information.
Do you see a message indicating a successful mount?
A successful mount message is:
Mount: vol_id mounted on drive_id
YES - Procedure is complete.
NO - If an error message appears, run this verification procedure again, ensuring that you specified a valid, available drive and a library cartridge. If the mount continues to fail, contact Oracle Support for assistance.
Dismount the cartridge by entering:
dismount vol_id drive_id force
where vol_id is the volume and drive_id is the drive you mounted earlier in the procedure.
The verification procedure is complete.