Sunday, 26 July 2020

Oracle CPU downloader

Every quarter I have to go through and download numerous patches for the Oracle CPU (Critical Patch Update). You have to view the CPU document on MOS, click on numerous links to get to the correct software, version, OS etc. and then click the links for each patch you require click the link to download and then click the link to actually download., and so it goes on.

So as per usual, you get to the point when you've had enough. Each application now requires multiple downloads, WebLogic Server, 4 patches, Portal 4-5 patches, database 3 patches, you get the picture.

So I decided to at least automate the downloading of patches.

You can download my script here, and use it as your own risk.

CSV File

You start by editing the CSV file and entering certain details about the patch.

Patch ID

Enter the Patch ID from the CPU page


This is the CPU date or the old style patch version or can be left blank. I personally only use the YYMM format when using the CPU style. If you don't want the CPU to be used to define the output folder name then leave blank. This is used to create the folder name for each Group, see below.


This has two purposes. First is to make it easier to see which Patch ID you need to update later on in the next CPU cycle. Second, the script uses it for a message when the patch isn't found in the patch recommendations XML file.


This is used to group patches together, for example, a group name of Portal will create a Portal folder and download multiple patches to the same folder. See example below.

OS (Linux-x86-64 | MSWIN-x86-64) for Generic leave blank

A lot of the patches are Generic, i.e. not OS specific, and some patches are OS specific. In this case you can define an optional 5th field too define which OS version of the patch you wish to download.

My sample CSV file, for the July 2020 CPU, looks like this...

# Patch ID, CPU|Version|blank, Description, Group, OS (Linux-x86-64 | MSWIN-x86-64) for Generic leave blank
# Portal,,,,
31390302,2007,WebCenter - Content,Portal,
31481845,2007,WebCenter - Portal,Portal,
31441160,2007,WebCenter - ADF,Portal,
31403376,2007,WebCenter - Core,Portal,
# WLS,,,,
31384951,2007,WLS - SPU,WLS,
31470751,2007,WLS - Coherence,WLS,
31544340,2007,WLS - ADR,WLS,Linux-x86-64
31544340,2007,WLS - ADR,WLS,MSWIN-x86-64
# WLS,,,,
31384959,2007,WLS - SPU,WLS,
31470730,2007,WLS - Coherence,WLS,
31544353,2007,WLS - ADR,WLS,Linux-x86-64
31544353,2007,WLS - ADR,WLS,MSWIN-x86-64
# Primavera,,,,
31541012,20,P6 18.8 EPPM,P6,
31618417,20,P6 18.8 Pro,P6_Pro,
31497173,7,P6 19.12 EPPM,P6,
31618148,7,P6 19.12 Pro,P6_Pro,
# RDBMS 11g,,,,
31326405,2007,DB 11g PSU OJVM Combo,RDBMS,Linux-x86-64
31302572,2007,DB 11g OH JDK,RDBMS,Linux-x86-64
30508206,2007,DB 11g OH Perl,RDBMS,Linux-x86-64
# RDBMS 12.1,,,,
31326396,2007,DB 12.1 PSU OJVM Combo,RDBMS,Linux-x86-64
31302525,2007,DB 12.1 OH JDK,RDBMS,Linux-x86-64
30508171,2007,DB 12.1 OH Perl,RDBMS,Linux-x86-64
# RDBMS 12.1 Windows,,,,
31211574,2007,DB 12.1 PSU,RDBMS_WIN,MSWIN-x86-64
31465095,2007,DB 12.1 OJVM,RDBMS_WIN,MSWIN-x86-64
# RDBMS 12.2,,,,
31326379,2007,DB 12.2 PSU OJVM Combo,RDBMS,Linux-x86-64
31302499,2007,DB 12.2 OH JDK,RDBMS,Linux-x86-64
30508161,2007,DB 12.2 OH Perl,RDBMS,Linux-x86-64
# RDBMS 19c,,,,
31326362,2007,DB 19 RU OJVM Combo,RDBMS,Linux-x86-64
31301460,2007,DB 19 OH JDK,RDBMS,Linux-x86-64
29511771,2007,DB 19 OH Perl,RDBMS,Linux-x86-64

As you can see I group a number of different patches together so that they all download into the same folder. My Portal Group downloads Portal, Content, ADF and Core into the same folder.

Folder Names

Talking of folder names, I use the information in the CSV file to create the folders.

