工学社 の本、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)と、www.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/www.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/www.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;
    }

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

    server {
        listen      80;
        server_name jh.gpl.jp www.gpl.jp www.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 www.gpl.jp www.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://www.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月から仕事先が変わるんで、再起動が難しいかも。何か作戦を練らねば。
            ・バッテリー無くして電源管理と連動する仕組みとか考えないと。

            あとがき

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

            著者にメッセージ

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