Here you will find the answers to the most frequently asked questions about KUSANAGI. There is also some additional information regarding how to use KUSANAGI.
Q1. I tried to connect via FTP but failed. Are there any other ways to upload files?
A1. For security measures, KUSANAGI does not allow external FTP connection in its initial setup. We recommend using a software that supports SSH (SFTP) connection, such as WinSCP or FileZilla.
For connection setup, please refer to “Q2. Please tell me how to set up the connection to transfer files to KUSANAGI using an SFTP client”.
Q2. Please tell me how to set up the connection to transfer files to KUSANAGI using an SFTP client.
A2. Please set up the connection as follows.
Host name: example.com (same as the host name for SSH connection) Username: kusanagi Password: [the password for user “kusanagi” that was set at the time of installation]
Examples for FileZilla and WinSCP
Filezilla
WinSCP
Q3. I was asked for FTP connection information when I tried to add or update plugins and themes or update WordPress itself.
A3. For security measures, KUSANAGI has put restrictions on access rights to each directory. This is why you will be asked to enter FTP information when you try to add or update plugins and themes or update WordPress itself.
Please enter the following information and proceed.
Host name: localhost Username: kusanagi Password: [the password for user “kusanagi” that was set at the time of installation]
Q4. Can I change the instance of the virtual machine after KUSANAGI is set up?
A4. Yes, you can. However, to optimize settings, you will need to run the following command using the new instance after launching the virtual machine and logging in via SSH.
# kusanagi configure
Q5. When I try to update yum, an error is displayed and I can’t update.
A5-1. If you see a message like the one below, you need to update kusanagi-php7.
Example of error messages
Error: Package: kusanagi-php7-7.4.21-1.noarch (kusanagi)
Requires: libonig.so.105()(64bit)
As per the following command, please specify the repository to be added when updating yum, and update kusanagi-php7 first.
# yum clean all # yum --enablerepo=remi,remi-php56 update -y kusanagi-php7
A5-2. If a message like the following is displayed, the remi package may be required for processing package dependencies.
Example of error messages You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Please specify the repository to be updated when updating with yum, as shown in the following command.
# yum clean all # yum --enablerepo=remi,remi-php56 update -y
A5-3. If you see a message like the one below, it’s because MariaDB 10.1 and 10.3 have been removed from the repository.
Example of error messages http://yum.mariadb.org/10.1/centos7-amd64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
Support for MariaDB 10.1 ended in October 2020, and support for MariaDB 10.3 ended in May 2023, and they have been removed from the MariaDB repository.
It is still in the archive repository, so confirm to see if the following content is in /etc/yum.repos.d/MariaDB.repo.
For MariaDB 10.0 baseurl = http://yum.mariadb.org/10.0/centos7-amd64 For MariaDB 10.1 baseurl = http://yum.mariadb.org/10.1/centos7-amd64 For MariaDB 10.3 baseurl = http://yum.mariadb.org/10.3/centos7-amd64
After confirming, you can update using the yum command by replacing the following content.
For MariaDB 10.0 baseurl = https://archive.mariadb.org/mariadb-10.0/yum/centos7-amd64/ For MariaDB 10.1 baseurl = https://archive.mariadb.org/mariadb-10.1/yum/centos7-amd64 For MariaDB 10.3 baseurl = https://archive.mariadb.org/yum/10.3/centos7-amd64
However, MariaDB 10.1 and MariaDB 10.3 will not be updated, so we recommend upgrading to 10.5.
You can perform the upgrade using the kusanagi upgrade mariadb command.
A5-4. If you see a message like the one below, the error may be caused by a change in the Let’s Encrypt root certificate.
Example of error messages failure: repodata/repomd.xml from kusanagi: [Errno 256] No more mirrors to try. https://repo.prime-strategy.co.jp/rpm/noarch/repodata/repomd.xml: [Errno 14] curl#60 - "The certificate issuer's certificate has expired. Check your system date and time."
As per the following command, please exclude repositories that fail authentication when updating yum, and update the ca-certificates module first.
# yum clean all # yum update -y --disablerepo=kusanagi,mariadb ca-certificates
After updating the ca-certificates module with the above command, remove disablerepo and execute yum update as usual.
A5-5. If a message similar to the following is displayed, an error may have occurred due to the status of the virtual server, cloud service, or repository.
Example of error messages [Errno 14] HTTP Error 404 - Not Found
If an error message is displayed and the yum update fails, please run the following command and try the update again.
# yum clean all # yum --enablerepo=remi,remi-php56 update -y
You may be able to update by repeating the above command several times.
If you still can’t update, please wait a while and then try updating again.
A5-6. If you see a message like the one below, it’s because CentOS 7 has been removed from the repository.
Example of error messages Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"
Support for CentOS 7 ended in June 2024 and it has been removed from the CentOS repository.
It is still available in the archive repository, so it is possible to access it by switching repositories.
You can update the repository information by executing the following three commands sequentially.
# sed -i 's|^mirrorlist=|#mirrorlist=|' /etc/yum.repos.d/CentOS-*.repo # sed -i 's|^#baseurl=|baseurl=|' /etc/yum.repos.d/CentOS-*.repo # sed -i 's|^baseurl=http://mirror.|baseurl=http://vault.|' /etc/yum.repos.d/CentOS-*.repo
After executing the above three commands, please execute yum again.
However, since CentOS 7 will never be updated, we recommend upgrading to KUSANAGI 9.
For the upgrade procedures, please refer to End of life KUSANAGI 8 / KUSANAGI 9 on CentOS Stream 8.
Q6. The yum update failed. What should I do?
A6. According to the state of your virtual machine server or cloud service, the following error may occur while updating yum.
[Errno 14] HTTP Error 404 - Not Found
If this error appears, enter the following commands and attempt the update again.
# yum clean all # yum --enablerepo=remi,remi-php56 update -y
You may have to do this several times before it updates successfully.
Q7. I couldn’t implement a session, is there another way to do so?
A7. In certain versions of KUSANAGI, the directory for saving PHP sessions may not have the proper authorization. Enter the following command to change the authorization.
# chown -R :www /var/lib/php/session/
Q8. Can the Shibboleth module be used with Apache in KUSANAGI Business Edition?
A8. Yes, you can.
For information on how to set this up, please refer to the Shibboleth Authentication Settings.
If /usr/lib64/shibboleth/mod_shib_24.so does not exist on the server, please execute the following command.
# kusanagi addon remove shibboleth # yum clean all # kusanagi addon install shibboleth
Q9. When setting up or updating a Let’s Encrypt certificate, certbot-auto messages are output.
A9. If you see a message like the one below, updating KUSANAGI will stop the message from appearing.
# kusanagi update cert Your system is not supported by certbot-auto anymore. certbot-auto and its Certbot installation will no longer receive updates. You will not receive any bug fixes including those fixing server compatibility or security problems.
You can update KUSANAGI using the following command.
If you see a message from certbot-auto and are unable to set up or renew your Let’s Encrypt certificate, please try again after updating.
# yum update -y kusanagi
Q10. If you are having trouble switching from nginx to Apache with kusanagi httpd, how should you respond?
A10. The following message may appear.
Example of error messages AH00526: Syntax error on line 5 of /etc/httpd/conf.d/ssl.conf: Cannot define multiple Listeners on the same IP:port ERROR: It has not been changed or restarted to httpd.
In that case, change the extension of /etc/httpd/conf.d/ssl.conf to something other than .conf and then execute kusanagi httpd again.
# mv /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.bak # kusanagi httpd
Q11. The latest image of KUSANAGI for Vagrant has been released, but it doesn’t update automatically.
A11. Even if the latest Box (image) is published in Vagrant, it will not be downloaded automatically.
To download the latest Box for KUSANAGI for Vagrant, please run the following command on the host side.
# vagrant box update --box primestrategy/kusanagi
The latest Box that you have downloaded will not be reflected in the KUSANAGI for Vagrant environment that has already been built.
This is because when KUSANAGI for Vagrant builds an environment, it makes a copy from the Box that exists at that time.
In order to build a KUSANAGI for Vagrant environment from the latest Box, you will need to either work in a separate directory or recreate the environment.
Q12. Is there any way to use an older version of MariaDB?
A12. In KUSANAGI 8.6 and later, the default database that is initialized using the kusanagi init command has been changed to MariaDB 10.5.
If you want to use MariaDB 10.3 as the default database, specify --dbversion 10.3 in the kusanagi init command.
Please note that MariaDB 10.1 has been discontinued in KUSANAGI 8.6.7.
Q13. I can’t update themes or plugins from the WordPress admin screen.
A13. If you are using PHP 8.0 or later, please confirm that the following content is in your wp-config.php.
define('FS_METHOD', 'ftpsockets');
After confirming, please change it as follows.
define('FS_METHOD', 'ftpext');