Category: Raspberry Pi

LogWatch 7.6 メールが来ない(解決)

LogWatchの7.6をインストールしたのですが，cron.dailyで飛ばしているlogwatchからメールが来ません．

ちゃんと，パッケージ内にある “README” の通りにしたのですが，結論的にはそれが間違いでした．

“README” には，

ln -s /usr/share/logwatch/scripts/logwatch.pl /etc/cron.daily/0logwatch

とするように書いてありその通りにしていましたが，これだと/etc/logwatch/conf/logwatch.confは空なので，/usr/share/logwatch/default.conf のまま，logwatch.plが実行されます．それではOutputはstdoutになってますから，いくら待ってもメールは来ません．

LogWatch 7.4.xでちゃんとメールが来ていた旧システムの設定を調べたところ，/etc/cron.daily/0logwatchはsymlinkではなくて，"--output=mail"というオプションを付けてlogwatch.plを実行するscriptになってます．

このスクリプトは配布パッケージのscheduler内のlogwatch.cronです．特に “README” 内では何も触れてないです😓

もちろん，/etc/logwatch/conf/logwatch.confに，

output=mail

と書く方法もありますが，これだとテストなどで手動でlogwatch(.pl)を動かす度にメールが送られて，ややスマートさに欠けます．

とはいえ，LogWatchからちゃんとメールが来るようになったら手動でlogwatchを起動する必要性も低いので，上記の設定をした上で，手で起動する時は，

--output=stdout

というオプションを付けてlogwatchを動かせば良いだけかもしれません．

LogWatch 7.6

そういえば，SlackwareARM 15.0のサーバーにまだLogWatchをインストールしていないことを思い出して，インストールすることにしました．前のOS (SlackwareARM 14.2) の時には，LogWatch 7.4.3 をインストールしていましたが，現在は7.6が最新版です．

手でインストールしてもいいのですが，SlackBuildsに用意されているので，

sbopkg -i logwatch

でインストールしてみました．試しに，/etc/cron.daily/0logwatchを走らせてみると，

/bin/sh: warning: shell level (1000) too high, resetting to 1

というメッセージが繰り返し出て，しまいにはsshdがこけてしまったのか，sshによる接続が切られてしまいました．

上記メッセージは，繰り返しshが呼ばれた時に起こるそうです．なんか，SlackBuilds提供のLogWatchインストールのためのスクリプトか，あるいは起動のためのスクリプトがバグっているようです．

そこで，removepkgしてから，手動でインストールをしました．インストールの仕方はソースパッケージの “README” に書いてあります．

手動で動かしたところ，コンソールにログのサマリーが出て，正常終了しました．しばらくcronで飛ばして様子を見ます．

関連記事

1日1回．

sshdのパスワード認証を不可にする

これは，OpenSSHのdaemonを使っている場合，通常は /etc/ssh/sshd_config 内で，

PasswordAuthentication  no

とすることで可能です．しかし，Slackware (64, ARMも)では，PAMの認証を使用していて，上記のオプションだけではパスワード認証をしてしまいます．

パスワード認証を不可にする場合は，

ChallengeResponseAuthentication no

を追記する必要があります．

参考ページ

このオプションについては，Slackware (64, ARMも) 15.0のデフォルトの sshd_config では一切触れられていない．

サーバーをガチャンと切り替えてみました

切り替えてみました．httpdのサービスのうち，WordPressは大丈夫なようです．

これより後，めんどくさいのでカテゴリーは，LinuxとNetwork，Raspberry Piくらいにします．

また，あまりに詳しい作業内容については，セキュリティー上の問題もあるので書きません．

1度サーバーをガチャンと切り替えてみます (2) 準備に手間取ってます

4月8日頃にガチャンと切り替える予定

2022年4月6日(水)の午前中に，ガチャンと切り替えようかと思いましたが，肝心なBIND (named)の設定がまだと気がつき，着手しましたが，難航しています．

もともとBINDのことはあんまり理解してないまま使ってきてました．解ってないのにいろいろ過去の複雑な事情が設定に盛りこまれています．

BINDもセキュリティーの事情からバージョンが上がる度にそういう曖昧さが許されなくなってきているようで，Slackware 14.xで動いていた設定をそのままコピーしても，エラーが出て動いてくれませんでした．

ということで，1, 2日かけて，BINDの設定をチューニングしてから，いよいよガチャンと切り替えます．

追記: とりあえずBIND動きました

BIND (named)の設定のエラーは，メッセージを見ながら，理解していないなりに😓 直して，エラーが出なくなりました．

しかし，システムを起動しても，namedもntpdも動いていない．前のシステムの起動手順などを見てみても，特に変わらないのですが．

なんとなく勘で，システムの時間が設定されていないとnamedが動かず，namedが動いていないから，ntpdがサーバーのipアドレスを取得できなくて動かないのではないか，と当たりを付けました．

一番の問題は，Raspberry Pi Model Bシリーズが，バッテリーにより駆動されるhardware clockを持っていないことです．起動時に何もしないと，1970年1月1日から始まってしまいます．

もともとの起動順は，rc.Mから呼ばれたrc.inet2によって，rc.bindがスタートして，そのあと，rc.Mの少し後でrc.ntpdが起動されます．これでしばらくするとclockが同期しますが，少し時間がかかるので，ntpd起動の前に，

/usr/sbin/ntpdate 0.pool.ntp.org

を実行するように，rc.ntpdに追加してあります．

SlackwareARM 14.xではこれで問題ありませんでした．つまり，システムの時間が1970年1月1日でもnamedは起動して，その後に起動するntpdのサーバー名を解決してくれます．しかし，SlackwareARM 15.0付属のBIND 9.16.xでは，システムの時間がめちゃくちゃだと，namedが居座らずに異常終了してしまいます．

そして，ntpdが時間サーバーのipアドレスを解決できずにやはり異常終了してしまう．

「ニワトリが先かたまごが先か」問題です．

仕方がないので，0.pool.ntp.orgでたまたま表示される1つのipアドレス（仮にnn.nn.nn.nn）を使い，rc.Mの中のrc.inet2起動の前に，

/usr/sbin/ntpdate  nn.nn.nn.nn

を書いて，解決しました．poolなのに，固定的に使うのは趣旨に反すると思いますが，起動時の一回だけだから勘弁しもらいましょう．

動けばいいのだ™
ntpdate実行時も．