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

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

システム

最近の投稿

アーカイブ

カテゴリー

ntpが正しく動かなくなった

ntp サーバが正しく動かない

NTPが正しく動いていない。nagios で、check_ntp_peer コマンドにて、NTP サーバの動作を検証しているが、

# /usr/lib/nagios/plugins/check_ntp_peer -H 127.0.0.1
NTP CRITICAL: Server not synchronized, Offset unknown|offset=0.000000s;60.000000;120.000000;

にて、同期がとれていないとのメッセージ。いろいろと、/etc/ntp.conf を触ってみるが、うまく動いていない。

ntp プロセスを確認すると、

# ps ax | grep ntp
9999 ? Ssl  0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -u 122:130

となっていて、設定ファイル /etc/ntp.conf を参照せずに、/run/ntp.conf.dhcp を読み込んでいる。この設定ファイルでは、dhclient で DHCP にて IP アドレスをもらう際に、ntp-server が指定されていたら、それを使うための設定らしい。じゃあ、この /run/ntp.conf.dhcp を作っているのはだれ?となる。

NetworkManager が原因

色々と確認したら、NetworkManager が原因のようだ。NetworkManager が管理しているデバイスだと、上記の余計な設定をしてくれるらしい。時期的には、Debian/bookworm に切り替えて、普通に upgrade したら、NetworkManager の機能が増えたんだろう。

eth0 を NetworkManager の管理から外すと無事に動き出す

ということで、NetworkManager が eth0 の設定を触らないようにさせる。

((( /etc/systemd/network/eth0.network で固定アドレスを割振る設定 )))
[Match]
Name=eth0
[Network]
Address=192.168.xx.2/24
Gateway=192.168.xx.1

((( /etc/NetworkManager/conf.d/99-unmanaged-devices.conf )))
[keyfile]
unmanaged-devices=interface-name:eth0

((( NetworkMangaerを再起動 )))
# systemctl reload NetworkManager

((( NetworkManagerの確認 )))
# nmcli device status 
DEVICE  TYPE      STATE     CONNECTION
eth0    ethernet  管理無し  --
lo      loopback  管理無し  --

((( ntpの起動状態を確認 )))
# ps ax | grep ntp
9999 ? Ssl  0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 122:130

ということで、無事に eth0 が NetworkManager の管理から外れ、ntp が正しい設定ファイル /etc/ntp.conf を読むようになった。

でも、”ps ax” を試すと、”dhclient eth0″ が動いている。どうも、IPアドレスの設定がおかしい。以前に、nmcli コマンドを試したときのゴミが残っているのかな。設定情報のファイルを編集。

(((  /etc/NetworkManager/system-connections/eth0.nmconnection )))
[connection]
id=static        <-- ここが eth0 と書かれていた。ここは、dhcp か static になるべき。
uuid=xxxxxxxxxxx
type=ethernet
interface-name=eth0
:

munin-2.0.67-2 で lock ファイルのトラブル

Debian の更新をかけたら、munin-2.0.67-2 となってから、以下のメールが定時処理で届く。

Creating lock /var/run/munin/munin-update.lock failed: Permission denied
 at /usr/share/perl5/Munin/Master/Update.pm line 127.

検索をすると、どうも 2.0.67-2 で出たトラブルで、対応中みたい。当分、様子見かな。
munin は、止めたくないしなぁ…
でも、5分毎の警告メールはうざいなぁ…

homebridge用にnode.jsの更新

家電制御用に動かしている Raspberry Pi の homebridge のために、node.js と npm の更新。

ついでに、最新の node.js を 16.3 にアップグレードしてみた。

$ sudo systemctl stop homebridge
$ sudo curl -fsSL https://deb.nodesource.com/setup_16.x | bash -
$ sudo systemctl stop homebridge
$ sudo apt-get install -y nodejs
$ sudo systemctl start homebridge
$ sudo npm update
$ sudo node -v
16.3.0
$ sudo npm -v
7.15.1

