ACSLS 8.4 has been developed and tested for the following Solaris environments:
Oracle Solaris 11 Update 2 (ACSLS 8.4 base through patch 8.4.0-2)
Oracle Solaris 11 Update 3 (requires ACSLS 8.4 patch 8.4.0-2 or later)
For ACSLS patch installation instructions, refer to the README.txt file included with the patch.
Note:
Only run theinstall.sh
script after the patch has been applied. This is true for both patches 8.4.0-2 and 8.4.0-3, which modify the installation requirements and behavior in that script.This chapter includes the following topics:
In addition to the Oracle Right to Use License for ACSLS, this product contains numerous third-party software components, each with its own license criteria. Read the THIRDPARTYLICENSEREADME.txt agreement located in the ACSLS_8.4.0 installation directory. For software components whose license requires re-distribution of the source code, you can find that source code under the initial package installation directory, ACSLS_8.4.0 (typically under /opt
). Look in the subdirectory, acsls_thirdPartySoftware/
.
If you are upgrading from a prior release, you must export the database and control files. As user acsss, run the command:
db_export.sh -f /path/to/my/export/file
In the example above, myExport
is the name you assign to your export file. A second file with a .misc
extension is also created. You should save myExport
and myExport.misc
to a non-volatile location. If you are updating your OS, then transfer these files to a remote machine for safe keeping.
For more information and procedures, refer to Exporting the Database in the ”Database Administration” chapter of the StorageTek ACSLS 8.4 Administrator's Guide.
If you have created additional ACSLS GUI users on ACSLS 8.1 or later releases, record those user IDs so you can re-add them after installing the new version of ACSLS. To do this:
As user acsss
:
cd $ACS_HOME/install
Type su root
.
Do not type su - root
to retain your acsss
environment.
Run ./userAdmin.sh
to get a list of existing users of the ACSLS GUI:
Select the List Users option and then the Exit option when you have finished.
Record the user IDs so you can re-add them later as described in "Adding Users of the ACSLS GUI".
This section describes the steps to install Solaris.
For installation procedures refer to the Solaris Installation instructions.
ACSLS 8.4 was tested using the Entire Distribution selection for the Solaris install. Oracle does not provide a minimum list of required packages for ACSLS, but the Entire Distribution is recommended.
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
ACSLS 8.4 may be installed in any file system. The ACSLS base and the ACSLS backup directories (for example, /export/home
and /export/backup
) must be mounted to allow SETUID
so 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, see the ACSLS Administrator's Guide, "Firewall Security Option" for details.
Three ACSLS user accounts, (acsss
, acssa
, acsdb
) are added automatically when you install the ACSLS package.
The package install creates an acsls
group and assigns all three users to this group. It also adds root
to the acsls
group.
If user accounts for the three acsls users already exist, the user home directory and group id will be adjusted automatically (if necessary) by the package install routine.
ACSLS 8.4 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
. The user home directories for ACSLS are:
acsss $installDir/ACSSS acssa $installDir/ACSSA acsdb $installDir/acsdb/ACSDB1.0
If user accounts already exist for these users and you are changing the $installDir
, then these users must be logged out of the system during the installation since their home directory will change.
If the user accounts already exist and they are locked, they must be unlocked before you install the package.
To check if the acsss
account is locked:
# passwd -s acsss acsss LK
The "LK" tells you that the account is locked. To unlock the account:
# passwd -u acsss
Do this for each user account.
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 needed to complete the ACSLS installation. Make sure the users are re assigned to the acsls
group and their home directories conform as stated in the fourth bullet. The user shell should be: /bin/bash
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.d/cron.allow
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 fail.
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 acsss
and acsdb
are not contained in the cron.deny
file.
If you are upgrading from an earlier version of ACSLS be sure to preserve your existing database which includes the library configuration and the tape cartridge locations inside the library. As user acsss
:
$ acsss db $ db_export.sh -f /path/to/a/safe/location
A typical ACSLS installation may involve an OS upgrade. Ensure the two export files are stored to a remote location where they are preserved during the upgrade
Remove the ACSLS package.
As user acsss
, bring down ACSLS.
$ acsss shutdown
As root
, go to the Package installation directory (typically /opt/ACSLS_
x.y.z
)
On Solaris, to remove the package, execute the un-install script.
# ./pkg_unistall.sh
On Linux, use rpm
to remove the package.
# rpm -e ACSLS
For ease of re-installation, not all ACSLS files are removed. The ACSLS user accounts and some directories still remain.
To remove the GUI user accounts and other files left behind, use:
# cd $installDir # rm -rf ACSSS ACSSA acsdb SSLM
To remove ACSLS administrative accounts:
# userdel acsss # userdel acsdb # userdel acssa
ACSLS 8.4 installs in any directory. Determine the base install directory where the ACSLS application should reside. If that directory does not exist, you should create it before installing the STKacsls package. The directory must be owned by root
with permissions set to 755
.
Note:
Unless otherwise specified by the user, ACSLS will be installed in/export/home
.To follow the default installation procedure:
Go to the Oracle Software Delivery Cloud, and find the ACSLS_8.4.0 software bundle available for both SPARC and X86 platforms.
Download the appropriate software bundle to a common installation directory, typically /opt
, and unzip the compressed file. The extracted package set is found in the resulting ACSLS_8.4.0
subdirectory.
PostgreSQL 8.3 installs automatically when you install ACSLS 8.4. If you prefer to install PostgreSQL 8.4 (see "Installing PostgreSQL"), download the postgresql.xxx.bz2
file to your install directory (typically /opt
) before running the package install script in the next step.
Go into the ACSLS_8.4.0
directory and run the command:
./pkg_install.sh
The pkg_install
script first prompts you to confirm your intent to install ACSLS 8.4.
A number of packages are included with the ACSLS 8.4 installation bundle. They include STKacsls
and five postgres
packages that support PostgreSQL.
On Solaris 11 the specific postgres
packages are not already installed, so they are installed automatically when you run the pkg_install
script. Review the license for each package and respond y to accept the package.
Before installing the STKacsls package, the script prompts you (y/n) whether to accept /export/home
as the default base directory for the ACSLS application.
If you answer n, the script asks you to enter the desired path to the package base directory. If the directory you specify does not exist, the script prompts for permission create the directory.
When the package installation is complete, you find that the packages in
ACSLS_8.4.0
have been moved to /var/spool/pkg
. They remain there for ease of re-installation until they are manually removed. What remains in
ACSLS_8.4.0
is pkg_install.sh
, pkg_uninstall.sh
, and README.txt. You can use these scripts to uninstall or re-install ACSLS at any time. Any SUNWpostgr 8.3
packages that were not installed will also remain in this directory.
The package installation utility creates user and group IDs for the following users: acsss
, acssa
, and acsdb
. It assigns home directories for these users and places them in the acsls
group. The root
user is also added to the acsls
group.
When upgrading from a prior ACSLS version, determine whether you intend to change the installation directory. ACSLS users should be logged out whenever their home directory is likely to change.
Note:
Secure administration practices recommend that you to set initial passwords for these users immediately after the package installation.Once the ACSLS packages are installed, root
needs to inherit the ACSLS environmental attributes. To do this, log out and log back in, or simply
su -
to inherit the acsls
group identity. Verify with the groups
command.
su - # groups root acsls
(other groups may be listed)
To set your shell to the ACSLS installation environment, source the.acsls_env
file:
. /var/tmp/acsls/.acsls_env
This step enables you to refer to $ACS_HOME
during subsequent installation operations.
Proceed to "Running install.sh".
PostgreSQL 8.3 installs by default with ACSLS 8.4. Run pkg_install.sh
and no further action is necessary. PostgreSQL 8.3 is completely compatible with ACSLS 8.4.
ACSLS 8.4 is also compatible with PostgreSQL 8.4. If you prefer to install a recent update of PostgreSQL 8.4, simply download the bz2 bundle (postgresql-8.4.xx-S11.<
platform
>-32.tar.bz2
) from the PostgreSQL website to the install directory (typically /opt
) where you downloaded the ACSLS 8.4 zip bundle. The ACSLS install script (pkg_install.sh
) recognizes what you have downloaded and installs it automatically.
To obtain a recent update to PostgreSQL 8.4, go to the following website:
http://www.postgresql.org/ftp/binary/
From this URL you get a listing of all PostgreSQL releases. You should select the latest maintenance level for version 8.4. Be sure to get the 32-bit version that is compatible with your server architecture. Navigate to the download file and select in the following order:
v8.4.xx
binary
solaris
solaris11
sparc or i386
postgresql-8.4.xx-S11.<platform>-32.tar.bz2
Be sure to select the 32-bit version.
Move the postgresql bz2
file to the parent directory of this package install directory (typically /opt
). The ACSLS_8.4.0 installation script, pkg_install.sh
, automatically installs the compressed PostgreSQL file that you downloaded, and moves it to the proper file system directory, /usr/postgres/8.4
.
If the PostgreSQL-8.4 tar
or bz2
file is not found, and if PostgreSQL 8.3 or 8.4 is not already installed in /usr/postgres/
, the pkg_install.sh
script installs the four SUNWpostgr-83
packages included in this directory. It then moves them to /var/spool/pkg
where they are installed using pkgadd
.
The install.sh
utility enables you to select from the extracted ACSLS 8.4 package the specific features required for your unique Oracle StorageTek library environment. Flexibility has been added in ACSLS 8.4, allowing you to choose whether to install options including the Graphical User Interface (GUI) and fibre library support. You can run this utility to install the entire product, any portion of the product, or to alter an already-installed product without the need for a full installation.
While you are still logged in as root
, run the commands:
cd $ACS_HOME/install ./install.sh
Database creation is first step in the install.sh
routine. This step is necessary if you are installing the package for the first time. If your ACSLS database already exists and you do not want to rebuild it, then you have the option to skip this step. This step creates a new database under PostgreSQL and establishes an automated schedule for database backups.
Determine the directory where you intend for the database to reside. If that directory does not exist, then you must first create the directory. The directory must be owned by root
with permissions set to 755
. Unless you specify otherwise, the backup directory will be placed directly under your base directory. See step-1(c) in "Installing the ACSLS Package".
The install.sh
routine asks:
Which file system will be used to store database backups? [/export/backup]
Click Return to select the suggested directory, or specify a different directory. If you assign a relative path, it is placed directly under the desired path that you assigned in step-2 in the section, "Installing the ACSLS Package".
The install routine proceeds to load policy modules. These allow the ACSLS application to freely access its PostgreSQL database.
The mchanger driver is relevant only to fibre-attached or SCSI-attached library configurations. The install.sh
routine asks:
Shall we install the mchanger driver for fibre-attached libraries? (y/n)
Respond with y or n whether your library environment includes a fibre-attached library such as the SL500 or SL150 library.
If you enter y, the routine scans the attached SAN environment, looking for any StorageTek library devices. It reports the devices it finds and prompts 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 install.sh
routine probes the system for qualified HBAs, and then lists the ports it finds with the following prompt:
Please select the HBA port you intend for Target-mode operation: 1) HBA Port WWN xxxyyyzzz Not connected 2) HBA Port WWN aaabbbccc Connected to a remote HBA
Select the desired port by the corresponding number. The port you choose must be connected to a remote HBA.
The Graphical User Interface (GUI) is an option.
If you are co-hosting ACSLS with another application that uses WebLogic, do not install the ACSLS GUI. To install the GUI:
Enter y at the following prompt:
Do you want to install the ACSLS Graphical User Interface? (y/n)
If this is a minor update or configuration change (not a new installation) your ACSLS GUI may already be installed.
In this case, you will have the option to re-install the GUI or to skip this section and retain the current ACSLS GUI domain. The install routine prompts:
The Acsls GUI Domain exists. Do you want to re-install it? (y/n
Select one of the following:
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 install 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 (y/n) whether to remove the existing GUI configuration.
When you install WebLogic on your ACSLS server, a 512-bit public key is automatically available to support basic https exchanges with client browsers. Normally, no further configuration should be necessary. However, more recent browsers, notably Internet Explorer 8 and above and Firefox 39 and above, require a lengthier key of no less than 1024 bits. Refer to "Configuring a Self-Signed Digital Certificate for HTTPS" for a description of and procedures for configuring an SSL encryption key.
The lib_cmd
feature is a command-line interface that performs many of the same operations that can be performed in the ACSLS GUI. This tool installs automatically if you choose to install either the GUI or logical library support.
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. If you do choose to install neither the GUI nor logical library support, you are given the option to install lib_cmd
.
Shall we install the optional lib_cmd interface (y or n):
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
During install.sh, you created the acsls_admin user. This user can now create accounts and assign passwords for other users of the ACSLS Web-based GUI application. You can refer to the list of GUI users that you saved earlier. To add a user, follow this procedure:
As root, go to the /export/home/ACSSS/install
directory.
Run ./userAdmin.sh
Enter the acsls_admin
password that you assigned in "Installing the Graphical User Interface."
From the menu, select (1) to add a new user.
Enter the ID of the user you want to add.
Assign a password for that user.
Passwords must contain eight characters with a combination of alpha and numeric or special characters.
You can use the userAdmin.sh
utility at any time to add or delete users or to change passwords for all ACSLS GUI users. See userAdmin.sh
in the Utilities chapter of the StorageTek ACSLS 8.4 Administrator's Guide.
The XML API (XAPI) is an API that allows StorageTek clients and servers to communicate using a common ELS protocol over TCP/IP. ACSLS 8.4 and later releases can be configured with XAPI support.
You install the XAPI component separately from ACSLS and after ACSLS has been installed.
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 as root
to the ACSLS server.
Source key ACSLS environment variables:
. /var/tmp/acsls/.acsls_env
(There is a 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)
Control files are customized files, user preferences, and local configuration files that are unique to your specific ACSLS environment.
If you have exported the database and control files, you now need to import them. The control files include those files in the data/external
directory that have been customized to your specific environment.
If you are migrating to ACSLS 8.4 from a previous release and have customized your dynamic or static variables, you must import them. For information, refer to Importing the Database in the ”Database Administration” chapter of the StorageTek ACSLS 8.4 Administrator's Guide.
If you are configuring ACSLS with an actual library follow this procedure. If you are installing a new ACSLS release and do not have a test library to use for configuring and testing ACSLS, see "Testing a New ACSLS Release Without a Library"".
Verify the server system hardware is properly configured, connected, powered on, and ready.
Verify each of the physical connections (example: Ethernet, fibre, SCSI) connections between the server and the library hardware.
Before configuring ACSLS to your library complex, make sure all libraries, rails, and CAPs are fully configured, powered on, and ready.
Create or import the Library Configuration. Refer to the ACSLS 8.4 Administrator's Guide for details.
To import the configuration from an earlier ACSLS release, see the section Importing the Database in the ”Database Administration” chapter.
To create a new library configuration, see the section Configuring or Reconfiguring Library Hardware in the ”Installing and Configuring Your Library Hardware” chapter.
If you are using logical libraries to support SCSI clients over Fibre Channel, set up the FC connections between any client HBA ports and suitable HBA ports on the ACSLS server. Fibre connections to logical library client machines should be active when you install ACSLS.
For help with connectivity problems, refer to the 'Troubleshooting” chapter in the ACSLS 8.4 Administrator's Guide.
Refer to the ”Installing and Configuring Your Library Hardware” chapter in the ACSLS 8.4 Administrator's Guide. See the section ”Using acsss_config to Configure Your Library Hardware”.
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 library or library partition to use as a test environment, it is possible to test a new ACSLS release in a limited way without having a test library for ACSLS to access. Follow this procedure:
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. See the 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 come ups 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.
Use the following procedure to verify ACSLS. You should be logged in as acsss
. This procedure mounts or dismounts a cartridge.
To start ACSLS Software, log in as user acsss
and run the acsss enable
command. Refer to acsss
in the ”Utility” chapter of the StorageTek ACSLS 8.4 Administrator's Guide.
For instructions on using cmd_proc
, refer to "Using a cmd_proc" in the StorageTek ACSLS 8.4 Administrator's Guide.
Query the server from the cmd_proc
by entering
query server
If messages are displayed indicating that the server is in waiting mode, wait for a message indicating that the server is running.
Verify the following are online. You must have at least one of each online. If not, bring them online with the vary
command.
query port all query acs all query lsm all query drive all
Do you have at least one cartridge in an LSM?
YES - continue with the procedure.
NO - Enter a cartridge into an LSM.
Mount a volume by entering:
mount vol_id drive_id
Use the query drive
command to get the ID of an available drive and the query volume
command to get the ID of a library cartridge. Refer to the ”Installing and Configuring Your Library Hardware” chapter in the StorageTek ACSLS 8.4 Administrator's Guide.
Did 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/dismount still fails, call Oracle Support for assistance.
Dismount the cartridge by entering:
dismount vol_id drive_id force
In the above command, vol_id
is the volume and drive_id
is the drive you specified in step-4.
The last step of your installation is auditing your libraries. You also need to audit your libraries if:
This is a new installation.
You are adding new libraries to an existing configuration.
Refer to ”Auditing the Library” in the Library Management chapter of the StorageTek ACSLS 8.4 Administrator's Guide.
The XAPI component can be removed without uninstalling ACSLS. To do this:
Log in as root
to the ACSLS server.
Source key ACSLS environment variables:
. /var/tmp/acsls/.acsls_env
(There is a period and space before /var/tmp/acsls/.acsls_env
).
Uninstall the XAPI component.
cd $ACS_HOME/install ./remove_xapi.sh Do you wish to remove the xapi service? (y)
Note:
If you are upgrading to another release of ACSLS, make sure to export your ACSLS database by using thedb_export.sh
utility command discussed in the ”Utility” chapter of the StorageTek ACSLS 8.4 Administrator's Guide.To uninstall ACSLS:
Log in as acsss
.
Enter acsss shutdown
.
Remove the package. To do this:
Log in as root
.
Go to the ACSLS_8.4.0 package installation directory (typically /opt/ACSLS_8.4.0
) and run pkg_uninstall.sh
.
The pkg_uninstall
script removes many, but not all ACSLS file systems and it keeps the user accounts in place for acsss
, acssa
, and acsdb
. This approach allows for faster upgrades of ACSLS.
On Solaris 11, the pkg_uninstall
utility prompts you whether to uninstall the PostgreSQL packages. You would normally answer "n" to this prompt unless you are permanently removing the ACSLS application.
To remove the contents of the ACSLS database backup directory:
rm -rf $ACSDB_BKUP
WebLogic and the ACSLS GUI are not removed automatically during a package uninstall for the following reasons:
Upgrading ACSLS may not require an upgrade of WebLogic or the ACSLS GUI.
Uninstalling WebLogic and the ACSLS GUI removes ACSLS GUI users and their passwords.
Uninstalling WebLogic and the ACSLS GUI removes any custom SSL keystore that may have been configured for the ACSLS GUI.
Reinstalling WebLogic takes time (five minutes or more) to complete.
To completely remove ACSLS from your system, perform the following steps:
cd $installDir rm -rf Oracle, SSLM userdel acsss userdel acssa userdel acsdb
Reboot.