CentOS 7 kernel 3.10.0-957.27.2 is now available. Please see RedHat Security Advisory 2019:1873 for more details.

As this update does not include any fixes for remote exploits, we are only updating managed servers with less trusted local users. As most of our clients only have more trusted users within their virtual servers, this means we will only reboot a small minority of the servers we manage.

As usual, we will perform these updates during your scheduled maintenance times while performing any documented per-server custom procedures before and after the reboot.

We now support WordPress 5.2.2.

We will be updating all Managed WordPress Hosting accounts this week following our usual four-round release cycle, with development sites being updated today (Tuesday).

Please thoroughly test your development sites early before updates make it to production update rounds on Thursday and Friday.

As usual, we will perform these updates during your scheduled maintenance times.

CentOS 7 kernel 3.10.0-957.12.2 is now available. Please see RedHat Security Advisory 2019:1168 for more details.

As this update does not include any fixes for remote exploits, we are only updating managed servers with less trusted local users. As most of our clients only have more trusted users within their virtual servers, this means we will only reboot a small minority of the servers we manage.

As usual, we will perform these updates during your scheduled maintenance times while performing any documented per-server custom procedures before and after the reboot.

For Long-Term Support (LTS) versions of Java, we have switched from Oracle's release of OpenJDK to RedHat's releases of OpenJDK (via CentOS).

Oracle does not support the full LTS lifecycle for OpenJDK, whereas RedHat does.

We will continue to use the Oracle OpenJDK for non-LTS versions of Java.

With this change, we have also restored our support of Java 7 (LTS) through its scheduled end-of-life in June 2020.

We have maintained compatibility with existing profile scripts in /opt/jdk-*/profile.sh (for Bourne shells) or /opt/jdk-*/profile.csh (for C shells). The primary difference is the scripts will pick-up the JVM from /usr/lib/jvm/java-*-openjdk-*/ instead of /opt/jdk-*/, but this should be transparent to applications.

For managed servers, we continue to install newer Java releases, work with clients to restart all applications on their schedule, then remove old Java releases once they are no longer used. We never remove a Java release out from under a running application.

We now support Java 12.

Java 12 may be used for any existing application by updating your profile script to include /opt/jdk-12/profile.sh (for Bourne shells) or /opt/jdk-12/profile.csh (for C shells). See this FAQ for more details on how to change Java versions:

https://aoindustries.com/clientarea/FAQ.ao?category=jvms&page=profile

As this is a non-LTS version, Java 12 will be supported until Java 13 is available. At that time, all uses of Java 12 will be automatically updated to Java 13.

We now support Managed MoinMoin Wiki Hosting.

We will install MoinMoin Wiki, then keep MoinMoin Wiki up-to-date on your behalf.

You have full administrative control over your MoinMoin Wiki installation.

We read the changelogs and published version compatibility, but will tend to install all available updates. We will perform a basic test of your site before and after updates, but we cannot accept responsibility for any site breaking due to these updates. We will resolve site problems on billable time, should the client not want to do this themselves.

We support four rounds of updates, nominally with round 1 on Tuesday through round 4 on Friday, but the precise schedule depends on both our workload and the schedule and urgency of the updates. The expected use-case of the four-round cycle is you may choose to have a dev site updated in round 1, then the production site updated in round 3 or 4, giving you a few days to test updates for compatibility during the weekly roll-out cycle.

We backup your MoinMoin Wiki installation (both files and database dump) before and after applying updates. Backup files are available at /var/www/site_name/var/backups/. These backup files are then replicated to additional servers both on-site and off-site per the server's configured file backup policy.

We now support Managed WordPress Hosting.

We will install WordPress, then keep WordPress, and all installed themes and plugins, up-to-date on your behalf.

You have full administrative control over your WordPress installation and may install any desired plugins and themes, including commercial premium themes. For premium themes, we may need to communicate with you regarding where to find changelogs and how to download updates.

We read the changelogs and published version compatibility, but will tend to install all available updates. We will perform a basic test of your site before and after updates, but we cannot accept responsibility for any site breaking due to these updates. We will resolve site problems on billable time, should the client not want to do this themselves.

We support four rounds of updates, nominally with round 1 on Tuesday through round 4 on Friday, but the precise schedule depends on both our workload and the schedule and urgency of the updates. The expected use-case of the four-round cycle is you may choose to have a dev site updated in round 1, then the production site updated in round 3 or 4, giving you a few days to test updates for compatibility during the weekly roll-out cycle.

We backup your WordPress installation (both files and database dump) before and after applying updates. Backup files are available at /var/www/site_name/var/backups/. These backup files are then replicated to additional servers both on-site and off-site per the server's configured file backup policy.

CentOS 7 kernel 3.10.0-957.5.1 is now available. Please see RedHat Security Advisory 2019:0163 for more details.

As this update does not include any fixes for remote exploits, we are only updating managed servers with less trusted local users. As most of our clients only have more trusted users within their virtual servers, this means we will only reboot a small minority of the servers we manage.

As usual, we will perform these updates during your scheduled maintenance times while performing any documented per-server custom procedures before and after the reboot.

PHP 7.0 will be end-of-life on 2019-01-10 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.0 becomes end-of-life:

1. PHP 5.4
2. PHP 7.1
3. PHP 7.2
4. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.0.x to PHP 7.1.x
2. Migrating from PHP 7.1.x to PHP 7.2.x
3. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.0 to PHP 7.1. We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

We have enabled the citext module in all our active PostgreSQL builds:

