最近スパムが多くて、良いスパム対策はないかと物色。
で、なんか売り文句によると99%のスパムメール撲滅できるというものが。
基本的なコンセプトはこちらに詳しく書いてある。
- メールサーバがメール中継サーバからのSMTPアクセスは受け入れるがエンドユーザーコンピュータからの直接のSMTPアクセスは拒絶するという単純なもの
- SMTPアクセスをかけてきたクライアントのFQDNの特徴に基づいて、クライアントがメール中継サーバか、エンドユーザー回線につながったコンピュータかを推定することができる
- うまく管理されているメール中継サーバのほとんどは、逆引きで得られるFQDNを持つ。逆引きFQDNのないIPアドレスからのSMTPアクセスは、少しの例外を除いて拒絶すればよい。
- 正規表現を使うことによって、エンドユーザー用回線の逆引きFQDNとメール中継サーバの逆引きFQDNを区別する
- メールサーバがこれらの規則によってSMTPアクセスを拒絶する時は、「後で再試行せよ」を意味する応答コード「450」を 返すべきである。そうすれば、これらの規則のいずれかに引っかかる正当なメール中継サーバを、後で述べるホワイトリスト（許可リスト）を作ることによって 救済することができる。
- HELOコマンドが宛先サーバのIPアドレスまたは受信者のドメイン名を通知している
- 送信者ドメインの検索失敗
- 内容の検査
なるほどね。
エンドユーザ回線を拒絶するのはでかそうだ。
この方式をS25R(Selective SMTP Rejection)方式というそうだ。
そして、この方式とは別にGreylistingという方式がある。
Greylistingは簡単に言えば、再送要求を一旦返して、ちゃんと再送してきたものを受け取る方式。
S25RとGreylistingを組み合わせた方式がRgrey方式として紹介されている。
また、意図的な応答遅延を行うことで配送タイムアウトが通常のMTAよりも速いものを切り落とすtarpittingという方式もある。
これは、通常、スパム業者は大量のメールを配送する関係から、応答の遅いMTAには配送を早々とあきらめるよう設定されていることが多いことを利用したもの。
S25R+tarpittingによる、Starpitという手法も紹介されている。
そして、全部ごった煮のパターン、S25R + tarpiptting + Greylistingを組み合わせたtaRgrey方式が紹介されていた。
taRgrey方式の簡単な説明は以下の通り。
taRgreyとは、メールサーバ上でスパムやウイルスメールを排除するためのフィルタの手法で、 S25Rとtarpittingとgreylistingというスパム判定手法を組み合わせて使うというものです。
S25Rにより、動的IPっぽいFQDNからの接続からは怪しいと判断し、tarpitting(応答の遅延)を行います。tarpittingを待ちき れずに送信元が接続を切った後、再度送ってきた場合にはgreylisting(再送のチェック)により救済します。S25Rとtarpittingと greylistingと、全てのフィルタを抜けれなかったものだけがスパムとして排除されます。
さて、じゃあtaRgrey方式で、といきたいところだが、ここにかかれている方法はパッチを当てなければならない。
aptでパッケージ管理している関係上、できるだけdebian非公式パッチは当てたくない。
なので、パッチを使わないで実装する方向とする。
ということでどこでチェックしようかpostfixの設定を眺めることしばらく。
smtpd_recipient_restrictionsでやるのがいいかなあ、という結論。
PostfixでのGreylistingはpostgreyを使う。
ホワイトリストは許可して、S25R方式で怪しい奴らにgreylistingをかける。
それを通ったものにはtarpittingをかける。
という流れにする。
postgreyをインストール。
# aptitude install postgrey
/etc/default/postgrey POSTGREY_OPTS="--inet=127.0.0.1:10023"
127.0.0.1をつけないとipv6でbindしてた。
いや別にいいんだけど。
main.cf smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_client_access regexp:$config_directory/white-list.txt, check_client_access regexp:$config_directory/permit_client_nots25r, check_policy_service inet:127.0.0.1:10023, check_client_access regexp:$config_directory/tarpitting, permit
white-list.txt http://www.gabacho-net.jp/anti-spam/white-list.txtのものを使用
permit_client_nots25r
/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ WARN
/^user.+\.mindspring\.com$/ WARN
/^[0-9a-f]{8}\.(.+\.)?virtua\.com\.br$/ WARN
/\.catv\.broadband\.hu$/ WARN
/[0-9a-f]{4}\.[a-z]+\.pppool\.de$/ WARN
/\.dip[0-9]+\.t-ipconnect\.de$/ WARN
/\.dip\.t-dialin\.net$/ WARN
/\.dyn\.optonline\.net$/ WARN
/\.(adsl|cable)\.wanadoo\.nl$/ WARN
/\.ipt\.aol\.com$/ WARN
!/(^unknown$)|(^[^.]*[0-9][^0-9.]+[0-9].*\.)|(^[^.]*[0-9]{5})|(^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z])|(^[^.]*[0-9]\.[^.]*[0-9]-[0-9])|(^[^.]*[0-9]\.[^.]*[0-9]\.[^.]+\..+\.)|(^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9])/ OK
/./ WARN
tarpitting /./ sleep 65
main.cfでのsmtpd_recipient_restrictionsで基本的な認可のあとに
ホワイトリストによる認証（check_client_access regexp:$config_directory/white-list.txt）
S25RでOKなものの認可（check_client_access regexp:$config_directory/permit_client_nots25r）
微妙なやつらをpostgreyでgreylistチェック（check_policy_service inet:127.0.0.1:10023）
それも抜けたのはtarpitting（check_client_access regexp:$config_directory/tarpitting）
という感じ。
設定してからしばらくログ眺めてたけど良い感じでスパムをブロックしてくれている。
SPFの設定もしようかと思ったけど、あっちは転送時にfailしたりしちゃうことがあるみたいだから、とりあえず今回はやめておいた。
postfix-policyd-spfパッケージ入れてちょいちょいいじれば使えそうなんだけどね。
そういえばすっかり忘れていたHDDのチューニング。
昔はhdparmでチューニングすることで、HDDの速度が結構伸びたものだ。
ついでにサーバ機なので静音化と省電力化も図りたい。
ということでしらべ直す。
hdparmで速度に関係しそうなオプションは以下のあたり。
-a Get/set fs readahead -A Get/set the drive look-ahead flag (0/1) -c Get/set IDE 32-bit IO setting -d Get/set using_dma flag -m Get/set multiple sector count -M Get/set acoustic management (0-254, 128: quiet, 254: fast) -Q Get/set DMA queue_depth (if supported) -W Get/set drive write-caching flag (0/1) -X Set IDE xfer mode (DANGEROUS)
レスキューディスクでアレイを作ったらホームホストがそのときのレスキューのホスト名になっちゃってて、ようするにdebianになっちゃってたんで、なんとかしたいと思ったわけですはい。
アレイを組み立てるっていうかassembleするときに–update=で指定できるようで。
でもシステム領域含まれてるんでまたレスキュー使わないといけないんですね、はい。
ということでレスキューに潜り込んで、ホスト名を目的のものにちゃんと設定します。
じゃなかったらassembleの時にオプションで–homehost=で指定します。
# mdadm -A /dev/md1 /dev/sd[ab]1 --update=homehost
ホスト名ちゃんとしたの指定してなかったら
# mdadm -A /dev/md1 /dev/sd[ab]1 --homehost=hogehoge --update=homehost
みたいな感じ。
アレイがすでに起動してたら一回停止してからやりましょう。
アレイのメタデータのバージョンが1系ならmdadm -Dで出てきます。
Name : hogehoge:2 (local to host hogehoge)
のところ。
homehostと今のホストが正しければlocal to host hogehogeのところが出てきます。
mdadm -Dsでかぶってる名前のやついたら一回アレイをとめて
# mdadm -A /dev/md1 /dev/sd[ab]1 --update=name
とかしましょう。
解消されるはずです。
ちなみにmd1とかmd2とかのデバイス名を変えたい場合も同じ感じで、アレイが動いていれば停止して、アセンブルしてやって名前更新かけてやればいいです。
できあがったらシステムをルートにしてシェルを実行して、mdadm -Ds>>/etc/mdadm/mdadm.confたたいて今までのアレイ情報はコメントアウトしましょう。
念のためupdate-initramfs -uk allたたいておいた方が良いかもしれません。
特にデバイス名を変更した場合は必須だと思います。
ふと気づいたんだけども、DomUの一つでmailコマンドが存在しないことに気づいた。
消したのか元々入ってなかったのか。
ということで使えるようにする必用がある。
debianではmailコマンドはmailutilパッケージに含まれるらしい。
ということで、
# aptitude install mailutils
これでメール送れるはずだとおもってテストしてみる。
# mail test@example.com
Cc:
Subject: test
test
おや。
届かない。
おかしい。
キューに残ってる。
で、exim4の設定を本格的にやる気はない、というかDomU(U1)から配送するのは基本的にシステムメールだけな予定。
なので、別のDomU(U2)でうごいているPostfixさんに配送を任せようということに。
# dpkg-reconfigure exim4 メールサーバ設定形式でスマートホストを使う lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x 必要とするものに最適と思われるメールサーバ設定形式を選択してください。 x x x x ダイヤルアップシステムなどの動的 IP アドレスのシステムでは、一般に送出するメールを x x 配信のために別のマシン (「スマートホスト」と呼ばれる) に送るよう設定すべきでしょう x x 。インターネット上の受信システムの多くは、迷惑メール対策として動的 IP アドレスから x x やってくるメールをブロックしているからです。 x x x x 動的 IP アドレスのシステムは、自身のメールを受け取るようにするか、ローカル配送を x x (root と postmaster へのメールを除き) すべて無効にするかできます。 x x x x メール設定の一般的なタイプ: x x x x インターネットサイト; メールは SMTP を使って直接送受信される x x ○ スマートホストでメール送信; SMTP または fetchmail で受信する x x スマートホストでメール送信; ローカルメールなし x x ローカル配信のみ; ネットワークなし x x 今は設定しない x x x x x x <了解> <取消> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 自分のサーバ名を入れておくのがまあ普通。 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x 「メール名」は、ドメイン名がないときにメールアドレスを「修飾」するために使われるド x x メイン名です。 x x x x この名前はほかのプログラムによっても使われます。これは、単一の完全修飾ドメイン名 x x (FQDN) にすべきです。 x x x x たとえば、ローカルホストのメールアドレスが foo@example.org の場合、ここで入力する x x 正しい値は example.org となるでしょう。 x x x x 書き換えを有効にすると、この名前は送出するメッセージの From: 行に出現しません。 x x x x システムメール名: x x x x U1.waterblue.net___________________________________________________________ x x x x <了解> <取消> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj ローカルからのメールしか送らないので、ローカルを指定 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x IP アドレスのリストをセミコロンで区切って指定してください。Exim SMTP リスナデーモ x x ンは、ここで挙げられたすべての IP アドレスをリスンします。 x x x x この値を空にすると、Exim はすべての利用可能なネットワークインターフェイスの接続を x x リスンするようになります。 x x x x このシステムが (ほかのホストからではなく) ローカルサービスから直接メールを受け取る x x のであれば、ローカルの Exim デーモンへの外部からの接続を禁止するのもよいでしょう。 x x このようなサービスには、fetchmail 同様にローカルホストとやり取りする電子メールプロ x x グラム (MUA) も含まれます。ここで 127.0.0.1 と入力すると、パブリックなネットワーク x x インターフェイスのリスニングを無効にするので、外部から接続できなくなります。 x x x x 入力側 SMTP 接続をリスンする IP アドレス: x x x x 127.0.0.1 ; ::1____________________________________________________________________ x x x x <了解> <取消> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 受信先になる気もないのでデフォルトで十分 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x このマシン自身が最終的な宛先と見なされるべきドメインのリストをセミコロンで区切って x x 指定してください。これらのドメインは一般に「ローカルドメイン」と呼ばれます。ローカ x x ルホスト名 (fileserver.waterblue.net) および 'localhost' は常にこのリストに追加さ x x れます。 x x x x デフォルトでは、すべてのドメインは同一のものとして扱われます。a.example と x x b.example の両方がローカルドメインである場合、acc@a.example と acc@b.example は同 x x じ最終宛先に配送されます。異なるドメイン名を別々のものとして扱いたいときには、設定 x x ファイルをあとで編集する必要があります。 x x x x メールを受け取るその他の宛先: x x x x ___________________________________________________________________________________ x x x x <了解> <取消> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj リレーする気もないのでデフォルトで十分 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x このシステムがスマートホストの役割としてメールを無条件にリレー可能な IP アドレス範 x x 囲のリストを、セミコロンで区切って指定してください。 x x x x 標準的なアドレス/長さのフォーマットを利用すべきです (たとえば 194.222.242.0/24 や x x 5f03:1200:836f::/48)。 x x x x このシステムをほかのホスト向けのスマートホストにしようとするわけではないなら、この x x リストを空のままにしておいてください。 x x x x メールをリレーするマシン: x x x x ___________________________________________________________________________________ x x x x <了解> <取消> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 送信を委託するサーバを指定。 ちなみにここにgmailを指定したりもできるらしい。
smtp.gmail.com:587
を指定すればいいらしいけど試してない。 外部送信専用ならgmail指定するのも良いんじゃないでしょうか。 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x このシステムが送出スマートホストとして使うメールサーバの IP アドレスまたはホスト名 x x を指定してください。スマートホストが TCP/25 とは異なるポートからのみのメールを受け x x 付けるのであれば、2 つのコロンとポート番号を追加してください (あとえば x x smarthost.example::587 あるいは 192.168.254.254::2525)。IPv6 アドレスでのコロンは x x さらに二重にする必要があります。 x x x x スマートホストが認証を必要とする場合、SMTP 認証のセットアップについて書かれた x x Debian 固有の README ファイルを参照してください。 x x x x 送出スマートホストの IP アドレスまたはホスト名: x x x x U2.waterblue.net_________________________________________________________________ x x x x <了解> <取消> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 自分の場合はどのシステムからのメールか必用なのでいいえ。 ローカル用途ではなく、外部に向けて使う場合ははいを選びましょう。 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x x x 異なるシステムで生成されたかのように見えるよう、送出するメールのヘッダは書き換えで x x きます。ここで「はい」と答えると、From、Reply-To、Sender、Return-Path の x x 'fileserver.waterblue.net'、'localhost'、'' が置き換えられます。 x x x x 送出するメールでローカルメール名を隠しますか? x x x x <はい> <いいえ> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj ネットワーク接続が定額制ならいいえで問題ない。 未だに従量制ならはいにしたほうが節約になる。 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x x x 通常の動作モードでは、Exim は起動時、およびメッセージの受信時と配送時に DNS ルック x x アップを行います。これは、記録用であり、設定ファイルにハードコードされた値の数に抑 x x えることができます。 x x x x このシステムが完全な DNS サービスリゾルバを常時利用できない場合 (たとえばインター x x ネットアクセスがダイヤルアップオンデマンドを使ったダイヤルアップ回線の場合)、これ x x は望ましくない結果となり得ます。たとえばExim の起動時やキューの実行時 (待機中のメ x x ッセージがないときでも) に、コストの高いダイヤルアップイベントを引き起こす恐れがあ x x ります。 x x x x このシステムがダイヤルオンデマンドを使っている場合には、「はい」と答えるべきです。 x x インターネットアクセスに常時接続しているのであれば、「いいえ」とすべきです。 x x x x DNS クエリの数を最小限に留めますか (ダイヤルオンデマンド)? x x x x <はい> <いいえ> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 受信する気ないのでどっちでも。 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x Exim はローカルに配送された電子メールを異なる形式で格納できます。ほとんどの場合は x x 、mbox と Maildir のどちらかが使われます。mbox はすべてのメールフォルダを x x /var/mail に単一ファイルで格納します。Maildir 形式では、各個のメッセージは x x ~/Maildir/ に分割されたファイルとして格納されます。 x x x x ほとんどのメールツールは、ローカル配送方式が mbox であるとデフォルトでは仮定してい x x ることに注意してください。 x x x x ローカルメールの配送方式: x x x x /var/mail/ 内の mbox 形式 x x ホームディレクトリ内の Maildir 形式 x x x x x x <了解> <取消> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 金輪際いじる気ないのでいいえ。 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x x x Debian の exim4 パッケージは、1 つのモノリシックなファイルである「単一設定」 x x (/etc/exim4/exim4.conf.template) か /etc/exim4/conf.d/ に置かれる約 50 の小さなフ x x ァイルから実際のファイルが構成される「分割設定」のどちらでも利用できます。 x x x x 単一設定は大きな変更をするのに向いており、一般的により安定しているのに対し、分割設 x x 定は小さな変更を行うのに楽な方法を提供します (ただし脆く、配慮せずに変更すると壊れ x x るかもしれません)。 x x x x 分割設定と単一設定の詳細な議論については、/usr/share/doc/exim4-base にある Debian x x 固有の README ファイルで参照できます。 x x x x 設定を小さなファイルに分割しますか? x x x x <はい> <いいえ> x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
という感じで設定。
うごいた。
今回はこれであっさり目標は達成できたけど、スマートホスト側でリレー云々の設定が必用な場合もありそうな気がする。
その辺はスマートホスト側のSMTPサーバの設定をどうにかしてください。
うちのサーバ機はxenを使って仮想化して運用している。
そして毎日定期バックアップをLVMのスナップショット機能を利用して行っているのだけども、どうも最近挙動がおかしいことに気づいた。
作成したスナップショットが高確率でファイルシステムにエラーを含んでいる。
# xm pause debian # lvcreate -s -n snapdebian -L 200G /dev/ms09/debian Logical volume "snapdebian" created # xm unpause debian
としてスナップショットを作成する。
ここまではいい。
が、ここでfsckを走らせるとエラーが出る。
# e2fsck -yfv /dev/ms09/snapdebian e2fsck 1.41.12 (17-May-2010) /dev/ms09/snapdebian: recovering journal Clearing orphaned inode 15466504 (uid=109, gid=109, mode=0100600, size=0) Clearing orphaned inode 15466503 (uid=109, gid=109, mode=0100600, size=0) Clearing orphaned inode 15466502 (uid=109, gid=109, mode=0100600, size=0) Clearing orphaned inode 15466501 (uid=109, gid=109, mode=0100600, size=20) Clearing orphaned inode 15466500 (uid=109, gid=109, mode=0100600, size=0) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/ms09/snapdebian: ***** FILE SYSTEM WAS MODIFIED ***** 715619 inodes used (2.13%) 738 non-contiguous files (0.1%) 182 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 706955/133 23572155 blocks used (17.56%) 0 bad blocks 6 large files 677160 regular files 29784 directories 126 character device files 40 block device files 2 fifos 16 links 8469 symbolic links (8324 fast symbolic links) 29 sockets -------- 715626 files
マウントしてrsyncでバックアップをとるとumountでえらい時間がかかる。
カーネルが文句いってる。
[ 647.099517] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466504 [ 647.099539] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466503 [ 647.099548] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466502 [ 647.099556] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466501 [ 647.099591] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466500 [ 647.099599] EXT4-fs (dm-18): 5 orphan inodes deleted [ 647.099710] EXT4-fs (dm-18): recovery complete [ 647.433114] EXT4-fs (dm-18): mounted filesystem with ordered data mode [ 1080.113046] INFO: task umount:4061 blocked for more than 120 seconds. [ 1080.113114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1080.113201] umount D 0000000000000000 0 4061 2294 0x00000000 [ 1080.113331] ffffffff8147b1f0 0000000000000282 0000000000000000 ffff8801e6971de8 [ 1080.113544] 0000000000000000 0000000000000000 000000000000f9e0 ffff8801e6971fd8 [ 1080.117004] 0000000000015780 0000000000015780 ffff8801c17654c0 ffff8801c17657b8 [ 1080.117004] Call Trace: [ 1080.117004] [<ffffffff8100e629>] ? xen_force_evtchn_callback+0x9/0xa [ 1080.117004] [<ffffffff8100ece2>] ? check_events+0x12/0x20 [ 1080.117004] [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe [ 1080.117004] [<ffffffff81109274>] ? bdi_sched_wait+0x9/0xe [ 1080.117004] [<ffffffff8130d19a>] ? _spin_unlock_irqrestore+0xd/0xe [ 1080.117004] [<ffffffff8130c3e7>] ? __wait_on_bit+0x41/0x70 [ 1080.117004] [<ffffffff8100f0ac>] ? xen_smp_send_reschedule+0x0/0x7 [ 1080.117004] [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe [ 1080.117004] [<ffffffff8130c481>] ? out_of_line_wait_on_bit+0x6b/0x77 [ 1080.117004] [<ffffffff81065f24>] ? wake_bit_function+0x0/0x23 [ 1080.117004] [<ffffffff811092ec>] ? sync_inodes_sb+0x73/0x12a [ 1080.117004] [<ffffffff8110cea1>] ? __sync_filesystem+0x4b/0x70 [ 1080.117004] [<ffffffff810f1aa2>] ? generic_shutdown_super+0x21/0xfa [ 1080.117004] [<ffffffff8100eccf>] ? xen_restore_fl_direct_end+0x0/0x1 [ 1080.117004] [<ffffffff810f1b9d>] ? kill_block_super+0x22/0x3a [ 1080.117004] [<ffffffff810f226d>] ? deactivate_super+0x60/0x77 [ 1080.117004] [<ffffffff81104bc0>] ? sys_umount+0x2dc/0x30b [ 1080.117004] [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b
場合によってはこのままumountできずにプロセスが残り続けて死ねる。
とりあえずディスクI/Oがロックされた状態になるんだろう。
この問題は稼働中のext4ファイルシステムのスナップショットを作成した際に起きるようだ。
おそらくジャーナルに書き出したデータが実データに反映されていないような状況でスナップショットを作成した場合に起きるんじゃないかと予測している。
のでext3でも同じ現象が起きるだろう。たぶん。
まあ、別にそれでも変更差分をきちんと吸収してくれているならかまわないんだけども、使い終わったスナップショットをアンマウントするのになんで何分もかかるのかがわからない。
その上、使用済みのスナップショットボリュームを削除しようとしても失敗することがある。
# lvremove -f /dev/ms09/snapdebian Unable to deactivate open ms09-debian-real (254:5) Failed to resume debian.
これに関してはバグレポートが見つかった。
とりあえず4ヶ月経過しても治っていないらしい。
んーむ。
こうなるとバックアップ手法を見直す必要性が出てくる。
Dom0とDomUとで疑似遠隔rsyncでバックアップとなるのだろうか。
だけどそれだとrootでのリモートログインが必要となるから駄目だな。
ゲストはゲストでバックアップパーティションをディスクとしてアタッチして、各自でバックアップしてもらうような形ならいけるか。
あー、設定するのがめんどくさい。
とりあえずどういうことかというとログを張った方が早い。
# aptitude upgrade （中略） libc6-i386 2.13-16 を (.../libc6-i386_2.13-19_amd64.deb で) 置換するための準備をしています ... libc6-i386 を展開し、置換しています... libc-dev-bin 2.13-16 を (.../libc-dev-bin_2.13-19_amd64.deb で) 置換するための準備をしています ... libc-dev-bin を展開し、置換しています... libc6-dev 2.13-16 を (.../libc6-dev_2.13-19_amd64.deb で) 置換するための準備をしています ... libc6-dev を展開し、置換しています... libc-bin 2.13-16 を (.../libc-bin_2.13-19_amd64.deb で) 置換するための準備をしています ... libc-bin を展開し、置換しています... man-db のトリガを処理しています ... libc-bin (2.13-19) を設定しています ... (データベースを読み込んでいます ... 現在 52504 個のファイルとディレクトリがインストールされています。) libc6 2.13-16 を (.../libc6_2.13-19_amd64.deb で) 置換するための準備をしています ... /var/lib/dpkg/tmp.ci/preinst: line 141: /bin/mv: No such file or directory dpkg: /var/cache/apt/archives/libc6_2.13-19_amd64.deb の処理中にエラーが発生しました (--unpack): サブプロセス 新しい pre-installation スクリプト はエラー終了ステータス 1 を返しました dpkg (サブプロセス): 新しい post-removal スクリプト を実行できません (/var/lib/dpkg/tmp.ci/postrm): そのようなファイルやディレクトリはありません dpkg: クリーンアップ中にエラーが発生しました: サブプロセス 新しい post-removal スクリプト はエラー終了ステータス 2 を返しました dpkg (サブプロセス): rm command for cleanup を実行できません (rm): そのようなファイルやディレクトリはありません dpkg: クリーンアップ中にエラーが発生しました: サブプロセス rm cleanup はエラー終了ステータス 2 を返しました 以下のパッケージの処理中にエラーが発生しました: /var/cache/apt/archives/libc6_2.13-19_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) パッケージをインストールできませんでした。復旧を試みています: 現在の状態: 依存関係破損が 3 個 [+3], 更新が 113 個 [-4]。 # aptitude upgrade -bash: /usr/bin/aptitude: そのようなファイルやディレクトリはありません # exit logout INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: cannot execute "/sbin/getty" INIT: Id "1" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel
どうもlibc関係みたいです。
こうなると何もできない。
回避方法はアップグレードしないこと。
とりあえずholdしとけばいい？
んで、いつ修正されるんだこれ。
こっちの人も同じ状況になってるんだけど、libcのバージョンが結構違うのよね。
うちは
2.13-16 -> 2.13-19
あちらでは
2.13-2 -> 2.13-3
何となくだけどこれ環境によってでるでないがありそう。
さすがにみんながこの状況に陥るならリリースされないだろうし。
追記
やはりバグレポート提出されていた。
2.13-20で治ったらしいけど怖いなー。
あとでバックアップして更新やってみるか。
ファイルサーバのHDDが死にかけたので再セットアップ。
lvmでパーティションきりきり。
で、ファイルシステム作成。
# mkfs.ext3 /dev/fileserver/fssystem # mkswap /dev/fileserver/fsswap # mkfs.ext4 /dev/fileserver/file
ベースシステムのセットアップ。
# mount /dev/fileserver/fssystem /mnt/temp # debootstrap --arch=amd64 lenny /mnt/temp http://ftp.jp.debian.org/debian
いろいろと書き換え
fstabの設定 # cd temp # vi etc/fstab # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/xvda1 none swap sw 0 0 /dev/xvda2 / ext3 errors=remount-ro 0 1 /dev/xvda3 /fileserver ext4 defaults 0 0 ホスト名の設定 # vi etc/hostname files hostsの設定 # vi etc/hosts 127.0.0.1 localhost 192.168.1.x files.waterblue.net files nicの設定 # vi etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.x network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 ネームサーバの設定 # vi etc/resolv.conf nameserver 192.168.1.x aptの設定 # vi etc/apt/sources.list deb http://security.debian.org/ lenny/updates main contrib non-free deb http://ftp.jp.debian.org/debian lenny main contrib non-free シリアルコンソールの設定 hvc0を使うようにしてttyは起動しない # vi etc/inittab 1:2345:respawn:/sbin/getty 38400 hvc0 #1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6 # vi etc/securetty hvc0 hvc0の作成 # cd dev # mknod hvc0 c 229 0
xenのDomU用設定ファイルを作る。
# # Configuration file for the Xen instance file, created # by xen-tools 3.9 on Sun Oct 11 14:47:01 2009. # # # Kernel + memory size # kernel = '/boot/vmlinuz-2.6.32-5-xen-amd64' ramdisk = '/boot/initrd.img-2.6.32-2-xen-amd64' memory = '512' # # Disk device(s). # root = '/dev/xvda2 ro' disk = [ 'phy:/dev/fileserver/fsswap,xvda1,w', 'phy:/dev/fileserver/fssystem,xvda2,w', 'phy:/dev/fileserver/file,xvda3,w', ] # # Hostname # name = 'file' # # Networking # vif = [ 'ip=192.168.1.x,mac=xx:xx:xx:xx:xx:xx' ] # # Behaviour # on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart'
あとは/mnt/tempをアンマウントしてxm create file -cで起動してコンソールログインしてお好きに。
ちなみに、ext4ファイルシステムはカーネル2.6.26だと
# tune2fs -E test_fs /dev/fileserver/file
やってからext4devじゃないとマウントできなかった。
2.6.32だとext4じゃないとマウントできなかった。
xenでDomUを構築した際、コンソール接続したいと思うだろう。
通常、Linuxではttyが標準のキャラクタデバイスになっているが、xenでは専用の仮想コンソールデバイスがある。
それはxvcであったり、hvcだったりする。
What’s the correct console device name for my Xen PV guest
- Xenlinux (“xenified”) kernels use “xvc0″ as the console device.
- Upstream kernel.org pv_ops kernels use “hvc0″ as the console device
Examples of Xenlinux kernels using “xvc0″ console:
- xen.org linux-2.6.18-xen
- RHEL5 / CentOS5 kernel-xen 2.6.18
- Debian Etch 2.6.18-6-xen
- Debian Lenny 2.6.26-2-xen
- Ubuntu 8.04 LTS “hardy heron” 2.6.24 xen kernel
- Novell SLES 10 and SLES 11 xen kernels
- OpenSUSE xen kernels
- Various “xenified” forward-ports of the Novell/OpenSUSE Xen patches (2.6.29, 2.6.30, 2.6.31)
Examples of pv_ops domU kernels using “hvc0″ console:
- All upstream/mainline kernel.org Linux kernels since 2.6.26.
- Fedora 10, Fedora 11, Fedora 12 kernels
- Ubuntu 8.10 2.6.27 server-kernel
- Ubuntu 9.04 2.6.28 linux-image-server
- Ubuntu 9.10 2.6.31 ec2-kernel
で、xenではDomUとコンソール接続する際、標準ではそのキャラクタデバイスに接続するようになっている。
キャラクタデバイスを変えたい場合は、ブートオプションでxenconsで指定する。
実際はDomUの設定ファイルの、extraを用いて以下のようにすることが多いだろう。
extra='xencons=tty'
みたいな感じで。
でも特に理由がないなら標準の方を使った方がいいんだと思う。たぶん。
でまあ、DomUのセットアップの仕方によっては、DomUにxvc0あるいはhvc0が作られなかったりすることがある。
そういう場合は、作ってやればいい。
# mknod /dev/hvc0 c 229 0
みたいな感じで。
sshでもコンソールでもログインできないときはDomUのファイルシステムをマウントして、マウント先のdevに作ってやる。
で、/etc/inittabに以下を記述
1:2345:respawn:/sbin/getty 38400 hvc0
/etc/securettyに以下を記述
hvc0
ちなみにxvcはxen virtual console, hvcはhypervisor virtual consoleの略らしい。
今までxen 3.2 + linuxカーネル 2.6.26-2で運用してきたんだが、思い切ってバージョンアップに踏み切った。
debianではカーネルパニック起こしまくってなかなかバージョンアップできなかったんだけども、ようやくいけたのでかきかき。
動作した組み合わせは
- linux-image-2.6.32-5-xen-amd64
- xen-hypervisor-3.4-amd64
の組み合わせだ。
xen 3.4と2.6.26のカーネルとかでも普通にパニックおこしたけどもこの組み合わせはいけた。
ふーやれやれっていうかんじ。
ときにxen 4.0はdebianではいつでるんだろ？
パッケージの様子をみていると、4.0.0-1~experimental.1がpending uploadsにはなってる。
そのうちexperimentalあたりからリリースされる感じだろうか。
Previous Entries
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts
Back
Void 
Life 
Earth 
Wind 
Water 
Fire