WAS v8.0 > Install the application serving environment > Distributed operating systems > Install the product
Non-root installations
Non-root users can install WAS 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
- Set permissions
- Private GSKit installation
- Non-root limitations
- Uninstallation considerations
Installation considerations
There are various considerations that examine 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 WAS
- DMZ Secure Proxy Server for IBM WAS
- IBM HTTP Server for WAS
- IBM WAS
- Pluggable Application Client for IBM WAS
- Web Server Plug-ins for IBM WAS
- 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.
Set permissions
We 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 Set file permissions for more information.
Restriction: The permissions features are not available on Windows operating systems.
Private GSKit installation
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
We 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 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.
- Operating system 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 WAS installation registry file and the vpd.properties file. All installable components are fully functional despite the lack of native registration.
- 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. The installation registers installed components in the WAS 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 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.
- 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 WAS, 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 WAS processes, including the application server, node agent, dmgr, 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. 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
Uninstall as an administrator: If an administrator user uninstalls an application server that is owned by another user, all registry entries for all appserver 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.
Related
Set file permissions
chutils command