じゃんくはっく

今日も自宅サーバいじるよ〜！

ほんと、好きねぇ〜。今日は何するんですか〜？

ぴー

じゃんくはっく

好きというか、まだ設定いろいろあってw。とりあえず、バックアップをどうしようかなと。

プラグインとか便利なのあるでしょ？あれじゃだめ？

ぴー

はい、ぴーちゃんの言う通り便利なプラグインがあります。

超有名なWordPressバックアッププラグイン

この２つが特に有名じゃないでしょうか？

UpdraftPlus WordPress Backup Plugin

あと、これ。

BackWPup – WordPress Backup Plugin

前者のUpdraftPlusは、一度使ったことがあります。通常ならこれでバックアップはOKじゃないでしょうか。でも、今回はちょっと自宅サーバ構成に難があって、自分のドメインに自分でアクセスできない問題があります。

自分のドメインに自分でアクセスできない問題！

これはつまり、https://hack.gpl.jp や、https://hack.gpl.jp で自分自身にアクセスできないということです。こういう場合、WordPressのcronやジェットパックなどいろんな部分で問題が発生します。これは、wp-cliで診断すると以下のようになります。

$ wp cron test
Error: WP-Cron spawn failed with error: cURL error 28: Connection timed out after 3000 milliseconds

この、cURL error 28 エラーはいろんなケースで出るのですが自分の場合は、登録されているURLに自分自身でアクセスできないことが原因です。この問題の根本は以下で紹介しています。まだ解消していません。

ポートフォワードの経路で、Uターン NATとかヘアピンNATが使えないルータの場合のあれこれ

https://hack.gpl.jp/2020/09/07/ポートフォワードの経路で、uターン-natとかヘアピ/

この解消はまた別の機会にやるとして、今回はこういう中途半端な環境で wp-cronが動作しない中、どうやってバックアップを行うかという感じです。

さて、どんな方法があるの？

王道としては、バックアップスクリプトを書いて、どこかクラウドストレージへコピーする方法です。データベースと、WordPress側で更新される画像など uploads以下にできるファイル、またカスタマイズするテーマなどもバックアップしておきたいです。それらをスクリプト中に記載してLinuxのcronで実行するという、めんどくさいやり方です。世の中、便利になりすぎてこういうスクリプト書くのが面倒になってきています。

バックアップ方針とTermux環境で使えそうなツール

バックアップ方針は、やってる最中に気が変わるとして、下調べしてみると必要なツールは以下となりそうです。

・クラウドへのバックアップ　
　→　GoogleDriveにバックアップしたい
　→　rcloneがある！
・uploadsは差分バックアップしたい
　→　rsyncがある
　→　Termuxもバイナリがある
・全部、スクリプトで書くと面倒
　→　wp-cli　を使って、プラグインと併用してみる
・DBは30日分保存、uploadsは差分保存

幸い、Termuxのバイナリにはこれらのツールが揃っていることがわかりました。rclone は、今回はじめて使います。

Rclone syncs your files to cloud storage

https://rclone.org/

まとめ

今回、なんとなくわかったのは以下となります。

・WordPressのcronは、自己のURLで自分自身をcurlで叩いている。
・それが出来ないと、cURL error 28のエラーが発生する。
・wp-cliで、wordpress の jobを linux の cron で叩けば動く
・クラウドへの保存ツールは、rcloneで解決

あとがき

まぁ、そもそもネットワーク構成をちゃんとやって自分自身をちゃんと参照できるようにしないとだめだよなーと。ただ、NATとポートフォワードをしていて内部LAN側に違うポートで提供している環境は他にもあると思うので、もしかすると誰かの参考になるかなとも。たぶん、その２へ続くと思います。

前回、事前に調査した4つの監視サービスを検討してみました。この中では格段に操作と設定がしやすかった、site24x7 というサービスを紹介することにします。なぜ、このサービスなのかと言うと４つのサイトに同時にサインアップして実際に使ってみたのですが、説明書も何も見ずに最後まで設定できたからです。

site24x7の有料プランでできること

Site24x7　プラン比較

https://www.site24x7.jp/packs-comparison.html

詳細はこの表の通りですが、無料プランと有料プランの格差がありますよね？有料は7000円〜となっていますが、実は10ドルで出来そうな感じです。後ほど紹介しますね。

さて、無料プランではWEBの死活監視ができ、アラートはメールで可能。ステータスページは有料と違い、グラフが表示できるダッシュボードが公開できない。という内容です。有料と無料では、公開できる情報（グラフ）が違います。実際にこのサイトで公開している監視グラフのページを見てもらうほうが理解が速いかなと思います。

