TomcatのDBアクセスユーザーのパスワードを暗号化する

TomcatでDBにアクセスする場合、server.xmlcontext.xmlResource要素に以下のような設定をします。

<Resource name="jdbc/TestDB" auth="Container"
    type="javax.sql.DataSource"
    maxTotal="100" maxIdle="30" maxWaitMillis="10000"
    username="javauser" password="javadude"
    driverClassName="com.mysql.jdbc.Driver"
    url="jdbc:mysql://localhost:3306/javatest"/>

この時、password 属性の値には平文のパスワードを書くことになりますが、「これはセキュリティ上良くないのでは?」ということを聞かれて、少し調べてみました。

まず、何よりも先に読むのはユーザーガイドです。

Tomcat 8.5 – JNDI Datasource HOW-TO – Database Connection Pool (DBCP 2) Configurations

ここには、暗号化についての言及はなく、設定例には平文のパスワードが記載されています。

ということで、少し調べてみると、TomcatのWikiの中にそれについて書かれたページがありました。

Tomcat Wiki – Why are plain text passwords in the config files?

この中で、いくつか対策の例が上がっていますが、いずれもパスワードを安全に保持にする方法ではなく、“Security by Obscurity”(隠ぺいによるセキュリティの確保)であり、根本的な対策にはならないと書かれています。むしろ、server.xmlに対する読み取りアクセスをrootユーザーやTomcat実行ユーザーだけに限定することの必要性について言及しています。

このXMLファイルのパスワードを暗号化することにどれだけの効果があるかは分かりません。しかし、それでも、気休め程度でも、平文のパスワードではなく、暗号化されたパスワードを書いておきたい、という方はいるのではないかと思います。そんな方々のために簡単な解決策となるファクトリークラスをつくってみました。これを利用すると、前述のXMLのpassword=”javadude”password=”xe2J0sJ+WlEAX3L4v/EI3A==”のように暗号化されたパスワードを書けます。Tomcat 8.5で動作確認しましたが、他のバージョンでは若干のロジック修正が必要かもしれません(DBCP2のライブラリを使用しているので)。

使用方法

使用方法は以下の通りです。

  1. GitHubからファクトリークラスをgit cloneして下さい。
    $ git clone https://github.com/k-tamura/encrypt-db-password.git
  2. encrypt-db-password/src/main/java/org/t246osslab/tomcat/dbcp/dbcp2の中にあるEncryptionDataSourceFactoryのメソッド encrypt()decrypt() に暗号化、復号化の処理を実装します(実装してありますが、変更して下さい)。:
        public static String encrypt(String source) throws NoSuchAlgorithmException, NoSuchPaddingException,
                InvalidKeyException, IllegalBlockSizeException, BadPaddingException {
            // TODO Remove the following code and write a processing of returning an encrypted string
            Cipher cipher = Cipher.getInstance(ALGORITHM);
            cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(KEY.getBytes(), ALGORITHM));
            return new String(Base64.getEncoder().encode(cipher.doFinal(source.getBytes())));
        }
    
        public static String decrypt(String encryptSource) throws NoSuchAlgorithmException, NoSuchPaddingException,
                InvalidKeyException, IllegalBlockSizeException, BadPaddingException {
            // TODO Remove the following code and write a processing of returning an decrypted string
            Cipher cipher = Cipher.getInstance(ALGORITHM);
            cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(KEY.getBytes(), ALGORITHM));
            return new String(cipher.doFinal(Base64.getDecoder().decode(encryptSource.getBytes())));
        }
    
  1. mvnコマンドでビルドします。
    $ mvn clean package
  2. 生成した依存ライブラリを含むjarで平文のパスワードを暗号化します。
    $ java -jar target/encrypt-db-password-1.0.0-jar-with-dependencies.jar \
     -e [平文のパスワード]
  3. 以下のようにデータソースの定義(server.xmlなど)を編集します:
  4. <Resource name="jdbc/TestDB" auth="Container"
        ・・・
        password="[暗号化したパスワード]"
        factory="org.t246osslab.tomcat.dbcp.dbcp2.EncryptionDataSourceFactory" 
        ・・・
        url="jdbc:mysql://localhost:3306/javatest"/>   
    
  1. 依存ライブラリを含まないjarをTomcatのlibディレクトリにコピーします。
    $ cp target/encrypt-db-password-1.0.0.jar $CATALINA_HOME/lib/
  2. Tomcatを起動します。

Tomcatのバージョンによって、若干の変更が必要かもしれませんが、こんな手順でいいはずです。

