TermuxのパッケージPHP7.4.21最新ビルド

じゃんくはっく
じゃんくはっく

最近、仕事が忙しがったー!

もう今年も半分終わっちゃいましたね。

ぴー
ぴー
じゃんくはっく
じゃんくはっく

今回は、TermuxのPHPを最新の7.4.21 にしたよ

最新ビルド作ったんですか?

ぴー
ぴー

Termux のPHPバージョンは、今は8系になっていて7.4系の最終リリースは7.4.12 でした。ちょっと古かったので、2021年7月01日にリリースされたphp7.4.21をビルドしておきました。7系はあと1年くらいは使うつもりです。ところで、xdebug付きはどうやってビルドするんでしょうね。次の課題です。

PHP7.4.21のダウンロード先

Github: termux-php7

LINK

完全にはテストしていませんが、このサイトにも入れながらテストしています。今のところ大丈夫かな?心配な人は自分でビルドして、テストしてみてくださいね。ビルド方法はググってくだされ。

アップデート方法

前の記事で、php8.xからphp7.4.12にダウングレードする方法は書いていますので、今回はアップデートです。

TermuxでPHP7を使いたい! PHP8からPHP7にして使う。

URL

さくっと、バージョンあげてみましょう。

ステップ1

ZIP圧縮したのも以下にあるのでダウンロードして解凍しておきます。

cd 適当なDIR
wget https://github.com/take-i/termux-php7/raw/master/php_7.4.21-aarch64-deb.zip
unzip php_7.4.21-aarch64-deb.zip

解凍すると以下な感じです。

$ tree php_7.4.21-aarch64-deb
php_7.4.21-aarch64-deb
├── apache2_2.4.46-4_aarch64.deb
├── libicu_67.1_aarch64.deb
├── php-apache_7.4.21_aarch64.deb
├── php-fpm_7.4.21_aarch64.deb
├── php-pgsql_7.4.21_aarch64.deb
└── php_7.4.21_aarch64.deb

今回は、nginxですので、本体とphp-fpmを入れておきます。libicu_67は前回(php7.4.12)と同じなのでそのままです。apacheとphp-apacheはまったくテストしていませんので、自己責任で入れるならお願いします。動作しない場合は、ご連絡を。対応するかは別ですが。

ステップ2

アップデートする前に、パッケージが更新されないようしていた場合は以下のようにパッケージ名が出ますのでそれを解除しておきます。

$ apt-mark showhold
php
php-fpm

解除は、unhold です。

$ apt-mark unhold php php-fpm
Canceled hold on php.
Canceled hold on php-fpm.

解除されたか、再度 1つ上のコマンドを実施しておきます。

ステップ3

アップデートといっても、コマンドは同じです。

cd php_7.4.21-aarch64-deb
※以下は今回入れないので削除。
rm apache2_2.4.46-4_aarch64.deb php-apache_7.4.21_aarch64.deb* php-pgsql_7.4.21_aarch64.deb*

dpkg -i ./php*

ステップ4

確認。ちゃんと、7.4.21が入っていますね。

$ php -v
PHP 7.4.21 (cli) (built: Jul 10 2021 16:36:28) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

勝手にアップデートされないようマークしておきます。

apt-mark hold libicu php php-fpm

マークされたか、確認

$ apt-mark showhold
libicu
php
php-fpm

ステップ4

nginxとphp-fpm を再起動しておきます。このスマホはroot化してあって、nginxはroot権限でmasterプロセスが動作しているので、sudoしてKILLしておきます。

$ killall php-fpm
$ sudo killall nginx
再起動
$ php-fpm
$ sudo nginx

phpinfo()などで確認しておきます。

まとめ

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

・termuxのphp最新をビルドしてみた
・テストは人柱として、このホストやっています
・何かあれば報告(してね)
・xdebug付きのもビルドしてみたいがどうやるんだろうか?

あとがき

まだこのブログは、スマホのumidigi F2で動作させています。そろそろ電池を交換したので、pixel3を復活させないとですが、腰が思いです。あと、最近keyCDNも1ヶ月くらい運用していますので、そろそろそのネタも描きたいなと。ついでにアドセンスなんかも運用していますが、これは駄賃くらいにしかならないので、やめた方がいいんじゃないかという感じ。広告でるのは好きじゃ無いし、回避方法は見る側がいくらでもできますしね。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

静的HTMLをWordPressから作るには?

じゃんくはっく
じゃんくはっく

静的ページでミラーサイト作りたいな!

WordPressからHTML作るやつですね!

ぴー
ぴー
じゃんくはっく
じゃんくはっく

GitPagesとかNetlifyとかでブログ運用できるからね

コメントとかメール送信とかは?

ぴー
ぴー

ここんところ、WordPressから静的なHTMLを吐き出して運用するにはどうしたらいいかっていう事を研究していました。このブログは、現在スマホのPixel3やUmidigiF2で作られていますが、静的なHTMLページにできたら、かなり処理負荷が減り、またセキュアな運用ができるので実現してみたいなと思っています。

