前回、事前に調査した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 junkhack@gpl.jp

あとがき

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