Prometheus2とGrafana6によるシステム監視 FreeBSDのメモリとCPU温度

前々回、PrometheusとGrafanaとNode Exporterのインストールを行った。前回は、既存のGrafanaのNode Exporter用テンプレートを貰ってきて使ったが、Linuxホストの監視用特化なのでFreeBSDのホストではメモリや温度の情報が表示されなかった。
そこで、今回はテンプレートはそのままで、Prometheus側の設定でFreeBSDの情報をLinuxの情報互換にして表示する。
初歩の初歩なので、すでにPrometheus, Grafanaを使いこなしている人にとっては見るところが無いかも。

CPU温度を取れるようにする

FreeBSDではCPUの温度はカーネルの温度関係のモジュールを使えるようにしていないと機能しないかもしれない。まぁ、システム監視をするなら間違いなく有効にしているだろうけど。

手動でカーネルモジュールを読み込んで温度を確認する方法

# kldload coretemp    #←カーネルモジュール読み込み CPUがAMD系ならkldload amdtemp
# sysctl dev.cpu | grep temperature  #←CPU温度表示
dev.cpu.3.temperature: 42.0C    #以下、CPUのコア(仮想含む)の数だけ温度が表示される。
dev.cpu.2.temperature: 42.0C
dev.cpu.1.temperature: 41.0C
dev.cpu.0.temperature: 41.0C
/boot/loader.conf (システム起動時に自動的に読み込む設定を追加)
1
2
coretemp_load="YES"  #Intel系CPU用
amdtemp_load="YES"  #AMD系CPU用

Node Exporterの情報確認

Node Exporterの情報はプル(Pull)なので、送られてくるのではなく取りに行く。つまり「http://Node Exporterホスト:9100/metrics」にアクセスしたらそのホストのNode Exporterの情報を取ることができる。
FreeBSDのホストのNode Exporterの情報を見るとメモリと温度は以下のようなの。つまり、Grafanaで見ると表示はされていないが、それらしいものは出力はされている。ただし、Linuxと比べると取得できる項目はだいぶ少ないっぽい。

メモリ
# HELP node_memory_active_bytes Recently used by userland
# TYPE node_memory_active_bytes gauge
node_memory_active_bytes 1.083392e+07
# HELP node_memory_buffer_bytes Disk IO Cache entries for non ZFS filesystems, only usable by kernel
# TYPE node_memory_buffer_bytes gauge
node_memory_buffer_bytes 1.16641792e+08
# HELP node_memory_cache_bytes Almost free, backed by swap or files, available for re-allocation
# TYPE node_memory_cache_bytes gauge
node_memory_cache_bytes 0
# HELP node_memory_free_bytes Unallocated, available for allocation
# TYPE node_memory_free_bytes gauge
node_memory_free_bytes 1.2384256e+08
# HELP node_memory_inactive_bytes Not recently used by userland
# TYPE node_memory_inactive_bytes gauge
node_memory_inactive_bytes 7.29227264e+08
# HELP node_memory_size_bytes Total physical memory size
# TYPE node_memory_size_bytes gauge
node_memory_size_bytes 1.949618176e+09
# HELP node_memory_swap_in_bytes_total Bytes paged in from swap devices
# TYPE node_memory_swap_in_bytes_total counter
node_memory_swap_in_bytes_total 0
# HELP node_memory_swap_out_bytes_total Bytes paged out to swap devices
# TYPE node_memory_swap_out_bytes_total counter
node_memory_swap_out_bytes_total 0
# HELP node_memory_swap_size_bytes Total swap memory size
# TYPE node_memory_swap_size_bytes gauge
node_memory_swap_size_bytes 0
# HELP node_memory_swap_used_bytes Currently allocated swap
# TYPE node_memory_swap_used_bytes gauge
node_memory_swap_used_bytes 0
# HELP node_memory_wired_bytes Locked in memory by kernel, mlock, etc
# TYPE node_memory_wired_bytes gauge
node_memory_wired_bytes 1.085915136e+09

CPU温度
# HELP node_cpu_temperature_celsius CPU temperature
# TYPE node_cpu_temperature_celsius gauge
node_cpu_temperature_celsius{cpu="0"} 40.9
node_cpu_temperature_celsius{cpu="1"} 40.9
node_cpu_temperature_celsius{cpu="2"} 41.9
node_cpu_temperature_celsius{cpu="3"} 41.9

Linuxと比べるとFreeBSDではメトリクス名が違うのが判るはず。LinuxとFreeBSDで明らかに対応しそうな似たメトリクス名があってもそれに値が入っていない場合は別のメトリクスから探さなければならなかったり、複数のメトリクス値から計算する必要があったり。