WordPressは設計が古い、王道のWEB-DBアプリ

WordPressは最初のバージョン1.xがリリースされてもうすぐ20年になろうとしています。付き合いは古く1.xと2.xの変わり目あたりからWordPressをいろんな用途で使っていました。基本的な設計は今も変わっておらず、WEB-DBアプリケーションの位置づけです。

WorePressは、アクセスされる側(フロントと俗にいいます)にPHPがあり、記事の実態や設定などは裏方(俗にバックエンドといいます)でMySQLデータベースが処理する王道なWEB-DBアプリです。図では以下のようになります。

PHP処理時間や、データベース処理時間をなくせば劇的に速くなります。今テストで2つのサーバに静的なHTMLを出していますので、記事の後半で視覚的に評価してみます。

静的なHTMLを吐き出すとどんなメリット・デメリットが?

WordPressがこの構成をしているのは、動的に処理ができるからです。記事の検索や各種プラグイン処理、コメント処理、メール送信機能などです。たとえば、この記事には「目次」がありますが、これは「LuckyWP Table of Contents」というプラグインが自動的に挿入してくれています。こういう固定表示系のプラグインは静的なHTMLを吐き出しても問題ありません。しかし、コンタクトフォーム 7などメール送信系やコメント部分、あるいは検索系は静的なHTMLでは実現できません。

普通にブログを書いて、コメントはあきらめ、PingBack(もう今はその恩恵もあまりない機能)やメール送信、その他動的に生成される機能を無視すれば、WordPressが出す静的HTMLで十分なんじゃないかなと思ったりします。

どうやって静的なHTMLを取得するか?

前置きが長くなりましたが、どうやって実現するかです。クライアント側でwgetコマンドなどを使い取得する方法や、WordPress本体側(プラグインを使って)から取得する方法の2つに大別されます。今のところ、プラグインを使ってHTMLを吐き出す方法が良さそうかなと思っています。実際に試して評価したのは以下2つです。

Simply Static

https://ja.wordpress.org/plugins/simply-static/

もう一つはこちら。

Export WP Page to Static HTML/CSS

https://wordpress.org/plugins/export-wp-page-to-static-html/

両方とも、Pro版があります。今のところ、後者の「Export WP Page to Static HTML/CSS Pro」は現時点の最新がver1.0.4ですがバグがあり正常に取得できません。またスラッグ にマルチバイト文字列があるとファイル生成時にURLエンコードされたファイル名で保存されてしまいます。(リンクされず404になる)この問題はSimply Staticでもありますが、英数字スラッグ であればSimply Staticでは問題ありません。もう少し様子を見て、良さそうならSimply StaticのPro版を検討しようかなと思っています。こちらはGit連携があるようで、完全に静的HTMLを他のWEB領域にデプロイすることができそうです。

Simply StaticのGitHub統合

https://patrickposner.dev/docs/simply-static/github/

静的ファイルをGitHub Pagesに出してみた

このブログを微調整した開発サイトから、Simply Staticを使い静的なHTMLを出力しGitHub Pagesにコミットしてみました。ドメインは独自ドメインにマッピングしてあります。SSLも自動ですので便利。

Github Pagesミラーサイト

https://jh2.gpl.jp/

こちらの応答時間はsite24x7の監視で以下のようです。

東京観測地点からの平均値は128ms です。速いですね。

静的ファイルをNetlifyに出してみた

GithubPagesのリポジトリにコミットすると、Netlifyにもデプロイされるようにしています。こちらも、ドメインは独自ドメインにマッピングしてあります。SSLも自動ですので便利ですね。

Netlify (ねっとりふぁい)ミラーサイト

https://jh.gpl.jp/

世界にはいろんな静的サイトホスティングがありますが、このNetlifyは無償でも使える有名なところです。こちらの応答時間はsite24x7の監視で以下のようです。

Netlifyの方は、東京から平均835ms です。Github Pagesのほうが速いですね。

比較のため、スマホサーバからの応答時間も

スマホサーバ、WordPress+NGINX+php7.4.x+mariadbでの応答も比較のため出しておきます。これは、KeyCDNを使ったりキャッシュを調整したりいろいろチューニングしています。

Pixel3 スマホサーバ
 WordPress+NGINX+php7.4.x+mariadb KeyCDN

https://hack.gpl.jp/

site24x7の監視で以下のようです。

東京観測地点からは、平均385msです。ちなみに、KeyCDNを経由する前は以下のようです。

平均1.27秒なんでかなり遅いですね。KeyCDNの効果は劇的です。でも1ヶ月に1000円弱かかるんですよね。

また、これ以外にもLargest Contentful Paint(LCP)という指標があり、簡単に言えばユーザーがそのページにアクセスしたとき、一番大きな画像またはテキストブロックが描画される時間です。具体的にウチのブログの場合は、以下がそれです。

これも、KeyCDNを使うと1.3秒くらいまで縮まりますが、使わないと4秒くらいかかってしまいます。しかし静的HTMLサイトなら、時間帯にもよりますが1秒から1秒弱くらいになります。

