2015年5月25日月曜日

Amazon AMI にAmavid-new を導入してみた

CentOS の Postfixメールサーバにウイルススキャンとスパムフィルタリング機能追加のため amavisd-new と Clamav を同時にインストールしていました。標準のレポジトリーに amavisd-new と Clamav のどちらも提供されているためyum install でどちらも簡単にインストールできました。

Amazon AMI では、そのままで Postfix + amavisd-new + Clamav 構成のメールサーバは導入はできません。標準のレポジトリーに amavisd-new の提供がありません。Clamav は提供されていて、以下 URL などで分かりやすく導入に関する資料が載っています。

http://www.agilegroup.co.jp/technote/ec2-clamav.html

epel リポジトリを追加すれば yum で amavisd-new もインストールできるようになるようですが、いままで yum でインストールしたことしかなく amavisd-new をインストールすることでどのようなファイルがどこに配置され、どのような設定がされるのかよく分かりません。そのためepel レポジトリからインストールした amavisd-new で問題が起きないか心配です。

そこで amavisd-new (amavisd-new-2.10.1.tar.xz)をプロジェクトのメインサイト

http://www.ijs.si/software/amavisd/ 

からダウンロードして手動インストールしてみました。

[
このブロッグを投稿してからしばらくして、以下 URL のページを見つけました。よくわかっている方のページなので参考になるとおもいます

http://linux.yebisu.jp/memo/765
]


ダウンロードして最初に分かったことは、Postfix 用には2つのファイルしか必要ないということです。 (amavisd 本体と 設定ファイルamavisd.conf) amavisd は Perl で書かれたプログラムで、いくつかの Perlモジュールに依存しているようです 。Perlと依存モジュールがあれば amavisd は動作しそうです。

1. Perl をインストール

2. INSTALL ファイルに記載されている依存モジュールをインストール

Archive::Zip   (Archive-Zip-x.xx) (1.14 or later, currently 1.30)
Compress::Zlib (Compress-Zlib-x.xx) (1.35 or later, currently 2.060)
Compress::Raw::Zlib (Compress-Raw-Zlib) (2.017 or later)
MIME::Base64   (MIME-Base64-x.xx)
MIME::Parser   (MIME-Tools-x.xxxx) (currently 5.504)
Mail::Internet (MailTools-1.58 or later have workarounds for Perl 5.8.0 bugs)
Net::Server    (Net-Server-x.xx) (version 2.0 adds support for IPv6)
Digest::MD5    (Digest-MD5-x.xx) (2.22 or later)
Time::HiRes    (Time-HiRes-x.xx) (1.49 or later)
Unix::Syslog   (Unix-Syslog-x.xxx)
Mail::DKIM     (Mail-DKIM-0.31 or later, currently 0.40)

>perl –MCPAN –e shell
>install [モジュール名]

3. オプションとなっている Mail::Spamassassin モジュールをインストールしようとしましたがエラーになってしまいます。代わりに yum で spamassassinをインストールしました。

これで amavisd の実行環境は整ったはずですが、amavisd はどのように起動するのでしょうか。ダウンロード済のファイルに amavisd-init.sh がありました。とりあえず開いてみると "/usr/sbin/amavisd"(19行名), "/etc/amavisd.conf"(22行目)となっています。amavisd 本体は /usr/sbin に、設定ファイルは /etc にコピーしておけば、amavisd-init.sh で起動できそうです。

シェルスクリプトを /etc/init.d に amavisd という名前でコピーしてから、chkconfig –add でサービス登録、最後に/sbin/service amavisd start で起動できるはずですが、起動前に /etc/amavis.conf を確認しておきます。

17/18行目に起動ユーザ名/グループの指定があります。

17行 $daemon_user  = 'vscan';     # (no default;  customary: vscan or amavis), -u
18行 $daemon_group = 'vscan';     # (no default;  customary: vscan or amavis), -g

以下の行のコメントは外しました。

22行  $MYHOME = '/var/amavis';

32行 $db_home   = "$MYHOME/db";      # dir for bdb nanny/cache/snmp databases, -D
33行 $helpers_home = "$MYHOME/var";  # working directory for SpamAssassin, -S
34行 $lock_file = "$MYHOME/var/amavisd.lock";  # -L
35行 $pid_file  = "$MYHOME/var/amavisd.pid";   # -P

ユーザ/グループの既定値はないようです。いままで amavis というユーザ、グループ名を使っていたため、vscanをamavis に変更。まだ、Linux にamavisというグループとユーザがないため、amavis グループとユーザをログイン不能(-s /sbin/nologin)として作成しました。ホームディレクトリは /var/amavis にしました。

