オンラインヘルプページの裏側 (No.1) では、名称とコンセプトの説明に留まりました。
ここでは、"コントロールパネル" として提供されている製品と、オンラインヘルプページの内部構造を比較してみます。
サーバ毎に Web アプリケーションは必要ない
レンタルサーバ (ホスティングサービス) が事業者として成長するには、必ず保有するサーバ台数が増えていくことになります。
"コントロールパネル" をインストールして使用する場合、サーバ台数に比例してライセンス費用等がかさむことになるでしょう。ボリュームライセンス等も用意されているかもしれませんし、オープンソースもあるかもしれません。
しかしながら、"コントロールパネル" が理解出来ないサーバ関連プログラムの管理は当然行えないので、きめ細やかな設定やサービス事業者オリジナルの構成には不向きでしょうし、実現しようとすれば、"コントロールパネル" と、"コントロールパネル" が理解出来ないプログラムの間に何らかのプログラムが必要となるでしょう。
ブリッジの様に橋渡しの役目を受け持つプログラムで実現したとしても、今度は "コントロールパネル" のバージョンアップ時の互換性に悩まされます。
Drive Network では、agent と呼ぶ 100% Perl のプログラムを自製しています。このプログラムは全サーバにコピーしていますが、オンラインヘルプページ で操作した内容を受け取ってバッチ処理する様なイメージで動作します。
Web サーバの動作権限と無関係
"コントロールパネル" が Web アプリケーションである以上、Web サーバのユーザ権限で動作しますが、サーバ内の設定が可能ということは root 権限に処理を渡す必要が必ず生じます。
知っている限りでは、root 権限で Web アプリケーションを動作させるが、port 80 以外で動作させて、URL を知らないユーザはアクセス出来ない (しにくい) 処置で動作させることが多い様です。
これでは port 番号を含めた URL を知られれば途端に危険度が増します。セキュアとはとても言い難いですね。
Drive Network では前述の agent が動作するだけでアカウントやメーリングリスト・データベース。アプリケーション設定等ご利用に必要な設定をすべて行います。Web アプリケーションではなく、コマンドラインでのみ動作するプログラムです。
処理の流れは、
- オンラインヘルプページでの操作
- 特定のフォーマットでメール作成
- 対象サーバ root 宛てに送信
- 着信したメールを procmail が解析し agent に渡す
- agent がメールを解析して設定
難しいプロトコルを使っている訳でも何でもなく、空メールと同等な仕組みです。仕組みは単純ですが、
- Web アプリケーションではないので、Web サーバの脆弱性とは無縁。
- procmail を経由して動作することで、root 以外は絶対にプロセス内動作が確認出来ない。(umask 077 で動作)
- agent はサーバ内の設定内容をコマンドラインで記述する程度のものなので、どんなプログラムにでも対応出来る。
また、"特定のフォーマット" で受信したサーバでは、Subject 認証に加え、md5 による文字列認証も行っています。これらを含めてようやくサーバ側で処理が始まります。
柔軟性を備えつつ、セキュアでもあるこの仕組みがアドバンテージと考えています。