• PostgreSQL 9.4: citext
• PostgreSQL 9.5: citext
• PostgreSQL 9.6: citext
• PostgreSQL 10: citext
• PostgreSQL 11: citext

We have improved our packaging of Apache Ant:

1. Added Provides "ant" to SPEC file.
2. Now including library dependencies per installation recommendations.
3. Added environment variable ANT_HOME to profile scripts.

PHP 7.1 will be end-of-life on 2019-12-01 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.1 becomes end-of-life:

1. PHP 5.4
2. PHP 7.2
3. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.1.x to PHP 7.2.x
2. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.1 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.1 to PHP 7.2. We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

We now support PostgreSQL 11. We have included the following modules in our build:

1. cube - Used by the earthdistance module.
2. earthdistance - Allows spatial indexing of geographical coordinates - (latitude, longitude) pairs.

Java 10 is now end-of-life.

A supported version of Java must be used for any existing application by updating your profile script. See this FAQ for more details on how to change Java versions:

https://aoindustries.com/clientarea/FAQ.ao?category=jvms&page=profile

Any uses of /opt/jdk-10/profile.* must be updated to either /opt/jdk-lts/profile.* or /opt/jdk-current/profile.* (or a specific newer version), depending on your choice of stability versus features.

Applications that use /opt/jdk-current/profile.* will switch from Java 10 to Java 11 on their next restart.

For all managed servers, we are replacing /opt/jdk-10/profile.* with /opt/jdk-current/profile.*, as Java 10 was a non-LTS version. We are also restarting all applications currently running Java 10, so their profile scripts can select a newer version of Java. We will communicate with you individually and perform these updates during your usual scheduled maintenance times.

PHP 7.0 will be end-of-life on 2019-01-10 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.0 becomes end-of-life:

1. PHP 5.4
2. PHP 7.1
3. PHP 7.2
4. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.0.x to PHP 7.1.x
2. Migrating from PHP 7.1.x to PHP 7.2.x
3. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.0 to PHP 7.1. We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

We now support Python 3.7.

Python 3.7 may be used for any existing user or application by updating your profile script to include /opt/python-3.7/profile.sh (for Bourne shells) or /opt/python-3.7/profile.csh (for C shells).

We now support Python 3.5.

Python 3.5 may be used for any existing user or application by updating your profile script to include /opt/python-3.5/profile.sh (for Bourne shells) or /opt/python-3.5/profile.csh (for C shells).

We now support Java 10.

Java 10 may be used for any existing application by updating your profile script to include /opt/jdk-10/profile.sh (for Bourne shells) or /opt/jdk-10/profile.csh (for C shells). See this FAQ for more details on how to change Java versions:

https://aoindustries.com/clientarea/FAQ.ao?category=jvms&page=profile

As this is a non-LTS version, Java 10 will be supported until Java 11 is available. At that time, all uses of Java 10 will be automatically updated to Java 11.

This will be our last version using the commercial build from Oracle. In the next version, Java 11 LTS, we will be switching to the OpenJDK builds.

Due to Java version numbers no longer beginning with "1.", along with the introduction of "LTS" (long-term support) and non-LTS versions, we have split our jdk1 meta-package into jdk-lts (favoring stability by using the oldest supported LTS Java release) and jdk-current (favoring features by always having the most current Java release).

Any uses of /opt/jdk1/profile.* must be updated to either /opt/jdk-lts/profile.* or /opt/jdk-current/profile.*, depending on your choice of stability versus features.

For all managed servers, we are replacing /opt/jdk1/profile.* with /opt/jdk-lts/profile.*, as the LTS versions best match our previous release cycle. Likewise, new instances of Apache Tomcat will default to jdk-lts.

We now support Tomcat 8.5 in both single-site and multi-site configurations. We have included the latest PostgreSQL JDBC Driver built for Java 8. We have also included the latest MySQL JDBC Driver 8.0.*.

We now support PHP 7.1. We have compiled PHP against PostgreSQL 9.6.

We have removed mcrypt from the build because it is deprecated in PHP 7.1. If this extension is required by your application, please Contact Us.

We now support MySQL 8.0.

We now support PostgreSQL 9.6. We have included the following modules in our build:

1. cube - Used by the earthdistance module.
2. earthdistance - Allows spatial indexing of geographical coordinates - (latitude, longitude) pairs.
3. tsearch2 - Backwards compatibility for applications developed for versions of PostgreSQL prior to 8.3.

PHP 7.0 will be end-of-life on 2019-01-10 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.0 becomes end-of-life:

1. PHP 5.4
2. PHP 7.1
3. PHP 7.2
4. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.0.x to PHP 7.1.x
2. Migrating from PHP 7.1.x to PHP 7.2.x
3. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.0 to PHP 7.1. We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.

PHP 7.0 will be end-of-life on 2019-01-10 per PHP: Supported Versions.

The following versions of PHP will be supported at the time PHP 7.0 becomes end-of-life:

1. PHP 5.4
2. PHP 7.1
3. PHP 7.2
4. PHP 7.3

Please review the following migration guides in preparation for this upgrade:

1. Migrating from PHP 7.0.x to PHP 7.1.x
2. Migrating from PHP 7.1.x to PHP 7.2.x
3. Migrating from PHP 7.2.x to PHP 7.3.x

We will communicate with you individually to coordinate any required upgrades before PHP 7.0 reaches end-of-life.

Once end-of-life is reached, we will upgrade any remaining uses of PHP 7.0 to PHP 7.1. We will carefully review all php.ini files to maintain any customizations through the upgrade. As usual, we will perform these updates during your scheduled maintenance times.