メールサーバを更新

色々資産？を整理という事でメールサーバを縮小化する計画のメモを残す事に。基本思いついた事、やった事を忘れないように書いたメモなので読み物としてまとめる気はありません。

まずは能書き編。

今まで長らくメールサーバは専用サーバを借りて運用していたけどVPSの安サーバに全面移行する事にした。これには色々背景があって専用サーバを借りた当時は自分で隅々まで管理出来るメールサーバを建てるにはこれしかなかったというのが大きく、またVPS自体は色々なサービスを試してみたがなんとなくメールの様なインフラをまかせるには信頼度という面で疑っていた部分もあって移行できずにいた。これには根拠になるデータがあるわけではなかったのでデータ取りの意味でも移行をしてみようというのが今回のストーリー。

ぶっちゃけgmailの様にある程度完成されていてSPAMも少ないサービスをベースにするのも考えてはいたのですが、もともと自前で全部やろうとした背景には自分自身のスキルアップというものもあったので100%移行するのもどうかと思っている次第。

あとはメールサーバみたいなものは基本的に設定を一回してしまえばセキュリティ的なパッチ以外は手を加えない事が多いので色々設定した内容を忘れてしまうというのもこうしてメモを残す背景の一つだったりする。

方針としてはまず

1. postfix、dovecotをベースに考える
2. SPAM対策もそれなりに行う（ここが一番変化する部分かも）
3. 管理コストを最小限に減らす
4. 今後の引越しがしやすい様にする

1) postfix、dovecotをベースに考える

こちらは結局smtpdの現状のデファクト・スタンダードは相変わらずpostfixの様だというところからです。pop3/imap4に関しては長年使っているdovecotから乗り換える理由も無いかなと。未だにqmailの方が扱いやすいと思っている人間なので（様々な理由で戻る気はありませんが）そこら辺をなんとか克服したいトコロ。たんに勉強と経験不足なだけですけどね。

個人的にはもう少し違う世代のサーバプログラムがあるならいじってみたいところだと思っていますが・・・Lamsonとか色物な感じはしますが面白そうな気もしています。求めているものが全て1パッケージになっていると楽ではあるんですが、ある程度の軽さと容易さを兼ね備えたものってナカナカ無いし・・・。

2) SPAM対策もそれなりに行う

SPAM対策に関しては別エントリーで書きます。長年色々な用途に使い続けすぎて現状完全にハニーポット状態なのでまぁ、いい加減SPAMを消すのにも飽き飽きしているしスマホで受ける事を考えると必要な物だけ来て欲しいというのもあるので。永遠の課題なのかもしれませんが、逆にメールサーバをいじっていて一番楽しいところなのかも・・・ｗ

3) 管理コストを最小限に減らす

もともと面倒くさがりなので出来る限り簡単に管理出来る様にしたいところ。また、VPSにする事によってコストが非常にさがるので二重化も考えたいと思っています。二重化するという話になった途端に色々と問題点も出てくるのでその辺りもノウハウとして一個一個潰していきたいと思っています。

4) 今後の引越しがしやすい様にする
個人的な印象ではVPSは浮き沈みが激しく、使用開始当時に良くても品質が落ちたり会社が潰れたりという事がよく起きます。また、専用サーバのハード依存なものとは違い、サービスの仕様が年を追う毎に良くなっていくのも特徴でマイグレーションのコストを下げることによってより良いサービスに移行出来る可能性を秘めているというのも特徴と思っています。これは3番の二重化の話しとほぼ同義だったりするかもしれません。

embedded開発はじめました その２

昨日GCCをビルドしたりシコシコやっていたわけだけど面倒くさがりが早くも顔を出し結局バイナリでインストールしてしまいました。ダウンロードも含めて5分ぐらいで終了。あれ！？簡単すぎた・・・。

いや、ちょっと色々先達の情報を見ていたらWindows環境の人はSourcery CodeBench Liteとかでさくっと環境作っている訳ですよ。他にも開発環境売っている会社いっぱいあって、お試し用の廉価版とかを出している所もいっぱいあるわけです。じゃあマックも何かあるんかい！と思って調べたら。