node exporter 1
Grafanaで使用しているテンプレートから、メモリのグラフ表示のためにの何のメトリクスを使っているかを編集モードで確認する。クエリーの全文を確認する。1つのメトリクスしか使われていないとは限らない。

FreeBSD           ⇔    Linux
メモリ
node_memory_free_bytes   ⇔ node_memory_MemAvailable_bytes
node_memory_inactive_bytes ⇔ node_memory_MemFree_bytes
node_memory_size_bytes   ⇔ node_memory_MemTotal_bytes
スワップ
node_memory_swap_size_bytes ⇔ node_memory_SwapTotal_bytes
node_memory_swap_used_bytes ⇔ node_memory_SwapCached_bytes
node_memory_swap_size_bytes - node_memory_swap_used_bytes(差分) ⇔ node_memory_SwapFree_bytes
CPU温度
node_cpu_temperature_celsius ⇔ node_hwmon_temp_celsius

「がとらぼ」の中の人はFreeBSDではスワップを使わない方針のため、ちょこっと試しただけでテキトーに書いてます。間違っていたらスミマセン。

Prometheusの設定変更

対応を調べたら、メトリクス名の書き換えをPrometheusに設定する。
このときに、ルールを書く設定ファイルを分ける。

メインのPrometheusの設定ファイル
/usr/local/etc/prometheus.yml (追記)
1
2
rule_files:
   - "prometheus_node_exporter.yml"

2行を追加する。すでに別のルールファイルを指定して使っているなら既存のルールファイルの指定行の次の行に上の2行目を指定する。
YAMLファイルは行頭の字下げに意味があるのでむやみに字下げしたり、逆に行頭のスペースを取らないこと。
ファイル名だけを指定したら設定ファイルと同じディレクトリという意味なので/usr/local/etc/prometheus_node_exporter.ymlになる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
groups:
- name: node_exporter-FreeBSD-metrics  #何か名前をつける
  rules:
  - expr: node_memory_free_bytes                #書き換え元のメトリクス名
    record: node_memory_MemAvailable_bytes    #書き換え後のメトリクス名
  - expr: node_memory_inactive_bytes
    record: node_memory_MemFree_bytes
  - expr: node_memory_size_bytes
    record: node_memory_MemTotal_bytes
  - expr: node_memory_swap_size_bytes
    record: node_memory_SwapTotal_bytes
  - expr: node_memory_swap_used_bytes
    record: node_memory_SwapCached_bytes
  - expr: (node_memory_swap_size_bytes{job="node_exporter"} - node_memory_swap_used_bytes{job="node_exporter"})
    record: node_memory_SwapFree_bytes
  - expr: node_cpu_temperature_celsius
    record: node_hwmon_temp_celsiu

Linuxのnode_memory_SwapFree_bytes (スワップの空き容量)に相当する値はFreeBSDでは取得できないようなので、node_memory_swap_size_bytes (スワップの全容量)とnode_memory_swap_used_bytes (スワップ使用量)の差分を求めて、その値がスワップの空き容量だろうとした。何台かのFreeBSDホストでスワップを使っていたらこのメトリクス名と計算が正しいのか確認できたんだろうけど、空いてた1台に急遽スワップを作って、スワップがほぼほぼ使われない中で「これかな?」で出したので正しいかは判らない。

Grafanaでグラフ表示を確認する

Prometheusを再起動またはリロードする。

# service prometheus restart
または
# service prometheus reload

暫く待ってGrafanaにメモリ、スワップ、CPU温度が表示されればOK.

node exporter 2
前回のテンプレートではCPU温度は 下部で折りたたまれたSystem Detailを展開した最後のグラフ。

このようにメトリクス名を変換、或いは、複数のメトリクスから計算した値を渡すようにすることで、Linuxとは違う名前のメトリクスで出力されるシステムでも簡単に表示できるようになる。今回の場合はテンプレートを弄っていないので当然Linuxホストはそのまま正常に表示できる。

関連記事:

Orange Pi Zero PlusでADS-B受信

前回までは、アンテナからRTL-SDRチューナーまで20mのアンテナケーブルを通していた。
しかし、高周波で長いアンテナケーブルは大きく減衰するという情報を得ていたので、このアンテナケーブルを短くすることにした。そこで、アンテナ直下(実際にはBPF+LNAを挟んで)チューナーを繋ぎ、そこからUSBケーブルでシングルボードコンピュータに繋ぐことにした。シングルボードコンピュータは先日購入したOrange Pi Zero Plus。そこからLANは有線のネットワークケーブルで。Oragne Pi Zero PlusはArmbian (Debian buster)を入れて、ADS-Bの受信は dump1090-mutabilityを使用することにした。つまり、dump1090-Xで受信してLANにデータを流し、他のPCでその受信したデータを使う(地図にプロットするなど)することにした。dump-1090-Xにもウェブ機能があって地図にプロットして他のPCのブラウザからそれを見るということができるが、今回はOrange Pi Zero Plusが(SBCとしてはまぁまぁでもPCと比べるとかなり)非力なのでプロットは他のPCで行うということにした。それに、パッケージで配布されるdump-1090-Xは内臓ウェブ機能が殺してあったりするし。

