内部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://hack.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を動作させることだったんですがこれは当分、違う方法でやることにします。

著者にメッセージ

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

スマホを冷蔵庫に入れて冷え冷え状態でベンチマークしたらどうなる?

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

冷蔵庫に入れて冷やしてベンチ測ると、どうなるんだろう?

なんかググると、スマホは冷蔵庫に入れちゃだめ!ってあるよ。

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

冷蔵庫は約10度くらいなんで、寒冷地の温度とそう変わらないよね?

まぁ、気の済むまで実験してくださいw

ぴー
ぴー

以前、Pixel3のベンチマークを計り直したとき、良いスコアが出たので「温度?」が関係しているのかなと思ったんですよね。今回は、冷蔵庫にPixel3をぶっこんでUnixBenchを計測してみたいと思います。

まず結果から

スマホはどの程度低温に弱いのか実験!

https://www.yamareco.com/modules/yamanote/detail.php?nid=1497

先人がやはりいました。この方は冷凍して実験したようです。人柱ですね!なので、冷蔵庫くらいでは問題なさそうなんじゃないかと思います。

スマホはこんな感じで冷蔵庫に入っています。猫カンがあるのは突っ込まないでね! まず、結果からご報告です。

・Pixel3 Android11 冷蔵庫に入れて計測

シングル:583.3
8CPU:1833.7

なんと過去最高です!

今回は、CPU温度の他、バッテリー温度もグラフ化しました。ベンチマーク中はこのように上昇しました。冷やした状態からだと、CPU温度は過去最高87度まで上昇したようですね。

 冷やせば速く動作するってことは実験からわかったので、筐体を分解してファンを取り付けて運用するのはアリかもしれません。

詳細ベンチを・・

詳細についてはこちらに貼り付けておきます。

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: localhost: Android
   OS: Android -- 4.9.223-g5bded8e40b62-ab6647920 -- #0 SMP PREEMPT Thu Jul 2 03:22:48 UTC 2020
   Machine: aarch64 (unknown)
   Language: en_US.utf8 (charmap=, collate=)
   13:07:43 up 4 days,  3:18,  load average: 0.22, 0.20, 0.18; runlevel 

------------------------------------------------------------------------
Benchmark Run: Thu Oct 08 2020 13:07:43 - 13:35:50
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       29344957.6 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     6364.3 MWIPS (10.0 s, 7 samples)
Execl Throughput                                353.6 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        448563.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          177698.8 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1080251.9 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1151314.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  53273.4 lps   (10.0 s, 7 samples)
Process Creation                               1031.2 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1522.3 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    599.3 lpm   (60.1 s, 2 samples)
System Call Overhead                        1186164.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   29344957.6   2514.6
Double-Precision Whetstone                       55.0       6364.3   1157.1
Execl Throughput                                 43.0        353.6     82.2
File Copy 1024 bufsize 2000 maxblocks          3960.0     448563.7   1132.7
File Copy 256 bufsize 500 maxblocks            1655.0     177698.8   1073.7
File Copy 4096 bufsize 8000 maxblocks          5800.0    1080251.9   1862.5
Pipe Throughput                               12440.0    1151314.0    925.5
Pipe-based Context Switching                   4000.0      53273.4    133.2
Process Creation                                126.0       1031.2     81.8
Shell Scripts (1 concurrent)                     42.4       1522.3    359.0
Shell Scripts (8 concurrent)                      6.0        599.3    998.9
System Call Overhead                          15000.0    1186164.4    790.8
                                                                   ========
System Benchmarks Index Score                                         583.3

------------------------------------------------------------------------
Benchmark Run: Thu Oct 08 2020 13:35:50 - 14:04:03
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables      133676583.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    32433.5 MWIPS (10.2 s, 7 samples)
Execl Throughput                               1466.7 lps   (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        672443.5 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          202034.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1920062.6 KBps  (30.0 s, 2 samples)
Pipe Throughput                             4980247.5 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 324913.7 lps   (10.0 s, 7 samples)
Process Creation                              12358.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   5728.2 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    698.4 lpm   (60.4 s, 2 samples)
System Call Overhead                        2734159.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0  133676583.1  11454.7
Double-Precision Whetstone                       55.0      32433.5   5897.0
Execl Throughput                                 43.0       1466.7    341.1
File Copy 1024 bufsize 2000 maxblocks          3960.0     672443.5   1698.1
File Copy 256 bufsize 500 maxblocks            1655.0     202034.3   1220.8
File Copy 4096 bufsize 8000 maxblocks          5800.0    1920062.6   3310.5
Pipe Throughput                               12440.0    4980247.5   4003.4
Pipe-based Context Switching                   4000.0     324913.7    812.3
Process Creation                                126.0      12358.3    980.8
Shell Scripts (1 concurrent)                     42.4       5728.2   1351.0
Shell Scripts (8 concurrent)                      6.0        698.4   1164.1
System Call Overhead                          15000.0    2734159.8   1822.8
                                                                   ========
System Benchmarks Index Score                                        1833.7

ソースコード

計測に使ったソースです。

#!/data/data/com.termux/files/usr/bin/python3
# coding: utf-8

import requests
import time
api_key='Write API Key'

def sender():
    # CPU Temp
    f = open("/sys/class/thermal/thermal_zone0/temp","r")
    t = f.read()
    f.close()
    cpu_temp = float(t) / 1000
    # Battery Temp
    f = open("/sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pmi8998@2:qcom,qpnp-smb2/power_supply/battery/temp","r")
    t2 = f.read()
    f.close()
    battery_temp = float(t2) / 10
    # USB Temp
    f = open("/sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pmi8998@2:qcom,qpnp-smb2/power_supply/usb/temp","r")
    t3 = f.read()
    f.close()
    usb_temp = float(t3) / 10
    # BMS Temp
    f = open("/sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pmi8998@2:qpnp,fg/power_supply/bms/temp","r")
    t4 = f.read()
    f.close()
    bms_temp = float(t4) / 10

    payload = {'api_key': api_key, 'field1': float(cpu_temp), 'field2': float(battery_temp), 'field3': float(usb_temp), 'field4': float(bms_temp)}
    print("CPU Temp is:%s"%cpu_temp, end=' ')
    print("Battery_temp Temp is:%s"%battery_temp, end=' ')
    print("USB_temp Temp is:%s"%usb_temp, end=' ')
    print("BMS_temp Temp is:%s"%bms_temp, end=' ')
    r = requests.get('http://api.thingspeak.com/update', params=payload)
    print("Result: ", r.text)
    time.sleep(1.0)

def main():
    sender()

if __name__ == '__main__':
  main()

まとめ

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

・冷蔵庫に入れれば冷えてベンチマークは良い結果となる。
・UnixBenchは過去最高、マルチで1800を超えた!
・バッテリー温度は、13.5度くらいまで下がった
・ベンチ中はCPU温度は87度まで上昇した!
・今の所、壊れていない。壊れてもいい人以外、真似しないように。
・スマホサーバとするなら、分解してヒートシンク+ファンをつけるのが良さそう。

あとがき

WiFiアクセスポイントを冷蔵庫付近まで持ってきて電波強度を最強にして夏場は過ごすのもありかもしれません。まぁ、もう暑い季節はすぎてしまったのでやるなら来年、2021年度の夏ですかね!

 あと、root化していると、オーバークロックもできるようですがまだ試していません。

著者にメッセージ

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

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