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を出す根本原因を探らないとなのですが、腰が重いです。

著者にメッセージ

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

    内部DNSをTermuxのDNSMASQで動かす!

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

    内部ネットワークから参照するDNSを作ったよ!

    それって、どんなDNSなの?

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

    例えば、example.jpだと192.168.1.1にアクセスできるようにするとかできるよ

    UターンNAT対策?

    ぴー
    ぴー

    そうなんですよねー。UターンNAT対策で内部DNSが欲しかったんです。

    内部DNSを低消費電力サーバのスマホtermuxで動かしたいなと思って、いろいろ格闘していました。先日はOpenWrtというルータ上で動かしていましたが、今回は、root化したスマホ上のtermuxで動かしてみました。53ポートで動かすのでroot化が必要ですが、termuxのrootパッケージの1つ、dnsmasqを使って内部DNSを作ろうと思います。

    dnsmasqとは?

    公式:Dnsmasq

    http://www.thekelleys.org.uk/dnsmasq/doc.html

    比較的、軽量でDHCP、BOOTPやPXEにも対応しているDNSサーバでOpenWrtにも使われていたります。自ドメイン以外は指定のDNSに転送して応答してくれます。内部ネットワーク向けの簡易なDNSとしては十分な機能をもっていますね。

    今回は、IPv4で自ドメインの応答とそれ以外は8.8.8.8のDNSにフォワードして応答してもらうだけのシンプル設定です。DHCPなどそれ以外の機能はつかいません。

    Termuxのdnsmasqは?

    ポート53で動かすので、root化したスマホにtermuxを動かしている必要があります。1024番ポート以下はrootじゃないとバインドできません。パッチ内容は以下から参照できます。

    termux-root-packages:dnsmasq

    URL

    やってみましょうか!

    ステップ1 インストール

    インストール自体は簡単です。root-repoパッケージを入れてから、dnsmasqを入れるだけです。

    $ pkg install root-repo -y
    $ pkg install dnsmasq -y

    本体とmanなどが入ります。サイズは264Kと小さいですね。

    $ ll /data/data/com.termux/files/usr/bin/dnsmasq
    -rwx------ 1 u0_a143 u0_a143 264K Aug 17 02:40 /data/data/com.termux/files/usr/bin/dnsmasq*

    ステップ2 設定

    Termuxのdnsmasqだと、設定ファイルはデフォルトで無いので作ります。

    $ cd $PREFIX/etc
    $ vi dnsmasq.conf 

    内容は以下です。ほどよく読み替えてください。

    ホスト設定:$PREFIX/etc/hosts-dnsmasq
    ログ:$PREFIX/var/log/dnsmasq.log
    このホストIP:192.168.1.38
    Termuxユーザ:u0_a143
    ドメイン:gpl.jp
    フォワードするDNS:8.8.8.8

    listen-address=127.0.0.1,192.168.1.38
    port=53
    bind-interfaces
    user=u0_a143
    group=u0_a143
    no-poll
    # プライベートIPアドレスの逆引きを上位DNSサーバに転送しない
    bogus-priv
    # ドメインの無いホスト名のみ問い合わせの場合、上位DNSサーバに転送しない
    domain-needed
    # ローカルエリア内のドメインを指定
    local=/gpl.jp/
    # ホスト名で問合せされた時、下記のdomain=で指定されたドメイン名を補完
    expand-hosts
    # 補完するドメイン名
    domain=gpl.jp
    
    # LocalDNS
    addn-hosts=/data/data/com.termux/files/usr/etc/hosts-dnsmasq
    server=/gpl.jp/192.168.1.38
    server=/1.168.192.in-addr.arpa/192.168.1.38
    log-queries
    log-facility=/data/data/com.termux/files/usr/var/log/dnsmasq.log
    
    server=/localnet/192.168.1.38 # change ip for your ip-server
    server=8.8.8.8
    no-resolv 

    ホスト設定:$PREFIX/etc/hosts-dnsmasq は以下となります。

    192.168.1.38    f2
    192.168.1.47    p3
    192.168.1.47    hack
    192.168.1.47    junkhack

    resolvファイルは自サーバを参照するよう以下にしておきます。

    $ cat resolv.conf 
    #nameserver 8.8.8.8
    nameserver 192.168.1.38

    ステップ3 起動

    53ポートでバインドさせるので、rootで起動します。

    $sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

    ステップ4 確認

    確認です。明示的に dig @hostip domain と@でdnsを指定するとより良いです。

    $ dig f2 +short
    192.168.1.38
    
    $ dig -x 192.168.1.38 +short
    f2.gpl.jp.
    
    $ dig hack.gpl.jp +short
    192.168.1.47
    
    $ dig yahoo.co.jp +short
    182.22.59.229
    183.79.135.206

    ホスト名のみでも大丈夫ですね。FQDN自ドメインも引けますし、逆引きもできます。管理外はフォワードして応答してきました。

    例えばまったく違うドメインを指定

    $ cat hosts-dnsmasq
    192.168.1.38    f2
    192.168.1.47    p3
    192.168.1.47    hack
    192.168.1.47    junkhack
    192.168.1.111   test.example.jp

    このように、違うドメイン名をFQDNで記載したら参照できるのでしょうか?

    設定変更・再起動

    $ sudo killall dnsmasq
    $ sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

    参照できるか引いてみます。

    $ dig test.example.jp +short
    192.168.1.111
    
    $ dig -x 192.168.1.111 +short
    test.example.jp.

    参照できますね。これって設定ファイルのserver行でドメイン指定しなくてもいいんですかね? 設定項目はもっとシンプルにできるのかもしれませんが、追求するのはヤメにしておきます。

    まとめ

    同じ設定を、UmidigiF2では動きましたが、Pixel3ではフォワーダーが動かなかったです。

    ・UmidigiF2では動作し、Pixel3ではフォワーダーが動かない原因は不明
    ・機会があれば、BOOTPやPXEも試してみたい
    ・FQDNで記載すれば違うドメイン名でもOK
    ・MXやテキストレコードなどはどうやって指定するのだろう?

    あとがき

    今の所不具合はなさそうです。もう1週間ほど動かして問題なさそうであれば今のWordPressサーバを統合しようかなと思います。メインPCからもこのDNSを参照していますが速度的にも特に問題はない感じです。

    著者にメッセージ

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

      2020/10 site24x7 でのSLA状況など統計データ

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

      引っ越ししてからのSLAデータ報告です!

      site24x7のレポート?

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

      そうそう。有料会員になったんでとりあえず使っています!

      99.95% って難しそうだね!

      ぴー
      ぴー

      site24x7のスターターパックというのを10月から始めてみました。いわゆる監視サービスなんですが10ドルで契約できるので、ちょっと使い始めています。

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

      LINK

      とりあえず、SLAレポートが出せるのでこれを月末に出していこうかなと思います。

      2020・10のSLA

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

      原因は?

      5日の停止はDNSの設定ミスです。27日と28日は内部ネットワークを少し変更してその影響で少し止まってしまいました。30日は、NGINXがBadGatewayを出して本格的に停止していました。今の所、root化したtermuxでNGINXを動かすとこの現象が発生しています。これはなんとかしないとだめですね。設定関連での停止は、今後以下のように対策しようと思います。

      ・設定変更後、5分は監視レポートが飛んでくるか確認する。

      なかなか設定ミスの間違いには気がつきにくいです。とりあえず何か変更したら、5分は監視サービスの動きを見ることで対応しようと思います。

      まとめ

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

      ・引っ越し当初なんで設定することがたくさんあった
      ・設定変更後は、監視サービスの動きを5分は見て見ることにする
      ・サーバ1つだとやっぱりきびしい。多重化が必要。
      ・root化したNginxだとBadGatewayが出てしまう。なんとか対策しなくとだが根本原因がまだ不明

      あとがき

      UmidigiF2をroot化したので、とりあえずこっちに戻して様子を見ようと思いますが、めんどくさいのでちょっと作業は中断。スマホサーバを安定して動かすのは難しいです。

      著者にメッセージ

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

        Umidigi F2 をroot化したよ!

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

        Termuxを1024ポート以下でデーモン起動できるから、やっぱりroot化はやっておきたいよね。

        今までサーバ利用していたUmidigiF2をroot化するのね!

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

        そうそう! UmidigiF2の公式ファームウェアを使ってroot化です。

        ちょっと検索してみたけど、まとまってる日本語記事ってないですね!

        ぴー
        ぴー

        さてさて、今日から4連休です! 初日の本日は今までこのブログのWordPressサーバとして約1ヶ月利用していたUmidigiF2をroot化してみましたので、忘れないうちにその方法を書いておきます。日本語でまとまっている情報はなかったので、どこかで役に立つかもしれませんね。

        root化とは?そのメリットは?

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

        https://junkhack.gpl.jp/2020/10/05/pixel3android11rroot/

        以前、Pixel3のroot化したときも書きましたが、簡単にいえばAndroidの最高管理権限をゲットして普通では出来ないことをやれるようします。なお、同じことをされる場合は、bootを純正以外にしますので自己責任でお願いしますね。

         で、root化する今回の目的も前回と同じで termuxを動かした時rootパッケージを使えるし、1024ポート番号以下のデーモンを起動できます。例えば、WEBサーバの80番ポートや、SSLの443番ポートです。

         というわけで、UmidigiF2のroot化やってみましょうか。

        ステップ1 概要

        こういうのは、まず全体像が見えていることが大事です。UmidigiF2をroot化するにあたり、概要は以下となります。

        ・UmidigiF2のBootローダーのロック解除をする
        ・Magiskというツールを使い、twrpは使わない
        ・Magisk Managerを使い、純正ファクトリーイメージに含まれるBootにパッチする
        ・adb純正ツールで、パッチしたBootをUmidigiF2に書き込む
        ・Termuxはroot権限を利用できるようMagiskに設定しておく

        今回も、Pixel3の時と同じように、Magiskというツールで行いました。TWRPのオフィシャルに行ってきたんですが、てっきりUmidigiF2はTWRP公式ビルドにあると思っていたんですよね。残念ながら、公式ビルドにはないようでした。

        TeamWin – TWRP Devices

        https://twrp.me/Devices/

        一方、MagiskはAndroidパーティションスキームに準拠していれば使えるはずです。オフィシャルサイトであるソース配布元のGitは以下になります。

        Magisk

        https://github.com/topjohnwu/Magisk

        さぁ、やってみましょうか!

        ステップ2 必要なツールと準備

        まずは前準備です。今回もosxでやっていますがLinuxでもWindowsでもChromeBookでもできると思います。オフィシャルのマニュアルも参照してね。

        Magiskオフィシャルインストール手順

        https://github.com/topjohnwu/Magisk/blob/master/docs/install.md

        上記だけでは、全体がまだ見えてきませんね。つまり、ざっくりと以下が必要です。

        (1)fastbootとadbコマンドが動作する環境
         これは、SDK Platform-Toolsを入れればOKです。Googleからリリースされていますので最新を入れておきます。AndroidStudioを入れてある環境ならばすでに入っていますが、ツールだけであれば以下からダウンロードできます。現在の最新は、Version 30.0.4です。

        SDK Platform-Tools 

        https://developer.android.com/studio/releases/platform-tools.html

        (2)UmidigiF2のファクトリーイメージ(StockROM)
         今手元のUmidigiF2で動いているバージョンを確認してください。筆者の場合は最新のUMIDIGI_F2_V1.0_20200402_20200506-1120が入っていたので以下をダウンロードしておきました。これはワイヤレスアップデート画面から現在のバージョンを確認できます。あとから、Boot.imgを取り出してMagiskでパッチします。

        StockROM UMIDIGI F2
         UMIDIGI_F2_V1.0_20200506.V3.17.rar

        https://community.umidigi.com/forum.php?mod=forumdisplay&fid=228

        (3)MagiskManagerのアプリ
         これは以下のオフィシャルサイト(GitHub)からダウンロードできます。筆者はCanaryビルドを使いました。安定番は、MagiskManagerv8.0.2です。

        純正に戻す場合はこれ以外にも必要ですが、今のバージョンをroot化するだけなら以上でOKです。

        ステップ3 ファクトリーイメージを展開

        オフィシャルサイトからダウンロードした、UMIDIGI_F2_V1.0_20200506.V3.17.rar を展開しておきます。rarファイルを展開するといろいろありますが、今回使うのは boot.img と、vbmeta.img です。わかりやすいよう1つ上の階層にでもコピーしておきましょう。

        .
        └── UMIDIGI_F2_V1.0_20200506.V3.17
        ::
            ├── boot.img
        ::
            ├── vbmeta.img
        ::

        ステップ4 Bootローダーのロック解除

        通常であれば、開発者向けオプションの「OEMロック解除」項目はこのようにグレーアウトした状態となっていますが、これをONにしておきます。

        まず、ここにたどり着くには開発者向けオプションを有効にして、次にOEMロック解除をONにします。

        [設定]> [端末情報]> [ビルド番号]を複数回タップして[開発者向けオプション]を有効にしておきます。

        [設定]> [システム]> [詳細設定]で[開発者向けオプション]を開き「OEMロック解除」を有効にし、確認のためにパスワードを入力します。「USBデバッグ」も有効にしておきます。

        次に、USBケーブルでPCと接続し、「adb reboot bootloader」とターミナルからタイプします。

        $ adb reboot bootloader

        すると、スマホはfastbootモードで再起動します。

        再起動したら黒い画面でスマホは止まりますので、以下から認識しているか確認しておきます。

        $ fastboot devices
        F2xxxxxxxxxxxx3	fastboot

        ここから先は、スマホが初期化されますので注意を!

        スマホは黒い画面で左下に少し文字が見える状態だと思います。以下をタイプしてボリュームの+ボタンを押しブートローダーのロックを解除します。

        $ fastboot flashing unlock

        次に以下をタイプしてボリュームの+ボタンを押しセキュアパーティションのロックを解除します。

        $ fastboot flashing unlock_critical

        続けて以下で再起動させます。

        $ fastboot reboot

        起動は5秒くらい遅れますが、ホーム画面がでればOKです。これで先ほどの「OEMロック解除」は以下のようになっているはずです。

        fastbootモード中、スマホの画面に表示される文字が小さくてみずらいですが、上記のように操作すれば問題ないはずです。

        ステップ5 Boot.imgのパッチ

        boot.imgをスマホに転送し、Magisk Managerを使用してパッチを適用します。

        まずは、MagiskManagerのアプリを入れておきます。
         https://github.com/topjohnwu/Magisk

        アプリを入れたら、起動させ「Magiskのインストール」からboot.imgを選択してパッチを当てます。以下のようになれば成功です。

        パッチしたboot.imgファイル(magisk_patched.img)はPCにダウンロードしておきます。

        ステップ6 パッチしたBoot.imgを書込

        引き続き、USB接続したPCから操作です。以下をタイプでリブートします。

        $ adb reboot bootloader

        再起動したら黒い画面でスマホは止まりますので、以下から認識しているか確認しておきます。

        $ fastboot devices
        F2xxxxxxxxxxxx3	fastboot

        カレントディレクトリに、magisk_patched.img があるとしたら以下のコマンドで書込みます。verityしないオプションはつけなくても大丈夫とは思いますが、まだ試していません。

        $ fastboot --disable-verity --disable-verification flash boot ./magisk_patched.img

        以下、実行例です。

            $ fastboot --disable-verity --disable-verification flash boot ./magisk_patched.img 
            Sending 'boot' (32768 KB)                          OKAY [  0.721s]
            Writing 'boot'                                     OKAY [  0.731s]
            Finished. Total time: 1.455s

        オフィシャルのストックロムから取り出した、vbmeta.imgを書込みます。

        $ fastboot --disable-verity --disable-verification flash vbmeta ./vbmeta.img

        実行例は以下です。

            $ fastboot --disable-verity --disable-verification flash vbmeta ./vbmeta.img 
            Rewriting vbmeta struct at offset: 0
            Sending 'vbmeta' (4 KB)                            OKAY [  0.013s]
            Writing 'vbmeta'                                   OKAY [  0.001s]
            Finished. Total time: 0.016s

        最後にリブートです。

        $ fastboot reboot

        root化の確認

        リブート後、MagiskManagerを起動するとこのようになっていると思います。

        例えば、Termuxからrootパッケージを入れて、rootになれるか確認です。

        $ tsu
        # whoami
        root
        # id
        uid=0(root) gid=0(root) groups=0(root)
        # 

        tsuコマンドはtermuxのsuコマンドです。これを行うとmagiskにroot権限を許可するか聞かれますのでOKとしておきます。

        まとめ

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

        ・スマホに入っているバージョンと同じROMをパッチすることでSP Flash Toolを使わなくてもOKだ。
        ・SP Flash Toolは、WindowsとLinuxしかない。
        ・元の状態に戻したい場合は、SP Flash Toolが必要。
        ・今のところ問題なさそう。もう少し遊びながら様子見。

        あとがき

        これでPixel3で試せなかったことが実験できます。本来、Pixel3は、手元であれこれアプリのテストに使いたいので、UmidigiF2がこのブログのメインマシンになる予定です。そのうち、また入れ替えたいと思います。

        著者にメッセージ

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

          メルカリ880円のルータに組み込みLINUXのOpenWrtで内部DNSを動かす!

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

          やっとPixel3に引っ越しできたよ!

          おめでとー! 何をそんなに苦労してたの?

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

          いやー、ローカルにDNSを立ち上げようとあれこれとね!

          結局、どうやってローカルDNS立ち上げたの?

          ぴー
          ぴー

          ということで、今見ているこのWordPressブログはUMIDIGI F2から Google Pixel3のスマホに引っ越ししました!

           一番嬉しいのは、ローカルからブログを書く時、もうVPNを繋げて書かなくてもよくなった点ですね! 今まではUターンNATの問題で内部ネットワークからはこのブログにアクセスできなかったのです。ブログ記事を書く時もVPN経由で外からアクセスしていたので、記事を書くのが少し面倒だったんです。今回は、Pixel3に引っ越ししてローカルDNSを立ち上げた事を記事にしようかなと思います。

          ローカルDNSを立ち上げろ!

          なぜローカルDNSを立ち上げる必要があったかは、このあたりを見ていただくとその経緯がわかるかなと思います。

          ポートフォワードの経路で、Uターン NATとかヘアピンNATが使えないルータの場合のあれこれ

          Link

          ローカルにDNSを立ち上げれば、UターンNATがダメなルータを使っていても迂回した経路が作れます。そして、Termuxの1024以下ポートが使えない問題は、root化した Pixel3を使って回避しました。つまり、今動いているNGINXは、port80とport443で動作しています。こんな感じ!

          # ps axu | grep nginx
          root     12762  0.0  0.0 10868580 2144 ?       Ss   02:14   0:00 nginx: master process nginx
          u0_a218  12763  0.0  0.1 10869584 3912 ?       S    02:14   0:00 nginx: worker process
          ::
          u0_a218  12771  0.0  0.0 10868708 2312 ?       S    02:14   0:00 nginx: cache manager process
          
          # netstat -an | egrep ':80 |:443 ' | grep LISTEN
          tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
          tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN  

          当初は、このroot化したPixel3にDNSを起動させる予定だったんですが、思いの外うまく動かなくて結局、安いルータをメルカリでゲットしました。なんとお値段、送料込み880円!

          I-O DATA WN-AC1167GR

          11ac対応867Mbps(規格値)Wi-Fiルーター
          WN-AC1167GR

          https://www.iodata.jp/product/network/wnlan/wn-ac1167gr/index.htm

          このルータに、OpenWrtというオープンソースな組み込み用Linuxがあって、このI-Oデータのルータにも適合したファームウェアがあります。これを使って、dnsmasqというDNSが使えるので、ローカルDNSとして活用してみました。

          I-O DATA WN-AC1167GRにOpenWrtを!

          まずは、OpenWrtを入れます。このファームウェアは以下にあります。

          OpenWrt Project Techdata: I-O Data WN-AC1167GR

          https://openwrt.org/toh/hwdata/i-o_data/i-o_data_wn-ac1167gr

          Firmware OpenWrt Install URL から、ファクトリーイメージがあるので、これを純正のファームウェアアップデートから書き込みするだけです。LANポートは、デフォルトで192.168.1.1/24 のネットワークになっていてDHCPサーバも動いています。

          このCPUは、MediaTek MT7620Aが載っているようですね。32bitのarmで1coreのようです。

          MediaTek MT7620N/A

          https://www.mediatek.jp/products/mt7620n-a

          詳細な設定は、省きますがLAN側のネットワークに上位ルーター側で使っているネットワークを割り振っているだけです。DHCPはこのルータでは止めてあります。WAN側の青いLANは使っていません。FireWallも全部外してあります。うまく設定すれば、WAN側とLAN側をブリッジさせて同一ネットワークで使うこともできると思いますが、なぜかうまくいかず結局、シンプルな設定にしました。

           あと、とりあえず、いろいろ試して5Ghz帯の無線LANは安定しなかったので、2GHZの無線LANにしています。何か設定の勘所があるのかもですが、ちょっと追うのはヤメておきます。

          このようにインターフェイスはLAN側のポートだけ使って、あとは無線LANの設定をLANに紐づけているだけです。いわゆるブリッジ接続(アクセスポイント的な)で使っている感じですね。

          OpenWrtで、DNSMASQの設定を!

          OpenWrtルータは、SSHも出来ますのでログインしてdnsmasqがどの設定ファイルを見ているか確認してみます。管理画面からも設定はできるんですが、どの設定項目がどのパラメータなのかわかりにくいので、直接設定ファイルを見てみました。

          psコマンドは、BusyBoxのやつを使っているようですね。オプションは効きませんでした。こんな感じでdnsmasqの起動オプションを確認。

          root@OpenWrt:~# ps | grep dnsmasq
            847 dnsmasq   1344 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid

          -C オプションが設定ファイルです。このファイルの中は、こんな感じです。

          # auto-generated config file from /etc/config/dhcp
          conf-file=/etc/dnsmasq.conf
          filterwin2k
          no-negcache
          strict-order
          localise-queries
          read-ethers
          enable-ubus
          expand-hosts
          bind-dynamic
          quiet-dhcp
          domain=gpl.jp
          server=/gpl.jp/
          server=8.8.8.8
          server=192.168.1.1
          dhcp-leasefile=/tmp/dhcp.leases
          resolv-file=/etc/resolv.conf
          stop-dns-rebind
          rebind-localhost-ok
          dhcp-broadcast=tag:needs-broadcast
          addn-hosts=/tmp/hosts
          conf-dir=/tmp/dnsmasq.d
          user=dnsmasq
          group=dnsmasq
          
          
          dhcp-ignore-names=tag:dhcp_bogus_hostname
          conf-file=/usr/share/dnsmasq/dhcpbogushostname.conf
          
          
          bogus-priv
          conf-file=/usr/share/dnsmasq/rfc6761.conf

          あとは、hostsの内容はWEB GUI画面から管理できます。

          リモートのmacから、digで確認してみます。

          $ dig @192.168.1.100 hack.gpl.jp
          
          ; <<>> DiG 9.10.6 <<>> @192.168.1.100 hack.gpl.jp
          ; (1 server found)
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2575
          ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
          
          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags:; udp: 4096
          ;; QUESTION SECTION:
          ;hack.gpl.jp.			IN	A
          
          ;; ANSWER SECTION:
          hack.gpl.jp.		0	IN	A	192.168.1.47
          
          ;; Query time: 0 msec
          ;; SERVER: 192.168.1.100#53(192.168.1.100)
          ;; WHEN: Mon Oct 26 03:55:29 JST 2020
          ;; MSG SIZE  rcvd: 56

          管理外のドメインも引いてくれるか確認しておきます。なんとか大丈夫そうなので、設定はよしとします。ハマった点としては5Ghz帯の無線LANだとどうしても、接続が切れてしまうようでした。何か、設定があるのかもですが解決できなかったので2Ghz帯のにしています。無線LANとスマホは近くに置いてあるのでまぁ実質問題ないでしょう。Pixel3からスピードテストすると以下のようです。

          監視サイトからの読み込みも 2秒くらいなのでまぁ良いかなと。

          まとめ

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

          ・OpenWrtは、iptablesも設定できるようなのでうまく応用すればいろいろ使えそう
          ・今回は、5Ghzの無線LANは通信が切れてしまう現象が起きた
          ・なので、2Ghzの無線LANで運用することに
          ・DNSMASQは、それなりに動いているようだ
          ・無線LANの機器なので消費電力は5Wくらい。省電力
          ・違う無線LAN配下からは、pingが通らない。これはなぜか?
          ・上位ルータからはPingは通る
          ・引っ越ししたroot化したpixel3は今の所、調子良さそう

          あとがき

          無線LANがぶつぶつ切れて、設定がぜんぜん進まず、どうしようかと思ったんですが2Ghzにしてなんとか安定しているように見えます。組み込みのLinuxと無線LANドライバーは、弄れる知識がないのでいつかチャレンジしてみようとは思いますが、今はもうお腹いっぱいです。設定疲れました!でも、なんとか当初の目標がクリアできてよかったです。たかが、内部DNSですが、消費電力が少なくて今のところ便利に使えています。あとは、そのくらい安定して動作するか検証ですね。

          著者にメッセージ

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

            D.J.BツールのdaemontoolsをTermuxで動かしてみたよ!

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

            ぴーちゃん、DJBのdaemontoolsって知ってる?

            ・・・まったく知りません!

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

            デーモンを起動管理させるツールなんだけど、これがTermuxで動かせないかな?ってチャレンジしてみたよ。

            またマニアックなネタですね!w

            ぴー
            ぴー

            はいな! またマニアックネタかもしれませんので需要はあまり無いかもしれませんね。w

            daemontoolsとは?

             このツールは、DJBことダニエル・ジュリアス・バーンスタインさん(WIKI参照)が作ったツール群です。DJBさんは、qmailやdjbdnsというメールやDNSも作っています。daemontoolsは、全部で17個の単体プログラムで作られている常駐するプログラムを起動管理するものです。

             DJBツールは、設定や取り扱いがよくわからんという人もいて好き嫌いの別れるツールです。しかし、驚異的にバグが少なく非常に興味深い作りになっています。

            その昔、sendmailやbindに嫌気がさしてqmailやdjbdnsを使っていた時期があったのですが、rpmやdebパッケージなどがないので設定はそれなりにしないと動きません。作者がバイナリ配布を認めていないんです。その為、RedHatはqmailのサポートを明示的に切り捨てています。ちなみに、無償で登録できるRedHatの開発者アカウントがあれば、ナレッジも読めますよ。

            Red Hat は、Red Hat Enterprise Linux で qmail SMTP サーバーの使用をサポートしていますか?

            https://access.redhat.com/ja/articles/2540051

            そんな感じでDJB作のソフトウェアを10年ぶりくらいに使ってみました。あまりに久しぶりすぎて、だいぶ使い方とか忘れていましたがなんとか動いているように見えますのでちょっとメモしておきます。

            daemontoolsの概略

            daemontools とは、デーモンを監視するツールのことで、qmail の作者 D.J.B. によるツールの事。メリットは、daemontools によって監視させておけば、 自動的に再起動してくれます。注意事項は以下。

            • バックグラウンドになるデーモンは管理できない。
            • この為、run から動作させるプロセスは、 & を付けてバックグラウンドにしないこと。

            詳細は、オフィシャルサイトを参照。https://cr.yp.to/daemontools.html

            今回は、Androidで動作するTermuxでdaemontoolsを動作させるように修正をしました。

            インストール

            daemontoolsは、展開したソースディレクトリにコマンドがシンボリック・リンクされます。

            このインストール例では、ホームディレクトリに bin を作成し、そこに展開してインストールします。

            $ mkdir bin
            $ cd bin
            
            $ git clone https://github.com/take-i/termux-daemontools.git
            $ cd termux-daemontools/admin/daemontools-0.76/
            $ package/install

            インストールは以上で終了です! ビルドツールが入れてなくてmakeできない場合は、このように入れておいてください。

            $ pkg install autoconf automake bison bzip2 \
                          clang cmake coreutils diffutils \
                          flex gawk git grep gzip libtool \
                          make patch perl sed silversearcher-ag \
                          tar termux-exec wget -y

            コマンドはどこにあるの?

            コマンドは、termux配下の $PREFIX/bin ディレクトリ以下にありますが、これはシンボリック・リンクです。

            $ which svscan
            /data/data/com.termux/files/usr/bin/svscan

            また、このシンボリック・リンク先は、$PREFIX/command/ になります。

            $ ls -l /data/data/com.termux/files/usr/bin/svscan
            lrwxrwxrwx 1 u0_a257 u0_a257 46 Oct 21 15:10 /data/data/com.termux/files/usr/bin/svscan -> /data/data/com.termux/files/usr/command/svscan

            つまり、コマンドの本体はビルドしたディレクトリ以下にあります。ビルドしたディレクトリを削除するときは注意しましょう。

            $ tree $PREFIX/command/
            ├── envdir -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/envdir
            ├── envuidgid -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/envuidgid
            ├── fghack -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/fghack
            ├── multilog -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/multilog
            ├── pgrphack -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/pgrphack
            ├── readproctitle -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/readproctitle
            ├── setlock -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/setlock
            ├── setuidgid -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/setuidgid
            ├── softlimit -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/softlimit
            ├── supervise -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/supervise
            ├── svc -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/svc
            ├── svok -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/svok
            ├── svscan -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/svscan
            ├── svscanboot -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/svscanboot
            ├── svstat -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/svstat
            ├── tai64n -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/tai64n
            └── tai64nlocal -> /data/data/com.termux/files/home/bin/termux-daemontools/admin/daemontools/command/tai64nlocal

            daemontoolsの起動

            必須ではありませんが、明示的にPATHを記載したい場合は以下のように追記しておきます。

            ~/.bashrc

            ::
            #djb tool daemontools
            export PATH=$PATH:$PREFIX/command

            リモートシェルから、Daemontools の起動は、スマートフォンのroot化を行なっている場合は root で起動できます。その場合は、

            $ nohup sudo svscan $PREFIX/service/ &

            一般ユーザーで起動する場合は、

            $ nohup svscan $PREFIX/service/ &

            どちらかの方法で起動してください。なお、Termux:Boot の有償アプリを入れている場合は、~/.termux/boot/ 以下に以下のような起動スクリプトを記載しておくとスマホを再起動してホーム画面まで行った時に自動的に起動します。

            #!/data/data/com.termux/files/usr/bin/sh
            
            export PATH=$PATH:$HOME/bin
            export PATH=$PATH:$PREFIX/command
            export PREFIX=/data/data/com.termux/files/usr
            
            sudo svscan $PREFIX/service/ &

            設定のサンプル

            例えば、crondをdaemontoolsで起動させるサンプルです。ホームディレクトリにbootディレクトリを作成して後から $PREFIX/service/ にシンボリック・リンクを張って起動させます。以下の例では、実態のディレクトリは$HOME/boot/ですが、どこでもOKです。$PREFIX/var/boot/ とか好きなところにディレクトリを作成してください。

            $ cd
            $ mkdir -p boot/crond
            $ cd boot/crond
            
            $ vi run
            #!/bin/sh
            
            export PATH=$PATH:$HOME/bin
            export PATH=$PATH:$PREFIX/command
            export PREFIX=/data/data/com.termux/files/usr
            
            exec 2>&1
            exec > /dev/null
            
            # start up script example.
            # need pkg install cronie
            exec crond -n

            デーモン起動しないように、crond を -n オプションでフォアグランドで起動しています。

            $ cd ../
            $ chmod +t crond

            このようにスティッキービットをディレクトリに付けておきます。

            起動

            シンボリック・リンクを張ると起動します。

            $ ln -s $HOME/boot/crond $PREFIX/service/

            起動確認

            ルートで、svscan を動作させている場合は以下のようにすれば svstatコマンドで確認できます。

            $ tsu
            # svstat $PREFIX/service/crond
            /data/data/com.termux/files/usr/service/crond: up (pid 8704) 191 seconds

            rootで動作させている場合は、プロセスツリーが以下のようになっています。

            init─┬
               ::
                 ├─magiskd─┬─logcat
                 │         ├─sh───svscan─┬─supervise───run───sleep
                 │         │             └─supervise───crond

            つまり、Termuxを完全に落としてもcronは動き続けてくれます!

            サービスの一時的な停止

            $ svc -d $PREFIX/service/crond

            サービスの再開

            $ svc -u $PREFIX/service/crond

            永続的なサービスの削除

            監視ディレクトリからシンボリック・リンクを削除します。

            $ cd $PREFIX/service/
            $ unlink crond

            注意事項

            setuidgidなど、一般ユーザ(termuxをインストールしたユーザ)では動作しないと思います。また、すべてのコマンドをテストしていませんので、動作無保証です。テスト済みのコマンドは以下から確認できます。

            Github:termux-daemontools

            https://github.com/take-i/termux-daemontools/blob/master/readme-jp.md

            まとめ

            今回の要点は以下となります。

            ・daemontoolsは、Termuxでもなんとか動作させることができた
            ・root化されていないTermuxでも動作する
            ・root化されているスマホだと、Termuxをタスクから完全に落としても動作するデーモンを管理できる
            ・メリットとしては、root化されていない端末の場合、サービス起動管理が一元化できそう。
            ・setlockは、いろいろ使えそうなのでちゃんと動くか確認してみたい。

            あとがき

            一応、djbdnsもtermuxで動作させようとあれこれ弄っていたのですが、どうやらうまく動作させることができませんでした。Androidの起動管理がよくわかっていなくて、djbdnsを起動させるとメモリーがどんどん膨らみ、swapも使い果たして再起動してしまいます。これは、djbdnsの問題ではなく、おそらくandroidの起動するシステムが関連している感じですがよくわかっていません。

             当初の目的では、DNSを動作させることだったんですがこれは当分、違う方法でやることにします。

            著者にメッセージ

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