これまではPHPの提供は、パフォーマンス重視ということでApache＋mod_php（モジュール版PHP）としておりましたが、セキュリティの向上、ユーザ利便性の向上を目的としてCGI版（FastCGI）に移行することになりました。実装としては、Apache+mod_fcgid+suEXECとなります。

また、CGI版への切り替えによるパフォーマンス低下が、最近のテスト結果からそこまで顕著ではなかった、或いは体感できる違いがなかった、むしろ速くなる場合がある事も切り替えの理由です。

逆に、Apacheが作成するディレクトリやファイルの権限が各ユーザ権限になる、（やろうと思えば）php.iniの設定もユーザ毎に切り替えられる、ユーザ毎の負荷状況が把握しやすいなど、利用面・管理面においてもメリットの方が大きいと判断しました。

というわけで、下記の日程で順次切り替えを行いますので、利用者の皆さんはご留意願います。

■作業内容
PHPの動作モードの変更
（mod_php → mod_fcgid）

■作業日程および作業範囲
①2012/02/19(日) ～25日(土)のどこかの時間帯でアカウント名の頭文字がa～mで始まるユーザ全員
⇒2/19(日)に対象ユーザについて全て完了しました。

②2012/02/26(日)～3/3(土)のどこかの時間帯でアカウント名の頭文字がn～z、0～9で始まるユーザ全員

■予想される影響範囲と対策
①ファイル、ディレクトリ所有者の問題
PHPを利用しているCMS等のアプリが、既存のApacheを所有者とするファイル、ディレクトリへの書き込み、変更、削除ができなくなる。
（パーミッションが707や606等、otherにも書き込みができていたものは影響なし）
⇒変更を実施したユーザのホームディレクトリ配下で、所有者がApacheとなっているものを対象に、所有者変更を一括して行います。（管理者作業）

②ホームディレクトリへ新規ディレクトリの追加
各ユーザのホームディレクトリに存在する、public_htmlやlogsなどの既存ディレクトリ以外に、新たに下記のディレクトリが作成されます。
・/etc
・/tmp
・/fcgi-bin