これで起動できそうです。amavis サービスをスタートすると、エラーが表示されました。必要なディレクトリが存在しないようです。/etc/amavisd.conf を見ると 36行目に

#NOTE: create directories $MYHOME/tmp, $MYHOME/var, $MYHOME/db manually

とあります。$MYHOME = '/var/amavis' ですので /var/amavis/tmp, /var/amavis/var, var/amavis/db ディレクトリを作成してから、ディレクトリのオーナーとグループをamavis に変更後、再度サービスをスタートさせてみました。起動しました。停止もできました。

Clamav との連携も amavis.conf の 383-386行のコメントを外して387-391行の Note の通りに設定すれば問題ないようです。

まだ確認したわけではありませんが、amavisd-new のインストールは Perl関連モジュール導入するだけなので epel レポジトリからインストールしても問題はなさそうです。インストール後の amavis.conf の$daemon_user、$daemon_groupとソケットファイル名を確認すれば Clamavとの連携も問題はないのではないでしょうか。

INSTALLファイル43-49行に外部プログラム(解凍用)に関する記述があります。

The following external programs are used for decoding/dearchiving
if they are available:
  compress, gzip, bzip2, nomarch (or arc), lha, arj (or unarj), rar (or unrar),
  unzoo (or zoo), pax, cpio, lzop, freeze (or unfreeze or melt), ripole,
  tnef, cabextract.
Self-extracting archives (executables) can be of types zip, rar, lha or arj,
and are only recognized when the corresponding dearchiver is available.

レポジトリから amavisd-new を Yum でインストールすると、これらのプログラムもインストールされるはずです。しかし、Amazon AMI ではrar, ripole, tnef などを別途導入しないとログに必要な外部プログラムが存在しないと書き込まれてしまいました。Amazon AMI 標準のレポでは提供されていないようなので、ログをみて必要な解凍プログラムを rpmforge から導入しました。

インストールが完了後に INSTALLファイルの下の方にインストール方法に関する説明が
あることを発見しました。わざわざ手動インストールしたので、ここに記載されている手順にしたがってインストールしたら amavis についてよくわからないままになっていたはずです。amavis.conf ファイルを見ながら(試行錯誤しながら)導入したおかげで いままでより amavis がよく分かった様な気がします。

備考:

いままでAmavisd の重要な設定について以下URLの解説が役に立ちました。amavisd と PostfixやClamav と連携する方法の説明は見かけますが、ウィルス感染したファイルが添付されていると判断されメールや、スパムと判断されたりしたメールをどう扱うかの設定についての説明はあまり見かけません。このページでは virus, spam, bad headerメールをどのように処理するのかの設定を説明しています。

http://www200.pair.com/mecham/spam/amavisd-settings.html



2015年5月16日土曜日

Windows/OSX/Linux でのHIDデバイスの抜き差し検知

1. Windows

何もしなくても HIDデバイスの抜き差しで、ウィンドウプロシージャに WM_DEVICECHANGE メッセージが投げられてきます。何もしなければ、デバイスを差すと複数の WM_DEVICECHANGEメッセージが発生します。抜いた時も複数のメッセージが発生する場合があります。

確実に抜き差しで1回の WM_DEVICECHANGEメッセージが発生するようにするには、このURLが参考になります。

http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-or-Removal


2. OSX

検知する デバイスの ID を登録しておき、そのデバイスの抜き差し操作があったら呼び出される関数を登録しておきます。そのデバイスが抜き差しされたら OS が登録した関数を呼び出します。差し込みの時、抜き取りの時と別々に呼び出す関数を登録できます。IOKitが必要です。

Windowsと比較すると、セットアップ処理をするコードを追加しなければなりませんが、細かな制御ができます。


 HID デバイスの抜き差し検知は安定しています。


3 Linux

Windows/OSX のようにプログラム内で HID デバイスの検知する方法を知りません。そのようは方法があるかどうかも分かりません。

udev ルールで HIDデバイスの抜き差し操作があったときに実行されるプログラムを登録できますので、そのようなプログラムを作成して、そのプログラムとアプリケーションプログラム本体とがプロセス間通信をして検知した HID デバイス情報は受け渡したり、抜き差しイベントを発生させたりすることができます。

udev ルールでプログラムを実行させる設定については、

http://www.reactivated.net/writing_udev_rules.html

のページ内の Running external programs upon certain events を参照してみてください。

抜き差しを検知するルールをセットアップ、抜き差しで実行させるコードを指定するというモデルは OSX とまったく同じですが、 OSX ではすべてがライブラリで統合されていて、アプリケーションプログラムの1つのスレッドでデバイス検知が可能です。一方 Linux はそのような統合はされておらず、それぞれのコンポーネントを手動でつなぎ合わせなければなりません。


