「Debian」タグアーカイブ

QNAP NASとLinux(Debian Buster)を1台のUPSに連動させる

基本的な内容はSynologyのNASと変わりません。
今回は相違点のみ書きますので、詳しくは以前のSynologyの記事を参考にしてください。

Synology NASとLinux(Debian Buster)を1台のUPSに連動させる その1
Synology NASとLinux(Debian Buster)を1台のUPSに連動させる その2

QNAP TS-673に繋いだUPS情報のネットワーク共有設定をします。

IPアドレスには連動させたいPCのIPを指定して、TS-673にUPS情報を取得しにくるのを許可します。

TS-673のupsmon.confは以下の場所にありました。
/etc/default_config/ups/upsmon.conf

upsmon.confの中身を覗くと
MONITOR qnapups@localhost 1 admin 123456 masterという記述がありました。

ユーザー名:admin
パスワード:123456
で接続すればOKです。

ちなみに@前の文字もupsではなくqnapupsになっているので、NASのIPを192.168.1.100と仮定すると、Debian側の/etc/nut/upsmon.confの接続部分の記述は以下のように書く必要があります。

MONITOR qnapups@192.168.1.100 1 admin 123456 slave

これで無事にQNAPのNASともUPS情報のネットワーク連携ができました。

Synology NASとLinux(Debian Buster)を1台のUPSに連動させる その2

Synology NASとLinux(Debian Buster)を1台のUPSに連動させる その1の続きとなります。

SynologyのDS1618+はUPSのネットワーク共有でNUTというアプリを裏で動かしています。
NUTはNetwork UPS Toolsのことで、Linuxで利用可能なパッケージとなっています。
DS1618+にSSHで接続して設定を確認してみました。

/usr/syno/etc/ups/upsmon.confの中身を覗くと
MONITOR ups@localhost 1 monuser secret masterという記述がありました。

ユーザー名:monuser
パスワード:secret
で接続すればいけそうです。

早速、連携したいDebianにNUTパッケージをインストールします。
# apt install nut
※この記事を書いている時点でのバージョンは2.7.4-8となります。

NUTの細かい内容まで説明は難しいので、詳しく知りたい方はNUTのオフィシャルドキュメントを読んでみてください。
細かいところまで読むと結構勉強になりす。

ということで、設定内容だけ抜粋です。

/etc/nut/upsmon.conf
このファイルが基本的な設定ファイルとなります。
※NASのIPを192.168.1.100と仮定して書いていますので、ご自身の環境に置き換えてください。
このファイルでNASを見に行くという設定を行います。
DS1618+にSSHでログインして確認したIDとPASSを使用します。
SynologyのNAS同士のUPS連携は可能になっていますので、DS1618+だけでなく別の機種でも同じ設定になっていると思われます。

MONITOR ups@192.168.1.100 1 monuser secret slave
MINSUPPLIES 1
SHUTDOWNCMD “/sbin/shutdown -h +0”
NOTIFYCMD /sbin/upssched
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower

NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC

RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

MONITOR行はNASではmasterになっていましたが、Debianでは見に行く側なのでslaveとなります。
NOTIFYFLAGの行はUPSのステータス変更時に何を行うかを設定する行となります。
他にも色々なステータスがありますが、今回はこの3つのみを設定します。

ONLINE:正常運転時のステータスです
ONBATT:バッテリー運転時のステータスです
LOWBATT:バッテリーが残り僅かになった時のステータスです

後ろのSYSLOG+WALL+EXECの意味は以下となっています。
SYSLOG:syslogにログとして書き込みます
WALL:全ユーザーのターミナルにメッセージを書き込みます
EXEC:後述するNOTIFYCMDが実行されます

NOTIFYCMDに関する設定ファイルは以下となります。
/etc/nut/upssched.conf

CMDSCRIPT /bin/upssched-cmd
PIPEFN /var/run/nut/upssched.pipe
LOCKFN /var/run/nut/upssched.lock

AT ONBATT * START-TIMER upsgone 120
AT ONLINE * CANCEL-TIMER upsgone
AT LOWBATT * START-TIMER upsgone 5

実際に実行するスクリプトをCMDSCRIPTで指定しています。
AT行はステータスを受け取った際にスクリプトに対する動きを設定しています。
AT_ステータス_ホストの設定_スクリプトに対する実行タイプの指定_スクリプトに渡す引数_タイマーの場合は秒数
となります。

AT ONBATT * START-TIMER upsgone 120を例にとると
バッテリーのステータスになったら、全てのホストの設定で、タイマーを開始、スクリプトにupsgoneを渡し、タイマーの時間は120秒
となります。
START-TIMERの部分は
CANCEL-TIMERがタイマーをキャンセル
EXECUTEだとスクリプトを実行となります。
今回の設定ではLOWBATTの場合でもタイマー5秒としていますが、即時実行したければEXECUTEでもいいかと思います。

最後に実際に実行されるスクリプトを編集します。
/bin/upssched-cmd

case $1 in
        upsgone)
                logger -t upssched-cmd "The UPS has been gone for awhile"
                upsmon -c fsd
                ;;
        lowbatt)
                logger -t upssched-cmd "The UPS became lowbattery"
                upsmon -c fsd
                ;;
        *)
                logger -t upssched-cmd "Unrecognized command: $1"
                ;;
esac

ONBATT、LOWBATT共にやっていることは同じで
upsmon -c fsd
というコマンドでシャットダウンを行っています。
その上の行はログ出力なので文字が違うだけで、その下のコマンドは同じになっています。

設定が終わったら最終的に
# systemctl restart nut-client
を実行してサービスを再起動します。

あとは実際にUPSの電源を抜いてみて時間通りに動くかをテストします。
ハブの電源もUPSに接続していないと、実際の停電時にNASと通信ができないので注意が必要です。
またDebianのシャットダウン迄の時間は、NASよりも短くしておかないと、今回のNAS側の設定では先にUPSの電源が切れてしまいます。
(NAS側で最終的にUPSの電源OFFを行っています)

実際に停電と同じ状態にして上手く動けば完了です!

Synology NASとLinux(Debian Buster)を1台のUPSに連動させる その1

自宅のネットワーク環境を10Gbに変更すべく、色々なものを10Gb対応製品に入れ替えました。
NASもASUSTORの2ベイのものからSynologyの6ベイモデルDS1618+へと変更しました。
DS1618+はそのままでは10GbEには対応していませんが、ネットワークカードを追加することで対応します。

以前はPC類を停電から守るためにUPSを使用していましたが、バッテリー交換に結構なお金がかかることや、停電など殆どしないことからUPSの運用をやめていました。
今回はHDDの台数も増えたことからUPS運用を再開することにしました。

以前はAPCのSmart-UPS 750を使用していましたが、NASとWebサーバーであるNUC(小型PC)とネットワークスイッチのみ保護できればいいので、小型のものを採用しました。
メーカーは同じくAPCでBR550S-JPというモデルです。

UPSと機器をネットワーク接続ではなくUSBやシリアルケーブルなどで接続する場合は、UPSと通信できる機器は1台のみです。
安いUPSではネットーワークインターフェースを持っていませんので、基本的にはUSBでの接続になるかと思います。

今回はまずAPCのUPSとSynologyのNASをUSBで接続し、SynologyのNASのネットワークUPSサーバー機能を使用し他の機器を更に接続します。

UPSとNASの接続は簡単でAPCのUPSに付属のUSBケーブルでUPSとNASを接続するだけです。
設定もすごく簡単でSynologyのコントロールパネルを開きハードウェアと電源の項目でチェックボックスをONにしていくだけです。

今回はNASがUPSサーバーにもなりますので、セーフモードになるまでの時間は他の機器をシャットダウンするまでの時間よりも長くしておいてください。
またネットワークUPSサーバーを有効にするにもチェックを入れます。
更に許可されたDiskStationデバイスをクリックして、UPS管理する機器のアクセス許可を行います。

アクセス許可はIPアドレスで行いますので、機器のIPはDHCPではなく固定IPで運用する必要があります。
UPSとNASの設定に関してはこれで終了です。

次回はSynologyのNASとDebia(Buster)のUPS連携の設定を行います。
Synology NASとLinux(Debian Buster)を1台のUPSに連動させる その2に続きます

Debian 10 (Buster)のanacronについて

Debian 9 (Stretch)のanacronについて
という記事を以前書きましたが、Debianを10 (Buster)へアップデートしたらanacronがまたおかしくなったので、再度設定を行いました。

/lib/systemd/system/anacron.timer
[Unit]
Description=Trigger anacron every hour

[Timer]
OnCalendar=*-*-* 07..23:30
RandomizedDelaySec=5m
Persistent=true

[Install]
WantedBy=timers.target

アップデートによって設定も初期化されたようです。
そして気付いたことが!
Debian9では上手く動かなかった時間指定が「..」を使ったレンジ方式で書かれています。
ということで、この部分を修正して
# systemctl daemon-reload
# systemctl restart anacron.timer
で完了と。

Debian 9 (Stretch)のanacronについて

以前、サーバーとしてdebianを運用していた環境ではanacronは動いてませんでした。
基本的に電源を落とすことがないのでcronのみで大丈夫だったからです。

cronはタスクを定期実行するためのサービスです。
anacronはcronと同じように定期実行のサービスですが、常時電源が入っていることを想定していないPCのために、電源ONの際に本来実行すべきだったタスクを実行してくれます。

cronとanacronは別物ですが、cronからanacronを呼んだり、anacronからcron.dailyを呼んだりと切り離せない関係にあります。