広告

EasyBuggy Bootのトリセツ

「EasyBuggy Boot」は、バグだらけのWebアプリケーション「EasyBuggy」のSpring Bootベースのクローンで、JavaのWebアプリケーションで起こりうる様々な問題を、非常に手軽に体験できるWebアプリケーションです。EasyBuggyと機能的な差異はほとんどありませんが、起動方法等に若干異なる部分があります。EasyBuggyよりも新しい技術が使われており、開発やデバッグがしやすくなっています。

easybuggy

EasyBuggy Bootの特徴

基本的にはEasyBuggyと同等の機能を持っているので、用途などはこちらのページを参照下さい。「EasyBuggy」と「EasyBuggy Boot」の主な構成の相違点は以下の通りです。

相違点 EasyBuggy EasyBuggy Boot
ベースとなる技術 Servlet 3.0.1 Spring Boot 1.5.6 (Servlet 3.0.1)
プレゼンテーション層 未使用 (一部 JSP 2.2 + JSTL 1.2) Thymeleaf 2.1.5 (一部 JSP 2.3 + JSTL 1.2)
DBクライアント/サーバー JDBC / Derby 10.8.3.0 Spring JDBC 4.3.9 / Derby 10.12.1.1 (Java 7の場合)、または10.13.1.1 (Java 8の場合)
LDAPクライアント/サーバー Apache DS Client API 1.0.0 / Server 1.5.5 Spring LDAP 2.3.1 / unboundid-ldapsdk 3.2.1
メール JavaMail 1.5.1 JavaMail 1.5.1 (Spring Boot Mailで導入されるJavaMail 1.5.6をオーバーライド)
開発ツール 無し Spring Boot Developer Tools 1.5.6
Java Java 6以上をサポート Java 7以上をサポート

スクリーンショット

以下はメインページで、ブラウザの言語設定によって日本語と英語が切り替えられるようになっています。見ての通り、いろいろなバグを確認できます。

68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f34333836392f34633864333931322d383736302d626363312d383834652d3465356131346536373131642e706e67

バグのリンクをクリックすると、そのバグが確認できます。

起動方法

EasyBuggyを起動して、http://localhost:8080にアクセスすると、メインページが表示されます。起動方法には次の3つがあります。

  • javaコマンドで起動
  • mvnコマンドで起動
  • warファイルをサーブレットコンテナにデプロイして起動

それぞれどのように使い分けるか説明します。

● javaコマンドで起動:

もっとも関単にEasyBuggyを起動する方法です。ROOT.warをダウンロードして、次のコマンドで起動します。

$ java -jar ROOT.war

この時、以下のようにJVMオプションを指定しておくと、問題が発生しやすく、またログを確認しやすくなります。

$ java -Xmx256m -XX:MaxMetaspaceSize=64m -XX:MaxDirectMemorySize=90m -XX:+UseSerialGC -Xloggc:logs/gc.log -Xloggc:logs/gc_%p_%t.log -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M -XX:GCTimeLimit=15 -XX:GCHeapFreeLimit=50 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/ -XX:ErrorFile=logs/hs_err_pid%p.log -XX:NativeMemoryTracking=summary -agentlib:jdwp=transport=dt_socket,server=y,address=9009,suspend=n -Dderby.stream.error.file=logs/derby.log -Dderby.infolog.append=true -Dderby.language.logStatementText=true -Dderby.locks.deadlockTrace=true -Dderby.locks.monitor=true -Dderby.storage.rowLocking=true -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=7900 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -ea -jar ROOT.war

● mvnコマンドで起動:

GitHubからEasyBuggy Bootをgit cloneして下さい。

$ git clone https://github.com/k-tamura/easybuggy4sb 
$ cd easybuggy4sb

その後、次のコマンドでビルドから、起動までが一気にできます。

$ mvn clean spring-boot:run

新しい機能を追加したり、ソースコードを変更して動作確認してみたい場合、このコマンドを実行すればビルドして、すぐに動作確認をすることができます。

● warファイルをサーブレットコンテナにデプロイして起動:

Tomcat以外のコンテナにもデプロイできます。ROOT.warをダウンロードして、PayaraやJettyなどにデプロイすれば、起動します。javaコマンドで起動したときと同様に、JVMオプションを指定することをお勧めします。

開発の方法