WordPress構成のサイトだと、いろいろチューニングしないとこのくらいの速度にはなりません。結構面倒で、CDNを契約するとそれなりにコストがかかります。月間1万ページビューくらいのブログでも1000円くらいはCDNに持っていかれます。何も意識しなくても、静的HTMLページだとそれより速いですからね。しかも、GitHub Pagesや、Netlifyを使えば無料の範囲で実現できます。

まとめ

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

・静的HTMLファイルだけで運用してみる価値は十分にあるが、迷う
・とりあえずミラーサイト的な位置づけで実験運用
・静的HTMLにした場合、検索、メール、コメント、Feedをどうするか?
・逆にそれ以外はほぼ、WordPressの動的機能を使う必要性は感じない
・全記事、スラッグ を英語にするにはどうしたら?自動変換してくれるプラグインとか?

あとがき

ほんとWordPressって手間がかかりますね。こういうのが面倒なんで、アーキテクチャーがオワコンとか言われているんです。

しかし、WordPress がnode.jsで動作して、設計も一新される時がいつかくるかもしれません。新しいものが必ずしも良いとは限りませんが、確実にアーキテクトは変化していきますので、何が最適なのかはいろいろ実験して手法を知っておくことが大切だなと思っています。チューニング次第では、apacheもnginxに近づけますし(面倒ですが)、WordPressも静的サイトに近づけることは可能です。まぁでも、実際は楽でセキュアなのが良いですよね。今時、sendmailなんて使いませんし、WEBサーバはnginxが主流です。

仕事では、あまり実験できないので趣味の範囲でいろいろ実験しておいて使えそうだなと思った手法は実際に仕事にフィードバックしていきたいですね。月〜金で仕事でmac使って、土日もほとんど同じような事をやっていますので、この業界が好きなんでしょうね。というか、オタクなだけですが。。。

ネットとPCと通販があれば、場所はどこでも生きていけそうです。ログハウスとか、手作りしながら、ブログ、Youtubeで配信する生活に憧れます。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

1つ目のWordPressの記事を2つ目のWordPressにコピーするプラグインはどこかに無いかな?

じゃんくはっく
じゃんくはっく

今日もWordPress触っていくよ〜!

ってか、最近暑いわね!

ぴー
ぴー
じゃんくはっく
じゃんくはっく

1つ目のWordPressの記事を2つ目のWordPressにコピーするプラグインとか誰か作ってないかなーと探してる

MainWPってのはどう?

ぴー
ぴー

AサイトのWordPressとBサイトのWordPressの記事を管理してみたいので、そんなプラグインがあるか探してみました。大体、だれかが何か作っていたりするので、まずはリサーチです。やりたいことは、言葉で書くとわかりにくいので、図に書くとこうなります。

記事Item 1Item 2Item 3
WordPress B
WordPres…
WordPress A
WordPres…
記事Item 1Item 3
Viewer does not support full SVG 1.1

つまり、Aサイトの投稿済み記事をBサイトに個別にコピーするという感じです。画像などのリソースもそのままBサイトに入れば最高です。

AサイトもBサイトも設定やプラグイン構成やテーマが違うので、記事とそのリソース(画像など)を複製できればいいのですが、、、そんなことはどうやったら実現できるでしょうか。それを今日は検討しています。

MainWPプラグインはどうかな?

MainWPっていうのがありました。使い方は省略しますが、こんな事が実現できることはわかりました。

・管理WPから、複数の新規記事を複数のWPサイトへ発行できる。
・MainWP本体プラグインを管理WPに入れる。配信するWPにはMainWP Childを入れる
・2台構成の場合は、管理WPに、MainWPとMainWP Childを入れる

残念ながら、Aサイトのすでに投稿済みの記事を個別に選んで、Bサイトにコピー(投稿)することはできないそうです。Pro版を使ってもダメみたい。どうりでそんなインターフェイスがないわけだ。

 ということで、何か違う方法を模索。XML-RPC経由か、DBにトリガーを作るか。または、、、、うーん、DBだけだったら、レプリケーションフィルターオプションとかで行けそうかも。WordPressの機能を使ってやるのが良さそうですが。

記事をコピーしてどうするの?

はい、実は今研究中の課題がありまして、それはGitHubのPagesにWordPressコンテンツを静的ファイルにして書き出すというものです。

GitHubのpagesにコミットしたWordPressの静的ページ(テスト中)

https://junkhack.github.io/

このページは、WordPressから書き出した静的なファイルです。それを吐き出すようの専用のWordPressを作って、メインサイトから記事を同期させたかったわけです。メインサイトとは、プラグイン構成やテーマファイルが変わる予定なので、これらを実現するには、記事のコピーが必要だったわけです。

GitHub pagesは、まだテスト中なので、リンクが切れていたり、画像がgithubからじゃなかったりするページがありますが、全体としては結構使えるんじゃないの? という感触です。たとえば、ニューヨークからの接続時間は、現在のスマホサーバに接続すると以下のような時間となりますが、