カスタム Credential Provider の開発


Windows Vista以降の OS のログインは従来の GINA方式 から Credential Provider 方式になっています。

1. GINA では、GINA DLL からエクスポートする関数が決められていて、その関数を実装しました。

2. GINA 方式では、カスタム GINAがすべてを機能を実現することは不可能でした。 Windows 標準の msgina に依存しなければならない機能があり、エクスポート関数から msgina 内の同じエクスポート関数を呼び出す必要がありました

3. CP は COM になりました。Windows 標準の CP に依存することなく、カスタム CP ですべての機能を実装できるようになりました。


カスタム CP は、マイクロソフト提供の CP サンプルをもとに作成することが推奨されてます。

このブログと同じタイトルの Japan Platform SDK Support Team Blog の記事が以下 URL にあります。

http://blogs.msdn.com/b/japan_platform_sdkwindows_sdk_support_team_blog/archive/2011/04/22/credential-provider.aspx

この記事の内容を参考にしながら、CP サンプルをカスタマイズして独自 CP を開発していくことになるはずです。

弊社では CP サンプルをもとに MxLogon / GAuthLogon を作成していますが、1つ教訓を得ました。それは、CP のサンプルのコードは鵜呑みにしない、コードを確認しないまま使わないで、どのような処理をしているのか、そして、それが正しく処理されているかをある程度確認てから使うようにしないと、最後までバグに悩まされるということです。

Web には CPサンプルのバグが指摘している記事がいくつか見つかります。どこにも書かれていない問題点も存在するようです。

カスタム CP 作成のできるだけ早い段階で CP サンプルコードを確認することを勧めたいと思います。

CP V1 / V2 の2つのバージョンがありますが、V2 を先に開発すると V1 は V2のコードに V1/V2専用のコードを define 追加することで、容易に1つのコードベースから V1/V2 のどちらでも生成できるようになると思われます。

MxLogon は USBキーを利用した CP でUSBキーの抜き差しを検知して動作を決めます。ハードウェアの抜き差しを検知して動きを変える CP 開発は、ハードウェアと使わない CP と比較すると格段に難しくなるという印象があります。 その理由の1つは、CP が同時に2つ実行されることがあるからだと思います。サンプルのコードは同じ CP が同時に複数実行されることを想定していないようなので、カスタム CP ではそれを想定してカスタマイズする必要があります。

最初はソフトだけで完結する フルCP から作成して、その後ハードウェアを使う CP に手をつけたほうが、長期的には早道になるような気がします。

2015年5月13日水曜日

AWS で Windows サーバを立ててみる

現在まで10年ほど使ってきた Windows 2003 Server 用 PC は、頻繁につかっていたのではないので、まだ健在だ。過去数年は数か月に1度程度しか電源を入れていない。電源を投入すると大きなファンの音が鳴り響き、しばらくすると熱を放ち始める。さすがに真冬は暖房代わりとはいかないが、秋、春の肌寒い季節に起動しておくと、狭い部屋は暖かく感じる。夏は耐えられない。そして、何よりも耳に触るのがファン音だ。しばらく使ってから電源を落とすと、辺りに静寂が戻り、精神的にホッとする。このようなことから、電源を入れないで済むように環境を整備して、とりあえずなんとかなった。

騒音の出ないサーバがあれば便利だと思っていましたが、最近はAWS でサーバを立ち上げるというオプションもあります。サービスとしてサーバがクラウド上にあれば、熱や音で悩まされることはないはずだと思い、AWS で 社内用にWindowsサーバを立ち上げてみました。

なにしたいかというと、社内 LAN 上に AWSの Windowsサーバがあるかのような環境を整えることができるかどうか、そして、そのよう環境を実運用できるかどうかを確かめることです。

1. 社内 LAN と VPC間をVPN接続

AWS の VPN はIPsecなので IPsec対応の VPN装置が必要です。簡単に試せるような装置をさがしていたところ、

https://ultradairen.wordpress.com/2013/12/22/buffalo-vr-s1000-vpn-to-aws/
Buffalo VR-S1000 VPN to AWS

を見つけました。バッファロー VR-S1000 は実売価格 20,000円で、インターネットルーター機能、10接続VPN, 簡易NAS( USBポートに接続した USBメモリ/ハードディスクを共有できる ) といった機能を兼ね備えています。これを使って試してみました。


2.  AWS で Windows 2012 Server R2 (無料枠対象)インスタンスを作成


