OpenAthens LA support ended on 31 March 2020

Search

Skip to end of metadata
Go to start of metadata

Patching

The OpenAthens LA servers use many components to support the operation of the OpenAthens LA software (e.g. Apache websever, OpenSSL) and keeping those components up to date is important to ensure that none of them leave you or your users vulnerable to security exploits. 

There are three elements to patching the OpenAthens LA servers and software.

Security patches

You should regularly update all internet facing servers and doing so monthly is sufficient in most cases.

Occasionally there may be urgent patches that need to be applied - e.g. the so-called 'heart-bleed' patch. In such cases you will be alerted by our service desk and you should update as soon as possible, especially on runtimes because they are internet facing. The announcement will tell you how.

New versions of OpenAthens LA

When these are released, you will see an alert in the administration console, and will receive announcements from us. Except where releases address security issues, you will have about a year before the previous version leaves support.

Patch cycle

If you have an existing patch cycle for servers, including OpenAthens LA in that is encouraged.

If you do not yet have one, once per month is reasonable.

How to apply a patch

This is covered in more detail on the generic upgrade page, but in short:

On Linux servers, log in and run the command:

sudo yum update

This will update all the software on the server. The command first checks which updates are available then asks you to confirm you want to continue.

On Windows servers, the only relevant components that Windows Update will not take care of are the OpenAthens software, and Java.

Monitoring

If you have monitoring software, it is ok to add it to the servers to monitor things like diskspace.

If you want to check manually:

Clock synchronisation

Access the server with the maint account and check that the following command gives the correct date and time:

date

To rectify, see 5 - Time synchronisation on the runtime

Diskspace

Access the server with the maint account and enter the following command:

df -h

You should see an output along the lines of:

Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   14G  1.2G   12G  10% /
tmpfs                         947M     0  947M   0% /dev/shm
/dev/sda1                     477M  146M  306M  33% /boot

It's the first line you are usually interested in.

What to do if there is very little diskspace left

If your runtime has been happily running for a couple of years, then archiving or deleting old logs should be sufficient  - see: Where the logs are on the servers.

If you have enabled debug level logging and not disabled it, the logs will be considerably larger than expected. To turn debug logging on or off, see: Server logging level

If you are really busy, you will need to decide between allocating more disk space to the runtime, or adding additional runtimes in a load balanced environment.

  • No labels