※当サイトの記事には、広告・プロモーションが含まれます。

ネットワーク機器の設定情報をバックアップするツール「Oxidized」の処理の流れを整理してみる

nazology.kusuguru.co.jp

アメリカのアラバマ大学UA)から発表された研究により、生命が生と死を超えた第3の状態に変化できるとの概念が示されました。

生命には生と死を超えた「第3の状態」の状態が存在すると判明 - ナゾロジー

研究ではここ十数年の研究成果がレビューされており、栄養、酸素、生化学的刺激が与えられた場合、人間やカエルの体が死後に新たな機能を備えた「多細胞生物」に変化できることが示されています。

生命には生と死を超えた「第3の状態」の状態が存在すると判明 - ナゾロジー

研究者たちは死の生物学が進んだ結果「生物の死に関する従来の理解や「生命」および「生物」の定義が時代遅れになっている可能性がある」と結論しています。

生命には生と死を超えた「第3の状態」の状態が存在すると判明 - ナゾロジー

⇧ むっちゃ怖いんですが...

死後、火葬とかされてる時は、苦痛を感じる意識とかは消失している状態と信じて良いんですよね?

そうでないと、死後に阿鼻叫喚の地獄を味わうステップが待っていることになって、救いが無さ過ぎるんだが...

でも、

鳥葬(ちょうそう)とは葬儀、または死体の処理方法のひとつであり、肉食の鳥類に死体を処理させるものである。

鳥葬 - Wikipedia

概要

チベット仏教にて行われるのが有名である。またパールスィーと呼ばれるインドゾロアスター教徒も鳥葬を行う。国や地域によっては、法律などにより違法行為となる。日本では、鳥葬の習慣はないが、もし行った場合刑法190条の死体損壊罪に抵触する恐れがある。

鳥葬 - Wikipedia

チベット仏教ゾロアスター教などで「鳥葬(ちょうそう)」とかの風習が残ってるらしいのだけど、死後、意識が戻ったような話を聞かないけれど、科学的に死後も意識が残ってるとか判明したら、絶望しか無いんだが...

生命が生と死を超えた第3の状態に変化できるとの概念が示されました。

いや、死後の平安は保証して欲しんだが...

ネットワーク機器の設定情報をバックアップするツール「Oxidized」の処理の流れを整理してみる

何度か話に上げてきたのですが、

github.com

Oxidized is a network device configuration backup tool. It's a RANCID replacement!

It is light and extensible and supports over 130 operating system types.

https://github.com/ytti/oxidized/tree/master

⇧ 上記のGitHubで公開されているツールなのですが、ドキュメントの説明が少な過ぎて、カオスな状態ですと。

とは言え、「Oxidized」の各ファイル群の関係が知りたいが、Ruby初心者の我輩には、皆目見当が付かないですと...

で、「Microsoft Copilot」に確認したところ、Dockerの場合は、

  • Dockerコンテナ起動
    runitで常駐プロセスとして、Oxidizedのプロセスが起動する。

とのことなのだけど、Oxidizedのプロセスがどのような流れで処理を行っているかというと、

  1. oxidized/bin/oxidized
    エントリーポイントとして、Oxidizedの実行が開始されます。
  2. oxidized/lib/oxidized/core.rb
    Oxidizedのコア機能が初期化されます。
  3. oxidized/lib/oxidized/config.rb
    configファイルが読み込まれ、設定が適用されます。
  4. oxidized/lib/oxidized/nodes.rb
    バイスのノード情報が読み込まれ、管理されます。この際にrouter.dbファイルも読み込まれます。
  5. oxidized/lib/oxidized/input
    SSHTelnetなどの入力メソッドが定義され、使用されます。
  6. oxidized/lib/oxidized/model
    バイスのOSタイプに応じたモデルが適用されます。
  7. oxidized/lib/oxidized/output
    取得したデバイスの設定情報が保存される出力メソッドが定義されます。

という感じで処理が流れていくらしい。

まぁ、「Microsoft Copilot」の言うことなので、全く信用の無い情報なのだけど...

で、「runit」については、

developer.medley.jp

runit とはなんなのか

プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。

runit が便利なので、使い方を紹介した話〜メドレー TechLunch〜 | MEDLEY Developer Portal

Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。

qmail の作者であるdjbが作ったdaemontoolsの後継のプロダクトです。

runit が便利なので、使い方を紹介した話〜メドレー TechLunch〜 | MEDLEY Developer Portal

■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる

Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます

runit が便利なので、使い方を紹介した話〜メドレー TechLunch〜 | MEDLEY Developer Portal

⇧ ということらしく、「Systemd」によるサービスとしてのプロセスで起動するのに似ているそう。

「Systemd」の利用を避けたのは、Dockerコンテナの起動で度々問題を起こしてたからとかなのかね?

「Oxidized」のドキュメントに処理の流れを記載して欲しいお気持ちです...

デバッグ実行できるような環境を作って、ステップ実行で処理を追うしかないんかね?

Rubyデバッグ実行の環境を作るのが無茶苦茶、面倒な気がしますが...

そして、今日も今日とて「Ruby」のソースコードの読解が辛い...

処理の起点、所謂、エントリーポイントが分かり辛いんよね...

毎度モヤモヤ感が半端ない…

今回はこのへんで。