Non-root installation

Non-root users can install WAS ND in both silent and interactive mode for full product installations and removals, incremental feature installations, and silent profile creation. 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. Significant enhancements have been made to non-root installation in the current version of WAS ND.

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, unless the owner reassigns ownership of the appropriate 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.

The set of post-installation operations that are subject to this rule includes installing a feature (incremental installation), installing maintenance, uninstalling WAS ND, and installing a customized installation package (CIP) created with the IBM WebSphere Installation Factory on top of an existing installation in a slip installation.

The full installer programs and the Update Installer (UPDI) check to verify that the current installer is also the owner of the installed files.

• Installation considerations
• Verifying and setting permissions
• Private GSKit installation
• Non-root limitations
• Uninstallation considerations

 

Installation considerations

There are various considerations examine to install as a non-root user.

• Non-root installations apply to all of the WebSphere software components in WAS packageNon-root installers can install all of the components, including:

  • WAS
  • IBM HTTP Server
  • Web server plug-ins
  • DMZ Secure Proxy Server for IBM WAS

  • Application Client
  • 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 the home directory

  Default installation locations are within the home directory of the non-root installer to verify a writable disk space. 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. 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 the root user 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.

 

Verifying and setting permissions

New feature: A major enhancement to non-root support for the appserver is the ability to verify and set file permissions. Users can now verify adequate file permissions before installing the product, and can use a utility to change ownership to another user for the file system after installation for future operations on that product

Certain subsequent install operations (SIOs) on the appserver can now be attempted and performed by other users, whether root or non-root. SIOs include installing features, edition upgrades, fix packs, and slip installs of customized installation packages created with the IBM Installation Factory. New utilities allow us to determine whether the user has sufficient file permissions to perform a subsequent installation operation successfully before the operation begins, and to change owner and group file permissions on a targeted appserver installation.

(Windows) Restriction: The permissions features are not currently available on Windows operating systems.

 

Private GSKit installation

New feature: IBM HTTP Server and the Web server plug-ins installers now install a private copy of IBM Global Security Kit (GSKit) which allows both root and non-root users to enable SSL support

In previous versions of WAS ND, IBM Global Security Kit (GSKit) was installed as a global installation by the IBM HTTP Server and Web server plug-ins installers and was shared among all registered applications. The only supported GSKit installation method was to run the native installation package as a root user. In the current version of WAS ND, a private copy of GSKit is installed as part of the IBM HTTP Server and Web server plug-ins installations which allows non-root users to perform complete installations that include SSL support.

The GSKit package is installed to the gsk7 directory within the installing product’s root directory.

The private copy of GSKit is maintained through GSKit update packages delivered in IBM HTTP Server and Web server plug-in fix packs.

Fix packs are applied using the Update Installer (UPDI).

[Solaris]

Because a global copy of the GSKit is no longer installed, if we are using zones on the Solaris operating system we can now use the private GSKit without a zone-writable /usr directory. In previous releases, GSKit had to be installed manually in the global zone before installing IBM HTTP Server or plug-in in a non-global zone.

 

Non-root limitations

There are some limitations and differences when installing as a non-root user as opposed to a root user.

• Local Web server plug-in installation

  When the Web server plug-in and the appserver are installed on the same machine (local installation scenario), non-root installation for the plug-in component is only supported if the appserver was also installed by the same non-root user. Otherwise the Web server configuration scripts will fail to run against the appserver installation.

• [AIX] [HP-UX] [Linux] [Solaris]

  Home directories

  You cannot successfully complete certain post-installation tasks if the installing non-root user does not have a home directory defined. Any user installing and using WAS must have a valid home directory.

• Port value assignment

  • Create a profile is optional during WAS ND 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 nonconflicting port values. The installation program assigns appropriate port values to a non-root installer, such as greater than 1024, for example.

  • 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 InstallShield Multi-Platform (ISMP) registration

  • [AIX] [HP-UX] [Linux] [Solaris]

    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 installation registry file and the vpd.properties file. All installable components are fully functional despite the lack of native registration.

  • [HP-UX] 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.

  • (Windows) 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.

• Installation visibility

  The non-root installer cannot register software packages natively. However, ISMP registers installed programs in its vpd.properties file, while the installer programs register installed components in the WAS installation 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 visibility to share installation information with a root or administrator user, all installation 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 installation registry will still be local instead of 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 installation information generated by a root or admin user.

• Temporary filesNon-root users installing on Solaris might experience errors accessing temporary files left in the /var/tmp directory from a previous installation attempt by another user, as seen in the installation log:

  Process, com.ibm.ws.install.ni.ismp.actions.FeaturePanelControlAction, err, java.io.FileNotFoundException:
  /var/tmp/normalFeaturePanelControl.xml (Permission denied)
  

  Manually delete all *Control.xml files in the tmp directory before running the installation program.

• (Windows) 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 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-administrator installers that AFPA is not installed.

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

• Edge Components

  Edge requires root privileges because of its native installation mechanisms.

• (Windows) Java™ Web Start

  The Application Client 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 Firefox 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) Windows services limitations

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

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

• Menu limitations

  • (Windows) Start menu entries

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

    If an administrator installs WAS and then non-administrators create profiles, the non-administrators can see their shortcuts.

  • (Linux) Gnome and KDE menu entries

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

    Normally, menu items are only visible to the installing user. To allow other users who create profiles to see menu items for their profiles, they must have access to a copy of the base WebSphere#.menu file. All profile shortcuts are visible to all users who have access to the base WebSphere#.menu file. Copy this file into either the /etc/xdg/menus/applications-merged directory (for all users) or the user's $HOME/.config/menus/applications-merged directory. Make sure there are no conflicts between the menu file names in the /etc/xdg/menus/applications-merged directory and any user's $HOME/.config/menus/applications-merged directory.

 

Uninstallation considerations

• (Windows) Uninstall as an administrator

  If an administrator user uninstalls an appserver which is owned by another user, then all registry entries for all appserver instances owned by the administrator will also be removed. You should uninstall any non-administrator appserver with the owning non-administrator user if possible.

---

Subtopics

Verifying and setting file permissions

 

Related

vpd.properties file
Operating system registry keys