admin の紹介

このサイトはAWSのEC2の一番小さいLinuxサーバで動かしています。 アクセスは少ないのでとりあえずは快調に動いています。

Drop Box Windowによるファイル転送

RemoteFileTransferに関してサーバ側のWebServiceはなんとか満足できる動作をしていますが、Client側はjavaのコマンドラインアプリケーションで実行しています。これをAmazon Cloudのようなウィンドウズアプリケーションにしてファイルのドラッグ&ドロップで作業できないかトライしてみました。
ネットをいろいろ調べてみるとSwingにはTransferHandlerという仕組みがあるようで、それを自分の実行したい実装をつけてextendsして、それをSwingのオブジェクトにくっつければ何とか動作しました。

まだ、ウィンドウ上のステータス表示やリモート側のリスト表示がありませんが、とりあえず、一区切りとして..

サンプルコード

Web ServiceのSSL化

昨日ちょっと触れました、Web ServiceのSSL化です。
2時間位、ネットの情報とともに格闘したら解決しました。意外に簡単でした。

まず、自分のhtppsの環境を理解する必要があります。Tomcat上のアプリケーションがhttpsで通信される場合、二つの方法があります。ひとつはApache(httpd)でSSLをイネーブルして、Tomcatでは何もしない方法。もうひとつはApacheはいじらず、Tomcat自体のSSLを有効にする方法。Apacheを使用していない環境であれば必然的に後者になります。
このあたりの環境を理解しないでネットの調査をするといらないことに時間を費やしてしまいます。私のように….。私の環境はApacheでSSLです。

Apache側でSSLを実現していますので、私の場合にはTomcatをいじる必要はありませんでした。まず、ベースは他のWebApplicationのSSL化と同じことになります。このあたりは以前、自分のWikiに記載しておきました。
Client側のURLをhttpsに変更してClientを起動します。しかし、以下のようなエラーが出てしまいます。
javax.servlet.ServletException: javax.servlet.jsp.JspException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
実はClient側のJREがこのサイトを正規のものと理解できないので、アクセスできないようです。ですから、ClientのJRE自体にこのサーバの認証データを登録する必要がありました。
先ほどのApacheのSSL化では以下の三つのセキュリティ関連のファイルを作成しました。
server.key(秘密鍵)
server.csr(CSRファイル、公開鍵+証明書申請情報)
server.crt(デジタル証明書)
このうちClient側に設定するファイルはserver.crtです。
このファイルをブラウザーを使用してPCにダウンロードすると、なぜかファイル名が
server.cer
に変化していました。ブラウザー、あるいはWindowsがファイルの意味を理解しているようです。
さて、各JREには以下のようなファイルがあり、そこにサーバの認証情報が格納されるようです。
例:\glassfish3\jdk7\jre\lib\security\cacerts
keytoolというjavaのツールを使ってcertificateを追加します。keytoolはjre\binにありますので、場合によってはPathを張る必要があります。
コマンド:
> keytool -import -alias <別名> -file client.cer -noprompt -trustcacerts -keystore %JAVA_HOME%/jre/lib/security/cacerts

私の実例:
keytool -import -alias nantoka7cert -file server.cer -noprompt -trustcacerts -keystore \glassfish3\jdk7\jre\lib\security\cacerts

いくつかのJREを併用している場合はそれぞれ設定しておいた方が良いかもしれません。
この時点で最初のエラーは出なくなりましたが、私のjRE7の環境ではさらに以下のエラーが出ました。
Exception in thread “main” javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
これはJREからURLの表現に関してセキュリティが厳しくなっているようで、私のssl.confの設定しデフォルトのままだったので起きた問題でした。
ssl.conf内の設定:
以前:
ServerName localhost:443
以後:
ServerName nantoka7.com:443
JRE7の場合、SOAPのclientが指定するURLはこの設定と合致しないといけないようです。上記の場合、www.nantoka7.com ではだめで、nantoka7.comである必要があります。
これで私のFileTransferWebServiceもhttps上で動作するようになりました。
以前、SOAPではパスワードがPlain Textで送られるのが問題…というのを読んだことがあります。httpsを使えばその問題はクリアできますね。

 

 

 

 

FileTransferServer 一応の完成

