Okay, in PeopleTools 8.53 you can now specify a digital certificate for SSH, not sure if this was there in 8.52, but in the past I would put the SSH keys (private and public) out in the sshkeys folders of the application server and reference them in the URL properties for SFTP configurations.

Well, you can now store these in the digital certificates area and just reference it using the alias key.  In order to make this work you need to generate an ssh key pair.  On a Redhat system you should be able to run:

ssh-keygen

Just follow the prompts.  You will need to have the openssl rpm’s installed.  This should generate and id_rsa and id_rsa.pub file in the users home directory under the .ssh directory.  You will want to append the id_rsa.pub key to the authorized_keys file (create it if it does not exist).

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

chmod 644 ~/.ssh/authorized_keys

You should be able to check you key by issuing the following:

openssl rsa -in ~/.ssh/id_rsa -check

Now here comes the trick, if you try to copy the public and private key from the SSH window on a windows machine and paste it into the digital store, I found that this would cause the certificate to fail.  I had to sftp the private and public key to my local machine and use my trusty UltraEdit to open the files in unix mode and copy and paste the contents into the digital certificates windows.  It appears that when copying in windows mode it uses the CR/LF versus if you have it in Linux mode it will just have the LF.  This appears to make a big difference.  No errors either way except it just won’t work with the windows format.

NOTE:  If you are copying the .ssh directory from one server to another (multiple application servers) make sure that the permissions on this folder are 700.  If you have a separate batch processing server you will want to ensure that it too has the .ssh folder and keys for the assignment user.

The other day, a trainer was in one of my new demo environments setting up for a demo and told me the time was wrong.  However, if you looked at the server the time was bang on except for the fact that it was using the UTC-0 Timezone, which is common for virtualized cloud server because what timezone you want is really up to you.

I was very surprised that PeopleSoft did NOT seem to acknowledge the servers timezone and adjust accordingly.  So in my case, the demo was in the eastern time zone, so I changed the server timezone to America/Toronto.  To do this, I found was a little less than straight forward:

server1 :>   cd /etc

server1 :>   mv /etc/localtime /etc/localtime.orig

server1 :>   ln -s /usr/share/zoneinfo/America/Toronto localtime

There are hundreds of timezones you can set to but for me that one worked great.  If I need to I can revert back to utc-0 by simply moving the localtime.orig back to localtime filename.  Once the change was made the database booted with the correct time and PeopleSoft worked correctly after that.  I tried to figure out from the support site why UTC-0 was not recognized but found no valid answers anywhere.

I was setting up a new environment for a training class and the new server was running on RHEL6.5 with PeopleTools 8.53. The application was a 9.0 application so for ease I just put verity on the server to build the portal registry index search.

The verity install went without a problem. I went in and ran the PORTAL_INDEX AE to build the search index. That went to success! I search for an item and I get no results.

When I search the application server logs I find the following error:

PSAPPSRV.30784 (808) [2014-04-14T01:39:52.074 VP1@{MyIP} (CHROME 34.0.1847.116; MAC) ICScript](0)
Error E0-1509 (Drvr): dlopen() returned: libstdc++.so.5: cannot open shared object file: No such file or directory
Error E0-1510 (Drvr): Error loading driver library ‘/oracle/psoft/pt853/verity/linux/_ilnx21/bin/locuni.so’
Error E0-1203 (Language): Error reading language definition file: /oracle/psoft/pt853/verity/linux/common/frenchv/loc00.lng
Error E0-1230 (Language): Could not create locale frenchv
VeritySrch::search: SessionManager::getSession failed: failed to obtain or create a valid VDK session.

My libstdc++.so.5 is in the 64 bit user library, when I did a little test and added the lib64 to the path, I got ELFCLASS64 error. I flipped over to the root account and install the 32bit library and the problem was solved.

yum install compat-libstdc++-33.i686

When linking COBOL on RHEL Linux x86_64, depending various factors you will most likely have a different gcc library then what is specified in cobopt64 configuration file.

As root change to the $COBDIR/etc directory and modify the cobopt64 file, look for the line:

set GCC_LIB=/usr/lib/gcc/x86_64-redhat-linux/x.x.x

Set x.x.x to the latest gcc version installed on the server at:  /usr/lib/gcc/x86_64-redhat-linux/x.x.x

Working on a new RHEL environment, and when I tried to build an application server and/or trying to start the psadmin tool, I get an error loading libtrio64.so shard libraries.

In my case I added $PS_HOME/bin to the LD_LIBRARY_PATH and everything started working. So in my case I have my LD_LIBRARY_PATH=$ORACLE_HOME/lib:%TUXDIR/lib:$PS_HOME/lib