http://www.yagarto.de/index.html#downloadmac

ああ、これでいんじゃね？って事でダウンロードしてイメージファイルをマウント。インストーラをダブルクリックしたら・・・あら不思議。簡単にインストール完了！

・・・しなかったorz よくよくドキュメント読んだらインストール先にインストーラをコピーしろだとさ。なんか単なる自己解凍形式だったみたい。というわけで、適当な所に展開をすると

yagarto-4.6.2

なんてフォルダーが出来たのでなんとなく

/usr/local/yagarto/yagarto-4.6.2

ここに配置（sudoさん使って移動してね）。その後マニュアルに書いてある通りにパスを通しておしまい。

$ vi ~/.bash_profile

export PATH="$PATH:/usr/local/yagarto/yagarto-4.6.2/bin"

export PATH="$PATH:/usr/local/yagarto/yagarto-4.6.2/tools"

これで

$ arm-none-eabi-gcc --version

とかやって反応があったら一段落。一応M4にも対応しているのを確認して一安心。

開発環境なんぞさっさと揃えて先に進みたいからとりあえず今日はこれで良しとする。もっと最適化をしたいとか色々欲が出て来たら自前でビルドも考えようと言う事で今日は気持ちよく寝れそうです。

余談ですが昼休みに購買に行ったらinterfaceの新しい号の特集がuCLinuxで思わず購入してしまいました。ついでにカメラモジュールの記事があったトラ技も。なんかタイムリーにもほどがあるでしょ・・・。

embedded開発始めました

なんか本業そっちのけな見出しです。まぁ良かろう。

という訳で、マイコンボード上に勉強がてら一から積み上げた簡単なシステムを構築してやろうというところをゴールにすえます。現状、一般的に買い易い物はarm系という事でPandaやらBeagleやらがお買い得だしAndroidとかもモリモリ動いちゃうのですが、学習用という意味でもう少しシンプルな物という事で最初のターゲットをCortex-M4に定めてSTM32F4-Discoveryをお買い上げ。

まぁ、本業関連でM4自体はちょっとDSP的な処理も出来るマイコンというイメージだけど実際のところどのくらい性能出るんよ？ってのを検証したいというのが本当の目的だったりします。Cortex-A8/A9までは必要無いけどお安く程々に色々出来そうという期待も込めて。NetDuinoみたいにArduino互換でお手軽に使える様になるとHappyですね。

まずは開発環境を整えないといけないのでメインマシンのMacBookAir上にクロスコンパイル環境を構築してボード上で何かプログラムを実行出来るというところまで持って行くのを最初の目標にします。

まず、目標のイメージですけど

＜図 後で埋める＞

こんな感じかな？

1. 開発環境(binutil/gcc/gdb)を用意する


2. JTAG用にopenocdを用意する（今後の為に）


3. 開発が楽な様にEclipseベースの環境を揃える


4. 簡単なプログラムを作ってターゲット上で動かす


5. 既存のOSをポーティングする

というわけでステップ１

コンパイラを用意しましょう。バイナリで配られている物もある様ですがとりあえず全部自分でビルドしていきます。自前ビルド自体に特に意味がある訳ではないですが。

用意したのは下記のバージョンのもの。

ビルド用（newlibはredhat、mpcはmpcのページ。その他はGNUのFTPから）

• binutils-2.22


• gcc-core-4.6.2


• gcc-g++-4.6.2


• gmp-5.0.4


• mpfr-3.1.0


• mpc-0.9


• newlib-1.20.0

デバッグ用

• gdb-7.4


• openocd-0.5.0

ビルドの手順ですが最初下記のリンクを参照してGCC4.2.4のビルドをしたのですがヨクヨク調べてみたらM4で使うにゃ4.6以降じゃないとまずそうなのでしきり直します。基本的な流れ及びbinutil/newlib/gdbのビルドはコレに準拠でいきましょう。

http://www.ethernut.de/en/documents/cross-toolchain-osx.html

とりあえず今日は負けという事でorz

そういえばM4のドキュメントも入手せねば。DSPまわりとか良くわからないし。STMあたりにあるのかなぁ？

