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:
PeopleSoft in general leaves it to the administrator to ensure that digital certificates are set up properly. Given digital certificates don’t tend to change very often, and the provider changes even less frequently, it can be difficult to understand and remember how this works, and prevent issues.
There are two parts to a digital certificate. One part is the private key which is used to encrypt data, and is installed, in our case, on the load balancer. It is important to keep this safe so nobody can impersonate our system. The public key is what we are mostly dealing with here. This is available to anyone and can be used to decrypt the data, and check it came from someone we trust.
Our WebLogic server recently crashed. There were a number of issues identified in the post mortem, which were addressed to prevent the same thing happening again. It also occurred to us that WebLogic should restart itself automatically if it fell over. This is easily achieved using systemd, but for whatever reason Oracle chose not to configure it to do this.
This is a PeopleSoft system which might be configured slightly differently to other
WebLogic installations. PeopleSoft
by default provides a systemd unit file which is mostly copyright warnings, so I won’t
include it here. Oracle have created a
legacy init.d file which is called by systemd as a oneshot. This in turn calls the startPIA.sh and stopPIA.sh scripts
as appropriate. So if the web server crashes, it stays stopped.
The University has a Single Sign On (SSO) system. There are a number of ways that it can be used. In this case I am investigating the use of Security Assertion Markup Language (SAML). There is also Shibboleth which is related, and our SSO can also use, but I will leave that till another time.
I am creating a test application running in django on my desktop. Django by default only listens on the loopback interface which means it can provide friendly information to developers safe in the knowledge that anyone who can view it is logged on to my desktop. Sites are identified using their URL, so I need to add a unique hostname. I edited /etc/hosts and added myhost.local as a hostname to the end of the line that starts 127.0.0.1. Now I can visit http://myhost.local:8000 in my web browser and get to my test website.
I am trying to gather some information about an environment once it has been created and save it in a small Django app. This is about my adventures trying to discover the Weblogic version from the it’s registry which is an XML file.
The XML registry is in the Oracle inventory, and starts like this:
| |
I’d like to extract the WebLogic Server version which is on line 4.
As I don’t know XML it’s tempting to use grep and sed to find the information I want, but I notice
there is an XML module in Ansible. It is community maintained, and
it’s not stable, so it’s behaviour might change. This is valid from versions between 2.4 and 4,
maybe later.