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" '
                      'statusbody_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_bypasshttp_upgrade;
    proxy_set_header      Upgrade            http_upgrade;
    proxy_set_header      Connection         "upgrade";
    proxy_set_header      Hosthost;
    proxy_set_header      X-Real-IP          remote_addr;
    proxy_set_header      X-Forwarded-Hosthost;
    proxy_set_header      X-Forwarded-Server host;
    proxy_set_header      X-Forwarded-Forproxy_add_x_forwarded_for;
    proxy_set_header      X-Forwarded-Proto  scheme;
    #proxy_set_header      X-Forwarded-Portserver_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;
    ## キーゾーン名
    setkeys_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;

     ## キーゾーン名
     setkeys_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;
}

setis_mobile '';
 
## スマートフォン用のキャッシュを作る為の判定処理
## WordPress標準の wp_is_mobile() 関数と同じ判定処理
if (http_user_agent ~* '(Mobile|Android|Silk/|Kindle|BlackBerry|OperasMini|OperasMobi)') {
    setis_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 uriuri/ /index.php?args;
}
 
## NginxとPHP-FPMはソケットで繋ぐ
## HTTPステータスコードによって各キャッシュの有効期限を制御する
location ~ .php {
    try_filesuri /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_nginxfastcgi_script_name;
    fastcgi_no_cachedo_not_cache;
    fastcgi_cache_bypass do_not_cache;
    fastcgi_cachekeys_zone;
    fastcgi_cache_key    is_mobilescheme://hostrequest_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情報を外部に投げる仕組みを考える

あとがき

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

著者にメッセージ

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

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

著者にメッセージ

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

XIAOとスマホだけでnode.jsのJohnny-Fiveを動かす最短コースをご案内!

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

きたきたきたー!

なんか興奮してますね!w

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

スマホとXIAOだけでNodeのJohnny-Fiveを動かせるようになったよ!

NodeとかJohnny-Fiveとか何それ?

ぴー
ぴー

はい、ちょっと興奮気味なんですが今日のネタは、

「XIAOとスマホを接続して、それだけでXIAOを制御する!」

ってことがメインテーマです。物理的な接続イメージは図に書くとこんな感じです。node.js実行環境をtermuxに作り、johnny-fiveというnode環境で動作するものをFirmataプロトコルでXIAOとやりとりします。もっと簡単にいえば、

JavaScriptでXIAOを操る ですね。

通常、node.js実行環境はPCに作ったりしますので、物理的な接続イメージは以下のようになるかと思います。

JavaScriptでXIAOのGPIOを操作するのですが、まだこの構成のメリットがよくわかっていませんので、触ってみようと思いました。

物理的に用意するもの

(1) Androidスマホ
(2) Seeed XIAO
(3) ケーブル(Type-C x Type-C)

Androidスマホは手持ちのものでも、余ったものでもOKです。XIAOは3個入りで1800円くらいでアマゾンから購入できます。ケーブルは100円ショップですね。

Androidスマホ の必要アプリ

GoogleStore : Termux

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

まず、Androidスマホのアプリを入れておきます。あと、もう一つ有償アプリですが以下を入れておきます。日本円で190円です。

GoogleStore : BT/USB/TCP Bridge Pro

https://play.google.com/store/apps/details?id=masar.bluetoothbridge.pro

これはブリッジアプリで、今回の用途ではXIAOのUSB接続のシリアル通信をTCP上にブリッジする用途で使います。シリアルTCPのブジッジアプリは他にもいろいろありますが、XIAOと接続できた勇逸の神アプリです。

Termuxのセットアップ

アプリを入れたら、パッケージをアップデートしておきます。Termuxのコンソールからタイプするのが面倒なら、PCからSSHして作業するといいかもです。

pkg update
pkg upgrade

以下が今回必要なものです。

pkg install nodejs python clang make openssh -y

手持ちの環境、HUAWEI P20 liteでは以下が入りました。

$ dpkg --list | egrep 'node|python|clang|make|openssh' | cut -b 5-50
clang              11.1.0         aarch64     
make               4.3-1          aarch64     
nodejs             14.15.4-1      aarch64     
openssh            8.4p1-1        aarch64     
python             3.9.2          aarch64     
termux-exec        1:0.8          aarch64 

nodejsはもう14なんですね。速すぎる!ぜんぜんついていけないです。

サンプルソースとインストール

まず、termuxでの操作です。コピペしやすいよう$ は省いておきます。

cd
mkdir j5
cd j5
wget https://github.com/take-i/j5-termux/archive/main.zip

まだ説明も何も書いていませんがそのうち、簡単に書いておきます。

サンプルソース

https://github.com/take-i/j5-termux

サンプルソース解凍しインストール

example にLEDが光るサンプルソースが入っています。

unzip main.zip 
cd j5-termux-main/example/
npm install

IPアドレスを修正

WiFiに接続していると思いますので、termux上でIPを確認しておきます。

ifconfig | grep inet

以下のようなIPv4が出ますので、それをメモしておきます。この場合は、192.168.1.36が自分のスマホのIPですね。

inet 192.168.1.36  netmask 255.255.255.0  broadcast 192.168.1.255

サンプルソースのIPを修正します。portは、あとでブリッジアプリで設定しますので、1024番〜の適当なポートにしておきます。1234でもOKです。

------- example/index.js
::
var options = {
  host: '192.168.1.36',  //host name or IP
  port: 1234  // port
}

XIAOにFirmataをセットアップ

この記事を書いている時はまだ、XIAOはFirmataのコードをビルドするとエラーになりますが、以下を適用すればOKです。そのうち、masterにマージされると思うので、ビルドエラーが出なければOKです。

add seeedunio xiao to boards.h please #475

https://github.com/firmata/arduino/issues/475

具体的には、以下からFirmataをダウンロードします。

firmata/arduino Releases
Arduino-1.0.x-Firmata-2.5.8.zip

https://github.com/firmata/arduino/releases/

先ほどのFixをBoards.hに反映し、ArduinoIDEからインポートします。

スケッチ例>Firmata>StandardFirmata のスケッチをXIAOに書込みます。

エラーなく書き込めたらOKです。

スマホでブリッジアプリを設定

次はスマホで BT/USB/TCP Bridge Pro のアプリを設定します。このアプリはDevceAとBをブリッジしますので画面のように設定します。

XIAOをUSB接続するとアクセス許可がでますのでOKします。「このUSBデバイスをデフォルトにする」はチェックしておいたほうがいいですね。

USBデバイスに接続(USB connect)し、TCP Serverをスタートさせます。2つ上の画像、右側のようになっていればOKです。

起動!

Termuxのindex.jsがある場所で以下のコマンドを実行すると動作します。

node index.js

成功すれば、以下のようにターミナルに表示されているはずです。

Connected to USB2TCP Bridge
IO ready!
1614296838868 Available Firmata  
1614296838874 Connected Firmata  
1614296838882 Repl Initialized  
>> Board connected!

XIAOの青色LEDが光っていれば成功です。写真では青色LEDが光っているタイミングを写せなかったので光っていませんが、チカチカしているはずです。

お疲れ様です。

まとめ

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

・Termux上でJ5を使う時は、USBに接続したボードを認識しないので、別アプリでUSBをTCPにブリッジさせて使う
・ブリッジさせるアプリはたくさんあるが、J5からXIAOと通信できたのはこれだけ
・実際に開発するときは、スマホ充電しながらUSB接続しないと電池持ちが。
・J5の使い所がまだよくわかっていないので、例をこなしながらどんなメリットがあるのか体験してみる

あとがき

node.js実行環境をTermuxに作ってそこから有線USB接続したXIAOを操れることがわかりました。まだ、どんなことができるのか、そしてどんなメリットがあるのかまーったく分かっていませんが今後、面白い活用方法などがあれば紹介、DIYしたいなと思います。

著者にメッセージ

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

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

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

もう少しだったのにー!

また落ちたのね?

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

そうなのよー、1月2日にねー。

正月だから寝てたのね!

ぴー
ぴー

site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していますが、果たしてスマホサーバで達成できるのでしょうか?

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

LINK

ちなみに、先月は99.368%で無理でした。かなり惜しかったんですよ!site24x7の監視サービスは強力です。これがなければ、もっとダウンタイムは長かったです。

2021・01のSLA

さて、今月の結果から!
ダウンタイムの合計19 時間 12 分あって、SLAは97.42%となり今月も目標の99.95%には届きませんでした。先月も書きましたが99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。正月早々に、監視のお知らせはきていたのですが、寝ていて気がつかず! この1日がなければ達成していたんですよー。

原因は?

今月も設定ミスではなく、NGINXがBadGatewayを出して本格的に停止していました。

ちょっと回避が難しいので、運用でカバーしようと思っているんですがやっぱり寝てるときとか無理ですね。

まとめ

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

・UmidigiF2に載せ替えようとおもっている。
・4月から仕事先が変わるんで、再起動が難しいかも。何か作戦を練らねば。
・バッテリー無くして電源管理と連動する仕組みとか考えないと。

あとがき

現在リモート勤務なので、まぁ気がつけばすぐに再起動かけられますがこの先仕事のライフワークが変わる可能性が大なので、再起動がむずかしくなりそうです。バッテリーを外して、電源をリモートからコントロールするとかちょっと工夫しないといけないですね。

著者にメッセージ

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

2020/11と12 site24x7 でのSLA状況・統計データ

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

だいぶ遅れましたがSLAデータ報告です!

99.95%は達成できた?

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

・・・

また来月がんばりましょう!

ぴー
ぴー

site24x7のスターターパックを2020の10月から始めています。監視サービスでSLAを99.95%目指していますが、果たしてスマホサーバで達成できるのでしょうか?

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

LINK

先月は、99.567%で無理でした。

2020・11のSLA

まずは結果から。ダウンタイムの合計17 時間 30 分あって、SLAは97.565%となり今月も目標の99.95%には届きませんでした。先月も書きましたが99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。

原因は?

今月のは設定ミスではなく、NGINXがBadGatewayを出して本格的に停止していました。今の所、root化したtermuxでNGINXを動かすとこの現象が発生しています。

ちょっと回避が難しいので、運用でカバーしようと思っていましたが夜間にダウンするともう無理ゲーです。

まとめ

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

・サーバが1つだとやっぱりきびしい。多重化が必要だがそこまでコストをかけたくない。
・root化したNginxだとBadGatewayが出てしまう。なんとか対策しなくとだが根本原因がまだ不明
・運用でカバーしようと思ったが、夜間にダウンするともう無理です。

あとがき

目標がクリアできなかったので、記事を更新するのも面倒になっていますが記録だけでも採っていこうかと。ちなみに、12月も無理でしたので、この記事にはりつえておきます。99.368%という結果。

かなり惜しかったんすが、今回もNGINXがBadGatewayを出してしまいました。17日の少し止まった部分はSSLの更新に伴うWEB再起動ですのでこれはまぁ許容。19日のがなければクリアしていました。NGINXがBadGatewayを出す根本原因を探らないとなのですが、腰が重いです。

著者にメッセージ

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