If CPU field is not empty I create the folder as Group_Version.CPU, if the Group field is empty I just use the Group to create the folder.

So a line like this: 31390302,2007,WebCenter - Content,Portal,

Will create the folder: Portal_12.

The version is retrieved from the recommendations file for each patch.

Configuration File

There is a configuration file with two options, one is optional.


This defines where the script will create the patch folders under.

From the above example, if you were to set outputFolderBase to OraMedia/Patches the script would download the Portal patches into OraMedia/Patches/Portal_12.


The script will prompt you for your MOS username each time you run it. You can define this setting in the configuration file and it will stop you from being prompted every time. useful if it's only you that ever runs the script.

Running the script

So we are finally set, we have defined outputFolderBase and optionally, oraEmail in the configuration file.

This script can be run from the patch-downloader folder or from elsewhere, it will find its configuration and CSV files etc.

The script will firstly ask you to authenticate to MOS. Assuming that was successful, it will then under two conditions download the patch recommendations XML file it uses to get the URLs for the patches.

Either the patch recommendations XML file doesn't exist or it is over 30 days old. It does this by downloading the OEM catalog zip file into outoutFolderBase/OEM/Catalog and extracting the files/data it requires to work.

Iterating over your CSV file, the script will attempt to work out the download URL, version and bundle name and then download the file into the correct patch directory.

Not all patches are listed in the patch recommendations XML file. For these missing patches the script will search for the patch number and download its individual XML fie to get the same information and download the patch as usual.

If the patch file already exists it will not attempt to download it again. So if a patch fails you will need to delete the file to force the script to download it again.

At the moment this script will not download OPatch or Java files as they are not part of the patch recommendations file and don't have individual patch XML files. Maybe in the next version of the script.

Friday, 3 July 2020

Oracle 19c / as sysdba to PDB

Up until now I, like most others, have when attempting to connect as sys to a PDB have used either:

. oraenv -s

sqlplus / as sysdba

SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         4 TEST                           READ WRITE NO
         6 TEST2                          READ WRITE NO

SQL> alter session set container=TEST;
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         4 TEST                           READ WRITE NO
or this, ensuring I have a TNSNames.ora alias set for TEST:

sqlplus sys/sys-pwd@test

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         4 TEST                           READ WRITE NO

Well I've just learnt another, easier, way to connect as sys directly to a PDB. This seems to be new to 19c, I've tried with 12c and it doesn't work.

. oraenv -s


sqlplus / as sysdba

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         4 TEST                           READ WRITE NO

It's this new variable ORACLE_PDB_SID that does the magic.

You are now connected directly to the PDB from the command line and not having to enter the sys password.

I haven't tried this on Windows but I assume that it will work as well.

Saturday, 22 February 2020

Veyon (Part 1) - Introduction and my system setup

Please note this is a draft and will be altered as necessary

In this series of blogs I'm working through setting up and using Veyon. Later blog posts will include configuring Veyon from the CLI and integrating Veyon with LDAP.

From the website: Veyon is a free and Open Source software for computer monitoring and classroom management supporting Linux and Windows.

1. Veyon (Part 1) - Introduction and my system setup (this blog post).
2. Veyon (Part 2) - Configure basic setup and authentication keys.
3. Veyon (Part 3) - Using the CLI (coming soon).
4. Veyon (Part 4) - Using LDAP (coming soon).

I will update these blog posts as and when I learn more or realise that I assume too much or have just got it all plan wrong.


In this post I'm going to show how to install Veyon, on both Linux and Windows.

I’m using Zorin OS 15 Ultimate for the master and a mixture of Windows 10 and Zorin OS 15 Education.

Veyon has two pieces of software, the configurator and the master. The configurator is used to configure Veyon on the master, or teachers, computer. The master is the Veyon runtime software and is used on the master computer to monitor and control the classroom computers.

Veyon Configurator application


Download Veyon for Windows and Linux

Downloads for Windows, mac and Linux can be found here.

Download the software for your operating system.


Download the latest stable version for Windows, usually 64 bit, but a 32 bit version is available.

When installing Veyon as a client on a Windows machine you need to deselect “Veyon Master”

Veyon client installation on Windows


Some distributions have Veyon available via their package managers.

Search for Veyon via your Linux package manager or from the command line.
apt list veyon
You should get something like this back.
 veyon/bionic,now 4.3.0-1~bionic amd64
