SSL: Create a cert7.db Certificate Database

The Smart Panda - NSS&NSPRIn the old days of PeopleSoft you needed to create a cert7.db database file in order to do things like LDAPS. However, to create an cert7.db file requires very old software because this format is very uncommon today. I have found you can create a cert7.db file using Netscape v4.7.3 or earlier according to various websites. However, I am very suspect of downloading old versions of software. There is an old toolset NSS (Network Security Services) & NSPR (Netscape Portable Runtime) available from Netscape (Mozilla) which does a nice job in creating the cert7.db.

To download I found you want to get version: NSS v3.4.2 and NSPR v4.1.2 use the Mozilla FTP site:
https://ftp.mozilla.org/pub/security/nss/releases/
https://ftp.mozilla.org/pub/nspr/releases/

I unzipped the files to separate directories, and then used a command prompt to setup the PATH to include both directories library’s:

SET PATH=%PATH%;%NSS_PATH%/lib;%PATH%;%NSPR_PATH%/lib

From the \bin directory, we need to run the certutil to create a new NSS Certificate Database:

certutil -N -d c:\temp\certdbfolder

To Add The Root CA Certificate:

certutil -A -n MyCA -d c:\temp\certdbfolder -i CA.cert -t C,C,C

To Add The Server Certificate:

certutil -A -n MyServer -d c:\temp\certdbfolder -i server.cert -t P

In order to use the cert7.db in the PeopleSoft Application Server, depending on your Tools & Application level you will want to put the files cert7.db & key3.db & secmod.db in the Application Server Domain root directory or in a folder “cert” in the root directory.

Pivot Grid: Generic Error Query Datasource

Pivot Grid: Setup Issue

Pivot Grid supports operational dashboard reporting within the Oracle PeopleSoft PeopleTools framework to provide a pivot table and chart representation of data using PeopleSoft Query data source. The framework also enables users to see different views of the data as in an Microsoft Excel pivot table, and the same data is also available in a chart view.

When doing a recent upgrade for a client they were experiencing issues opening up some pages in the Billing module.  The reason was that the Pivot Grid popups for the page were generating the error:

Generic error while executing the Query datasource. (268,91)

Interestingly, this error was only occurring in my Oracle Database systems.  No errors were being generated in SQL Server.  It would appear that there is a corruption in the data load for the data sources of the Pivot Grid.  In order to resolve this, My Oracle Support (MOS) recommends that you do the following:

Step 1:

Smart Panda - Pivot Grid ViewLogin with a super user who has ‘PivotGridAdmin’ role. This role can be added from the navigation: PeopleTools > Security > User Profiles > User Profiles – Roles page.

Step 2:

Navigate to Reporting Tools > Pivot Grid > Pivot Grid Wizard.

Step 3:

Open up the following Pivot Grids in the Pivot Grid Wizard and just move through steps 1 to 5 (no changes are necessary) and then save the pivot grid:

For Billing:

BI_BILLS_BY_STATUS_PVG
BI_CUST_IVC_PVG
BI_CUST_IVC_PVG2
BI_IVC_ANALYSIS_PVG
BI_LOC_PENDING_DRAW
BI_POST_IVC_PVG

For Accounts Payable:

AP_DB_VENDOR_LIABILITY
AP_S360_DB_VENDOR_BALANCE
AP_S360_DISCOUNTS
AP_S360_DB_AMOUNT_BY_STATUS
AP_PYCYCL_PGV
AP_S360_MATCH_EXCEPTION
AP_DB_AMOUNT_BY_STATUS

Step 4:

Retest the issue.

HTTP Port In Use Already

What do you mean the Web Server can’t start

httpsThere is nothing more fun then logging into your windows servers and there are more new patches to install to fix security problems and as per usual Windows must reboot.  I have Redhat servers that have never been rebooted but my Windows machines regularly have to rebooted just because.  Nothing frustrates me more as an administrator then rebooting servers, so many bad things can happen when you reboot.

For example on the weekend my servers were forced to restart and when they came back online my Web Server was down because the HTTP port was in use by another service.  This is odd because I didn’t install anything new however in my case it turned out to be the KDC proxy service that was installed when I did some changes to my remote desktop services.

In order to figure out what service was causing the problem in this case, there is a nice quick trick you can use to figure out what services rely on the HTTP and HTTPs ports.  From a command prompt if you issue the command:

net stop http

This will list out all the services that will be impacted when you execute this command.  In my case I don’t need the KDC proxy service to be running, so I shut down the service, and I was able to bring the WebLogic server online and my client was able to login to their environment from the web again.

PeopleTools: Long/Lob & DataTime Datatype Issues

