ホーム » コンピュータ » Linux » Debian (ページ 4)

Debian」カテゴリーアーカイブ

システム

最近の投稿

  • 洗濯槽クリーニング
    洗濯機、エラー停止の履歴で警告だす機能があったのか。ということで洗濯槽クリーニング開始。 […]
  • どあっぷ
  • 呼んだか?
  • テレビっ子
    部屋の模様替えをしたら、テレビ台に上りやすくなったようで、テレビで遊ぶようになった。 […]
  • Debian/trixie 更新が頻繁
    自宅サーバは、Debian/testing(trixie) で動かしているけど、この10日ほどは apt […]

アーカイブ

カテゴリー

raspberry-pi を buster から bullseye

Raspberry-Pi も長く運用してこまめに更新はかけているけど、Debian のバージョンとしては buster(10) もoldstable になっているので、bullseye(11) への更新をかける。

/etc/apt/souces.list.d に bullseye のファイルを追加し、”aptitude update ; aptitude full-upgrade”を実行。

時間はかかったけど、普通に更新が終わった。

inetutils-inetd でトラブル

自宅では、Raspberry-Pi に接続した温湿度センサーBME280 の結果を、メインマシンで参照させるために、inetd から BME280 を読み出すプログラムを実行している。しかし、更新後に温湿度が取れなくなる。tail /var/log/syslog を実行すると、

... inetd[3470]: cannot execute /.../bme280: Bad address

といったエラーが記録されている。原因を調べると、inetutils-inetd 2.0 では、組み込まれている libwrap により、/etc/hosts.allow にて接続許可されているかを確認するようになったみたい。そこで、以下を追加する。

((( /etc/hosts.allow )))
+ ALL: ::1
+ ALL: 127.0.0.1
+ ALL: 192.168.XX.XX/24

((( inetd を再起動 )))
# ps ax | grep inetd
# kill -HUP <<inetdのPID>>

再起動をすると、Bad address のエラーが再び発生。”/etc/init.d/inetutils-inetd stop”,”/etc/inetd.inetutils-inetd start”を行うと、Bad address が発生、”kill -HUP (inetdのPID)” を行うと、エラーが消える。意味不明状態。

なんとなく inetutils-inetd のバグのような感じに思えたので、inetd から xinetd に切り替えたら、bme280 の機能が無事に動く様になった。

eRemote mini も動かない

broadlink のモジュールが無いと言われるので、改めてインストール。

$ sudo pip3 install broadlink

eRemote mini による赤外線リモコン関係のスクリプトは、これで動き出す。

