ラベル サーバー の投稿を表示しています。 すべての投稿を表示
ラベル サーバー の投稿を表示しています。 すべての投稿を表示

2015年4月23日木曜日

phpMyAdmin上の文字化け対策

EC-Cubeでショッピングサイトを運用しているお客さんのサイトをリニューアルするということで、ついでに既存のくたびれていたサーバーから新しいサーバーへのお引っ越し。

商品のデータベースはそのまま利用するとのことで、まずはPleskのマイグレーションを利用して新しいサーバーにまるごと移転させたのだが、データベースの編集を行おうと"phpMyAdmin"で開くとデータだけが文字化けして読めない状態。(Webサイト上では正常に閲覧できる)


Pleskのマイグレーション時にデータベースの変換ミスかとおもいきや、オリジナルのサーバーにあるデータベースも既に文字化けしていた...。orz

調べてみると過去EC-Cubeのインストール時、そのままMySQLデータベースを利用すると格納する文字コードがLatin1になって文字化けしてしまう事があったもよう。(憶測)
いずれにしても既に構築されてしまったデータベースが文字化けしているものは直す以外手立てがない。

今回以降すべてrootでのコマンド作業です。

1)まずは既存のデータベースのダンプを作成。
※Pleskの場合データベースユーザーパスワードがLinuxのシステムとは別に管理されているため、通常のLinuxパスワード入力方法ではアクセスが出来ないので注意が必要です。

# mysqldump -u [db_user] -p`cat /etc/psa/.psa.shadow` [db_name] > [db_name].sql --default-character-set=latin1

2)書きだしたデータベースの文字コードを変換。

# perl -pi -e 's/latin1/utf8/' [db_name].sql

3)mysqlコマンドでデータベースの作り直し。

# mysql -u [db_user] -p`cat /etc/psa/.psa.shadow`
mysql> drop database [db_name];
mysql> create database [db_name] default character set utf8;
mysql> quit

4)作りなおしたデータベースに文字コードを修正したデータの読み込み。

# mysql -u [db_user] -p`cat /etc/psa/.psa.shadow` [db_name] < [db_name].sql

とりあえずこれで"phpMyAdmin"から閲覧するデータの文字化けは直りました。


ただ今度はWeb上で表示するのデータが文字化けしてしまう状態になってしまったので、EC-Cubeの設定で文字コード(utf8)を強制指定して回避しました。

 参考になったサイト:EC-CUBEをMySQLで動かして文字化けが起こるとき(インディゴWEB研究室)

オリジナルのサイト構築時に既にしくじってたって事ですね...。
これで何とかWeb上でもphpMyAdmin上でも文字化けしないで閲覧できるようになりました。

2014年6月19日木曜日

ネットワーク障害

今朝(といっても10時過ぎだが...)出社そうそう上司が「Facebookの表示がおかしい」とMacBook Proを持って近づいてきた。

見てみるとFacebookのページがスタイルシートや画像を読み込めず、おかしなテキストだけの配列になっていたので、ブラウザーの「要素の検証」で見てみると、スタイルシート関連を格納しているサーバーへ接続出来ないエラーが出ていた。(接続出来ないというより、「サーバーが見つかりません」状態)

そういえば先週末に社内ネットワークがなんとなく遅いって事で、ルーターのDNSにGoogleのOpenDNS(8.8.8.8)を指定して様子見ていた事を思い出し、コンソール画面からlookupコマンドで確認を取ってみたところ、情報が取得出来たり出来なかったりと非常に不安定な状態。

Webサイトの「要素の検証」から確認してみるとアカマイのネットワークでホストされているものがほとんど全滅しているような状態で、"apple.com"のドメインまで閲覧出来ない状態に陥ってしまっていた。(そもそもOpenDNSはアカマイとの接続がいまいちらしいが...)

取りあえずGoogleのOpenDNSを全ての機器から削除&ルーター再起動して午後からはどうにかアクセス出来る状態になっていた。

ところが17:00少し前ぐらいから別のスタッフが「またFacebook繋がらないです」との報告があり、見てみると今度は完全にシステムがダウンしている様子。


ブログなどに埋め込んである「いいね」ボタンもエラーを吐いてるし、かなり大規模なシステム障害の模様。ただ、自社ネットワークの障害じゃないので気分は楽。ww

結局17:30過ぎくらいまで復旧しなかったのだけれど、ネットの情報見てもかなり大規模な障害だったみたい。

