PC関係のメモ

各サーバの設定ファイルを変更管理したい

管理するサーバが増えて、管理する人も増えると誰がドコの何を変更したかを管理しなくちゃいけないわけで。

実現方法とかの覚え書き。

前提条件

• 目的は変更管理。改ざん検知ではない。
• Linux/Windowsサーバ数十台規模を想定。ネットワーク機器も入れたい。
• 既存環境になるべく影響がない方法で。
• セキュリティを確保。通信経路は暗号化するとか。

手法案

1. 各サーバの設定ファイルを変更管理サーバに集約。
2. 集約したファイルをバージョン管理システム(CVS,SVN,Git,etc...)で管理。

1の集約方法は対象OS/機器毎に違ってくるので後述。

2については例えばこんな感じ。

• 変更管理集約ディレクトリを仮に/var/versioning/<hostname>/とする。
• <hostname>はホストの名前を入れる。例えば「www.mylab.jp」みたいに。
• /var/versioning/下をまとめてSubversionで管理。集約処理が終わった後にまとめてコミット。

各OS/機器毎の集約方法については下記。

集約方法　- Linuxサーバの場合なら...

1. 変更管理対象の各サーバに変更管理用フォルダを作成。仮に/var/versioning/とする。
2. バージョン管理したいファイルのシンボリックリンクを/var/versioning/に作成する。
3. 変更管理サーバで、定期的(cron)に各サーバの/var/versioning/をrsync(+ssh)で変更管理集約ディレクトリに同期、集約する。

集約方法 - Windowsサーバの場合なら...(適当)

1. どうにかして変更管理サーバに対して対象ファイルを公開。cifsとか(ry
2. どうにかして変更管理サーバが変更管理集約ディレクトリに対象ファイルを取得。

集約方法 - ネットワーク機器なら...(適当)

1. 変更管理サーバから、except+telnetでコンソール入って変更管理集約ディレクトリに取得する。

メモ

変更管理サーバ側で、各サーバの変更管理ファイルを管理する方法も考えたんだけど、それってセキュリティ的にやばくね？(変更管理サーバからはどのファイルでも参照可能な状態にしないといけないわけで)

というわけで、変更管理ファイルに関しては、各サーバにお任せすることにする。

各サーバでの設定が入るので最初は面倒。

逆に変更管理サーバ側はシンプル。集めてコミットするだけ。

全体の流れはこう。

1. 変更管理対象サーバは変更管理用フォルダに変更対象ファイルのシンボリックリンクを張ってある。
2. 変更管理サーバが各サーバのファイルを集約。
3. 変更管理サーバが集約したファイルをバージョン管理。

あ、「誰が」変更したのか、っていうのはこれだとわからない。けどまぁ、運用でなんとかすればいいんじゃないかと思う。

用語とかがわかりづらいのでそのうち書き直す。

参考になりそうなサイト

• rsync + cron + ssh （rsyncd を立てない編）

[dddav]dddav 0.0.10.3リリース

約一年ぶりにリリース。

機能的には変わってませんが、必要なDLLを減らしたので総プログラムサイズが約3.3MBから約1.5MB程度に小さくなりました。起動に必要なファイルはdddav.exeとwebdav.dllのみになりました。(dddav.iniは無くても自動生成されます)

0.0.10.3の変更内容

仕様変更

• 開発環境をVisual C++ 7.1からVisual C++ 8.0に変更。
• MFC/Cランタイムライブラリ(CRT)を静的リンクに変更。これによりmfc80.dll/msvcp80.dll/msvcr80.dll/Microsoft.VC80.CRT.manifest/Microsoft.VC80.MFC.manifestは不要となりました。
• webdav.dllのインターフェースを変更。

会社に限らず組織に属する中で作業を行う場合、その組織内での標準に従った作業手順を踏むことが求められる。

大きな組織(会社等)であれば標準は文書(規定やガイドライン)として整備されているかもしれないが、小さな組織(会社であれば課、係)や新しい組織では自分で作っていくことが多い。もしくはそう意識しなくても自分が行った作業そのものが標準となることもあるだろう。

標準となる指標が文書になっていない場合、それを説明する側/される側には手間がかかるし無駄ができる。伝言ゲームと一緒で、情報の劣化も懸念される。

例えば説明する側は以下のような作業を行うかもしれない。

• 自分の体に染みついた標準を元に、説明用の資料を作成する。
• 説明する時間を設けけて説明を行う。
• 実際にその作業をやってもらい、フォローアップする。

※上記作業の最初と最後は省略されることもあるだろう。

そして説明される側(会社であれば上司であったり、同僚であったり、部下であったり)は以下のような作業を行うだろう。

• 渡される資料を読む。
• 説明を受け、自分なりに咀嚼し、必要であればメモを取る。
• 実際に作業し、不明点があれば説明者に指示を仰ぐ。

ここで重要なのは「説明用の資料」。

これが組織の標準文書として共有されていたのなら、資料を作る必要がなく(修正する必要はあるかもしれない)、説明される側も、独りよがりでない資料を読むことができる。

ではこの標準となる文書を作るためには、というと。

例えば上記作業に加えて下記のようなことを行う。

• 説明する側は説明される側からフィードバックを受ける。
• 説明される側がメモを取っていた場合は、資料から漏れている情報があったということなのでそれを資料に反映する。
• 説明される側が意図しない作業手順を踏んだ場合は、資料に曖昧な表現がなかったか推敲し反映する。
• 組織内でその文書を共有し使用してもらい、同様にフィードバックを反映していく。
• 組織内で査読を受け、標準の文書としての承認を得る。

ざっくり書いたけど後でまとめる。

WebKit Support Library Agreement

dddav - GUIのWebDAVクライアント for Windows

機能追加

• ホストに接続した際に表示するフォルダ(初期フォルダ)を設定可能にした。

XenのDomUを起動する方法

CentOS 5.1の場合。

# xm create /etc/xen/hoge

hogeはDomUの名前。

で、Dom0の起動時にDomUも自動起動する方法は/etc/xen/auto/内にショートカットを作るだけ。

例えばhogeを自動起動させたいのであれば下記のように行う。

# ln -s /etc/xen/hoge /etc/xen/auto/

NTPサーバの詳細な動作ログを取得する

「ログ」というキーワードで検索して、全然見つからなくてはまった。

On-line Manual of ntp.conf

を見ていて自分が知りたい機能は「モニタ機能」であることがわかった。

というわけで、/etc/ntp.confに以下を追記した。

# for logging
logfile         /var/log/ntp.log
logconfig       =syncall +clockall +peerall +sysall
# for monitoring support
statsdir        /var/log/ntpstats/
statistics      loopstats peerstats clockstats
filegen         loopstats file loopstats type day enable
filegen         peerstats file peerstats type day enable
filegen         clockstats file clockstats type day enable

サーバダウン

mylab.jpのサーバが本日昼頃までおよそ2日間ダウン。

原因は実家に置いてあるサーバの電源が抜けていたため…。

そろそろ自分の家と実家とで冗長構成にしようかな。というかレンタルサーバにしてしまうほうが維持コスト下げられるんだが…。