タグ: WordPress

はじめに

WordPressは，以下のようなファイル群で成り立っています．WordPressのバックアップは，それぞれのファイルのバックアップがされているなら、問題が生じて復元が必要となった場合，問題となったファイル群の復元によりWordPressを元にもどせます．

1. データベース (MariaDB 10)
2. WordPressのシステム(PHPファイル)

WordPressがSynology NASに置かれているなら，プラグインを使用せずとも，PHPファイルの復元はSynology NASの標準機能を使って簡単に行うことができます．

WordPress更新でスタック

WordPressの新しいバージョンが出た時にアップデートすることになる訳ですが，例えば，WordPress 6.0や6.2など(x.0やx.x)の場合，細かなバグがまだ少なからず含まれている場合があります．そういった時に少なからず起こるのが，「WordPressの更新をした途端にWordPressがダウンする」ことです．

また，最近知った情報では，WordPressなど関連するフォルダの権限設定について，WordPressのインストーラが厳格になったことで，以前のバージョンから新しいバージョンへの更新が途中で止まることが多々あるようです．フォルダのパーミッションの設定で以前にいじった記憶があり，それが原因として今回，何度目かのWordPress のバージョン更新で顕在化してしまったようです．現在，WordPress 6.2および，しばらく待った6.3も更新の途中でエラー表示を多数吐きながら，そのまま沈黙してしまいます(2023/08/19)．そうなると，もはや，サイトへの閲覧・アクセスは完全に閉ざされます．

バックアップと復元

このようなケースに対するWordPressの復旧は，データベース(MariaDB 10)の復元に関しては基本的に必要ではなく，プログラム自体であるPHPファイルなどのWordPressのシステムファイル群の復元を行うことで可能です．

同様に，プラグインのインストールや更新においても、WordPressが問題を起こした場合の基本的な対策は，データベースを復元するのではなく、PHPファイル群の復元を行うこととなります．

以下，これらPHPファイル群の復元に関して説明します．

復元方法の概要

データベース(MariaDB 10)のバックアップについては説明しません．

当サイトでは，データベースのバックアップには，とりあえずインストールしたプラグインで対応しています．でも，復元に使用したことはありません．あまり，信じていないからですが．

Synology NASでWordPressを構築しているのに，WordPressのバックアップ・アプリを使用することは，少し滑稽ですね．レンタルサーバーを使用してWordPressを構築している場合は，当然，WordPressのプラグインのバックアップ・アプリを使用してください．

今回説明するPHPファイル群の復元では，Synology NASのバックアップ・アプリ: 「SnapShot Replication」を使います．SnapShot Replicationを使用するということは，その他色々なファイルに対して適応可能なシステム用バックアップツールであり，PHPファイルやWordPressに限定されないし，信頼性が高いと思っています．

SnapShot Replicationは，指定した時間間隔毎に自動的に指定フォルダをバックアップし続けます．何世代までを残すのかの設定をしていれば，容量に困ることは少なくなります．

もしも，WordPressの更新によりWordPressがダウンしてしまっても，Synology NASのDMSにログインして，SnapShot Replicationから直近で複製されたファイル群を復元してやればよいのです．でも，更新などを実行する場合は，SnapShot Replicationから事前にReplicationしておくのが上等です．

以下，SnapShot ReplicationによるReplication(複製)とRestor(復元)の手順を示します．

事前の状態のバックアップ

WordPressの更新やプラグインの更新の前に，下図のようにSnapShot Replicationを起動して，”Replication -> Action -> Sync”を実行しシステム変更直前の状態を保持します．

リストア(復元)

更新作業を実行したものの失敗に終わり，サイトの閲覧・アクセスが完全に閉ざされた時は，以下の手順で事前に取った複製を使って復元します．

