さてようやく最後。今回のサーバ引っ越しでLinuxも色々と変わったんだなと実感。特にデーモン系サービスの制御が全然違うのに戸惑ってしまった。
systemctl (サービス)
これもなかなか馴染めない。デーモンは全て /etc/init.d/ の下にあって、そこで start だの restart をすればよいというのが身に付いちゃっているので、なかなか systemclt と手が動かない。
さらに、サービスの自動起動は chkconfig で設定するもんだと体が覚えているので、なかなか systemclt enable/disable というのも出てこない。
そんな中でも、一体全部でどんなサービスが動いているのかを列挙するコマンドが分からなくて四苦八苦。
$ systemctl list-units --type=service動いている/いないに関わらず、全てのサービスを列挙するのは以下。
$ systemctl list-unit-files --type=serviceufw (ファイアーウォール)
メール関係をインストールした段階でファイアーウォールを導入。今までは iptables を使っていたのだが、ufw の方が簡単に使えるらしい。
ということで導入してハマりまくったのは ufw のせいだ。その1 にもあるEchonet-Liteが全然動かない。数時間すったもんだした挙句、ファイアーウォールの穴あけを忘れていたことに気づいたときには膝から崩れ落ちた。
因みに現状は以下の通り。外部との壁になっているルーターのファイアーウォールがあるので、ここで設定しなくても外側からはほとんどのポートは塞がれているのだが、最近はスマホ経由で内側から・・・というのもなくもないので、余計なポートは閉じておくに越したことはない。
全部晒すわけにはいかないので、一部だけ覚書として以下に記す。
53 dns ALLOW 192.168.0.0/24
67/udp dhcp ALLOW 192.168.0.0/24
80/tcp http ALLOW Anywhere
110 pop3 ALLOW 192.168.0.0/24
137 samba ALLOW 192.168.0.0/24
138 samba ALLOW 192.168.0.0/24
139 samba ALLOW 192.168.0.0/24
443/tcp https ALLOW Anywhere
445 samba ALLOW 192.168.0.0/24
995/tcp pop3s ALLOW 192.168.0.0/24
3306 mysql ALLOW 192.168.0.0/24
3610 echonet ALLOW 192.168.0.0/24
2049 nfs ALLOW 192.168.0.0/24
9090 cockpit ALLOW 192.168.0.0/24
50500 gerbera ALLOW 192.168.0.0/24
お休み中はお静かに
テレビ番組や映画のmp4ファイルが保存されている大容量のUSB HDDが繋がっているのだが、就寝時のシーンとしている中でやはりHDDの駆動音が気になる。
TBS放送時代の古いトムとジェリーを知っている人は、間に放送されていた、このエピソード”冬眠中はお静かに”を思い出すかもしれないが、正に「やかましい！ 静かにしろ！ ノックするのに音を立てるな！ ワシは眠いんだ！ いいか！音を立てるなよ！」状態なのである。
以前のサーバでは機械的に午前1時を過ぎるとUSBのパワーを落とし、午前6時にサーバの再起動ということをしていた(なぜかUSBのパワーをOnにしても再接続されなかったため)。
まず、USBデバイスの階層を調べる。
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 2: Dev 8, If 0, Class=Mass Storage, Driver=uas, 5000M
|__ Port 4: Dev 9, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12MBus02の下のPort1のUSBハブに繋がっている2台のMass StorageがターゲットとなるUSB HDDだ。
(ちなみにPort2はOS本体がインストールされているメインストレージのSATA SSD)
以下のコマンドででBus02-Port1から下のUSBを切り離す。
$ /usr/bin/echo -n "2-1" > /sys/bus/usb/drivers/usb/unbindうまく行った。では前のサーバでうまく行かなかった再接続はどうか。
$ /usr/bin/echo -n "2-1" > /sys/bus/usb/drivers/usb/bindお、ちゃんと再接続してUSB HDDが見える！ということで、cron 用にコマンド usb_down と usb_up を作成しておく。DLNA Gerberaのサービスを止め、Sambaを外し、アンマウントしてからUSBを切り離す。
/home/cronjob/usb_down
!/bin/sh
/usr/sbin/service gerbera stop
/usr/bin/systemctl stop nmbd smbd
/usr/bin/umount -f /media/hdd2
/usr/bin/umount -f /media/hdd3
/usr/bin/sleep 30
/usr/bin/echo -n "2-1" > /sys/bus/usb/drivers/usb/unbind
USBの接続はその逆のシーケンスを辿る。
/home/cronjob/usb_up
#!/bin/sh
/usr/bin/echo -n "2-1" > /sys/bus/usb/drivers/usb/bind
/usr/bin/sleep 30
/usr/bin/mount /media/hdd2
/usr/bin/mount /media/hdd3
/usr/sbin/service gerbera start
/usr/bin/systemctl start nmbd smbd
と、ここまでやっていて、ふとHDDのスピンダウンがあったのを思い出した。前のサーバの時はスピンダウンしても、何かが定期的にHDDアクセスしていたのか、数分もすると必ずスピンアップし、色々と調べたが誰が犯人なのか良く分からなくなり諦めていた。
今回、HDDのスピンダウンを試してみたらうまく行ってしまった。なんだ、usb_down も usb_up も何も要らなかったんだ。
結局最新の usb_down は以下のようになっており、アクセスすれば勝手にスピンアップするので up 相当のスクリプトは不要だ。
/home/cronjob/usb_down
/usr/bin/sdparm -r --command=stop /dev/sdb
/usr/bin/sdparm -r --command=stop /dev/sdc
まだ何かのはずみでアクセスが行くようなので、午前0時、1時、2時に cron でこのスクリプトを呼び出している。
以上で今回のサーバ構築は終了だ。それにしても6～7年の間に、Linuxも随分変わったのだなと実感。しばらくは、この状態で様子を見ようと思う。
にしても疲れたな。