2016年06月04日(土) - 01:18 | カテゴリ:
Linux
構築メモ：nowsky system-lab memo [ISC-DHCP]
今までのns-lab BBでは、DHCPサーバをCiscoルータで代用していたのだが、
ここに来てルータとかスイッチの刷新を行う必要が出てきてしまい、
DHCPサーバ代わりに使っていた、オンボロルータも廃棄対象になってしまった。
という事で、このまま放置しておくとDHCPでIPアドレスを払い出しているセグメントが
モロに影響を受けてしまうので、早めに対策を打つ必要が出てきたこともあり、
「この際だからISC-DHCPで組もう。ついでに冗長化もLet's try!」という事を思いついたので、
久々にソースコードのビルド走らせながら、DHCPサーバを構築してみた。
今回は下記の様な構成で組んでみた。
実際は、間にL2SWやらFWが合ったりするのだが、面倒なので割愛。
↑の通り、クライアントとDHCPサーバは別セグメントにしているので、
ルータにはDHCPリレーエージェントの設定(ip helper-address)を設定しておいた。
一般のご家庭なら、こんな事やらないだろうが、
逸般の誤家庭なら、当たり前な気もする冗長構成なので致し方ない ﾍ(ﾟ∀ﾟﾍ)
ちなみに、上記の構成だとDHCPリレーは、
Primary/Secondaryの2つへパケットを投げる設定にした上で、
2台のサーバ間で払い出しアドレスの同期処理をしておく必要がある。
まぁ、厳密にはこんな事やらないでも冗長化出来るのですが… (´・ω・｀)
………
で、この構成を1週間程運用してみたのだが、今の所は何も無く平和に過ごす事が出来ている。
DHCPサーバを個別に立てる案件は少ないし、そもそもこんな構成取る方が面倒臭い物だが、
いつ何時使う事になるか判らないので、知識を蓄えておいて損は無いだろう。
« 続きを隠す
2016年05月14日(土) - 22:46 | カテゴリ:
Linux
DigiLoogが動いているサーバのPHPは今までver5.6を使っていたのだが、
そろそろPHP7にも手を出さないと技術追いつけぬと思ったので、
DigiLoog本番鯖のPHPもver7.0にアップデートしてみた。
…その結果、何年も前に作った自作モジュールがお亡くなりになって大変だったが良い経験が出来たとさ (゜∀。)
アップデート後、ns-labのトップページは問題無かった。
技術Wikiの方は、一部の自作モジュールがエラーを吐いていたが、修正して復帰 (｀・ω・´)
Wikiの方でエラーを吐いてる自作モジュールが色々とあったのだが、
その中でも多かったのが、eregとかmysql_queryを放置していた物。
これらはPHP7.0で削除されたので、そっくりそのまま関数が使えなくなってしまった。
PHP5.6に上げた時に修正しなかった過去の自分に対して… ( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ
削除された関数は、ちゃんと代替関数が用意されているので切り替えれば問題無いのだが、
微妙に仕様が変わっていたりして、単純に置換するだけでは無くデバッグがちょい面倒だった。
「ちゃんとマニュアルとかリリースノート読め」という良い教訓になった。
………
PHP5.6とPHP7.0の比較なのだが、上のような昔から非推奨指定されていた物が、
今回のアップデートで完全削除された以外は殆ど問題無さそう。
前から話題になっている動作速度もかなり改善されているし、
PHP7.0の時代が来る前にテストを行っておくのも良いかもしれない。
« 続きを隠す
2016年03月27日(日) - 16:25 | カテゴリ:
Linux
前回：ns-labのMTA鯖を拠点冗長化してみた
今までは↑の構成で問題無かったのだが、
昨日S氏とプライベートの待ち合わせをしている時に、
S氏「(自鯖に)メール送ったんだけど、届いていないっぽい」
自分「スパムフィルターで除外されたかな? もう一度送っておくれ」
S氏「送った。 どうよ?」
自分「届かぬ…」
というやり取りがあり、色々と原因をシミュレートしていた所、
修正前の構成ではVPNが切断された場合、メール配送が著しく遅延する事に行き着いた。
というのも、ConoHa側に着地したメールは固定配送(DNS指定)を切って、
ドメイン毎にVPNを通過させつつ、SpamFilterへ着地されている。
その為、VPN接続断の状態だとConoHaから先が無くて、ConnectionTimeoutになってしまっていた。
ちなみに、今までは固定配送先のDNSレコードを自動切り替えして対応していたのだが、
ここの所プライベートでも自鯖メールを使う様になり、
このままじゃマズイという事で、良い機会だと思って配送経路も冗長化してみた。
という事で配送経路を修正した結果がこちら。
経路上では難しい事はせずに、普通に迂回させる方針にしてみた。
|
|
|
通常配送
|
VPN障害時
|
普通の設計なら、VPNを安定化させて接続断を極力起こさないようにしたり、
そもそもVPNを経由させずにInternetで配送させる筈。
しかし、ns-labの場合はVPN-GWで少し細工したり、VPN接続性の実験を常にしている為、
通常のメールについても出来る限りVPNを通したい経緯があった。
………
試行錯誤している中で、固定配送を冗長化する設定で大きな問題が起きた。
それは、Postfixではmailertableの様に固定配送先を複数設定するのが普通は出来ないという事。
厳密には固定配送先が1つまでなら、"transfer_maps"のみで出来るけれど、
似たような事をするには、master.cfを弄ったりと面倒臭い事がわかった。
最終的にはmailertable相当の事が実現出来たのだが、
何故Postfixでtransfer_mapsを書く時に複数の配送先を指摘出来ないのが、
今回の設定を作る上でハマる要因の一つだった(´・ω:;.:…
………
メールとDNSは昔からある仕組みだからこそ、複雑だしいたる所にハマる要因があるのが怖い。
ns-labのメールサーバは特殊な構成だし、シンプル構成への組み替えを考える頃合いなのかもしれない。
…と言いつつ、複雑だからこそ判る事もあるので、このまま突っ走る予定ではありますが ﾍ(ﾟ∀ﾟﾍ)
« 続きを隠す