SwitchBot の制御が動かなくなり、プラグインを別の物に切り替え。

rsyslogの設定

Buffalo のルータのログをサーバに保存する設定。ルータを更新した時に、syslog 設定までやってなかった。ということで、改めて設定。

出力するファシリティは、local1 なので、以下の設定を加える。
以前に、設定した時は、/etc/rsyslog.conf を触ったけど、Debian流で /etc/rsyslog.d に local1.conf ファイルにまとめる。

サーバ側の設定

(( /etc/rsyslog.d/local1.conf ))
#
module(load="imudp")
input(type="imudp" port="514")
local1.*   /var/log/local1.log
#
(( /etc/logrotate.d/rsyslog ))
  /var/log/messages
+ /var/log/local1.log

ルータ側の設定

google home が動かなかったな…

そういえば、先日の朝とか、いつもの Google home mini に「照明つけて」とか言っても、ネットワークにつながっていないとかいって動かなかったけど、google のトラブルが原因か。

我が家では、家電制御は、Google Home mini → homebridge-gsh → homebridge だから、我が家のネットワークの問題(mydns.jpの接続トラブルで逆引き失敗することがある)で、homebridge-gsh が動かないと思っていたけど、google さんがトラブっていりゃうごかないよね。

まあ、homebridge は Home アプリで操作が普通で、”Hey Siri!” で操作できるし、記事みたいに何もできなることはないし。

サーバをspeepさせない

職場で実験用にセットアップしたサーバが、ほっておくと sleep で繋がらなくなる。

下記の設定で、sleep, suspend,hibernate 機能を停止する必要あり。

$ sudo systemctl mask sleep.target suspend.target hibernate.target

UPSがself-testでブザーとまらず

3年物のAPCのUPS APC ES 550(BE550G-JP)が、朝の5:00にブザーが鳴って止まらず。

電圧異常かと思って、電源ボタンを押したら停止。でも、サーバはシャットダウン操作してないで落ちてる。

LOGを確認すると、apcupsd の self-test 機能が動いて、バッテリーの交換時期なので、ブザーを鳴らしたみたい。マニュアルを見ると「停止条件は『電源オフ』」実は、ひと月前にも同じようにブザーが鳴って、今回は2回目。self-test の期間は、2週間に設定されているみたいなので、このままだと、また叩き起こされそう。

電源異常じゃないのならバッテリー交換とも思うけど調べると交換バッテリー7000円。前のUPSは、保持時間が多少落ちようとも無視して本来2~3年の寿命の物を5年以上使ってた。今回も劣化を無視してもう少し使いたい。

apctestでbattery dateを修正

UPS監視ソフトの apcupsd の付属ソフトに、apctest でセルフテストを直にさせようと思ったけど、上手く動かない。でも、battery の日付を書き換えるコマンドがある。寿命をだますということで、試しにバッテリー交換してないけど日付を書き換えてみた。これで、だませるかな。

(2020/12/28:追記) バッテリーが消耗していれば、battery-date を修正しても、朝の4:45に再びブザーが鳴り響き、効果なかった。(T_T;

ついでに、夜中にバッテリー警告で起こされるのもつらいので、警告音を DISABLE にできるみたい。munin で、バッテリー状況は観察してるし、自宅サーバだし「落ちてもたかがしれている状態」なので、問題ないだろう。とはいいながら、エラーが改めてでなくなるのを確認するまでは、ENABLE にしておくか。

$ sudo systemctl stop apcupsd.service
$ sudo apctest
(略)
Please select the function you want to perform.
1)  Test kill UPS power
2)  Perform self-test
3)  Read last self-test result
4)  View/Change battery date
:
Select function number: 4
Current battery date: 09/12/2016
Enter new battery date (MM/DD/YYYY), blank to quit: 09/12/2020
:
6)  View/Change alarm behavior
:
Select function number: 6
Current alarm setting: DISABLED
Press...
 E to Enable alarms
 D to Disable alarms
 Q to Quit with no changes