GitHubのpagesにコミットした静的ページだと、以下のように速くなります。

さすが、htmlやcssやjsだけの静的ファイルになると速いですね。Githubのリソースだから自動的にCDN経由になりますしね。速度的には以下な感じです。測定拠点はワシントンです。

PageSpeed Insights(GoogleのWEB速度チェック)でも、いい感じでした。

GitHub Pagesのリソース制限は?

リソース制限などは、以下のサイトにまとまっています。

GitHub Pagesでホストするサイトのアクセス上限は月10万リクエストが目安
::(抜粋)
 GitHub Pagesソースリポジトリの推奨制限は1GB
 公開されているGitHub Pagesサイトは1GB以下
 GitHub Pagesサイトは、1か月あたり100GBまたは100,000リクエストの帯域幅制限
 GitHub Pagesサイトは、1時間あたり10ビルドの制限

LINK

個人サイトのブログ程度なら、ミラーサイトとして問題なさそうな感じですかね。

まとめ

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

・MainWPを使ってみた
・しかし、これは個別で投稿済みの記事をBサイトにコピーはできない
・GitHub Pagesのリソース制限は個人サイトくらいなら問題なさそうかな?
・WordPressを静的に吐き出して利用するには、まだまだいくつか考慮するポイントがありそう。

あとがき

世の中は広いから、大抵のものはだれかが作っています。 リサーチしてると面白いものがどんどん発掘されて、当初の目的を忘れていたりします。w さて、次はWordPressの静的ファイルに書き出す仕組みづくりを検討です。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

工学社 の本、androidの改造 に掲載されたよ!

なんと、このブログの記事が工学社の本に掲載されましたよ!

ぴー
ぴー
じゃんくはっく
じゃんくはっく

なにぃー! こんなふざけたブログが本に載っただと!

よかったら、本屋さんまたはネットでポチってね!

ぴー
ぴー
じゃんくはっく
じゃんくはっく

ネタは「Pixel3のroot化」の件です。

工学社 出版のI/O編集部さんが、「Androidスマホの改造」っていうタイトルの本を出されたのですがその中で、なんと、このブログの記事の一部が載っていますよ。ただいま、絶賛予約中です! 5/27発売です。

出版社 : 工学社 (2021/5/27)
発売日 : 2021/5/27
言語 : 日本語
単行本 : 112ページ
ISBN-10 : 4777521494
ISBN-13 : 978-4777521494
寸法 : 14.8 x 1 x 21 cm

元ネタとなった当ブログの記事はこれです。

Pixel3・android11(R)正式リリース版でroot化!

LINK

内容抜粋

工学社さんのサイトに抜粋がありましたので引用しておきます。第一章に、赤文字部分が掲載された部分です。

■非公式アプリを入れる―root化
 機械オンチでも出来る!Androidをroot化する方法
 Pixel3・android11(R)正式リリース版でroot化

■“スクショ”禁止のアプリで画像を保存 ―「Xposed」導入
 Androidに「Xposed」を導入する方法
 「Xposed」の使い方に関するアレコレ

■有志が作った最新OSでセキュリティ向上 ―ROM焼き
 「Xperia XZs」のROM焼き
 ROM焼き手順

■キャリア以外のSIMカードを入れる―「SIMロック解除」
 「SIMロック解除」とは
 「SIMロック解除」の条件と手順について

■高度なカスタマイズを可能に―adbコマンド
 「Windows」で「adbコマンド」を使う方法
 「Mac」で「adbコマンド」を使う方法

あとがき

こんなブログの記事が、まさか本になるとは思っていませんでした。依頼が来た時は、びっくりです! 汎用性がある記事っていうのは、目に止まるっていうことですかね。root化の記事もそれなりに需要があるということですね。

 今度は root化したらこんなことができるよっていう記事も書いていこうと思いました。今回の本にも載っている「あっとはっく」さんのサイトは面白い記事がたくさんありますね。見習いたいと思います。

日々をハックする記事をお届け:あっとはっく

LINK

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

TermuxでNGINX+php-fpm+mariadbを動かす具体的な設定例

じゃんくはっく
じゃんくはっく

今日もTermuxとWordPress触っていくよ〜!

今日は何するんですか〜?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

一時的にPixel3からUmidigiF2へスマホサーバを移動しようと思って設定を纏めておいた!

設定の備忘録ですね!

ぴー
ぴー

さて、最近記事をサボりがちでしたがコメントにて、「TermuxでWordPressを動かす具体的な設定例」が見たいとご意見をいただきましたので、自分のメモがてら纏めておきます。

まずはUmidigiF2の電池交換

アリエク:UmidigiF2 バッテリー(購入時は1,283円)

Link

UmidigiF2の電池が膨らんできましたので、アリエクで買ったUmidigiF2の電池に交換します。裏蓋は粘着テープで貼り付けられているだけなので、カードとかピックで分離します。

NFCやカメラ部分がプラスティック部品で固定されているので、周りのネジ11本を外してバッテリーコネクタを外せるようにします。