To install run the following and after a while you will be returned to the command prompt and be able to start confguring Veyon. 
sudo apt install -y veyon
If Veyon isn’t listed in your package manager then you can do one of two things.

1. Add the Veyon PPA repository to apt and install Veyon 
sudo add-apt-repository ppa:veyon/stable
sudo apt install -y veyon
2. You can go to here and download Veyon manually for your respective Linux distribution.

Authentication keys and Linux/Windows groups

As I'm going to be using authentication keys as part of this setup I will need to either create groups to control access to the Veyon Configurator or use built-in groups.

As part of my setup I'm going to use two groups whilst configuring and running Veyon.

I will create the group veyon-master, only on the master machine, and will allow access to Veyon's master software. On client machines I will create the group veyon-client on the client machines and add users to the group or set it as a default group that every user will receive.

A quote from the documentation.
Then an access group must be set for both private and public keys. Only users who are to be allowed to access computers using Veyon Master should be member of the access group set for private keys. The public key should be assigned to a global access group so that the key is readable for all users and the operating system.

Linux - Master

As root run the following commands to create the group and add your user to the group.
groupadd veyon-master
usermod -aG veyon-master $USER
 You will have to logout and back in again to get the group membership. You can test that you have the new group membership by typing id.

To enable us to specify the public keys group we will need to create the veyon-client group on the master as well, see below.

Linux - Client

On the client, as root, we will create the client group and then alter the system to add that group, by default, to any new user create on the system.
groupadd veyon-client
usermod -aG veyon-client $USER
We can create a new user and add our group from the command line using the following command.
useradd client1 -G veyon-client

If we instead use the adduser command we can automate the inclusion of the new group by default to all new users. The file we need to alter, for Debian based Linux distributions, is /etc/adduser.conf. We can either edit the file and alter the settings or use sed to script the changes.

The two lines we need to alter or add are ADD_EXTRA_GROUPS and EXTRA_GROUPS. From the comments in /etc/adduser.conf.

ADD_EXTRA_GROUPS -  If ADD_EXTRA_GROUPS is set to something non-zero, the EXTRA_GROUPS option will be default behaviour for adding new, non-system users.

EXTRA_GROUPS - This is the list of groups that new non-system users will be added to.
So uncomment both lines and add veyon-client to the list of groups in EXTRA_GROUPS.

As I enjoy using the command line and sed, you can use the following command to edit the above file, assuming that the lines in the file haven't already been altered.
sed -i -e 's/#ADD_EXTRA_GROUPS=.*/ADD_EXTRA_GROUPS=1/g' -e '/#EXTRA_GROUPS="/s/#EXTRA_GROUPS="/EXTRA_GROUPS="veyon-client /' /etc/adduser.conf
EXTRA_GROUPS should now read something like this.
EXTRA_GROUPS="veyon-client dialout cdrom floppy audio video plugdev users games"

You can now go ahead and test this by creating a new user, using adduser not useradd, and checking that it automatically has the veyon-client group membership.

grep veyon /etc/group

Now we have Veyon installed we can move onto part 2, configuring Veyon master and configuring the client.

Thursday, 23 January 2020

Veyon (Part 2) - Configure basic setup and authentication keys

Please note this is a draft and will be altered as necessary

In this series of blogs I'm working through setting up and using Veyon. Later blog posts will include configuring Veyon from the CLI and integrating Veyon with LDAP.

From the website: Veyon is a free and Open Source software for computer monitoring and classroom management supporting Linux and Windows.

1. Veyon (Part 1) - Introduction and my system setup.
2. Veyon (Part 2) - Configure basic setup and authentication keys (this blog post).
3. Veyon (Part 3) - Using the CLI (coming soon).
4. Veyon (Part 4) - Using LDAP (coming soon).

I will update these blog posts as and when I learn more or realise that I assume too much or have just got it all plan wrong.

In part 1, the introduction, I went through setting up Veyon on both the master machine and client machines. In this blog I'm going to use the GUI to configure Veyon.

Configuration files, CLI or manually

The settings can be imported via configuration files using the CLI or running individual commands using the CLI. So you can configure Veyon for the master or client and then save and load different configuration files. I’d suggest that you create two configuration files, one for the clients and the other for the master especially if you are going to alter a number of settings and/or have a number of machines to configure or rebuild.