先日からのWebServiceによるファイル転送プロジェクトですが、とりあえずの完成です。
細かい使い勝手などは今後修正していくにせよ、基本的な動作はとりあえず、満足できるレベルになりました。
前回の懸案事項のパケットサイズと周期の関係も
パケットサイズ: 64KB
周期(delay):500msec
をデフォルトとしました。これらはClient側でのコントロールできるパラメータですので、今後、クライアント側を修正していくなかで改良できると思います。

サーバ側Code:
サーバ側オブジェクト
FileTransferWebService.java
サービスの本体となります。Clientから使用可能なMethodは以下となります。
createFile(String filename)
ファイル名に該当するFileオブジェクトを作成し、コネクションに追加する動作となります。
deleteFile(String filename)
ファイル名に該当するファイルを削除します。
listFileNames(String filename)
サーバ側に存在するファイル名の配列を戻します。
put (String filename, ChunkData packet)
ファイル名に書き込むデータをサーバ側に送ります。戻り値が0の場合はデータが正常に書き込まれたことをあらわします。それ以外の値が帰ってきた場合には、その番号のパケットをサーバ側が求めていることを意味します。

ChunkData.java
ここで、Client側とやり取りするパケットのフォーマットを定義しています。ファイルの送り手側がそのファイルに関する全パケット数と各パケットの番号をセットします。サーバ側で、そのパケットの順序どおりにファイルに書き込むことになります。パケットには該当のファイル名も含まれています。ファイル名によって、後述のコネクションを識別することになります。

Connection.java
WebServiceの場合、一つ一つのリクエストごとにそのリクエストがどのファイルのものかを識別しなければなりません。また、データの書き込み途中のFileオブジェクトも管理する必要があります。それをこのConnectionオブジェクト内のリストで管理します。新規にファイルが作成される場合や、削除、あるいはデータ書き込みがされる場合にはこのリスト内にファイルが存在するかを確認し、もし、存在すればそのFileオブジェクトに対して所望の処置を行い。もし、そのリスト内にFileオブジェクトが存在しなければ新規に作成することになります。
このファイルオブジェクトはファイル名で管理されています。

 サンプルクライアントCode:
対向のホスト名(アドレス)、ユーザ名、パスワードの後に、
list
create
delete
のキーワードによってファイルを転送したり、削除したり、サーバ側の確認ができます。

EC2のサーバにファイル転送を行う場合、二つの方法を使っていました。
Poster(FireFoxのadd-onのPUTクライアント)
SCPによるファイル転送
Posterの場合は大きなファイルの転送を行おうとするとうまく送ることができないことがありました。また、SCPの場合、SSHのパスワード認証をEnableにしなければならず、セキュリティ上好ましくありません。
今回、WebService経由でのファイル転送の手段が増えましたのでサーバにファイルを送る際のオプションが増えて助かります。できればこのサービスをSSL上に移行したいところですが、Certificateのところでうまくうごかないんだろうと思っています。

 

 

Web Serviceによるファイル転送

さて、PCの引越しも終了しましたので以前のWebServiceを使ったファイル転送プロジェクトです。 Goodle, AmazonそしてMicrosoftでも無料のネットワークストレージが提供されていますが、 基本的にこのネットワークストレージにファイル転送する手段はhttpベースと私は理解しています。 httpベースなので、FWでがちがちにポートを絞られている環境でも動作することができます。
同じような仕組みを自分のEC2のサーバで作れないかというのが今回の発端。
Webサービスでサーバからデータを取り出したり、逆にデータを転送する仕組みはつくりましたので、 その延長上の仕組みとして
サーバ側:  File作成  File削除  Fileへのデータの追加
…これはファイルの作成時にFileオブジェクトにデータを書き込む仕組みです。
基本的にはこれだけなのですが、Clientからのリクエストが一回ごとに独立したSoapリクエストになりますので、 File名をキーにしてそのFileオブジェクトなどを保持する仕組みが必要です。
クライアント側:  ローカル側のファイル名とそのファイルのデータをパケットにしてサーバ側に送ります。  ファイルのサイズから事前にトータルパケット数と毎回の送っているパケット番号をデータに組み込みます。
本当は、サーバ側とクライアント側でパケット番号のミスマッチがおきたときの処理なども実装が必要ですが、 そこまではまだ詳しく考えていません。
まあ、とりあえず、この仕組みでファイルの転送を行うと600KB程度のファイルは問題なく遅れるのですが、数MBを 超えるファイルは途中でconnection timeoutでAXISのエラーで転送がとまってしまいました。

