wordpressの更新を管理画面からSSHで行う設定

吉祥寺北口システム

wordpressの本体やプラグイン、テーマ、翻訳を管理画面からSSHで行う設定をやってみました。
やってみれば簡単なんですが、処理時間が少しかかるのと、サーバ上に秘密鍵置くのは気持ちが落ち着かないという、今まで手を出さなかった理由を再確認する結果でした。そういうのが平気な人におすすめです。

wordpressの更新はどうやるか

wordpressは定期的にバージョンアップしています。それとは別にプラグインもバラバラにバージョンアップします。バージョンアップの理由は機能追加だったりのポジティブな面がある一方で、セキュリティ上の問題での対応もあるので、基本的には全部が最新バージョン推奨です。めんどくさい。

で、更新ですが普段はサーバに入ってWP-CLIでやってます。
そうでなければ最新バージョンのファイルをダウンロードしてきて上書きアップロードでもできます。これが一番単純。

上記はどちらもサーバに接続して作業するので、サーバって何？みたいな人にとってはハードルが高い作業。ブラウザで出来ないの？って思う人がいても不思議じゃなく、実際ブラウザでやろうよって話で設定してみました。

参考にしたサイト

ここに殆ど書いてあります。
それと一緒にwordpress公式のwp-config.phpの説明を読むとより良いかも知れません。公式だし。

更新処理はどうやっているんだろう

WP-CLIの場合、サーバに入って更新するユーザになった上でコマンドを実行する。サーバから外部サーバに更新ファイルを取りに行く。
上書きアップロードは手元のPCからサーバにファイルをアップロードする。
どちらもわりと単純です。

それに比べると管理画面からの更新はちょっと複雑。
こんな段取りで処理されます。

  1. ユーザがブラウザ上の更新ボタンを押す。

  2. 更新ボタンが押されてwordpressの管理機能が処理をスタートする。

  3. wordpressの処理内で、指定の秘密鍵とパスフレーズでwordpressを更新できるユーザが自サーバにSSH接続をする。
    指定の秘密鍵は更新できるユーザのものだけど、wordpressを実行しているapacheとかnginxとかkusanagiのユーザ権限が必要、ややこしい。

  4. SSH接続した先でWP-CLIと似たような処理をする。(詳細未確認)
    WP-CLIみたいに進捗状況を表示していて、都度やりとりしている模様。

操作上はブラウザで完結してサーバって何？な人も操作できるけど、実際はサーバのこと知らないで自由にお使いいただくの怖くない？という仕組みに思えます。そんなことない？
秘密鍵？wordpressを更新できるユーザ？SSH接続？wordpressを実行しているユーザ？何を言ってんだろう…。

やってみる

$ su - wordpressを更新できるユーザ
$ cd hogehoge(WEBからアクセスできない良き所)
$ mkdir .wp_ssh
$ ssh-keygen -f .wp_ssh/id.rsa
(参考先ではパスフレーズなしだったけど、パスフレーズ入れた方がまだマシかも)
$ cat .wp_ssh/id_rsa.pub >> ~/.ssh/authorized_keys (元々SSHで入ってますよね)
$ sudo chown -R apache:apache .wp_ssh (参考先ではnginx。WEBサーバの実行ユーザくらい分かるよね)
$ sudo chmod -R 600 .wp_ssh

鍵の設定が終わったら wp-config.php に設定追加します。

define( 'FS_METHOD', 'ssh2' );
define( 'FTP_PUBKEY', 'WEBからアクセスできない良き所/.wp_ssh/id_rsa.pub' );
define( 'FTP_PRIKEY', 'WEBからアクセスできない良き所/.wp_ssh/id_rsa' );
define( 'FTP_USER', 'XXXX' );  //wordpressを更新できるユーザ
define( 'FTP_PASS', 'XXXX' );  //鍵のパスフレーズ
define( 'FTP_HOST', '127.0.0.1:22' ); //SSHポートが22じゃなければ変更する

参考先はパスワードを設定してないけどパスフレーズがあれば設定します。
これであとは管理画面から更新するだけ。


設定が漏れるとこうなるという例

wp-config.phpの設定が漏れると、更新しようとしてエラーが出るので幾つかやってみました。エラーメッセージはいつも理不尽。

FTP_PUBKEYの設定が違うとこうなる。
そもそも公開鍵の指定いる？っていう。
FTP_PASSが間違っているとこうなる。
FTP_PUBKEYの設定間違いもこれで良くない？
~/.ssh/authorized_keys に公開鍵が登録されてないとこうなる。
wp-config.phpの設定ミスじゃないので気づきにくい。

処理がタイムアウトすることもある

更新処理はわりと時間かかります。5分とか。

更新処理は数分かかることが多いのでWEBサーバの設定でタイムアウトしてしまうことがあります。
Service Temporarily Unavailableが進捗状況のテキストに出てそこで止まる。急に英語が出て、終わったかどうかも分からない。

その場合、WEBサーバの構成にあわせてタイムアウトを長めに設定しなおす必要があります。WEBサーバの構成にあわせてって言われても！っていう。

しかもタイムアウトで止まった場合、wordpress上では更新処理中のままなので、wp_optionsテーブルのアップデート中のフラグを立てている行を削除する必要があります。

mysql> delete from wp_options where option_name='core_updater.lock';

本当に知らない人にまかせて大丈夫なんだろうか？って不安にならない？

wordpress誰でも使えるっていう違和感

いかがだったでしょうか。
分かっている人にはサクサク設定できる内容でした。分かってる人には。

wordpressはブラウザで何でもできるようにする傾向があって、プラグイン入れまくって管理画面が昔のIEのツールバーみたいになることが多いです。

そこに混じってwordpressのバージョン更新という、コアな部分までもブラウザでやっちゃいますか？というのは、気持ちは分かるんですけど、任せていただけませんか？みたいなことを思います。

仕事欲しい、お金欲しいというのもありますけど、この方面でトラブルが起きた時って、何が起きているかの調査からスタートするので大変なんです。しかもすでにトラブルは起きていて、復旧もできないなんて状況もある。
それなら最初からこっちでやらせてくださいと思うわけです。

でもブラウザで操作できるんですよね…っていう。



この記事が気に入ったらサポートをしてみませんか？