This chapter describes how to install ACSLS Release 8.5 in a Solaris environment.
Topics include:
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
As root, go to the Package installation directory (typically /opt/ACSLS_x.y.z)
To remove the package, follow the un-install instructions for the your specific installed release. For example, to remove the ACSLS release 8.4 package, execute the pkg_uninstall.sh script:
# ./pkg_uninstall.sh
The ACSLS user accounts still remain.
Remove ACSLS administrative accounts:
# userdel acsss # userdel acsdb # userdel acssa # userdel postgres # groupdel acsls # groupdel postgres
Reboot.
Ensure that a compatible version of Solaris is installed.
ACSLS Release 8.5.1 is designed to run on Oracle's Sun SPARC and X86 platforms running Solaris 11, Update 3, or Solaris 11, Update 4.
For Solaris 11, Update 3, Support Repository Update (SRU) 35 or later is required.
For Solaris 11, Update 4, Support Repository Update (SRU) 8 or later is required.
ACSLS Release 8.5.0 is designed to run on Oracle's Sun SPARC and X86 platforms running Solaris 11, Update 3. Support Repository Update (SRU) 35 is required.
The Oracle Solaris Product Pack can be obtained from the Oracle Software Delivery Cloud:
For installation procedures, refer to the Solaris installation publications.
Note:
ACSLS 8.5 was tested using the Entire Distribution selection for the Solaris installation. Oracle does not provide a minimum list of required packages for ACSLS. However, the Entire Distribution is recommended.If the Entire Distribution is not used, the Solaris installation may be missing a standard Solaris package required for correct ACSLS operation. If this occurs, acquire and install the missing package. Solaris packages can be obtained from http://pkg.oracle.com.
For example, to find and install a missing unixodbc package:
Visit http://pkg.oracle.com.
In the search field, type unixodbc and click the Search button. To see more than the latest version of the package, use Advanced Search options.
In the search results, the complete title of the package indicates the latest Solaris version,11.4:
library/unixodbc@2.3.4,5.11-11.4.0.0.1.14.0:20180814T170705Z
You can click the package name link to view version details including corresponding OS releases.
From your Solaris platform, click the Installation link to install.
Alternative installation tips:
Use the pkg command directly from the command line on the platform:
pkg install pkg://solaris/library.
The release is displayed:
/unixodbc@2.3.4,5.11-11.4.0.0.1.14.0:20180814T170705Z solaris
If that version is disallowed, supply the package name without the version:
pkg install pkg://solaris/library/unixodbc.
For more information, refer to "Adding and Updating Software in Oracle Solaris" in the Oracle Solaris Information Library.
Your Solaris installation should "Enable remote services" to ensure that network client applications are able to communicate with the ACSLS server.
If you select the Solaris "Secure by Default" installation option, then it is necessary to alter a network configuration property for rpc-bind. To do this:
Check the property setting:
# svccfg -s rpc/bind listprop config/local_only
If the local_only property setting is true, you must set it to false.
# svccfg -s rpc/bind setprop config/local_only=false
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.
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.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 rm -rf /opt/ACSLS_8.5.1
Unzip the compressed file. The extracted package set is found in the resulting ACSLS_8.5.1 subdirectory.
Create the user accounts and associated groups described in Table 2-1. For command examples, see Appendix A.
ACSLS 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 2-1 Required ACSLS User Accounts (Solaris)
| 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. For example, if the postgres user already exists, you must change its home directory to /usr/postgres/10-pgdg. The user shell should be /usr/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 ACSLS_8.5.0 or ACSLS_8.5.1 directory, run the pkg_install.sh utility:
./pkg_install.sh
Note:
During installation, thepkgadd utility may generate warning messages regarding existing home directories and associated user shell-related files (for example, /export/home/ACSSS, .profile, and .bashrc).
If you have previously cleared stale versions or files and set up home directories according to Table 2-1, please safely ignore these warnings and proceed with installation.
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.
Note:
Installation may take significant time based on network and server configuration settings.Enter the following command to inherit the ACSLS environment:
. /var/tmp/acsls/.acsls_env
As root, run the ACSLS install.sh utility:
cd $ACS_HOME/install ./install.sh
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
ACSLS can present logical libraries to client applications over a fibre connection. Any portion of an attached physical library can be represented as a (SCSI) fibre-attached library with a fibre target port. To implement this capability, you must have a QLogic fibre HBA. This step converts one or more QLogic HBA ports from their default initiator mode to target mode.
The utility asks:
Do you want to install support for Logical Libraries?(y/n)
Enter y if you are using logical libraries. Otherwise, enter n.
If you enter y, the utility asks:
The Logical Library features in ACSLS require target mode support.- required action: pkg install system/storage/scsi-target-mode-frameworkInstall the target mode package now? (y or n)?
Enter y to install the target mode packages.
Next, the install.sh routine probes the system for qualified HBAs, and then lists the ports it finds.
Select the desired port by the corresponding number. The port you choose must be connected to a remote HBA.
ACSLS can present logical libraries to client applications over a fibre connection. Any portion of an attached physical library can be represented as a (SCSI) fibre-attached library with a fibre target port. To implement this capability, you must have a QLogic fibre HBA. This step converts one or more QLogic HBA ports from their default initiator mode to target mode.
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 Solaris SMF 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 smce rmi-registry surrogate stmf weblogic
When the install.sh utility exits, ACSLS installation is complete.
Once ACSLS is installed, you can perform the following post-installation tasks:
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.0 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.