自宅サーバは Debian/testing で運用しているけど、 "aptitude safe-upgrade"しても、大量の保留。

試しに"aptitude full-upgrade"を実行すると、nagios3 が perl-5.20 に 依存していて、 perl 関連のライブラリがこぞって保留となっている。

icingaに切り替え

nagios4 とかがあるかと思って、"aptitude search nagios"を実行すると、 pnp4nagios なるものがひっかかり、インストールをしようとすると、 "icinga" を入れようとする。モニタリングは icinga が担当しているようで、 設定ファイルもほとんど nagios と同じ。 pnp4nagios は、表示を担当するようだけど、 内部で使う mysql とかの設定が悪いのか、 動かない。 ひとまず、icinga でも状況は確認できるので、pnp4nagios はやめておく。

自宅では、室内の温度センサーが一定気温を越えたらメールさせるとか、 アホなルータが間違ってDHCPを起動させていないとか、独自チェックも させているので、 手間取るかとおもったが、無事移行ができた。

external commandが実行できない

nagios3をセッティングした時とまるっきり同じ症状だけど、監視の一時停止などを行う、 インタフェースが動かない。 設定がオフになっているのと、 処理を起動するためのパイプが入っているディレクトリの アクセス権限の問題なので、設定を変更。 この手の設定は、nagios3 を icinga に読み替えるだけなのは、nagios の fork だから、そのまんま。

(( /etc/icinga/icinga.cfg ))
check_external_commands=1
$ sudo dpkg-statoverride --update --add nagios www-data 2710 /var/lib/icinga/rw
$ sudo dpkg-statoverride --update --add nagios nagios 751 /var/lib/icinga

Debianを使っていると長年稼働させるから、古い設定ファイルで トラブルが起こることが多い。samba でもその傾向があるのか、 /etc/samba/smb.conf.ucf-dist が反映されず残ってる。

ということで、古い設定ファイルをバックアップして、 smb.conf.ucf-dist を極力触らずに設定ファイルを更新していた。

でも、いざ共有フォルダに書き込もうとしたら、書き込み失敗。 確認したら、"[homes] read only = yes"になってた。

メール録画予約で、予約メールの確認方法が pop3 で、apop か PLAIN しか使えないので、 自宅サーバ上に、pop3 / PLAIN 接続ができるようにした。 しかし、半日ほど運用していると、プロセス数がなんか多い。

"ps ax"で確認すると、"dovecot/auth -w"の量が定常的に30件ほど出てくるようになった。 何らかのプロセスがブロックしているのかと思ったら、プロセス数は増えたり減ったり。 ブロックしているなら、時間と共に増加傾向があるはず。そこで syslog を見ると、

Oct 17 16:15:05 hostname dovecot: pop3-login: Aborted login
(auth failed, 1 attempts in 20 secs): user=,
method=PLAIN, rip=37.49.224.10, lip=192.168.xx.xx,
session=<bg+4qkciNAAlMeAK>

みたいなのが、続々と表示される。攻撃相手のアカウント探しみたい。 ファイアウォールで dovecot 関連は、pop3s に限っていたとはいえ、 こういう攻撃をうけるのね。

早々に、dovecotでPLAINを禁止し、FireWallのpop3sを閉じ、メール録画予約も取りやめ。 確認のために、前述の dovecot のLOGを確認すると、どうも中国人が利用しているサーバを想定したパスワード探索をしている。

145 user=liu,
145 user=lee,
145 user=huang,
145 user=chen,
116 user=yu,
116 user=yang,
116 user=wu,
116 user=wang,
116 user=lu,
116 user=lin,
116 user=li,
116 user=cheng,

我が家のテレビやレコーダーは、 東芝に統一してあり、どちらもメールを使った 録画予約ができる。

今回改めて、下記資料を見ながら、録画予約のメールを作る Web フォームを作ってみた。

• VARDIA/レコーダのメール予約

ただ、我が家では、 朝のテレビ自動On＆曜日に応じた チャンネル設定とかしてるけど、 メール録画機能をOnにすると、 テレビがつけっぱなしか、 ping で確認できなくなった。

nmapでポートスキャンかけたけど、 常に全拒否で、電源状態を確認できそうな ネタがない。