Recently, I was working on a PeopleTools 8.44 to 8.54 Upgrade and ran into some major issues with the fact that the database so far behind in so many areas.  On the Oracle platform PeopleSoft changed the way it handled Long datatype fields and also how it handled Date & Time datatype fields.  The  part that I found was very difficult was some of the scripts that are more current don’t seem to take into account that coming from 8.44 might be an issue in handling these different datatypes.

Basically, in order to make this upgrade work I did a 8.44 to 8.53 upgrade first, and made sure that the LONG TO LOB datatype conversion was ran before the upgrade and that the DATABASE_OPTIONS field on PSSTATUS was set to 34 datatype setting.  Otherwise I ran into all sorts of weird issues with datatypes.

DATE and DATETIME, LONG and LOB fields in PeopleSoft and Oracle database

In PeopleTools 8.49 and earlier, Datetime and time fields are stored as DATE datatype in Oracle database. For example, you could see a DATETIME or a TIME field in Application designer might show as a DATE field in the Oracle database. Similar issues could be seen with LONG, CLOB and LOB datatype fields as well.From PeopleSoft PeopleTools 8.50 and higher, the TIMESTAMP datatype is now supported for TIME and DATETIME field types. These datatype changes are mandatory, and the DATE datatype will no longer be used for the  DATETIME and DATE datatype fields.Updating the Database for Timestamp:
This is a separate step performed during an application or tools upgrade. This step invokes a SQL statement called UPGDBOPTIONS_ENABLETIMESTAMP.SQL from PS_HOME/scripts folder. This DMS script updates the database to indicate that the new TIMESTAMP datatype is now enabled. If the upgrade is performed through PeopleSoft Change Assistant(as it should be), the step is displayed and can be run only if the upgrade is from PeopleSoft PeopleTools 8.49 or earlier.

What does this step do?
Why the DATE, TIME and DATETIME formats chosen in PeopleSoft application designer show as DATE field in the database and how is this controlled?
This feature is controlled by the DATABASE_OPTIONS field in  PSSTATUS record.
DATABASE_OPTIONS field can store four different values:

  1. 0 – PeopleSoft is using the old datatypes (Long fields and Legacy Unicode implementation).
  2. 2 – PeopleSoft is using the new Oracle datatypes supported with PT8.48 (LOBs and CLS Unicode implementation).
  3. 32 – PeopleSoft is using old datatypes, (LONGs and Legacy Unicode implementation) with TIMESTAMP post PT8.50 conversion enabled.
  4. 34 – PeopleSoft is using the new Oracle datatypes supported with PT8.48 (LONGs and Legacy Unicode implementation) with TIMESTAMP post PT8.50 conversion enabled.
PeopleTools Version and Features supported:
  1. Datatypes supported with PT8.48 – LOBs and CLS Unicode implementation
  2. Datatypes supported with PT8.50 – TIMESTAMP enabled
Depending upon which version of PeopleTools is installed and what features are enabled, an appropriate number from 0, 2, 32 and 34 will be updated while running this step.

Oracle: UDE-00008: operation generated ORACLE error 31626

Yesterday, I was working with Oracle’s data pump export tool, which is something I don’t normally do. I am not really sure why Oracle is so difficult to work with in regards to backing up, migration of data and recovery of data. I mean it is just flat out confusing when you don’t do it on a regular bases.

So I ran into all sorts of weird errors. The first one was:

ORA-23603: STREAMS enqueue aborted due to low SGA – after some research I found that the my SGA area was too small, which in my opinion “Who Cares” you are simply dumping data to a flat file why in the world does that need to be complicated, but….

The quick google search turned up to increase the streams_pool_size parameter and increase the SGA memory target area. The first change I needed to make was to increase the sysctl parameter to as this parameter defines the maximum size in bytes of a single shared memory segment that a Linux process can allocate in its virtual address space. So I modified the sysctl.conf file and increased my kernel.shmmax paramter and set the change active with the sysctl -p call. You need to shutdown/start the database for this change to be made. I also modified the init.ora file to increase the streams_pool_size parameter.

It took a couple of tries to get everything to run correctly, however, the last run I did presented me with the UDE-00008 error. What the heck, everything looks great, so again another google search reveals a novel idea: check the logs:

Master table “SYSTEM”.”SYS_EXPORT_FULL_02? successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_FULL_02 is:
/oracle/datadump/fs92demo.dmp
Job “SYSTEM”.”SYS_EXPORT_FULL_02? successfully completed at Wed Jun 17 11:13:53 2015 elapsed 0 00:41:17

Well, what do we have here. Everything completed successfully. Apparently there is a glitch in Oracle’s data pump that sometimes appears randomly however, the job has ran successfully. Simply ignore the error and move on! If you want to read up on the bug apparently the bug number on Oracle is: 5969934. I honestly, didn’t take the time to read it.