Preparing for Installation

Step 1: Export Existing Database and Control Files

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.

Step 2: Remove Previous ACSLS Versions

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.

Step 4: Network Security Settings

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
```

Step 5: Cron Administration

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.

Step 6: ACSLS Access Privileges

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.

Step 7: Download and Unzip the ACSLS 8.5 Package

To download and unzip the ACSLS 8.5 package:

Start a web browser on the system and visit the Oracle Software Delivery Cloud:

https://edelivery.oracle.com
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.

Step 8: Create User Accounts and Groups

Create the user accounts and associated groups described in the table below. For command examples, see Installation Command Examples.

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	`$(installDir)/ACSSS` Default example: `/export/home/ACSSS` Ownership/Permissions: Directory Owner: `acsss:acsls` Minimum permissions: `rwxr-x---`	/bin/bash	ACSLS control user
acssa	acsls	`$(installDir)/ACSSA` Default example: `/export/home/ACSSA` Ownership/Permissions: Directory Owner: `acssa:acsls` Minimum permissions: `rwxr-x---`	/bin/bash	ACSLS SA user
acsdb	acsls	`$(installDir)/acsdb/ACSDB1.0` Default example: `/export/home/acsdb/ACSDB1.0` Ownership/Permissions: Directory Owner: `acsdb:acsls` Minimum permissions: `rwxr-x---`	/bin/bash	ACSLS DB user
postgres	postgres	`/usr/postgres/10-pgdg` Ownership/Permissions: Directory Owner: `postgres:postgres` Minimum. permissions: `rwxr-xr-x`	/bin/bash	postgres user
root	no requirement	standard root Ownership/Permissions: user defined	/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.