HDD換装

ついでにこれも書いておこう

ずっと使い続けていたメインマシン(MacBook(Core duo 2GHz))のHDDが手狭なのを外付けHDDで凌いでいたのがだんだんもう億劫になってきたので新しいHDDを購入。恐らくドイツで最後のPC系の買い物になると思う。

いままでHitachi党だったけど安さに負けて今回はWDに挑戦。過去にヘッド退避が頻繁すぎて即死したことがあるんでずっと手を出してなかったけど・・・どうなるやら。熱的には前のHitachiの方が熱かった感じがするので結果としては良い選択だったのかもしれない。

しかし、Macの移行は楽ですな。ディスクツールから復元して入れ替えるだけ。価格.comでマックに入れられるか否かなんてスレッド立ってたけど悩むような次元じゃなく普通に簡単に動いてます。

で、今まではなんと120GBで頑張っていたわけですが（最初は確か60GBのディスクが入っていたような）どうせならもうでかいの入れてしまえと一番大きい750GBをお買い上げ。1TBもあったけど12.5mm厚ということで対象外デス。

つか前のディスク比でも容量6倍ですな。ウハウハ。

これで気兼ねなく写真編集とかも出来るってなもんです。やっぱり内蔵ディスクに入っている方が気楽に編集出来るしイイ！

移転作業中

久しぶりにこのブログも再開。なんか見た目色々変わってるなぁ。

というのもドイツからの帰国も決定し、組込みばかりやっていた生活からこっち系に戻る可能性もあるので、リハビリがてら分散していた古いサーバを１サーバに集約する作業を開始した為。キープに近いアクセスの少ないサイトが多いのでさくらのVPSの試用も兼ねてこいつに集約する事にする。

当初は前から気になっていたnginxを使ってサーバを構築するつもりで色々やっていたけど、どうもこの人何でもこなす優等生という感じではなく特定用途に特化している感があり、不可能ではないけど実現するには色々設定が面倒くさそうで（IP一つにバーチャルホストで複数サイト、複数ユーザがいる状態で古いcgiやらを動かすなんてのをやっていた）結局lighttpdで日和ってしまった。

まぁ、お陰さまで数日頭を抱えて楽しんでいた悩んでいた問題がインストール、設定を含めてものの30分程度で解決。動作も良好ということで結果オーライですか。まぁ、勉強になりました。

nginxは使い方も大分理解してきたので別件に使ってみようと思います。

しかし、サーバの整理は面倒臭がってやってなかったけど、この５年放置していたと考えると凄いお金を無駄にしていたな・・・。今後は気をつけよう。

Connection refused

唐突に復活するこのブログ。

はっと気づいたら（Webサーバとしては）全然使っていない鯖のApacheにつながらなくなっていた。

ログを見てみると

[warn] (61)Connection refused: connect to listener on 0.0.0.0:80

という出力が多発した後にログが途切れていた。

ぐぐる先生曰く

http://www.cyberciti.biz/faq/connection-refused-connect-to-listener-on-000080/

という事で設定を下記のように変更。

# vi /usr/local/etc/apache22/httpd.conf

の

Listen 80

を

Listen <Global IP>:80

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

しかし、ずっと放置していて１年位普通に動いていたのに突然ダメになったのはなんででしょうな・・・うーむ。

SPAM対策あれこれメモ

現状のスパム対策に関する頭の整理を兼ねたメモ。

今のところ色々な方法が考案されているけどS25Rに関連する話（greylistingとtarpittingを組み合わせる）が効果高そうな気がしていて前から試したかったのですが面倒でやっていなかった。が、今の環境ではWebメールからシコシコ読む事が多くなったのでスパムを捨てるのが面倒くさいという事で効果測定をする事に。その前に現状よく語られるSPAM対策の個人的な理解と見解を。

HELO

ここの情報をどこまで信用してフィルタしてしまっていいのか疑問を感じる。

RBL(DNSBL)

ブラックリストの仕組みとしては有用だと思うけど、IPベースでフィルタするので巻き添えを食らってメールが届かなくなる事があるのがコワイ。でも自前で作るとメンテが面倒くさい。