バッテリーの裏は透明なフィルムで剥がせるよう工夫されています。よく切れるテープとかは使われていませんでした。交換自体はPixel3とかと比べると非常に楽ですね。メンテナンス性は良いです。あとは両面テープを貼り直して裏フタを固定するだけです。

 さてと、では面倒な設定まとめを書いておきます。

Termuxを入れてアプリを設定

Termuxについては、Google Play Storeから入れます。root化していなくても大丈夫ですが、ポート制限があるので1024ポート以上でないとWEBサーバは公開できない仕様です。

Termux:Google Play Store

URL

リモートから設定したほうが楽なので、最低限SSHを入れて起動しておきます。パスワードを設定しておきます。

pkg update 
pkg install openssh
sshd
passwd

あとはリモートからSSH接続して設定していきます。面倒でなければSSH鍵認証の設定をしておいてもOKです。

ssh termux_host_ip -p 8022

他、アプリNGINX+php-fpm+mariadbも入れておきます。

pkg install nginx php-fpm mariadb

どんなバージョンが入っているか確認しておきます。

dpkg -l | egrep 'nginx|php|mariadb'

現時点、2021/05/11 時点では以下のバージョンになりました

$ dpkg -l | egrep 'nginx|php|mariadb'
ii  mariadb                    2:10.5.8       aarch64      A drop-in replacement for mysql server
ii  nginx                      1.20.0         aarch64      Lightweight HTTP server
ii  php                        8.0.6          aarch64      Server-side, HTML-embedded scripting language
ii  php-fpm                    8.0.6          aarch64      FastCGI Process Manager for PHP

2020/10頃は、PHPが7.4.xだったのでver8系になったようです。PHP8の新機能はここ参照。

PHP7が良い場合は、ここにdebfileがあるようです。Wordpressを動かす場合はPHP7.4.12のほうが無難かも。あとで検証してみます。

 ※追記

上記のdebfile だとエラーになって動作しないようでしたので、ビルドしなおしました。ここ参照

NGINXの設定

ホームディレクトリ以下にWEBのドキュメントROOTを作ります。どこでもいいのですが、termuxの$HOMEに作ります。自分の場合は、デフォルトのWEB ROOT(htdocs_default)と、hack.gpl.jp ドメインのWEB ROOT(htdocs_nginx)を分離しています。

$ echo $HOME
/data/data/com.termux/files/home
$ cd
$pwd
/data/data/com.termux/files/home
$ mkdir htdocs_nginx
$ mkdir htdocs_default

あと、SSL関連のファイルを格納しておくのでそれ専用のディレクトリも作っておきます。SSL関連は以下を参照

Termuxネイティブ環境でacme-nginxを使いワイルドカード証明書を自動取得!

LINK
$ cd
$ mkdir -p ssl/gpl.jp/ 
$ tree ssl
ssl
└── gpl.jp

NGINXの設定ファイルを作ります。conf.dディレクトリに分離して設定ファイルを保存するのでディレクトリも作っておきます。

$ cd
$ cd ../usr/etc/nginx/
$ mkdir conf.d

オリジナルファイルをバックアップしておきます。UNIX系ではDiff取ったりして確認したりすることもあり、設定ファイルは消すより待避する癖をつけておいたほうが無難です。自分の場合は、_org が元あったファイルという意味にしています。

$ cp -p nginx.conf nginx.conf_org

今回の設定例では、root化してある端末なので、ポートは80と443にしています。root化していない場合は程よく読み替えてください。
nginx.conf ファイルは以下のように設定しています。userは、termuxを入れた環境によって違いますので whoamiやidコマンドで確認しておきます。

user  u0_a143;
worker_processes  auto;
worker_rlimit_nofile 4096;