これらのディレクトリおよび配下のファイルは仕様上ユーザ権限での書き込みができますが、削除しないようご注意願います。(/fcgi-binについては削除、変更不可）

以上、当サービス開始以来初めての大きな仕様変更となってしまいご利用中の方にはご面倒をおかけしますが、ご理解いただきますようお願いします。

また、この変更によって新たに見つかった不具合等がありましたら、お手数をおかけしますがBBSやメールにて報告をお願いします。

その後、全てのユーザさんのデータベースのチェック・修復・アップグレードを行うコマンドである、mysql_upgradeを実行しています。

問題が出ている場合は早めにご連絡をお願いします。

本年もどうぞ宜しくお願いいたします。

昨年の震災の事もありますし、今年は素直に「おめでとう」と言えない気分でいます。

さて、いきなりですが明日（日付的には明後日）2012/01/09 00:00前後にサーバーのCPUを交換しますのでこの時間帯で30分～1時間のサーバ停止が伴います。ご利用中のユーザさんにはご迷惑をおかけしますが、ご理解下さい。

現在のAthlon LE-1640B 2.7GHzからPhenomⅡ X3 720 Black Editionに変わります。

何故今更このCPUかというと、書斎で使っているデスクトップPCの構成を一部変える事で、今回のCPUが余ったからです。シングルコアCPUからトリプルコアCPUに変わりますので、パフォーマンス的にはかなり向上するものと期待しています。

最近特にMySQL利用ユーザさんが増えてきて、負荷も増大してきたので丁度良いかも。

そもそもサーバ製品なので本当はサーバ用CPUにしたかったし、本来はサポートされていないCPUに交換するという事自体気が引けたのですが、まぁそこは個人サーバということである程度柔軟に考えたいと思います。

というわけで、交換後に動作確認、マルチコア最適化設定が必要であれば実施しますのでこの時間帯は不安定になると思います。

完了し次第またこちらで更新します。

[2012/01/09] 20:14 追記
01/09 01:00頃に全ての作業が完了しています。
本当はすぐに報告しようとしたんですが疲れていて寝てしまいましたので、ここに報告します。

全体的なレスポンス、ロードアベレージは改善されていると思われます。
abによるWebサーバベンチマークでも同時に処理可能なリクエスト数が増えています。

しばらくこれで様子を見てみます。

ずっとTwitterでしか進捗更新をしていませんでしたが、公式にも報告をしておきます。

今回の障害は、2011/11/23 17:40頃に外部サーバからの監視アラートが携帯に届き、障害を知る。

たまたま家にいたので調査の結果NICがリンクダウンしていたため、更に調査。

NICがどうやっても復旧せず、サーバ再起動を試すもシャットダウン後に電源が入らなくなり、どうにか起動するもBIOS画面がぐちゃぐちゃに。。

これらの現象からマザーボードの故障と判断し、部品の手配を始めましたがこのHP製のサーバ ML115 G5は結構前のモデルで流通量はかなり多かったはずなのに、中古でもあまり出回ってない事を知る。

部品の手配を諦め、サーバ本体を探し始め新潟のドスパラで中古を発見し、早速注文。

翌日の2011/11/26に届き、HDDを新サーバに引っ越し、無事復旧が完了。

停止時間としては2011/11/23 17:40～2011/11/26 16:40となっており、ユーザの皆さんには大変ご迷惑とご心配をおかけしました事をお詫びいたします。

現在は全てのサービスが復旧し正常に稼働しております。

おまけとして、余っていたメモリを追加し合計6GBでの運用となります。（4GB→6GB）

3年間以上ほぼ通電しっぱなしで運用してきたのでサーバも疲れがきたか。。

この教訓を活かし、早めに新しいシステムへの移行も考慮したいと思っています。

次回のシステムは現在のサーバをP2Vで仮想化しVMWareで管理していこうと考えていますが、いかんせん先立つものがないのですぐには実施できません。

またその時はこちらで報告します。

以上です。

■日時
2011/09/15 10:00-13:00の期間で60分程度

■内容

• バックアップ用HDDの容量増加に伴う交換作業
• サーバ筐体内清掃作業

完了した時点でまたこちらで報告いたします。

ご迷惑をおかけしますがご協力をお願いします。

[2011/09/15 14:30 追記]
予定通り10:20～11:00くらいの間で、HDD交換、フォーマット、筺体清掃が完了しました。
ついでにテストとしてディスクバックアップも実行しました。

2011/09/05　00:05現在、つながったりつながらなかったりしてると思いますが、これは試行錯誤の結果です。

これを機に本気でiptablesを勉強中です。
ルーターのスタティック/ダイナミックフィルタによるファイアウォールに加えて、Linux側でも”まじめに”実装しようと思ってます。

今のところひとまずは、サイバー攻撃上位を占めている国の中で日本、（わけあって）アメリカを除き、中国、韓国、台湾、ロシアの4つの国に関して、APNICの提供する最新のIPアドレス範囲を使って定期的にiptablesでアクセス拒否設定するよう、スクリプトを作成しているところです。

インターネットというグローバルなサービスの中でこのような制限をかけることは非常に悲しいことでありますが、これも自サーバを守るためには不本意ながら実施せざるを得ません。

これらの理由でやはりここ数日間、通信が不安定になる可能性があります。
また、新規利用希望のユーザさんの登録処理も少し滞っていますが、これが落ち着いたらまとめて手続きしますので、申し訳ありませんが気長にお待ちいただければと思います。

これはユーザが増えたとかというレベルではなく明らかに不正アクセスによるものと考えられます。
Webサーバのチューニングは以前より少しずつ行っていますがそれを遥かに超えるリクエストが来ています。

ハードウェアの新調も視野に入れないといけませんがこの状態が連日続くようであればファイアウォールでの対策も視野に入れようと思います。
ユーザさんにはご迷惑をおかけしますが、ここ数日は切り分け・テスト等で連絡なしにサービスを停止・稼働する事がある場合があること、予めご了承下さい。

[2011/09/03 22:00] 追記
とりあえず暫定処置としてスパムやDoS攻撃の多い国のIPアドレス範囲からのWeb/FTPアクセスを一時的に遮断しています。
しばらくこれで様子をみます。

PHP5.2.14→5.3.3となり、単純なバージョンアップができないため一度PHPとPHPライブラリを全て削除してからの新規インストールでした。
そのためWebサービスの停止が10分くらい発生しています。

その後色んな調整と確認で朝の4時くらいまでかかりましたが、以前から気になっていたPHPの5.3化が無事完了しました。

以上です。

■日時
2011/08/08(月) 09:00〜12:00頃

■事象
サーバへの通信断による全サービスの停止

■理由
ネットワーク専用UPSのバッテリ劣化による電源供給の停止。
サーバ専用UPSは動作していたため、サーバ自体は稼働していましたが、ネットワーク機器が全てシャットダウンしていたため通信ができていませんでした。

■対応
管理者が仕事で出ていたので、たまたま家にいた嫁をリモート操作し、ネットワーク用UPSのバッテリを経由せず、AC直結となるよう配線変更を実施。サービスの復旧を確認。
職場から（今の客先では個人PC使えないため）iPhone4を使いAmazonで交換用バッテリを発注。
翌日、早速届いた交換用バッテリを古いものと交換。正常動作を確認。

■考察
約2年前も同様の症状で落ちた記憶が。。
バッテリ劣化しても自動でACバイパスしてくれるUPSに買い替えようかなぁ

原因は、OSのアップデートパッチによるPerl関連ライブラリのアップデートにより、メールのウィルスチェックソフト（amavisd-new）が起動不良になっており、SMTPサービス的には稼動していたものの、メールチェック前で滞留し、配送ができていない状態でした。

今朝9時ごろその事に気付き、出先から苦労しながらｗ解決いたしました。
各メールユーザには数時間～半日遅れた形でメールが配送されております。

ご迷惑をおかけしました。