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ヶ月くらい運用していますので、そろそろそのネタも描きたいなと。ついでにアドセンスなんかも運用していますが、これは駄賃くらいにしかならないので、やめた方がいいんじゃないかという感じ。広告でるのは好きじゃ無いし、回避方法は見る側がいくらでもできますしね。

著者にメッセージ

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

    入力内容をご確認ください

    お問い合わせ頂きありがとうございます



      

    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 junkhack.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 junkhack.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://junkhack.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情報を外部に投げる仕組みを考える

          あとがき

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

          著者にメッセージ

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

            入力内容をご確認ください

            お問い合わせ頂きありがとうございます



              

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

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

            ついに99.95%以上を達成したよ!

            きたー!おめでとうー

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

            2月のダウンタイムは3 分 29 秒でした

            スマホサーバなのにがんばったね!

            ぴー
            ぴー

            site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していましたが、ついに達成できました!

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

            LINK

            ちなみに、先月は97.42%で無理でした。site24x7の監視サービスは強力ですが、まだ自動的に復旧する仕組みを作っていないので、再起動は人力となっています。これができれば常に目標SLAを達成できそうです。

            2021・02のSLA

            さて、今月の結果から!
            ダウンタイムの3 分 29 秒で、SLAは99.991%となり今月は目標の99.95%に届きました! やったー!

            ツイッターで、呟いていたらSite24x7の中の人がうれしいメッセージを送ってくれました。

            嬉しいツイート、ありがとうございます!

            少しダウンした原因は?

            毎回、いいところでダウンするので今月は意図的に再起動を手動でしておきました。毎回、ある程度時間が経過すると「Bad Gateway」が出てしまうんです。とりあえず、再起動を少し入れて様子見をしてたんですが、それが良かったようです。赤い部分は再起動を入れたので、そのダウンタイムです。

            まとめ

            今回の教訓は以下となります。

            ・再起動は有効だった
            ・根本原因はまだ未調査。対処療法で再起動して対応
            ・再起動を自動化するには、スマホのリセットを外部から行う仕組み作りが必要
            ・実験用で、UmidigiF2にその仕組みを模索したい

            あとがき

            前回から、スマホを意図的に再起動させる仕組みをどうするか考えています。ハードウェア的に再起動を行うには、バッテリーを外して、電源をリモートからコントロールするようにするとか考えていましたが、root化してある端末ですので、他にも方法がありそうです。それにハードウェア的にリブートさせてもandroidシステムのいろいろな問題(例えば再起動後はロック解除しないとホーム画面まで行けないなど)があります。

            ソフトウェア的には、以下コマンドでシステムが瞬時にシャットダウンします。

            $ tsu
            # reboot -p
            Done

            -pオプションを取れば、リブートします。しかし、このリブートだとWiFi接続に自動的に接続しなかったり、再起動時はロック解除をしないとHOME画面まで行かないのでTermux bootが動作しなかったりと問題があります。

            そこで、以下を試しています。

            Google Play : MacroDroid – デバイス自動化

            https://play.google.com/store/apps/details?id=com.arlosoft.macrodroid

            このアプリはよく出来ていて、これを使うことにより、以下のような事ができることがわかりました。

            ・一定曜日の特定時刻にソフトリブート(要root化必要)
            ・起動時にWiFiの特定APへ接続(ヘルパーアプリ使用)
            ・起動時に特定アプリを強制起動(termuxを起動させる)

            このリブートだと、ロック解除しなくても特定アプリが動かせるし、WiFiへの接続も問題なさそうです。

            termux が動作すれば termux boot でtermux内部のソフトウェアは起動します。今は、テストでdnsmasqやsshdを自動起動させていますが問題なさそうです。とりあえずは、一定間隔でリブートさせることは出来そうです。

            site24x7の障害検知サービスをどのように受けて、このシステムと切り離してトリガーしてリブートできるよう、何か良い方法はないかなと考えているところです。トリガーはいろいろあるので、その方法を模索中です。

            著者にメッセージ

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

              入力内容をご確認ください

              お問い合わせ頂きありがとうございます