dump1090でADS-B受信 1
購入して開封したばかりのOrange Pi Zero PlusのSoCにヒートシンクとつなげるための銅ブロックを乗せた写真。(このときはまだ付属の無線LANアンテナがつながっている。)

dump1090でADS-B受信 2
左上がアンテナ、青い基板がBPF+LNA、緑色(+黒ヒートシンク)がチューナー、USBでつながっている右の基板がOrange Pi Zero Plus。それから生えている黒い細い線でつながった中央下寄りの金色のやつは無線LANを殺すためのダミーロード。また、Orange Pi Zero Plusから赤黒のコードが伸びているのはBPF+LNAに供給する5V+GND
と、いうことで、前回設置したアンテナの台となる塩ビパイプの中に、ほぼ一式が収まる形となる。
写っていないが、この一式に電力を供給するダイソーの2.1AのUSB ACアダプタも用意している。

dump1090でADS-B受信 3
塩ビパイプに2cm x 2cmの穴をあけた。Orange Pi Zero Plusの基板に付けた銅ブロックがぎりぎり通るサイズに穴を開ける。穴が大きいとガタつく筈なので少し小さく穴をあけて、ヤスリで削って調整した。上の写真では穴がパイプの上に近い側にあいているように写っているが、実際は上下逆。
穴のサイズは銅ブロックとぴったりであっても雨が入ると困るので穴と銅ブロックの境にはホットボンド(グルーガン)をグルリと1周。これで防水だけでなくさらにガッチリ固定できる。

dump1090でADS-B受信 4
設置した。見た目は前回と殆ど変わらない。パイプから頭を出している銅ブロックの上に(側面に)ヒートシンクを熱伝導テープで貼り付けた。このテープは圧力をかけたらその後は外れなくなるので便利。(剥がす時が怖いけど)

Orange Pi Zero Plusでチューナーの認識

Orange Pi Zero Plusにログインし、USBで繋いだRTLチューナーを認識していることを確認する。

$ lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

復調用チップはRTL2832Uの筈なのにRTL2838と認識されているが、これは気にしなくて良いらしい。
つまり、特に何もせずにUSBチューナーを挿すだけで認識されている。Windowsとは大違い。

dump1090-mutabilityのインストール

$ sudo apt update                        #←パッケージ情報を最新にする
$ apt-cache search dump1090    #dump1090-XXXを探す   (検索だけならsudo無しで可)
armbianで提供される標準レポジトリではdump1090-mutabilityだけが表示された。
$ sudo apt install dump1090-mutability

残念ながらdump1090-faは無かったが、dump1090-mutabilityがダメということではない。
とにかく、インストールはこんだけ。あっけない。

テスト起動 インタラクティブ表示+ネット出力

$ dump1090-mutability --interactive --net
もう少し指定するならこんな感じ?
$ dump1090-mutability --net-only --net-bo-port 30007 --net-bi-port 30006
とか
$ dump1090-mutability --net-only --net-bo-port 30007 --net-sbs-port 0 --net-fatsv-port 0 --net-bi-port 30006
テキトーに好みのオプションを付けてやれば良い筈

起動してエラーにならないこと。

問題ないようであれば、自動起動の設定を行う。
パッケージでインストールしたdump1090-mutabilityでは/etc/init.d/dump1090-mutabilityというスクリプトが用意されているようだが、init系のサービス起動はよくわからない。(基本的にFreeBSD派なのでLinuxはよくわかっていない)
なので、systemd用の自動起動の設定を行う。

/lib/systemd/system/dump1090-mutability.service (新規作成)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
[Unit]
Description=dump1090-mutability
Before=multi-user.target
After=network-online.target
Wants=network-online.target

[Service]
WorkingDirectory=/usr/share/dump1090-mutability/
ExecStart=/usr/bin/dump1090-mutability --interactive --net      #←起動コマンドは好きにして
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target
サービスの有効化 (以後、意図的に無効化するまでずっと有効+自動起動)
# systemctl enable dump1090-mutability
有効化したサービスを手動で起動
# service dump1090-mutability start
サービスを手動で停止
# service dump1090-mutability stop

armbianで提供される標準レポジトリでインストール可能なdump1090-mutabilityは内蔵ウェブサーバ機能が無効になっている。
内蔵ウェブサーバが欲しければ自分でdump1090-XXXを内蔵ウェブサーバ有効でビルドすることになるが、非力なシングルボードコンピュータで動いているdump1090-XXX側でウェブサーバを動かす必要は無いと考える(動かしたくない)。