Bayesian filter

話題になり始めた頃に試したが、効果は非常に高い気がした。ただし、100%間違えなく振り分けるという事は不可能なので、結局誤認識して捨てられていないかという所謂ゴミ箱漁りをしたくなるので本末転倒だと感じている。実際友達に送ったメールがそういうのに引っかかってて連絡がつかなかったなんて事もあったので余計な気を回す必要が増えて嫌い。個人的な見解ではサーバ側でやるよりもユーザが勝手にやれば良いと思う。とはいえこれはPOPでとったメールに対しては有効だけど、IMAPだとユーザ側でやるのはちょっと面倒かも。

S25R

スパムの殆どはプロバイダから送られてくるという観点でのもの。というわけでプロバイダから送られてくる物は殆どひっかけられるわけだけど、自宅サーバの人からの物も捨ててしまう。個人的な見解では動的IPでメールサーバやる事自体がナンセンスだと思うし、そんなもん捨ててしまえとは思うけどネ。結局のところgreylistingの前フィルタとしてしか意味が無いと思っている。

tarpitting

やりたい事はわかるけど、息を止めている時間をかなり長めにしないと効果が無さそうなデータが出ている様だし、サーバ側の負荷になるので正直好みではない。積極的に導入する気がしないので今後実験サーバをたてる際にでも見てみたい。と言う事でこれはまだ試してません。

greylisting

今回試したい目玉だった。一見さんは再送を強いるという事で着信が遅くなってしまうのが問題。ただし、普通のサーバなら不達は無いし、一回しかトライしないサーバだとしても送信者にエラーくらいは返すだろう。S25Rを使って怪しい物だけに適用する事でマイナス部分をかなり減らせる。また、SQLGrey等だと自動的にリストを作ってくれるので面倒が少ない。

番外編IPでフィルタ

アジア系とか南米系とか自分と関係無いだろうと思っているIPを根こそぎ拒否してしまうもの。正直気持ちはわかるけど過激すぎる気がする。酷いところは日本以外のIPは全部遮断とかもあったし・・・。ホームページでもこういうフィルタをしているところがあって情報を収集している際にはねられて一寸イラっとした事もちらほら。ある意味鎖国だよねぇ・・・日本人らしい対応だと思うけど。うちの環境では出来ない方法だな。




まぁ、とりあえずこんなところかな。

正直どれもリスクがあって手放しにこれだっという対策は無いと感じている。S25R+greylist、そしてサーバとしての自前のブラックリストを簡単に管理出来る仕組みを入れるというところがリスクを考えた場合の落としどころとしては良いところかなと。

で、実際にpostfix+sqlgreyを設定してみた効果はというと日本のアダルト系、出会い系のスパムはgreylistでほぼ壊滅に追い込めた。が、海外系のバイアグラだのなんだのってメール、しかもbotネットから来ていると思われるメールは再送をきちんとやってくれてスルーされてしまって結局期待してたほど劇的な効果は無かった。

この結果から言える結論としては

1. 日本のSPAM業者は効率向上の為に真面目にサーバをSPAM向けにチューンしている。そのおかげでgreylistやおそらくtarpitが非常に有効。


2. botネットを使う様な連中は物量で攻めて来るので１の様なチューンをしておらずノーマルなサーバから送っている為に普通のサーバと見分けがつかない為すり抜けてしまう。

こんなところだと思う。で１は対策しやすいとして２に関しては頭が痛いところ。見かけ上普通のサーバなのでブラックリストを使う位しか思いつかないけど、自動化出来ないといたちごっこだし、同じホストからの再送もそれほど無いので費用対効果が薄い感じ。同じ内容を複数のサーバから送ってくる（botネット）からそういう部分でフィルタは出来る気がしているけど、やっぱりコンテンツフィルタは抵抗があるな・・・。ブラックリストの仕組みにアドレス、ホストだけじゃなくて内容も保存しておいてコンペアとるなんてのも良いのかな？？

もうちょっと様子見＆統計をとってみたいと思う。