APIサーバーにも繋がらなかったし、全世界で繋がらなかったとなると"Facebook"のシステムというよりもっとネットワークの根幹で障害を起こしていたような予感...。
ま、個人的にどうにかなるレベルのものじゃないけどね。

サイバー攻撃によるシステム障害でない事を祈ります。
("人的ミス"ってのも企業にとっては大問題なんだろうけど、個人的には許せてしまうのです。w)

2014年5月15日木曜日

OS X Server の証明書期限切れアラート

5月に入った頃久しぶりにOS X Server(10.8.5)に画面共有で接続してみたところ、Serverプログラムに大量の「警告バッジ」が付いていることに気が付いた。


どうやら「各種SSL証明書の有効期限が切れている」って事らしいのだが、ヘルプとか調べてみてもあまり詳しい解説が見当たらない。

アラートの中にもそのまま「証明書の置き換えボタン」が付いている物もあったので、そのまま深く考えもせずポチッと更新して置いたのですが、本日また接続してみるとまだアラートの止まっていない物がある。


"証明書APSP"から始まる数種類の物がずっと期限切れのエラーを吐きっぱなし。
"APSP"が何の略なのかよくわからないけど「APSP」「証明書」で検索すると、同じ事例が大量にひっかかるので、Apple製品特有の証明書であることは間違いなさそう。

で、検索で最初にリストされていた"Bloggerさん"のサイトを参考に"キーチェーンアクセス"から期限切れの証明書をサクッと消して作業完了。
OS X Serverって毎年こんなメンテナンスが必要なんでしょうか?
たいした作業ではないけれど鬱陶しいですね。

2014年2月23日日曜日

Plesk Panel 11.0.x のアップデートエラー

管理しているホスティング用サーバーのインターフェースにPlesk Panel 11.0の入っているものがあるのだけれど、しばらく前からオートアップデートが機能しなくなっていた。

Panelへログインして「ツールと設定」からアップデート画面(8447ポートへの接続)を開こうとしてもブラウザは「サーバーに接続出来ません」のメッセージを返すだけ。

Parallelsのサポートページで検索してみると不具合内容が該当するエラーへの対象法が掲載されていたので同じように実行してみたのだが、どうも要領が獲ない。

Cannot start GUI autoinstaller: this webpage is not available

最初の確認項目である"autoinstaller"の起動チェックでは解説にあるとおり"ERROR: Installer is busy."を返してくる。

# /usr/local/psa/admin/sbin/autoinstaller --show-releases
Doing restart of Parallels Installer...

ERROR: Installer is busy.

要は旧バージョンの"autoinstaller"が起動しっぱなしになっていて新しく"autoinstaller"のタスクが起動できない状態になっているって事らしい。

単純に古いタスクを"kill -9"してしまえば動き出すって事なので解説の通り"autoinstaller"を"ps"コマンドで探してみたのだけれど、そんなコマンドは実行されていない...。orz

"autoinstaller"で引っかからないのならもう少し許容範囲を広げて"installer"で検索してみると...
ありました。"parallels_installer"って名前で実行されてます。

# ps ax | grep installer
30344 ?        SN    12:10 /var/cache/parallels_installer/parallels_installer_CentOS_6_x86_64 --select-product-id plesk --select-release-current --show-components --enable-xml-output

"kill"コマンドで該当するプロセスを落としてみると無事8447番ポートへの接続とインストーラーが起動するようになりました。
意外とちょこちょこと仕様変更がありますな...。

たった0.5のバージョン違いだけど、11.5の調子が非常に良いのでいっそ11.5にアップグレードしてしまおうか思案中。

2014年1月18日土曜日

OSX Serverの修復(AFP接続エラー)

木曜日の晩に「復元ディスクアシスタント」でなんとか復旧した"OS X Server"(Mountain Lion)だったが、金曜日の朝業務の開始時間まもなくスタッフより「ファイルサーバーに接続出来ません。」との報告が入る。

いや、そんなはずはない。OS再インストールでサービスが復旧したのは確認した。
ファイルサーバーへの接続が出来るかも当然確認した。
試しに報告をくれたスタッフのアカウントを使って自宅から接続してみたところ問題なく接続出来た。

連絡のあったスタッフに「入れないのは一人だけ?」と確認すると、その部署のメンバーは全滅との話。
そんな事は無いはずだと、事務所のMac miniへ"画面共有"で接続し、接続障害の出ているスタッフのアカウントでOSX Serverにログインしてみたところ、共有ボリュームがマウント出来ない。

???

特にエラーなどのアラートも出ないのだが、Finderのウィンドウには「接続出来ません」のメッセージが残るだけ。
再度自分のアカウントや、上司のアカウントを試してみると共有ボリュームに問題なくアクセス出来る。