受信したデータをWindowsで表示

今回はdump1090-mutabilityで受信したデータをLANに流しWindowsでプロットすることにした。
Windows側で使用するのは定番のVirtual Radar Serverで、ダウンロードページからダウンロードして普通に実行してインストールする。
今回はWIndows用のVirtual Radar Serverを使ったが、LinuxやMacのOSXもあるのでPCなら大抵はVirtual Radar Serverは使える。

Virtual radar Server 1
WindowsではVirtual Radar Serverをインストールするとスタートメニューの「V」の中にVirtual Radarという項目が出来て、その中のVirtual Raderという飛行機アイコンをクリックしてVirtual Raderアプリを起動する。
メイン画面はこんな感じ。上の画像はすでに稼働中のVirtual Raderなので幾つか表示が入っているけど初起動なら白い罫線部分は真っ白の筈。

Virtual radar Server 2
左上のメニューから「Tools」をクリックする。
ポップアップしたメニューの一番下の「Options」を開く。

Virtual radar Server 3
左列一番上の「Data Sources」が開く筈。違うの表示されたら「Data Sources」をクリックする。
マッププロバイダはGoogle Mapsあたりが無難。Google Mapsをアプリから使うにはAPIキーが必要になるので、ブラウザを開いてGoogleに自分のアカウントでログインしてMAP APIキーを取得する。(方法はググってね)
取得したAPIキーを「Google Maps API key」の欄に貼り付ける。

Virtual radar Server 4
左列の上から2番めの「Receivers」を選択する。
上の画像では既に「Orange Pi Zero Plus」というのが登録されているが、初めて起動なら表示されない筈。
ADS-Bレシーバーを追加する場合は[+]を押す。

Virtual radar Server 5
レシーバーの登録画面
「name」欄に受信機の名前(わかりやすいの)を入力。
「Address」欄には受信機の繋がったホストのIPアドレスを入力。
「Port」欄には30003など、受信機の繋がったホストのDump1090-Xと通信できるポート番号を入力。

Virtual radar Server 6
左列の「Web Server」を選択。
飛行している飛行機を正しく認識できた範囲を地図上にプロット(カバレッジ表示)するなら「Internet users can see receiver range Plots」にチェックする。初期値はチェック無し。暫く使った後はまたチェックを外すことになると思うけど。

Virtual radar Server 7
設定したら最初の画面に戻って、ウェブサーバがオンラインになっていることを確認。またはオフ・オンするなど。
オンライン・オンラインの切り替えは、右上のボタンを押す。

Virtual radar Server 8
もう一度メニューから[Tool]s → [Options]を開いて、左列から「Web Site」の下の「Initial Settings」を選択する。
右上にURLが幾つか表示される。メインで使うのは一番上。それをクリックするかリンクをコピーしてブラウザで開く。

Virtual radar Server 9
ブラウザでDesktop Siteを開いて暫く〜1日くらい待つ。
設定でカバレッジをプロットするようにしたので、受信機から飛行中の飛行機が正しく認識されている範囲(Virtual Radar起動から現在)が透過黒色で地図上に表示されている。(上の画像の地図の中央のギザギサの黒っぽいやつ)
この範囲は、完全に認識された飛行機が通った最も遠い場所を示すので、認識が中途半端な飛行機がもっと遠くを通っても範囲は広がらない。逆に言えば、不正確に認識された飛行機はカバレッジのエリアの外をいっぱい飛んでいる。
眺めていたら右下のリストで飛行機の高度がGNDと表示されていてどこかの飛行場にいるらしいのも認識されている様子。上の地図のカバレッジの範囲内には飛行場は無いと思うので、福井・小松・小牧・中部国際、関空・伊丹・神戸のどれかに居る飛行機の筈。つまり結構広い範囲が不正確ながらも受信出来ている様子。東の方はカバレッジでは一宮辺りまでとなっているが、右下のリストに表示される飛行機の登録番号から確認すると木曽山脈に近い中津川あたりの上空を飛行する機からも不完全ながらも信号が届いているよう。

Virtual radar Server 10
地図の全画面表示もできる。日本の本州の形が判るくらいで表示すると、カバレッジ狭いなぁ。アンテナ設置場所からの距離でこの1.5倍くらいは欲しい。できたら大阪湾と伊勢湾の上空にいる飛行機の信号が届いて欲しい。飛行場とか低高度に居るのまで受信したいなんて贅沢は言わないから。

