www.kinryo.net

mariadbの全テーブルをチェックする
# mysqlcheck -c -u root -p -A

wp_xxxxx.wp_options
Warning : InnoDB: The B-tree of index option_name is corrupted.
Warning : InnoDB: The B-tree of index autoload is corrupted.
error : Corrupt
wp_xxxxx.wp_postmeta
Warning : InnoDB: The B-tree of index post_id is corrupted.
Warning : InnoDB: The B-tree of index meta_key is corrupted.
error : Corrupt
wp_xxxxx.wp_posts
Warning : InnoDB: The B-tree of index post_name is corrupted.
Warning : InnoDB: The B-tree of index type_status_date is corrupted.
Warning : InnoDB: The B-tree of index post_parent is corrupted.
Warning : InnoDB: The B-tree of index post_author is corrupted.
error : Corrupt
ワーニング部分を抜粋：
データーベースに入り、reapir table wp_options; でエラーが出る。そうだInnoDB はreapir table をサポートしていないんだっけ。
なので、/etc/my.cnf の [mysqld] に下記を追記してを再起動
innodb_force_recovery = 1
右の数字を3にし、再起動でも治っていない。
色々ググると optimize table が使えそうなので、データーベースに入り、DB名で使用するDBを指定し

optimize table wp_options;
+----------------------+----------+----------+-------------------------------------------------------------------+
| Table                | Op       | Msg_type | Msg_text                                                          |
+----------------------+----------+----------+-------------------------------------------------------------------+
| wp_iguchi.wp_options | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| wp_iguchi.wp_options | optimize | status   | OK                                                                |
+----------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.052 sec)

お！ 直たみたい。他の2つのテーブルも同様にしてから、再度
# mysqlcheck -c -u root -p -A
全てOKになった。めでたし、めでたし. 忘れずに
innodb_force_recovery = 1 をコメントアウトし、mariadb を再起動してね。

このWEBのXOOPSはかなり古いバージョンで、phpのバージョンが5.6.40で動いていて、CentOS7にあるWEBはWORDPRESSを使い、バージョンは7.4.18が入っている。
なのでphp-fpmを使い両方のバージョンを使えるように設定した。

データーベースのデーターも移行しhttps://kinryokai.net (これがCentOS6から移行したドメイン）にアクセスすると真っ白！！、phpがおかしいかなと、このWEBの直下（index.phpと同じ場所）にtest.phpとして
<?php
phpinfo();
?>
を保存し、kinryokai.net/test.phpにアクセスするとちゃんと表示される。
色々試すと kinryokai.net/modules/piCal (カレンダー）は表示が出るけど他は一切真っ白。
これには3日くらい悩んだ、php-fpmの設定や、php関連のモジュールのインストール、virtualhostの設定、letsencryptの設定　等々 でも原因は全く簡単
cacheにapacheが書き込めない設定になっていた。これはデーター移行の時rsyncではなく、コピーをしたので、所有者がそのユーザーになってしまっていた。
所有者をapacheにして書き込み権限を持たせたら、問題なく動いた。
また、カレンダーが表示されたのは、以前クローラーがチェックに来た時、１日毎にアクセスをし、cacheの量が半端なく増加したため、カレンダーのcacheはdisableしているので、表示されたのだ。後からなら原因はわかるが、トラブっている時はこんな事は思いもよらない。

vsftp を ssl に対応しようと、letsencrypt の設定を記入し再起動をしたらエラーが出て起動しない。これは単純に rsa_cert_file の記入間違いだったので、訂正し、起動するがエラーが出て起動しない。それではと
# vsftpd /etc/vsftpd/vsftpd.conf
で、コンフィぐファイルのチェック、エラーは出ない。
だったら、エラーを細かく出そうと、/etc/vsftpd/vsftpd.confに

xferlog_std_format=NO
log_ftp_protocol=YES
dual_log_enable=YES

を記入し再起動、でもエラーで起動できない、そうだよなー、今のCONFファイルで起動しないのに、幾ら設定を足しても起動するわけが無い。
/var/log/messagesログには

systemd: Starting Vsftpd ftp daemon…
systemd: vsftpd.service: control process exited, code=exited status=1
systemd: Failed to start Vsftpd ftp daemon.
systemd: Unit vsftpd.service entered failed state.
systemd: vsftpd.service failed.      このログの時間とホスト名は決してあります。

と何も表示が無い。うーん困った。
そうだ、困った時の再起動！！
再起動したら何事も無かった様に起動した！！、今迄殆ど記憶が無い困った時の再起動は、個々に来て11月1日もあったな。どうした LINUX ？？

maillog に1分毎に clamav-milter[18105]: No clamd server appears to be available と出る！！
# systemctl status clamd@scan で見てもclamd は動いているし、clamav-milter 設定やその関連する や グループの設定も間違っていない。また、これは本ちゃんサブホストでの問題だが、これを行う前にテスト用のサブホストを作り、そこで動いた設定と同じにしているが、どうやってもエラーが止まらない。

そうだ、困った時の再起動だ！！（WINDOWSでは結構あるが、LINUXではエラーの為にした覚えはないが）
結果：何事もなかったようにエラーは出ない！！
何かCACHEなどが効いていたのかなー