どうやら特定のグループに属するアカウントだけがおかしな事になっている様子で、コンソールでログを確認してみると
2014/01/17 14:07:08.098 NetAuthSysAgent[85944]: NAHSelectionAcquireCredential complete: iakerb 708CD051-A6E4-3D8E-5833-C1FFF191FD01 - [username]: GSSCred: 0x7fb2fb6170a0 <MC: iakerb [username]@WELLKNOWN:COM.APPLE.LKDC>
2014/01/17 14:07:08.182 NetAuthSysAgent[85944]: AFP error -5014 mapped to EIO
のように"AFP error -5014 mapped to EIO"というエラーが出ていた。
検索してみると"5014"のエラー事例はそこそこ見つかるのだけれど、決定的な解決策が見つからない。
Appleのディスカッションサイトでは「AFPサーバーの初期設定ファイルを捨てたら治った」ようなコメントも見つけたので試してみたけれど効果無し。

ただ不思議な事に"Finder"のウィンドウからだと上記のエラーでマウント出来ないのだが、"Finder"の「移動」メニューにある「サーバへ接続(Command + K)」から接続するとエラーの発生するアカウントでも問題なく共有ボリュームがマウント出来るというおかしな状態である事も確認出来た。

こうなると、破損と言うよりはパーミション絡みのエラーっぽいので、OSX Serverの"DiskUtility"で再度「アクセス権の修復」を試みてみた。
すると思ったより共有絡みのファイルで「エラー&修復」のログがはき出された。
“Library/Preferences/com.apple.alf.plist”上のグループが一致しません。80 であるはずですが、グループは 0 になっています。
“Library/Preferences/com.apple.alf.plist”を修復しました
警告:SUID ファイル“System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent”は変更済みで、修復されません。
“System/Library/Frameworks/CoreGraphics.framework/CoreGraphics”上のアクセス権が一致しません。lrwxrwxrwx  であるはずですが、lrwxr-xr-x  になっています。
“System/Library/Frameworks/CoreGraphics.framework/CoreGraphics”を修復しました
“System/Library/Frameworks/CoreGraphics.framework/Resources”上のアクセス権が一致しません。lrwxrwxrwx  であるはずですが、lrwxr-xr-x  になっています。
“System/Library/Frameworks/CoreGraphics.framework/Resources”を修復しました
“System/Library/Frameworks/CoreGraphics.framework/Versions/Current”上のアクセス権が一致しません。lrwxrwxrwx  であるはずですが、lrwxr-xr-x  になっています。
“System/Library/Frameworks/CoreGraphics.framework/Versions/Current”を修復しました
“Users”上のアクセス権が一致しません。drwxr-xr-x  であるはずですが、drwxr-x---  になっています。
“Users”を修復しました
“Users/Shared”上のアクセス権が一致しません。drwxrwxrwt  であるはずですが、drwxrwxrwx  になっています。
“Users/Shared”を修復しました
修復後は問題のあったアカウントも問題なくアクセス出来る様になったため、結果としてはパーミッションエラーであったことは間違いなさそうです。

意外とGUIが起動できなかったのもパーミッションの問題だけだったような気がします。
長い時間かけてOSの再セットアップなどする前にシングルユーザーモードで起動して"fsck"コマンド試してみれば良かった。

ま、同じ失敗しないように備忘録です。

2014年1月17日金曜日

OSX Serverの修復

どうも「iPhoneライブラリ」のサーバー共有がいただけない。

そもそも270GBオーバーのライブラリを共有しようってのがそもそもの間違いなのかもしれないけれど、正規の手順でiPhoneを終了させなかったりネットワークが途中で切断されたりした場合に、かなりの確率でライブラリを破損させる。

