Wednesday, 5 May 2010

Running WebSphere Portal as a non-root user

This is a Work-In-Progress article, and I'm sure to make changes as I go through the next few days.

One of my clients has a requirement to run WebSphere Portal 6.1.5 as a non-root user on Linux, which is fairly standard. In most production environments, organisations are reluctant to release the root user's password to anyone, and control often remains with the hardware/OS administrators, whereas WebSphere etc. lives up at the application level.

In my scenario, I have installed WebSphere Portal Enable 6.1.5 *as* root; installing as non-root is far more tricksy, and requires one to install WebSphere Application Server as root, change the permissions of the newly installed WAS, and then install WebSphere Portal into the existing WAS environment.

This is far better explained here: -

In my case, I did the installation, as root, using the standard installation wizard, which lays down WAS, Portal/WCM etc.

Once installed, I did the following - as root: -
  1. Created an ibmusers group

    groupadd ibmusers
  2. Created an ibmuser account ( as a member of the ibmusers group )

    useradd -g ibmusers ibmuser
  3. Set the password for the ibmuser account

    passwd ibmuser
  4. Set permissions for the /opt directory structure for the ibmusers group - on my system, this is ONLY used by WebSphere

    chmod -R g+rwx /opt/IBM
    chgrp -R ibmusers /opt/IBM
     
  5. Set permissions for the /tmp directory structure for the ibmusers group

    chmod -R g+wr /tmp
    chgrp -R ibmusers /tmp

  6. Set permissions for the /var/tmp directory structure for the ibmusers group

    chmod -R g+wr /var/tmp
    chgrp -R ibmusers /var/tmp
I then ran the following tests: -

  • Having checked, as root, that WebSphere Portal was stopped - using the serverStatus.sh command, I logged in as ibmuser and navigated to the following directories: -

    /tmp
    /var/tmp
    /opt/IBM/WebSphere/AppServer/log

    and verified that I could create/edit/delete files using the touch, vi and rm commands
     
  • Again, as ibmuser, I then used the startServer.sh and stopServer.sh commands to start and stop WebSphere Portal
     
  • Having run up the server, again as ibmuser, I checked that I could view and delete the logs in: -

    /opt/IBM/WebSphere/AppServer/profiles/wp_profile/logs 
     
Having done all of the above, I performed one final test: -
  •  I rebooted the server, and logged on from the Gnome login panel as ibmuser and ran through the same tests as before, just to ensure that there were no root permissions hanging around :-)
I did hit one small, but semi-obvious, snag - when I rebooted the server at a later stage, I was unable to log in to Gnome as root; to be more precise, I was able to log in, but received a whole host of Gnome errors, implying that it couldn't talk to the network, even though I could see that eth0 had a valid IP address and that I could ping the server's hostname.

Given that I'd made a change to the permissions of /tmp, I though that there might be lock files etc. hanging around. I changed the runlevel to 3 to fully kill the X11 server, via the init 3 command, cleared the contents of /tmp using the command rm -Rf /tmp/* and then restarted X11 using the command init 5.


When I logged into Gnome as root, all was well.


So far, so good. The next test is to add a new user to the ibmusers group and see whether I can run through the same set of tests again.



2 comments:

Unknown said...

Did you made good expiriences with this?
What about patching? Does it still work?

Dave Hay said...

Yes, it worked perfectly well, including fix packs etc.

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...