error_log  /data/data/com.termux/files/usr/var/log/nginx/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    use epoll;
    multi_accept on;
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type text/plain;

    charset            utf-8;
    sendfile           on;
    tcp_nopush         on;
    tcp_nodelay        on;
    server_tokens      off;
    keepalive_requests 100;
    keepalive_timeout  3;

    server_names_hash_bucket_size 64;
    types_hash_max_size 2048;
    client_body_buffer_size 64k;
    client_body_temp_path /data/data/com.termux/files/home/htdocs_default/tmp/client_body_temp 1 2;
	
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /data/data/com.termux/files/usr/var/log/nginx/access.log  main;

    gzip  on;
    gzip_vary       on;
    gzip_proxied    any;
    gzip_comp_level 6;
    gzip_types      text/plain text/css text/xml text/javascript
                    application/json application/javascript application/x-javascript
                    application/xml application/rss+xml application/atom+xml
                    image/svg+xml image/x-icon;

    ssl_session_timeout 30m;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_tickets off;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /data/data/com.termux/files/usr/etc/nginx/dhparam.pem;
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;

    fastcgi_buffers         8 64k;
    fastcgi_buffer_size     64k;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout    60;
    fastcgi_read_timeout    300;

    proxy_connect_timeout 60;
    proxy_send_timeout    60;
    proxy_read_timeout    120;
    proxy_http_version    1.1;
    proxy_cache_bypass    $http_upgrade;
    proxy_set_header      Upgrade            $http_upgrade;
    proxy_set_header      Connection         "upgrade";
    proxy_set_header      Host               $host;
    proxy_set_header      X-Real-IP          $remote_addr;
    proxy_set_header      X-Forwarded-Host   $host;
    proxy_set_header      X-Forwarded-Server $host;
    proxy_set_header      X-Forwarded-For    $proxy_add_x_forwarded_for;
    proxy_set_header      X-Forwarded-Proto  $scheme;
    #proxy_set_header      X-Forwarded-Port   $server_port;
    proxy_set_header      X-Forwarded-Port   443;
    proxy_temp_path       /data/data/com.termux/files/usr/var/log/nginx/tmp;
	
    ## cache_pathについては別ファイルで設定する
    include /data/data/com.termux/files/usr/etc/nginx/conf.d/cache_path.conf;
		
    server {
        listen *:80 default_server;
        server_name  _;
		root   /data/data/com.termux/files/home/htdocs_default;

		charset utf-8;

		access_log  /data/data/com.termux/files/usr/var/log/nginx/host.access.log  combined;
		error_log  /data/data/com.termux/files/usr/var/log/nginx/host.error.log warn;

	    index index.html;
	    include /data/data/com.termux/files/usr/etc/nginx/conf.d/common.conf;

	}

	include /data/data/com.termux/files/usr/etc/nginx/conf.d/hack.gpl.jp.conf;
	include /data/data/com.termux/files/usr/etc/nginx/conf.d/gpl.jp.conf;
	
}

SSLのdhparamは、以下で出しておきます。この意味についてはここ参照

openssl dhparam -out /data/data/com.termux/files/usr/etc/nginx/dhparam.pem 2048

設定ファイルはインクルードしてあります。

conf.d/cache_path.conf
conf.d/common.conf
conf.d/hack.gpl.jp.conf
conf.d/gpl.jp.conf

まず、cache_path.conf の設定です。キャッシュディレクトリも作成しておきます。

mkdir -p /data/data/com.termux/files/home/cache/hackgpljp
mkdir -p /data/data/com.termux/files/home/cache/proxy.gpljp
mkdir -p /data/data/com.termux/files/home/cache/wwwgpljp

cache_path.conf

location ~ /. {

## php-fpmでキャッシュを作る時
fastcgi_cache_path /data/data/com.termux/files/home/cache/hackgpljp levels=1:2 keys_zone=gpljp:30m inactive=600m max_size=10g;
## proxy経由でキャッシュを作る時
proxy_cache_path /data/data/com.termux/files/home/cache/proxy.gpljp levels=1:2 keys_zone=proxy_gpljp:30m inactive=600m max_size=10g;

# www.gpl.jp or gpl.jp
fastcgi_cache_path /data/data/com.termux/files/home/cache/wwwgpljp levels=1:2 keys_zone=wwwgpljp:18m inactive=5m max_size=10g;

common.conf は以下です。

## .htpasswdとか . から始まるファイルへのアクセスは404で応答
## 403だとそのファイルがあるのが外からわかってしまう
location ~ /. {
    return 404;
}
 
## ファイルが無くてもエラーログを出さない
location ~ /(favicon.ico|apple-touch-icon-*) {
    log_not_found  off;
    access_log  off;
}

このサイトのメイン設定 hack.gpl.jp.conf は以下です。

server {
    listen      80;
    server_name jh.gpl.jp hack.gpl.jp hack.gpl.jp;

    root   /data/data/com.termux/files/home/htdocs_nginx;

    access_log  /data/data/com.termux/files/usr/var/log/nginx/hackgpljp.access.log  combined;
    error_log  /data/data/com.termux/files/usr/var/log/nginx/hackgpljp.error.log warn;

    client_max_body_size 20M;
    ## キャッシュの設定:有効 -> 0 無効 -> 1
    set $do_not_cache 0;
    ## キーゾーン名
    set $keys_zone gpljp;
	
    include /data/data/com.termux/files/usr/etc/nginx/conf.d/common.conf;
    include /data/data/com.termux/files/usr/etc/nginx/conf.d/hackgpljp_wp.conf;
    include /data/data/com.termux/files/usr/etc/nginx/conf.d/add_header.conf;
}
 
server {
     listen      443 ssl http2;
     server_name jh.gpl.jp hack.gpl.jp hack.gpl.jp;
     root   /data/data/com.termux/files/home/htdocs_nginx;

     access_log  /data/data/com.termux/files/usr/var/log/nginx/ssl_hackgpljp.access.log  combined;
     error_log  /data/data/com.termux/files/usr/var/log/nginx/ssl_hackgpljp.error.log warn;

     client_max_body_size 20M;
     ## サイトのSSL証明書
     ssl_certificate     /data/data/com.termux/files/home/ssl/gpl.jp/gpl.jp.crt;
     ssl_certificate_key /data/data/com.termux/files/home/ssl/gpl.jp/gpl.jp.key;

     ## キャッシュの設定:有効 -> 0 無効 -> 1
     set $do_not_cache 0;

     ## キーゾーン名
     set $keys_zone gpljp;

     ## 必要な設定ファイルを読み込み
     include /data/data/com.termux/files/usr/etc/nginx/conf.d/common.conf;
     include /data/data/com.termux/files/usr/etc/nginx/conf.d/hackgpljp_wp.conf;
     include /data/data/com.termux/files/usr/etc/nginx/conf.d/add_header.conf;
}

ここで、インクルードしている設定は以下です。

conf.d/hackgpljp_wp.conf
conf.d/add_header.conf

hackgpljp_wp.conf

index index.php index.html;
error_page 404 /index.php?error=404;
 
# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~ /. {
    deny all;
}
 