STS (Spring Tool Suite)を使用して、EasyBuggy Bootのソースコードを参照したり、開発、デバッグする方法についても載せておきます。STSはEclipseベースのIDEで、Springベースの アプリケーションの開発が簡単にできるようにカスタマイズされています。

  1. このページからSTSをダウンロードして下さい。
  2. GitHubからEasyBuggy Bootをgit cloneして下さい。
    $ git clone https://github.com/k-tamura/easybuggy4sb
    $ cd easybuggy4sb
    
  3. 以下のコマンドを実行します。このコマンドでSTSでの開発に必要なファイル(.projectファイルや.classpathファイル)が作成されます。また、依存するライブラリのソースコードも参照できます。
    $ mvn dependency:sources
    $ mvn eclipse:eclipse
    
  4. STSを起動します。
  5. パッケージエクスプローラからクローンしたプロジェクトをインポートします。「Existing Maven Projects」を選択して、「Next」をクリックして下さい。
    Screenshot-Import .png
    「Root Directory」にクローンしたプロジェクトへのパスを入力し、「Finish」をクリックします。
    Screenshot-Import Maven Projects .png
  6. パッケージエクスプローラのeasybuggy4sbプロジェクトを右クリックし、「Debug As」、「Spring Boot App」と選択すると、デバッグモードでEasyBuggy Bootが起動します。
    Screenshot-Spring - easybuggy4sb-src-main-java-org-t246osslab-easybuggy4sb-Easybuggy4sbApplication.java - Spring Tool Suite .png

ソースコードを修正すると、自動的にリロードされて、修正が反映されることも確認してみて下さい。

リモートデバッグする方法

リモートのEasyBuggy Bootをデバッグする場合は、次のデバッグ設定を追加することでデバッガーをアタッチできます。

  • Connection type: Standard (Socket Listen)
  • Host: localhost
  • Port: 9009

Screenshot-Debug Configurations

 ビルドの方法

以下のコマンドで、実行可能かつデプロイ可能なwarファイルを作成することができます。

$ mvn clean package

注意事項

OutOfMemoryError関連のリンク(特にネイティブメモリを操作するもの)をクリックすると、PCの動作が不安定になる可能性があります。CPUやメモリを制限したVM上で起動するなどしてから、自己責任でリンクをクリックして下さい。

Eclipseのショートカットが効かなくなったら

EclipseやSTSのショートカットが効かなくなったら、どのように対処すればいいでしょうか?ご存知では無い人のために、ここに記しておきます。

例えば、STSのインポートの編成(Ctrl+Shift+O)が効かなくなったとします(実際に私がそうだった…)。

そんなときは、Window > Preferences > General > keys で「Ctrl+Shift+O」で検索してみます。

1.png

ここに存在しなければ、もちろん機能しません。その場合は、「Restore Defaults」ボタンをクリックして元に戻しましょう。ここにあっても機能しない場合は、競合する別のコマンドが優先して機能してしまっています。なので、それらのコマンドに別のキーバインディングを割り当てるか、アンバインドします。

この変更を適用した後でもショートカットが効かない場合は、「Filters…」をクリックして、

2.png

「Filter uncategorized commands」などのチェックを外します。

3

こうすると、見えていなかった競合するキーバインディングが見つかるので、これも別のキーバインディングに変えましょう。

5

これでショートカットが機能するようになるはずです。

 

OpenIGのCaptureFilter利用時の注意点

OpenIG 2.1.0を利用しているシステムでCLOSE_WAITのコネクションが溜まって、応答が返らなくなるという現象があり、調査しました。

HTTPコネクションのリークの問題だろうと思い、外部システムにHTTPで通信しているClientHandlerというクラスのソースコードを見てみたところ、確かにコネクションを生成して、クローズしていません。その上、コネクションの最大数のデフォルトは64で、この値に達するとコネクションが生成できなくなり、応答が返らなくなるようでした…

/** Default maximum number of collections through HTTP client. */
private static final int DEFAULT_CONNECTIONS = 64;

ということで対策が必要です。ClientHandlerで生成してるコネクションなので、このクラスでクローズするのが適切かと思ったのですが、実際にやってみると、うまくいきません。どうもClientHandlerの後で呼ばれるFilterクラスでもコネクションを使いまわしているようで、ClientHandlerでクローズすると、Filterクラスで例外がスローされてしまいます。

さらに調べてみると、このコネクションをクローズしているのは、次の5つのFilterクラスであることが分かりました。

  • CaptureFilter
  • EntityExtractFilter
  • ExceptionFilter
  • HttpBasicAuthFilter
  • ReplaceFilter

