Non-root users can install the product 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. However, there are limitations. In
the current version of WebSphere Application Server Network
Deployment, the IBM HTTP Server, or the Web server plug-ins components,
a non-root installation does not install the GSKit security components
needed by the IBM HTTP Server or the Web server plug-ins for SSL support.
As a result, you must have root access to install the GSKit to use
SSL communication. Also, non-root installation for the plug-in component
is only supported if WebSphere Application Server 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.
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 (a CIP from the Install
Factory) on top of an existing installation in a slip installation.
Guidelines for installing WebSphere Application Server as a non-Administrator on Microsoft® Windows Vista™ and Windows 2008 operating systems:
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
- 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. 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 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 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.
Limitations and differences
There are some
limitations and differences when installing as a non-root user as
opposed to a root user.
- Port value assignment limitations
- 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 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 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.
Operating system and ISMP registration limitationsRegistry
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.
Adaptive Fast Path Architecture (AFPA) limitationsAFPA
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 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-adminstrator
installers that AFPA is not installed.
- Edge Components limitations
Edge requires root privileges
because of its native installation mechanisms.
Web Start limitationsApplication
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 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 HTTP Server Administrative server.
- An administrator installer can create the service
after the fact using the WASService command.
- Menu limitations
Start menu entry limitationsEntries
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 entry limitations 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.
- 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 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 a 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.
- Profile Management Tool limitation
If you install multiple instances of WebSphere Application Server
as the root user and give a non-root user access to only a subset
of those instances, the Profile Management Tool does not function
correctly for the non-root user. In addition, a com.ibm.wsspi.profile.WSProfileException or Access
is denied message occurs in the app_server_root/logs/manageprofiles/pmt.log file.
By default, non-root users do not have access to the program file
directories, which is the default installation location for the product.
To resolve this issue, the non-root user can install the product or
be given permission to access the other product instances.