# Deny access to any files with a .php extension in the uploads directory
# Works in sub-directory installs and also in multisite network
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~* /(?:uploads|files)/.*.php$ {
    deny all;
}

set $is_mobile '';
 
## スマートフォン用のキャッシュを作る為の判定処理
## WordPress標準の wp_is_mobile() 関数と同じ判定処理
if ($http_user_agent ~* '(Mobile|Android|Silk/|Kindle|BlackBerry|OperasMini|OperasMobi)') {
    set $is_mobile 'mobile.';
}

set $do_not_cache 0;

## GET メソッド以外はキャッシュを作成しない
if ($request_method != GET) {
    set $do_not_cache 1;
}

if ($query_string != "") {
	set $do_not_cache 1;
} 

## キャッシュして欲しくないファイルは除外
if ($request_uri ~* '/(wp-admin/|wp-login.php|wp-cron.php|xmlrpc.php|wp-json/|??feed|wp-json|sitemap.xml)') {
    set $do_not_cache 1;
}
 
## ログイン済みのユーザー等、Cookie を持っていたらキャッシュを使わない
if ($http_cookie ~* 'comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in') {
    set $do_not_cache 1;
}
 
## 画像ファイル等はブラウザキャッシュを効かせる (60日)
location ~* .(jpg|jpeg|gif|png|css|js|swf|ico|pdf|svg|eot|ttf|woff)$ {
    expires 60d;
    add_header Cache-Control "public, no-transform";
    access_log off;
}
 
## リクエストは index.php に投げる
location / {
    try_files $uri $uri/ /index.php?$args;
}
 
## NginxとPHP-FPMはソケットで繋ぐ
## HTTPステータスコードによって各キャッシュの有効期限を制御する
location ~ .php {
 
    try_files $uri /index.php;
 
    include fastcgi_params;
    fastcgi_pass  unix:/data/data/com.termux/files/usr/var/run/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME  /data/data/com.termux/files/home/htdocs_nginx$fastcgi_script_name;
 
    fastcgi_no_cache     $do_not_cache;
    fastcgi_cache_bypass $do_not_cache;
    fastcgi_cache        $keys_zone;
    fastcgi_cache_key    $is_mobile$scheme://$host$request_uri;
    fastcgi_cache_valid  200 5m;
    fastcgi_cache_valid  301 302 1h;
    fastcgi_cache_valid  404 1m;
    fastcgi_cache_valid  any 1s;
 
    fastcgi_hide_header X-Powered-By;
}

add_header.conf は以下です。

add_header Strict-Transport-Security "max-age=15552000"; 
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options SAMEORIGIN;

add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy "default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' ;";
add_header Referrer-Policy strict-origin always;
add_header Permissions-Policy "fullscreen=() geolocation=()";
add_header X-hacker "Hello. :-)";

PHPの設定

WordPressを動かすなら、少しPHPの上限を上げておくほうが無難です。termuxパッケージのPHPは、デフォルトファイルがないので、php.iniは以下に作ります。

vi /data/data/com.termux/files/usr/lib/php.ini
[PHP]
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 128M

[mail function]
sendmail_path = "/data/data/com.termux/files/usr/bin/msmtp -C /data/data/com.termux/files/home/.msmtprc -t"

iniで指定してある、phpからのメール送信設定は、msmtpを使っています。これは以下を参照。

Termuxからメールを送れるようにするには?

https://hack.gpl.jp/2020/09/30/termux-smtp-client/

NGINX+php-fpmの動作確認

たくさんインクルードファイルがあって、わかり辛いかもですね。うまく動作しているか動作確認です。

sudo nginx

root化してある場合は、nginxはroot で動作させないとポート80,443にバインドできません。1024以上であればtermuxの一般ユーザで起動させます。

 起動時に何かエラーメッセージが出たらその対応をしていきます。

mariaDBの設定

冒頭でmariaDBのパッケージはインストールしています。ここでは初期設定をします。基本的には以下でいけるはずです。

Termux Wiki : MariaDB

https://wiki.termux.com/wiki/MariaDB

mysqlに接続するコマンドは、リモートからではなくtermuxのスマホ本体から行ってください。リモートからだと、権限がらみでtermuxユーザでmysql接続、use mysql; ができません。