20mのアンテナケーブルを無くすともっと広い範囲(全方位で100km以上程度)を確実に受信できるのかと期待したが、20mのアンテナ線を使った前回と比較して、アンテナ設置場所からの距離で1〜2割程度増えただけでで思ったよりもカバレッジは広がらなかった。しかし、認識される飛行機の数は大幅に増えていて、さらにカバレッジ内外の中途半端認識機の数が凄い。アンテナ設置場所が周囲を山に囲まれているので全方位で100km, 150km、山が無い方向で200km, 300kmというのは無理かと思ったが、アンテナを良くすればチャンスありかもと期待してしまう。
購入した1090MHzのアンテナは6dBiと書かれたシールが貼ってあったが、信じていない。同様のアンテナが2dBi程度なのでそれと同じ程度の筈だと思っている。4千円〜1万円程度の市販アンテナを買うのもアリだろうけど、テキトーに自分で作ることを考えている。アンテナの性能を測定する機械を持っていないので段数の多いコリニアアンテナとかは無理だけど。

あと、アンテナ下の塩ビパイプは密封ケースに近い状態だけど、そこに熱源のRTL-SDRレシーバーとシングルボードコンピュータが入って中がかなり高温になっている模様。シングルボードコンピュータのSoCの熱の幾らかはヒートシンクから外部に放出されている筈だが、RTL-SDRレシーバはパイプ内に熱を吐いたのがそのままパイプ内に留まるし、パイプに当たった太陽の熱もパイプ内を温める。OrangePi Zero Plus内蔵のSoC温度計によると午後の一番暑い時間だと70度を示すほど。Orange Pi Zero Plusとヒートシンクだけを室内で動かしたときは50度を超えることはなかったのでやはり高温。Orange Pi Zero Plusは多少の高温でも大丈夫かもしれないが、RTL-SDRレシーバがそれに近い温度で大丈夫かしら。
今度、自作アンテナに取り替える際にパイプの排熱も少し考えたい。(その頃には気温が下がってるかもだけど)

関連記事:

NanoPi NEOでNTPサーバ再構築 (全まとめ)

NanoPi NEOでNTPサーバ

2年半ほど前に作ったNanoPi NEOのNTPサーバだが、ストレージの使用状況の値が取れなくなったのでsshでログインしたところ、ファイルシステムが見えなくなっていた。メモリ上に展開済みのサービスだけが動いていて使用できる状態。ファイル操作に関するものはlsすら通らなくて全部I/Oエラー。システムを再起動することも出来ずに電源ブッチして、その後もう一度電源を入れたが2度と起動しなかった(そりゃそうだ)。
NanoPi NEOのストレージはmicroSDカードなので、それを抜いてPCに挿してみたが、カードを認識するもののパーティションもファイルも見えず、こちらもエラー。強制的にゼロフィルしてみたけど、I/Oエラー頻発でもうmicroSDカードとして正常に使えないみたい。
で、このmicroSDカードを作ったときにカードが壊れることを前提に、カードのコピーを作って予備に置いておいたのだが、こちらもPCに挿しても中身が読めず、NanoPi NEOに挿してもやはり使えず。
最近のmicroSDカードは多くがTLCなのでデータの保持期間が短くなっていて2年〜4年で保存されたデータが信頼できなくなる(消える)とは聞いていたけど、本当なのね。
最近はQLCなんてのも登場しているみたいだけど、低容量のカードには採用されてないだろうし、そもそもよく知らないけど怖いなぁ。

ということで、予備も使えないということで、一から作り直すことに。これに懲りて、今後は完成したmicroSDをイメージファイルにしてハードディスクに保管しよう、そうしよう。

さて、2年半ほど前は当時の最新版のArmbianのDebian jessieで作ったが、今はその次のDebian stretchも過ぎて最新版がDebian busterになっている。
ブログ用にDebian jessieのイメージファイルarmbian_5.27_Nanopineo_Debian_jessie_dev_4.10.3-gatolabo.7zを上げてたけど、さすがに古いのでArmbianのDebian busterを最新ソースでビルドすることにした。

カーネルオプションはDebian jessieのときと同じくTimer周りを変更した。(前回の記事参照) なお、Device DriverのPPS SupportのPPS client using GPIOは標準が選択状態だったので触っていない。また、サウンド周りは今回は未変更。

NanoPi NEO用Armbian5.93 Debian buster 4.19.65  Timer変更版 (NanoPi NEO2用ではない)
Armbian_5.93_Nanopineo_Debian_buster_next_4.19.65.7z

NanoPi NEO用Armbian5.94 Debian buster 4.19.68  Timer変更・サウンド無し版
Armbian_5.94_Nanopineo_Debian_buster_next_4.19.68.7z

イメージファイルをmicroSDカードに焼いて、NanoPi NEOに挿すのだが、最近のArmbianでNanoPi NEO/NEO2用は初期値が何故かネットワークを利用できない状態になっている。NanoPi NEOに挿す前にPCに挿してマウントし、その設定を触る。Linuxなどではファイルの書き換えに管理者権限が要る筈なので注意。
同じArmbianでもOrange Pi用はネットワークケーブルを挿すだけで(DHCPなら)自動的にネットワークに繋がるんだけどNanoPiは違うのは何でかしら?

