Non-root users can install WebSphere® Application Server Network Deployment 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
the product.
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 the product, 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
There
are various considerations you must examine if you want to install
as a non-root user.
- 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:
- WebSphere Application Server
- IBM HTTP Server
- Web server plug-ins
- DMZ Secure Proxy Server for IBM WebSphere Application Server
- 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 your 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 installations
Silent
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
application server 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.
newfeat
Certain subsequent install operations (SIOs) on
the application server 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 you to determine whether your 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 application server installation.
See Verifying and setting file permissions for more information.
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.
newfeat
In previous versions of the product, 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 the product, 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).
Because a global copy of the GSKit
is no longer installed, if you are using zones on the Solaris operating
system you 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 application server are installed on the same machine
(local installation scenario), non-root installation for the plug-in
component is only supported if the application server was also installed
by the same non-root user. Otherwise the Web server configuration
scripts will fail to run against the application server installation.
- 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 the product must have a valid home directory.
- Port value assignment
- Creating a profile is optional during WebSphere Application Server 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 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 WebSphere Application
Server installations.
Multiple non-root installers diminish the
ability to detect and avoid port value conflicts. WebSphere Application Server installations
are visible to the installer ID only, because the non-root installations
do not register globally. If the root user performs all WebSphere Application Server 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
- 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 WebSphere Application
Server installation 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.
- 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 WebSphere Application Server 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 WebSphere Application
Server 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 WebSphere Application Server
before and access is upgraded, it becomes possible to access global
installation information generated by a root or admin user.
- Temporary files
Non-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.
- Adaptive Fast Path Architecture (AFPA) limitations
FRCA/AFPA
has been deprecated starting with V7.0 and its use is discouraged.
There is no support for Windows Vista, Windows 2008, or any later Windows operating systems.
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 WebSphere Application
Server, are not usually cacheable. Most application servers 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.
- 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 services
limitations
- The non-root installer cannot create Windows services
for any of the WebSphere Application
Server processes, including the application server, 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
- 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 the product and then
non-administrators create profiles, the non-administrators can see
their shortcuts.
- 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. If you want 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
- Uninstalling as an administrator
If
an administrator user uninstalls an application server which is owned
by another user, then all registry entries for all application server
instances owned by the administrator will also be removed. You should
uninstall any non-administrator application server with the owning
non-administrator user if possible.