Storing the client configuration file in a central place will allow the scripting of configuring a client machine each day or week via the Veyon CLI and say Linux cron or Windows Task manager.

Configure Veyon on the master

Once Veyon is installed on the master machine you will need to configure Veyon. Here I’m planning on leaving most of the settings as their default. In fact I'm going to alter one setting and create the authentication keys.

To run Veyon’s Configurator by either searching for it in the start menu or by running the command veyon-configurator, as root, from the command line.

Change Veyon settings

As said before I’m not going to alter many settings, in fact I’ll change only one setting.

On the General tab, change the Authentication Method to Key file authentication.

Alter Key Authentication Method to key file authentication
Alter Key Authentication Method to key file authentication

When you click on Apply, Veyon will save the configuration and ask whether to restart the Veyon service or not, click Yes.

Here is a good time to save the client configuration file. Press File->Save settings to file.

Chose your location and save the file with a meaningful name, e.g. Veyon-Client. Later on, once we have defined our rooms and computers we will save the configuration again but to a master file.

Create authentication keys

On the Authentication keys tab, click on Create key pair and enter the name of the user group or role you are creating the keys for. Most documentation suggests that you call it teacher and I think that at the moment it uses it for the file names it generates.

See the documentation for more information on using more than one key pair and access controls for groups and access rules.

Now we want to alter the access group allowed to use the teacher private key. Access to this key allows a user to run Veyon master and access/view all the defined rooms and computers.

On both Windows and Linux you can create a group and add users to the group to restrict who can run the master and login successfully with the private key.

In part 1 we created the groups veyon-master and veyon-client, shown below, and will now set the keys to the correct group access. If the groups aren't created on the master then we will get an error.
sudo groupadd veyon-master
sudo usermod -aG veyon-master $USER
We will need to logout and back in again to gain access to the groups to run the master software, but before we do that we will alter Veyon’s private and public keys to use the new groups.

Select the teacher private key, press Set access group and change the group from root to veyon-master. Do the same for the public key but set the group to veyon-client.

Set authentication key access group

We now need to export the public key to use on the client machines.

Select the teacher public key and press Export key.

Accept the default filename (teacher_public_key.pem) and save the file. You will need the Veyon installation file, the optional client configuration file and this key file to complete the client installation later, so save to a USB key or central location.

Apply the changes and say Yes to restarting the service. 

Install and configure Veyon on the client

See above for installing Veyon on Windows and Linux. Ensure that on Windows you do not install Veyon master on the client machines.

Run the Configurator and either import the client settings or alter the client to use Key file authentication.

Then we will import the public key. Go to the Authentication keys tab, press Import key and open the teacher_public_key.pem file exported earlier from the master machine.

Public authentication key imported into the client

Whilst at the client machine, note down the location and the clients IP address. You may also want to record that clients MAC address, this will allow Veyon to start the client machine remotely, assuming that you have wake on LAN setup on the clients.

Most Linux machines use "ip address" to show the IP address, older clients used ifconfig. Windows uses ipconfig or "netsh interface ip show config" or probably even PowerShell.

Rooms, machines and IP addresses

Next we need to define or rooms and machines. As this software is designed schools and colleges it allows us to define rooms (class rooms) and computers in each room.

Go to Locations and computers tab and create locations and computers for your set up.

My test setup, for example is:

Location: Downstairs
Computer: PC
Host address/IP:

Location: Upstairs
Computer: PC
Host address/IP: 192.168.136

Location: Upstairs
Computer: Laptop
Host address/IP:

Once complete, Apply settings and restart the Veyon service.

Run Veyon

Now that you have the clients setup with the configuration and public key and the master configured correctly we can start up Veyon master and monitor our clients.

Find Veyon Master in the menus or activities or run veyon-master from the command line.

Click on Location and & computers in the bottom-left hand corner of the app. You can now see your locations and computers.

We can select client machines and see a thumbnail of the actual screen and then monitor, control or take over one or every machine using the buttons across the top of the master application.

You can see the user documentation here for using the master software.

So now you are good to go. Veyon master is configured and the clients are using the authentication key to communicate back to the master.

In the part 3 on this series I'm going to show how many of the tasks completed in the GUI can be achieved from the command line.

Oracle CPU downloader

Every quarter I have to go through and download numerous patches for the Oracle CPU (Critical Patch Update). You have to view the CPU docume...