一応、正規のやり方は以下らしい。
焼き終わったmicroSDカードをPCに挿してマウントしたところまでやったとする。
そのmicroSDの中の/boot/armbian_first_run.txt.template をリネームしてarmbian_first_run.txt にする。
そのarmbian_first_run.txtを編集する。何か幾つか存在する設定行の FR_hogehoge='値' を自分のネットワーク環境に合わせて変更する。
これは有線・無線(USBのWi-Fiアダプタ使用時)のどちらもらしい。
で、設定の書き換えが終わったら比較的上の方にあるFR_general_delete_this_file_after_completion=1 という行を削除してからファイルを上書き保存する。で安全な方法でPCからアンマウントしてからNanoPi NEOに挿して最初の電源投入を行ってrootでログインしてarmbian-configでいろいろ設定。
と、いうことらしい。

しかし、面倒なのでそんなのは無視。
以下

/etc/network/interfaces (編集)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
auto lo  #この2行は最初からある筈
iface lo inet loopback

auto eth0
allow-hotplug eth0
#no-auto-down eth0

iface eth0 inet static    #IPv4で固定IPの設定
address 192.168.0.124   #IPv4のIPアドレス
netmask 255.255.255.0  #IPv4のサブネットマスク
gateway 192.168.0.1     #IPv4のデフォルトゲートウェイ
dns-nameservers 8.8.8.8  8.8.8.4  #IPv4用のネームサーバ

iface eth0 inet6 static   #IPv6で固定IPの設定
address 2001:xxxx:xxxx:xxxx::xxxx  #IPv6のIPアドレス
netmask 64    #IPv6プレフィックス長
gateway 2001:xxxx:xxxx:xxxx::yyyy  #IPv6のデフォルトゲートウェイ
dns-nameservers 2001:4860:4860::8888  2001:4860:4860::8844 #IPv6用のネームサーバ

#もし、DHCPなら
auto eth0
iface eth0 inet dhcp

ファイルを書き込んだら正しい手順でアンマウントしてからNanoPi NEOに挿して電源オン。
SSHでログイン。アカウントはrootでパスワードの初期値は1234。初ログイン時はすぐにパスワード変更を求められるので、先に1234を入力してから、次に新しいパスワードを入力する。そのまま新しい通常ユーザー登録に進む。

DHCPを使わない場合は/etc/resolv.confで名前解決の設定も。でないと、少なくともNTPで外部の時刻ソースをホスト名指定したときに困る筈。

CPUクロックの調整

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
120000 240000 480000 648000 816000 960000 1008000 1056000 1104000 1152000 1200000 1224000 1248000 1296000 1344000 1368000

NanoPi NEOは以前は最高クロックが1008000だった筈だが、1368000まで使えるようになっている?
しかし、そんなクロックは要らないので648000〜1008000辺りで調整。その際に稼働中に周波数が可変にならないよう最低値と最大値を同じにする。実際はガバナーをperformanceにすれば指定した最大クロックしか使われない筈。

/etc/default/cpufrequtils (修正)
1
2
3
4
ENABLE=true
MIN_SPEED=1008000
MAX_SPEED=1008000
GOVERNOR=performance

ガバナーをperformanceにしているのでMIN_SPEEDは0でも何でも良い気がするが、一応MAXと合わせた。

システム再起動する

設定の反映状態を確認。
$ cpufreq-info -p
1008000 1008000 performance
クロックの固定・可変状態の確認
$ cpufreq-info -s
120000:1, 240000:0, 480000:3, 648000:0, 816000:12, 960000:23, 1008000:130755, 1056000:2, 1104000:0, 1152000:0, 1200000:0, 1224000:0, 1248000:0, 1296000:0, 1344000:0, 1368000:798  (58)

1008000:xxxのxxxが大きくて、他のクロックのxxxが0または小さな値であること。
さらに暫くシステムを再起動しない状態の後にもう一度コマンドを実行して1008000:xxxのxxx値だけが増加すること。他のクロックのxxxが増えなければOK.

PPSを使えるようにする

/boot/armbianEnv.txt (編集)
1
2
3
4
5
6
7
8
9
verbosity=1
logo=disabled
console=tty0
overlay_prefix=sun8i-h3
overlays=uart1 pps-gpio
param_pps_pin=PG9
rootdev=UUID=7c95fe25-eeb0-4d04-a3e5-fde8a5771a1f
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

基本的には変更するのはoverlays=の行で、他にparam_pps_pin=の行を追加する。
PPSのピンはGP9を指定しているが、これがNanoPi NEOのどのピンかは過去記事参照。
特に気を付けたいのはoverlays=行で、全部書き換え。