でも一番の問題は、cec-client が動かなくなる… (x_x;

nagios4 をインストール

icinga が最新パッケージではサポートされていないので、icinga2 や zabbix をインストールしようとしたけど、データベースの初期化やらが面倒で上手く動かせていない。でも改めて確認したら、nagios3 から 更新しようとしたけど一度諦めた nagios4 のパッケージがインストールしやすくなっていた。しかもDebian12(bookworm)でも使える。

もともと、icinga は nagios からの派生だし、nagios3時代の名残りのファイルも残ってたし、設定ファイルのそれなりの変更は必要だったけど、監視コマンドなどの設定はそのまま流用できた。

設定ではまったこと

設定がそれなりに完成したけど、最初警告メールが飛ばずに悩んだ。

原因は、サービスの設定ファイルのテンプレート generic-service だった。いい加減な設定でメールが飛ぶのを防ぐために、templates.cfg で設定している generic-host や generic-service をそのままサービス監視の定義に使うと、テンプレートの設定の generic-service の定義の最後についている “register 0” によって、これはテンプレートだから…ということで、通知などの機能が動かない様になっている。

そこで generic-service から派生させた local-service などを使うべき。

# ダメなサービス定義
define service{
        use                     generic-service    ; Name of service template to use
        host_name               localhost
        :
}
# 有効なサービス定義
define service{
        use                     local-service    ; Name of service template to use
        host_name               localhost
        :
}

もう少し調整したいところもあるけど、ひとまず使えるようになってきた。

mysql5.6からmariadb10.6の更新

事の始まりは、職場で管理しているサーバに、サーバ監視ソフト icinga を入れたいけど、新しくセットアップしたサーバなので、古い icinga1 が使えず icinga2 を入れたかった。しかし上手くいかないので、自宅サーバで検証してから….ということで、自宅サーバに icinga2 を入れようとしたら、mysql-5.6 では古いみたいで、新しい データベースサーバを入れようとして、これで自宅サーバの wordpress が動かなくなって四苦八苦。

 

mysqlのバージョンアップ

mysql のバージョンを上げようと、ダメだったら元に戻せばいいや… と安易に考え、mysql-server-8.0 に上げる。しかし、mysql が起動しなくなった。どうも、mysql 5.6 → 5.7 → 8.0 と上げないと構成の違いで起動しなくなるみたい。でも、自宅サーバで wordpress が動かなくなるのは不便なので、ひとまず mysql-5.6 に戻そうとしたら….. 5.6 は古すぎて元のパッケージがインストールできなくなってた。(x_x;

# wordpress のトラブルを怖がって、データベースパッケージの更新を手抜きしていたのが悪い。

mariadb-10.6 への移行で文字化け

しかたがないので、商用パッケージに移行している mysql ではなく、その無償版ブランチの mariadb に移行させた。しかし、こんどは文字化け。utf8 を DB 内部での保存方法の問題(utf8mb3→utf8mb4)みたい。

mysql-community-5.6 のインストールもダメ

これまた不便なので、一時的に mysql の本家から mysql-5.6 をインストールしてみたが、パッケージ依存が色々発生したようで、これまた入れるのにひと手間。んで、ようやく入ったと思ったら、起動しない。(T_T;

mariadb-10.6 再チャレンジで成功

んで、あーだこーだと色々がんばって、最終的には mariadb-10.6 でようやく動くようになった。最終的な教訓は、mysql と mariadb だけど、debian でのアップグレードなら、文字コード問題は発生しないように、古い utf8 設定のデータベースは、utf8mb3 設定にしてくれたみたいで、何も変更の必要はなかった。下手なバックアップからのリカバリーで文字コードが変になったみたい。普通に、mysql5.6 のバックアップで /var/lib/mysql を総復旧かけて元通りになった。 mysql8.0, mysql-community-5.7 の悪あがきは、無駄な一苦労だった。

んで、何がしたかったんだっけ…. icinga2 を入れるんだ! でも、今日はもういいや。

追記:データベースの破損とバックアップからのリカバリー

ひとまずの修復が終わったと思って、mariadb への更新に合わせ、データベースの文字コード問題 utf8mb3 から utf8mb4 の変更とおもって、データベースのフルバックアップをしようと思ったらエラーがでる。どうも、色々と作業をしていたら、データベースの一部ファイルが壊れているみたい。

今回の作業直前にバックアップしたファイルからリカバーを行おうとしたけど、エラーがでて復旧に失敗する。

しかたがないので、/var フォルダの tar バックアップから復旧を行う。2週間ほど前のバックアップなので、ちょっと記事が消えたかもしれないけど、しかたがないな。

$ sudo systemctl stop mariadb
$ sudo tar zxvf /...PATH.../var.tar.gz -C / var/lib/mysql
$ sudo systemctl start mariadb

LinuxからEP-706A印刷でlsb 3.2が無い

自宅では、すでに古くなった EPSON の EP-706A を使っているが、導入当初は Linux からの印刷環境は簡単に導入できていた。

しかしながら最近、家族のノートパソコンから印刷できないとのクレーム。ドライバのインストールとか簡単に…と、Windows の プリンタ共有で設定していたもの。ひとまずは、ノートパソコンに直接プリンタを使うように再設定してもらったものの、Linuxからの印刷はできた方が便利。

改めて確認すると、2022 にドライバの更新などもされているようなので、epson-inkjet-printer-201307j_1.0.0-1lsb3.2_amd64.deb, epson-inkjet-printer-escpr_1.7.18-1lsb3.2_amd64.deb, epson-printer-utility_1.1.1-1lsb3.2_amd64.deb をダウンロードしてインストールを行うが、lsb 3.2 以上が必要とのエラーメッセージが表示される。

他の人の事例の情報では、Ubuntu では大丈夫なようだが、Debian では lsb の取り扱いが変更となって、私と同じような lsb 3.2 が必要といったメッセージで使えなくなっている様子。今までは使えていたので、他のOSの更新の中で lsb-core(3.2?) などが削除された様子。無理やり古い lsb をインストールしている事例も報告されているけど、Linux を経由しなければ印刷できているし、そこまで頑張る気力がないな。

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!福井工業高等専門学校
    }

 

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でも警告が出ていたはず」だけど、動いていたよなぁ…という修正点ばかり。(^_^;

逆引きできないホストからのメール拒否

自宅サーバのメールに、よくできた偽装メールが届く。

国別IPアドレスで接続制限しているから、それなりに拒否しているはずだが、今回の JCB を語った偽装メールは、From: が *.cn で、ホスト名は逆引きできない、国ドメインではアメリカの IP アドレスだった。

どちらにしろ、我が家に *.cn からのメールが届く段階でヤバい。

ということで、逆引きできないホストからの接続自体怪しいので、smtpd_client_restriction に、reject_unknown_client を加える。

さらに smtpd_sender_restrictions を追加。

# SMTP接続相手がRBL登録されていれば受け取らない
smtpd_client_restrictions = permit_mynetworks,
                reject_rbl_client bl.spamcop.net,
                reject_rbl_client all.rbl.jp,
                reject_unknown_client,
                permit

# 送信者が怪しいものは拒否
smtpd_sender_restrictions = permit_mynetworks,
                reject_non_fqdn_sender,
                reject_invalid_hostname,
                reject_unknown_sender_domain

raspberry-pi のディスク容量増

自宅内の色々な処理(温湿度モニタリング, 家電リモコン制御, homebridge)をさせている、Raspberry-Pi のディスク容量(8GB) の容量が不足してきた。大した処理はしていないし、不要なパッケージは消していたけど、homebridge などを使っていたりで、ギリギリになってきた。

Raspberry Pi の SDD交換&拡張

しかたがないので、32GB SDD を買ってきて、イメージファイルでコピーを行う。

((( 元のraspberry-piのイメージ吸い出し )))
$ sudo dd bs=4M if=/dev/sdd of=~/rpi.img
((( 新しいSDDにイメージを書き戻し )))
$ sudo dd bs=4M if=~/rpi.img of=/dev/sdd
((( 新しいSDDでraspberry-piを起動し ))) 
$ sudo raspi-config --expand-rootfs

Google 検索

My Google   Yahoo

Microsoft

ファンサイト