したがって、ClientHandlerでコネクションを生成したら、これらのFilterクラスのいずれかを呼び出さないと、コネクションがリークするということになります。今回問題になっていた機能も、ClientHandlerを読んだ後に、これらのいずれも呼び出していませんでした。

この問題がなぜテスト環境では見つからなかったかというと、本番環境移行時にCaptureFilterを取り除いたことに理由があります。CaptureFilterはデバッグ目的でリクエストやレスポンスの中身を出力することができます。デバッグ時には便利なのですが、本番環境では性能面やセキュリティ面を考慮して、外すのが一般的です。このシステムでも本番環境移行時にCaptureFilterを外したところ、次の図のようにコネクションがリークしてしまったということです。

IGConnLeaks

そもそも、CaptureFilterはその名前と機能から判断すれば、ログ出力以外のことをすべきではないと考えるのが普通です(つまりCaptureFilterのバグと考えられます)。ガイドには、「Captures request and response messages for further analysis.」と書いてありますし。

ちなみにOpenIG 3.1.0から、CaptureFilterはDeprecatedになっており、代わりにCaptureDecoratorというクラスを使うことが推奨されているようです。おそらく、この問題は解決しているのではないかと思います。

TomcatのsafeToDelete.tmpの謎を追う

「TomcatのtempディレクトリにあるsafeToDelete.tmpというファイルは何ですか?」

こんな質問をされたので、少し調べてみました。

※大げさなタイトルですが、超小ネタです。

ぱっと手元にあるTomcatを確認したところ、確かに、tempディレクトリの下にはsafeToDelete.tmpという空のファイルができています。バージョン6.0でも7.0でも8.0でもこの空のファイルがあります。保存されているディレクトリ名とファイル名から判断すると、削除したところで問題が無いことは推測できるのですが、これは一体??

ということで、まずは”safeToDelete.tmp”でググってみました。が、イマイチそれらしい答えが見つからず。

まあ、Tomcatのガイドに書いてあるだろうと、今後は「safeToDelete.tmp site:tomcat.apache.org」とサイト内検索でググってみましたが、結果はゼロ。

こうなると、ソースコードを調べた方が速そうなので、「safeToDelete」でソースコード全体をgrep。すると、ヒットはしたのですが、dist.xmlに以下の1行があるだけ…

<touch file="${tomcat.dist}/temp/safeToDelete.tmp" />

dist.xmlはantでTomcatをビルドする際に読み込まれるファイルで、これをもとにantは空のファイル(safeToDelete.tmp)を作成(touch)しているだけです。作成しているものの、どこからも参照されていないこのファイルに何の意味があるのでしょうか。このファイルが作成されるようになった過去の経緯を知らないと、存在意義は分からなそうです。

ということで、いつからのこのファイルがあるのか調べてみると、Tomcat 5.0.28には入っていませんでした。Tomcat 5.5.36を調べてみると、bugzilla37035-safeToDelete.tmpというファイルがありました…あ、そゆこと…

ということで、bugzillaでid=37035を検索すると、ありました。
https://bz.apache.org/bugzilla/show_bug.cgi?id=37035

Windowsの解凍ツールWinZIPでTomcatのtar.zpファイルを解凍したときに、もともとあった空のtempディレクトリが消えてしまう、というバグ(?)でした…

WinZIPの問題であって、対策すべきではないのでは?対策の仕方も…

そして、次の疑問が。logsやworkなどの空ディレクトリはなぜ、この対策をしなかったのか?tempディレクトリはサーブレットの仕様で規定されているから?深追いするような問題では無いので、この辺りで調査は切り上げます。

EasyBuggy のトリセツ

EasyBuggyは、JavaのWebアプリケーションで起こりうる様々な問題を、非常に手軽に体験できるWebアプリケーションです。ここでいう問題とは、メモリリークやデッドロックなどの障害、SQLインジェクションやオープンリダイレクトなどの脆弱性、OutOfMemoryErrorなどのエラー、算術オーバーフロー、性能上の問題などいろいろなものが含まれます。

なぜそのようなものをつくったかというと、教育や実験に活用できると考えたからです。問題を再現させて事象を解析してみると、トラブルシューティングの方法やバグ修正の仕方を学ぶことができます。実践的に学習すると予想外な結果が出ることもあり、理由を調査して理解を深めることができます。そして、その経験があることで、実際に本番環境で問題が発生した時でも冷静に対応できるのではないかと考えます。

EasyBuggyの特徴

