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.
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.
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:
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.
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:
Access the server with the maint account and check that the following command gives the correct date and time:
To rectify, see 5 - Time synchronisation on the runtime
Access the server with the maint account and enter the following command:
You should see an output along the lines of:
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.