1. DMSにログイン
2. SnapShot Replicationを起動
3. 左画面の復元(Recovery)をクリック
4. 主画面にある複製リストを選択(例では，Web – Replicated)
5. 復元(Recovery)をクリック
6. 複製リストが現れる(例では，Recover – web)
7. WordPressの更新(など)でWordPressがダウンする前，且つ最も新しい複製リストを選択する
8. (因みに，Browseをクリックすると，複製されたフォルダ/ファイルが表示される．
9. Action > Restore to this snapshot (復元)をクリックする
10. (複製するスケジュール間隔が短くて，変更されたファイル数が少ない場合は，瞬時に復元は完了します)
11. 復元完了
12. 以上

Ver.6.2.2でもダメ

WordPress 6.1.3から6.2.2に更新してもWarnningを吐いてしまう．その後，WordPressは起動しなくなってしまった．

Warnningはフォルダーの権限(パーミッション)設定にあるとのメッセージです．このメッセージが170余り続きます．どうやら173行面のfilesystem関連のようです．

---

Warning: chmod(): Operation not permitted in /volume1/web/myblog/wp-admin/includes/class-wp-filesystem-direct.php on line 173

以下に示したサイト*1の内容を参考に修正してから，もう一度WordPressの更新を行おうと考えている．今日(7/9)はここまで．

*1, WordPressのパーミッション設定決定版

(d/f) rwx rwx rwx
r: read, w: write, x: execute

https://qiita.com/hirai-11/items/f4d81f27886b623c5ef0

備忘記録

WordPressの更新プログラムの適用には，個人ユーザーで割り当てるのではないため，以下の設定は更新プログラムの適用には，基本的に関係がない．ただし，この設定の目的は，セキュリティを高めることである．

– そもそものパーミッション設定値は

ググった結果，一般的な値は以下の通り．環境によっても違った最適な値があると考えられるので，現状はこれで設定しても良いがが，最適値を知るには調査を継続して，塾講が必要である．それが専門家の一歩．

パーミッション(permission; 権限)は，(所有者-グループ-その他)の並びでそれぞれ十進数では，一桁の0~7の数字で構成されている．差更に0~7は二進数では，三桁(rwx)で表される．r: read, w: write, x: executeの意味．r, wおよび xは，0または1であり，1の場合に権限がある．

具体的な数値の意味としては，7は，フルアクセスであり，6の意味はread & writeとなる．

以上の意味から，基本的に7, 5, 1は，めったに設定されない．

1. .htaccess : 606 or 604
   • 606の左から6は所有者(owner)，0はグループ(group)，6はその他のユーザー
2. wp-config.php : 400
3. ディレクトリ : 705
4. その他ファイル : 604

NASでの作業 (コマンド編)

パーミッション設定作業は，DSMではできない(?)か，当初は理解不足だったのでsshでログインしてコマンド操作で実施したが，それでもWordPressのUpdateはできなかった．おそらく，トップの「web」フォルダーを含めた設定が必要ではないかと考えられた．sshでのコマンドについて備忘記録をここに残しておく．

<備忘記録>

1. Login: ssh “<NAS IP Address>” -p “<port>”
2. Command : sudo chmod 604 .htaccess
3. command : sudo chmod 400 wp-config.php
4. Command : sudo find . -type d -print|xargs|sudo chmod 705
5. Comamnd : sudo find . -type f -print|xargs|sudo chmod 604

NASでの作業(DMS編)

そもそも，パーミッションの(所有者-グループ-その他)についてFileStationからプロパティを開いて，そのパーミッションにおけるパラメータとの対応がよくわからない．パーミッションの「所有者」とは? 「グループ」とは?

例えば，そのパーミッション設定には，User or Groupとい設定項目がある．これは，(所有者-グループ-その他ユーザー)におけるどのことを示しているのか不明だ．User or Groupで「http」を指定したパーミッションは，いったい(所有者-グループ-その他)のどれにあたるのか?

所有者/グループの見極めの答えは，こうだ．

1. httpが所有者か，グループか，その他ユーザーかは，コントロールパネルのユーザー設定で判断できる．httpは，グループにあるので，httpはグループと判断できる．
2. 同様に，httpsはグループである．

以下のSynologyサイトにパーミッションの設定方法が記載されている．sshは，セキュリティ的にあまり使いたくないので，DMSのFileStationでパーミッションの設定ができるように，設定方法を調査した．

トップの「web」フォルダーのパーミッションの設定は以下の通り，readまたはread & writeに設定する．

1. webのプロパティー(properties)から
2. Permission Editorを開く
3. User or Groupを「http」に
4. Inherit (継承) from を「<none>」のまま
5. Typeを「Allow」に
6. Apply toを「All」に
7. Read，またはReadとWriteにチェック．

以上の結果，機能しなくなっていたSiteGuard(以下に説明した)のCAPTCHAが表示できるようになった．

How should I set access permissions to folders used for hosting websites?

https://kb.synology.com/en-ca/DSM/tutorial/What_should_I_set_permissions_to_folders_for_websites

Read設定では機能しないプラグイン

SiteGuardというWordPressへのログイン制限が可能となるプラグインでは，ReadとWriteの設定になっていないとCAPTCHAが表示されない．

Ver.6.3でもダメ

最近，Version 6.3が出たので，WordPress 6.1.3から6.3に更新してみました．でも，同じように，同様の項目と数のWarnning を吐いて，そのまま沈黙して終了となりました．そこで少しググって，親のフォルダの権限に，「http」のRead権限を設定して，もう一度，Version 6.3で更新してみました．

その結果，以下のWarnningを吐き沈黙しましたが，今回のWarnningの数は著しく少なくなりました．173行目のfilesystem関連のWarnningは出なくなりました．(実は，もう少し追加の設定が必要なのですが，それは，以下に完結しているので，もう少し読んでみてください)

---

試行錯誤でのその他エラー

試行錯誤してからWordPressの更新をする場合，以下のように表示が出て先に進まない時があります．その場合，データベースにインストールのイベント情報が入力されているため，WordPressのシステムファイルの復元では改善できません．15分間待つしかないようです*2．

WordPress を更新
別の更新が現在進行中です。

*2, WordPress「別の更新が現在進行中です」エラーの解決方法

https://kinsta.com/jp/knowledgebase/wordpress-another-update-is-currently-in-progress/

結局

wordperssのupdateを可能にするには，結局，親フォルダでる”Web”へのアクセス権限として，”http”をオーナーを”Full Control: フルコントロール”に設定することで，無事にWordPress 6.3-jpで更新することが出来ました．

1. 設定対象 : 親フォルダ”Web”
2. “オーナ” また “http”による”フルコントロール: 管理・読取・書込”権限を設定した (一般的なLinuxのフルコントロールとは，rwxのうちx(実行)が無いため異なると考えられる)
3. 設定は，FileStationからフォルダのプロパティを開いて行う

やっぱり，”ホームNW研究所”の観音寺さん*3には，いつも助けられてばかりです．この場を借りて感謝します^^)．