以下のような点にこだわって開発しました。

  • 簡単、手軽である
  • 多くの技術を使わず、基本的な技術のみを使う
  • IDE、ビルドツールと連携し、開発からデプロイまでが短時間にできる
  • サーブレットコンテナ、DB、LDAPなどを組み込み、インストールや初期設定が不要
  • 単純なパッケージ・クラス構成 (基本的に1機能 – 1サーブレットの関係)
  • デザインは最小限に (本当はこだわりたいんですが…)

スクリーンショット

以下はメインの画面で、ブラウザの言語設定によって日本語と英語が切り替えられるようになっています。見ての通り、いろいろなバグを確認できます。

main

バグのリンクをクリックすると、そのバグが確認できます。以下はOSコマンドインジェクションを確認できるページです。

math

java.lang.Mathを使用した数式を入力すると、計算結果が表示されるという単純な機能の中に、OSコマンドインジェクションの脆弱性があります。(i)マークで始まる説明の通り、特定の文字列を入力すると、致命的な問題が発生します。

起動方法

EasyBuggyを起動して、http://localhost:8080にアクセスすると、先ほどのメインページが表示されます。起動方法には次の3つがあります。

  • javaコマンドで起動
  • mvnコマンドで起動
  • warファイルをサーブレットコンテナにデプロイして起動

それぞれどのように使い分けるか説明します。

● javaコマンドで起動:

もっとも関単にEasyBuggyを起動する方法です。easybuggy.jarをダウンロードして、次のコマンドで起動します。

$ java -jar easybuggy.jar

この時、以下のようにJVMオプションを指定しておくと、問題が発生しやすく、またログを確認しやすくなります。

$ java -Xmx256m -XX:MaxPermSize=64m -XX:MaxDirectMemorySize=90m -XX:+UseSerialGC -Xloggc:logs/gc.log -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M -XX:GCTimeLimit=15 -XX:GCHeapFreeLimit=50 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/ -XX:ErrorFile=logs/hs_err_pid%p.log -XX:NativeMemoryTracking=summary -agentlib:jdwp=transport=dt_socket,server=y,address=9009,suspend=n -Dderby.stream.error.file=logs/derby.log -Dderby.infolog.append=true -Dderby.language.logStatementText=true -Dderby.locks.deadlockTrace=true -Dderby.locks.monitor=true -Dderby.storage.rowLocking=true -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=7900 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -jar easybuggy.jar

easybuggy.jarはPayara Microを組み込んでいるので、Tomcatなどのサーブレットコンテナが無くても、起動することができます。easybuggy.jarはTomcatを組み込んでいるので、サーブレットコンテナが無くても、起動することができます(バージョン1.3.0から変更しました)。

● mvnコマンドで起動:

次のコマンドでビルドから、起動までが一気にできます。

$ mvn clean install exec:exec

新しい機能を追加したり、ソースコードを変更して動作確認してみたい場合、このコマンドを実行すればビルドして、すぐに動作確認をすることができます。

mvnコマンドを実行する場合は、Payara Microではなく、組み込みのJettyサーバーが起動します。mvnコマンドを実行する場合も、組み込みのTomcatサーバーが起動します(バージョン1.3.0から変更しました)。

● warファイルをサーブレットコンテナにデプロイして起動:

Tomcat以外のコンテナにもデプロイできます。ROOT.warをダウンロードして、PayaraやJettyなどにデプロイすれば、起動します。easybuggy.jarを起動したときと同様にJVMオプションを指定することをお勧めします。

開発する方法

EasyBuggyはMavenのプロジェクトとして開発しているので、Eclipseで開発するためには、次のコマンドを実行します。

> mvn eclipse:eclipse

このコマンドを実行すると、Eclipseのプロジェクトに必要な .classpath や .project ファイルが作成されます。このプロジェクトをインポートすれば、Eclipseでソースコードを参照したり、改造したりすることができます。

デバッグする方法

Eclipseの場合は、次のデバッグ設定を追加することでデバッガーをアタッチすることができます。

  • Connection type: Standard (Socket Listen)
  • Host: localhost
  • Port: 9009

Screenshot-Debug Configurations

注意事項

OutOfMemoryError関連のリンク(特にネイティブメモリを操作するもの)をクリックすると、PCの動作が不安定になる可能性があります。CPUやメモリを制限したVM上で起動するなどしてから、自己責任でリンクをクリックして下さい。

既知の問題と対策の方法

Javaやサーブレットコンテナのバージョンにも依存しますが、Windows上での動作で問題が出る場合があります。

● メインページにアクセスすると、内部サーバーエラーが発生する(v 1.3.0より前のバージョンでの問題):

