homebridgeをnodejs-18.xに更新したら動かず
nodejs の最新の 18.x が出ているようなので、Raspberry-Pi で動かしている homebridge でも適用しようと試す。
しかしながら、homebridge , homebridge-ui-x も動いてはいるけど、アクセサリ画面が表示できなくなってしまった。いろいろと更新を試したが復帰しない(すでに自宅内は google home 経由で色々と活用しているので復帰しないとすごく不便)ので、元に戻す。
nodejs をダウングレードして、nodejs-18.x に合わせて更新してしまった /usr/lib/node_modules/* が悪さする可能性も高いので、バックアップから、node_modules ディレクトリを元に戻すなど、ひと手間かかったけど、無事に設定が元通り。
はぁ、他の人の人柱の情報が出そろってからにすりゃ良かった。(x_x;;
postgreyの更新トラブル
postgrey に更新があった(1.36-5.2 ⇒ 1.37-1)ため、外部からのメールが届かなくなり、設定の変更が必要となった。
postgrey trouble
職場で動かしている WordPress の2段階認証メールを自宅サーバに転送しているが、2段階認証のメールが届かなくなった。原因は、怪しいメールは一旦拒絶することで spam を拒否してくれる postgrey がうまく機能していないと思われる。
/var/log/mail.log を見ると、下記のようなエラーで postgrey が起動していない。
May 5 16:53:15 ...: warning: problem talking to server 127.0.0.1:10023: Connection refused
エラーを探すと /var/log/syslog に以下のメッセージを残して、postgrey 起動に失敗しているので、
May 5 17:11:53 ... postgrey[974882]: Option greylist-text requires an argument
/etc/default/postgrey の POSTGREY_TEXT のオプションをコメントアウト。
((( /etc/default/postgrey ))) - POSTGREY_TEXT="" + # POSTGREY_TEXT="reject by postgrey"
しかし、この変更後も職場からのメールが reject されている。
May 5 17:19:20 ... postfix/smtpd[975541]: NOQUEUE: reject: RCPT from unknown[xxx.xxx.xxx.xxx]: 450 4.2.0 <t-saitoh@tsaitoh.net>: Recipient address rejected: reject by postgrey; from=<www-data@...> to=<...@...> ...
たぶん、職場のサーバは Azureで動かしているが、今回の更新による拒否判定が厳しくなったんだろう。仕方がないので、/etc/postgrey/whitelist_clients.local に、自分の管理している Azure サーバのIPアドレスを書き並べる
((( /etc/postgrey/whitelist_clients.local ))) xxx.xxx.xxx.xxx 職場のWordPressサーバのIPアドレス
でも、postgrey-1.37 の更新は本家の changelog を見ると 2016年 みたいだけど、debian パッケージでは随分遅れての 更新だな。手法的にも、もっと確実な、SPF とか DKIM の対応がすすんで、postgrey は時代遅れなのかな。自宅サーバでは、postgrey で reject しそうな接続元は GEOIP で SMTP 拒否しまくりだし、あまり役に立ってないかも。
postfix backward compatibility
今回のトラブルで改めて、postfix のエラーログを見ているとpostfixの再起動時に以下のようなメッセージが出ている。
May 5 19:06:07 ...: Postfix is running with backwards-compatible default settings May 5 19:06:07 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details May 5 19:06:07 ...: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
設定ファイルでは、compatibilty_level が 2 とかになっていたので、書いてある通り 3.6 に上げておく。
((( /etc/postfix/main.cf ))) compatibility_level = 3.6
icingaのWebサーバチェックの改良
自宅サーバで職場のWebサーバの動作確認を行っているけど、WordPress で MySQL が落ちた際に、Webサーバとしては動いているけど、ページが正しく表示できていないことを検出できていなかった。Webサーバに MySQL のステータスチェックをさせる方法もあるかもしれないけど、その Webサーバは自分の管理でもないし、icinga などを入れることもできない。
最近の鯖管なら、zabbix を入れるのが普通なのかもしれないけど、我が家は時代遅れなので古い古い nagios を経て 古い icinga にて運用中。
そこで、nagios-plugin の check_http には、Webサーバの応答データに特定文字が含まれるか確認する機能があるので、それを導入。
# 動作確認用のcommand を登録
define command {
command_name check_https_expect_string
command_line /usr/lib/nagios/plugins/check_http \
--ssl -H '$HOSTADDRESS$' -I '$HOSTADDRESS$' \
-s '$ARG1$'
}
# 監視対象のサーバ
define host {
host_name fnct-www
(略)
}
# HTTPS の返答を確認し、WordPressが正しく動いていれば
# 含まれていそうな文字の有無をチェック
define service {
use generic-service ;
host_name fnct-www
service_description HTTPS-EXPECT
check_command check_https_expect_string!福井工業高等専門学校
}
SwitchBot の電池交換
Access Category Password プラグイン導入
記念となる記事も BLOG に残しているけど、プライバシー的にアクセス制限をかけたいことも多い。公開状態を「パスワード保護」にするのが基本だけど、記事毎にパスワードを設定することになり、色々と面倒。
functions.php とか header.php とかを触って BASIC 認証をかける方法も紹介されているけど、メンテナンスが面倒。
プラグインを探していたら、“Access Category Password” というのが見つかる。特定のカテゴリーに属している記事にパスワードがかけられる。WordPress の管理者とか編集者などのロールに合わせてパスワード無しとすることもできる。
今回は、”hidden”というカテゴリーを作り、これをアクセス制限対象に登録してみた。今後は、見せたくない記事なら”hidden”カテゴリーに追加するだけ。見せてもいい相手には、こちらからパスワードを教えるか、WordPress のユーザに招待すればいい。
丹南ケーブルのメンテナンス2/18早朝
利用している丹南ケーブルのネットワークのメンテナンスで、02/18 01:00-05:00 にネットワーク断のアナウンス。
自宅では、ネットワークやら色々監視させているので、監視システム icinga の一時停止のスケジュール登録。
at の日時の書き方をいつも忘れるのでメモ。
$ echo "/bin/systemctl stop icinga" | sudo at 01:00 021822 $ echo "/bin/systemctl start icinga" | sudo at 05:00 021822
DNSのルートサーバ問題?
自宅では、自宅内だけの DNS を実現するために、DNSサーバ bind を動かしているけど、ブラウザで作業中にたまに DNS によるエラーでページが表示されない。
もしかして、変なところからの攻撃を防ぐために 国別のIPアドレス情報(GEOIP)を元に、接続拒否をしているのが原因かもしれない。確認を行うと、DNS ルートサーバの 中に、スウェーデン(SE)とオランダ(NL) が含まれていて、オランダが拒否リストに入ってた。
ということで、i.root-server.net(SE) , k.root-server.net(NL) を個別に許可リストに加える。
((2022-04-06))
再起動すると、ferm が動いていないのか iptables が未設定の状態になっている。確認をすると、OS起動時のエラーの中に、i-root-server.net の名前解決に失敗して、firewall 設定が途中で止まっている。DNS の設定が動いていない前段階で ferm を動かす順序なのでしかたがない。
ということで、許可リストの設定ファイルで、i.root-server.net などは IPアドレス記載に変更した。
WordPress 5.9-ja
WordPress 5.9 が新しく公開された様子。早々に、5.8.3→5.9 に更新を行う。
PHP8.1に更新
PHPのバージョンが、php7.4 をメインに使っていたけど、他のシステムで php7.4-common のモジュールの整合性が悪いので、php8.1 が出ているみたいなので、更新を行い、モジュールの相性をチェック。
((( インストールされているphp7.4系モジュールすべてを8.1でインストール )))
$ sudo aptitude install `dpkg -l | grep php7.4 | awk '{print $2}' | sed s/php7.4/php8.1/`
((( php8.1 を有効化 )))
$ sudo a2enmod php8.1
$ sudo a2dismod php7.4 # a2enmod php8.1 したら 7.4 消してくれると思ってたけど、残ってて
# systemctl restart apache2 してもエラーになるから悩んだ
((( apache2 を再起動 )))
$ sudo systemctl restart apache2
php7系からphp8系の移行による文法などの違いから、いくつかの自作 PHP プログラムが動かなくなってチョロチョロとプログラムを修正することになったけど。
改めて、プログラムを修正していると、「このプログラムなら、php7.4でも警告が出ていたはず」だけど、動いていたよなぁ…という修正点ばかり。(^_^;
ctgserver.net からのspam攻撃
自宅サーバに spam 送信の攻撃がしつこい。
確認すると、日本国内に割り当てられたIPアドレスだけど、ctgserver.net という中国系企業に割り当てられたもの。デタラメなホストを名乗って送信しようとしている。日本国内のアドレスとはいえ悪質なので、Firewall で 202.61.144.0/20 でごっそり接続拒否としておいた。
Jan 5 21:34:41 perrine postfix/smtpd[1163220]: connect from unknown[202.61.149.209] Jan 5 21:34:41 perrine postfix/smtpd[1163220]: NOQUEUE: reject: RCPT from unknown[202.61.149.209]: 450 4.7.25 Client host rejected: cannot find your hostname, [202.61.149.209]; from=<jcbjp-account-update@cnzsyc.cn> to=<xxxx@tsaitoh.net> proto=ESMTP helo= Jan 5 21:34:41 perrine postfix/smtpd[1163220]: disconnect from unknown[202.61.149.209] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6
同様の攻撃が、134.122.192.0/18 “BGP CONSULTANCY PTE LTD” からも届いている。これまた、日本国内割り当ての中国系企業。この記事を見ると同じ穴のムジナっぽい。がんがん拒否しまくろう。国内IPアドレスも汚染されてきてるよなぁ…
制限しても、すぐさま別のアドレスから同じような攻撃。調べてみると大きなアドレスブロックを持ってるな。
202.61.128.0/18 134.122.192.0/18 118.107.0.0/18
Google 検索