ライブラリの破損だけならiPhotoの問題だけなのだが、重傷な場合なぜがHDDのエラーも引き起こし(今回2回目)ハードディスクのメンテナンスまでしなければならない状態に陥る。(ハードディスクのエラーと言っても、一旦再起動してマウントし治すとエラーは出なくなるので、やはりiPhotoの異常なHDDアクセスが原因なのではないかと思っている。)
【DiskUtility log】
+0900: ジャーナルをリプレイする必要がありますが、ボリュームが読み出しのみに設定されています
+0900: ジャーナリングが有効な HFS+ ボリュームを確認中です。
+0900: エクステントオーバーフロー・ファイルを確認中です。
+0900: カタログファイルを確認中です。
+0900: スレッドレコードの数が正しくありません
+0900: リーフレコードカウントが正しくありません
+0900: (正しい値 1411601、不正な値(現状)1411600)
+0900: マルチリンクファイルを確認中です。
+0900: カタログ階層を確認中です。
+0900: スレッドレコードが見つかりません(id = 1166753)
+0900: ディレクトリの項目カウントが正しくありません
+0900: (正しい値 118、不正な値(現状)117)
+0900: 拡張属性ファイルを確認中です。
+0900: ボリュームビットマップを確認中です。
+0900: アロケーション不足のため、ボリュームビットマップに若干の修復が必要です
+0900: ボリューム情報を確認中です。
+0900: ボリュームヘッダに若干の修復が必要です
+0900: ボリューム“Data_HD1”が壊れています。修復する必要があります。
+0900: エラー:このディスクは修復する必要があります。“ディスクを修復”をクリックしてください。

で、今回またもやライブラリにどうしてもアクセス出来ない状態に陥ったためDiskUtility.appでHDDを検証してみると、結構酷い報告をされたため取りあえずOS X Server自体を再起動する事にして、ついでにしばらく適応していないいくつかのアップデータなどを充てて再起動を実行した。

いつも通りアップデート作業が進みシャットダウン。Mac特有の起動音とともに再起動が始まりグレーバックに林檎マークが現れ......。

....。?!

待てど暮らせど一向にログイン画面が来ません。(T_T)
レインボーカーソルがクルクルと回り続けているだけ...。

かな〜りヤバい感じなのだが、念のためSSHでログインを試みてみると、あっさり接続出来る。
デスクトップのMac miniから共有ボリュームにアクセスしてみても問題なく接続出来る。
どうやら各種サーバーサービスは起動しているようで、GUIのウィンドウサーバーだけが起動出来ない状態に陥ったもよう。

何度かコンソールからリブートかけてみたのだけれど一向に解決しないので意を決してOSX ServerのOS再インストールに踏み切ることにした。

実は10.7以降メディアの供給がなくなったMac OSの初めてのリカバリーセットアップだったので、ちょっとドキドキしながら起動音後に"Command + R"を押したままにして「復元ディスクアシスタント」を起動させる。

アップルのサポート情報にもあるとおり、「OS X の新規コピーをインストールし、同時にファイルと設定をそのまま残すことができます。」である事を信じてOSの再インストールを30分ほどかけて完了させた。

OSのインストールが終わって再起動。祈るように画面を見つめていると...来ました。デスクトップのログイン画面。

共有ディスクのマウントやリモートログイン、その他もろもろのサービスに接続出来ることを確認して何とか復旧させました。
なんとか明日の業務に支障をきたす事を避けられた安堵感に包まれながらその日は事務所を後にしたのです...。(明朝発覚するトラブルがあることも知らずに...。)

後半へ続く

2013年9月5日木曜日

メールサーバースパム被害

マジ散々な一週間だった...。

それは一件のユーザーからの問い合わせで発覚。
「送ったメールがなかなか先方に届かない」との問い合わせだった。

メールサーバー(ゲートウェイ)のモニターグラフを見て愕然。毎分700通ほどのメールが着信している。
しかも外部からスパムが大量に送りつけられているかと思いきや、内側から配信しようとしている状況だ。

すぐさまLAN内のサーバーで大量のメールを発信しているサーバーを特定しメールのログを確認。ログも膨大なサイズに肥大していて閲覧するのも辛いほど。

サーバーはSMTP-AUTHのみ接続を許可され、不正中継をしていないことは確認できたのでSMTPユーザーのセッションを洗い出してみる事に。
以下のコマンドで"smtp-auth"で接続したユーザーアカウントだけ抽出して回数順にソートして並べてみる。

# cat /var/log/maillog |grep -I smtp_auth |grep -I user |awk '{print $11}' |sort |uniq -c |sort -n

ログのローテーションから10時間ほど経っていたのだが、普通多くても数回程度のSMTP接続が、1つのユーザーアカウントだけ数分おきのインターバルで500回近く接続している。
そのアカウントに的を絞ってIPを調べてみると、市内のフレッツ光ユーザーなのに接続しているIPアドレスは全て"ロシア"、"ウクライナ"や"ベラルーシ"など旧ソ連諸国や東ヨーロッパからの接続。

緊急的に該当ユーザーアカウントのパスワードを変更しログを注視して見ているとそれ以降"smtp-auth"接続エラーで配信されることはなくなった。
問題なのはユーザーアカウントがどこで盗まれたのかなのだが、調査してもサーバーから漏れた痕跡はないし、それ以外のユーザーアカウントが利用されていないので、ユーザーのPCがフィッシング等にあった可能性が高いと判断している。