最初は何も考えずに Windows 2012 Server R2 のEC2 インスタンスを 作成してみました。物理的な作業はまったく不要で、身体を動かす必要がありません。OSインストールも不要です。
このインスタンスは VPC ( 10.0.0.0/16 )の サブネット 10.0.0.0/24 に配置したものとします。


3. VPC へのVPN 接続


この VPC に VR-S1000を使って接続してみます。

3-1  AWS側設定


a. カスタマーゲートウェイ作成 
社内インターネット接続の WAN IP アドレスを指定するのみで作成できます。

b. VPNゲートウェイ作成/アタッチ。
任意の識別名を指定するだけで作成できます。作成したら、VPC ( 10.0.0.0/16 ) にアタッチします。

c. VPN接続作成
カスタマーゲートウェイとVPNゲートウェイを指定して VPN 接続を作成します。ルーティングは”静的”を選択して、 VR-S1000 の LAN側アドレス ( 例えば 192.168.10.0/24 ) を指定します。

d. セキュリティ設定の追加
インバウンドルールで 送信元 192.168.10.0/24からのトラフィック、プロトコール, ポートを許可します。


3-2  VR-S1000 の設定


a. AWSコンソール - VPC - VPN接続で、作成済みの VPN接続を選択して "設定のダウンロード”で Microsoft - Windows Server の設定を取得します。

b. VPN ウィザードで ”事前共有キー”に Preshared keyの値、”リモートWAN IPアドレス”に
Remote Tunnel Endpointの値、リモート LANネットワークに 10.0.0.0, リモート LANサブネットマスクに 255.255.0.0 を設定して、[追加]します。次の画面で暗号化方式を AES-128 に変更します(2箇所)


3-3 設定確認


インスタンスのプライベート IP ( ここでは10.0.0.100 ) に対して PING して応答が返ってきました。次にリモートデスクトップでこのインスタンスに接続していました。AWSコンソールの EC2から Windows 2012R2のインスタンスを選択して、[接続]ボタンで 

a. リモートデスクトップファイルのダウンロード
b. Administrator ユーザのパスワード取得

をします。ダウンロードしたリモートデスクトップファイルをダブルクリックして RDP 接続を開始。ユーザ名(Administrator)とパスワードを設定して Windows にログインできました。


4 問題点

この Windowsサーバはデフォルトの VPCのサブネットで動いています。デフォルト VPCは、特に何もしなくてもインターネットゲートウェイが付いていため、インターネット接続ができるようになってます。インスタンスに Elastic IP が割り当てられていれば、そのパブリック IPでインターネットアクセスができますし、外部からこのインスタンスにアクセスできます。これは、社内 LANのサーバに外部からそのサーバの パブリック IP でアクセスできてしまうことを意味します。

これでは困ります。社内 LAN 上のサーバのように、プライベート IP だけを持っていて、外部には自由に NAT 経由で出ていくことができる一方、外部からはアクセスできないようにしなければなりません。


5. NATインスタンス


そのようは方法を探すと、AWS サイトにNATインスタンスというものが紹介されていました。

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html#NATSG"
NATインスタンス


a. デフォルト VPC とは別途 VPC を作成して、そこに2つのサブネットを作成。

b. インターネットゲートウェイを この新規 VPC にアタッチ

c. 1つのサブネットのルートテーブルでデフォルトゲートウェイにインターネットゲートウェイを指定
してパブリックサブネットとする

d. このパブリックサブネットに NATインスタンスを立ち上げる

e. もう1つのサブネットのデフォルトゲートウェイに NATインスタンスを指定。外部へは直接アクセスするルートはないため、プライベートサブネットになる

f. Windowsサーバをこのプライベートサブネットに配置する

g. この VPC に VPNゲートウェイをアタッチして Windows サーバに RDP 接続を行う


思っていたより簡単に Windows サーバをプライベートサブネットに配置できました。NATインスタンス専用の AMI があります。NATインスタンスは本当に起動するだけで、ログインする必要すらありません。ローカル LAN にブロードバンドルータを取り付けるといった感覚で設置できました。もちろん、LANケーブル、電源コードをいじる必要はなく、ブローバンドルータの既定 IP アドレスが分からないといったこともなく、AWSコンソールからすべて設定できました。

サブネットを複数作成してもルータを設置する必要がありません。ルータは”組み込まれている”
そうです。インターネット回線を用意する必要もありません。机に座ったままキーボードとマウス操作だけでインターネット接続できる複数のサブネットをもったネットワークにサーバを立てて、VPN接続できる環境を整えることができてしまいました。Windowsサーバに言語パックをインターネットから導入したときにインターネット接続が非常に速かったことに気づきました。