調査してみると、サーバ側、クライアント側ともにTimeWaitのソケットが大量に存在しています。 おそらく、ソケットのリソースが枯渇して接続できなくなってしまうのでしょう。 そこで、一回のパケットのサイズを1KB、一回の転送ごとに1秒のsleepをいれたところ、とりあえずは転送が 止まることはなくなりました。
ただし、この設定では9M程度のファイルの転送時間が9000/60/60=2.5と約2時間半もかかります。
どのくらいの値にチューニングするのが良いんでしょうね?
Amazon Cloudアプリの動作をWiresharkで解析してみても勉強になるかもしれません。

 

 

 

Specified JDBC Driver com.mysql.jdbc.Driver class not found

PCの引越しをしていますが、Eclipse上で以前作成したWebApplicationがローカルでDBにアクセスする際にエラーになりました。

一応、Reference Library には
mysql-connector-java-5.1.20-bin.jar
へのパスが張ってあるのですが、Driverのクラスが見つからないようでした。
最終的にはWeb Applibrary(WEB-INF/libへのファイルコピー)にファイルを追加することによって、動作しました。
Hibernate実行時に使用されるライブラリはWeb-INFに存在しないといけないのかも知れません。

 

青空文庫 吉川英治の刊行予定

Kindleストアでの吉川英治作品の有料販売はちょっとショックでしたが、自分の読みたい本のフォーマット変換を実施し、変換した場合はサイトにアップしていきたいと思います。
吉川英治、短編もいいですね。「鬼」なんて最後に泣きそうになってしまいました。昔は吉川英治は流行作家でもあり、その作品はある意味その時代の「一般的」なものであったのかも知れませんが、今、読んでみると、新鮮でキックもあり、また、現在ゆえに心を打たれる点も多いように思います。大きな意味では吉川英治も「現代の作家」ですが、「現在の作家」も負けずに創作しなければなりませんね。

さて、青空文庫今後の吉川英治刊行予定です。

3/21 増長天王、茶漬三略
3/24 野槌の百、旗岡巡査
3/27 春の雁、八寒道中
3/30 べんがら炬燵、無宿人国記
4/3  柳生月影抄

4/6からは鳴門秘帖が始まります。

今のところ、今年青空文庫で刊行された吉川英治は、本日刊行の治郎吉格子と醤油仏以外はすべて読み終えました。

kindleストアの有料「吉川栄治」作品

Kindleストアに青空文庫をベースにした、「吉川栄治」の作品が有料で販売されていました。青空文庫の作品については、宮沢賢治や夏目漱石の作品が無料版としてKindleのサイトにアップしていましたので、吉川栄治についても当然、時間の問題でアップされると思っていたのですが、有料でアップされていたのがびっくりです。
青空文庫が二次使用に関して基本自由の方針ですのでこのこと自体は不法ではありませんが、ちょっと残念です。せっかくボランティアの努力によって電子化された情報をちょっとデータフォーマットの変換程度のことで利益を上げようというのはあまり誇れた行為とは思えません。
わたしは、個人的に今年の「吉川栄治」の著作権切れを楽しみにしていたので、青空文庫で作品が公開されると同時に自分でファーマット変換をしてKindleで読んでいます。自分が楽しむために変換したデータですが、もしかしたら、他の人の役に立つかも知れないと思い、サイトにアップしています。あくまでも個人の趣味のサイトなので多くの人にアクセスして欲しいとか、広告で稼ぎたいとか、そういう意図はないのですが、今回のようなケースをみると、自分のサイトももう少し注目されれば社会に貢献できるのではなどと考えてしまいます。
青空文庫による電子化は本来はもっと広い二次利用を理想的な目標としているのだと思います。たとえば、個人的に宮本武蔵の研究をしている人が、吉川栄治の宮本武蔵をベースに自分の考えや、感想を絡めた、新たな解説本を作成したり、本文そのままで、自分の挿絵や写真などを挿入したり、青空文庫のデータをベースにいくらでも二次的な創作の可能性は広がると思います。そのような作品であれば、どのような価格設定がされていても誰も文句はないでしょう。実際、そこには二次創作をした人の著作権が発生するわけですし…
いずれにせよ、基本的にデータフォーマットの変換だけを実施して、その労力の対価として価格設定される電子データに違和感を感じる人は多いと思います。とくに青空文庫の場合、データの入力やなど校正にどう考えてもデータ変換よりも多大な労力がかかっているわけですから、そのデータが無料で提供されている意味を理解できないのだとすると悲しいです。

 

