xz-utils のバックドア問題
XZ形式の圧縮ファイル生成/解凍の xz-utils にバックドアが仕掛けられるというトラブルが報告されている。オープンソースで開発されているソフトで、誰かがソースコード中に悪意のあるコードを仕込んだらしい。このため、ソースでビルドされたパッケージにも影響する。xz-utils の 5.6.0, 5.6.1 が該当し、Debian でも testing / trixie などでインストールされる。
xz-utilsの確認とダウングレード Debian/trixie
確認すると、しっかりインストールされていた。
$ dpkg -l | grep xz-utils ii xz-utils 5.6.1+really5.4.5-1 amd64 XZ-format compression utilities
さすがに怖いので、安全なバージョンが出るまでダウングレードだな。
$ sudo apt install xz-utils/stable $ sudo aptitude hold xz-utils
Ubuntu 2.2 LTSは大丈夫
dpkg -l | grep xz-utils ii xz-utils 5.2.5-2ubuntu1 amd64 XZ-format compression utilities $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.4 LTS" :
具体的な情報を探すと 「vulnerableなxzがインストールされている状態で xz –version を実行するとバックドアが開いてしまうので実行するなという話だそう。」という情報があるし、インストールされているとはいえ自分自身で活用していないので “xz –version” は実行していない。というか、この記事を遡ると Debian の 5.6.1+really5.4.5-1 は、5.4.5 に戻されていて大丈夫みたいだな。ということで改めて、apt install xz-utils で、5.6.1+really5.4.5-1 が入った。5.6.1 の様に見えるけど、実は 5.4.5 。
saslauthd のトラブル
saslauthdが起動しない
メールの送信機能が動いていない。色々と調べたら、”systemctl start saslauthd” を実行しても起動しない。
正確に言うなら、systemctl が終わらない。1,2分ほど待つとタイムアウトが発生して強制終了となっている。
# systemctl start saslauthd # --- 1,2分で強制終了となる # journalctl -xeu saslauthd # journalctl で確認できるとのメッセージがあるので The job identifier is 21448. 3月 15 08:51:27 xxxx saslauthd[33874]: : master pid is: 33874 3月 15 08:51:27 xxxx saslauthd[33874]: : listening on socket: /var/spool/postfix/var/run/saslauthd/mux 3月 15 08:51:27 xxxx systemd[1]: saslauthd.service: Can't open PID file /run/saslauthd/saslauthd.pid (yet?) after start: No such file or directory 3月 15 08:52:57 xxxx systemd[1]: saslauthd.service: start operation timed out. Terminating. 3月 15 08:52:57 xxxx saslauthd[33874]: : master exited: 33874 3月 15 08:52:57 xxxx systemd[1]: saslauthd.service: Failed with result 'timeout'. ░░ Subject: Unit failed
postfix の smtp認証の設定の影響
色々調べると、こちらの記事を見つける。
postfix の中で、smtpd の起動はデフォルト(非chroot)では、/var/run/saslauthd の中にパイプなどを作る。しかし、postfix で SMTP認証を使えるように設定するための設定では、smtpd を chroot で起動するために、/etc/default/saslauthd の中の設定で、/var/spool/postfix/var/run/saslauthd を使うように指定しないといけない。
((( /etc/default/saslauthd ))) # See /usr/share/doc/sasl2-bin/README.Debian for Debian-specific information. # See the saslauthd man page and the output of 'saslauthd -h' for general # information about these options. # # Example for chroot Postfix users: "-c -m /var/spool/postfix/var/run/saslauthd" # Example for non-chroot Postfix users: "-c -m /var/run/saslauthd" # # To know if your Postfix is running chroot, check /etc/postfix/master.cf. # If it has the line "smtp inet n - y - - smtpd" or "smtp inet n - - - - smtpd" # then your Postfix is running in a chroot. # If it has the line "smtp inet n - n - - smtpd" then your Postfix is NOT # running in a chroot. OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
しかし、何らかの更新の中で 非chroot の /var/run/saslauthd を参照する設定となり、この中にパイプなどを作っても反応がないために、起動に失敗している様子。
ということで、元記事に書いてあるように、/var/spool/postfix/var/run/saslauthd を使わせるために、シンボリックリンクを設置する。saslauthd パッケージの更新で chroot 起動の判定が不十分なのではないかな。
# rm -rf /var/run/saslauthd # ln -sf /var/spool/postfix/var/run/saslauthd /var/run/saslauthd # systemctl start saslauthd
(追記) 次は Permission denied
無事に saslauthd は起動するようになったけど、次はパスワード認証が受け付けない。LOG を確認すると下記のエラーがでるようになった。
2024-03-15T11:59:10.543324+09:00 xxxxx postfix/smtpd[46317]: warning: xxxxxx[xxx.xxx.xx.xx]: SASL PLAIN authentication failed: generic failure, sasl_username=xxxx@xxxx.xxx 2024-03-15T11:59:10.560548+09:00 xxxxx postfix/smtpd[46317]: warning: SASL authentication failure: cannot connect to saslauthd server: Permission denied
これまた、調べてみたけど /var/spool/postfix/var/run/saslauthd 配下のファイルのパーミッションが原因っぽい。
配下のファイルに、下記の制限を設定して無事にメールが出せるようになった。
# chmod -R +x /var/spool/postfix/var/run/saslauthd/
muninで計測した値を参照する方法
muninで測定している値を、nagios でチェックするプラグインを作ったり、homebridge で参照する方法。
(( 最後の5分の LAST 値を参照 )) $ rrdtool fetch 測定対象-g.rrd LAST -s -5min -e now 42 1707829800: 1.5195333333e+01 1707830100: -nan
職場からの接続を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 レコードの引けないメールサーバの受入れ設定を記述する。また、接続拒否リストの生成スクリプトで、職場のアドレスを登録しないように修正する。
CCS811空気品質センサーに温湿度補正の実行
CCS811を使った空気品質センサーを使っているけど、夜になると次第に異常な値になっていく。
原因はよく掴めないままだけど、CCS811の機能の中に温湿度で補正をかける処理がある。補正といってもちょっとした程度かと思っているけど、時間経過とともに大きく変化していることから、1時間おきに温湿度補正をかけるようにプログラムを追加してみた。
色々と処理を触ってみるけど、時間が経つと大きな値が取れる状態になってしまう。倍率みたいな設定項目あるのかな…
ブレーカー落ちた
洗濯機の乾燥機能が動かなくなり、修理に来てもらって無事動いたのはいいけど、夜にブレーカーが落ちた。
自宅サーバへの被害も考え、UPS電源の電圧を APCUPSD でモニタリングしていて、電源電圧が下がると、google-home で警告メッセージが流れるようにしてあるんだが、動作せずに落ちてる。nagios4 の LOG をみると、電圧低下は検出しているけど、通知が発動していない。なんでやねん。
(2023-12-03追記)
別のタイミングでは、警告メッセージの読み上げは動いていた。夜間はスピーカ音量を落としているので、気づきにくい音になってたけど。
Switchbot Plug の制御
電気毛布が必要な時期、外出時の電源を切り忘れるのを防ぐために、昨年導入していた Switchbot Plug 。
スマホの SwitchBot アプリのタイマー機能で朝に強制オフの制御していたけど、寝る時にスイッチを入れるのは、自分が不在の時だとムダだし、homebridge や cron で制御するのも面白そう。
switchbot-utility のインストール
ということで、Raspberry-Pi に、switchbot-utility をインストール。
((( 事前にSwitchbot アプリは設定済み ))) $ sudo pip3 install switchbot-utility $ cd /usr/local/lib/python3.9/dist-packages/switchbot_utility
制御するには、Switchbot アプリのトークンと秘密鍵が必要なので、アプリを起動して「プロフィール」、「設定」の画面を開いて、「アプリバージョン」の表示を 10 回連打すると、「開発者向けオプション」を表示できる。この画面を開いてトークンとクライアントシークレットをコピーし、上記の switchbot_utility のフォルダ内に、settings.json のファイル名で保存。
Python で以下のスクリプトを実行すると、switchbot-utility で扱えるデバイスの一覧 deviceList.txt が作られる。
((( settings.json ))) // Switchbot アプリで取得したトークンとシークレットを、 // switchbot_utilitiy のフォルダに settings.json で保存しておく { "token": "xxxxx....", "secret": "yyyyy...." } ((( devicelist.py ))) // Python で以下のスクリプトを実行すると、deviceList.txt が作られる。 // 以下を devicelist.py で保存し、python3 devicelist.py で実行! from switchbot_utility.switchbot import Switchbot switchbot = Switchbot() switchbot.devicelist() ((( deviceList.txt ))) 441793xxxxxx, 電気毛布, Plug, 000000000000 C5B496xxxxxx, エアコン, Bot, 000000000000
実際に、Switchbot Plug を動かすために、下記のscriptでスイッチを制御できるようにしてみた。
#!/usr/bin/python3 # -*- mode: python; coding: utf-8; tab-width: 4 ; -*- # SwitchBot をON/OFFする import sys import time import os from switchbot_utility.switchbot_plug import SwitchbotPlug # ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~ # 制御するSwitchBot に合わせて、上記~~~ を書き換える。 sb_dir = '/usr/local/lib/python3.9/dist-packages/switchbot_utility' # Switch Bot Plug MAC ADDR # deviceList.txt 調べた MACアドレスを記入 sb_plug_macaddr = '441793xxxxxx' # コマンドライン引数プロセス名 script_file_name = sys.argv.pop( 0 ) # コマンドライン引数 -d <デバイスID> while len( sys.argv ) >= 2 and sys.argv[0] == '-d' : sys.argv.pop( 0 ) sb_plug_macaddr = sys.argv.pop( 0 ) # setting.jsonを読み込むため os.chdir( sb_dir ) # SwitchBot Plug に接続 sb_plug = SwitchbotPlug( sb_plug_macaddr ) # ~~~~~~~~~~~~~ この部分に制御対象用のコンストラクタを書けばいい if len( sys.argv ) == 0 : # 引数なしは、状態を表示 print( sb_plug.get_power() ) elif len( sys.argv ) == 1 : # status | on | off | toggle or turn arg = sys.argv.pop() if arg == 'status' : # exitでスイッチ状態を返す sys.exit( 0 if sb_plug.get_power() == 'on' else 1 ) elif arg == 'on' : sb_plug.turn_on() # ON elif arg == 'off' : sb_plug.turn_off() # OFF elif arg == 'toggle' or arg == 'turn' : # スイッチを反転 pw = sb_plug.get_power() if pw == 'on' : sb_plug.turn_off() elif pw == 'off' : sb_plug.turn_on()
このプログラムを、homebridge-cmdswitch2 の設定に加える。
{ "platform": "cmdSwitch2", "name": "cmdSwitch2", "switches": [ { "name": "電気毛布", "on_cmd": "/usr/local/bin/switchbot-plug.py on", "off_cmd": "/usr/local/bin/switchbot-plug.py off", "state_cmd": "/usr/local/bin/switchbot-plug.py status" } ] }
ということで、「OK Google, 電気毛布を点ける」でON、朝は起床時間にあわせたタイマーでOFF完成。
google-home-playerをインストール
Raspberry Pi で動かしていた homebridge だけど、nodejs.20.x が出ているとのことで、更新をかけた。しかしこの反動で、google-home-notifier が喋らなくなった。以前より google-home-notifier の内部で利用している google-tts-api のバージョンがあがると動かなくなるトラブルが発生していた。この状況下で、この後継となる google-home-player が出ているので、これを契機に乗り換え。
google-home-player のインストール
google-home-player を使うと、Google Home mini, Google Nest mini で自然なに英語や日本語をしゃべらせることができる。
$ sudo npm install -g google-home-player
Rapberry-Pi の更新で GPIO が動かない
64bit OS の arm64 で動かしている Raspberry-Pi で、rpi-update を実行したら、kernel が Linux 6.1.61-v8+ となり、自作スクリプトのいくつかが動かなくなった。原因は wiringPi や GPIO など絡んだ処理の中では、/proc/cpuinfo にアクセスして “Hardware” を取得しその値に合わせてアクセスするポートなどを切り替えているみたい。しかしながら、linux-6.x になったら /proc/cpuinfo で Hardware 情報が取れなくなったため、wiringPi, GPIO関連のプログラムが動かなくなった。
BME280 温湿度センサーを GPIO 経由から ioctl() から I2C を制御する処理に書き換え
$ ./bme280 Oops: Unable to determine board revision from /proc/cpuinfo -> No "Hardware" line -> You'd best google the error to find out why.
参考にしていたプログラムが wiringPi 経由で I2C 接続の温湿度センサー bme280 を使っていたけど、仕方がないのでプログラムを修正し、ioctl() 経由に修正。
bit 演算が多用されていて、unsigned char と char の宣言を手抜きしたら、異常値が出るようになった。char型の部分を unsigned char に修正したら、大きな値にずれる異常値はなくなった。でも、その後も時々小さな値となる異常値が発生した。どうも nagios やら munin で監視していると時々同じタイミングで bme280 の値取得の処理が起動されるようで、I2C デバイスの競合が発生していると思われた。このため、I2C デバイス /dev/i2c-* を開く際に flock() による、排他処理も追加した。
OLED ディスプレィ SSD1306 の処理を Adafruit_CircuitPython_SSD1306 に変更
Adafruit_Python_SSD1306 を使って表示させていた処理が動かなくなる。内部で WiringPi などを使っているのか “RuntimeError: Could not determine platform…” といったメッセージが出て動かなくなる。これも GPIO あたりのトラブル。調べていると Adafruit_CircuitPython_SSD1306 なら動きそう。
$ sudo pip3 install adafruit-circuitpython-ssd1306
若干のプログラム修正で動くようになった。