システムを再起動してdmesgを確認。

$ dmesg | grep pps
[    1.360813] pps_core: LinuxPPS API ver. 1 registered
[    1.360821] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    9.321577] pps pps0: new PPS source pps@0.-1
[    9.321737] pps pps0: Registered IRQ 96 as PPS source
こんな感じで表示されればOK.

NTPのビルド・インストール

システムに最初から入っているntp関係のファイルを削除してビルドしたntp関係のファイルに置き換える。特に難しいところはないので、さくっと実行するだけ。

$ sudo  apt install libcap-dev
$ sudo service ntp stop
$ sudo /lib/systemd/systemd-sysv-install disable ntp
$ sudo apt remove ntp
$ cd ~
$ wget http://archive.ntp.org/ntp4/ntp-4.2.8p13.tar.gz
$ tar zxvf ntp-4.2.8p13.tar.gz
$ cd ntp-4.2.8p13
$ ./configure CFLAGS="-O2 -g -fPIC" --enable-linuxcaps --enable-ATOM --enable-NMEA --enable-ipv6 --prefix=/usr --bindir=/usr/sbin --sysconfdir=/etc
$ make -j4
$ sudo make install
$ sudo mkdir /var/lib/ntp
$ sudo touch /var/lib/ntp/ntp.drift
$ sudo chown -R ntp:ntp /var/lib/ntp
$ sudo rm /etc/systemd/system/ntp.service    #←このファイルの古いのが残っていると困るので忘れずに

ntpは普通のサービスではないのでsystemctl disable HOGEのようなサービス無効化方法ではない。(3行目)
2年前は/usr/local/下にインストールしてシンボリックリンクにしていたが、元ファイルと同じく/usr/binや/usr/sbinなどに置くようconfigureで--prefix=/usrを指定するようにした。
2019年8月中旬現在、ntp4の最新版は4.2.8p13になっている。

/lib/systemd/system/ntp.service (作成)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
[Unit]
Description=Network Time Service
Documentation=man:ntpd(8)
After=network.target
Conflicts=systemd-timesyncd.service

[Service]
Type=forking
# Debian uses a shell wrapper to process /etc/default/ntp
# and select DHCP-provided NTP servers if available
ExecStart=/usr/sbin/ntpd
PrivateTmp=true

[Install]
WantedBy=multi-user.target

このファイルはntpパッケージを削除する前の/lib/systemd/systemd/ntp.serviceを退避しておいてそのまま戻すというのはダメ。ExecStart行が元のままでは使えない。
12行目のPrivateTmpは下手に指定しない方が無難かも。(12行目は無しで良い) 上の例のようにしているとntpの各種stats情報を取得しようとして指定ディレクトリにファイルが出力されないと悩むことになるかも。

ここまでやったらntpをサービスとして有効化する。ntpd起動はまだ。

$ sudo ln -s /lib/systemd/system/ntp.service /etc/systemd/system/multi-user.target.wants/ntp.service
$ sudo /lib/systemd/systemd-sysv-install enable ntp

ntp無効化時と同じく、普通のサービスのようにsystemctl enable HOGEで有効化ではない。(2行目)

NTPの設定

ntpdが使用するデバイスを読み込み可にするが、普通のコマンド打ちではシステム再起動後に戻ってしまうので、パーミッションを自動設定するように設定ファイルを書く。

/etc/udev/rules.d/10-gps.rules (新規作成)
1
2
KERNEL=="ttyS1",SYMLINK+="gps0",MODE="0666"
KERNEL=="pps0",MODE="0666"

システム起動後のコマンドを追加する。

/etc/rc.local (exit 0の直前に挿入)
1
2
3
4
/bin/systemctl stop ntp.service
/bin/stty -F /dev/ttyS1 9600
/usr/sbin/ntpdate 162.159.200.1     #CloudFlare NTP Server
/bin/systemctl start ntp.service

ここではserviceコマンドは使わずsystemctlにした。(serviceではサービス起動に失敗したので)
ntpdateが無い場合はapt install ntpdateで入れる。
ntpdate -u xxx.xxx.xxx.xxxの様に-uオプションを使うならNTPサーバ稼働中でも実行できるがここで実行。

/etc/ntp.conf (全面編集)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list

#statsdir /tmp/
#statistics loopstats peerstats clockstats
#filegen loopstats file loopstats type day enable
#filegen peerstats file peerstats type day enable
#filegen clockstats file clockstats type day enable

#cloudflare
server time.cloudflare.com prefer #162.159.200.1, 162.159.200.123, 2606:4700:f1::1, 2606:4700:f1::123
server ntp1.jst.mfeed.ad.jp #210.173.160.27

