Limitations of non-root installers

 

+

Search Tips   |   Advanced Search

 

Non-root installers can install WAS ND V6.1 in both silent and interactive mode for full product installations and removals, incremental feature installations, and silent profile creation.

Installing as a non-root user in V6.1 works the same as installing as a root user does in previous versions. The term non-root implies an installer on an operating system such as AIX or Linux, but it also means a non-administrator group installer on a Windows system.

There are limitations.

• For the IBM HTTP Server, or the Web server plug-ins components, a non-root installation does not install the GSKit security components needed for SSL support. As a result, have root access to install the GSKit.

• Non-root install for the plug-in component is only supported if WAS is also installed as non-root.

For existing installations, the root or non-root installer who owns the currently installed files is the only user who can perform subsequent installation or removal operations on that installation. Such restricted operations include profile creation, unless the owner reassigns ownership of the appropriate profile directories and files to another user. The root user is not under the same restriction, and can delete an installation owned by a non-root user.

Initially, the owner is the installer. However, the installer can assign ownership of an existing installation to another user.

The set of post-install operations that are subject to this rule includes...

• Installing maintenance
• Uninstalling the product
• Installing a customized installation package on top of an existing installation in a slip installation.

Allowing a non-owning user to perform the post-install operations introduces ownership complexities that V6.1 does not support. The full installer programs and the Update Installer (UPDI) check to verify that the current installer is also the owner of the installed files. A non-owner is not allowed to continue the operation.

The following expectations help define the parameters for using a non-root installer ID.

• Non-root installations apply to all of the WebSphere software components in the product package. Non-root installers can install all of the components, including:
  • WAS
  • IBM HTTP Server
  • Web server plug-ins
  • Application Client
  • Application Server Toolkit
  • Update Installer

• Non-root installations install an operational product

  Whenever possible, if some portion of an installation requires root privileges, the installation programs provide an option so that the non-root installer can install an operational product, but without enabling the privileged option.

• Installation programs identify root-only options

  Installation programs clearly identify privileged options by disabling such options in the interface of the non-root installer.

• Default installation locations are within your home directory

  Default installation locations are within the home directory of the non-root installer to verify a writable disk space. Default installation directories for root installers are the same as for V6.0. The installation programs verify that specified disk locations are writable.

• Installation programs display a list of limitations

  Non-root installers see a panel in the installation user interface after prerequisite checking completes. The panel clearly summarizes limitations that exist for a non-root installation.

  For example, messages might say that the GSKit cannot install and that the product cannot register natively with the operating system. The non-root installer can continue with the knowledge of the existing limitations or can cancel to install as root without the limitations.

• Silent installers support non-root installationsSilent installations have a new option across all installation packages that achieves a similar objective. The allowNonRootSilentInstall option has a default value of false:

  • The installation program checks the value of this option when a non-root installer attempts the installation. The installation program ignores the option when root is installing.

  • A false value discontinues a non-root installation. The resulting message in the installation log indicates that the allowNonRootSilentInstall value must be true. The log also indicates non-root installation limitations.

  • A true value permits the installation to proceed. The resulting message in the log indicates conditions that might exist because of the non-root limitations.

  • Comments for the non-root installer option in the sample response file clearly summarize the limitations.

• Root can use specialized installation routines to install privileged options

  Whenever possible, separately installed privileged options are integrated with the non-root installation.

  For example, a routine to install menu options on Linux systems lets a root user intervene to allow the entries for a non-root installer. See the description of using the moveWebSphereMenu.sh script later in this topic.

The following limitations and differences exist when installing as a non-root installer:

• Port value assignment limitations

  • Creating a profile is optional during WAS Network Deployment installation.

    Port value assignments for the profile occur only when the installation creates a profile. The port value assignments are part of the profile configuration.

    The installation program does not prompt an installer for which port values to use, but instead, generates and assigns a set of non-conflicting port values. The installation program assigns appropriate port values to a non-root installer, such as greater than 1024, for example.

  • In WAS V6.0, profile creation avoids port value conflicts by examining port values in use by other WAS installations.

    Multiple non-root installers diminish the ability to detect and avoid port value conflicts. WAS installations are visible to the installer ID only, because the non-root installations do not register globally. If the root user performs all WAS installations, the problem is avoided.

  • When running as non-root, the IBM HTTP Server installation program displays a default port value of 8080.

    The default value for a root installer is 80.