mariadb を起動します。

$ mysqld_safe &

以下はリモートからではなくtermuxのスマホ本体から行ってください。

mysql -u $(whoami)

リモートからDB Toolを使いたいので権限をつけておきます。リモートホストIPや、passwordなどは程よく読み替えてください。

use mysql;
set password for 'root'@'localhost' = password('YOUR_ROOT_PASSWORD_HERE');
GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.1.%' IDENTIFIED BY 'YOUR_ROOT_PASSWORD_HERE';
flush privileges;
quit;

リモートのGUIツールから接続テストをしておきます。以下は、macのTablePlusというツールの画面です。

termuxのsshユーザー名はなんでも良いです。ここでは無指定です。

あと、デフォルトのcharacter-setを指定しておきたい場合は以下のようにします。

vi /data/data/com.termux/files/usr/etc/my.cnf.d/server.cnf
$ cd
[client]
default-character-set = utf8mb4
[mysqld]
character-set-server = utf8mb4

utf8mb4は文字を1〜4byteで取り扱うので、こっちがよろしいかと。

mariadbを再起動しておきます。

$ ps axu | grep mariadb
 ※PIDを確認
$ kill 30563
$ mysqld_safe&

WordPressを動かしてみる

ほどよくDBを作成して、WEB ROOTにWordpressを展開します。

$ cd
$ wget https://ja.wordpress.org/wordpress-5.7.1-ja.zip
$ unzip wordpress-5.7.1-ja.zip
$ mv wordpress/* htdocs_nginx/
〜省略〜

以下、省略。PHP8環境でのWordPress動作確認は何か気がつけばネタにしたいと思います。

まとめ

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

・現状の設定だとコメント投稿がうまく動作しない
・ジェットパックのいいね も動く時と動かない時がある
・TermuxのPHPパッケージが8になっていた
・WordPressがPHP8で問題ないか確認する
・とりあえず、wp5.7.1でプラグインが何もない状態であれば動いているように見える
・今、使っているプラグインやテーマを全部突っ込んでみて確認してみる

あとがき

サーバ設定とか、ほんとダルいですねー! 最近はインスタンスも1から作る機会なんてだいぶ減ってきているんで、こういう設定とかめんどくさいなーって感じました。AWSもGCCも、ずいぶん楽できる環境が整っているからそう感じるわけで。なんでもリモートできる、良い時代ですね。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

2021/03 site24x7 でのSLA状況・統計データ

じゃんくはっく
じゃんくはっく

新年度、始まりましたね!

この季節、あったかくて好きだわー

ぴー
ぴー
じゃんくはっく
じゃんくはっく

リモートで自宅で仕事してるときが一番つらいねw

せめて散歩でもして気晴らししないとね!

ぴー
ぴー

春ですねー! めちゃくちゃ暖かくなって外出したいんですが、なかなか世間の事情で旅行とまでは行きませんよね。せめて、散歩くらいはしたいものです。仕事の用事で、東京ー名古屋間をバイクで走ったのですがまだ夜は寒かったです。昼はちょうどいい天気で、めちゃくちゃ気持ちよかったです。

 さて、ちょっと遅れましたが今回も3月のSLA統計データを出しておきます。

何を目指しているの?

稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

LINK

site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指しています。99.95%とは1ヶ月にダウンタイムが21.6分以内であればOKということですが、10月から初めて1回しかクリアしていません。今年の2月に達成できたのですが、それ以外はNGINXか、PHPか、何かがメモリーリークしているような現象になります。

2021・03のSLA

今月の結果です。障害時間の合計は7 時間 39 分あって、SLAは98.972%となり目標の99.95%には届きませんでした。今月からなのか、site24x7のレポート画面が少し進化したようです。

主な内容はNGINXの「Bad Gateway」問題です。この事象は不定期に発生しますが、必ずOSがフリーズしたような現象になります。おそらくメモリーリークしている感じです。完全にOSが死んでいるわけではなく、かろうじて動作はしています。なぜなら、NGINXはBad Gatewayの応答を出しています。また、thingspeakで、CPU温度や、バッテリー温度をpythonで投げているのですがこれは動作しています。再起動するときに AndroidOSのホームを開こうしても開ません。仕方なく、電源ボタン長押しで強制再起動という感じです。

どのくらいのアクセス数なの?

去年の10月くらいから、pixel3のスマホサーバに引越ししたのですが、アクセス状況はこんな感じです。引越し以前のデータもそれほどかわりません。横ばいといった感じです。

こんなサイトでも3000人くらいのユーザさんが見ているのには驚きです。見ていてくださってる読者さんには感謝ですね。

まとめ

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

・時間をなんとか作って、NGINXを新システムに載せ替える
・メモリ使用量などOS情報を外部に投げる仕組みを考える

あとがき

課題はわかっていて、その調査をするか、代替え策を実行するか、やるべきことはわかっているのですが、腰が重いです。やることが退屈なので、違う面白いことに目がいってしまい、そのうち手をつけたいなと数ヶ月ずっと思っています。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。