#mfeed
#server ntp2.jst.mfeed.ad.jp #210.173.160.57 prefer
#server ntp3.jst.mfeed.ad.jp #210.173.160.87
#server ntp1.v6.mfeed.ad.jp #2001:3a0:0:2001::27:123
#server ntp2.v6.mfeed.ad.jp #2001:3a0:0:2005::57:123
#server ntp3.v6.mfeed.ad.jp #2001:3a0:0:2006::87:123

restrict -4 default ignore
restrict -6 default ignore
restrict -4 127.0.0.1
restrict -6 ::1

#My Network(LAN)
restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
restrict 2001:xxxx:xxxx:xxxx:: mask ffff:ffff:ffff:ffff:: nomodify notrap

#cloudflare
restrict -4 162.159.200.1 mask 255.255.255.255 nomodify notrap noquery
restrict -4 162.159.200.123 mask 255.255.255.255 nomodify notrap noquery
restrict -6 2606:4700:f1::1 nomodify notrap noquery
restrict -6 2606:4700:f1::123 nomodify notrap noquery

#mfeed
restrict -4 210.173.160.27 mask 255.255.255.255 nomodify notrap noquery
restrict -4 210.173.160.57 mask 255.255.255.255 nomodify notrap noquery
restrict -4 210.173.160.87 mask 255.255.255.255 nomodify notrap noquery
restrict -6 2001:3a0:0:2001::27:123 nomodify notrap noquery
restrict -6 2001:3a0:0:2005::57:123 nomodify notrap noquery
restrict -6 2001:3a0:0:2006::87:123 nomodify notrap noquery

#NMEA
server 127.127.20.0 mode 16 minpoll 4 prefer
fudge  127.127.20.0 time2 0.175 refid NMEA

#PPS
server 127.127.22.0 minpoll 4 true
fudge  127.127.22.0 flag3 1 refid PPS

2年前は外部の時刻ソースは全てMFEEDにしたが、今回は今年の5月くらいだっけに話題になったCloudfalreの公開NTPサーバを参照する。今後はこれをホスト名指定してラウンドロビンで使うのが良いかなと。あと、念の為にMFEEDの1台。
今回はpreferはCloudflareのNTPサーバに付けている。

DHCPの場合はNTPが勝手に制御されて/etc/ntp.confが使われないようなので、次のファイル内のrequest行の最後の部分を消す(黄字の部分)。

/etc/dhcp/dhclient.conf (変更)
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, domain-search, host-name,
	dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
	netbios-name-servers, netbios-scope, interface-mtu,
	rfc3442-classless-static-routes, ntp-servers;
一番最後のセミコロンを間違って消さないこと。

システムを再起動する。
または、他は全て準備出来ていて、NTPサービスだけ起動するなら

$ sudo service ntp start

システムまたはNTPサービス起動後、暫く待ってから確認。特にPPSは5分程度待つ。

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .NMEA.           0 l    4   16  377    0.000   -1.176   5.355
oPPS(0)          .PPS.            0 l    3   16  377    0.000    0.001   0.002
+2606:4700:f1::1 10.22.8.215      3 u   33   64  377   12.631   -7.143   0.153
+ntp1.jst.mfeed. 133.243.236.17   2 u   57   64  377   11.800    1.048   0.204

上はntpd起動後18時間くらい経っている。外部時刻ソースとの差を要調整かも。

おまけ、不要なサービスの停止

サービスの確認
$ sudo systemctl list-unit-files

リストが表示されるので不要なサービス名をメモる。

サービスの停止と無効化 (それぞれ2行セットで)
$ sudo systemctl stop dbus-fi.w1.wpa_supplicant1.service
$ sudo systemctl disable dbus-fi.w1.wpa_supplicant1.service
$ sudo systemctl stop dbus-org.freedesktop.nm-dispatcher.service
$ sudo systemctl disable dbus-org.freedesktop.nm-dispatcher.service
$ sudo systemctl stop network-manager.service
$ sudo systemctl disable network-manager.service
$ sudo systemctl stop NetworkManager-dispatcher.service
$ sudo systemctl disable NetworkManager-dispatcher.service
$ sudo systemctl stop NetworkManager-wait-online.service
$ sudo systemctl disable NetworkManager-wait-online.service
$ sudo systemctl stop NetworkManager.service
$ sudo systemctl disable NetworkManager.service
$ sudo systemctl stop wpa_supplicant.service
$ sudo systemctl disable wpa_supplicant.service
$ sudo systemctl stop apt-daily-upgrade.timer
$ sudo systemctl disable apt-daily-upgrade.timer
$ sudo systemctl stop apt-daily.timer
$ sudo systemctl disable apt-daily.timer
$ sudo systemctl stop man-db.timer
$ sudo systemctl disable man-db.timer

必要・不要なサービスは人によって、環境によって異なると思うので自己判断で。

関連記事: