We have an application that uses a lot of memory when a user takes particular actions. I feel the application should take steps to protect itself - it shouldn’t allow an action from a user which will cause issues. I wasn’t able to influence the application so we lived with occasional out of memory issues, and times where processes could not be forked due to lack of memory.
Back to my series about applying patches to PeopleTools 8.59. I am now visiting the Windows process scheduler. Like the Unix servers, Oracle installs all the software, so it all needs to be patched. But there are always additional complications with Windows.
If the same procedure as Unix is followed to download Java, we end up with an
executable installer. The only silent install option is /s - there is no
way to specify the folder it ends up in. Also this does a Windows install
updating the registry etc. It’s likely not to want to have two copies of the
same Java in different locations.
Now we have the core PeopleSoft stack communicating encrypting traffic, we need to address the add-ons. Elastic search is becoming more important, and it is difficult to use PeopleSoft without it. Here is how to add encryption to Elastic Search and Kibana.
There is two way communication between Elastic search and PeopleSoft, Both of these directions need to be configured. Fortunately we have already done some of this work.
This procedure is documented in PeopleBooks under Products -> Development Tools -> Search Technology -> Working with PeopleSoft Search Framework Security Features. Here are links for Elasticsearch and Kibana
Here is an interesting problem we had recently. A field which should be length 1 was being reported in some cases to be length 4. How is this possible?
I use dbms_sql.describe_columns to discover the size of the field in a
remote database. I use this value to recreate a copy of the view in the
remote database as a table locally. This is used for testing.
We can mimic this in the local database as follows:
Further to my last article about applying critical patches to the web server, lets take a look at the application and database servers.
In my mind WebLogic runs on the web tier, and Tuxedo runs on the Application and process scheduler tier. The Oracle Client is also on the Application and process scheduler tier. However, since these and Java are installed on all tiers, we should apply the patches on all tiers.
As I write this it is a month after Oracle released the critical patch updates, but there is still no sign of the Infra DPK, which contains Java and WebLogic updates. If Oracle are not going to supply this patch reliably, we will have to work out how to do it ourselves.
In a default install we can do the following as user psadm1:
In the last article we looked at encrypting communication between WebLogic and the load balancer. Now it is time to investigate the traffic between WebLogic and the Application server. Without this configuration the logs get filled with messages like this:
WARNING: LLE Configuration discovered!
Note that LLE has been deprecated.
You should upgrade to SSL to secure network links.
Let’s upgrade to SSL then!
We already discussed TLS with regards to the Integration Broker and the Web Server. The application server conceptually works in the same way, but it (mostly) isn’t written in Java, so in practice the procedure is slightly different.
In the past we used to assume communication on our network was protected by physical security. Now that seems not to be a reasonable assumption. So we should probably encrypt communication within PeopleSoft. Here is how I do that.
We control both ends of communication between tiers of PeopleSoft. So we can create our own certificate authority, and instruct our software to trust it.
We need a root certificate for our Certificate Authority (CA). I created it as follows: