DigiLoog

“ns-lab”には様々な自宅サーバが稼働しているのだが、
その内の2台でClamAVが起動しなくなる事象が出た。
その2台は古めの仮想サーバホストに収容しており、
ClamAVが起動しきる前にsystemdによってdaemonをkillされている事が判った。

ClamAVはパターンファイルのサイズが肥大化しているので、
結果として起動時に読み込むパターンサイズも大きくなっている。
結果、起動する前にsystemdによってdaemonをkillされてしまい、
その後にsystemdによるservice再起動も重なる事で無限ループ状態に陥っていた。

対処は簡単で、systemd全体のタイムアウト時間を延ばすか、
ClamAVのサービスファイルに”TimeoutSec”を追記する。

こうする事で、TimeoutSecの時間はdaemonをkillせずに処理を待つ様になる。
ClamAVが起動しなくなる原因によるが、処理の遅いCPUを使っている場合には効果がある。

1週間前の2019/07/06にDebian最新バージョンとなるBuster(ver.10)がリリースされた。
筆者の自鯖もメールゲートウェイとしてDebianを使っていたり、
ラズパイでDebian系統のRaspbianを使っているので、そのうちアップグレードする必要がある。

その前に、メインPCをRyzenで再構築する必要があるのでまだ着手は出来ないが、
情報収集するタイミングはあるので情報収集を継続しておきたい所。

複数のドメインを購入して色んな用途に利用しているのだが、
その中でも力を入れているのが、ブログも動いている “ns-lab” ドメインだったりする。
当初は技術習得・新技術の検証として立ち上げたのだが、
色々と拡張を続けた結果、Internet向けの権威DNSは4台のフルアクティブ構成で、
全て自前でDNSサーバを持つ様になった。

DNSと言うと踏み台攻撃が怖い為、
万が一にも攻撃側にならない様にアプリケーションのバージョン管理は気をつけていて、
マイナーバージョンアップも即実施するレベルで追従する運用体制を取っている。
ただ、4台のサーバを一度にアップグレードするのはそれなりに辛い作業で、
他の事が重なるとアップグレードが追い付かない時があった。

さらに、1台のサーバが停止しても大丈夫な様にマルチマスタゾーンの構成をとり、
サーバ障害時にはスレーブ相当のサーバが昇格する構成になっている為、
ゾーン編集時には2+N台のゾーンを同じにしておく必要もあった。

『なんとかしないとまずいな～』と思いつつ、twitterを見るとAnsibleがやたらと流行っており、
『このビッグウェーブに乗るしかない！』と思い立ったので、
まずは目先の課題解決とAnsibleのポテンシャルを測る為に仮運用してみた。

………

結論からとなってしまうが、無事にDNSサーバのアプリケーションアップグレードと、
マスターDNSゾーンを各々のサーバに配布・適用する作業の自動化が達成できた。

今回、知識習得に1時間、設定レベルの落とし込みに8時間程で達成出来たのだが、
初めての人でもそれなりの処理ルールを作り上げられたので、個人的には成功の部類だと思う。
一からスクリプトで自動処理を作る場合、相応の言語知識とアルゴリズムを組むセンスが必要になるが、
Ansibleの場合は処理が体系化出来ている事もあり、勉強負荷が低いのも今回の成果に繋がったと思う。

Ansibleは構成管理として使う事が多いだろうが、
今回実施した様な、手動で実施している事を自動化する目的でも通用するポテンシャルを持っている。
まだ、お試しな事もありplaybook公開まではやらないが、今後は公開してブラッシュアップしつつ、
何れはモジュール自作とかにも取り組みたい所なので、さらに踏み込んで使ってみる予定。