Maintain multiple profiles on Solaris
If you created additional portal profiles or augmented existing default profiles with WebSphere Portal, the profiles now share the product installed files (binary files); therefore, any updates must be coordinated with the users of the various profiles because these updates can affect the run time behavior of each profile. You must stop all servers across all profiles sharing the same set of binary files while the updates are occurring. Similarly, if the product binary files are shared across several systems supporting their own portal profiles, all IBM WebSphere Portal instances across these servers should be stopped during the update process. It is also probable that updates to each profile will be needed, especially in the case of product maintenance application. Updates to the profiles might require that application server instances be restarted in those profiles. In this case, user traffic can be prevented to these server instances during the maintenance window by temporarily removing the target servers from any web servers or load balancers.
When additional portal profiles are based on shared product binary files across multiple servers, it is requires that the shared file system containing the product binary files are shared at the same location on each server and that the location reflects the original installation location, so that the install location is consistent across each profile configuration. For instance, if WebSphere Portal is installed under...
/opt/IBM/WebSphere
...then that directory must be shared with other systems as...
/opt/IBM/WebSphere
To maintain additional portal profiles:
- Modify the web servers or load balancer that routes requests to the appservers in these profiles to temporarily quiesce traffic to these servers, if applicable.
- Stop all application server instances of each profile:
./stopServer.sh WebSphere_Portal -username wpadmin -password foo
- If the profiles are federated to a cell, on each node, run...
./stopNode.sh -username wpadmin -password foo
- Apply the changes to the product binary files as appropriate, such as product maintenance for WAS or WebSphere Portal.
Applying WebSphere Portal maintenance will automatically update the initial profile created by product installation (wp_profile). When product binary files are shared across multiple machines, it is assumes that the default installed profile, wp_profile, is present on the source server from which these product binary files are shared. This sharing allows wp_profile to be updated when the product binary files are updated. Follow the instructions included with the product maintenance and the product update installer for updating the product binary files and the default wp_profile profile. Customer supplied binary files, such as custom JAR files, properties files, or other file system updates, must be added to the binary files at this time as well.
- Apply changes to each profile.
Depending on the change required, we might have to start the application server instances. If WebSphere Portal maintenance is applied to the profile, instructions are provided with the fix on how to update just a profile without reapplying the updates to the product binary files. Customer supplied updates to enterprise applications, portlets, and other J2EE resource configurations must be applied at this time as well.
- After updating each profile, verify the change. Then start any stopped servers and, if applicable, the nodeagent, and then return user traffic to the application server instances.