KUSANAGI Module Updates

The individual modules that make up KUSANAGI have been updated.
The updated module versions are as follows:

OpenSSL 1.0.2o
httpd 2.4.33 (OpenSSL 1.0.2o)
nginx 1.13.9 (OpenSSL 1.0.2o)
PHP7 7.2.4

To enable the aforementioned features, execute the following command:

# yum update

Includes security update, we recomend to update as soon as possible.
PHP 7.2.4
OpenSSL 1.0.2o

Please reboot middlewares. OpenSSL was updated and rebuild related middlewares.
Example: nginx and php7

kusanagi php7
kusanagi nginx

These command show whether OpenSSL’s update is applied to middlewares.

# /usr/local/openssl/bin/openssl version
OpenSSL 1.0.2o  27 Mar 2018
# strings /usr/local/lib64/httpd/modules/mod_ssl.so  | grep -E 'OpenSSL\s+1[.0-9a-z]+' | uniq
OpenSSL 1.0.2o  27 Mar 2018
# nginx -V 2>&1 | grep OpenSSL
built with OpenSSL 1.0.2o  27 Mar 2018
# php7 -i | grep -i 'OpenSSL Library Version'
OpenSSL Library Version => OpenSSL 1.0.2o  27 Mar 2018

KUSANAGI Module Updates

The modules that composed KUSANAGI had been updated. The new versions are as follows.

httpd 2.4.33

Use the following command to update modules.

# yum update

Includes security update by httpd. Recomend to update as soon as possible.
https://httpd.apache.org/security/vulnerabilities_24.html

If an error message shows when you execute kusanagi httpd command, please execute the following command:

# kusanagi httpd

Warning: httpd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
# systemctl daemon-reload
# kusanagi httpd

KUSANAGI Module Updates

The modules that composed KUSANAGI had been updated. The new versions are as follows.

PHP7 7.2.3
APCu 5.1.11
apcu_bc 1.0.4

Use the following command to update modules.

# yum update

PHP 7.0 will be PHP 7.2, if you get error when you update, you can revert to the previous version with the following command.

# yum downgrade kusanagi-php7

Please check mcrypt If you have errors when you use PHP7.2 . mcrypt was removed from PHP7.2. Recommend to use OpenSSL.

If you need to use mcrypt, you can download it from PECL and import it.

KUSANAGI Module Updates

The individual modules that make up KUSANAGI have been updated.
The updated module versions are as follows:

nginx 1.13.9

nginx1.13.9 includes new function ‘Server Push’.

The module update can be applied with the following comand:

# yum update

KUSANAGI Update 8.2.0

KUSANAGI Update 8.2.0

PostgreSQL can now be used with KUSANAGI. In addition to the existing Maria DB database option, uses can now choose PostgreSQL.

PostgreSQL 9.6.7
Pgpool-II 3.7.2

Database selection can be done during KUSANAGI initialization(kusanagi init), and there is now a new command, kusanagi dbinit.

Please check this kusanagi document for details about kusanagi dbinit.

For those using older versions, running the command below with root privileges will update KUSANAGI to 8.2.0.

# yum update

KUSANAGI Update 8.1.2-6

KUSANAGI Update 8.1.2-6

KUSANAGI 8.1.2-6 update with bug fix has been released.

For those using version 8.1.2-5 and earlier, running the command below with root privileges will update KUSANAGI to 8.1.2-6.

# yum update

If you have just performed the most recent update and the leftover cache causes a “no pakages marked for update” error, use the following command and then perform a yum update.

# yum clean all

Bugfixes in KUSANAGI 8.1.2-6

8.1.2-6 fixes the following issues:

If the Mroonga WordPress plugin is enabled, the ‘kusanagi addon remove mroonga’ will succeed, even though it should not.

In version 8.1.2-5 and earlier, there was a bug where removing the WordPress plugin Mroonga from MariaDB while it is activate only deletes the table data and leaves the index and other metadata intact, when it gets deactivated using ’kusanagi addon remove mroonga’.

Thus a new table would not get created after ractivating Mroonga.

This issue was fixed in KUSANAGI 8.1.2-6.

In KUSANAGI 8.1.2-6, on a website provisioned with WordPress on KUSANAGI with an active Mroonga plugin, attempting to remove Mroonga will result in the error message below. Deactivating the Mroonga plugin from profile name ‘xxxxx’ WordPress site and running the remove command again will succeed.

# kusanagi addon remove mroonga
Mroonga WordPress plugin is activated.
Please deactivate mroonga plugin from 'xxxxx' Profile.
add-on remove was aborted
# 

KUSANAGI Update 8.1.2-5

KUSANAGI Update 8.1.2-5

The KUSANAGI 8.1.2-5 update with bug fixes has been released.

For those using version 8.1.2-4 and earlier, running the command below with root privileges will update KUSANAGI to 8.1.2-5.

# yum update

If you have just performed the most recent update and the leftover cache causes a “no packages marked for update” error, use the following command and then perform a yum update.

# yum clean all

Bugfixes in KUSANAGI 8.1.2-5

8.1.2-5 fixes the following issues:

Failure to upgrade MariaDB during kusanagi init

During kusanagi init, there have been cases where referencing the MariaDB10.0 package cache causes upgrading MariaDB10.1 to fail.
This bug has been fixed in KUSANAGI-8.1.2-5.

If there are issues running commands

Redoing kusanagi init after updating to 8.1.2-5 is the most surefire solution, but the method below will also work:

Delete the existing MariaDB package.

# yum remove -y 'MariaDB*' galera

Check the file /etc/yum.repos.d/MariaDB.repo

baseurl = http://yum.mariadb.org/10.0/centos7-amd64
If you see this line, change it to the one below:
baseurl = http://yum.mariadb.org/10.1/centos7-amd64

# yum clean all
# yum install -y MariaDB-devel MariaDB-client MariaDB-server

If the KUSANAGI settings are written in the /etc/my.cnf.d/server.cnf.rpmsave file, copy the [mysql] contents from /etc/my.cnf.d/server.cnf.rpmsave to the [mysqld] contents of /etc/my.cnf.d/server.cnf.

Last, restart MariaDB.

systemctl restart mysql

KUSANAGI for GCP is now available

KUSANAGI for GCP is now available.

Please see the guide at KUSANAGI for GCP

KUSANAGI module update

The modules that composed KUSANAGI had been updated. The new versions are as follows.

PHP7 7.0.13

Use the following command to update modules.

# yum update

Simply Fast WordPress [16] – Enabling Always-On SSL and HTTP/2 on an existing HTTP WordPress site (Part 2: Application)

This is a series of articles explaining how to speed up WordPress, the use of which is growing rapidly for CMS-based business sites and media sites. This time, we will explain step-by-step how to implement Always-On SSL and HTTP/2 on an existing HTTP WordPress site.

Last time, as preparation for enabling HTTP/2 and Always-On SSL, we explained how to migrate an existing WordPress site over to KUSANAGI. This time, we will show how to enable HTTP/2 and Always-On SSL on sites already running on KUSANAGI.

If you just started reading this blog from this article or you have a WordPress site that is not running on KUSANAGI, please read the back issue “Enabling Always-On SSL and HTTP/2 on an existing HTTP WordPress site (Part 1: Preparation)” and follow the instructions from step 1.