墜落日記 - 2009年5月の墜落
2009年5月10日
Borland 買収と Delphi コンパイラの将来
突然のことだったが、先日 Borland が Micro Focus に買収された。
Micro Focus 社はレガシーマイグレーションに重点を置き、Windows や UNIX/Linux 上での COBOL 環境を販売する企業だ。
とは言っても、元々の Borland 由来の技術である Turbo Pascal から発展・派生した Delphi や、C++Builder、JBuilder など、昔からの Borland を知る技術者にとって Borland の遺伝子と呼べるべき技術は CodeGear として分社化され、既に EMBARCADERO TECHNOLOGIES へ買収されている。
言ってみれば今回 Micro Focus が買収した部分は Borland が多角化を目指して各社から買収した部分である。
なので、一抹の寂しさはあるにせよ、本来の Borland の遺伝子にはもはやなんの影響もない。
と言うか、Micro Focus が今の Borland のどの部分を必要としていたのか、ちょっと微妙な気もしないでもないが、ソフトウェアテストツール市場の拡充を目論んでのことだろうか？
CodeGear と言えば、先日「Delphi コンパイラの将来」と題した記事が投稿された。
Delphi しか知らない人からしてみれば Turbo Pascal コンパイラ時代から引き継がれていた文法などが実は残っていることなど知るよしもないだろうが、Delphi が今まで大命題として掲げてきた過去の開発資産との互換性―――後方互換性と、先進的でエキサイティングな機能の実装との二律背反が感じられて面白い。
後方互換性という面はビジネス現場での開発にとって非常に重要な問題となる。
一発一発が単発なツールの類や、小規模なパッケージではあまり問題は起こらないだろうが、大規模かつミッションクリティカルなビジネスアプリケーションの開発に於いて、開発言語が最新の技術に対応しつつ後方互換性を確実に維持してくれることは非常に大きな武器となる。
例えば、Microsoft の VisualBasic は 6.0 と .Net の間に埋めがたい大きな溝が発生して、マイグレーションに多大な工数を必要とした―――それはぶっちゃけ作り直しのレベルである。
6.0 までの VisualBasic の言語仕様がキチガイという事実もあるにせよ、これを .Net 仕様に合わせて大変革してしまうのは、純粋に技術的な観点からは良いとしても、大規模かつミッションクリティカルなビジネスアプリケーションを維持するベンダとしては狂気の沙汰にしか思えなかった。
大規模かつミッションクリティカルなビジネスアプリケーションを VisualBasic で作ったというそもそもの選択ミスはここでは語らないことにするが。
Delphi では元々の言語仕様が割としっかりしていたせいもあって、その様な狂気じみた地殻変動は起こっていない。
しかし反対にドラスティックな言語機能の拡張というのも今まで起こっていなかったとも言える。
最近流行の無名メソッドやジェネリック型の対応などがなかなか実装されなかった部分などもこれを如実に表している。
もっとも如実な例は、マルチバイト文字の内部実装がずっと旧態依然とした Shift JIS であり、最新の 2009 になるまで Unicode 対応しなかったことである。
これを槍玉に挙げて Delphi コンパイラを糞だ何だと大騒ぎする短絡的な連中もいるが、これはひとえに高度な後方互換性を維持してきたが故の苦肉の選択であり、「Delphi コンパイラの将来」で語られる二律背反な部分である。
この「Delphi コンパイラの将来」を読むと、後方互換性の維持と先進的でエキサイティングな機能との両立に、如何に神経を割いてきたのかが伺える。
2010 年には発表されるという 64bit 対応コンパイラにおいてどのような解答を示してくるのか、非常に楽しみである。
2009年5月6日
発作的に Atom を試してみた
新型マルチレイヤスイッチの導入によるネットワーク環境再構築作業はほぼ完了した。
サーバラック替わりのパソコンデスクにも全てセッティングが完了して、現在本番運用に突入している。
ま～今後色々と問題が起こるかも知れないから先代マルチレイヤスイッチはしばらく状態維持をしておこうか。
今回 Mini-ITX マザーボード ATW-9813+ と Intel のサーバ用 NIC EXPI9404PT を主軸に色々と組んでみたのだが、小さいって事は良いことばかりではないことを痛感した。
小さいと重量が小さいとか、体積が小さいとか、省電力にしやすいとかメリットはあるが、省電力前提なので安心できる出力を持った電源が用意しづらいとか、ケースの選択肢が極端に限られるとか、ケース内のエアフローの確保がしづらいとかが発生する。
また、ロープロファイルの PCI カードに対応したケースは数在れど、標準プロファイルに対応したケースは少なくなるのも問題だ。
当初予定の Noah 800 は標準プロファイルに対応しつつも群を抜く小型であるメリットはあったが、80W という低出力が不安定要素を引き込んだ。
現在運用中の A-ITX-200P300 は 300W の電源容量を持つので安心感はあるが、今度はエアフローが残念なレベルである。
それらを高いレベルで満足させるためには SG05 辺りは確かに妥当なのかもしれない。
で、余ってしまった Noah 800 や、端っから使う気がなかった NIRVANA の標準ハードディスク、インストールさえ終われば無用となる光学ドライブなど、ほとんど一式揃っているので、つい発作的に Atom を作ってみてしまった。
仕入れてきたのは Atom 330 を積んだ Intel D945GCLF2。
実は先日の秋葉原練り歩きで既に入手していたとは口が裂けても………げふんげふん。
Atom 330 は TDP 8W の省電力が売りで（Atom 230 は 4W、N270 に至っては 2.5W ともっと凄いけど）、デュアルコア、HyperThreading の仮想４コアを実現している。
NIRVANA に積んであった Core2 Duo T8100 の TDP が 35W だから、単純計算で 27W の省電力化が可能となった筈。
取り敢えずファイルサーバに仕立て上げるべく、D945GCLF2 にメモリとハードディスクと光学ドライブ繋いで Windows Server 2003 Enterprise Edition を放り込んでみると、全く問題なく快調にインストール作業は進んだ。
で、現在のファイルサーバから eSATA を増設する PCI カード、RATOC の REX-PCI15PM を移植してみて再起動。
REX-PCI15PM の消費電力は不明だが、取り敢えず電源容量の範囲内には収まったようで、挙動不審は発生していない。
なお、REX-PCI15PM に積んでいる SATA コントローラ SiI3124 は Windows Update をすることで Microsoft から入手することが出来るので、別途ややこしいインストールは必要ない。
ここに更に SATA RAID ボックス、CG-HDC4EU3500 を接続してみて認識させるも、挙動がおかしくなることはない。
なんとかなりそうな雰囲気だ。
なんとかならなかったらどうするんだ？ という疑問は事象の地平の彼方へ置き去りだ。
その後、自宅内ホームページ用の Apache HTTP Server を放り込んだり、DFS を構築したりしてみたのだが、速度的な問題は出ていない。
もちろん高負荷がかかるようなサーバ用途には向かないとは思うが、あまり負荷のかからないファイルサーバなどの用途には、省電力だし良い選択肢かもしれない。
何と言っても安いしね。
そうそう、去る５月５日はドルパ２１の日だったな。
ちょっとフェイトは興味があったんだけど、新型マルチレイヤスイッチ構築の紆余曲折や MSDN の支払いの口座引落が迫っている関係もあってスルー………
ま～なのはは身請けしているので、ヘッドが共通なら面白みは半減だからいいけどね。
それにフェイトで切っておけば今後はやてが出たとしても勢いで散財する危険性が無くなるし………ではなくて、仮想サーバ構築の為の軍資金を作る方が先決だし(汗々)
仮想サーバを構築してしまえば、追加の退職手当が必要な人員削減も出来るわけだし(爆)
（いや～誰が考えたのか知らんけど、このネタ好きだわマジで）
2009年5月4日
結局、無難な線で軟着陸
新型マルチレイヤスイッチの稼働試験を昨日からぶっ通しでやってみて、とうとう３０時間稼働の実績を示した。
もう不安定化の原因は電源容量不足と断定して良いだろう。
80W という低容量はやはり Atom か EPIA 辺りでないと無茶無理無謀で、NIRVANA の電源設計がかなりタイトか、むしろ無茶だったと言えよう。
TDP 8W の Atom 330 を積んだ Intel D945GCLF2 にハードディスク追加の状態ですらアイドル時 47W 程度を持っていく様なので（出典）、もともと 35W の TDP を持つ Core2 Duo T8100 では単純計算でアイドル時 74W、チップセット回りの TDP も上がっているだろうし、これに TDP 12W の EXPI9404PT を追加すれば無理に決まっている。
NIRVANA は基本的に弄っちゃダメだったわけだ。
冷静に考えろ、俺。
と言うわけで、余った Noah 800 は Atom 行き確定(爆)
で、本日は秋葉原を練り歩く予定だったので、ついでに SFX 電源搭載の Mini-ITX ケースを仕入れてしまった。
仕入れたのは昨日の予定通り、A-ITX-200P300、300W の SFX 電源を搭載している小型ケースだ。
搭載電源 SL-8300SFX のサイズは 125mm(W)×63.5mm(H)×100mm(D) の一般的な SFX(C) サイズで、これなら故障時も入手に問題は無かろう。
と言うわけで、余った CF-A8989WT150 は行き場が無くなった(爆)
問題が電源なのかマザーボードなのかの切り分けがしたくて居ても立っても居られずカッとなって買ってしまったケース、微妙に後悔している………(汗々)
誰か必要な人が居たら譲ってしまおうか？？
（オクに出品するのは面倒、というか出品経験なし）
で、例によって現在は稼働試験中。
ま～マザーボードと EXPI9404PT は既に３０時間連続稼働実績はあるので、A-ITX-200P300 標準搭載電源の稼働試験ということになる。
しばらく負荷をかけ続けておいて、様子を見てみよう。
ちなみに、新型マルチレイヤスイッチの名前は順当に NIRVANA が使えたのであれば《にるばーな》にするつもりだったのだけど、紆余曲折を経て NIRVANA のパーツのまま使っているのは結局マザーボードだけなので（正確にはマザーボードとメモリと CPU）、Core2 Duo T8100 のコアより順当に《ぺんりん》と命名する。
マルチレイヤスイッチとしての役目を終える《どったん》こと Pentium M 725 の用途は現在考え中。
順当にファイルサーバとして利用する案もあったのだけど、Intel D945GCLF2 辺りを購入してきて Atom 導入すれば NIRVANA の余りパーツを使って安く一台組めるしで、実現する意味が薄いのも事実………
御役御免の廃棄処分かね………？
それはそれで勿体ないのだけど………う～ん………
そう言えば、旧マルチレイヤスイッチでは eth0 に割り当てられていた NIC が死んだ際には eth1 ～ eth5 が繰り上がって eth0 ～ eth4 になってしまって混乱した。
しかし現在稼働試験中の新型マルチレイヤスイッチでは EXPI9404PT の認識が怪しい際にも eth0 ～ eth3 が使えなくなるだけで eth4 ～ eth6 は固定だった。
どうも Debian GNU/Linux の Sarge と Lenny の間で挙動が変わっているらしい。
気になって調べてみたら、Lenny の場合は /etc/udev/rules.d/70-persistent-net.rules ファイルに MAC アドレスと eth? との対応が固定的に設定されていた。
いつからこの様になったのか分からないが、これのおかげで障害時の挙動不審が押さえられて問題発見が早まったわけだ。
しかし反対に、VMware 上に Debian GNU/Linux をインストールしてクローン取ったりすると eth? がどんどん大きくなっていくってことかな？
それはそれで単純なクローンが取れなくて面倒ではあるかな………？
一長一短だね。
2009年5月3日
やっぱ電源が足りてねぇっ！？
新型マルチレイヤスイッチ NIRVANA の稼働試験をやってみたら、出るわ出るわ、トラブル続き(笑)
ま～ Debian のバージョンが変わったことでいくつかの設定内容が変化していたり、いくつか追加設定しないといけなかったところとかは問題なく修正できたのだけど、勘弁できない問題が浮上した。
増設した Intel EXPI9404PT が認識したりしなかったりするのである。
起動時に認識しなかったり、起動してからしばらく経つと止まってしまっていたりと現象が一定しない。
設定してしばらくしたら唐突にネットワークが切れるから何かと思ってみたらコリジョンが山ほど発生しているとか、再起動したら使えるようになる場合とデバイス自体が消えて無くなる場合が混在してワケ分からないとか。
決まっておかしな挙動を起こすのは PCIe に増設した EXPI9404PT の方で、ATW-9813+ にオンボードの方は現象が起こることはない。
挙げ句の果てに時々 Linux 自体が起動しなくなるとかもある。
ライザーカードの接触不良なども疑ったけど、どうやらここまでおかしな挙動をするのは電源容量が足りていないからではないかと思われ。
もともと AC アダプタの電源容量は 80W で平均電力消費量が 116W という「ちと無茶じゃないか？」という部分もあったが、いくらハードディスクを取っ払って SSD にしたとは言え、EXPI9404PT の増設による平均電力消費量 12.096W の増加は致命的だったか？
ま～、たしかに Noah 800 シリーズは元々 VIA の EPIA 向けだしなぁ～(爆)
VIA の EPIA と言えば小型・低消費電力が大好きなマニアックな諸兄御用達のロリっ娘だし(爆)
いくらなんでも EPIA をお迎えするための小部屋に Core2 Duo 放り込むのは無茶だったのか？
標準状態の NIRVANA は辛うじて動いていたということか？
………ってか、A.T.WORKS の営業がやたら動作確認したがったのって電源容量問題が発生するのが分かっていたからじゃないだろうな？(汗々)
と言うわけで、SFX 電源搭載可能な Mini-ITX ケースを物色することが確定(涙)
標準の PCI カードが挿せるしスリムドライブも利用可能な SG05 辺りは狙い目かも………ま、インストール自体は終わっちゃってるから光学ドライブなんぞ要らないけどね………
Atom ボードでも買わない限り Noah 800 は完全に無駄だな………しくしく………
トラブル繋がりではないけど、2001 年秋口に構築して未だに稼働していた初代の Pentium 4 マシン、《うぃる》が唐突に落ちた。
バチンと「電源が逝っちゃったかな？」という音がして再起不能。
ま～流石に第一世代 Willamette コア の Pentium 4 だし、マザーボード側が逝っちゃったとしても不思議はないけど、何も NIRVANA のトラブルと同時並行してトラブらなくても良かろうに………(汗々)
追記。
………………………………ん？
もう朝方になったから寝ようかと思ったら、唐突に《うぃる》が起動した？
電源ケーブルを繋いで、ダメで元々で電源ボタンを押して………１時間後！？
こ、こりゃ完全に電源ですねっ？ 電源なんですねっ！？
《うぃる》、お前もか………！
更に追記。
NIRVANA の電源容量不足を疑って、150W 電源搭載の Mini-ITX ケースを仕入れてきた。
本当は SG05 辺りが手に入ると良かったんだが、なんかゴールデンウィークで品薄状態になってしまっていて、仕方なく近所の PC DEPOT で CF-A8989WT150 を仕入れてきた。
もう少し時間を掛けて作業しても良かったんだけど、長期休業中でないと耐久試験に付き合えないという問題もあるので、思い切ってやってしまった。
NIRVANA をバラして光学ドライブ以外を全て CF-A8989WT150 に放り込み、起動する。
すると、今まで不定期に出ていた iptable の設定時の変なエラーも見えなくなり、Intel EXPI9404PT の認識もしっかりしている。
なので、現行マルチレイヤスイッチからネットワーク制御を委譲させて、連続稼働試験に入ってみた。
今の所問題なし、ま～これを書いている時点でまだ連続稼働３時間程度でしかないが、前は１時間も保たなかったし、EXPI9404PT の認識自体が怪しかったし………
ちなみに、NIRVANA に入っているマザーボード ATW-9813+ は一応 Mini-ITX のフォームファクタなのだけど、OPMA コネクタの関係で奥行きが大きくなっているので、Mini-ITX 規格でタイトに作られていると入らない。
現実に CF-A8989WT150 に突っ込む際には内蔵電源の配置を直さなければならなかったので注意が必要だ。
ま～販売終了してしまった ATW-9813+ に今更気をつけろも無いとは思うけど(汗々)
なお、CF-A8989WT150 の内蔵電源は Comstars という会社の KT-T150FX-06A という型番の TFX 規格電源の様だが、KT-T150FX-06A 自体は一般に販売していないだけでなく Comstars 社の製品紹介でも登場しない特殊なモノらしい。
大きさも 65mm(W)×65mm(H)×130mm(D) とえらく小さく、ぶっ壊れたら換えが効かないという問題があるのも事実。
壊れた時にはケースごと買い換えるか、さもなければ CF-A8989WT150 をもう一回買ってきて共食い整備するかしかないかな？
入手性の高くなった SFX 電源を考えたのはこの辺りもあった筈なんだけど、コロッと忘れてるなぁ～………俺(汗々)
更に更に追記。
連続稼働試験、６時間経過、なおも順調。
これはもう電源容量不足だっただけと考えて良いかも？
少なくとも電源が安定すれば動くことは分かってきた。
明日は秋葉原に行く予定の日なので、今後のことも考えて SFX 電源搭載可能な Mini-ITX ケースでもついでに物色してみようか？
A-ITX-200P300 あたりも良いかも？
Noah 800 には余裕が出来たら Atom マザーでも放り込んでみようか？
更に更にさら～に追記。
連続稼働試験、１０時間経過、なおも順調。
2009年5月2日
致命的な OP25B と増える自己投資？
新型マルチレイヤスイッチの構築は着々と進行中。
基本は Debian GNU/Linux での構築で、アプリケーションサーバとしての用途が存在しないマルチレイヤスイッチにおいてはソースから手動でビルドする要素が全くないため、Debian のパッケージにほとんどお任せ。
要らない機能はバッサバッサと切り捨てる―――と言うかインストールしないので、8GB の SSD でも 5GB くらい余ってしまうから素敵だ。
（ちなみに 512MB が /boot パーティション、5.5GB が / パーティション、2.0GB がスワップパーティションとしたので、実質 OS 本体は 1.0GB 程度しか使っていない）
で、実はもうほとんど出来ているので、後はえいやっと入れ替える根性があれば良しである。
しかし今更というか、ほんとマジ遅すぎる危惧なんだけど、DIRAC Noah-800 の電源って耐久性能は如何ほどなんだろうね？
マルチレイヤスイッチとして常時稼働するわけだから、電源の耐久性能って結構重要。
AC アダプタの障害ってよくコネクタ部分の接触不良や断線を聞くけど、それは抜き差しが頻繁になる運用をした場合の話で、今回においては据え置きの連続稼働だからその可能性は低い。
そうすると AC アダプタと本体側の電源回路の耐久性能になるわけだけど、少なくとも AC アダプタの予備の用意とか、最初からちょっとまともな奴探してくるとかした方が良いかもなぁ～とか漠然と。
もしかしたら電源を安定化させるために SFX 電源が使えて通常の PCI カードのスロットを持った SCY-201-ITX とか SG05 とかを調達した方が良いのかも？
当然どちらも Noah-800 より大きくなってしまうから省スペースとはいかなくなってしまうけど………
しかし、ソコまでやったらマジで NIRVANA である必要性ねぇ～っ！！
ATW-9813+ の再販、ないし ATW-9813+ の拡張版の販売を求むっ！！(爆)
………ま～、連休中に連続運転の試験してみて、様子を見ようか………？
ちなみに余る予定の Pentium M 725 使って小型 PC 作るのも面白そうとか思っている俺がいる。
乗っている NIC が蟹ってところは気に入らないけど AIMB-250-B で完全ファンレスの無音 PC とか面白そうじゃね？
さてさて、本日の本題は OP25B（Outbound Port25 Blocking）である。
OP25B とは、昨今社会問題化している迷惑メール対策として、「いっそメールの配送に利用される 25 番ポートを閉じちゃいましょう」という極論に近いような方策である。
そもそも SMTP の仕組みはインターネットの仕組みがまだ研究室の中だけに留まっていた当時に性善説を前提に作られた仕組みであり、無条件のメール配送リレーを前提に動作する。
つまり正当なユーザだろうが、悪意のユーザだろうが、善意の脳足りんだろうが、自分がやっていることが目一杯スパムの片棒だと理解していないお小遣い稼ぎ気分のおばちゃんだろうが、SMTP は構わずメール配送してしまう。
なので、安価に大量のダイレクトメール（言い得て妙だ）を送りつける手段として手軽極まりないのであるからして迷惑極まりないのである。
で、最近のスパムはプロバイダの SMTP サーバを利用せずに独自の SMTP サーバから大量の送信をしていることがあり、こうなるとプロバイダの SMTP が認証をしようが止めることが出来ない。
そこで、SMTP のポート番号である 25 番で外部に飛び出そうとするトラフィックを止めてしまって、プロバイダが用意する SMTP の利用に制限してしまったりする。
これら方策を総じて OP25B と言う。
例えば、自分が利用しているプロバイダである WAKWAK では、WAKWAK 以外のメールサーバを利用する場合に OP25B に撃墜されることになる。
つまり WAKWAK のネットワークから外部業者の SMTP を利用したり、会社の SMTP を利用したり、自分で作った SMTP サーバで送信したりすると撃墜される。
なお WAKWAK ではアドレスプラスという固定 IP 提供サービスに契約している場合、ま～身元もハッキリしているし、そもそも固定 IP アドレスが必要って事はメールサーバを自前で用意する可能性もあるわけだから、対象外にしてくれているので有難い。
この配慮がなければとっくの昔に自宅サーバからメールが送れなくなっているのだ、くわばらくわばら………
さて、ここで考えたい。
プロバイダに 25 番ポートをふさがれた外部業者は、どうやってメールサービスを提供するのか？
簡単である、25 番ポートでなければ良いのだ。
これが俗にサブミッションポートと言われる奴で、認証付き SMTP を 587 番ポートで提供するのが通例らしい。
そうすると OP25B にも撃墜されないし、認証付きだから誰がやっているのかハッキリするわけで、めでたしめでたし、と。
そうは問屋が卸さねぇぜコンチクショーッ！！
何がまずいかって？
簡単だっ！！
サブミッションポートの用意が間に合わなければそれだけで即アウトなんだよっ！！
今回どうもこの問題が起こりそうな気配である。
自分、一年前くらいに仕事で色々とタイミングが悪い状態になってモバイルネットワークが切実に必要になり、仕方ないから EMOBILE に契約した。
もちろん自費である。
理由まとめて費用算出して申請したって承認が出るか出ないかだけで１ヶ月も２ヶ月も待たされるし、よしんば承認されたとしても更にそれから契約じゃ、目の前の危機は救えないからである。
で、導入した EMOBILE で存分に機動力を発揮していたら、先日、自分のトコロに EMOBILE から、５月から順次 OP25B の適用範囲を拡大する旨の通知が来てしまった。
これは洒落にならんと会社のシステム管理に問題提起したら、
「会社には来ていない、個人向け契約だけじゃないの？ ま、前向きには検討するよ」
みたいな有難いお言葉である。
ここで後ろ向きに考えられても困るわけだが、何も OP25B 実施するのは EMOBILE ダケじゃないんだし、ちゃんとしてもらわないと業務に支障が出る。
社員全員が揃いも揃って内勤♪ とか、充実した WEB メールシステムで会社メールは一元管理♪ とか恵まれた環境じゃないんだから(汗々)
というか、IT 化が最も遅れている業界は IT 業界です、ふひひ。
しかし、これは、覚悟を決めて自宅サーバでサブミッションポートを提供してしまう他ないか？
自宅サーバからは WAKWAK の配慮で 25 番ポートが問題なく使えるし、自宅サーバでリレーさせれば問題なく飛ばせるよな？
って、また仕事のインフラを自分で整えようとかしてるし。
（唐突に冷静になる俺）
2009年5月1日
マルチレイヤスイッチ構築開始
ハードウェアが揃ったので、早速マルチレイヤスイッチの構築に入る。
新型マルチレイヤスイッチとして現行のマルチレイヤスイッチの仕事を委譲していくにあたり、作業しなければならないのは以下のタスクである。
- PPPoE 常時接続により WAN 回線を構築
-
WAN、個人用、公開用 DMZ、家族用 DMZ の４系統のネットワークのパケットを制御する。
個人用からは WAN、公開用 DMZ、家族用 DMZ へフルアクセス。
家族用 DMZ からは WAN、公開用 DMZ へ一部のみ許可、個人用へ不許可。
公開用 DMZ からは WAN へ一部のみ許可。
- WAN からの http、https をサーバへフォワーディング。
- WAN からの smtp をメール配送ゲートウェイで一端受けて、自ドメインへのメールのみメールサーバへ転送、その他は破棄（踏み台防止）。
- ネームサーバを構築
- DHCP サーバを構築
- NTP サーバを構築
その他にも作業性を維持するために、SSH サーバや FTP サーバは必要になる。
将来的には、
- http、https ゲートウェイの構築
もタスクとなるが、これはサーバ環境が仮想化されて、サーバの役割分担が明確になってからとなろう。
で、ついでに IP アドレスの振り直しも画策。
現在、個人用のネットワークが 192.168.1.0/24、家族用が 192.168.11.0/24、公開用 DMZ が10.0.0.0/8 となっている。
ここで個人用のネットワークを今後の VPN 環境の構築なども視野に入れ、クラス B 辺りのアドレスに引き上げてしまおう。
また仮想マシンの稼働が増えていくと正直クラス C では狭いので、その対策も含めて。
この作業にはネームサーバの設定の変更と、実際に新型マルチレイヤスイッチが稼働を始めた際の端末側のネットワーク設定の変更の２つのタスクが発生する。
ノートなんかの移動端末は DHCP で繋いでいるから関係ないが、固定端末は IP を固定で割り振っているので手間がかかる。
こういう地殻変動起こしやすい環境再構築の際にやってしまわないとチャンスがない。
しかし、むむ、分かっちゃいたが、なにげに面倒(爆)
取り敢えず、ネームサーバの設定は完了。
パケット制御も設定し終えたはずなので、あとはメール配送ゲートウェイの構築が終わればえいやっと入れ替える作業に入れるはずだ。
も、もう一踏ん張り………！！