有料プランのグラフ

このサイトの監視状況　有料プラン（１ヶ月ほど無料）

https://hack.gpl.jp/status/

上記リンクは、有料プランが終わったときには見れないのでスクリーンショットをつけておきます。有料プランはカスタマイズしたグラフをダッシュボードに作り、それを共有することが可能です。

いろんなグラフが作れますが、上から「応答時間詳細」でこれは東京リージョンからのものです。その下が、「ページ読み込み時間詳細」です。どちらも、DNSや接続時間など詳細に出ています。

応答時間詳細は、各所にヒゲ状に突出している部分がありますね。また、ページ読込時間を見ると夜間帯は安定していますが、昼間はギザギザしていますね。

次は、「スループット」と「各ロケーションからのSSLハンドシェイク時間」です。200kb/secくらい最高で出ていますが、平均値は120kb/secくらいですね。WEBデータのような小さいデータの転送は速度があまり出ないのかな？

SSLハンドシェイクの時間は、各拠点からのものでこの拠点は世界中から８箇所まで選べます。国内だと東京・長野・大阪が選べました。

最後の図は、「ロケーションごとのページ読み込み時間」です。面白いことに東京よりも、シンガポールからのほうが速そうです。また、意外にもニューヨークやロサンゼルスからも遅くはありません。有料プランは、これ以外の数多くの機能があり全部は紹介しきれませんが、概ね有益だなと感じました。例えば、証明書期限チェックやドメイン更新期限チェックなどあります。面白いなと思ったのは、Tracerouteによるネットワークパス分析です。

ロスからと東京からのホップ数（ざっくり言えば、ルータ越えの数）はそう変わりないみたいw　また、深センからはいろんな経路があるんだな！　ということがわかりました。

site24x7の10ドルの有料プラン！

これだけ、いろいろな機能ができるなら検討してもいいかもしれません。このサービスの価格は、有料にするとお幾らなんでしょうね？

はい、最初に見てもらった価格表はPro〜7000円から有料とありましたが、なんとスターターという有料プランもあるようです。これは日本円だと毎月払いで2000円、ドル払いだと１０ドルと記載されています。

可能かどうかは不明ですが、ドル建ての支払いのほうがお得な気がします。月払い10ドルならアリかもですね。この表中にある、詳細監視というのは、以下のことです。四角枠で囲った部分、これは欲しいですね。

ブラウザーと記載してあるものは、時系列でその時の読込にかかった状態が記録されています。例えば、2020/09/22 2:55 の東京からの読込が10秒ほどかかっている部分があります。

これは、ブラウザーからの読込は以下のようになっていました。

つまり、JSの読込が遅いのか？　あるいは、画像の読込が遅いのか？　あるいはジェットパックで画像置き換えられたCDNが悪いのか？　などが各拠点から時系列でわかってしまいます。すごいですね！

site24x7の無料プランは・・・？

無料プランでは、有料プランでできるダッシュボードのグラフを共有することはできませんでした。グラフが見たければ、管理パネルにログインしていれば以下のように見えます。

計測地点は、シアトル（US)からのみです。試験を行う間隔は10分となりそれ以下はできません。死活監視のみとなり、無料プランでグラフはこれ以外は登録できないようです。シアトルからの監視ですが、まぁ十分でしょうか。有料プランで出来たブラウザからの読込はサポートしていません。
　なお、グラフの共有（ダッシュボード）はできず、公開できるのは、ステータスページで、StatusIQ というサービスを使って行えるようです。これも実際に見てもらったほうが速いです。以下に、このサイトの状態を貼ってあります。

NetWork Status FreePlan

https://hack.gpl.jp/network-status-freeplan/

グラフは出すことができず、サービスが生きているか死んでいるかを表示するものみたいですね。

なお、WEBサイトを登録するときの画面は以下のようになります。

あとがき

最初、WEBを監視するだけだと思っていましたが関連するサービスがたくさんあって、このサービスは今後検討してみたいなと思いました。しかし、スマホサーバを外部から１０ドル払って監視する価値がどのくらいあるのかまだ未知数です。

監視できる事は豊富で、コスパ的に見れば、類似サービスの中では突出しているようにも思えます。多少味付けは違いますが、マカレルよりいい機能があるかな！と感じています。でも、マカレルはLINE通知があるので好きなんです。

site24x7で、まだ試していないのはLinuxのリソースを監視するサービスです。これもエージェントがtermux で動作するのかどうかわかりません。Termuxネイティブ環境は何かと制約があるのです。もし、うまくいったら、また続報があるかもです。

存在は知っていましたが使ってみると便利でした。

