After many years of working with PeopleSoft I try not to get to worried about the little things, because so much changes every day that you could lose your mind trying to keep track of it all.

I was doing an install of the Oracle Database software on a new RHEL 5.8 server the other day and I could not get my X11 forwarding working.  Now I don’t claim to be an expert in SSH and never will be, but I use the Bitvise Tunnelier and then use XMing for the SSH/X11 client software.  On this server I had setup the SSH Daemon to run X11 forward on using the default off-set 10.  This basically means that the communication for X11 will be on port 6010 instead of 6000. This means that your display variable will need to be set differently.  This is the export command I used:

export DISPLAY=localhost:10.0

In a lot of cases it will just show you 0.0, but because of the offset you need to change to 10.0 when using the off-set of 10. When setting up my SSH connection in Tunnelier, under the terminal tab, you need to enable X11 forwarding, and you will need to change your Display variable appropriately, in my case I was using the offset: 10, so I entered:

127.0.0.1:10.0

Lastly, I found that the XMing client defaults to NO offset, so when I launched XMING launch, on the first page it asks what the offset should be be.  Once I changed that to 10, everything started working great.

It should also be noted that if you are using a firewall (in my case iptables) you will want to make sure port 6010 is open correctly if using the ssh-offset 10.

The common error I got with this configuration being wrong as: Windows TCP error code 10061.

When creating a new server the other day, I was attempting to start the application server and a ran into an odd error message that did not seem to have any solution from PeopleSoft’s support or even google for that matter. This error was found in the stderr output file for the application server:

ERROR: dlopen in libpscompat failed for ‘libpsora.so’: libclntsh.so.10.1: wrong ELF class: ELFCLASS32

I couldn’t find anything specifically wrong with the symbolic links in the library directories for Oracle as the sites were suggesting.  The weird thing that kept the red flag waving was ELFCLASS32.  After some more review of the environment I had just created, I found that I had installed the Oracle Database software using a 32bit Linux version instead of the Linux_x86_64 bit version.  This was caused by simply not paying attention when I was downloading the software.  When downloading the software if you try to download from the main site they only let you download 11.2.0.1, but for PeopleTools 8.52.xx you want to be at 11.2.0.3.  After logging into support and search for patchset 11.2.0.3 the page that comes up has a drop down, and there is a Linux version and a Linux_x86_64 bit version (much further down).  After I installed the correct version and recreated the database, the application server started without any issues.

I ran into a weird problem where I was unable to install PIA (PeopleSoft Internet Architecture) through the delivered install tools (PsMpPIAInstall or PSADMIN).  It kept getting about 90% complete and then drop out and report an error saying PIA failed to install.

I was not able to find out much about the error, but what I did find was that I was missing a bunch of libraries specifically in my case WLST classes.  As it turned out I had been cleaning up a bad install of another product and deleted the utils directory from the BEA home.

I re-installed the weblogic 10.3.0.4 version on the server into a new BEA home, and everything worked fine after that.

I found several cases that report multiple reasons for the failure but in the end the only thing that remained constant was re-install and everything works again.  There are several directories that weblogic installs with that are necessary in order to make PIA install work.

Error:  java.lang.RuntimeException: Could not find the OffLine WLST class

When doing the install you can issue the parameter: -debug -DDEBUG=true and that will issue thousands of information rows, but it does give some idea where the issue is.

I believe with release of PeopleTools 8.44, they introduced a new feature that requires a user id for internal web server communication to load web profile information from the database and also performance agent information.

By default PeopleSoft delivered the product with the default userid PTWEBSERVER.  Which uses a default delivered role of “PeopleTools Web Server”, which links to the delivered permission list “PTPT1500”.

When you build your PIA (PeopleSoft Internet Architecture) you will be asked to enter a userid and password for this internal web server communication.  If the information is incorrect you will often see the error: “CHECK APPSERVER LOGS. THE SITE BOOTED WITH INTERNAL DEFAULT SETTINGS, BECAUSE OF: bea.jolt.ApplicationException: TPESVCFAIL – application level service failure”.

This user information is stored in the configuration.properties file, which is located in the:

<webserv root>/applications/peoplesoft/PORTAL.war/WEB-INF/psftdocs/<piasite>/ folder (for weblogic)

You will notice that the userid/password are encrypted.  This encryption is done using the PSCipher utility that is delivered with the pia.  I haven’t verified this but in past releases you could enter the userid and password unencrypted and it worked fine, however, I always encrypt them now, so I have tested this against 8.5x.  It should also be noted that the userid and password are both case-sensitive.

To encrypt the password use the PSCipher script located at <webserv root>/bin. PeopleTools 8.51 moved utility files to the folder <webserv root>/piabin. I usually run the setENV first (however, it usually does it for you now) and then run PSCipher <newpasstoencrypt>.  It will return an Encrypted password in the form:   {V1.1}xxxxxxxxxxx= copy this password and place it into the configuration.properties file.

If you are still experiencing a problem, make sure that the user you are trying to connect with has the correct password entered into the user security screens, and that the account is unlocked.

With the release of the 8.51 Tools they also introduced a password for the domain.  You set this password in the configuration of the application server, and you have to enter it for things like integration broker and also in the PIA web configuration.  This password is encrypted the same way in the configuration.properties file.

Happy Configuring!

Every now and then I find that I am battling permission issues in the unix environment and it usually turns out to be the permissions that are set on the directory or file.  Unix has an interesting way of handling permissions.  If you do a list command “ls -l” you will see a box of information on the left that looks like:

———- (10 dashes) If you see this, the file has NO rights (pretty rare).

The first position you will commonly see a “d” or “l”, the “d” is for directory, and “l” is for a link.

Position 2 to 4 are the owner permissions “rwx”, where “r” is read, “w” is write, “x” is execute

Position 5 to 7 are the group permissions “rwx”, where “r” is read, “w” is write, “x” is execute

Position 8 to 10 are the world permissions “rwx”, where “r” is read, “w” is write, “x” is execute

You can change the permissions using the command: “chmod”

To grant the read permission you give a value of 4, write permission is 2, and execute is 1.  So if you want to grant read+write, you would do 4+2 = 6.  And when you issue the chmod you give it a number for each permission (owner, group and world), so if you wanted to give the owner, group and world read and write access to a file you would issue the command:

chmod 666 filenametochangepermissionsto

Another useful function is the chown function, which changes the owner and/or group permission.

chown user:group filenametochangeownershipto
chown -R user:group directorytochangeownershiptorecursivelyto