• Operating system and ISMP registration limitations

  • Packages installed by a non-root installer cannot register using the native operating system mechanisms, such as Red Hat Package Manager (RPM) on Linux.

    WebSphere software registers in the WAS install registry file and the vpd.properties file. All installable components are fully functional despite the lack of native registration.

  • ISMP uses native operating system registration on these platforms when installing as root, and does not create a vpd.properties file.

    When installing as a non-root installer, the installer programs create a vpd.properties file on all platforms, including Solaris and HP-UX.

• Operating system and ISMP registration limitations

  Registry entries are on a non-administrator per-user basis instead of registering the software for the entire machine, which occurs when an administrator user installs.

• GSKit limitation

  GSKit is included in the IBM HTTP Server component and in the Web server plug-ins component. As mentioned, GSKit provides SSL capability.

  • GSKit v7 relies on an absolute path to locate and correctly initialize the open source based ICC software subcomponent that handles low-level cryptography.

    GSKit cannot find ICC during a non-root installation. Because of the potential of having no cryptographic support (and possibly other unexpected effects), the installer programs do not allow a non-root installation of GSKit.

  • Additionally, GSKit v7 and earlier versions are not implemented for multiple different instances of the GSKit libraries within a single process on an operating system such as AIX or Linux.

  • GSKit v7 uses native installation methods that require root authority, such as:
    • pkgadd
    • installp
    • rpm (Linux),
    • swinstall

  • The installation programs indicate that GSKit is not installable to a non-root installer.

• Adaptive Fast Path Architecture (AFPA) limitations

  AFPA is a software architecture that dramatically improves the efficiency, and therefore the capacity, of Web servers and other network servers by caching static files.

  AFPA is a Windows kernel-level device driver within the IBM HTTP Server. AFPA provides caching of static files served from IBM HTTP Server. AFPA is recommended for very high-volume (tens of millions of hits per day) static-file Web sites only.

  Dynamic Web pages, such as those generated by WAS, are not usually cacheable. Most appservers should not enable AFPA.

  • A Windows kernel-level device driver cannot install from a non-administrator installer. Windows requires administrator group privileges when installing device drivers.

  • The IBM HTTP Server installation program indicates to non-admininstrator installers that AFPA is not installed.

• Edge Components limitations

  Edge requires root privileges because of its native installation mechanisms.

• Web Start limitations

  Application Client Version 6.1 supports Java Web Start (JWS) on all supported platforms. Particularly on a Windows system, the Application Client requires administrator access in order to configure JWS properly, by updating Windows native registry entries with some JWS-specific entries.

  Non-administrator installers cannot register the update, which provides less than full support for JWS. For example, a JWS application cannot launch from the Internet Explorer or Mozilla browser.

  JWS is not an installable feature for the Client and cannot be separately installed by an administrator installer. The installation program lists JWS as one of the non-administrator limitations on Windows systems.

• Windows services limitations

  • The non-root installer cannot create Windows services for any of the WebSphere Application Server processes, including the appserver, the node agent, the deployment manager, the IBM HTTP Server, or the IBM HTTP Server Administrative server.

  • An administrator installer can create the service after the fact using the WASService command.

• Start Menu entry limitations

  Entries in the menu are for the non-administrator installer, but are not available to all users.

• Gnome and KDE menu entry limitations

  Entries in the menus are for the non-root installer instead of being applicable to all users.

• Users and group definition limitations

  IBM HTTP Server Administrative Server configuration creates users and user groups. A root user is required to perform such configuration.

• Installation visibility limitations

  The non-root installer cannot register software packages natively. The installer programs register installed components. ISMP registers installed programs in its vpd.properties file. The installer programs register installed components in the install registry file. Both files are in the home directory of the non-root installer as opposed to being a globally shared resource available to all users.

  In case a non-root or non-administrator user is granted access or visiblity to share install information with a root or administrator user, all install information cannot be accessed in certain scenarios. If the non-root or non-administrator user has previously installed WAS before increased access rights are granted, the scope of the install registry will still be local instead of a global.

  However, if the non-root or non-administrator user has not installed WAS before and access is upgraded, it becomes possible to access global install information generated by a root or admin user.

---

 

Related tasks

Installing the product and additional software

 

Related information

vpd.properties file
Operating system registry keys
Directory conventions
WASService command