WP-CLI は WordPress を管理するためのコマンドラインインターフェースです。

https://wp-cli.org/ja/

つまり、こんなことが出来ます。

$ wp plugin list
+----------------------------------------+----------+--------+---------+
| name                                   | status   | update | version |
+----------------------------------------+----------+--------+---------+
| akismet                                | active   | none   | 4.1.6   |
| amp                                    | active   | none   | 2.0.1   |
| autoptimize                            | active   | none   | 2.7.7   |
| jetpack                                | active   | none   | 8.9     |
| jquery-manager                         | active   | none   | 1.10.6  |
| line-auto-post                         | active   | none   | 1.0.1   |
| litespeed-cache                        | inactive | none   | 3.4.2   |
| multiple-domain-mapping-on-single-site | active   | none   | 1.0.4   |
| ultimate-addons-for-gutenberg          | active   | none   | 1.17.0  |
| word-balloon                           | active   | none   | 4.12.0  |
| wordpress-importer                     | active   | none   | 0.7     |
| wpfront-scroll-top                     | active   | none   | 2.0.2   |
| duplicate-post                         | active   | none   | 3.2.5   |
+----------------------------------------+----------+--------+---------+

シェルが使える環境だったら使わないと、もったいないですね！

インストール抜粋

Termux環境でも使えるか試してみました。要件はさきほどのリンクに記載してありますがPHP5.4〜とUNIX系の環境だそうです。WordPressは、3.7〜。

ステップ１

適当なディレクトリを作っておきます。例では、home直下にtmpディレクトリを作りそこで作業します。まず、wp-cli.phar をダウンロードします。

cd
mkdir tmp
cd tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

ステップ２

一応、確認です。

php wp-cli.phar --info

以下のような感じで出力されました。

OS:	Linux 4.14.141+ #1 SMP PREEMPT Wed May 6 10:13:36 CST 2020 aarch64
Shell:	/data/data/com.termux/files/usr/bin/bash
PHP binary:	/data/data/com.termux/files/usr/bin/php
PHP version:	7.4.10
php.ini used:	/data/data/com.termux/files/usr/lib/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/data/data/com.termux/files/home/tmp
WP-CLI packages dir:	
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.4.0

ステップ３

実行権限をつけて、パスが見えるところに移動。

chmod +x wp-cli.phar
mv wp-cli.phar PREFIX/bin/wp
::（ちゃんと見えるか確認） which wp
/data/data/com.termux/files/usr/bin/wp

ステップ４

タブ補完できるようにしておきます。

cd
mkdir bin
cd bin
wget https://raw.githubusercontent.com/wp-cli/wp-cli/v2.4.0/utils/wp-completion.bash

vi ~/.bash_profile

以下を追記

source /data/data/com.termux/files/home/bin/wp-completion.bash

反映しておきます。

source ~/.bash_profile

確認

$ wp ※ここでタブキーを押してみると以下が表示されます。
cache              cron               help               menu               post-type          shell              theme 
cap                db                 i18n               network            rewrite            sidebar            transient 
cli                embed              import             option             role               site               user 
comment            eval               language           package            scaffold           super-admin        widget 
config             eval-file          maintenance-mode   plugin             search-replace     taxonomy           
core               export             media              post               server             term 

ステップ５

実際に使ってみましょう。WordPressのプラグインがあるディレクトリに移動します。以下は、プラグインの一覧を出すコマンドです。

$ wp plugin list
+----------------------------------------+----------+--------+---------+
| name                                   | status   | update | version |
+----------------------------------------+----------+--------+---------+
| akismet                                | active   | none   | 4.1.6   |
| amp                                    | active   | none   | 2.0.1   |
| autoptimize                            | active   | none   | 2.7.7   |
| jetpack                                | active   | none   | 8.9     |
| jquery-manager                         | active   | none   | 1.10.6  |
| line-auto-post                         | active   | none   | 1.0.1   |
| litespeed-cache                        | inactive | none   | 3.4.2   |
| multiple-domain-mapping-on-single-site | active   | none   | 1.0.4   |
| ultimate-addons-for-gutenberg          | active   | none   | 1.17.0  |
| word-balloon                           | active   | none   | 4.12.0  |
| wordpress-importer                     | active   | none   | 0.7     |
| wpfront-scroll-top                     | active   | none   | 2.0.2   |
| duplicate-post                         | active   | none   | 3.2.5   |
+----------------------------------------+----------+--------+---------+

お〜！　これは便利ですね。いろんな使い方があるので、以下をみてみてくださいね。

WP-CLI　Quick Start

