When updating CentOS it can be very useful as a sysadmin to compare the incoming update package versions against the currently installed version. However this isn't an overly easy task as the installed version numbers are not printed out in the resulting dnf/yum update summary table.

Updates coming in can be seen in the summary table by running 

dnf update

However a safer command (as you have to rememeber to cancel the command) is:

After 8+ years of running EVE Online on Linux with great success, recently there have been major changes to the nvidia and vulkan libraries causing some issues. Along with the changes on EVE Client towards DX11 and 64bit upgrades there has been a few hurdles to keep EVE running smoothly.

On the 26th Feb 2020 CCP turned off the ability to launch and use 32bit clients so any reference to 32bit installations here is for historical purposes and won't work.

After updating one of my VPS's I experienced the adrenaline rush of rebooting, waiting, panicking and rolling back a kernel update. Normally updates on CentOS are stable and nothing to worry about. However after all the fast patches to the kernel due to the new Intel/CPU based vulnerabilities I was rightly cautious to run the updates on a non-vital server first.

Kernel Update 3.10.0-693.17.1.el7 was the culprit, and as of today (2018-02-12) the CentOS repos including Plus still haven't pushed a fixed version.

Having been a linux system administrator for quite some time, one of the main annoyances has been fixing changed files when the package maintainers have also added to them. Mostly this can be avoided by using the package.d/custom.conf settings files, however sometimes we are forced to make changes to the core package files.

On the last update the following conflicts came up on one of our systems:

After the Owncloud PHP-FPM script name bug, i've found Drupal 8's update.php script uses a similar routing convention to OwnCloud's index.php/app/files.

With the generic ProxyPassMatch directive the response is a 404 Not Found for the second page of the update process update.php/selection:

ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9001/app/$1

This can be fixed by adding an explicit match statement for the update script:

Recently updated my Raspberry Pi 2 running Arch Linux through pacman -Syu. This pulled in the latest versions of Apache 2.4 and PHP 7, normally staying on the same major version doesn't introduce any breaking changes, however this time all the PHP based applications stopped working.

OwnCloud was one which started a redirect 302 loop on the login page and the Sync Client also stopped working. The actual setup is quite basic, Owncloud installed though pacman -S owncloud