Java Communications API
Java Communications APIが10年以上ぶりくらいに必要になったので探す。なんかRXTXというのを使えという記事が見つかるものの、飛び先がリンク切ればかりで、twitterでぼやいたところ、さくらばさんから場所を教えていただきました。もっともこのRXTXというのは、パッケージ名がgnu.orgになっていてJava Communications APIとは別物のよう。まぁUSBモデムデバイスが制御できれば良いので、これを使うことにする。
Linux amd64というマイナー環境なので、ソースからコンパイルすることにする。zipで置いてあるやつは、UTS_RELEASEという識別子が無いよ〜というエラーでコンパイルできないので、CVSから最新版を取る。
で、これだと/dev/ttyACMnデバイスが見つからないのでソースを修正する。src/gnu/io/RXTXCommDriver.javaを開き、
if(osName.equals("Linux"))
{
String[] Temp = {
"ttyS", // linux Serial Ports
"ttySA", // for the IPAQs
"ttyUSB", // for USB frobs
"ttyACM",// linux CDC ACM devices <<= ここを追加。
"rfcomm", // bluetooth serial device
"ttyircomm", // linux IrCommdevices (IrDA serial emu)
};
CandidatePortPrefixes=Temp;
}
あとは、定石通りconfigure/make/make installでok。あ、export JAVA_HOME=の指定が必要。
ここにあるデバイス列挙のサンプルを動かしてみると、列挙された。
shanai@desktop:/tmp$ java Test
WARNING: RXTX Version mismatch
Jar version = RXTX-2.2
native lib Version = RXTX-2.2pre2
/dev/ttyACM0 - Serial
/dev/ttyS0 - Serial
月食
丁度玄関先から見えたので月食を観察。うちの機材は望遠側は300mmまでしかないので、画角的にはこんな感じ。
撮影条件は、1/60s f10 ISO320あたり。以降はトリミング。
22:02頃
22:25頃
22:33頃
22:53頃
23:00頃
23:03頃ほぼ隠れてきて、暗い部分はノイズが厳しいのでシャッタ速度を1s近辺まで落とす。
23:32頃
23:34頃相当暗い。ss 3.2s f10 ISO1600。薄い雲が流れていて、シャッター速度があまり遅いと結構不鮮明。折り返し地点も過ぎたんで退散。寒かった。
ベートーベン ピアノソナタ第26番
ベートーベン ピアノソナタ第26番「告別」
Beethoven Piano Sonata No26 "Les Aduieux"
Italian Grand2で演奏。ハーフペダルとソフトペダルが、あると無いとでは表現の幅が全く違う。
JBossを狙ったwormにやられてしまいました。
JBossを狙ったwormにやられてしまいました。
侵入されたwormは、どうやらこれのよう。ここに解説があります。
ここに書くことは、私が個人的に調べたことで、必ずしも正しくない場合があります。
アクセスログを見て、HEAD /jmx-console/HtmlAdaptor... のような身に覚えのないリクエストがあり、サーバが200を返していたら、やられている可能性が高いです。サーバのカレントディレクトリ(通常はJBossのbinディレクトリ)に、pnscanとかfly.plのような見慣れないファイルがあるようなら、100%やられています。
jmx-consoleにきちんとユーザ、パスワードを設定していないことが原因で、これにより外部から管理用のWebアプリケーションをデプロイできてしまうようです。上記のページには、きちんとjmx-consoleにユーザ、パスワードを設定する方法が記載されていますが、一度でも侵入されてしまった場合、バックドアアプリケーションがデプロイされてしまっているので、jmx-consoleだけ手当してもwormがどんどん入ってきてしまいます。
基本的にはサーバを綺麗に入れ直すのが良いと思いますが、本稼働中だと、なかなかそうもいかないので、私は以下のようにしました。まずJBossを落とします。jmx-consoleとweb-consoleは使用していなかったので、deploy/jmx-console.war、deploy/management/console-mgr.sarをリネームしました。あと、deploy/managementの下に、idssvc.war、iesvc.war、zecmd.war、zlpwhWeJ.warというディレクトリがあるようであれば削除します。私の場合は特に見つかりませんでしたが、deploy直下に怪しいwarがあるようなら、それも削除(リネーム)します。あと、念のためdeploy/workも削除しておきました。binディレクトリに送りこまれたwormも削除します。これでJBossを立ち上げて、アクセスログを監視し、サーバが200を返しているリクエストに怪しいものが無いことを確認します。とりあえず、うちのサーバはこの対処をしてからは侵入されていないようです。
繰り返しますが、ここに書いた内容は間違っているかもしれませんので、ご注意ください。
Play frameworkでデッドロック その4
こりゃあかん、
framework/src/play/server/ServletWrapper.java
private void copyStream(HttpServletResponse servletResponse, InputStream is) throws IOException {
OutputStream os = servletResponse.getOutputStream();
byte[] buffer = new byte[8096];
int read = 0;
while ((read = is.read(buffer)) > 0) {
os.write(buffer, 0, read);
}
os.flush();
is.close();
}
というわけで修正。
private void copyStream(HttpServletResponse servletResponse, InputStream is) throws IOException {
try {
OutputStream os = servletResponse.getOutputStream();
byte[] buffer = new byte[8096];
int read = 0;
while ((read = is.read(buffer)) > 0) {
os.write(buffer, 0, read);
}
os.flush();
}
finally {
try {
is.close();
}
catch (IOException e) {
Logger.error("Cannot close input stream.", e);
}
}
}
このパッチ当てておけば、とりあえず、warで実行する限りは問題なくなった。
こちらもバグ報告しておいた。