easybuggy.jarで起動した場合、Javaのバージョンによっては、メインページにアクセスすると次のエラーが発生する場合があります。

HTTP Status 500 – Internal Server Error

org.apache.jasper.JasperException: PWC6345: There is an error in invoking javac.  A full JDK (not just JRE) is required

この場合は、JDK/binを環境変数「path」に追加し、JRE/bin/javaを実行して下さい。

> set path=%path%;C:\Program Files\Java\jdk1.8.0_121\bin
> "C:\Program Files\Java\jdk1.8.0_121\jre\bin\java" -jar easybuggy.jar

● 「Failed to delete ○○.jar」のエラーが出力されて起動できない:

mvnコマンドで起動した場合、JavaのバージョンによってはCtrl+CでもEasyBuggyのプロセスが停止しない場合があります。この場合は、起動時に次のようなエラーが出力されます。

> mvn clean install exec:exec
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building easybuggy 1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ easybuggy ---
[INFO] Deleting C:\Users\ktamura\git\easybuggy\target
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.681 s
[INFO] Finished at: 2017-03-14T09:45:18+09:00
[INFO] Final Memory: 7M/155M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:2.5:clean (default-clean) on project easybuggy: Failed to clean project: Failed to delete C:\easybuggy\target\easybuggy-1-SNAPSHOT\WEB-INF\lib\xom-1.2.5.jar -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

この場合は、「JVMクラッシュ」や「コードインジェクション」のページにアクセスして、EasyBuggyのプロセスを強制的に停止させてしまうのが、手っ取り早いです 🙂 。「JVMクラッシュ」で停止させる場合は、logsディレクトリにコアダンプが出力されるので、増えてきたら削除して下さい。

V4エージェントを使うべきか

2016年の4月にバージョン4.0.0のWebエージェントがリリースされました。以前のバージョンにあったいくつかの問題に対応するため、一から実装し直しています。

リリースノートにかかれている主な新機能は以下の通りです:

  • IISのマルチサイト構成のサポート
    IISエージェントV4は、IISのマルチサイト構成に対応し、サイト毎に独自のエージェント設定が可能になっています。
  • Apacheのバーチャルホストのサポート
    ApacheエージェントV4は、Apache Webサーバー上の複数のバーチャルホストにエージェントをインストールすることができ、仮想ホスト毎に独自のエージェントの設定が可能です。
  • 権限の自動付与
    Webサーバーの実行ユーザーが書き込む必要のあるフォルダに、権限を自動的に付与することができます。
  • カスタマイズ可能な暗号化設定
    エージェントとOpenAM間の通信の暗号化の方式を詳細に設定できます。

この他に地味にうれしいのが、Javaのインストールが必要無くなったということです。以前のバージョンは、なぜかエージェントのセットアップツールがJavaで実装されていて、それだけのためのJavaをインストールしなければいけなかったのですが、これが不要になっています。

また、–s オプションでサイレントインストールがより簡単にできるようになっています。

$ ./agentadmin --acceptLicence --changeOwner --s \
  /etc/httpd/conf/httpd.conf \
  http://openam.example.co.jp:8080/openam \
  http://app.example.co.jp:80/ \
  webagent1 \
  pwd.txt

・・・

Installation complete.

ということで、今すぐアップグレードしてバージョン4.0.0のWebエージェントを使うべきか、というとまだ現時点ではお勧めはできません(ForgeRock社のサブスクリプションを購入していない場合は)。実際に動かしてみたのですが、いくつかの(致命的とも言えそうな)問題が見つかりました。JIRAを見る限り、バグも多く上がっています。動作が安定するまでまだ時間がかかるのかなぁと思っています。

 

(…とまで書いて、このブログ記事を公開するのを忘れていました…そして数ヶ月後…)2016年の12月にWebエージェント 4.1.0がリリースされました。

Webエージェント 4.1.0リリース

新しい4.1.0はどのような変更があったかというと、ここに書かれている通りです。いくつかのエンハンスがされていますが、それほど大きなものではないように思います。ただし、このバージョンで修正したバグは、リリースノートに載っているだけでも78件あります。これらの中には「メモリリーク」、「リダイレクトループ」、「クラッシュ」などの用語が見られるので、やはり4.0.0は本番環境で使用するのは避けるべきという判断は正しかったと思います。4.1.0になり、バグが大量に修正され動作は大分安定するようになったと予想しますが、まだ3.3.xなどのバージョンの方が安定しているかもしれません。