https://make.wordpress.org/cli/handbook/guides/quick-start/

いろいろ便利な使い方があると思うので、備忘録：〜　で紹介していきたいと思います。

あとがき

やっぱり自宅サーバでWordPressをLinuxにホスティングしてみると、面白い発見がいろいろありますね。今まで、使わなかったいろんな方法があると夢が膨らみます。例えば、テスト環境なんかも簡単に作れそうですね。あるいは、差分を取って slack に投稿しておけば自動アップデートで何がどうなったかもわかると思います。アイデア次第ですね。

前回、別記事にすると言っていた件です。

Termux環境で動作するLet’s Encryptのワイルドカードドメインに対応した自動化ツールを探せ！

https://hack.gpl.jp/2020/09/11/wildcard-domain-acme/

今日のネタは、Termuxネイティブ環境で acme-nginx というPythonで、作られた自動化ツールで Let’s Encrypt のワイルドカードドメイン証明書を取得します。さぁうまく出来るでしょうか？ ちなみに、ワイルドカード証明書とは、以下のようなことを言います。

ワイルドカード証明書とは

「*.example.jp」のように、コモンネームの一番左のラベルにアスタリスク（*）を指定したサーバー証明書です。

ワイルドカード証明書は「www.example.jp」「login.example.jp」「member.example.jp」のように、アスタリスクと同一階層のサブドメインのみが異なるすべてのサーバーにインストールできます。
また、JPRSの提供するワイルドカード証明書なら、「*.example.jp」の証明書を「example.jp」のようにアスタリスク（*）を除いたホスト名のサーバーでも利用できます。

https://jprs.jp/pubcert/about/wildcard/

では作ってみましょう。acme-nginx はもう入れてあるものとします。DNSはデジタルオーシャンに変更して、APIトークンを取得してあります。

ステップ１

適当な証明証を入れておくディレクトリを作っておきます。例では、example.jp　というドメインで説明しています。

cd
mkdir -p ssl/example.jp
cd ssl/example.jp

ステップ２

アカウントキーと、ドメインキーを作成します。

openssl genrsa 4096 > account.key
openssl genrsa 4096 > example.jp.key

ステップ３

digitaloceanのトークンを環境変数に入れておきます。

export API_TOKEN=digitaloceanのトークン

ステップ４

証明書を発行します。WEBの認証はないので便利ですね。パスは、Termuxxの環境変数 $PREFIX に置き換えたほうが見やすいかもですね。

acme-nginx \
	--no-reload-nginx \
	-k /data/data/com.termux/files/home/ssl/example.jp/account.key \
	--dns-provider digitalocean \
	--domain-private-key /data/data/com.termux/files/home/ssl/example.jp/example.jp.key \
	-o /data/data/com.termux/files/home/ssl/example.jp/example.jp.crt \
	-d '*.example.jp' -d 'example.jp'

ドメインの指定は、*.example.jp と example.jp を指定します。そうしないと、example.jp でのドメインだけのアクセスで証明書が無効となります。
　実際のログは（ドメイン名は置き換えていますが）以下のようになります。

2020-09-13 02:45:40,777 - INFO - trying to create account key /data/data/com.termux/files/home/ssl/example.jp/account.key
2020-09-13 02:45:41,727 - INFO - trying to register acmev2 account
2020-09-13 02:45:43,612 - INFO - already registered
2020-09-13 02:45:43,613 - INFO - trying to create domain key
2020-09-13 02:45:43,615 - INFO - acmev2 dns challenge
2020-09-13 02:45:43,615 - INFO - preparing new order
2020-09-13 02:45:46,648 - INFO - order created
2020-09-13 02:45:47,644 - INFO - verifying domain example.jp
2020-09-13 02:45:47,670 - INFO - creating TXT dns record _acme-challenge.example.jp IN TXT uWmLyGGgK1Jyj（省略）RHo-A5TUKBAac
2020-09-13 02:45:50,642 - INFO - asking acme server to verify challenge
2020-09-13 02:45:52,486 - INFO - waiting for example.jp challenge verification
2020-09-13 02:45:53,239 - INFO - example.jp verified!
2020-09-13 02:45:53,240 - INFO - delete dns record
2020-09-13 02:45:56,793 - INFO - verifying domain example.jp
2020-09-13 02:45:56,817 - INFO - creating TXT dns record _acme-challenge.example.jp IN TXT hP2bwoYASAQYL（省略）VkiKGDupZxfw0
2020-09-13 02:45:59,551 - INFO - asking acme server to verify challenge
2020-09-13 02:46:02,005 - INFO - waiting for example.jp challenge verification
2020-09-13 02:46:02,884 - INFO - example.jp verified!
2020-09-13 02:46:02,885 - INFO - delete dns record
2020-09-13 02:46:05,385 - INFO - signing certificate
2020-09-13 02:46:08,480 - INFO - certificate signed!
2020-09-13 02:46:08,480 - INFO - downloading certificate
2020-09-13 02:46:09,472 - INFO - writing result file in /data/data/com.termux/files/home/ssl/example.jp/example.jp.crt