Windows8 Zipファイル内の日本語ファイル名が文字化け

仕事で使っているPCのWindows8へのアップグレード終了です。
HW的には同じLapTopを使用しますので、
自分のPC(WinXP)—>代替PC(Win8)—-> 自分のPC(Win8)
という流れで2回の引越しが必要でした。
自分の快適な環境を再構成するのに結構手間取っていますが、ぶつかった問題のひとつが表題の現象。
基本的にはファイル名も日本語で表示、作成できるのですが、どういう訳かほかのPCでZIPしたアーカイブファイル内の日本語名のファイルが文字化けします。
最終的に修正したのは以下の手順
Control Panel —> Region and Language —> Administartive タブ
ここで
Language for non-Unicode programs
ここの設定を
Japanese (Japan)
設定にすることでZIPファイル内の日本語ファイル名も読めるようになりました。

勉強不足ですが、Windowsの日本語名ファイルはShift JISなんでしょうか?それともUnicode?

 

 

ベランダ園芸

春らしい陽気になってきました。
室内で育てていたサボテンなども日光浴です。
成長の記録として、写真撮影

息子が小学2年生のころの学研の付録の種から育てたサボテンです。
最近、ネットでサボテンの育て方を少し学びましたので、今年は少し真面目に取り組もうかなと思っています。


マンションの花壇で枯れそうなので植え替えたオキザリスです。
小さな鉢に移して、部屋の中の窓辺に置いておいたら葉っぱが茂り始めました。
最近は状態が変わりませんが、今後、生育してくれることを期待しています。

1月にAmazonで購入したサボテン栽培セットのナガサボちゃんです。
よく見ると、二つに開いた上の部分に細いトゲができ始めています。
高く育つ種類とのことです。

 

こちらはマルサボちゃん。丸いサボテンになるはずです。こちらはトゲらしいものはまだみあたりません。

AWS サーバのアップグレード検討

AWSの無料枠でEC2のMicro Instanceを使っていますが、メモ容量が600Mです。
このサーバ上にAppache, Tomcat, MySQLをベースにWordpressや個人のWebServiceなどを走らせていると、通常状態でメモリの残りが10M以下という事態もしばしばです。
やはり、ここはサーバのアップグレードをしたいのですが、Microの上のSmallサイズのサーバのスポットインスタンスのコストは東京のオンデマンドで $0.088/hour、一か月毎日24H運用にすると$64、6000円弱といったところでしょうか。
一応、Webサイトですので、 24Hx365D動かしておきたいのですが、6000円はちょっときついですね。無料期間が終わった際のMicro Instanceは$0.027/H 一か月約$20、micor->Smallのアップグレードで費用が3倍になります。
ここでAWSのEC2に関してはリザーブドインスタンスという考え方があり、1年、あるいは3年契約である金額を前払いすればトータルのコストが下がるというものです。前払いの固定料金を払うことで従量部分の料金が安くなり、24Hx265Dで使用する場合のトータルコストを軽減できます。固定部分が一番高くて、従量部分が安くなるプランの場合、私の試算では、Smallインスタンスで一月あたりのコストを約$36まで下げることができます。
さらに、AWSのEC2の価格はRegionごとに異なっていて、日本は高めの価格になっています。一番安そうなのはOregonのEC2、OregonのSmallインスタンス、1年契約ならば一か月あたりのコストを $28程度まで下げることができます。余談ですが、EC2はRegionごとに管理しています。もし、Oregonで今の東京のインスタンスと同じものを起動するにはEBSのSnapshotをOregonにコピーすればそのSpanshotを使用してインスタンスを起動できるようになります。
日本からOregonまでの遅延がどの位なのかわかりませんが、自分のサーバが海外にあるというのもちょっと気持ちいいかもしれません。
いずれにせよ、現在はまだ、microインスタンスが無料で使用できますので、よっぽど酷い状態にならない限り、このままの状態で使い続けることになると思います。

カテゴリー: AWS