jenkinsによってデプロイされたWEBアプリが
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException
を吐き出してあれこれやったので一言。
残念ながらログをどっかやってしまったが、
「0ms前にパケットは送ることに成功したけど、返答が無い。」
みたいなスタックトレースが出ていた。
TOMCATにデプロイされているリソースファイルがどうやらおかしい。
リソースフォルダにローカル向けの開発用リソース
が乗っけられている。
それを読み込んだせいで、
本来はDBサーバを参照しているはずが、
存在しないlocalhostのDBを参照しているのだから返答が無いのは当たり前である。
mavenのゴールの設定がおかしいのかな？
と思ったが違う。
結局、
pom.xmlのリソースディレクトリの記述順によるものだった。
/src/main/resources/resource.xml(local用)
/src/product/resources/resource.xml(product用)
が存在し、
profile「product」に記述したリソースディレクトリの記述はこうなっていた。
<profile>
<id>product</id>
・
・
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>src/product/resources</directory>
</resource>
</resources>
・
・
</profile>
クリーンするとローカル環境では問題なくlocal用リソースが使われていたこともあり、
clean package -P productを行えば、product用リソースが使われると思っていた。
記述を以下のように変えた。ひっくり返しただけ。
<profile>
<id>product</id>
・
・
<resources>
<resource>
<directory>src/product/resources</directory>
</resource>
<resource>
<directory>src/main/resources</directory>
</resource>
</resources>
・
・
</profile>
にしたら望みどおりのパッケージングになった。
この記事を書いている途中、懐疑的になって確認してみたが、やっぱりこうすると直る。
同名ファイルが存在した場合のpom.xmlの解析とMavenの挙動を細かく気にしてなかったので結構詰まった。
tomcatがビルドしたてのwarをデプロイ出来てないだけか？とか、
コネクタのバージョンが間違ってるのか？とか、
そもそもリソースファイル自体に問題があるのか？とか、
DBサーバーの権限・IP関係が間違ってるのか？とか、
色々模索した。
直接的な原因はDBにあると思ったら勘違い。
しかし・・根本的な解決になってない感が半端無い・・・
ふと思いついてfish(フレンドリーうんたらかんたらシェル)を入れようと思ったら
色々あったのでメモ。
調べるうちに複数の問題点が見つかった。
その内容は大きく2つ。
・fishインストール出来ない←macports（portコマンド）が使えないのが原因
・macports（portコマンド）が使えない←makeが使えないのが原因
まず当たったのが根本原因であるmakeが使えないというトラブルだが、
これはXcodeをインストールすることで解決できる。
手順としては、
appleのデベロッパーコネクションに登録する。
↓
ログイン後、Mac Dev Centerに行く(http://developer.apple.com/devcenter/mac/index.action)
↓
Xcode3 for snow leopard欄のdmgをダウンロード。ログインしないとXcode3の項目すら出てこない模様。
↓
インストール。
容量でかい。いい方法が見つからんかったのでしょうがない。
ちゃんとmakeは使えるようになった。
---余談---
ひょっとすると、インストール途中でitunesを終了させるように警告が出るかもしれない。
終了させても進まない時は、以下の方法を試す。
アプリケーション→ユーティリティ→アクティビティモニタを起動
一覧の中のiTunes helperのプロセスを終了させる。
するとちゃんと終了されてうまくいくはず。
---------
次にmacports
http://www.macports.org/install.php
の文中の「downloads」から、一覧ページに飛べる。
飛んだ先が↓
https://distfiles.macports.org/MacPorts/
ここの雪豹用dmgをダウンロードし、インストール。
終了したら
>sudo port selfupdate
で更新。
やっとfishのインストール。
>sudo port install fish
でようやくfishのインストール開始。
終了。
インストールがひたすら長かった・・・
依存関係が大変多い。
開発しつつインストールしたけど、普通に1・2時間、いやもっとかかった。
RSA暗号を使用して鍵交換方式によるsshノンパスログインを設定する。
クライアント、サーバのどちらかで
>ssh-keygen -t rsa
コマンドを発行すると、
Generating public/private rsa key pair.
Enter file in which to save the key (/home/anonymous/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/anonymous/.ssh/id_rsa.
Your public key has been saved in /home/anonymous/.ssh/id_rsa.pub.
The key fingerprint is:
38:9c:ad:96:c5:41:cf:b2:d1:ba:39:90:a6:93:b2:70 anonymous@machine
以上のような表記が出る。
出力先はデフォルトのままで概ね問題ないが、
上書きしてしまう恐れが有るため、予め.sshの中身を確認しておこう。
既に鍵があったら、システム管理者の人に聞いてみよう。
パスフレーズは無しで生成。
つまりエンターを3回くらい押せばOK。
すると.ssh下にid_rsa,id_rsa.pubが生成される。
.pubが付いている方が公開鍵、もう一方が秘密鍵である。
鍵を生成したら、クライアント側に秘密鍵、サーバー側に公開鍵を設置する。
のだが、接続したいアカウントによって入れるディレクトリが変わる。
クライアントのユーザー「client」が、
サーバーのユーザー「server」としてログインしたい場合、
クライアントの/home/client/.ssh下に秘密鍵を設置する。
サーバー側は複数のクライアントからの認証を受け付けるため、
公開鍵をポンと置かない。
サーバーの/home/server/.ssh下に、「authorized_keys」という名のファイルを作り、
公開鍵の中身をコピペする。
一つの公開鍵は、改行なしで示す必要があるので注意すること。
当然だが、途中で改行があるとうまくいかない。
あとは各ファイル・ディレクトリのアクセス権限及び所有者を変える。
双方の「.ssh」は
chmodコマンドで「700」を設定する。「700」だぞ。
chmod 700 /home/client/.ssh
ユーザー、グループも変更。
chownコマンドをそれぞれ実行し、「client」,「server」に設定。
chown client /home/client/.ssh
chown server /home/server/.ssh
みたいな感じ。
グループを一致させる必要があるかは未調査。
おそらくオーナーと一緒でよかろう。
クライアントのid_rsaと
サーバーのauthorized_keys
のアクセス権限は「600」にする。
「.ssh」は「700」、
鍵自体は「600」。
何という罠。
オーナー、グループもそれぞれのアカウントに属させる。
これでいけるはず、以下動作確認例
自分は「anonymous」アカウントを持ち、
クライアントの「client」アカウントが、「server」アカウントとしてサーバーにログインできるか試す場合。
sudo -s（rootになる）
su - client（clientになる）
ssh -i /home/client/.ssh/id_rsa server@xxx.xxx.xxx.xxx（-iは鍵の指定を行う際に用いる。id_rsaを使って、xxx.xxx.xxx.xxxにserverとしてssh接続を試みる）
今回は自分が「client」アカウントではないので、アカウントを切り替える必要があります。注意。
パスワード要求されなかったら成功。
おめっとさん。
クライアント、サーバのどちらかで
>ssh-keygen -t rsa
コマンドを発行すると、
Generating public/private rsa key pair.
Enter file in which to save the key (/home/anonymous/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/anonymous/.ssh/id_rsa.
Your public key has been saved in /home/anonymous/.ssh/id_rsa.pub.
The key fingerprint is:
38:9c:ad:96:c5:41:cf:b2:d1:ba:39:90:a6:93:b2:70 anonymous@machine
以上のような表記が出る。
出力先はデフォルトのままで概ね問題ないが、
上書きしてしまう恐れが有るため、予め.sshの中身を確認しておこう。
既に鍵があったら、システム管理者の人に聞いてみよう。
パスフレーズは無しで生成。
つまりエンターを3回くらい押せばOK。
すると.ssh下にid_rsa,id_rsa.pubが生成される。
.pubが付いている方が公開鍵、もう一方が秘密鍵である。
鍵を生成したら、クライアント側に秘密鍵、サーバー側に公開鍵を設置する。
のだが、接続したいアカウントによって入れるディレクトリが変わる。
クライアントのユーザー「client」が、
サーバーのユーザー「server」としてログインしたい場合、
クライアントの/home/client/.ssh下に秘密鍵を設置する。
サーバー側は複数のクライアントからの認証を受け付けるため、
公開鍵をポンと置かない。
サーバーの/home/server/.ssh下に、「authorized_keys」という名のファイルを作り、
公開鍵の中身をコピペする。
一つの公開鍵は、改行なしで示す必要があるので注意すること。
当然だが、途中で改行があるとうまくいかない。
あとは各ファイル・ディレクトリのアクセス権限及び所有者を変える。
双方の「.ssh」は
chmodコマンドで「700」を設定する。「700」だぞ。
chmod 700 /home/client/.ssh
ユーザー、グループも変更。
chownコマンドをそれぞれ実行し、「client」,「server」に設定。
chown client /home/client/.ssh
chown server /home/server/.ssh
みたいな感じ。
グループを一致させる必要があるかは未調査。
おそらくオーナーと一緒でよかろう。
クライアントのid_rsaと
サーバーのauthorized_keys
のアクセス権限は「600」にする。
「.ssh」は「700」、
鍵自体は「600」。
何という罠。
オーナー、グループもそれぞれのアカウントに属させる。
これでいけるはず、以下動作確認例
自分は「anonymous」アカウントを持ち、
クライアントの「client」アカウントが、「server」アカウントとしてサーバーにログインできるか試す場合。
sudo -s（rootになる）
su - client（clientになる）
ssh -i /home/client/.ssh/id_rsa server@xxx.xxx.xxx.xxx（-iは鍵の指定を行う際に用いる。id_rsaを使って、xxx.xxx.xxx.xxxにserverとしてssh接続を試みる）
今回は自分が「client」アカウントではないので、アカウントを切り替える必要があります。注意。
パスワード要求されなかったら成功。
おめっとさん。