メール録画のためのアカウント作成

メール録画機能は、指定した自分のメールアドレスにPOP3でアクセスして、 特定フォームの本文を探す方式。 しかし、最新テレビじゃないし、POP3Sとか使えず平文で読もうとするし、 認証もAPOPに対応しているけど、我が家の設定の都合上APOPは….

どうせ自宅内のメールサーバあるし、regza/テレビ用、vardia/レコーダ用の アカウントを作る。

bluetoothドングルの余っているのを、再活用しようとチャレンジ。 ただ、管理用のソフトが日進月歩なのか、CUIで操作する方法は、 参考にならない記事ばかり。(この記事もいつまで使えるやら…)

サーバで活用したいので、gnomeやkdeを使った設定も使いたくないので、 調べると、bluetooth-agent(bluez) を使ってという記事があるけど、 jessie では入っていない。

bluetoothなんちゃら…だろうと、shellの補完させると、 bluetoothctl なんていうコマンドがある。

インストールとbluetoothドングルの確認

((bluetooth関連のインストール))
$ sudo aptitude install bluetooth
$ sudo /etc/init.d/bluetooth start

次にbluetoothの認識されている状態を確認。 buffaloのメジャーなbluetoothドングルなのか、普通に認識している。

((bluetoothの認識状態))
$ sudo /etc/init.d/bluetooth status
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled;
vendor preset: enabled)
Active: active (running) since 木 2015-10-15 18:12:51 JST; 17min ago
Docs: man:bluetoothd(8)
Main PID: 9999 (bluetoothd)
Status: "Running"
CGroup: /system.slice/bluetooth.service
└─9999 /usr/lib/bluetooth/bluetoothd

bluetoothctlコマンドでペアリング

bluetooth-agent の変わりに、bluetoothctlを使う。 “[bluetooth]#” のプロンプトが出たら、様々なコマンドが対話的に使える。 “help”で命令も見れるので、見ながら適当にやってみる。

((bluetoothctl))
$ sudo bluetoothctl
[NEW] Controller 00:1B:DC:xx:xx:xx host [default]
[bluetooth]# list
Controller 00:1B:DC:xx:xx:xx host [default]
[bluetooth]# show
Controller 00:1B:DC:xx:xx:xx
Name: host
Alias: host
Class: 0x000104
Powered: yes
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile...

肝心のペアリングだけど、”pair”なんてコマンドがあるし、試してみる。 BT番号を入力したら簡単に成功。ろくにマニュアル見ていないけど、 ここまではスムーズ。

((bluetoothのペアリング))
[bluetooth]# power on   ←ドングルを使えるように
[bluetooth]# scan on    ←デバイスを探す
Discovery started
[CHG] Controller 00:1B:DC:xx:xx:xx Discovering: yes
[NEW] Device 70:3E:AC:xx:xx:xx iphone6-user
デバイスを見つけるたびに情報が表示される
[bluetooth]# scan off    ←デバイス探しを止める
[bluetooth]# pair 70:3E:AC:xx:xx:xx  ←見つけたデバイスのアドレス
:
((ここでペアリング相手にメッセージが出るのでOKを押す))
[CHG] Device 70:3E:AC:94:73:34 Paired: yes
Pairing successful    ←ペアリング成功
((ペアリングで信用登録が必要な場合))
[bluetooth]# trust 70:3E:AC:xx:xx:xx ←デバイスを信用
[bluetooth]# connect 70:3E:AC:xx:xx:xx ←デバイスを接続

再起動後にも接続するための設定

• Arch Linuxでbluetoothを使う

この記事によると、udev で対応をとるらしい。

(( /etc/udev/rules.d/10-local-bluetooth.rules ))
$ sudo vi /etc/udev/rules.d/10-local-bluetooth.rules
# Set bluetooth power up
ACTION=="add", KERNEL=="hci0″, RUN+="/usr/bin/hciconfig hci0 up"

最近Windows環境から、自宅サーバに rlogin.exe で ssh 接続しようとすると 「get msg global request hotkeys 00@openssh.com」みたいな 警告メッセージが表示されるようになった。

調べてみると、rlogin のバージョン(2.17.x)の問題っぽい。 早々に、最新の(2.19.1) に入れ替えたら問題解決。