*3,WordPressの更新に失敗した時の対策
– ホームNW研究所 –

webを”フルコントロール: 管理・読取・書込”に設定する．

https://nw.myds.me/synology/wordpress5-5-update/

その後

WordPressのUpdateはできたものの，その後，WordPressにログイン(SiteGuardプラグインから)しようとしたら，その機能てである「ひらがな」のCAPTCHAが表示されなくなっており，ログインができなくなっていたことに気づいた．

調べてみると，以下のリンクに解決方法があったので，それをヒントに以下を適用した．

気になる点は，httpのパーミッションがReadのみになっていたフォルダがあったこと．もしかすると，wordpressのUpdateの後処理として処理されている可能性も否定できない．

1. FileStationから
2. webフォルダのパーミッションについて
3. httpを「read, write」をチェックした．
   (この設定は，おそらく，(所有者 – http – その他)において所有者はhttpと考えられるため (6-0-0)と考えることができる．「そもそもパーミッション設定値は」の項で述べた，600に設定されているものと思われる．要は，所有者以外がアクセスできないと理解すれば納得がゆく．
4. ついでに，httpsにも「read, write」をチェックした．

ワードプレス　SiteGuard　画像表示されない

wpcontent -> plunins -> siteguard -> really-simple-captcha」のパーミッションを「777」にする

https://server-recipe.com/1880/

結局の設定値

色々作業して混乱してしまったため，どれをどの順序で実施したのかはもう夢のかなたに行ってしましたが，現状では，以下のことが可能となっている．

1. 試行錯誤の結果，wordpressのupdateが可能なままなのかは不明となってしまった．今後，wordpressのupdateの際に確認したい．
2. SiteGuardによるログインは可能
3. Plaginのupdateは可能

まとめ

自前のサーバーにWordPressを置いている場合，特にSynology NASを使用している場合での，WordPressの復元について，実際に生じた問題解決に迫られて実施した内容を解説しました．

WordPressのバックアップにはデータベース(MariaDB 10)とシステムファイル群(PHP)の二種類が必要ですが，今回は，システムファイル群の復元について取り上げました．

2018年からSynology NASにWordPressを設置してblogを行ってきましたが，システムファイル(PHP)絡みによるWordPressのダウンを何度か経験しました．

PHPの復元については，Synology NASの場合，SnapShot Replicatonを使えば簡単に復元が可能です．ここでは，取り上げなかったデータベース(MariaDB 10)の復元についても，Hyper Backupを用いれば可能です．このことは，WordPressのバックアップには，プラグインを使用する必要はなく，NASの機能を使ってシンプルにWordPressを管理することが可能であることを意味します．

WordPressに負担を掛けずに管理する，すなわち，NASに備わった機能を用いて管理するのは，エコだと思います．

不具合のあったWordPressの更新バージョンはそっとしておいて，6.2.x (x.xx)がでるまでおとなしく待ち，6.3で更新をしてみましたが，結果は，同様にWarnningを吐いて完全停止になりました．

バックアップの必要性は，結局問題が生じたときの備えです．今回は，関連フォルダのパーミッション不正によりwordpressのupdateが実行不可となったことで，その必要性を再認識しました．

話題は転じて，WordPressの親フォルダのぱーミッションの設定に関しては，以下の経緯をたどりました．

試行錯誤として，最初に「http」にRead(読取)権限を付与しました．その結果，数百に上る多数の173行のエラーはなくなりました．でも，その先の309行目のエラーが1つ現れました．

更に，ググっていいくと「ホームNW研究所」に直接的な記事がありました．Webフォルダのパーミッションを　”フルコントロール: 管理・読取・書込”に設定するとwordpressのupdateはすんなり実行できました．

そのご，しばらくしてwordpressにログインしようとした時，セキュリティの向上としてSiteGuardというプラグインを使用してCAPTCHAを表示させるようにしていましたが，そのCAPTCHAが表示されなくなっていました．

結局は，httdのパーミッションがreadのみになっていたことが原因と結論しました．httdをreadとwriteにチェックを入れると，SiteGuardは正常に機能するようになりました．

この設定により，最初にwordpressのupdateを可能にできたhttdの設定であるフル設定”フルコントロール: 管理・読取・書込”になっていません．今後，wordpressのバージョンアップがありupdateが必要な時には，この設定のままでupdateをしてみようと思います．

試行錯誤はまだまだ続く–)

編集履歴

2023/04/16 Mr. HARIKIRI
2023/07/09 追記: Ver.6.2.2-jpでも正常に更新できず，今後はパーミッション設定を中心にした対策を考える
2023/08/19 追記: やっとこWordPress 6.3-jpで更新完了．Ver.6.3-jpでも同様にエラーで停止した．”http”に”Read”パーミッションを与えて173行のWarnningはやっつけた．でも，309行目のWarnningが出てきた．実は，もっと簡単でした．親フォルダへの”http”での権限設定は，”フルコントロール: 管理・読取・書込”にするとOKです．
2023/08/20 追記: 備忘記録としてNASへのsshによるログイン，chmodの一括適用方法など．
2023/09/23 追記: DSMのFileStationから「web」フォルダーのパーミッションを設定する方法．変更: タイトル変更 (パーミッション設定を追加)