My Blog

今月初めにやってきた台風6号が思いもよらず強風だったことで止めていた太陽電池パネルが吹き飛ばされた

配電用のケーブルが付いているのでどこかに飛んでいったわけでなく屋根の上で踊りまわったのだと思われる

快晴ではないにしろ充電レベルが少しも上がらなかったので判明したのだが，元に戻しても大して変わらなく太陽電池の出力電圧も13.3Vと低い，太陽電池パネルのケーブル接続部分を触ると出力電圧が変化することから接触不良になったようだ

そして昨日の19:00頃バッテリーの低下により室外サーバが停止

このままでは室外サーバは復旧できないので，同時に購入していたもう１枚の太陽電池パネルを使い更新

更新した太陽電池パネルの出力電圧を確認すると曇りで13.92Vとなり改善

更新前のパネルは約３年前に設置した物

表面は汚れもあるが拭いても変わらないため焼け付けや細かい傷が付いていると思われる

白かったベース部（周辺のフチ）の色も変わっている

フレキタイプのパネルなので廃棄も楽だろう

ゴミ捨ての都合もありQHFアンテナを撤去，換わりにコーリニアアンテナを設置

多段のコーリニアアンテナの下側がベランダの支柱に被っていたためか，影響しない場所への移動によってゲインアップし受信範囲が増え約30機前後から約40機まで増加

北方は約150NM（270km）が受信できている（南方と東方は1,000ｍ超の山が近いので厳しい）

直接波のみの受信として大ざっぱな見通し距離を計算すると，こちらからは標高約100m地点のアンテナなので，水平線まで約44km

航空機からは，高度2,500ｍ（8,202ft）で220kmとなるので，この辺りまで受信できているってことかな

参考）5,000ｍ（16,404ft）311km，10,000m（32,808ft）440kmとなる

場所がら高度は1,000mあたりが限界で低空まで追えないのは残念ではある

受信（dump1090-fa）が安定したので上部のリンクに「ADS-B」を追加

室外サーバにてADS-B受信をdump1090-mutabilityで試行させていたところ何度もダウンしたり受信できなくなる現象が発生

やはり更新の終わった古い版数からなのかと，後継として継続更新されているdump1090-faに変更

後継のdump1090はdebian系パッケージにはなくFlightAwareが提供しているようだ（なので-faか）

Armbian（ubuntu版）用に作成するため，がとらぼさんの記事を参考（こちらなど）にした

$ git clone https://github.com/flightaware/dump1090 dump1090-fa

$ sudo apt install git lighttpd debhelper librtlsdr-dev pkg-config dh-systemd libncurses5-dev libbladerf-dev libusb-dev devscripts
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています... 完了
状態情報を読み取っています... 完了
E: パッケージ dh-systemd が見つかりません
$

（dh-systemd は必要ないので外す）

$ sudo apt install git lighttpd debhelper librtlsdr-dev pkg-config libncurses5-dev libbladerf-dev libusb-dev devscripts

$ cd dump1090-fa
$ dpkg-buildpackage -b --no-sign --build-profiles=custom,rtlsdr

$ cd ..

$ ls dump*

dump1090-fa-dbgsym_10.2_arm64.ddeb
dump1090-fa_10.2_arm64.buildinfo
dump1090-fa_10.2_arm64.changes
dump1090-fa_10.2_arm64.deb

（インストール）

$ sudo dpkg -i dump1090-fa_10.2_arm64.deb

最新が10.2，再度入れ替える場合は以下のように先に削除

$ sudo systemctl stop dump1090-fa
$ sudo systemctl disable dump1090-fa
$ sudo dpkg -r dump1090-fa

簡易httpも動作し，アクセスは「localhost:8080」または「localhost/skyaware/」となる

MAP表示（試行中）：dump1090-fa

アンテナも付け替えてLNAを動作させたところ受信範囲は広くなった

ADS-B用のコーリニアアンテナを移動させて接続

室外サーバにVirtualRadarは負担が大きいので稼働は停止

Windows版VirtualRadarからJSONファイルをGETして表示させることはできるので，アプリサーバを立ち上げて重い処理を任せるのもありかなと検討中

尚，JSONファイルは/runに置かれるが，armbianでは基本/runはtmpfsになるのでSDカードでも問題にはならない

最近アクセスが多いのでログを観てみると，そのほとんどがBOTであることが判る

ログの書き込み量でパフォーマンスも落ちるし，SSDは書き込み量で劣化するので少しでも少なくしようかと以下を参考にログの調整を行った

参考：Apacheで特定のリクエストをログから除外しメモリ負荷を軽減する方法

ログの実態確認

リクエスト頻度が高いパスやリソースの確認

awk '{print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -20

以下が上位

/freo/js/
/freo/images/
/freo/css/
/robots.txt

特定のIPからのリクエスト確認

awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -20

現状は特に問題なし

BOTをログから抽出

grep "bot" /var/log/apache2/access.log

appleBot，GoogleBot，amazonbot，bingbotなどが抽出

100アクセス/時間という感じ

除外設定

000-default.conf，default-ssl.confのCustomLogの記述を以下に変更

# ボットアクセスの除外 
SetEnvIfNoCase User-Agent "bot" dontlog

# 静的リソースへのアクセス除外 
SetEnvIf Request_URI "^/freo/js/" dontlog 
SetEnvIf Request_URI "^/freo/images/" dontlog 
SetEnvIf Request_URI "^/freo/css/" dontlog

CustomLog /var/log/apache2/access.log combined env=!dontlog

「/」はそのまま記述できるようだ

実証確認

ログローテートも月単位更新から週へ変更

強制的にログローテート

logrotate -f /etc/logrotate.d/apache2

しばらく置いて，ログに無いことを確認