curl で switchbot API v1.1 を呼出す
Amazon タイムセールで、SwitchBot CO2 センサー付き温湿度計の割引がでていたので、Hub mini セットで発注。CO2センサーは以前 CCS811 でモニタリングしていたけど、もともと精度が悪かったし異常値がでるようになってモニタリングをやめてるので、SwitchBot で復活させたくて、買ってしまった。だけど、CO2センサーは発送が始まらず、Hub mini だけが届く。ということで、ひとまず Hub mini で遊ぶ。
curl で switchbot API の情報を取得する
Python などで API をたたく記事が多いけど、もう少しシンプルにできないかということで、手抜き curl で試してみる。
まずは、最もシンプルな、v1.0 で取得する方法。
最初の token, secret には、SwitchBot スマホアプリで入手したものを書き込む。(v1.0では secret 使ってないけど)
#!/bin/bash token="xxxxxx....xxxxxxx" secret="yyyy...yyy" url_list_v10="https://api.switch-bot.com/v1.0/devices" curl -s -H "Authorization:${token}" "${url_list_v10}"
switchbot API v1.1 で取得する
ちょっと面倒だけど、セキュリティ的には v1.1 で取得するのが定番。最初は Unauthorized で失敗して色々と試行錯誤したけど、openssl … -binary がキモだった。(こちらの記事を見て、sha256 のハッシュの形式が違うのに気づけた。)
#!/bin/bash token="xxxxxx....xxxxxxx" secret="yyyy...yyy" t="$(/usr/bin/date +%s%3N)" # time = Epoch time 13桁 nonce="$(/usr/bin/uuidgen)" # uuid sign=$(echo -n "$token$t$nonce" \ | /usr/bin/openssl dgst -sha256 -hmac "$secret" -binary \ | /usr/bin/base64 -w 0) url_list_v11="https://api.switch-bot.com/v1.1/devices" curl -s --request GET \ -H "Content-Type: application/json" \ -H "Authorization: ${token}" \ -H "sign: ${sign}" -H "nonce: ${nonce}" -H "t: ${t}" \ "${url_list_v11}"
取得した json コンテンツから特定のデバイスの情報を抜粋する
結果は、JSON 形式なので、jq を使って必要な場所だけ抜粋する。
$ bash swbot.sh \ | jq '.body.deviceList[] | select( .deviceId == "ZZZZZZZZZZZZZZZZ")'
Switchbot meter plus から温度,湿度を表示
Switchbot Hub mini が無い時は、温湿度計(meter plus)からのデータ取得は Bluetooth 経由で動かしていたので、Raspberry Pi で温度を取得していたが、この方法であれば LAN 接続であればどこからでも取得可能なので便利。
(略) swbot_meter="ZZZZZZZZZZZZZZZZ" url_list_v11_meter="${url_list_v11}/${swbot_meter}/status" curl -s --request GET \ -H "Content-Type: application/json" \ -H "Authorization: ${token}" \ -H "sign: ${sign}" -H "nonce: ${nonce}" -H "t: ${t}" \ "${url_list_v11_meter}" \ | jq -r '.body | "Temperature: " + (.temperature|tostring) + "C\n" \ + "Humidity: " + (.humidity|tostring) + "%"'
これで、温度、湿度がとれる。これなら munin 用のスクリプトも shell で簡単に書けそう。だけど、バッテリー残量(.battery)は 60% 台まで落ちているはずだけど、100% なんだよな。他の SwitchBot Plug でも、電力値が取れなかったりと SwitchBotAPI は、全機能を網羅していない様子。
買い替えたいもの…
Apple の WWDC 2024 の発表を終え、色々と買い替えたいと思い始める。とはいいながら、優先順位つけるだろうけど。
- Apple Watch 5 2019-10-05 (5年)
- WiFi メッシュルーター Buffalo WRM-D2133HP 2019-06-27 (5年)
- iPhone 12 mini (パパすまほ) 2021-05-09 (3年)
ルーターも、すでに5年経過しているようだ。
watchOS11では、series 5 が対象外になるから、Apple Watch かなぁ…
iPhone は、Apple が想定している買い替え周期は 3 年のようだけど、iOS 18 はまだ iPhone12 をサポートしてくれそうだし。
wordpressでWP_SITEURL,WP_HOMEでプロトコル指定を省略できないか?
ケーブルテレビのSTBのブラウザで、自宅サーバに接続させようとすると接続が拒否られる。letsencryptのroot証明を受け付けてくれないのが原因。一部の動作確認ページをブラウザから接続させたいと思うけど、自宅サーバはWordPressなのでhttpsで WP_HOME, WP_SITEURL がしてあるために、強制的に https になってしまう。
試しに、wp-config.php で “https://hostname” でなく、”//hostname” とか “/” を指定してみた。
“/” だと、ページが上手く表示されない。(cssなどがうまく読み込めていない様子)
“//hostname” だと、ページは表示できるけど、wp-login.php でのログインが上手くいかない。(多要素認証のプラグインが影響しているのかもしれない)
職場からの接続をFWの拒否リストに入れてた…
職場のWordPressの多要素認証対策で、自宅サーバにワンタイムパスワードを送っているんだけど、職場で自宅サーバに imap 接続ができなくなっていた。
症状としては、Thunderbird で自宅サーバ宛のメールが読めなくなった。色々と確認する中で、”telnet-ssl -z ssl 自宅サーバ imaps” を試すと、接続ができない。自宅だと問題なし。色々と疑ってかかったら、結論は、自宅サーバの FireWall に、職場からのアクセス拒否のルールが加えられていた。
んで、このアクセス拒否ルールが加えられた原因は、職場からのメールで “Sender address rejected: Domain not found” の log が残るから。
自宅サーバでは、”Sender address rejected” の警告が続くとメール系の接続拒否リストに登録する処理が書いてある。
ということで、/etc/postfix/sender_restrictions で MX レコードの引けないメールサーバの受入れ設定を記述する。また、接続拒否リストの生成スクリプトで、職場のアドレスを登録しないように修正する。
車載WiFi AN-S092を導入
WiFiルータとして、Huawei E5785 を利用していたけど、出先で使う頻度も少ないしもっと活用ということで車載WiFi として活用。
ただし E5785 だと車載ルータとしてつかう場合、車に乗るたびに起動操作が必要となるし、車を降りるとシャットダウンが必要。単純に車の電源に連動して使いたいということで車載用のWiFiルータを探し、KEIYO (あんまり聞かない日本企業) の AN-S092 を見つける。単純にUSB給電と共に起動し、バッテリーも無いので車を離れれば勝手に切れる。
早々に届いてセットアップ。でも、ちょっと手間取ったかな。
KEIYO AN-S092 のセットアップ
Huawei E5785 は、mineo(au) で使っていて、au VoLTE対応SIMで micro SIM サイズで使っていたけど、AN-S092 は nano SIM サイズなので、micro SIM の外枠を外してスロットに入れる。
設定が手間取ったのは、Web管理画面パスワードと SSID パスワードの設定。(説明書)
E5785 と同じ設定にしようとしたら、Web管理者画面に入れない。管理者パスワードに短いものを設定したけど、パスワードは8文字以上の制限があるようだ。ということで付属のリセットピンで工場出荷状態に初期化。
WiFiの設定も変更したけど、パスワードがはじかれる。WiFiパスワードは英数字のみ みたい…。管理者パスワードもWiFiパスワードも、設定後に使えないパスワードなら、登録時点で拒否してほしいな。ということで、再びリセットピンで工場出荷状態に初期化。英数字のみに気づくまでに、リセットピンでのリセット数回…..(x_x; スマホだとタイプミスも多いので PC で設定となった。
ということで、Amazon さんにレビューを書いておいた。設定さえちゃんとすれば便利なので高評価つけてるけど。
\
postfixの設定見直し
自宅サーバに届く迷惑メールの設定はそれなりにやってるつもりだけど、相変わらず届く。
迷惑メールの送信側も、DKIM や SPF といった迷惑メールに誤認されない対策をして送ってきている。そこで改めて postfix の設定を見直す。
RBLサイトの整理, 正引き・逆引きチェック
迷惑メール送信者のデータベース(RBL)の設定をしていたけど、all.rbl.jp, zen.spamhaus.org はサービスを停止しているようで、nslookup all.rbl.jp とかも失敗するし設定を削除。
Dynamic DNS サイトのような迷惑メールサイトからのメールを拒否するために、reject_unknown_reverse_client_hostname を設定していたけど、DKIM, SPF まで設定した迷惑メールサーバも多いので、設定をさらに厳しく reject_unknown_client_hostname に変更。
この設定を変更すると、逆引きと正引きが一致しない Dynamic DNS サイト(まさに自サイト tsaitoh.net はこの状態)からのメールを拒否することになる。しかし、迷惑メールの制限を強化したいし、身の回りの 逆引きと正引きが一致しない所からのメールは、smtpd_client_regexp で受信許可するようにしよう。
((( /etc/postfix/main.cf ))) smtpd_client_restrictions = permit_mynetworks, check_client_access regexp:/etc/postfix/smtpd_client_regexp - reject_rbl_client all.rbl.jp, # サービス停止 - reject_rbl_client zen.spamhaus.org, # サービス停止 reject_rbl_client bl.spamcop.net, - reject_unknown_reverse_client_hostname, # 逆引きだけをチェック + reject_unknown_client_hostname, # IP->name->IPのチェックあり permit
よく出来たフィッシングだな….
コロナ感染入院給付金の請求
と思いフィルタ設定をしようと “Received:”タグを確認して、送信元の IP アドレスを確認したら本物だった。
改めて、日本生命さんのサイトに”メールのリンクを使わずに”ログインして確認してみたけど、しっかり自宅サーバのメアドも登録してあった。
<重要>【三井住友カード】お取引が決済できませんでした
((( /etc/postfix/main.cf ))) smtpd_client_restrictions = permit_mynetworks, check_client_access regexp:/etc/postfix/smtpd_client_regexp : ((( /etc/postfix/smtpd_client_regexp ))) : /\.googleusercontent.com$/ REJECT
リモート監視 nagios-nrpe を使ってみる
Raspberry-Pi で WiFi スキャンをさせたいけど、警告を出すために raspberry-pi 側に nagios4 のような本格的な監視システムを入れるのは資源のムダに思えたので、軽量な監視とすべく、リモート監視用の nagios-nrpe-server を使ってみた。
メインサーバ port=5666 リモート 監視プラグイン nagios4 ----> check_nrpe ------------> nrpe ----> check_root nagios-nrpe-plugin nagios-nrpe-server
nrpe は リモートの監視プラグインを check_nrpe と nagios-nrpe-server が経由して呼出してくれる。
リモートの監視側
nagios-nrpe-server をインストールして、監視サーバからの接続を許可する。インターネット経由で監視するなら、5666 ポートが通るようにファイアウォールの設定が必要。
((( 必要パッケージのインストール ))) $ sudo aptitude install nagios-nrpe-server ((( /etc/nagios/nrpe.cfg ))) # 監視サーバからの接続を許可 allowed_hosts=127.0.0.1,::1,192.168.xx.00/24 ~~~~~~~~~~~~~~~~~(追加) ((( /etc/nagios/nrpe.d/enabled.cfg ))) # 監視するためのチェック処理を登録。nrpe.cfg から nrpe.d/*.cfg に設定を移動 command[check_root]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p / command[check_load]=/usr/lib/nagios/plugins/check_load $ARG1$ ((( /etc/default/nagios-nrpe-server ))) # 自宅内のような閉じた中でSSLが不要の場合 NRPE_OPTS="-n" ((( nagios-nrpe-server を再起動 ))) $ sudo systemctl restart nagios-nrpe-server
メインの監視サーバ側
nrpe用のプラグインをインストールすると、/etc/nagios-plugins/config/check_nrpe.cfg や /usr/lib/nagios/plugins/check_nrpe を入れてくれる。
((( 監視側にnrpe用のプラグインを追加 ))) $ sudo aptitude install nagios-nrpe-plugin # nagios or icinga はインストール済み ((( nrpe の入ったリモートが呼び出せるか確認 ))) $ /usr/lib/nagios/plugins/check_nrpe -H リモート -c check_root DISK OK - free space: / 21321 MB (74% inode=86%);| /=7363MB;23944;26937;0;29930 ((( /etc/nagios-plugins/config/check_nrpe.cfg ))) # nagios/icingaなどのcommand設定の確認 # this command runs a program $ARG1$ with no arguments and enables SSL support define command { command_name check_nrpe command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ } # this command runs a program $ARG1$ with no arguments and disables SSL support define command { command_name check_nrpe_nossl command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -n } ((( nagios4 のサービス監視に check_nrpe を呼出す設定を追加 ))) define service{ use local-service host_name リモート service_description DISK check_command check_nrpe!check_root # check_command check_nrpe_nossl!check_root # SSLなしで設定した場合 } ((( nagios4 を再起動 ))) $ sudo systemctl restart nagios4
nagios4 で監視ができるようになったので、温湿度センサーや空気品質センサーの確認も nrpe 経由に変更してみた。
catt で chromecast を制御
chromecast を Linux から制御する python script の cast_url とかを使っていたけど、もっと使いやすくなった catt というものが公開されていた。
こちらで公開されていた DLNA サーバを検出する simple-dlna-browser も便利。
$ simple-dlna-browser -L http://192.168.xx.yy:zzzzz/dms/ddd.xml (TZ-HT3500) $ catt scan Scanning Chromecasts... 192.168.xx.yy - ベッドルーム - Google Inc. Google Nest Mini 192.168.xx.yy - リビングルーム - Google Inc. Chromecast 192.168.xx.yy - 居間(google home) - Google Inc. Google Home Mini $ catt -d リビングルーム cast https://www.youtube.com/watch?v=HBSC0RDuUlQ Casting remote file https://www.youtube.com/watch?v=HBSC0RDuUlQ... Playing "DREAMS COME TRUE - うれしい!たのしい!大好き!(from DWL2007 Live Ver.)" on "リビングルーム"... $ catt -d リビングルーム stop
なんちゃってIPv6でトラブル
自宅では、IPv6 でインターネットにつながらない状態の癖に、IPv6 の運用実験として色々な設定をしている。
しかし、最近繋がらないページなどが時々出ていて、どうも IPv6 サイトが原因だと予測はしていた。
今回、病院に入っていて家に不在の時に限って、ママがゲームサイトに繋がらないと文句を言ってきた。今までは動いていたのだが、ゲームサイトにも IPv6 化が進んでいる中で、ゲームサービスが IPv6対応になったんだろうな。おかげで IPv4 しかつながらないネットワーク環境のくせに、スマホがインターネットに IPv6 で繋ごうとするのが原因。
自宅では、IPv6 対応のために、DHCPサーバで IPv6 アドレス配布の設定をしていた。しかしこれが誤解のもと。実は IPv6 アドレスの自動設定機能の radvd を動かしていて、この設定は動いていないと思っていたが、実は radvd の設定が生きていた。
このため、DHCPv6の設定を消しても、radvd が相変わらずスマホに IPv6 ルータ情報をアナウンスするため、IPv6 で外に繋がらない状態となっていた。
ということで、/etc/radvd.conf を別名で残しつつ、”sudo aptitude purge radvd” で radvd の機能を止めた。