その後ゲートウェイ(スパム、ウイルスフィルタ)に詰まった4万数千のキューと、該当ユーザーが利用していたメールサーバー内に拒否されて配送待ちになっていた45万ほどのキューの処理...。

正直そんな大量なキューを分類し削除処理していては時間がかかりすぎるため、一旦詰まったキューのディレクトリ丸ごと切り離し、空のキューフォルダと差し替えて送信サーバーの復旧を計る。

問題なのはそこからで、分離したキューを掃除して正常なメールだけを再送しなければならないのだが、Postfixで運用しているメールゲートウェイはどうにかなりそうなものの、アカウントを盗られた該当サーバーはQmailは運用されていたためキューの管理が煩雑な上45万件という膨大なキュー...。

Postfixのキューは"incoming"ディレクトリで一元管理されているため意外と処理が楽なのだが、Qmailの場合queue以下に"info","local","mess","remote"(他にもいくつか)などのディレクトリに別れ、それぞれに情報が格納されているためディレクトリ間の情報がおかしくなるとqmailのログにこれまた大量のエラーが吐き出されるようになる。

壊れたqueueを修復してくれる"queue-fix"( http://www.netmeridian.com/e-huss/queue-fix.tar.gz )なるツールも存在したので試してみたのだけれど、逆にqmailのシステムがエラーコード65を吐いて出て全くメールの送信が出来なくなってしまったため、やむなくqueue以下のフォルダを全て削除&新規作成して復旧させた。

#  cd /var/qmail/
#  mv queue queue.orig
#  mkdir queue
#  chown qmailq:qmail queue ; chmod 750 queue
#  cd queue
#  mkdir mess
#  for i in `seq 0 22`; do mkdir mess/$i ; done
#  for d in info intd local remote todo ; do cp -r mess $d ; done
#  chmod -R 750 mess todo
#  chown -R qmailq:qmail mess todo
#  chmod -R 700 info intd local remote
#  chown -R qmailq:qmail intd
#  chown -R qmails:qmail info local remote
#  mkdir bounce pid lock
#  cp -a ../queue.orig/lock/* lock/
#  /etc/init.d/xinetd start
#  /etc/init.d/qmail start
#  chown qmailq:qmail pid lock
#  chown qmails:qmail bounce
#  chmod 700 bounce/ pid/
#  chmod 750 lock

今回のスパム送信者は数通の配信で接続先(IP)を変え、本文もランダムに変えるし送信者もでたらめなアドレスを生成させるといった手の込みようで、一定のキーワード検索では抽出が困難になるようなメールを生成していた。

Qmailはキュー管理用の様々なツール("qmail" "キュー" "削除"等でググってみた)を使ってみたけどあまりの時間のかかりように途中であきらめました。

色んな国から大量の接続を経由して配信しているって事はかなりのPCが踏み台にされてるんだろうなぁ...。一つのIPからだとたいした数のスパムを配信してないのでまったく気付かない人も多いと思う。orz

結局今回は丸3日ほど処理作業に振り回されました。なんだか段々手強くなっていくなぁ...。(T_T)
ホントいい加減にして欲しい。

2013年6月6日木曜日

Mountain Lion(10.8) Server運用インプレ

ゴールデンウィーク中に置き換えた社内用ファイルサーバー。

利用していたFileMaker Server 8の互換問題でなかなかリプレース出来ず、Tiger(10.4)から4世代飛びでMountain Lion(10.8)へのアップグレード。

古いマシンも多く稼働しているため最新のOSが入ってくると、なかなか運用が面倒な事も多い。

先ず一番最初につまずいたのは、「Mac OS X 10.4.x(Tiger)以下では日本語名の共有ポイントがマウント出来ない」って事。

(サーバーには繋がるんだけど...)
(マウントができない...。(T_T))

これに気付いたのは外注さんとのデータ受け渡し用の共有フォルダに日本語名を付けたのが発端だったのだけれど、この場合は相手が一人なので素直に共有名を1バイト文字に付け直して事なきを得た。

ただ、困ったことに社内にも一台10.4で運用しているマシンがあって、これはOS9で稼働している端末との中継役を担っていた。
既に10.6以降でAppleTalkが廃止されているので、こういった中継機が無いとOS9とデータのやり取りができなくなってしまう。

かといってこの端末1台の為だけに全て英語表記のファイル共有名にするのもせっかくサーバーを刷新した恩恵も薄れる...。(インターネット周りのサーバーは問答無用で1バイトオンリーですけどね。)

Illustrator3.3やPhotoshop6の為にClassic環境も入っていたんだけど、もうさすがに動かすことは無いだろうって事で、この中継機を10.4(Tiger)→10.5(Leopard)にバージョンアップすることに決定。

ところがこの10.4マシン、PowerMacintosh G4(AGP Graphics)....。
CPUスペックがPowerPC G4 400MHzしかない。(よくこんな端末動かしてるなwwwwww)

ところが10.5(Leopard)の最低動作環境は"PowerPC G4"だと867MHz以上のクロック数が必要だそうで、インストールスクリプトが拒絶する。(T_T)
周りを見渡すと床に放置されていたPowerMacintosh G4(QuickSilver)が有ったので、こちらにHDDを移植して起動。(こういうところ、Macは便利だよねぇ)
「このMacについて」を確認してみると、"PowerPC G4 800MHz"しかない...。w


もう、八方ふさがりかと思いきや、ネットで検索してみると"推奨環境を満たさないマシンにLeopardをインストールする"為の騙しソフトが配布されているのを発見。


どうやらこのアプリを立ち上げて再起動すると、CPUクロックを933MHzに偽装してインストーラーを騙してくれるツールのよう。
5年以上も昔に必要とされたツールなので、詳しい内容ははしょります。ww



そんなこんなで、PowerMac G4に10.5をねじ込んで無事全ての端末からOSX Serverの"日本語名"共有ポイントがマウント出来る様になりました...。

【後日談】
ただ、せっかく苦労してインストールした10.5(Leopard)だったのに、その後10.6(Snow Leopard)使いのスタッフから不具合報告があった。

「あの〜、サーバー内のファイルがSpotlightで検索できないんですが...。」
「なんですと?!」
(それこそSpotlight検索ができないOSX Serverなんて"ク○ープを入れないコーヒー"みたいじゃないか!!。(古!!))

確認したところ、10.6.x以下のOSでマウントされたサーバーボリュームをSpotlight検索をかけてみると、"検索中"のまま検索結果が得られない状態に陥る。(エラーは出ない)


いろいろと検証してみたところ、英語表記(1バイト文字)から始まっていれば、日本語が含まれるのマウントポイントでも問題なく検索できるのだが、全てが"日本語表記"のマウントポイントだとサーバーのSpotlightインデックスにアクセスできないみたい。(とうぜん10.7.x以降のOSではフル日本語共有名でもOK)

こればっかりはどうにもなりません...。
スタッフ全員に「ロゼッタ捨てて、みんな10.7(Lion)にアップグレードしましょう」とはとても言えない...。orz

結局10.6.x以下のシステム使いがいる部署の共有ポイントは全て英語表記にしましたとさ...。めでたし、めでたし。orz

「しょせんアメリカ人が作ったコンピューターシステムだし、こんなもんか...。」とは思ってみても、なんとなく納得いかないぞ。
(#゚Д゚)ゴルァ!!


2013年5月7日火曜日

ゴールデンウィークにファイルサーバー更新

今年のゴールデンウィークはいろんな意味で忙しかった。

前半は月末の検収作業で図面の仕上げに追われ"休み"どころでは無かったし、後半連休は会社の共有サーバーのリニューアルの為、スタッフが休みに入った3日に敢行。

社内の共有データベースを"FileMaker Server 8"で運用していた関係上、ハードもPower Mac G5から更新できずにいた。

クライアント側のハードスペックが上がるにつれて"FileMaker Pro 8"では運用できない状態になってきており、データベース仕様に互換性が無くなった"FileMaker Pro 12"に置き換える都合でサーバー本体と"FileMaker Server"もめでたく更新となりました。

社内の端末が90%ほどMacな会社なので、当然サーバーもMacで行きます。
昔は"PowerMac" or "Mac Pro"をサーバー機に検討していましたが、今は"Mac mini"に"OS X Server"が最初から入っているのがラインナップされているので、そちらをチョイス。

"Core i7(2.3GHz)"のCPUは、スタッフ数20〜30人の企業であれば全く運用には問題ないです。一応メモリは16GBに増設しました。今時1万円も出せば購入出来ますからね。

コンパクトなPCでは不利だった記憶媒体周りも、今の"Mac mini"では"ThunderBolt"のインターフェースもあるし、外付けのRAID用意した方が後々の運用も楽ちん。

"PowerMac G5"の時からデータ運用は外付けRAIDだったので、データの移行は接続し直すだけで完了。アカウントを必要なだけ作成してグループを作成。
あとは共有ポイントを作って、ユーザーのアクセス件ごとに割り当て。

ちょとつまずいたのは"FileMaker Server 12"でのデータベース公開。
インストール及びセットアップはあっという間だったのだが、8→12へコンバートしたデータベースを公開しようと"データベースのアップロード"ツールを使ったのだが、データベースの選択ウィンドウにあるべきデータベースが一切見えない。

調べてみると、"Java 7"では日本語表記のファイル名が選択出来ない様子。
Java 7 for Mac OS X: [データベースアップロードアシスタント]で、全角文字を含むファイルを選択できない
"Java 6"では問題ないみたいなんだけど、"FileMaker Server 12"の最新版がすでに"Java 6"をサポートしていようなので、諦めて手動アップロードでデータベースを設置。

特にツールでのアップロードにこだわったわけでは無いのだけれど、パーミッションやらなんやら自動的にセットしてくれそうだったしね。手を抜こうと思っただけ。

取りあえずデータベースが共有出来たことを確認して、アカウント毎の共有ボリュームの見え方をチェック。
外注さんとデータの受け渡しに使っているフォルダもあるので、余分な場所まで見えてしまっては困ります。

ここでも一つつまずいた。
全てのアカウントでサーバーに接続、ファイルの閲覧が出来ることを確認したのに、連休明けて業務を再開した途端市内の印刷工場から「データサーバーに接続出来なくなってしまったんですけどぉ...?」との連絡がはいった。

電話でやり取りしいてもラチがあかないので、車で数分の外注さんまで出向いて状況を確認してみたところ、「サーバーに接続〜ユーザー名・パスワードの入力〜共有ポイントの選択」まではちゃんと進むのに、その後「オリジナル項目が見つからないため、操作を完了できません。」とエラーが出てマウント出来ない。
そのまま現場でいろいろ試しても状況は変わらず、諦めて会社に戻って検証。

外注さんが利用していた端末と同じ"Mac OSX 10.4.11"で稼働しているMacを探しログインしてみると同じようにエラーが出てマウントできない。

実は今回のサーバーリニューアルで、分かりずらかったマウントポイントの表記を日本語に変えたのだが、これがまずかった。
10.5以降であれば問題なくマウント出来るのだが、10.4以前のOSでは日本語の共有ポイントは接続出来ないことが判明。(実パス名は1バイト文字だが、Server設定で共有ポイント名を日本語にしている)

その外注さん向けの共有ポイントだけ以前の通り英語表記の1バイト文字にして無事接続が出来ることを確認。(WindowsだとXPですら問題なくマウント出来るのにねぇ...。)

思ったよりあっけなく完了したMacサーバーの更新作業でした。
新しいMacサーバーは"Spotlight Server"機能もあるし、業種柄写真データなども大量にストックしているので、あらためてファイルの管理が楽になる運用方法を検討した方が良さそうです。


2012年9月22日土曜日

VMwareゲストのフラグメンテーション

サーバーも仮想化技術が進んだお陰で、保守や引っ越しなどが格段に楽になった今日この頃。

今週末は調子の悪くなったサーバーの引っ越し作業にすったもんだして、二晩連チャンの徹夜作業になってしまった。

木曜日の夜の作業で、サーバーを別のサーバーへそっくり引っ越す作業だったのだが、4GBのデータを移動させるのに通常であれば2〜3時間程度で終わるはずなのに朝(8時間経過)になっても半分も取り出せない。

結局、クライアントのサーバーを日中止めるわけにも行かないので、作業を中断しグダグダのサーバーのまま再度運用再開。orz

実質"300MB/時間"程度しかデータの読み出しが出来ていない状態。(T_T)
ビットレート換算だと680Kbps程度か? 10Mbps帯域保証のネットワーク回線でのコピーが680Kbpsってどういう事??

で、原因を突き詰めていってどうも怪しいのは"VMware"の仮想ボリュームという結論に。
大半のWebサーバーはParallelsの仮想化ソフトで管理しているのだが、いくつかのサーバで"VMware Server"を利用して仮想サーバーを構築している。

無償のソフトウェアを使っておいて文句言う筋合いじゃないのだろうけれど、特にSQLなどのデータベースが頻繁に読み書きするWebサイトを"VMware Server"上に構築すると、時間と共にレスポンスが段々悪くなってくるみたいだ。

どうやら細かな読み書きが多発するコンテンツは"VMware"ゲストの仮想ボリューム(.vmdkファイル)がかなり重度なフラグメンテーションを起こすらしい。

このフラグメンテーションが進んでいくと、CPUもメモリも十分余裕があっても、HDDの応答待ちだけでかなり時間がかかるようになってくる。
結局サーバーがグダグダなのは、サーバーリソースなどの問題ではなく、"WMware"の仮想環境にあったわけでした。

ただ、容量が変動する仮想ディスクでなく、固定の容量で構築していればこのような酷い状態にはならないようで、構築時にしくじっていたという事実も判明。

いずれにしても中身を抜かないと再構築も行えないので、翌日の晩にリベンジの引っ越し作業を敢行。

まずはHDDの読み出し速度を正常化させないと仕事にならないのでホストへ"ssh"でログインした後メンテナンスコマンド(-d)で仮想ディスクのデフラグを実行。
# vmware-vdiskmanager -d [ゲストOS名].vmdk
20GBほどの仮想ボリュームは15分ほどでデフラグ完了。(早!!)

早速マイグレーションでコンテンツの引っ越しも実行。
「うん、普通に転送速度が出るようになった。これなら3時間もあれば全ての作業は完了できる。後はマイグレーション完了後にDNSを書き換えて新しいIPへ振るだけ...。」
の、予定だったのだが前日の徹夜がたたって、うたた寝...。ww

気付いたときには、すでに5時近くになっている。
慌ててDNS書き換えたものの、2時間ほど経ってもレコードのキャッシュを書き換えてくれないDNSもチラホラ...。(自宅のフレッツ光-NTTPCもそうだった)

しょうが無く、古いIP側のhttpdも動かして"vhost.conf"にProxy転送設定を書き込んで強制的に新しいIPへ転送する事に。
ProxyPass / http://[新しいIP]/
ProxyPassReverse / http://[新しいIP]/
久しぶりに冷や汗ものもサーバー引っ越し作業となりました。
その後、娘の運動会会場へ出向きテントの下で爆睡してしまいました。orz

【追記:備忘録】
デフラグ前に使用する"vmware server 2.0"用コマンドライン

・ゲスト一覧取得
# vmware-vim-cmd vmsvc/getallvms

・ゲストOS起動
# vmware-vim-cmd vmsvc/power.on [VM id]

・ゲストOS停止
# vmware-vim-cmd vmsvc/power.off [VM id]

・ゲストOS再起動
# vmware-vim-cmd vmsvc/power.reboot [VM id]

・ゲストOSサスペンド
# vmware-vim-cmd vmsvc/power.suspend [VM id]

2010年3月30日火曜日

Webサイト改竄

 今日は一日振り回されました。(ToT)

 関係企業のWebサーバーが"TheWayEnd"によって攻撃されてしまいました。

 攻撃されたサイトではosCommerceを利用されていたのですが、調べてみるとこのシステムに脆弱性が見つかっているので、この脆弱性を攻撃されたようです。
▽ osCommerce--------------------------------------------------------
 WebベースのEコマースプログラムであるosCommerceは、"ドットドット"を含む細工されたHTTPリクエストをfile_manager.phpスクリプトに送ることで、ディレクトリトラバーサルを実行されるセキュリティホールが存在する。この問題が悪用されると、リモートの攻撃者に任意のファイルを閲覧される可能性がある。
 2004/05/19 登録

 危険度:中
 影響を受けるバージョン:すべてのバージョン
 影響を受ける環境:UNIX、Linux、Windows
 回避策:公表されていません
 結局osCommerceのfile_manager.php(アップローダー?)を利用して不正ファイルを設置したようで、"images"ディレクトリ以下に各種ファイルをアップしてそこを拠点にリモート制御で改竄可能なディレクトリ(777)を探しながら「ハックしましたよ!」みたいなメッセージファイルを置いていった模様。

ちなみに設置されていたファイル群は以下のようなものでした
2.6.9
2.6.9-22
2.6.9.1
2.6.c
Linux-2-6-9 <--ここまでカーネルハック用ツール? 
dee.php <--リモートシェル!? 
hacked
nec0.php
twe.html <--よく見かける犯行声明ファイル 
twe.php
twee.php
 "TheWayEnd"によるWeb改竄は日本でも今年1月くらいからかなり増えている様子で、osCommerce以外にもWordPressのwp-config.phpファイルを改竄する手法もあるようです。
 独自サーバーでWebサイトを運営している皆さんくれぐれも注意して下さい。

あと、777のパーミッションは極力割り当てないようにしましょう...。