http://nanno.dip.jp/softlib/man/rlogin/

自宅サーバ及び職場の自分用Debianサーバは、testingにて運用し、 定期的に "aptitude update ; aptitude safe-upgrade" を行っている。 でも、safe-upgrade だと、新しいパッケージが入らないままになることも多い。 このため、"aptitude full-upgrade" を行っているが、 今回は、競合パッケージがちょっと多くて、競合チェックに失敗する。

(( 定番の更新 ))
# aptitude update ; aptitude safe-upgrade
(( 不要パッケージの消去 ))
# aptitude purge `deborphan`
# aptitude install gcc-5-base libstdc++6 libgcc1 gimp gimp-data
# aptitude install aptitude kdelibs-bin libopencv-core2.4v5
# aptitude install libtag1v5-vanilla libmagick++-6.q16-5v5 libtag1v5
(( ようやくfull-upgradeでの競合チェックに成功 ))
# aptitude full-upgrade
(( 競合でtexliveが消えちゃったので再インストール ))
# aptitude install texlive-full

logrotate時の警告メッセージで下記のようなものが出ていたので、 調べてみると、squid 2.7系から3.4以降に変更の際には /etc/squid/squid.conf の修正が必要な様子。

2015/09/13 07:47:16| WARNING: (B) '::/0' is a subnetwork of (A) '::/0'
2015/09/13 07:47:16| WARNING: because of this '::/0' is ignored to keep splay tree searching predictable
2015/09/13 07:47:16| WARNING: You should probably remove '::/0' from the ACL named 'all'
2015/09/13 07:47:16| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1'
2015/09/13 07:47:16| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable
2015/09/13 07:47:16| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost'
2015/09/13 07:47:16| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1'
2015/09/13 07:47:16| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable
2015/09/13 07:47:16| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost'
2015/09/13 07:47:16| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8'
2015/09/13 07:47:16| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable
2015/09/13 07:47:16| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost'
2015/09/13 07:47:16| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
2015/09/13 07:47:16| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable
2015/09/13 07:47:16| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost'
2015/09/13 07:47:16| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
2015/09/13 07:47:16| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable
2015/09/13 07:47:16| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost'
2015/09/13 07:47:16| ERROR: Directive 'hierarchy_stoplist' is obsolete.
2015/09/13 07:47:16| ERROR: Directive 'upgrade_http0.9' is obsolete.
2015/09/13 07:47:16| ERROR: Directive 'broken_vary_encoding' is obsolete.
2015/09/13 07:47:16| ERROR: Directive 'extension_methods' is obsolete.

Warningについては、localhost とか all は、ACL を squid.con で定義しなくて良いみたいなので、 コメントアウトする。後半のErrorについても、古い設定項目なので、同様にコメントアウト。

(( /etc/squid/squid.conf ))
#Recommended minimum configuration:
- acl all src all
+ # acl all src all
# acl manager proto cache_object # Commented out on upgrade to 3.4
- acl localhost src 127.0.0.1/32
- acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
+ # acl localhost src 127.0.0.1/32
+ # acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
- hierarchy_stoplist cgi-bin ?
+ # hierarchy_stoplist cgi-bin ?
# Don't upgrade ShoutCast responses to HTTP
- acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9]
- upgrade_http0.9 deny shoutcast
+ # acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9]
+ # upgrade_http0.9 deny shoutcast
# Apache mod_gzip and mod_deflate known to be broken so don't trust
# Apache to signal ETag correctly on such responses
- acl apache rep_header Server ^Apache
- broken_vary_encoding allow apache
+ # acl apache rep_header Server ^Apache
+ # broken_vary_encoding allow apache
#  TAG: extension_methods
#       Squid only knows about standardized HTTP request methods.
#       You can add up to 20 additional "extension" methods here.
- extension_methods REPORT MERGE MKACTIVITY CHECKOUT
+ # extension_methods REPORT MERGE MKACTIVITY CHECKOUT

今朝も再びサーバが不調となった。

不調時のkernel log

改めて、不調となる時間帯の syslog, messages あたりを眺めてみると、 異常動作が始まる前に、共通して以下のようなLOGが出力されている。 どうも、kernel の cron あたりで発生。

