2 Installing ACSLS on Solaris

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 the install.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:

Legal Notice

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/.

Exporting the Database and Control Files

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:

  1. As user acsss:

    cd $ACS_HOME/install
    
  2. Type su root.

    Do not type su - root to retain your acsss environment.

  3. 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.

  4. Record the user IDs so you can re-add them later as described in "Adding Users of the ACSLS GUI".

Installing Solaris

This section describes the steps to install Solaris.

Notes for the Solaris Administrator

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.

Network Security

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:

  1. Check the property setting:

    # svccfg -s rpc/bind listprop config/local_only
    
  2. If the local_only property setting is true, you must set it to false.

    # svccfg -s rpc/bind setprop config/local_only=false
    

Access Privileges

  • 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.

User Administration

  • 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

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

Removing Previous ACSLS Version

  1. 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

  2. Remove the ACSLS package.

    1. As user acsss, bring down ACSLS.

      $ acsss shutdown
      
    2. 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.

    3. To remove the GUI user accounts and other files left behind, use:

      # cd $installDir
      # rm -rf ACSSS ACSSA acsdb SSLM
      
    4. To remove ACSLS administrative accounts:

      # userdel acsss
      # userdel acsdb
      # userdel acssa
      

Installing the ACSLS Package

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:

  1. Go to the Oracle Software Delivery Cloud, and find the ACSLS_8.4.0 software bundle available for both SPARC and X86 platforms.

    1. 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.

    2. 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.

    3. 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.

    4. 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.

  2. 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.
  3. 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)

  4. 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.

  5. Proceed to "Running install.sh".

Installing PostgreSQL

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/

  1. 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
    
  2. Be sure to select the 32-bit version.

  3. 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.

  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.

Running install.sh

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

Creating the Database

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.

Installing an mchanger Driver

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

Installing Support for Logical Libraries

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.

Installing the Graphical User Interface

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:

  1. Enter y at the following prompt:

    Do you want to install the ACSLS Graphical User Interface? (y/n)
    
  2. 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
    
  3. 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.

Installing lib_cmd

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):

Installing ACSLS Services

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

Adding Users of the ACSLS GUI

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:

  1. As root, go to the /export/home/ACSSS/install directory.

  2. Run ./userAdmin.sh

  3. Enter the acsls_admin password that you assigned in "Installing the Graphical User Interface."

  4. From the menu, select (1) to add a new user.

  5. Enter the ID of the user you want to add.

  6. 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.

Installing the XAPI Service with ACSLS

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:

  1. Ensure you have installed the ACSLS package and run install.sh to finish the ACSLS installation.

  2. Ensure you are logged in as root to the ACSLS server.

  3. Source key ACSLS environment variables:

    .  /var/tmp/acsls/.acsls_env
    

    (There is a period and space before /var/tmp/acsls/.acsls_env).

  4. Install the XAPI component:

    cd $ACS_HOME/install
    ./install_xapi.sh
    Installing the XAPI component for Oracle IBM mainframe clients. Continue? (y)
    

Importing the Database and Control Files

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.

Installing and Configuring your Library Hardware

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"".

  1. Verify the server system hardware is properly configured, connected, powered on, and ready.

  2. Verify each of the physical connections (example: Ethernet, fibre, SCSI) connections between the server and the library hardware.

  3. Before configuring ACSLS to your library complex, make sure all libraries, rails, and CAPs are fully configured, powered on, and ready.

  4. 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.

  5. 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.

  6. For help with connectivity problems, refer to the 'Troubleshooting” chapter in the ACSLS 8.4 Administrator's Guide.

  7. 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”.

Testing a New ACSLS Release Without a Library

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:

  1. Install the new ACSLS release on a separate server.

  2. 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.
  3. Import the database and control files into your new ACSLS release using db_import.sh.

  4. 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

  5. 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.

Verifying ACSLS Installation

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.

  1. 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.

  2. 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
    
  3. Do you have at least one cartridge in an LSM?

    • YES - continue with the procedure.

    • NO - Enter a cartridge into an LSM.

  4. 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.

  5. 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.

  6. 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.

Auditing the Library

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.

Uninstalling the XAPI Service

The XAPI component can be removed without uninstalling ACSLS. To do this:

  1. Log in as root to the ACSLS server.

  2. Source key ACSLS environment variables:

    .  /var/tmp/acsls/.acsls_env
    

    (There is a period and space before /var/tmp/acsls/.acsls_env).

  3. Uninstall the XAPI component.

    cd $ACS_HOME/install
    ./remove_xapi.sh
    Do you wish to remove the xapi service? (y)
    

Uninstalling ACSLS 8.4

Note:

If you are upgrading to another release of ACSLS, make sure to export your ACSLS database by using the db_export.sh utility command discussed in the ”Utility” chapter of the StorageTek ACSLS 8.4 Administrator's Guide.

To uninstall ACSLS:

  1. Log in as acsss.

  2. Enter acsss shutdown.

  3. Remove the package. To do this:

    1. Log in as root.

    2. 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.

  4. To remove the contents of the ACSLS database backup directory:

    rm -rf $ACSDB_BKUP
    
  5. 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
    
  6. Reboot.

Uninstalling any SCSI Media Changer Drivers

  1. Log in as root.

  2. Remove the SCSI Media Changer (mchanger) drivers.

    #rem_drv mchanger
    
  3. Remove mchanger.conf.

    #rm /usr/kernel/drv/mchanger.conf
    
  4. Remove any mchanger device links.

    #rm /dev/mchanger*
    
  5. Remove package directories.

    #rm -rf /opt/STKchanger