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

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

システム

最近の投稿

アーカイブ

カテゴリー

smartd の警告

サーバから以下のようなメールが送られてくるようになってきた。

This message was generated by the smartd daemon running on:

   host name:  perrine
   DNS domain: tsaitoh.takefu.fukui.jp

The following warning/error was logged by the smartd daemon:

Device: /dev/sda [SAT], 5 Offline uncorrectable sectors.

syslog にも記録があるとのことなので確認すると、

Oct  5 22:32:04 perrine smartd[565]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct  5 22:32:04 perrine smartd[565]: Device: /dev/sda [SAT], 5 Offline uncorrectable sectors

やばいと思いながらも /dev/sda を確認すると、古いHDDをつなげて rsync などでバックアップをとるようにしているデバイスなので、ひとまず安心。

(2022/12/08) 警告メール止まったみたい

運用の中、バックアップ用のドライブだったけど、バックアップ処理の中で利用セクタから外れたのか、警告メールが来なくなったな。

fetchmail daemon が勝手に起動

自宅サーバでは、丹南ケーブルの自分宛の spam だらけのメールを捨てるために、夜中に fetchmail を起動するようにしている。

状況

しかし、最近 「別の fetchmail が動いているのでエラー」が発生している。確認をすると、自分の ID の fetchmail が daemon にて動いている。

fetchmail --nodetach --daemon 300

よくよく調べると login 時に、 “systemctl –user start fetchmail.service” にて起動される様子。

対応

システム全体の systemctl –user での起動は、/etc/systemd/user/default.target.wants にて管理されていて、以下のようなリンクが張られている。

fetchmail.service -> /usr/lib/systemd/user/fetchmail.service

ということで、以下のコマンドで勝手に起動される fetchmail を抑止する。

$ cd /etc/systemd/user/default.target.wants
$ sudo rm fetchmail.service

正しい systemd での設定方法

今回は、こういう力任せの方法をとったけど、こちらの資料を見ると、以下のやり方が正しい方法っぽいな。試しに、リンクを元に戻して下記コマンドを実行すると、リンクを消してくれていた。

$ sudo systemctl --global disable fetchmail.service

