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 edition upgrades. 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.
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
except under one of the following conditions:
- Installation Manager and the product were installed in group mode.
- The owner reassigns ownership of the appropriate directories and
files to another user.
The set of post-installation operations that are subject to this
rule includes installing a feature, upgrading a trial or from Express® to the base product,
installing maintenance, and uninstalling the product.
Installation considerations
There
are various considerations that 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 the following:
- Application Client for IBM® WebSphere Application Server
- DMZ Secure Proxy Server for IBM WebSphere Application Server
- IBM HTTP Server for WebSphere Application Server
- IBM WebSphere Application Server
- Pluggable Application Client for IBM WebSphere Application Server
- Web Server Plug-ins for IBM WebSphere Application Server
- WebSphere Customization
Toolbox
- Non-root installations install an operational product
If
some portion of an installation requires root privileges, Installation
Manager provides an option so that the non-root installer can install
an operational product without enabling the privileged option whenever
possible.
- Installation Manager identifies root-only options
Installation
Manager clearly identifies 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. Installation Manager verifies
that specified disk locations are writable.
Setting permissions
Note: You
can use the chutils utility to change ownership
to another user for the file system after installation for future
operations on that product.
Certain subsequent installation
operations (SIOs) on the application server can be attempted and performed
by other users, whether root or non-root. SIOs include installing
features, edition upgrades, and fix packs.
See Setting file permissions for more information.
Restriction: The permissions features are
not available on Windows operating systems.
Private GSKit installation
Note: Installing IBM HTTP Server and the Web Server
Plug-ins installs a private copy of IBM Global
Security Kit (GSKit), which allows both root and non-root users to
enable SSL support.
The GSKit package is installed to the gsk8 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.
If you are using zones
on the Solaris operating system, you can use the private GSKit without
a zone-writable /usr directory.
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 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
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.
- Operating system registration
- Installation visibility
The non-root installer cannot
register software packages natively. The installation registers installed
components in the WebSphere Application
Server installation registry file. The file is 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 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.
- 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.
- 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, node
agent, deployment manager, IBM HTTP
Server, or 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-root installer, but they are not available to
all users.
If an administrator installs the product and then
non-root users 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.
- chutils command
The chutils command
should be run by a root user.
Uninstallation
considerations
Uninstalling as an administrator:
If an administrator user uninstalls an application server that is
owned by another user, all registry entries for all application server
instances owned by the administrator are also be removed. You should
uninstall any non-root application server with the owning non-administrator
user if possible.