Sep 10 09:33:50 perrine kernel: [231581.206381] cron            D ffff880077456900     0  4305   1169 0x00000000
Sep 10 09:33:50 perrine kernel: [231581.206387]  ffff880070e60050 0000000000000018 ffff8800744d2a20 ffffffff81466362
Sep 10 09:33:50 perrine kernel: [231581.206391]  ffff880072bb8000 ffffffff8185f644 ffff880070e60050 00000000ffffffff
Sep 10 09:33:50 perrine kernel: [231581.206395]  ffffffff8185f648 0000000000000074 ffffffff81571eef ffffffff8185f640
Sep 10 09:33:50 perrine kernel: [231581.206398] Call Trace:
Sep 10 09:33:50 perrine kernel: [231581.206409]  [<ffffffff81466362>] ? __kmalloc_reserve.isra.27+0x32/0x90
Sep 10 09:33:50 perrine kernel: [231581.206415]  [<ffffffff81571eef>] ? schedule+0x2f/0x80
Sep 10 09:33:50 perrine kernel: [231581.206418]  [<ffffffff8157220e>] ? schedule_preempt_disabled+0xe/0x20
Sep 10 09:33:50 perrine kernel: [231581.206422]  [<ffffffff81573df5>] ? __mutex_lock_slowpath+0x95/0x110
Sep 10 09:33:50 perrine kernel: [231581.206427]  [<ffffffff814a750b>] ? __netlink_lookup+0xab/0xe0
Sep 10 09:33:50 perrine kernel: [231581.206430]  [<ffffffff81573e8b>] ? mutex_lock+0x1b/0x30
Sep 10 09:33:50 perrine kernel: [231581.206435]  [<ffffffff81107be8>] ? audit_receive+0x18/0xa0
Sep 10 09:33:50 perrine kernel: [231581.206438]  [<ffffffff814a9847>] ? netlink_unicast+0x107/0x1a0
Sep 10 09:33:50 perrine kernel: [231581.206441]  [<ffffffff814a9dce>] ? netlink_sendmsg+0x4ee/0x610
Sep 10 09:33:50 perrine kernel: [231581.206447]  [<ffffffff8145e3bc>] ? sock_sendmsg+0x3c/0x50
Sep 10 09:33:50 perrine kernel: [231581.206451]  [<ffffffff8145e82b>] ? SYSC_sendto+0xdb/0x170
Sep 10 09:33:50 perrine kernel: [231581.206455]  [<ffffffff8145bb8a>] ? sock_alloc_file+0x9a/0x120
Sep 10 09:33:50 perrine kernel: [231581.206461]  [<ffffffff811e7a42>] ? set_close_on_exec+0x32/0x70
Sep 10 09:33:50 perrine kernel: [231581.206466]  [<ffffffff811dc5d5>] ? SyS_fcntl+0x3d5/0x600
Sep 10 09:33:50 perrine kernel: [231581.206469]  [<ffffffff8145efea>] ? SyS_socket+0x8a/0xd0
Sep 10 09:33:50 perrine kernel: [231581.206475]  [<ffffffff81576132>] ? system_call_fast_compare_end+0xc/0x6b

一応 xfs の repair も実行

最近の不調3回のうち、2回については、上記LOGの前に、XFS の unmount のメッセージも出ていた。 XFSを使っているのは、外付け USB-HDD なので、一応、fsck.xfs を実行させておく方がいいかな…
ただ、実行させたら、代わりに xfs_repair コマンドを使えとの警告。

# umount /dev/sdc1
# xfs_repair /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 1
- agno = 0
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

ひとまず、カーネルのバージョンを落とす

前述のメッセージをみるからに、kernel の問題も考えられる。 そこで、linux-image-4.1.x を使っていたが、linux-image-4.0.x にバージョンを落とす。

i A linux-image-4.0.0-2-amd64
p   linux-image-4.1.0-2-amd64

不調、治ったかな…

最初はマザーボードの不調かと思っていたけど、カーネルの問題っぽくって、バージョンを落としていたけど、 色々と新しい update を適用していたら、異常停止の症状が出ていない。 多少不安はあったけど、改めて linux-image-4.1 を入れてみた。 その後は、ひとまず安定している様子だ。