|
Ｔ-４の整備日誌v2Ｔ－４の徒然なる駄文
|
本サーバから外部への接続を PROXY していたりする サブサーバの kotona が パッケージのメジャーアップデート後に本サーバからのSNMPでの監視に応答しなくなっていました。
/etc/default/snmpd の SNMPDOPTS において 127.0.0.1 (ループバック)以外から応答しないようになっていたためです。セキュリティ上、デフォルトではこうなるようで、アップグレード時に書き換えられたようです。
現在は書き換えて、外部(内部LAN)からの問い合わせにも答える事を確認しています。
グラフも書き換えられました。
PHP 5.2.5 がリリースされていましたので、適用しました。 リリース
特に問題はないと思われますが、異常があった場合はお知らせ下さい。
2007 年 11 月 1 日(米国西部時間)、インターネットの基盤を支えるルートネームサーバの1つ、「L.root-servers.net」のIPアドレスが変更になりましたので、これに対応しました。
旧 IP アドレス: 198.32.64.12
新 IP アドレス: 199.7.83.42
これに伴いヒントファイルを置換し、DNSサーバを再起動しました。
詳細はJPRSの「L.root-servers.net の IP アドレス変更に伴う設定変更について」についてをご覧下さい。
MediaWikiのバージョンを1.11.0にあげました。特に障害は無いと思っています。
週末に、某巨大写真機に行ってUPS(無停電装置)買ってきました。鉛蓄電池内蔵だけに持って帰るのが重たかった(約6kg)です。祖父地図にも昔は置いてあったのですが、一般ユーザには普及がイマイチなのか、何時の間にか取り扱い品目から消えていました。他の店に行くとサンワサプライとかの一般向けのUPSはあるのですが、こいつらは協調機能(停電時に連携してシャットダウン処理をする)がなかったりして、役に立ちません。国産だとオムロン、外国産だとAPC等がメジャーですが、置いてないんです。
巨大写真機はあんまり好きじゃないんですが、ここにしか置いてなかった。悲しい。
UPSの一台は鯖に接続されていて、不意の停電から保護していますが、サブ鯖とか重要度が少し低いのにはつけていなかったので、この際にと。
カーネルのメンテのついでにサクっとつないでしまおうと思いましたが、根元で付け替えると容量不足。750VA品だったらいけたようですが、ピーク時に105%負荷とかになってよろしくない。配線を考えないといけなくなりましたが、付け替えるとなると長時間になるので今回はパス。
いずれ半日程度鯖も含めて停止して電源工事をしますので、その時はご協力のほどを。
急ではありましたが、カーネル保守のため20:35頃から20:57頃にかけてサーバを再起動しました。
普通は数分で再立ち上げされますが、一部のディスクシステムのチェックが走っために予想外に時間が掛かりご利用の皆様にはご迷惑をおかけしました。ディスクチェックの結果は正常です。
つい先ほど、カーネルアップデート、リリース4.5への移行、Xサーバの更新に伴い、サーバを再起動しました。
Webアクセス、FTP、DNS、メールともに特に問題は確認されておりません。
僅かですが、Webサーバの設定を変更しました。
殆ど影響はないはずですが、Cookieの受け入れを完全に拒否していると、セッションを使用しているページは見れなくなる可能性があります。デフォルト拒否の人でもセッション関係のCookieは受け入れてください。
このサーバのLinuxシステムが、昨夜の定期アップグレードで相当数のパッケージが入れ替わって、4.5リリース相当になった様です。
影響がありそうなのが、
ImageMagick 画像関係
curl URL操作 PHPに影響する
dhclient グローバルIPの確保
gd 画像ライブラリ
glibc Windowsで言うところのDLLに相当する重要なライブラリ
net-snmp 健康診断
nfs-utils リモートファイルシステム
ntp 時計合わせ
openssl 暗号化
postfix メール
python スクリプト
sl-release リリースファイル
再起動汁とは言われてませんが、一度はした方がいいので金曜日の深夜あたりに一発再起動します。
今のところ不具合は出ていないはずですが、気がついたことがあれば早い目にコメントをお願いします。
FireWallの設定にミスがあり、FTPサーバにパッシブモードで接続されない不具合が発生しておりました。アクティブモードで接続した場合は問題が発生しませんので、この不具合はパッシブモードで接続されているユーザにのみ発生しておりました。
この自宅サーバのFireWallは二重化されていまして、一つはルータ側に、さらにサーバ自身にiptablesを使ってFireWallがセットされています。
ルータ側は大雑把に「必要なポート(サービス)だけを通す」という役割をしており、サーバ自身のiptablesはさらに細かいアクセスルールを設定したり、余計なパケットがWAN側に出ないようにしています。
これらのうち、iptablesの設定は、特に保存をしなければRAMの上だけのもので、再起動したりすると消えてしまいます。保存してあれば、それが再現されるのですが、保存していたルールが古かったようで、パッシブポートに使われる部分をdropしたままでした。
現在は、新しいルールを保存し、ルールも書き換えましたので、アクセス障害は解消されています。接続出来なかった方にはご迷惑をおかけしましたことをお詫びいたします。
今朝の06:28頃に停電が発生したらしく、ONU周りの機器と、実験的にネットワークにぶら下がっているlantanが落ちました。
サーバ本体は無停電装置での補償時間内でしたので、再起動等は発生していません。ネットワークの方も自動的に復帰した模様です。lantanが落ちてしまったので、NFS周りがちょいと異常になってLoadAvarageが上昇した状態になっていましたが、lantanの再起動により解決しております。
停電の理由は目下のところ不明ですが、我が家だけではなく地域的に停電したものと思われます。(家の主遮断機はトリップしていなかったこと、200Vの動力系も停止したことから)
1.chunk_split() 「文字列をより小さな部分に分割する」の整数オーバーフローの問題
が修正されたということでしたが、まだ内在しているようです。
この関数は
string chunk_split ( string string [, int chunklen [, string end]] )
という定義で
$D = chunk_split ($A,$B,$C);
$Aという文字列を$B(数値)ごとに区切り$Cという文字列を挿入した結果を$Dにしまう。
で、BASE64エンコードしたものをメールに添付するとかに使える関数です。
PHP Security Blogによると $Aと$Cに65537文字、$Bを一文字ごとにすると整数オーバーフローが5.2.3でも発生するということです。
自作のスクリプトでは使っていないのですが、直ったはずが直ってないというのは…。
現時点では本家の方にはアナウンスはありません。
鯖のログチェックしていたら、閉鎖したサイトの中身を消さなかった人がいたらしく、SPAMの巣に＞＜
閉鎖されてからかなり日数が立っていたので丸ごと削除しました。
また、生きてる？アカウントのサイトの掲示板がSPAMの巣に。/eve のところです。
うちは別に広告目当てとかに運営していないので、休止期を設けたりするのは構わないんですが、(何日以上ログインしないとアカウントが消える場所もあります)休憩するときは掲示板類等外部から書き換え出来るところは全部読み込み専用してから休んでください。さらに休むなら、アカウントの一時ロックを申請して下さい。放置されたアカウントほど危険なものはありません。
スパマーは油断するとすぐに集ってきます。キャプチャを設けるか、検索エンジンから隠すか、なんらかの工夫は必要な世の中です(嫌なものですが)。設置するスクリプトもよく吟味して選定し、必ずメンテして下さい。
近々、生存チェックのメールを出しますので、よろしくお願いします。
返事が無いサイトのアカウントは停止→さらに返信が無ければ削除します。最近、洒落にならんので。
PHPのバージョンアップが出ましたのでアップグレードしました。
現在のバージョンは5.2.3です。
今回のバージョンアップは5系列だけのようで、
1.chunk_split() 「文字列をより小さな部分に分割する」の整数オーバーフローの問題
2.imagecreatefrompng 「PNGからイメージ作成」で無限ループが発生する可能性がある問題
3.realpath()「絶対パス名を返す」にて open_basedir/safe_mode 設定がバイパスされてしまう問題
4.フィルター拡張モジュールのメールアドレス検査にある脆弱性
5.バンドルされていませんが、sqlite2ライブラリに於ける処理のCVE-2007-1887の改善
6.mysql_set_charset()「MySQL接続時の文字エンコードを実行時に切り替える」関数の追加
が含まれています。セキュリティ関連を含み全てのユーザにアップグレードを薦めるとなっています。
※今まで紙(本)の英和辞典使っていて、「いい加減新しい辞書買わないと」と電子辞書(CASIOのEX-word)買ったのですが、Vulnerabilityって載ってないんです。ぐぐればすぐに判ると思いますが、脆弱性です。日本語としてもコンピュータ関係を知らない人には聞きなれない言葉ですが、英語でも最近出来たんですかね。
よかれと思って交換したNTT-ME の MN8300 ですが、今年に入って４回目のハングアップを今日の16:10頃に起こしてしまったようです。起動時間なのか、転送量なのか、変なパケットでも送りつけられたのか判りませんが、ルータとして失格です。
仕方が無いので、もう古典的といってもいい古いルータのMN4412Vに戻しました。
サーバ本体の方はもう100日近く安定して動作していたのですが、カーネルアップも兼ねて電源を落としました。ついでに中も掃除して、HDDをカートリッジ式にしてワンタッチで交換できるようにもしました。
MN8300はスループットとして実績50Mbps近く出てました。NATテーブル数も4096ありましたが、MN4412Vは20Mbpsしか出ません。チューニングとか抜きにADSL時代のルータなのでそのぐらいしか求められていなかったのでしょう。NATテーブルも1024しかないので、個人使用とはいえ、あまりサーバ向けとは言えないものです。しかし、一年以上無停止(と言いますか、引退まで)ハングしたことは無い安定性を誇ります。MN8300はインテルのプロセッサを使っていてるのが鬼門なのでしょうか？OSは同じなんですけどね。
もっといいルータをと価格.comとか探しましたが、民生用ルータってやる気なしモード全開のようです。新製品というものはまるで見当たらない。あっても無線LANルータで、有線のものが無い。
GapNATも過去のテクノロジーかと思ってしまいます。業務用のルータはパソコン一台買えてしまう値段になるので、それならLinuxルータを一台組んだほうがとなって…。
まぁApacheの同時セッション数もそれなりでしかコンパイルしていませんので、超人気サイトが鯖に収容されない限りは大丈夫かと。スピードもフレッツファミリーなので20Mbpsぐらいでまけといてください。
PHPの新しいバージョンがリリースされていましたので、アップグレードしました。インストールされているバージョンは5.2.2です。
暗号化ライブラリ libmcrypt は 2.5.8 です。
なにやらmake testなるものが追加されていましたので実施しました。
エラーとして出されたものは以下の通りです。
=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #41117 (Altering $this via argument) [Zend/tests/bug41117_1.phpt]
easter_date() [ext/calendar/tests/easter_date.phpt]
unixtojd() [ext/calendar/tests/unixtojd.phpt]
カレンダー関係の不具合らしいですが、復活祭は日本では関係なさげなので問題なし
Bug #38474 (getAttribute select attribute by order, even when prefixed)
(OK to fail with libxml2 < 2.6.2x) [ext/dom/tests/bug38474.phpt]
libxml2のバージョンが古いという問題ですが、SL4(CentOS4)系を使っている限りバージョンは上がりません。セキュリティ関係のfixはされているので、とりあえずこのまま。不具合が出るようでしたら個別に入れますが、出来る限りしたくないので。
CentOS5系では libxml2-2.6.26-2.1.2 となっていましたので CentOS5系では出されないエラーです。
Bug #16069 [ext/iconv/tests/bug16069.phpt]
iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
htmlentities() test 2
(setlocale / fr_FR.ISO-8859-15) [ext/standard/tests/strings/htmlentities02.phpt] (warn: possibly braindead libc)
htmlentities() test 4
(setlocale / ja_JP.EUC-JP) [ext/standard/tests/strings/htmlentities04.phpt]
htmlentities()
test 15 (setlocale / KOI8-R) [ext/standard/tests/strings/htmlentities15.phpt]
iconv()周りのエラーですが、ロケールがインスコされていない事に起因するものと考えられます。
特に使用しておりませんので(UTF-8に統一のポリシー)無問題とします。
=====================================================================
以上は既知の不具合としますので、PHP関係のアプリを使う方はご注意ください。
また、PHPを狙った攻撃も多数報告されていますので、アプリの脆弱性チェック、最新バージョンの確認の方もよろしくお願いします。
04/12日 16:20頃から翌01:00頃にかけてルータの障害によるサービス停止が発生しておりました。
ルータの再起動にて復帰しております。特に障害となる原因があってのことではありません。また、サーバには障害は発生しておりません。
MN8300はあんまり安定がよろしくないのかなー。前のルータはスループットは遅かったけど落ちたことは一度も無かったのに。前にもMN8300は落ちたことがあるし。
ルータを再起動するとネットワークサービスも再起動(この時点でローカルであってもネットワークが一度落ちる)しないと駄目なので、リモートからはいかんともし難いです。
あんま落ちるようならば、古いのに戻すことも検討します。
メル鯖のリジェクトログにこのようなログが残っていた。
Mar 18 21:22:28 s98.ALPHA-w5.vectant.ne.jp [124.110.10.98] from=<fujita@netmail.kg> to=<検閲> helo=<abcde>
省略
Mar 18 21:42:36 s98.ALPHA-w5.vectant.ne.jp [124.110.10.98] from=<fujita@netmail.kg> to=<検閲> helo=<abcde>
これは、発信元のメル鯖が身元不審ということで、うちのメル鯖から「ちょっと待て」をかけられた転送依頼のログであるが、普通は「ちょっと待て」(つまり450)と言われたら時間単位で間が空く。しかしながら、こいつは数秒間間隔で狂ったように再送をかけていた。大体helo文がおかしいのでスパムだろうということは想像がつく。
このスパムメールは私のメアドに来たものではないが、実在するユーザ宛のものだった。
珍しく国内鯖なので、送信元のポートをつんつんしてみると、25番,110番等が空いている。しかしまともな返信は無い。(EHELO等に反応しない)。pingにはいっチョ前にフィルタをかけている。80番には反応しないので、Web鯖ではないらしい。
ぐぐって見ると、
に同じIPアドレスが晒されている。
ネット版怪文書らしい。メル鯖の事前チェックに引っかかってしまったこのスパムは、まったく配送を受け付けていない。よって内容は不明であるが、似たようなものであろう。メル鯖(SMTPエンジンか？)もさることながら、狂った内容の文章をばら撒いているだけのようだ。迷惑である。
リンク先の記事が2007年02月13日で今日は3月19日で、ゾンビにしては長生きしすぎだ。
さらにぐぐると ホスティングしている会社は ttp://www.vectant.co.jp/ である。事業者向け専業ぽい。ということはどっかのレンタル鯖を悪用していると見える。逆引きのs98というホスト名もそれっぽい。
Outbound Port25 Blockingまで実施しているとあるが、役に立ってねぇなｗ
ログによると、11:28頃にルータからDHCPでグローバルIPアドレスが貰えなくなったようで、大量のエラーが上がっていました。サーバその物は問題なく動いていたようですが、ルータが死んだら皆死んだの状態になり、14:00にDNSのキャッシュが切れて、予備回線からの操作も不能になりました。
ローカルからルータへのアクセスを試みましたが、反応無しだったのでルータは再起動しました。再起動によってログが消えてしまったので、詳しい理由は不明です。
ご利用の皆様にはご迷惑をおかけしました。
最近、サーバに設置されている掲示板類に大量の英文SPAMが投稿されることが散見されます。昔はいわゆる「荒らし」行為が殆どでしたが、インターネット全般の迷惑行為が悪戯・誇示から商業行為に変わってきたのと同様に、怪しげな薬物販売、アリエイト、SEO、フィッシングサイトへの誘導等の大量リンク張り行為が主となってきました。
奴らは、荒らし行為と違い、検索エンジンで特定のキーワード(bbs 又は著名なCGIのPOST処理ファイル名)で検索し、国内を含めるプロキシ・ボットネットを使ってプログラムで定期的に書き込んできます。
そこで、サイトに掲示板類を設置する時は、
1.掲示板と安易に推測される名前をフォルダなどにつけない。(特にBBS等)
2.スクリプトのファイル名を変えられる場合は変える。
3.画像認証機能等を持つスクリプトを選定する(書き込み行為が人間による事を保証させる)
4.確認画面を挟んでCookieを食べさせる等、ちょっと手間を増やす(スパマーは嫌がる)
5.XSS等の脆弱性が見つかる場合もあるので、メンテが続いているスクリプトを選定し、常に最新に保つ。
6.管理パスワードはもちろん安易に推測されないものにし、メール通知等を用いて書き込みを監視する
以下は状況に応じて。
副作用も多い。
1.JP規制をする
日本国内のプロバイダをすべて把握することは難しい
海外からの正当な書き込みを拒否する 場合がある
国内のボットネットを使って書き込まれる場合がある(プロバイダに通報して対処は出来る)
2.検索されないようにする
収集ロボットに嫌われるかも
集客率が落ちる・ランクが落ちるかも
敵が独自のロボットを使っていると難しい
3.日本語で書け規制 URL規制
リンクを書き込むことが目的であるため、本文中へのURL書き込みをNGワードにする。
日本語文字コードが含まれているかチェックする(これも日本語を解さないユーザを排除してしまう)
4.某巨大掲示板のプロキシチェックを組み込む
ボットネットには弱い(プロキシに見えない)
巻き添え・誤爆がある
等の対策を考えて運営して頂きたいと思います。
アクセスログを見る限り、人間が書き込んでいる事を確認するのがもっとも効果が高く副作用も少ないと思われる。(導入しているユーザの掲示板にはPOSTが沢山残っているにもかかわらず、書き込まれてはいない)
次に確認画面とCookieの組み合わせ。これはスパマーが何よりも効率を重視するピンポンダッシュである傾向が高いためと思われる。普通は書き込まれたことを確認するはずであるが、それをするものはまずいない。ユーザーが減る可能性もあるが、簡易な登録をしてもらうのも一手かもしれない。だが、これは一般に嫌われる。登録は手動で行い、管理人が現れるまで張れるだけ張って逃げたものもいる。
このブログにも毎週数百件のスパムがやってくるが、NGワードとDSBLチェック、ドメインチェックで98%以上は弾いている。これはよく出来ていると思われるが、副作用があるかも知れない。
また、使用しなくなった掲示板類やCGIは必ずパーミッションを殺して欲しい。削除するのが適切ではあるが、また再利用するかも知れない等で残したい場合は、ログファイル類は読み込み専用に、使わないプログラムの実行権限を無くす等の処置を行って頂きたい。
サーバ内のCGI類で放置されてスパムの巣窟になっているのがいくつか発見された。これらは管理者側で不適切なリンクを削除した上で、読み取り専用に変更した。書き込めなくなっているプログラムがあれば、管理体制を見直した上で、パーミッションを戻して欲しい。
掲示板を始め、ユーザが書き換えられるコンテンツは双方向なコミニュケーションを実現する(Web2.0的な)ツールであることは間違いないが、未成年にふさわしくないサイトや有害なサイトのリンクを放置しておくのは大変にまずい。掲示板設置者にとってもリスクと成りうる事なので留意して欲しい。
ProFTPDの脆弱性についての正確な情報を入手しましたのでお知らせします。
1.ProFTPDにおける不適切なCommandBufferSize設定によるスタックバッファオーバーフローの脆弱性
proftpd.confにてCommandBufferSizeの値に512より大きい値を設定している場合は全てのバージョン(最新版の1.3.0aにおいても)に影響があります。
対策
→CommandBufferSizeの値に512以下の値を設定する。又は設定をしない。
当サイトのサーバにおきましては確認済みです。
2.ProFTPD 1.3.0のフォーマット処理におけるバッファオーバーフローの脆弱性
1.3.0aを除く1.3.0系列の全てに影響があります。
対策
→1.3.0aにバージョンアップする。又は1.2系列の最新版にする。
当サイトのサーバにおきましては昨夜のうちに1.3.0aに変更済みです。
上記バージョンを使用し、ユーザにてファイルの作成が可能であるシステムにて実際に攻撃可能であることが実証されています。ProFTPDを利用してFTPサーバを公開している方はご注意下さい。
11月27日付けでFTPサーバソフトであるProFTPDに1.3.0aが出ましたのでアップデートしました。
CVE-2006-581に詳細が上がっているものに対しての修正で、コマンドバッファにチェック漏れがあり、リモートからのDoS攻撃(第三者に任意のコマンドを実行とも)が可能とされているものです。1.3.0に固有のようです(1.3.0以降と書かれていますが、1.3.0aで修正されているため)が、デストリビューションのを使用している場合は1.2.10でも内在している可能性があります。
FTP サーバの設定を変更しました。
FTP サービスは一般のユーザではchrootという機能が働いて、本来のサーバのファイルシステムを隠蔽しています。なので、一般ユーザの方がログインすると自分のホームディレクトリが/(root)に見えるはずです。拡張サービスを使っている方も同様です。
次に、FTPにアクセスしてログインしたりファイルを読み書きするとログが書き出されます。ここで書き込まれるアクセス時刻は、日本時間(JST)であるべきです。ですので、本来サーバソフトはサーバの現地時間設定ファイル(/etc/localtime)を読みに行って、時差(GMT+9時間)でもって、ログファイルに書き込みに行きます。
しかしながら、この現地時間設定ファイルはユーザディレクトリの外にあるため、アクセス出来ません。本来はアクセス出来る権限のあるプロセスが行うので問題ないのですが、glibc-2.3のバグによって出来なくなっていました。
長く書きましたが、これによってログに吐き出されるアクセス時刻がGMT(世界協定時)のままログに書き出されてしまっていました。私(管理者)はFTPでアクセスしても自由にディレクトリを移動出来るようにしているので、現地時間設定ファイルにもアクセス出来、気がつきませんでした。そのためログの時系列が目茶目茶になった挙句、ログが飛んでしまっていました。
これを修正するため、/etc/profile.d/tz.sh というファイルを作成し、そこでTZ環境変数を設定。
# echo 'export TZ=JST-9' > /etc/profile.d/tz.sh
# chmod 755 /etc/profile.d/tz.sh
proftpd.confに
TimesGMT false
offではどうも駄目のようです。
そして、反映させるために、一度サーバを再起動しました。
再起動の予定は無いと書きましたが、急いで修正する必要がありましたのでご理解ください。
ユーザサイドにおいては、サーバの時刻設定をGMT+9時間として頂きたいと思います。
FFFTPにおいては
このように設定して下さい。
設定がずれていると、サーバにアップロードしたファイルの時刻がずれて表示されます。
ついでと言ってはナニですが、identという認証に関わる機能を無効化しました。
今まではタイムアウト待ちになって、それから通常の認証となっていましたので、時間が掛かったかと思いますが、ログイン時間が短縮されていると思います。
スクリプトエンジンのPHPが5.2.0にバージョンアップしましたので、サーバにも適用しました。
新たなメモリマネージャを搭載、パフォーマンスの向上が図られているそうです。また、入力フィルタリングが追加されて、デフォルトで有効になるよう設定されています。また、htmlentities()やhtmlspecialchars()といったエスケープ関数に存在したオーバーフローの脆弱性も修正されています。
SQLite、PCREライブラリもグレードアップ。
5.1系の開発は5.1.6で終了だそうです。また、潜在的に危険をはらむ脆弱性が修正されていますので、早急にアップグレードすべきです。現在のところ、アップグレードに伴う不具合は見つけていませんが、何かありましたらよろしくお願いします。
http://www.php.net/
リリースノート(英文ですが読めると思います)
FTPサーバの Proftpdを1.3.0にしました。 http://www.proftpd.org/
いつもどおり Shift-JIS⇔UTF-8間のファイル名自動変換パッチつきです。 ProFTPD - iconv() 文字コード変換パッチ
メル鯖のPostfixもアップデートだぜー、とパッケージ使ってるの忘れてインスコしてしまい一時メール機能が使えなくなってました。20分程度で復旧したので大きな影響はないと思いますが、何か不具合があれば教えてください。
壊れてしまった前の鯖のkonigですが、在りあわせのマザボと交換して、とりあえず復活させました。ただしOSはやっぱりカスタムコンパイルしただけにデバイスドライバが無いだのグラボが見つからんだのになりまして、入れ直しです。最新版ということでCentOS4.4を入れました。
起動はちゃんとしまして、別パーテションの/homeデレクトリもちゃんと見えましたが、やっぱりSATA RAIDカードは認識はするもののただのSATAカードです。HDD4台見えているのでRAID1とは見えていないようです。
GbitのLANカードも見えてませんが、これは捨ててもいいでしょうｗ ベンダーIDを偽ってる糞カードなんで。
まともに予備機として育てていってもいいのですが、マザボが難有の曲者のうえ、もうmPGA478のマザボが市場にありません。中古も含めてLGA775に完全に移ったようです。あまりに新しいと現在のデストリビューションではチップセットが認識されない等の不具合が出てきますので、今しばらくはまったほうがよさげ。
ということで、konigはのんびりと引退生活をさせることにします。
仕事がひ●だったので自宅サーバの歴史をまとめてみるテスト。
いと懐かし。
急遽、実戦投入された五代目サーバ「declato」ですが、ハードウェア的整備が完了しました。
週末に残っていた以下の作業を行ないました。
1.バックアップデータを格納するHDDの取り付け
2.UPS(無停電装置)のへの電源系統の切替と自動シャットダウンソフトのインストール。
停電復帰時に出来る限り自動復帰出来るようなBIOS関係の設定
3.SSHによる外部からのメンテ
これで
160GBx2 + 320GB + 320GB + 250GB = 1050GB の内蔵HDDの搭載
250GB の 読み出し専用 NAS (NFS)
10分までの停電保証(内部ネットワークのみ) 停電後の自動再起動。
が出来ました。
NFS周りはNASの玄箱が自動で起動しないため、おかん再起動が掛かるまでは復帰しません。
USB もマウントのタイミングでは認識されていない事があるようで、この場合は手動でマウントです。これも読み出し専用に近いので問題ないでしょう。
通信系はONUに行く寸前のHUBまでバックアップされますが、ONUがされていないため切断されます。また不正な切断をすると再接続まで10分程度かかるため、サーバが停止しないような短時間の停電でも通信が途絶する場合があります。これは小型のコンセント型のUPSも発売されているので、予算がつけば解決したいと思います。
今年は割りと雷雨が少なくて助かりますが、停電はPCの敵。
ユーザデータのバックアップですが、 /home ディレクトリの100MB以下のデータが毎日午前5時半に別の物理ドライブにコピーされます。これはpdumpfsを使った差分バックアップでその時点での完全なスナップショットです。万が一データを戻したい場合はメールして下されば戻せます。
また、その直後にMySQLのデータベースのダンプも取られます。
とりあえずこれでシステムを落とさないと出来ないようなメンテは終わりです。カーネルの修正がこない限りは順調にuptimeを伸ばす予定です。今まで臨時に落としたりして迷惑を掛けたと思いますがお許しを。
SquirrelMailを使ってメールを送信すると次のようなエラーが出されて、送信済みボックスや、ドラフトボックスにメールが収納されないという問題。
エラー:
エラー: メッセージを追加できません INBOX.Sent.
サーバの応答: Error in IMAP command received by server.
もしサーバーのPHPが 5.1.0以上であれば、それが原因です。(メールボックスの容量が足りない、パーミッションが不適切、フォルダが存在しないなどでも出ますが、どれにも該当しない場合は疑ってください) なお、この状態でもメールは送信されています。
対処方法
functions/imap_general.php を開いて次の関数の記述を検索して下さい。
function sqimap_append ($imap_stream, $sent_folder, $length) {
// fputs ($imap_stream, sqimap_session_id() . " APPEND \"$sent_folder\" (\\Seen) \{$length}\r\n");
fputs ($imap_stream, sqimap_session_id() . " APPEND \"$sent_folder\" (\\Seen) {".$length."}\r\n");
で解決。
BUG tracker にありますが、なかなか見つからないものです。
発覚の経緯
Wikiにログイン出来ませんってメールを携帯アプリで見て、こそこそっと対処して、こそこそっとSquirrelMailで返信書いて送ろうとしたらエラー表示されてメール消失ｗ 自爆メール送ったら送信されていたので多分届いてはいると思います。メールは見れたらいい。返事は帰ってからと思っていたので、テストしきれてませんでした。
メール関係の整備を少々。
WebMailを入れたかったので、courier-IMAPを入れる。POP3も残したかったんだけど、courier-IMAPはmbox形式のメールボックスを読みに行けないと解り、メール配送の形式をMaildir形式に変更。
courier-IMAPは最新版ではIMAP/POP3の部分と認証の部分がcourier-authlibに分割されているので、ネットにあるネタは古いものが多くそのままでは使えないものが多かった。
http://www.kuri3.net/modules/bwiki/index.php?WebMail
等が参考になる。courier-authlibで検索するとよい。
なんかアレがない、これがないと文句言われることも多いが、yumで入れるか、シンボリックリンク張るかで解決。
4時間ぐらい格闘したもののインストールに成功。Webmailも動いた。
ということで、POPパスワード等が初期化されてしまったため、ログイン出来ない人はコメントでもいいのでご連絡をお願いします。
我が家4代目のサーバとして華々しくデビューしたケーニッヒくんでしたが、2006年08月15 日をもって引退となりました。
正確に言えば、死んではいないですが、メモリアクセスが化けるという危篤状態に陥り、継続運用は危険(コンパイル不可、データベースのテーブルを一度壊した)ということで引退とあいなりました。幸いにも予備機兼私の玩具だったデカルトくんを実戦投入し、5代目サーバとして運用していくことになりました。
デカルトくん
ケーニッヒとの違いはハード的には、
例のPV3装備のため、キャプチャ機のチビスケにメモリを供出してましたので、まずメモリを1GB(512x2枚)購入。
ケーニッヒが持っていた1TBに及ぶHDDの代わりとして320GBのSATA HDDを一台購入。WAN向けのNICも蟹がついていたので、違うメーカのに交換。容量的にはグレードダウンであり、RAIDも装備してませんが、ローカルPCのバックアップ的なものなので、当分はこのまま。
ケーニッヒ用の外付けHDD 250GBを取り付け。
コアデータは160GB×2のRAID1。 /home領域は100GBをとりあえず確保。
脳味噌はプレス子なのが気に入らないが、2.8GHzのHT付きが余っていたので、これを装備。擬似的とは言え、デュアルCPU。FSBは800MHz。多分2-3倍は速いはず。
ネットワーク能力的には300Mbps以上のファイル転送が可能です。
ソフト的には デカルト成長日記と基本的に変わらず。Apacheは2.2系、PHPは5系に。
主たるサービスは移植しましたが、細かい部分が残ってます。
せっかく盆休みなので、アニメ消化して、どっか温泉でも行って英気養う予定でしたが、全部これに消えました。平日だったらパニックだったかもと思うと、休みの日に壊れてくれて、最後のご奉公だったのかｗ
ケーニッヒは設定とか、昔のを参考にしたいものもありますので暫くは起動可能な状態を保ちたいと思います。
どう見ても一年以上更新されてなく、また放置プレイで連絡の無いサイトのデータは移していないので、やっぱり残したいという人は早い目にご連絡を。
パスワード類も今回は急ということで、こちらで移しましたが、データが古い等でログイン出来ない可能性もあります。これもご連絡ください。
メール関係、一部の拡張FTPサービスもパスワードの再設定が必要です。ご連絡ください。
朝、起きたらヤフーとか何にも見られなくなってました。
案の定、自宅鯖が死んでました(涙
ケーニッヒがDNSも受け持っているので、もう一本の回線が無傷でも名前解決出来なくなってしまうのです。
シスログを見ている限りは04:22頃まで生きていたようですが、コンソール、リモート共に沈黙。ハードリセットでリブート。RAIDのリカバリだけ掛けて復旧はしました。時間的に週毎のちょっと大きめのバックアップが走る直前ですが、目下のところ原因は不明です。シスログ上DHCPクライアントが怪しいログを大量に吐いていましたので、これを疑ってはいますが。
仕事がまたややこしい時期(プロジェクト改変期)で半ば欝でサイトとか放置気味(いろんな事にやる気が起きず)でしたが、デカルト(予備Linuxマシン)と同期を取ってコールドスタンバイさせる仕組みを考える時期に来てるかもしれません。ケーニッヒは爆弾(電源を切らないと立ち上がらないという謎の現象)を抱えているため、リモートからリセットとか出来ないのですｗ また一つ前のシステム(カーネル等)なのでサポート的にも実はヤバイ目です。(自分でソースからコンパイルして維持はしてますが)
ハードウェア的に予算がつくのは来年以降なので、もう少し頑張れケーニッヒ！
MySQLのmysql_real_escape_string()にSQLインジェクション可能な脆弱性
概要
MySQLの複数のバージョンで、リモートから攻撃可能な脆弱性が見つかっている。この脆弱性を利用する事により、データベースが参照及び改ざんされる可能性があると発表された。
MySQLを使用しているアプリケーションに対して、一重引用符のエスケープ文字列(\')を含むSQLを入力すると、サニタイジング処理などに使用されるmysql_real_escape_string() 関数のセキュリティが迂回される可能性があり、これにより、任意のSQLがデータベース上で実行される可能性があります。この脆弱性は、PostgreSQLでも見つかっており、早急な対策が必要。
この脆弱性はマルチバイトのサーバエンコーディングを使用している(UTF-8、EUC_JP等)場合に発生する。日本語を扱うデータベースはこれに該当するだろう。
対象バージョン
mysql 4.1.0～mysql 4.1.19
mysql 5.0.15～mysql 5.0.21
影響
ユーザからの入力がMySQLサーバに渡される際に(ログイン処理や検索フォームなど)、適切なサニタイジング処理を行っていても、SQLインジェクションが可能となり、これにより、リモートから任意のSQLが実行され、データ操作(書換え/削除等)、データ閲覧(情報漏洩)などが行われる危険性がある。 また、ユーザー認証(ユーザーパスワードの照合など)にデータベースを利用している際には、認証処理を回避される危険性がある。
なお、MySQL 3.23 および 4.0 は本脆弱性の影響を受けない。
回避方法
NO_BACKSLASH_ESCAPES SQLモードを使用することで暫定的に対処が可能である(このモードはMySQL 5.0.1以降で導入された)。NO_BACKSLASH_ESCAPESにより、SQL互換モードが有効になり、バックスラッシュが特殊文字として扱われなくなるため、SQLを無害化できる。
このモードを現在の接続で有効にするには、下記のSQLステートメントを実行する。
SET sql_mode='NO_BACKSLASH_ESCAPES';
また、下記を実行して、全てのクライアントに対して当該モードを適用することも可能。
SET GLOBAL sql_mode='NO_BACKSLASH_ESCAPES';
このモードを、サーバの起動時に自動的に有効にするには、「--sql-mode=NO_BACKSLASH_ESCAPES」コマンドラインを使用するか、サーバオプションファイル(システムによってmy.cnfまたはmy.ini)に「sql-mode= NO_BACKSLASH_ESCAPES」を設定する。
当サーバの対応
対応済みバージョンであるMySQL 4.1.20、5.0.22及び5.1.11-betaがリリースされているのでアップデートを行う。現行サーバのMySQLは5.0系列となっているので5.0.22へと変更する。
その他
公開コンテンツには使用していないので詳細は省くが、
PostgreSQL 8.1.4
PostgreSQL 8.0.8
PostgreSQL 7.4.13
PostgreSQL 7.3.15
についても同様の脆弱性が確認されているので、
PostgreSQL 8.1.4
PostgreSQL 8.0.8
PostgreSQL 7.4.13
PostgreSQL 7.3.15
にアップグレードが必要。
ここにはさっさと書いたけど、ここでも一応報告。
2006-05-07 16:50～17:10頃、ケーニッヒが突然死しました。原因は不明ですが、メモリの状態からしてだれかがメモリリークしてたんたじゃないかと。グラフがヘンだったし。
半年近く連続稼動してたんですけど、実は２ヶ月ぐらい前から挙動が怪しいと言えば怪しかった。前もなんか突然死したなぁ。 ハード更新？ そんな予算はない(2-3年間隔計画)ないので、もう少し頑張ってもらいましょう。カーネルは枯れきって(2.4系)いますが、まだ周辺のデーモン等はちゃんとコンパイルして使えてますから。PHPが5系がそのままではコンパイル出来ないところが痛いかな。4系がメンテされている間はそのままで。
とりあえず、家にいる間のトラブルだったので、即時再起動で、ダウンタイムは10分ほどだったはず。
それと新しい店子さんが入ったのでよろしく。
明日(３時間後)から、仕事か。欝だ。
MediaWikiでキット紹介を書いていこうとしているのだけど、デフォルトのままでは wiki/index.php/ブレードライガー みたいな URI になってダサイ。ということで、mod_Rewrite を使おうとしたけど、コンパイルしてなかったので、Apache 作り直し。
モデルを prefork から worker に変えたら負荷がどーなるかなー と浮気心だしたけど、PHPをスレッドセーフに作らなくては駄目で、そうすると返ってPHPは実行が遅くなるとの事。いつも通りに prefork に戻しました。
かなり久しぶりに使ったので相当なやんだけど、
/zoids/ 直下の .htaccess に
RewriteEngine on
RewriteRule ^zoidsWiki/?(.*)$ /zoids/zoids_wiki/index.php?title=$1 [L]
と書くと
http://www.zoids-fan.net/zoids/zoids_wiki/index.php?title=ブレードライガー
が
http://www.zoids-fan.net/zoids/zoidsWiki/ブレードライガー
に置き換わる。
正確には、
http://www.zoids-fan.net/zoids/zoidsWiki/ブレードライガー へのアクセスがWebサーバには
http://www.zoids-fan.net/zoids/zoids_wiki/index.php?title=ブレードライガー へのアクセスに見える。
FollowSymLinks は有効していないと失敗する。
置換する正規表現は、.htaccess が存在するディレクトリ以下を指す。
の二点がポイント。
昔、エロスパム業者がしつこく掲示板に書き込むので、この機能を使って虫かごにほおり込んでいた。
スパム業者がアクセスしてくる(置換する条件はホスト名や、ページ名など色々出来る)と専用ページが現れるという寸法。業者はシコシコと書き込むが、一般の来客者にはその掲示板は見えない。ブラウザのURIも変化しないのでまず気がつかないｗ 削除するとより燃え上がって書き込むので、満足するまで書かせていた。ご苦労であったｗｗ
ということで、地道にコンテンツ書いていくかなー。
ですが、Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 219.118.85.0 * 255.255.255.0 U 0 0 0 eth0 192.168.x.x * 255.255.255.0 U 0 0 0 eth1 default ppp85181.pm.twi 0.0.0.0 UG 0 0 0 eth0
こうなってしまうときが稀にあるようです。Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 219.118.85.0 * 255.255.255.0 U 0 0 0 eth0 192.168.x.x * 255.255.255.0 U 0 0 0 eth1
02/02 の 21:00～22:50 頃回線が落ちていました。→詳細
ご利用の方にはご迷惑をおかけしました。
なんかPPPoEが一方的に切られたぽいのですが、理由は謎。今回は家のモノによる犯行ではないようです。
パッチ当てが効いていて、今回は自動再接続していましたが、PPPoEでプロバイダが割り当てたグローバルアドレスを今度はルータのDHCPサーバが、konigサーバのNICに割り当てている(より正しく言うと、konigがルータに「アドレスくれ」ともらいに行く)アドレスがなくなっちゃって、DHCPサーバが割り当てたアドレスを無効にしてしまっていた。
konigがルータに能動的に「アドレスがないぞ、くれ」と言わないと、DHCPサーバ側からは割り当ててくれない。つまり、外から見れば復帰しない。またも手動で復帰させた。残念っ。
普通にファイル鯖もアクセス出来てて、IMも繋がっていたから気がつかなかったが、IMでメール鯖に繋がらないとか言われて、ヤフー見に行ったら繋がらない(DNSが死ぬため)。なんぞ起きたかと、焦りましたが、そういうことです。(IMは持続的にコネクション張るのでDNSの影響を受けなかった)
NICに振られたアドレスを監視して、なくなったら貰いにいくようにスクリプトを書いて、自動復帰を確実にするようにしたいと思います。
※konig自体は元気です。
#uptime
02:02:27 up 36 days, 31 min, 2 users, load average: 0.27, 0.17, 0.15
汎用スクリプト言語「PHP」のバージョン4およびバージョン5に、いくつもの脆弱性が見つかっており、 PHPGroup から、最新版「PHP 4.4.2」および「PHP 5.1.2」がリリースされています。
当サーバでは4系列を使用していますので、4.4.2にバージョンアップしました。その際、一時的にWebサーバが停止しました。
修正箇所の和訳はこちらで公開されています。
30件近くあります。XSS 攻撃の可能性のあるもの、PHP ext/session HTTP Response Splitting に対する防御機能も内蔵とのこと。
前回のバージョンアップの時は、4系と5系でかなり時差を持ってリリースされていましたが、今回はほぼ同時に行われたようでよかったです。共存出来れば一番いいんだけど。