ノートPCにdebianを普通にインストールしたらanacronも入っていたのですが、電源入れっぱなしだとcron.dailyが日付変更直後に動きました。
crontabの指定時刻は全然別の時間なのにです。
そこでanacronの仕組みを調査してみました。

まず/etc/crontabを確認してみると以下のようになっていました(一部のみ抜粋)

17 * * * * root cd / && run-parts –report /etc/cron.hourly
25 3 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts –report /etc/cron.daily )

上の行はcron.hourlyは毎時17分に実行されるとなっており、これは特に問題ありません。
下の行は3時25分に/usr/sbin/anacronを実行し、失敗だった場合は/etc/cron.dailyを実行するとなっており、こちらも問題なさそうに見えます。

しかし実際には/etc/cron.dailyにあるタスクは0:05など日付が変わって少しして実行されるのです。
(logwatchのレポートが0時過ぎに届くので気付きました)

本来、負荷分散させるためにcronのdailyやweekly、monthlyは夜中から明方のランダムな時間にセットされます。
が、anacronが入っていると0時過ぎにdailyやweekly、monthlyが動き始め、負荷分散の意味がありません。
(サーバーはanacron使うなということでしょうが、調べ始めたので最後まで行きますw)

次にanacronの設定である/etc/anacrontabを覗いてみました。

# These replace cron’s entries
1 5 cron.daily run-parts –report /etc/cron.daily
7 10 cron.weekly run-parts –report /etc/cron.weekly
@monthly 15 cron.monthly run-parts –report /etc/cron.monthly

一番左の数字は何日おきに実行するか。
上から1日、7日、1カ月という風になっており、後ろのdaily weekl monthlyとも一致しています。
左から2番目の数字は遅延時間です。
例えば一番上だと5分遅延という設定になっています。
この遅延時間は5分後に実行されるということではなく、0秒~5分の間でランダムな時間で遅延するというものです。

ここまで見てanacronには実行時間の概念がないことに気付きました…
だから0時過ぎに/etc/cron.dailyが実行されるのか。

ちなみにanacronが実行されると/var/spool/anacron以下の
cron.daily、cron.weekly、cron.monthlyというファイルにそれぞれ実行した日付が書き込まれます。
その日付を参照して同じ日に2回、同じ週に2回など重複して実行されないようになっています。
(逆にいえば、この日付を変更して再起動すれば、即時実行させることも可能です)

anacronには実行時間の設定がないのか?と調べたところSTART_HOURS_RANGEという設定があることが分かりました。
早速/etc/anacrontabに設定してみることに。

START_HOURS_RANGE=3-22

これで3-22の間しかanacronは実行されないはず!
ですが、また0時過ぎに実行されてしまう事態に。

更に詳しく調べたら、debian、ubuntuなどではこの設定は効果がないとのこと…

困りました。
そもそもanacronはどこで実行されているのかを調べました。

どうもsystemdがtimerで行しているようです。
/etc/systemd/system/timers.target.wants/anacron.timer

上記のパスはシンボリックリンクで、実際のパスは以下になります。
/lib/systemd/system/anacron.timer

中身を見てみると以下のようになっています。
[Unit]
Description=Trigger anacron every hour

[Timer]
OnCalendar=hourly
RandomizedDelaySec=5m
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/anacron.serviceが毎時ランダムの最大5分遅延で実行されるということです。
Persistent=trueはPCが起動した直後に実行するかどうかです。

なるほど、ではこのタイマー自体を指定時刻内でしか動かないようにすればいいのではないか、と思ったわけです。
調べると指定時間の設定をどう書けばいいのかが書いてありました。
systemd.time

書き方がちょっとわかりにくいですが「..」でレンジ指定、カンマ区切りで複数指定が出来そうです。
もちろんアスタリスクでワイルドカード指定も可能です。
レンジ指定はなんか上手く動かなかったので、最終的にカンマ区切りで指定することに。
朝の6時~23時まで毎時実行(それ以外の時間はanacronはタイマーで動かない)が以下の設定です。
(起動時即時実行は残しているので、対象外の時間でも起動したり再起動すれば実行されます)

[Timer]
#OnCalendar=hourly
OnCalendar=*-*-* 6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23:00
RandomizedDelaySec=5m
Persistent=true

但し、cronはcrontabに書いた時刻に実行され、そこからanacronが呼び出されるようになっています。
なのでanacronが23:00~6:00まで動かなくても、crontabに書いてある時間にanacron経由でcron.dailyのタスクは実行されます。
仕組みを知れば理解できますが、何も知らないと非常に複雑です。

crontabからanacronが呼び出されてると思いますが、anacronの動作対象外の時間だとcron.dailyは動きませんでした。
タイマーの設定がここまで影響しないとは思うので、何か他で影響が出てるのではないかと思います。

やはりサーバー運用の場合はanacronを止めた方が分かりやすい気がします(笑)