6. Windowsサーバ使用

Windowsサーバは北米リージョンで立ち上げました。既定では言語は英語になっていましたので、日本に変更しようとしてみると、ディスク容量不足でインストールできませんでした。無料枠は 30GBの容量でインスタンスが作成されていましたが、インスタンス作成直後、1GB程しか空き容量が残っていませんでした。これでは何もできないため、現在のボリュームのスナップショットを作成してから、ボリュームを削除、新規に 50GB の EBS ボリュームをスナップショットをもとに作成しました。


この新規ボリュームをインスタンスにアタッチして、インスタンスを起動しても C ドライブのサイズは以前のままです。 管理ツールの「コンピュータ管理」ー「ディスク管理」を使って Cドライブを拡張しました。

Cドライブの容量が 50GB になったところで、Windowsの言語を日本に変更してみたところ問題なく変更できました。

次に AWS の Windows サーバから社内 LAN 側のリソースを参照できるかどうか確認してみました。エクスプローラで \\(社内PCのIP) を指定すると、アクセスのためのユーザ情報が求められたあと、共有フォルダにアクセスできました。社内 LAN上のプリンタも問題なくセットアップでき、Windows サーバから直接印刷ができました。ほとんど遅延なく、北米のWindowsサーバから社内プリンタに印刷がされました。

おそらく社内 LAN に置いた物理サーバを置き換えることができるような気がします。


7  物理サーバ利用との比較


AWS の Windowsサーバは短期間の一時的な利用であればメリットは十分あると思われます。短期間の利用のために、わざわざ PC購入、設置、 OS インストールする必要はなく、使った分の費用しかからないため、費用的なメリットも十分にあるはずです。しかし、長期間にわたって使うことは零細企業にとってはコストメリットを十分に検討する必要があるような気がします。

AWS 費用は非常に細かく設定されていて、トータルのコストは1つ1つ積み上げてみないと分かりません。

a. EC2
b. EBS
c. Elastic IP
d. VPN接続

EC2 は停止可能、Elastic IP はデタッチ可能ですが、EBS は一度使い始めたら削除できません。VPN接続も、削除/作成を繰り返すわけにいきません。 EBS / VPN 接続は24時間/365日課金されるはずです( VPN接続を作成した時点から課金されると理解しています)

多くても数台のサーバが必要なだけの零細企業が業務に使うことことを考えると、すぐに飛びついて利用できるものではないのかもしれません。

AWS は、大手企業がオンプレミスのサーバ群を AWS に移すことができる環境を構築できるようなので、中途半端な部分はないはずです。すべてが”本格的” といった印象があります。クラウドサービスでもっとも気になるのがセキュリティだと思いますが、こちらも”本格的”のようです。

http://yoshidashingo.hatenablog.com/entry/2014/08/24/211825

このような本格的なインフラのコストだと考えると納得できる価格だとは思いますが、従来そこまで本格的なインフラを構築してきていない零細企業にとってはコスト負担増加は避けられないのではないでしょうか。

業務ではなく、提供する製品やサービスに利用する目的で AWSを活用する機会は零細企業にもあるはずですので、ハード/OS一切自前で用意することなくテスト、評価、試用目的で一時的に活用するメリットは十分にあるのではないかと思われます。

AWS ですぐに利用開始できたのは Route 53 DNSサービスでした。他のサービスとの違いは、ヘルスチェック機能が付加されている点で、この機能をつかうだけでもメリットはあるのではないかと思っています。

8  レンタルサーバとの比較

AWS でレンタル専用サーバと同じことをすることを考えると、コスト増は避けられません。インスタンスをハード占有にすると、1時間2ドルの追加料金(年 $2 x 24 x 365 = $17,520? ) が発生するようです。ハード占有にしない、リザーブドインスタンスにする、といったことで同等コストで Webサーバを構築できるかもしれません。同等コストで可用性、信頼性、保守性が高まるのであればメリットがでてきます。

可用性を求められる場合、本サーバ、バックアップサーバの2つのインスタンスを起動しておき、Route 53 DNSサービスでフェイルオーバを利用する、本サーバとバックアップサーバ間でデータの同期の問題がなければバックアップサーバは普段は止めておき本サーバに異常が発生したら通知を受け取り起動するなど、柔軟に考えた通りの構成を実現できそうです。

9 サービス提供のインフラとしての利用

AWS を使うことで零細企業でも大手と同じインフラを使ってサービスが提供できるようになります。サービスの可用性、安定性、信頼性について、AWSを使うことで”大手を同じインフラをつかっています、同等の可用性、安定性、信頼性です”といった形で提示できるメリットは大きいと思います。