工学社 の本、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でMacのスクリーンショット専用USBキーを作るDIY

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

          スクショの専用キーがほしい!

          Macだと、シフト+コマンド+3とかの?

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

          Mac標準だとそうだけど、Skitchっていうスクショツール使ってるからシフト+コマンド+5だね。

          いろんな需要があると思うからカスタマイズできるといいね

          ぴー
          ぴー

          今回のDIYは、ちょっと実用的なものを作ろうかと思います

          最近、はまっている小さくて安いArduino互換機、XIAOを使ってカスタマイズできるキーボードを作ろうと思います! 冒頭でも少し触れましたが、MacのスクショアプリでSkitchっていうツール使っているんですが、このスクショのショート専用のキーボードを作ろうかと。ショートカットは、シフト+コマンド+5ですが、3つもボタンを押さないといけないので、1ボタンだと助かります。

          その後、Skitchの編集メニューから「画像をコピー」でクリップボードに入れてWordPressのローカルアプリに貼り付けるのが、一連の動きです。このショートカットがシフト+コマンド+C です。

          構想では、この2つのボタンが専用であるといいなと。キャンセルしたいときにESCキーがあると便利かもしれませんね。

          使えるUSBライブラリは?

          TinyUSB Mouse and Keyboard library

          https://github.com/cyborg5/TinyUSB_Mouse_and_Keyboard/

          このライブラリは、Chris Youngさんが統合したTinyUSBです。以下で紹介されています。

          Mouse and Keyboard Control Using TinyUSB and BLE

          examplesを試したのですが、記述がわかりやすいし使いやすそうだったのでこれでやってみることにします。他にも、Seeedの紹介ページにAdafruitのライブラリを使った例がありますが、examplesを見た限りでは使いにくそうでしたのでこちらはパスです。

          Seeeduino XIAOをUSBデバイス(TinyUSB)として使う

          ライブラリを入れる

          マスターのZIPをArduinoIDEから入れて、例題をやってみます。

          ZIP : TinyUSB_Mouse_and_Keyboard

          URL

          Arduino IDEからライブラリをいれるのは、以下からです。

          ZIPのライブラリを入れると、以下のように同じところから見えていると思います。

          提供されたライブラリは、Macだと以下に入るようです。直接ここに入れてもOKです。

          /Users/USERNAME/Documents/Arduino/libraries/

          ちなみに、ArduinoIDE組込(デフォルトの)は以下です。

          /Applications/Arduino.app/Contents/Java/libraries/

          XIAOのボード関連は以下にあります。

          /Users/USERNAME/Library/Arduino15/packages/Seeeduino/

          ライブラリとか、PGのディレクトリ以下に格納しておいたほうが後からわかりやすいかもしれません。数年後、また動かそうとすると環境変わっていたりしますからね。その場合は、includeをダブルクオートで囲って記載すればカレントディレクリ(現在のディレクトリのこと)を参照します。

          #include "TinyUSB_Mouse_and_Keyboard.h"

          サンプルを動かしてみる

          Macユーザーで、Launchpad のショートカットをF5にしていれば動作します。

          $ git clone https://github.com/take-i/XIAO-USB-example.git
          $ cd XIAO-USB-example/xiao_usb1/
          $ open xiao_usb1.ino 

          XIAOに書き込んで、見てください。ブラウザが起動して JunkHackのページが見えていれば成功です。

          サンプル例では、Launchpadが開き、コマンドFで検索、英字モードに切り替えてterminalをタイプしてターミナルを開きます。ターミナルからはURLをオープンしています。macの場合、コマンドの修飾キーは以下のようにKEY_LEFT_GUIが相当します。WindowsだとWINキーです。

            // New terminal windows
            Keyboard.press(KEY_LEFT_GUI);
            Keyboard.write('n');
            Keyboard.releaseAll();

          Keyboard.pressは、押しっぱなし状態になるのでKeyboard.releaseAll()でリリースします。delayを入れないと、速すぎて期待する動作にならないので適当に調整します。

          4ボタンの専用キーボードを作る!

          さて、サンプルはうまく動いたので実際にボタンをつけて日常的に使える状態にします。こんなコードにしました。

          https://github.com/take-i/XIAO-USB-example/tree/master/ss-key

          Pin接続は、A7 , A8 , A9 , A10 とGNDの5つです。なお、このPGは同時にボタンを押した時の考慮はしていませんのでご注意を。クリティカルなボタンの場合は、何かキーが押されている場合は違うキーの処理に入らないようにする必要があります。

          筐体に組み込む!

          3Dプリンターとメカニカルスイッチで作るのが面倒だったので、適当なジャンク品のキーボードを漁ってきました。

          15年くらい前の無線キーボードです。エンターキーが無くなっているのは、子供に剥がされたからです。それ以来、使っていませんでしたがここに来て約に立ちそうです。

          このタイプのキーボードはノートPCと同じで、キーボードの下はフィルムのメンブレンスイッチになっています。これにジャンパー配線するのは厳しいので、端っこのパーツを使うことにしました。

          こっちは基盤があって、なんとかなりそうです。キーボード筐体をグラインダーで切断し、左側部分を使うことにしました。こんな感じ。

          配線はこんな感じ。XIAOは小さいので、ほんと助かります。

          黒い線がGNDで、それ以外はボタンからのプリント基板の配線からジャンパー線を出して使っています。

          こんな感じで、無線キーボードの上に置いてあります。

          右側からESC、スクショ、スクショのコピー、https://www.canva.com/ を開く の4機能を持たせてあります。今もこの記事を書いているときにこのボタンを使っていますが、かなり便利ですね! canvaを割り当てているのは、ブログ記事のサムネイルをいつもここで作るからです。今回はこんな感じかな?

          Macからはこんな感じで認識されています。

          キーボードの修飾キーにも、出ていますね

          MacのKeycodeを確認

          ※追記
          MacだとどんなKeycodeがタイプされるのか確認しておきたかったので、macosで動作するキーロガーのソースを少し修正してDecで数字を出すように改修したものが以下にあります。

          Mac OS X Keylogger

          https://github.com/take-i/keylogger-macos

          オリジナルは、アトランタのアプリ開発者、ケーシー・スカボローさんが作ったものです。簡単に使い方を記載しておきます。

          $ sudo touch /var/log/keystroke.log
          $ sudo chmod 644 /var/log/keystroke.log
          $ git clone https://github.com/take-i/keylogger-macos.git && cd keylogger-macos/
          $ make
          $ sudo ./keylogger

          ログは以下のパスに数字で出力されます。

          $ tail -f /var/log/keystroke.log

          たとえば、Macのキーボード配列の場合、F3キーはMission Controlのキーとなり、Keycodeは、160となります。F3の場合は99です。純正キーボードの場合は、以下のようにキーボード設定に「F1、F2などのキー標準のファンクションキーとして使用」のチェックボックスがでます。社外キーボードの場合、これはでないようです。

          DIYキーボードをUSB接続したとき、macのキーボードだと認識させてMission Controlのコードとして認識させるようにする方法を模索したのですが、ちょっとよくわかりませんでした。また、いつか再チャレンジしたときに覚書として書いておきます。

          まとめ

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

          ・Seeed XIAOは簡単にキーボード・マウスのデバイスが作れる
          ・スイッチOn,OffタイプであればPinの数分、キーは作れる(最大、11Key)
          ・ライブラリは、TinyUSB Mouse and Keyboard libraryが使いやすかった
          ・KeycodeというのがUSBの仕様で決まっているようです(hut1_12v2.pdf
          ・こっちのUSB仕様書のほうが新しいかな?(hut1_21_0.pdf
          ・macの場合は、Mac OS X Keylogger を少し手直しすれば番号がわかる
          ・しかし、USBの仕様書とは違う値が帰る(例:F3は、macだと10進で160または99、USB仕様書では、60)
          ・PGの定義は、0xC4で10進だと196
          ここによれば、0x88以上は、その値から0x88を引いた数(10進だと136)となるようです。つまり、196-136=60 なるほど!PGの定義からは謎がとけました
          ・しかし、macのkeycodeは違う値を出す。ここがよくわからない
          ・おそらく、macはkeycodeのマッピングテーブルを持っているのだろう
          ・または、キーボード種類によってF3はMission ControlになるようOSがマッピングしているのだろう
          ・keycodeとUSBデバイスのレイアウトの関係はまだ奥が深そうだ
          ・フィルムのメンブレンスイッチって自作できないかな?
          ・アルミテープとラミネートフィルムで作れないかな?

          あとがき

          作ってみて、実際に使ってみたらすごく具合がいいです。USBデバイスをこんなに簡単に作れるとは、驚きですね。いつか、本格的なキーボード作りもしてみたいです。40%キーボードとか小さくて可愛いので使ってみたいんですが、何から手をつけていいのかよくわかりません。あと、薄いMacのキーボードに手が馴染んでしまったのでという理由もあります。

          まぁ次キーボード作る機会もあると思うので、その時は自作したいですね。

          著者にメッセージ

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

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

            あとがき

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

            著者にメッセージ

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