Application Lifecycle Manager Deployment Guide

Transcription

1 Application Lifecycle Manager Deployment Guide Version 3.0

2 Application Lifecycle Manager June 2011 Copyright Alcatel-Lucent [ All rights reserved. Important Notice to Users No part of this document may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the express permission of Motive, Inc. ( Motive ) and/or Alcatel-Lucent. This document and the related software may only be used pursuant to a Software License Agreement or other similar written agreement in place between you and either Motive or Alcatel-Lucent. Furthermore, Motive and Alcatel-Lucent expressly disclaim any and all warranties regarding the information contained in, and the products and systems described in, this document, whether express, implied, or statutory, including without limitation implied warranties of merchantability or fitness for a particular purpose. Furthermore, this document is subject to change without notice. There may exist in this document references to using this product and the systems described herein in connection with products and/or systems owned by third parties. Please note that this information is provided as a courtesy to assist you. Such references are not intended to imply the granting of a license to use such products and/or systems. Such licenses shall result only from separately executed agreements between you and the owner of such products and/or systems. Neither Motive nor Alcatel-Lucent assume any responsibility or liability for incorrect or incomplete information provided about such third-party products. Alcatel, Lucent, Alcatel-Lucent, the Alcatel-Lucent logo, Motive and the Motive logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. The products and systems described herein may be covered by the various patents that have been issued to Motive and/or Alcatel-Lucent. Disclaimers This product is intended for commercial uses. Without the prior written consent of either Motive or Alcatel-Lucent it must not be used, sold, licensed or otherwise distributed for use in any hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life-support machines, or weapons systems, in which the failure of products could lead directly to death, personal injury, or severe physical or environmental damage. You hereby agree that the use, sale, license or other distribution of the products for any such application without the prior written consent of either Motive or Alcatel-Lucent, shall be entirely at your sole risk. You hereby agree to defend and hold Motive and Alcatel-Lucent harmless from any claims for loss, cost, damage, expense or liability that may arise out of or in connection with the use, sale, license or other distribution of the products in such applications. This document was originally written in English. If there is any conflict or inconsistency between the English version and any other version of a document, the English version shall prevail. 3JB AAAC-TPZZA

3 Contents Introduction... vii Audience... viii Conventions... viii Support and contact information... viii 1 Installation... 1 Previewing the ALM installation process... 2 Conducting the required pre-installation tasks... 3 Understanding the ALM deployment scenarios... 3 Understanding the ALM pre-requisites... 4 Understanding the required ports... 6 Creating an Oracle user manually (optional)... 7 Creating backups for the installation environment... 8 Installing ALM... 8 Understanding answer files... 8 Understanding the ALM sample answer file... 9 Understanding the unique answer variables Invoking answer file for ALM installation Conducting the post-installation and deployment tasks Configuring the ALM license Setting properties for using MDM with ALM (if applicable) Completing post-deployment tasks for using HDM with ALM (if applicable) Uninstalling and undeploying the ALM application Administration and Configuration Locating and logging onto the ALM Management Console Managing users and user authentication Understanding ALM groups Understanding the ALM users Understanding ALM licenses iii

4 Understanding the ALM interfaces Understanding the ALM Management Console Understanding the ALM Northbound Interface (NBI) Finding and configuring application trace logging Trace logging levels Understanding the default ALM logging and top-level Java packages Configuring ALM application trace log levels Configuring an MDM installation to send notifications to ALM Setting up additional search profiles for policies Flavor examples Policy examples Policies to manage applications Policies to manage device health Configuring OSGi security Configuring system settings Administering the Dashboard Console Finding Dashboard resources Installing the Dashboard Console Licensing the Dashboard Console Logging into Dashboard Console Dashboard Console GUI Understanding a Dashboard Console deployment Understanding the dashboard-config.xml file Sample XML Configuration File Threshold Configuration Uploading and downloading the configuration file Understanding Dashboard counters and graphs Configuring counters and graphs Dashboard Console administration SMP Data Source Understanding the ALM SMP data source Requirements for deploying the ALM data source Installing and configuring the ALM data source Installing the ALM Synchronous REST Service Installing the ALM data source in SMP applications Setting up SSL for the ALM data source iv

5 ALM data source reference Connection parameters Best practices Data types Methods Troubleshooting Glossary Index v

6 vi

7 Introduction An offering in the portfolio of Alcatel-Lucent digital life management solutions, Application Lifecycle Manager enables broadband providers to remotely deploy and manage applications and services on devices. ALM supports dynamic installation and upgrading of application components and provides configuration and event notification services. A flexible northbound interface supports integration into business networks. Application Lifecycle Manager management capabilities include: Device Management. Supports the necessary functions to inspect and update software on devices. Application Creation Framework. Offers service providers a framework to assemble software components into added-value home services and applications. It helps to relieve your team of manual checks for component dependencies and compatibility. Application Lifecycle Management. Coordinates the installation and deployment of end-user services on managed devices. Application Lifecycle Manager functionality includes application, deployment unit, and individual device life cycle management, as well as the ability to apply policies on multiple devices. ALM enables you to upload deployment units (software components) to a File Server or specify the URL of a File Server where the deployment units already reside, in preparation for download to a service device. It also features deployment unit management through the use of applications, which can be flagged for testing, for production, or for deprecation, the latter preventing them from being installed on the device in the future. Applications are defined using flavorss, which allow each application to store variant sets of deployment units and configuration information for devices with different requirements, and which allow the system to automatically choose the appropriate flavor to install on a particular device. The system supports maintenance of configuration files and managed objects for applications. ALM is installed on top of one or more device managers, through which it communicates with clients using the TR-069 protocol or the DM (device management) protocol. Its interfaces include the ALM Management Console and the Application Lifecycle Manager Northbound Interface (NBI). The ALM Management Agent provides a client-side interface that enables communication between the device and Application Lifecycle Manager through Home Device Manager. This guide contains installation, administration, and configuration information for Application Lifecycle Manager. For detailed information about the ALM Management Console, see the ALM Management Console Help. For details about the ALM Northbound Interface (NBI), see the Application Lifecycle Manager Programming Guide and the Application Lifecycle Manager: WSDL Reference. vii

8 Audience The Application Lifecycle Manager Deployment Guide describes how to install, administer, and configure the product. This guide assumes that you understand how to use the device manager(s) you have selected for you deployment and the applicable northbound interfaces (NBI). In addition, you should understand the OSGi framework and the architecture, terminology, and supported device protocols for your device manager.. Conventions This document uses the following typographic conventions: Bold Identifies the names of graphical user interface buttons, options, commands, fields, and labels. Italic Identifies variable placeholders such as function or method parameters representing information that must be provided by the implementation or user. Also identifies documentation titles and certain terms to emphasize meaning. Monospace Identifies information that you are required to type exactly as shown. This convention also identifies code and command samples, screen prompts, messages, and filenames. Monospace italic Identifies parameters whose actual names or values you must provide at a screen prompt or in a text field. UPPERCASE Identifies the names of keys on the keyboard. In multi-line code listings, the symbol indicates that the text was wrapped for typographical reasons. Support and contact information If you encounter issues with this product, visit the Online Customer Support (OLCS) [ website. After registering and logging on, you can access troubleshooting information. In addition, you can contact Alcatel-Lucent Motive Support by phone, fax, or , as follows: Toll-free phone (within U.S.) Outside U.S. Fax , option (United States) <support@motive.com> The Motive Product Group and its parent company, Alcatel-Lucent, are interested in feedback about your experience with this product and its documentation. If you have comments or suggestions, send to <pubs@motive.com>. viii Introduction

9 This chapter covers: 1 Installation Previewing the ALM installation process Conducting the required pre-installation tasks Installing ALM Conducting the post-installation and deployment tasks Uninstalling and undeploying the ALM application 1

10 Previewing the ALM installation process Installing Application Lifecycle Manager involves the following tasks: Conduct the required pre-installation tasks: Understand the ALM deployment scenarios Understand the ALM prerequisites Understand the required ports Create an Oracle database user manually (optional) Create backups for the installation environment Use the ALM installer: To create a standalone WebLogic Domain, Administration Server and a cluster with n number of Managed Servers for ALM This deployment scenario is recommended, and it is required for deployments in which ALM is only using MDM without also using HDM. See ALM deployed in its own WebLogic domain (recommended) on page 3 and the applicable procedure, To install ALM in its own domain on a host slated for the Administration Server and/or a Managed Server on page 20. Or To install and deploy ALM on Managed Servers in a HDM installation This deployment scenario is not recommended; however, it is supported for deployments in which ALM is using HDM. See ALM deployed in same domain as HDM on page 3 and the applicable procedure, To install ALM on a Managed Server in a HDM domain on page 21. Conduct the post-installation and post-deployment tasks: Configure the ALM license unless configuring it with the LICENSE_STRING variable during ALM installation. For related information, see SSL and License answer variables on page 20. Set the properties for using MDM with ALM (if applicable) Complete the post-deployment tasks for using HDM with ALM (if applicable) 2 Installation

11 Conducting the required pre-installation tasks Understanding the ALM deployment scenarios The recommended deployment scenario involves creating a WebLogic domain for ALM, including an Administration Server and a cluster of one or more Managed Servers on which to install and deploy the product. If the ALM deployment is to use HDM, other scenarios are supported. For information, see ALM deployed in same domain as HDM on page 3. ALM deployed in its own WebLogic domain (recommended) In the recommended deployment scenario, your team invokes the ALM installer on the host slated for the Administration Server in addition to one or more hosts slated for Managed Server instances. ALM is installed and deployed on each of the latter instances. The installer creates a domain named ALMDomain for the system, and the managed servers become part of an ALMCluster. For instructions, see To install ALM in its own domain on a host slated for the Administration Server and/or a Managed Server on page 20. ALM deployed in same domain as HDM If using ALM with HDM, it is supported to install and deploy ALM on Managed Servers created in the same domain as HDM. In the following table, compare the types of Managed Servers on which you can install and deploy ALM. For instructions, see To install ALM on a Managed Server in a HDM domain on page 21. Comparison: Managed Server types for the ALM application Type Characteristics Dedicated Managed Server Instance created by the ALM installer as a part of the ALM installation/deployment processes Installed as an instance either: On the HDM Administration Server host Or Conducting the required pre-installation tasks 3

12 Comparison: Managed Server types for the ALM application (continued) Type Characteristics A remote host on which an instance of the HDM Managed Server is installed Added to the HDMDomain but not added to the HDMCluster; instead, it is added to a cluster created for one or more ALM Managed Servers. HDM Managed Server (not recommended) Runs a JMS Server and the ALM application Instance created by HDM installer Installed on any host in the Home Device Manager environment Added to both the HDMDomain and the HDMCluster Runs both the HDM applications and the ALM application Understanding the ALM pre-requisites For minimum system requirements and known issues, see the Application Lifecycle Manager Release Notes. Home Device Manager and/or Mobile Device Manager Before installing Application Lifecycle Manager (ALM), at least one of the following products must be installed, configured, and functioning correctly. Home Device Manager 3.1. For Home Device Manager installation or upgrade instructions, see the Home Device Manager Installation Guide, version For system requirements, see the Home Device Manager Release Notes, version 3.1. Mobile Device Manager 3.1. For Mobile Device Manager installation or upgrade instructions, see the Mobile Device Manager Deployment Guide, version 3.1. For system requirements, see the Mobile Device Manager Release Notes, version 3.1. Database Server ALM requires a database instance running on one of the following Oracle Enterprise Edition server packages: 10g R2 version Or 4 Installation

13 11g version The Oracle client version installed on the Administration Server should match the version of the Oracle server installed for the database. For related information, see Creating an Oracle user manually (optional) on page 7 and Database answer variables on page 14. Note If using ALM with HDM, it is recommended to create the ALM database user on the same database instance in which the HDM database user is created. Oracle BEA WebLogic Server ALM requires Oracle BEA WebLogic 11g PS2 ( or ). Before installing ALM, you can install WebLogic on the target machines. Alternatively, you can use the ALM installer to silently install WebLogic with an applicable installer (for example, wls1034_generic.jar). For related information, see the answer variables in WebLogic Installer answer variables on page 11. Java Development Kit (JDK) ALM requires Java Development Kit (JDK) 1.6. Before installing ALM, you can install the JDK on the target machines. Alternatively, you can use the ALM installer to silently install the JDK with an applicable installer (for example, jdk-6u24-solaris-sparc.sh). For related information, see the entries for the Java variables in WebLogic and Java Installation answer variables on page 12. File Server for deployment units (bundles) Application Lifecycle Manager depends on a File Server to store deployment units for download by devices in the customer base. The File Server includes a component server for deployment unit uploading and a component server for deployment unit downloading. Most standard FTP and HTTP server components work with ALM, as long as the components support user name/password authentication or no authentication. Typically, the components are installed on the same host. For more information, see the File server requirements section in the Application Lifecycle Manager Release Notes. Supported protocols. Beginning with ALM 3.0, SFTP servers are supported for uploading bundles. Typically, SFTP servers are available on UNIX systems when the SSH daemon is installed. Uploading bundles. FTP and SFTP Downloading bundles. FTP, HTTP, and HTTPS Understanding the ALM pre-requisites 5

14 Before continuing, install a File Server with the FTP and HTTP components. In advance of each ALM installation, you need to define the applicable variables. For details, see File Server answer variables on page 19. Understanding the required ports The following table lists the ports that must be open for an ALM deployment. It does not include ports required by Home Device Manager. ALM required ports Port Number Protocol Destination Source Purpose 7006 HTTPS ALM Application server Management Access to the ALM Application Tier: Management Console NBI 9004 T3S ALM Application server BEA WebLogic administrator tools Used by BEA WebLogic tools to administer and monitor the server. This port is not required for normal operation JDBC Oracle server ALM Application server Database access. 22 SFTP ALM repository ALM Application server Upload of deployment units and configuration files. 443 HTTPS CPE (service gateway) ALM repository Download of deployment units and configuration files. SOAP port HTTP(S) ALM NBI system ALM Application Server An NBI system can register a SOAP endpoint in ALM to received asynchronous notifications. To make this work, the appropriate port must be accessible. If the NBI system uses JMS 6 Installation

15 ALM required ports (continued) Port Number Protocol Destination Source Purpose for notifications, this is not required. Creating an Oracle user manually (optional) Application Lifecycle Manager depends on a database user to persist ALM data in an existing Oracle database instance. For related information, see Database Server on page 4. Note If using ALM with HDM, it is recommended to create the ALM database user on the same database instance in which the HDM database user is created. The following table outlines the two ways to handle creation of the ALM database user. Comparison: Creation methods for ALM database user Method Manually using a database tool such as SQL*Plus The user created must include the connect and resource privileges (for example, grant connect, resource to username) Characteristics Enables configuring the ALM database user in a custom manner (for example, with dedicated tablespaces) Eliminates requirement to define the Database Administrator (DBA) credentials while installing ALM; this is only required when the installer is to create the ALM database user Requires setting the DROP_USER=n variable in the answer files for ALM installations. In turn, the ALM installer: Does not issue a drop user command for the specified database user Automatically using the ALM installer Does not attempt creating the specified database user Requires person who invokes the ALM installer and defines the answer files to know the Database Administrator (DBA) credentials Requires setting the DROP_USER=y variable in the answer file used for installing the ALM Administration Server or only the first Managed Server foralm deployments in a HDM installation. In turn, the ALM installer: Drops the specified user (if the user exists in the specified database instance). For example, this is useful in a re-installation scenario. Creating an Oracle user manually (optional) 7

16 Comparison: Creation methods for ALM database user (continued) Method Characteristics Creates or re-creates the specified database user, whichever applicable. Important For each ALM installation occurring after the database user for ALM is created, set the DROP_USER=n variable in the answer file. For example, DROP_USER=n is applicable when: The DBA manually created the user before your team began installing ALM on target hosts. Or Installing ALM subsequently after the user was created during the first ALM installation process, either for an Administration Server and Managed Server or for the first Managed Server in a HDM installation. If the manual option is preferable, create the user now before continuing. For related information, see the DB_USER=ALM_DB and DB_USER_PW=ALM_DB entry in Database answer variables on page 14. Creating backups for the installation environment It is highly recommended to create backups of the following components before installing Application Lifecycle Manager: Oracle database instance slated for ALM data File system of all target hosts slated for ALM installations Installing ALM The primary method for installing and deploying ALM is invoking the provided ALM installer with an answer file. Understanding answer files You can use answer.txt files to install ALM. Answer files define variables and deployment-specific values for installations. There are two ways to use answer files: 1. Include all the deployment-specific values required to install. 8 Installation

17 In this case, the installer does not prompt you for any values. 2. Include some of the required values to install. In this case, the installer pre-populates the prompts with the values defined in your answer file, and it prompts for any required values not defined there. Managed Server installations. For a cluster, you run the ALM installer once for each Managed Server instance; some configuration values must be unique per instance. As a result, edit your answer file before each installation. Alternatively, leave the Managed Server-specific values undefined in the answer file, and then provide them when prompted. For example, pay special attention to the following answer variables. The MANAGED_SERVER_NAME property requires a unique value for each server instance. Similar to value for INSTALL_DIR, the port values must be unique for server instances on the same host. For related guidance, see ALM File System answer variables on page 13 and Managed Server answer variables on page 16. # # Managed Server # MANAGED_SERVER_CREATE=y MANAGED_SERVER_NAME=ALM-Server MANAGED_SERVER_PORT=7005 MANAGED_SERVER_SSL_PORT=7006 MANAGED_SERVER_ADMIN_PORT=9004 MANAGED_SERVER_MACHINE=M_host DEPLOY_APPLICATION=y # Important For each ALM installation occurring after the database user for ALM is created, set the DROP_USER=n variable in the answer file. For example, DROP_USER=n is applicable when: The DBA manually created the user before your team began installing ALM on target hosts. Or Installing ALM subsequently after the user was created during the first ALM installation process, either for an Administration Server and Managed Server or for the first Managed Server in a HDM installation. Understanding the ALM sample answer file This section provides a sample answer file for installing ALM. For guidance on setting the values, see the applicable sections in Understanding the unique answer variables on page 11. # # WebLogic Installer # BEA_INSTALL_FILE=/opt/installers/wls1034_generic.jar PROXY_HOST=proxy.mycompany.com PROXY_PORT=8080 # Understanding the ALM sample answer file 9

18 # WebLogic and Java Installation # WL_HOME=/opt/alm30/wlserver_10.3 JAVA_INSTALLER=/opt/installers/jdk-6u24-solaris-sparc.sh #JAVA_HOME=/opt/alm30/jdk160_24 CREATE_SEPARATE_BEA_DOMAIN=y # # ALM File System # INSTALL_DIR=/data/alm/install_3.0_separate/ALM-Server INSTALL_OVERWRITE=y # # Administration Server # BEA_ADMIN_HOST=admin.mycompany.com BEA_ADMIN_PORT=9002 BEA_ADMIN_SERVER_SSL_PORT=9001 BEA_ADMIN_USER=weblogic BEA_ADMIN_PW=w3blog!c AUTH_TYPE=default # # Cluster # CLUSTER_NAME=ALMCluster CLUSTER_MULTICAST_ADDRESS= CLUSTER_MULTICAST_PORT=3456 # # Database # DROP_USER=y DB_EXE=/opt/oracle/product/ /bin/sqlplus DB_SERVER=dbhost.mycompany.com DB_PORT=1521 DB_SERVICE=serviceName DB_DBA=system DB_DBA_PW=password DB_USER=ALM_DB DB_USER_PW=ALM_DB # # Node Manager # NODEMGR_PORT=5560 # # Managed Server # MANAGED_SERVER_CREATE=y MANAGED_SERVER_NAME=ALM-Server MANAGED_SERVER_PORT=7005 MANAGED_SERVER_SSL_PORT=7006 MANAGED_SERVER_ADMIN_PORT=9004 MANAGED_SERVER_MACHINE=M_host DEPLOY_APPLICATION=y # # HDM Applications # HNM_MANAGED_SERVER_NAME=hdm_7004 HNM_JNDI_URL=t3s://hdm.mycompany.com:7004 HNM_NBI_URL= 10 Installation

19 HNM_NBI_USER=nbi_user HNM_NBI_USER_PW=password # # File Server # REPOSITORY_DOWNLOAD_SERVER=repository.mycompany.com REPOSITORY_DOWNLOAD_ROOT=/download REPOSITORY_DOWNLOAD_PORT=443 REPOSITORY_DOWNLOAD_PROTOCOL=ftp REPOSITORY_DOWNLOAD_USER=anonymous REPOSITORY_DOWNLOAD_PASSWORD=password REPOSITORY_UPLOAD_SERVER=repository.mycompany.com REPOSITORY_UPLOAD_ROOT=/upload REPOSITORY_UPLOAD_PORT=22 REPOSITORY_UPLOAD_PROTOCOL=ftp REPOSITORY_UPLOAD_USER=anonymous REPOSITORY_UPLOAD_PASSWORD=password # # SSL and License # # If installing into environment with # demonstration certificates, you must # remove the pound sign (#) to uncomment # and apply the FAKE_SSL_TRUST=y answer # variable. # #FAKE_SSL_TRUST=y # LICENSE_STRING=125hwyuguabacwjfs Understanding the unique answer variables WebLogic Installer answer variables BEA_INSTALL_FILE=/opt/installers/wls1034_generic.jar Only applicable if Oracle BEA WebLogic 11g PS2 ( or ) is not yet installed on the host. To have the ALM installer silently install WebLogic, specify the path up to and including the WebLogic installer. If the WebLogic installer is generic (a.jar file), Java starts the silent installation process. Note that the parent directory set in the WL_HOME variable is implemented for BEA_HOME. The parent directory is everything in the string value except for wlserver_10.3 (for example, /opt/alm30/). PROXY_HOST=proxy.mycompany.com and PROXY_PORT=8080 Only applicable when setting BEA_INSTALL_FILE to silently install WebLogic. Optionally, specify the fully qualified host name and port configured for an available Proxy Server. This helps overcome waiting times when the installation host is on a system with blocked Internet access. Instead, you can apply empty values for these variables. Understanding the unique answer variables 11

20 WebLogic and Java Installation answer variables WL_HOME=/opt/alm30/wlserver_10.3 Specify the absolute path for the Oracle BEA WebLogic Server on the host. For example: /opt/alm30/wlserver_10.3 where: /opt/alm30/ is the root directory in which WebLogic is either to be installed or is installed on the host. JAVA_INSTALLER=/opt/installers/jdk-6u24-solaris-sparc.sh Only applicable when JDK 1.6 is not yet installed on the host; otherwise, the JAVA_HOME variable is applicable. Specify the path to the JDK1.6 installer, which can be downloaded from the Oracle site. In turn, the JDK is installed in the BEA_HOME/jdk160 directory. At the same time, the JAVA_HOME variable is automatically set to BEA_HOME/jdk160. where BEA_HOME is the parent directory set in the WL_HOME variable. The parent directory is everything in the string value except for wlserver_10.3 (for example, /opt/alm30/). For subsequent Managed Server installations on the same host, comment out the JAVA_INSTALLER variable by inserting a pound sign in front of it (for example, #JAVA_INSTALLER). #JAVA_HOME=/opt/alm30/jdk160_24 Only applicable when JDK 1.6 is already installed; otherwise, the JAVA_INSTALLER variable is applicable. To specify the path to an existing JDK installation on the host, uncomment the variable by removing the pound sign (#), and then configure the value as applicable. CREATE_SEPARATE_BEA_DOMAIN=y Specify whether to create a separate domain for ALM. y to create a separate domain for the ALM deployment The CREATE_SEPARATE_BEA_DOMAIN variable must be set to y if ALM is installed only for MDM. That is because ALM is installed on a JBoss application server. The ALM installer does not support installing ALM on JBoss. Or n to install ALM in the domain for an existing HDM installation. 12 Installation

21 ALM File System answer variables INSTALL_DIR=data/alm/install_3.0_separate/ALM-Server Specify the path for the ALM file system. The installer creates the directory and copies various ALM files including an uninstall script there. Note For cluster installations with multiple Managed Servers on the same physical host, the value must be unique per Managed Server. That way, each Managed Server on the host has its own file system. INSTALL_OVERWRITE=y Specify whether to overwrite the directory specified with INSTALL_DIR variable given the directory exists. y to overwrite the existing installation Or n to stop the installation process without overwriting the existing installation Administration Server answer variables BEA_ADMIN_HOST=almadmin.mycompany.com Specify the fully qualified host name for the Administration Server. BEA_ADMIN_PORT=9002 Specify the administrative port number for domain-wide administration on the Administration Server. If the default port number (9002) is in use on the Administration Server host, change the value; otherwise, leave the setting unchanged. BEA_ADMIN_SERVER_SSL_PORT=9001 Specify the SSL port number for the Administration Server. If the default port number (9001) is in use on the Administration Server host, change the value; otherwise, leave the setting unchanged. BEA_ADMIN_USER=weblogic Specify the user name for the Application Server Administrator account. BEA_ADMIN_PW=w3blog!c Specify the password for the Application Server Administrator account. AUTH_TYPE=default Specify the set of password requirements to implement: default to implement fewer password constraints. The default configuration only permits authentication for account passwords that include eight or more characters, including at least two lowercase characters (for example, f and l). Understanding the unique answer variables 13