30秒くらいで、完了していますね。dnsにテキストレコードを書いている部分が2回あります。ちゃんと認証が通ればテキストレコードは削除していますね。これは便利！作者に感謝です！

ステップ４

あとは、キーと証明書をnginxに設定して再起動しておきます。

・Key
　/data/data/com.termux/files/home/ssl/example.jp/example.jp.key

・CRT
　/data/data/com.termux/files/home/ssl/example.jp/example.jp.crt

あとは、実際のクライアントから確認してみます。

おー、鍵マークがかかっていますね。うまくできているようです！　今度は、curlで https://gpl.jp にアクセスできるか確認してみます。WordPressには、このドメインはマッピングしていないので、静的ファイルが置いてあるURLに対してアクセスしてみます。curlクライアントはリモートのMacからです。

$ curl -Iv https://gpl.jp/license.txt
*   Trying 116.58.181.140...
* TCP_NODELAY set
* Connected to gpl.jp (116.58.181.140) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.gpl.jp
*  start date: Sep 12 16:46:12 2020 GMT
*  expire date: Dec 11 16:46:12 2020 GMT
*  subjectAltName: host "gpl.jp" matched cert's "gpl.jp"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fd360002000)
> HEAD /license.txt HTTP/2
> Host: gpl.jp
> User-Agent: curl/7.54.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200 
HTTP/2 200 
< server: nginx
server: nginx
< date: Sat, 12 Sep 2020 18:09:29 GMT
date: Sat, 12 Sep 2020 18:09:29 GMT
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< content-length: 19915
content-length: 19915
< last-modified: Wed, 12 Feb 2020 11:54:05 GMT
last-modified: Wed, 12 Feb 2020 11:54:05 GMT
< vary: Accept-Encoding
vary: Accept-Encoding
< etag: "5e43e75d-4dcb"
etag: "5e43e75d-4dcb"
< strict-transport-security: max-age=15552000
strict-transport-security: max-age=15552000
< x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block
< x-frame-options: DENY
x-frame-options: DENY
< x-frame-options: SAMEORIGIN
x-frame-options: SAMEORIGIN
< x-frame-options: ALLOW-FROM https://www.youtube.com https://www.wordpress.com
x-frame-options: ALLOW-FROM https://www.youtube.com https://www.wordpress.com
< x-content-type-options: nosniff
x-content-type-options: nosniff
< content-security-policy: default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' ;
content-security-policy: default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' ;
< referrer-policy: strict-origin
referrer-policy: strict-origin
< permissions-policy: fullscreen=() geolocation=()
permissions-policy: fullscreen=() geolocation=()
< x-hacker: Hello. :-)
x-hacker: Hello. :-)
< accept-ranges: bytes
accept-ranges: bytes

< 
* Connection #0 to host gpl.jp left intact

ちょっと長いですが、途中「SSL certificate verify ok.」が出ていますね。接続は、TLS2 でHTTP/2 プロトコルになっていますね。これで当初の目的は達成できました！ チェックサイトでは、A+判定出ていました。問題なさそうですね。

SSL Server Test (Qualys SSL Labs)

https://www.ssllabs.com/ssltest/

あとは、自動実行すればいいんですが termux の限られたリソースの中で cronjobを回して、ログを出し、何かあったらメールするっていうのをやるべきか、その他の方法を採用するかで迷っています。

　そもそも、termux でcronjobはちゃんと動くか確認しておかないとです。なんたって、androidシステム上で動いているわけですから。Dozeモードの影響とかそういうのは大丈夫なのか確認しないとです。

定期実行しておく

手動で実行していましたが、Site24x7 の監視サービスからアラートが飛んでくるので（これはありがたい機能ですが）cronに登録しておきました。しばらく様子を見てみます。

# update SSL . Run at 5:30 on the 1st and 15th of every month
30 5 1,15 * * /data/data/com.termux/files/home/ssl/gpl.jp/renew-cert.sh | $PREFIX/bin/msmtp [email protected]

あとがき

気になることはいろいろありますが、そろそろデータの引っ越しをやりますかね。 WordPress.com から速めに引っ越しして、新環境で記事を書いて行きたいです。