DigiLoog

続きを読む »

なんでLinux機なのにGUI環境を構築したのかと言うと、
今まで使っていたLinuxノートPCを廃棄した為(´・ω・｀)
だけど、GUI環境が全く無いのは勉強とかするのに不便なので、
「RDP環境を作って、リモートGUIすれば良いじゃね～か」という結論に至った為。

普通、Linux機にGUI接続するのなら、VNCを使うべきなのだが、
クライアントを入れないとダメだったり動作遅かったりで、
VNCはあまり好きじゃなかった後押しもあり、今回真面目にxRDP環境の構築をやってみた。
だが、xRDPは内部的にVNCを飛ばしていたり、
ローカルリレー用のポートを全部使い果たす(普通使い果たせないが…)と新規で接続出来なくなったりするが。

本職で入れる事は、ほぼ無いと思うが「ま～、自鯖だし」というレベルでは結構好調に動いている。
残るはソースからのビルドインストールだが、どうやってもビルドが途中でコケてしまうので、
時間ある時にじっくりと取り組んでみよう。

« 続きを隠す

続きを読む »

※ここから先は、解釈・解説を間違えていてもあしからず(´・ω・｀)

↑の通り、https(SSL)とかも問題無かったので安堵していたのだが、
毎週の楽しみであるエ○ゲブランドのサイトを巡回していた時に問題は起きた。

それは、SquidでHTTPのChunked Transferを処理するのにミスってしまい、
cache.logに「Exception error:corrupted chunk extension value」が出るという物。

ちなみに、これが発生したサイトは↓

• ハナヒメ*アブソリュート！
• MORE OFFICIAL WEBSITE

※サイトが悪いのでは無く、Squidの処理でコケてしまっている模様な点に注意

………

Squidを介さないとサイトを普通に見れるので、原因がSquidにあるのは明白。
という事で、パケットキャプチャとか、Web開発ツールを駆使してヘッダ情報を見ていくと、
どうやら、特定条件下で「Transfer-Encoding: chunked」になると、
Squid4.0がおかしくなるという所までは判明。

同様のエラーだと「Exception error:corrupted chunk size」という物は見たことがあるのだが、
今回は「extension value」なので↑のエラーとは別物だし当初は色々と情報を仕入れるのに大変だった。
しかし、ソース見たりとかググったりしていると、Beta版故のエラーという事がなんとなく判明。

Squid3.5とSquid4.0のソースをdiffすれば、該当箇所の修正方法もわかるのだろうが、
ここまでトラブルシュートする中で、そこまでやる気力が無くなってしまい、
最終的にはSquid3.5に戻して、ns-labのGatewayProxyは正常系に戻ったのでしたとさ。

………

Squidはメジャーバージョンが上がる毎に、様々な箇所の仕様が変更されるので、
本来はちゃんとテストした上で上げるべきなのだろうが、そこは自鯖という事でご愛敬。

何はともあれ、BetaはBeta故の理由があるという事を改めて学習した昨今でした。
…以前はBetaデバッガーやっていたが、そんな気力も何処かへ吹き飛んでしまった

« 続きを隠す

続きを読む »

今回HDDを交換するにあたって、ついでにKVM領域の拡大もやってみた。
と言ってもresizeしただけなので、ジャーナリングFSの変更は無しで。

今回購入したHDDは↓の4点。

• TOSHIBA – DT01ACA050
• Seagate – ST2000DM001
• Seagate – ST2000VN000
• WD – WD20PURX

『RAID組むのに、違うHDD使うとかわかってね～な』と仰る方。
Exactly。まぁ、こんな構成には理由がありまして…(´・ω・｀)

何故違うHDDメーカを組み合わせてRAIDを組んでいるかと言うと、
以前、SG製HDDで発生したファームウェア問題で、
自宅のRAID組んでいたHDDが一度に全滅した苦い経験がある為。

ガチの本番環境なら、RAID1+0とかで組むのでリスクも減るのだろうが、
ns-labの自鯖は仮想環境共存の為とか、録画鯖とかの為にわざとRAID1を2発にしている為、
ファームなどどうしようもない箇所での故障に備える為に、
HDDのメーカをずらしてRAIDを組むようになったのでした。

………

他にも、自鯖のNICが足りなくなったので、4ポート物に載せ替えてみた。
今までは2ポートNICを増設していたのだが、
流石に仮想環境を何個も作ると足りなくなってしまい…
ちなみに、お役御免になる2ポートの方は次の用途があるのでそっちに転用。

………

内容をHDDの方に戻して…

今回はSoftwareRAIDなので、mdadmとsfdiskを使ってパーティションコピーを行った。
今まで、ここまで大がかりなHDD交換は行った事が無かったので、
手探りしながらの作業で非常にヒヤヒヤだった(；´Д｀)

参考サイト様
　　トヤヲ・ネット – mdadmのRAID再構築
　　うまいぼうぶろぐ – sfdiskでパーティション情報のコピー

………

実は、一番ハマったのがパーティション情報のコピー操作だった。
mdadmは、以前LinuxでNAS相当を構築した時に色々触っていたので、まぁなんとかなった。

普段は、fdiskを使ってパーティションを切っている筆者なのだが、fdiskを使うと↓写真の様に、
パーティション1とパーティション2の始点と終点が同じ値を取る切り方が出来ない様になっている。

対処方法をググると、partedを使ったり、ddで直ダンプしたりと色々出てくるのだが、
partedは使った事無いし、取り替えたHDDは電源入れられないので、他の方法を使う必要があった。
という事で、出逢ったのがsfdiskを使って、
生きている方のHDDからパーティション情報のみダンプする方法。

例えば、
"/dev/sda" のパーティション情報を "/dev/sdb" にコピーして、
"/dev/md0" のデータを "/dev/sdb1" にコピーしてRAIDアレイの修復も行う場合、
　　[# sfdisk -d /dev/sda | sfdisk /dev/sdb –force]
　　[# mdadm /dev/md0 -a /dev/sdb1]                
を実行すれば、HDD容量にもよるのだが数時間で処理が完了する。

………

という事でRAIDのリビルドも無事完了し、
"www.ns-lab.org" の乗っている仮想鯖も新HDDで絶賛稼働中。
今の所はエラー無く安定稼働しているので、一安心という所( ´Д｀)=3

そしてNICも増設したし、仮想を動かすHDD容量もなんとか算段ついたので、
ロードバランサをLinux上で構築しフロントを全部ロードバランサに任せたり、
本気のライブマイグレーション環境を構築したりと、
今後の自鯖で行う事が目白押しになった[ns-lab BB]でした。

« 続きを隠す