“~/.config/systemd/user/*” にユーザ独自にサービスを登録するのなら、”systemctl –user enable oooo.service” を実行する。
“/etc/systemd/user/default.target.wants” を変更するなら “systemctl –global enable(or disable) oooo.service” を実行する。

CAA レコードが未設定で dehydrated (Let’s Encrypt) が失敗

自宅ドメインの SSL 証明には、Let’s Encrypt (実体は dehydrated) を使っているけど、CERT の有効期限の確認の処理で警告がでてきて、月に1度実施の更新でエラーを吐いているみたい。

DNS に CAA レコードが無いと失敗する

更新を実行すると、以下の表示が出ている。

ERROR: Challenge is invalid! (returned: invalid) (result: ["type"] "http-01"
:
["error","detail"]      "CAA record for tsaitoh.net prevents issuance"

Let’s Encrypt が更新する際に、ドメイン名の CAA レコードを参照しているけど、CAA レコードが正しくないために、SSL 更新に失敗している。

DNS Certification Authority Authorization とは、ドメイン名の所有者が認証局に対して、自分のドメイン名の公開鍵証明書の発行を許可するかどうかを指定できるようにするインターネットセキュリティポリシーのしくみである。(Wikipedia)

CAAレコードに letsencrypt.org を登録

自宅ドメインは、Dynamic DNS に mydns.jp を使っているので、mydns.jp の設定画面の “DOMAIN INFO” の所で、
「@ CAA 0 issue “\000”」 となっていたので、下記の設定を追加する。

Hostname Type Content Target ID
@ CAA 0 issue “letsencrypt.org” mydnsXXXXX

この設定の後、nslookup では、下記のようなデータが取れるようになった。

$ nslookup -query=CAA tsaitoh.net
tsaitoh.net     rdata_257 = 0 issue "letsencrypt.org"

他の仕事関連のドメイン名も同様の症状が発生するようになるはずなので、mydns.jp 関連の他ドメインで同様設定を追加する。

Date::Manip::MD5 is deprecated…

メールの流量モニタに一定のメールがずっと流れている記録が残ってる。

状況

確認すると、munin-cron で実行される munin-graph で以下のエラーメッセージが出ている。

Date::Manip::DM5 is deprecated and will be removed
  from the Date::Manip package starting in version 7.00 at (eval 5) line 1.

Date::Manip::MD5 パッケージは、ver 7.0 から Date::Manip から非推奨になったみたい。グラフは正常に生成されているものの、警告メッセージが5分おきに送られるのはうざい。

munin-graph と munin-cgi-graph の “Date::Manip::DM5” に関係する部分は、こんな感じ。

((( /usr/share/munin/munin-graph )))
  :
BEGIN {
    # This is needed because Date::Manip has deprecated the functional
    # interface in >= 6.x. So, we force the use of the 5.x API.
    $Date::Manip::Backend = 'DM5';

    # Double line here to avoid spurious warnings about D::M::Backend being
    # used only once.
    $Date::Manip::Backend = 'DM5';
}
use Date::Manip;
  :
((( /usr/lib/munin/cgi/munin-cgi-graph )))
  :
use IO::Handle;
BEGIN {
 no warnings;
 $Date::Manip::Backend = 'DM5';
}
use Date::Manip;
  :

対応

こちらの記事を見ると、Bug Report の中で、BEGIN {} ブロックの中を消すパッチを提案しているので、ひとまず、この2か所のBEGIN {} の範囲をコメントアウトで消すと、問題なく動いている。バグレポートも出ているので、近いうちに修正されるだろう。

usrmerge(usr-is-merged)でトラブル

いつものように “aptitude upgrade ; aptitude safe-upgrade”を実行したら、”usr-is-merged” パッケージをインストールしようとして、インストールの前処理でエラーが発生して upgrade が途中で止まってしまう。

状況と対応

関係のなさそうな他の無難なパッケージを更新し、usr-is-merged を入れようとする根源を探したら、”init-system-helper” みたい。でもこのままでは更新を継続できないので、aptitude full-upgradeを実行する。すると、“usr-is-merged” ではなく “usrmerge” パッケージをインストールすることになって、普通に更新が終わる。

# “aptitude install usrmerge” でも解消できるはず。

usrmerge とは

unix では、もともと /bin (システム必須の binary) , /usr/bin (システム運用上便利なユーザ向け binary) , /usr/local/bin (ユーザが個人的にインストールしたbinary) という使い分けをしてきたけど、最近ではパッケージインストーラが管理してくれるなか、/bin と /usr/bin の区別がほとんどなくなってきている。逆に /usr/bin 配下に binary がインストールされれば、/usr を read-only mount にできたりと利点も多いので、他の /sbin , /lib* も同様に…。ということで、usrmerge パッケージをインストールすることで /bin -> /usr/bin といったシンボリックリンクに切り替えてくれる。

# でも、そうなってくると /usr って、”ユーザ向け” という意味じゃなくなってくるよな。

usrmerge の結果として root ディレクトリを確認すると、/bin -> /usr/bin, /lib -> /usr/lib, …といったリンクが生成されていた。

$ ls -al /
lrwxrwxrwx   1 root root        7  9月 23 12:09 bin -> usr/bin
 :
lrwxrwxrwx   1 root root        7  9月 23 12:09 lib -> usr/lib
lrwxrwxrwx   1 root root        9  9月 23 12:09 lib32 -> usr/lib32
lrwxrwxrwx   1 root root        9  9月 23 12:09 lib64 -> usr/lib64
lrwxrwxrwx   1 root root       10  9月 23 12:09 libx32 -> usr/libx32
 :
lrwxrwxrwx   1 root root        8  9月 23 12:09 sbin -> usr/sbin

raspberry-pi bullseye で cec-client が動かない

最近は、google-home や Siri 経由で TVやチューナー の ON/OFF させるのに cec-client を使っているので、これが使えないと致命的。

症状

単純に apt で入った cec-client 6.0.2 では、デバイスが見つからない。(どうも 非 RPi のパッケージが入るらしい)

$ sudo aptitude install cec-client
$ echo 'scan' | cec-client -s -d 1
autodetect FAILED.
$ cec-client -l
Found devices: NONE
$ dpkg -l | grep cec
ii  cec-utils          6.0.2

バージョンを落としてみたけど、動かない。

$ sudo aptitude install cec-client/buster
$ echo 'scan' | cec-client -s -d 1
反応なし..^C でも止まらない
$ dpkg -l | grep cec
ii  cec-utils          4.0.7 

記事を漁ると bullseye では cec-client が動かないとかいう記事もあるなか、libCEC-6.0.2 を github よりインストールを行う。

github より libCEC をインストール

((( 最初に競合しそうな cec 関連を消す )))
$ sudo aptitude purge libcec4 libcec6 cec-utils

((( 資料を参考に... )))
$ sudo apt-get update
$ sudo apt-get install cmake libudev-dev libxrandr-dev python3-dev swig git

((( raspberry-pi 用の platform をインストール )))
$ cd
$ git clone https://github.com/Pulse-Eight/platform.git
$ mkdir platform/build
$ cd platform/build
$ cmake ..
$ make
$ sudo make install

((( libcec のインストール )))
$ cd
$ git clone https://github.com/Pulse-Eight/libcec.git
$ mkdir libcec/build
$ cd libcec/build
$ cmake -DRPI_INCLUDE_DIR=/opt/vc/include -DRPI_LIB_DIR=/opt/vc/lib ..
$ make -j4
$ sudo make install
$ sudo ldconfig

これが入って、ようやく cec-client が動き出す。Google Home や Siri のホームオートメーションはやっぱり便利。

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 を経由しなければ印刷できているし、そこまで頑張る気力がないな。

Google 検索

My Google   Yahoo

Microsoft

ファンサイト