Your choice: Select function: q

apcupsd.conf の修正

(2020/12/28) 何らかの selft-test と思って、バッテリー日付の修正を試したが効果が無いので、改めて、正統な selft-test 機能を止める方法。

(( /etc/apcupsd/apcupsd.conf ))
# Self test interval in hours 336=2 weeks, 168=1 week, ON=at power on
# SELFTEST 336 168 ON OFF  (default = 336)
SELFTEST OFF

homebridgeの一部が不具合

便利に使っている音声制御機能、しかし昨日から照明が消えない。google-home ではなく、元の Apple の Homeアプリで動かすと、アイコンに ! マークが付いている。ブラウザのリモコン機能は動くので、赤外線の光が届かないのかと思って気づくのが遅れた。(ブラウザ版は raspberry-pi でなく、自宅サーバで動いている)

原因は、raspberry-pi を stretch から buster に更新して、python の設定がおかしくなったみたい。

$ /usr/local/bin/broadlink bed-light power
Traceback (most recent call last):
  File "/usr/local/etc/python-broadlink/cli/broadlink_cli", line 8, in <module>
    import broadlink
ModuleNotFoundError: No module named 'broadlink'

しかたがないので、python-broadlink を入れ直し。default の python が 2.x 系か 3.x 系かの違いが原因のようなので、明示的に python3 系でインストール。

$ sudo install python3-dev python3-pip
$ sudo pip3 install broadlink

Raspberry Pi buster 更新でトラブル

自宅の Raspberry-Pi を buster に更新してみた。

定番の /etc/apt/sources.list の stretch を buster に書き換えて、

$ sudo aptitude update ; sudo aptitude safe-upgrade
大量にインストール...
$ sudo reboot

しかし、起動時に eth0 も認識せずに、emergency mode になってしまった。

root パスワードでログインし、手作業で eth0 を認識させて…。
原因としては、raspi-copies-and-fills が原因のようなので、削除。

$ sudo aptitude purge raspi-copies-and-fills

bind9でfilter-aaaaがpluginになる

自宅サーバを使っていて、raspberry-pi の更新をかけていたら、IPv6アドレスにつながらないトラブル発生。

我が家では、上流が IPv4-only だけど、自宅内の機器間のに IPv6 も使えるようにしている。このため、DNS の設定では、bind9 に、filter-aaaa-on-v4 の設定を加え、IPv4 の機器からの問い合わせには、IPv4 のみを返答することで、対応していた。

しかし、改めて “nslookup www.google.com 192.168.xx.xx” を実行したら、IPv4からの問い合わせの癖に、しっかり IPv6 が返ってきている。

調べてみると、bind9 (9.14)から filter-aaaa 機能は plugin になるみたい。んで、自宅サーバは 9.11→9.16 により filter-aaaa がoffになったのが原因…と思ったけど、syslog をみると “–enable-filter-aaaa”付きでcompileされてるし、”option ‘filter-aaaa-on-v4’ is obsolete and should be removed” と表示されてるから、現状では、まだ使えているはず。

ひとまず IPv6 オフ

ラズバイは、ひとまず下記の設定で、IPv6 をオフにしておく。

$ sudo /etc/sysctl.conf

((下記を追加))
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

$ sudo sysctl -p

これは、IPv6 が戻ったら、元に戻そう。

bind9 に plugin の filter-aaaa 設定

plugin になったら、下記のような設定をするようだけど、うまくいかないので近日中に要対応。

$ sudo vi /etc/bind/named.conf.options

plugin query "/usr/lib/x86_64-linux-gnu/named/filter-aaaa.so" {
    filter-aaaa-on-v4 yes ;
    filter-aaaa-on-v6 yes ;
    filter-aaaa { any ; }
} ;

Google 検索

My Google   Yahoo

Microsoft

ファンサイト