Linuxサーバー備忘録

kusanagiでサイトを公開している時に、http://でもhttps://でもサイトが閲覧できてしまうことがあります。

すべてhttps://にリダイレクトさせたい時にには以下のコマンド。

kusanagi ssl --https redirect kusanagi_provision

Aタグ内にエラー

Aタグ内を見てみるとpost_idが受けて取れていない感じのエラーが一緒に入ってた。

書き換え

get_the_permalink($post_id)

と書かれていたので、

get_permalink($post->ID);

と書き換え無事解決しました。

PHP5.*

「昔構築したWordPressの調子が悪い」と状態を確認してみると、PHP5.*のままレンタルサーバーを運用していたりすることがあります。

WordPressもPHP5.*のままだとバージョンアップできずに古いまま。当然プラグインも古いままという状態。

同じバージョンのPHPが利用できるサーバーを準備

本番環境で、PHPもWordPressも一気にバージョンアップなんてしたら取り返しの付かないことになります。エラーがでて残業して復旧作業とかになりかねません。

まずは、同じバージョンのPHPが使えるサーバーを準備します。

そして、コンパネから問題のサーバーと同じくらいのPHPバージョンを指定します。

MYSQLに関してはなかなかそうも行かないので、できる限り近いバージョンで。

MYSQLをダンプ・ファイル一式をコピー

SSHが使えるレンタルサーバーならコマンド一発でファイル一式をコピーすることができます。FTPでそれをやると恐ろしく時間がかかることがあります。

MYSQLはダンプファイルを使って開発環境サーバーでレストアします。

wp-config.phpの書き換え

wp-config.php内のDB情報を今回準備したサーバーの情報に書き換えます。

この状態で動作するか確認

元の環境と可能な限り近い環境にしたら、WordPressの閲覧・投稿などができるか確認します。この時点でエラーが出ていたら厄介（笑）

同じ環境ならエラーは出ないはず。

プラグイン関連をアップデート

WordPressの管理画面から、プラグインをアップデートします。

WordPressが動作しているか、エラーを吐いていないかもチェックします。

WordPressをアプデート

プラグインをアップデートしたら、WordPressもアップデートします。

WordPressが動作しているか、エラーを吐いていないかもチェックします。

プラグインをもう一回アップデート

WordPressをアップデートすると、更にプラグインのアップデートが必要な場合があるので、あればアップデート。

WordPressが動作しているか、エラーを吐いていないかもチェックします。

PHPのバージョンアップ

最後にPHPのバージョンアップ。PHP5.*からで、function.phpをいじっている場合色々書き換える必要が出てくると思います。

デバックモードにして、エラーを潰します。

最後にエラーも出ずに動作しているかのチェックをして完了。

元のサーバーの各種アップデート

開発環境でいじった手順で元の本番サーバーもアップデートしていきます。似たような環境でテストしたとは言え全く同じでは無いと思うので、おかしな挙動を起こしたときはデバッグモードでチェック。

最近はPHPはアクティブサポートは2年、セキュリティサポートは3年という周期が続いています。PHP7.4はとっくに2022/11/28でSecurityサポートが終了しました。

PHPのバージョンアップが早すぎて、各ディストリビュージョンはついていけてない感じ？サーバー管理者はPHPを使う場合は、各自でバージョンを確認しインストールする必要がありそうです。

ディレクトリ内のファイルを一括削除したいのに、

bash: /bin/rm: Argument list too long

と怒られる場合があります。ファイル数が多すぎて削除できない！というエラーです。そういうときには以下。

echo *.html | xargs rm

.htmlのファイルを一括で削除したい時の例です。

apacheを再起動しようとするとプロセスが残ってしまい再起動できない場合があります。例えば以下のようなエラーのときです。

 [crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock
 Configuration Failed

数個のプロセスなら1つづつkillしていけばよいのですが、数十となると手作業では厳しいです。そういうときには、

ipcs -s | grep apache | awk ' { print $2 } ' | xargs -i ipcrm -s {}

とやると、apacheなプロセスがすべてkillされます。

ps auxを実行して今稼働しているプロセスを調べますが、その表示順を変える方法です。

CPU使用率昇順

ps aux | sort -nk 3

メモリ使用量昇順

ps aux | sort -nk 4

プロセスの親子関係をツリー表示

順番とは関係ないのですが、プロセスの親子関係を知りたいときがあります。

ps -auxf

を実行すると、以下のようにツリー構造で表示されます。

ps -auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         2  0.0  0.0      0     0 ?        S    11月29   0:01 [kthreadd]
root         4  0.0  0.0      0     0 ?        S<   11月29   0:00  \_ [kworker/0:0H]
root         6  0.0  0.0      0     0 ?        S    11月29   0:21  \_ [ksoftirqd/0]
root         7  0.0  0.0      0     0 ?        S    11月29   0:01  \_ [migration/0]
root         8  0.0  0.0      0     0 ?        S    11月29   0:00  \_ [rcu_bh]
root         9  0.0  0.0      0     0 ?        S    11月29   7:25  \_ [rcu_sched]
root        10  0.0  0.0      0     0 ?        S<   11月29   0:00  \_ [lru-add-drain]

各種ログの確認作業は本当に骨が折れます。そういう時に特定の文字列が含まれた行のみを抽出することができると、問題のあるログを見つけやすかったりします。

sed -n '/抽出したい文字列/p' ファイル名 > 出力するファイル名

yumでアップデートした後に、サーバーを再起動すべきか迷うことがあります。kernelのアップデートがあれば再起動は必須なのですが、それ以外でも再起動が必要な場合がある可能性があります。

そういうときは、

needs-restarting -r

再起動が必要ではない時

再起動が必要ではないときには以下のように結果が帰ってきます。

Reboot is probably not necessary.

再起動が必要な時

再起動が必要なときは以下のように結果が帰ってきます。

Core libraries or services have been updated:
  kernel -> 3.10.0-1160.80.1.el7

Reboot is required to ensure that your system benefits from these updates.

More information:
https://access.redhat.com/solutions/27943

Core libraries or services have been updated:
の下が再起動が必要な理由が書かれています。

こういうときにはサーバーを再起動します。

例えば、365日以内に生成されたJPG画像ファイルをコピーしたい時は以下。

/usr/bin/find コピー元ディレクトリ -mtime +365 -name "*.jpg" | xargs mv --target-directory=コピー先ディレクトリ