home ホーム search 検索 -  login ログイン  | help ヘルプ

find 検索

261 - 270 / 1320    [|<]  [|<]  [<]  21  22  23  24  25  26  27  28  29  30   [>]  [>|][>|]
タイトル/名前 更新者 更新日
技術/Security/PKI,SSL,TLS/メモ02_OpenSSLとRSA msakamoto-sf 2013-07-27 18:52:23
技術/Security/PKI,SSL,TLS/メモ01_拡張子の迷宮(pem,der,crt,cer,csr,...) msakamoto-sf 2013-07-27 18:52:15
技術/UNIX/od, hexdump, xxd : 16進数 or 2進数ダンプ msakamoto-sf 2013-07-27 18:47:09
日記/2013/07/27/調べ物 : Node.js msakamoto-sf 2013-07-27 17:49:41
日記/2013/07/27/調べ物:Javaで書かれたWikiエンジン msakamoto-sf 2013-07-27 17:44:01
技術/OSSライセンス/"Stack Overflow"上のソースコードスニペット msakamoto-sf 2013-07-27 11:15:02
技術/UNIX/hostname msakamoto-sf 2013-07-27 10:40:13
Java/ClassLoaderの分割 : kamranzafar/JCL msakamoto-sf 2013-07-21 11:40:58
Groovy/Gradle/Eclipseとの連携/SpringのEclipsePlugin使用メモ msakamoto-sf 2013-07-15 12:07:25
Groovy/Maven/Eclipse + GGTS使用時のメモ msakamoto-sf 2013-07-15 11:52:51
ソート項目 / ソート順     1ページ 件ずつ表示

技術/Security/PKI,SSL,TLS/メモ02_OpenSSLとRSA  

所有者: msakamoto-sf    作成日: 2012-02-05 19:52:08
カテゴリ: SSL/TLS セキュリティ 

OpenSSLでRSA秘密鍵・公開鍵を作成し、署名したり署名を検証したりしてみました。

> openssl version
OpenSSL 0.9.8h 28 May 2008

古い・・・。大分前に以下のURLからインストールしたOpenSSL使ってます。


genrsaコマンド

genrsaコマンドでRSAに使う秘密鍵を生成する。

> openssl genrsa
Loading 'screen' into random state - done
Generating RSA private key, 512 bit long modulus
........++++++++++++
..++++++++++++
unable to write 'random state'
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIIBOwIBAAJBAOCBzlG9MrPdUXWgGIMN8LooK4UAiT28aEZ69flortYuzzwXb47q
WTeQkrTVnbJzopYRRLDswWbfNukAA9hwSbcCAwEAAQJAGpcFKqUv5iGmTjoh7ROv
mTy8usnvd0JjT0Ws8Fc3reIwlrNX4ahsL9GqgFY7YMbZIeaXqAagXopZvpg5fuwo
cQIhAPXu0MKxH4nZYTBDeF4Dx2Iec8JcD8HOly7hZpWnWY29AiEA6bJ28MZMsfDT
BtIsP4RiLddV9Fws/2yoEC2HWpAm6oMCIQCoRPuvipNitUqLRE7SPNGqL93SiTz6
xUip+e0/zh43HQIgHT9Sl2uZ6aMkJfRjyUc+KlKK1Vw73XOxzOSFzhXAaRUCIQDy
lMdy/X4wxbDD6wfA0RCgqGGYiGooblFJucQREIhATA==
-----END RSA PRIVATE KEY-----

ビット数を指定する場合は最後に引数で指定:

> openssl genrsa 1024

ファイルに出力する:

> openssl genrsa -out testrsa01_sec.pem

AES256(CBC)で暗号化する:

> openssl genrsa -aes256 -out testrsa01_sec_aes256.pem
Loading 'screen' into random state - done
Generating RSA private key, 512 bit long modulus
.......++++++++++++
..++++++++++++
unable to write 'random state'
e is 65537 (0x10001)
Enter pass phrase for testrsa01_sec_aes256.pem:(パスフレーズ入力)
Verifying - Enter pass phrase for testrsa01_sec_aes256.pem:(パスフレーズ入力)

暗号化すると"Proc-Type"と"DEK-Info"が追加されました:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,189...

c7f5hYcyY6c95ay73R8udIaPOBWGmukmYI46glvFOtUA2pnS2LYpiIAuvrk9obZP
...
-----END RSA PRIVATE KEY-----

rsaコマンド

RSAの暗号鍵から公開鍵を生成するのに使う。署名や暗号化処理にはrsautlコマンドを使う。

暗号化していない秘密鍵から:

> openssl rsa -pubout < testrsa01_sec.pem > testrsa01_pub.pem
writing RSA key

暗号化した秘密鍵から:

> openssl rsa -pubout < testrsa01_sec_aes256.pem > testrsa01_pub_aes256.pem
Enter pass phrase:
writing RSA key

デフォルトの出力形式はPEM形式となっている。

秘密鍵の暗号化を解除する:

> openssl rsa < testrsa01_sec_aes256.pem > testrsa01_sec_aes256_nopass.pem

暗号化されていない秘密鍵を暗号化する:

 > openssl rsa -aes256 < testrsa01_sec.pem
writing RSA key
Enter PEM pass phrase:(パスフレーズ入力)
Verifying - Enter PEM pass phrase:(パスフレーズ入力)
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,6EDEE202C1D95242C7541CB66448CE74

vUPpCqLnGrrardKlcfRZVCIgRBw1bCnxchozP1A19Zr0bt9IhvmkYch3Cec7xSbO
jwMGF/ACeYtVHCdppuEcf6wKlpSiZivyfy04fvDZ4KWZltkNN6YsKtbUEJ0A7uwJ
iqUEccD6/sZelxylDzjkPsxoXO7xVWk/rW8EUFcI3l/Zf6uk9L3E1CRR3M8DUY1U
zqVfCWFrLo6sP6xJ6cMIh6w8b6EPMS/3ITMdF3ek+x77Cip4KZgAX0CcmdZpkjwy
EmSf9LWyAbDOVIjqJTAeOAG+JJgjZ8WDueCLbSzgBTUBFnA4qVwqTboMcSxYjgTF
ZI2vefASaV32lMMqE9Gv6HdibTlprqdgDVdy/GoPpxsShMKsOQKKgY2aumZb1pfL
13Meo2yhuGxpQm1Zim3+vjU5AJr86M8lBzzomiESwGQ=
-----END RSA PRIVATE KEY-----

rsautlコマンド

署名や暗号化処理を行う。暗号化された秘密鍵を使っている場合、秘密鍵を使う"-sign", "-encrypt"で暗号化を解くためのパスフレーズの入力を求められる。"rsaコマンド"の項で作成した testrsa01_sec.pem, testrsa01_pub.pem を使って以下のファイルに対して練習してみる。
plain.txt:

abcdefghijklmn

なお、"-keyform"を指定しない場合の鍵ファイルのフォーマットはPEM形式。

署名と検証

署名:"-sign" + "-inkey 秘密鍵ファイル"

> openssl rsautl -sign -in plain.txt -inkey testrsa01_sec.pem -out sign.bin
Loading 'screen' into random state - done

sign.binはバイナリファイル。

秘密鍵による署名の検証:"-verify" + "-inkey 秘密鍵ファイル"

> openssl rsautl -verify -in sign.bin -inkey testrsa01_sec.pem
Loading 'screen' into random state - done
abcdefghijklmn

※元のファイル内容についてファイルに保存したい場合は "-out 出力ファイル名" を追加。

公開鍵による署名の検証:"-verify" + "-inkey 公開鍵ファイル" + "-pubin"

> openssl rsautl -verify -in sign.bin -inkey testrsa01_pub.pem -pubin
Loading 'screen' into random state - done
abcdefghijklmn

公開鍵ファイルを"-inkey"で指定しつつ、"-pubin"を指定しない場合、"-inkey"が秘密鍵として扱われエラーとなる。

> openssl rsautl -verify -in sign.bin -inkey testrsa01_pub.pem
Loading 'screen' into random state - done
unable to load Private Key

暗号化と復号化

公開鍵で暗号化:"-encrypt" + "-inkey 公開鍵ファイル" + "-pubin"

> openssl rsautl -encrypt -in plain.txt -inkey testrsa01_pub.pem -pubin -out plain_enc.txt

暗号化されたデータはバイナリ形式。"-pubin"を指定しない場合は秘密鍵として扱われエラーとなる。

秘密鍵で暗号化:"-encrypt" + "-inkey 秘密鍵ファイル"

> openssl rsautl -encrypt -in plain.txt -inkey testrsa01_sec.pem -out plain_enc2.txt

秘密鍵でも暗号化できるが、復号化には公開鍵ではなく秘密鍵が必要となる。

秘密鍵で復号化:"-decrypt" + "-inkey 秘密鍵ファイル"

> openssl rsautl -decrypt -in plain_enc.txt -inkey testrsa01_sec.pem
Loading 'screen' into random state - done
abcdefghijklmn


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-27 18:52:23
md5:ade9b4b26593ac1648a4455cf6ffcada
sha1:c9224e22723bb2114b52e3b39da665665133eeee

技術/Security/PKI,SSL,TLS/メモ01_拡張子の迷宮(pem,der,crt,cer,csr,...)  

所有者: msakamoto-sf    作成日: 2012-02-05 18:34:17
カテゴリ: SSL/TLS セキュリティ 

OpenSSLやPKI周りを調べていると、拡張子が色々出てきて混乱したので整理しました。
特にX509証明書関連については、以下のWikiページを参考にしています。

頻出拡張子の整理

.pem(PEM, Privacy Enhanced Mail)

Base64符号化を使ったデータフォーマット。データのenvelopeとしてのフォーマットであり、データの中身は特に問わない。そのため証明書や鍵データ等幅広く使われている。OpenSSLでもサポートされており、様々なオブジェクトデータで"-inform", "-outform"オプションに指定可能。

元々E-Mailの暗号化や認証システムとしてRFC 1421 - 1424で提案されており、フォーマットはその中に包含されていた。フォーマットについては広く使われるようになったが、暗号化や認証システムについてはPKIに取って代わられたようだ。

.der(DER, Distinguished Encoding Rules)

バイナリ形式のデータ形式で、OpenSSLでもサポートされている。
元を辿ればASN.1 (Abstract Syntax Notation One) という抽象構文を表現するためのフォーマットの一つ。ASN.1自体はあくまでも抽象構文を表現する表記法(Notation)であり、データ構造の定義を担う。これを実際のバイナリフォーマットとして表現するためのフォーマットの一つがDERであり、他にもBERやCERなどあり、この話題や文脈で"~ER"ときたらほぼ"Encoding Rules"と考えてよいだろう。
乱暴にまとめるとASN.1はC言語の文法を表現するBNF記法に相当し、BER/DER/CERは文法を解析してアセンブラに変換するコンパイラに相当すると考えてよい。

.crt, .cer
X509証明書を格納したファイル全般の拡張子。ファイルフォーマットとは関連付いていない。そのため、拡張子が.crtであってもPEM形式なのかDER形式なのかは、内容を確認しないと判断できない。
.csr(Certificate Signing Request)

CA(認証局)に提出する証明書要求データ。ファイルフォーマットと関連付いておらず、PEM形式なのかDER形式なのかは内容を確認しないと判断できない。

.p7b, .p7c
PKCS#7 形式の署名されたデータ
.p12
PKCS#12 形式の証明書。秘密鍵が格納されている場合もある。
.pfx
Microsoftによるデータフォーマット。いくつか問題点が指摘され、改良版としてPKCS#12が策定されたらしい。

PEM形式とDER形式の見分け方

X509証明書を保存したファイルの場合、

-----BEGIN CERTIFICATE-----

で始まり、

-----END CERTIFICATE-----

で終わるテキストファイルであればPEM形式とみてほぼ間違いない。

テキスト形式ではなくバイナリデータであればDER形式の可能性が高いが、X509そのままではなく、PKCS#7形式の可能性もある。

X509そのままの例:

> openssl asn1parse -inform DER < veri_ie_der.cer
   0:d=0  hl=4 l=1577 cons: SEQUENCE
   4:d=1  hl=4 l=1297 cons: SEQUENCE
   8:d=2  hl=2 l=   3 cons: cont [ 0 ]
  10:d=3  hl=2 l=   1 prim: INTEGER           :02
  13:d=2  hl=2 l=  16 prim: INTEGER           :641BE820CE020813F32D4D2D95D67E67
  31:d=2  hl=2 l=  13 cons: SEQUENCE
  33:d=3  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
  44:d=3  hl=2 l=   0 prim: NULL
  46:d=2  hl=3 l= 202 cons: SEQUENCE
  49:d=3  hl=2 l=  11 cons: SET
  51:d=4  hl=2 l=   9 cons: SEQUENCE
...

PKCS#7形式の例:

> openssl asn1parse -inform DER < C:\Users\FengJing\Desktop\veri_pkcs7.p7b
   0:d=0  hl=4 l=2863 cons: SEQUENCE
   4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
                                               ^^^^^^^^^^^^^^^^^
  15:d=1  hl=4 l=2848 cons: cont [ 0 ]
...

ブラウザがエクスポート可能なファイル形式

実験としてIE9とFirefox9で "VeriSign Class 3 International Server CA - G3" という中間証明書をエクスポートしてみる。

まずIE9の「インターネットオプション」メニュー→「コンテンツ」タブ→「証明書」ボタン→「中間証明機関」タブで "VeriSign Class 3 International Server CA - G3" を選択、「詳細」タブで「ファイルにコピー」ボタンをクリックすると「証明書のエクスポート ウィザード」が開始される。
ウィザードの途中でエクスポートファイルの形式を選択できる。IE9で今回の証明書の場合はDER, PEM(="Base 64 encoded X.509"), PKCS#7 が選択できる。

ここでは"Base 64 encoded X.509"を選択し適当なファイル名で保存する。IE9の場合、デフォルトの拡張子は".cer"として保存された。

続いてFirefox9の「Tools」メニュー→「Options」メニュー→「Advanced」タブ→「View Certificates」ボタン→「Authorities」タブで "VeriSign Class 3 International Server CA - G3" を選択、「Export」ボタンをクリックすると保存ダイアログが表示される。

ここでは "X.509 Certificate (PEM)" 形式で保存する。Firefox9の場合、デフォルトの拡張子は".crt"として保存された。

IE9, Firefox9のそれぞれでPEM形式で保存したが、内容を確認すると全く同一の内容であることが確認される。
またFirefox9でエクスポートするときに "X.509 Certificate with chain (PEM)" 形式で保存すると、以下のように上位の認証局("VeriSign Class 3 Public Primary Certification Authority - G5")の証明書がPEM形式で追加されている。

-----BEGIN CERTIFICATE-----
MIIGKTCCBRGgAwIBAgIQZBvoIM4CCBPzLU0tldZ+ZzANBgkqhkiG9w0BAQUFADCB
(... "VeriSign Class 3 International Server CA - G3" の証明書 ...)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB
... ("VeriSign Class 3 Public Primary Certification Authority - G5" の証明書) ...
-----END CERTIFICATE-----

続いてIE9で上と同じ証明書を"veri_ie_der.cer"という名前でDER形式で保存し、opensslコマンドでテキスト形式に変換してみる。

> openssl x509 -inform DER -in veri_ie_der.cer -text > veri_ie_der.txt

更にPEM形式で保存したいファイルについても同様にテキスト形式で保存してみる。

> openssl x509 -inform PEM -in C:\Users\FengJing\Desktop\veri_ie_pem.cer -text > veri_ie_pem.txt

当然であるが、2つのファイルの内容は完全に一致している。またテキスト形式では末尾にPEM形式でのデータが記載されている。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-27 18:52:15
md5:637e2ec55307ad6e3e72e763aabdc71d
sha1:56842e0ebecbde836aa1692f573974ac2cfc4992

技術/UNIX/od, hexdump, xxd : 16進数 or 2進数ダンプ  

所有者: msakamoto-sf    作成日: 2013-07-27 18:46:41
カテゴリ: Linux UNIX 

使うたびにググってるので、いい加減、よく使うパターンについてメモ。
16進数(od, hexdump, xxd)と2進数(xxd)ダンプ出力の、よく使うコマンド例のまとめ。
(unix上でのバイナリファイルの編集については 技術/vim/メモ6, バイナリデータの編集 とか参照。)

od

-v : 直前と同じ内容を持つ行も表示する。事実上、必須。
-Ax : 基数を16進数に。
-t :
  GNU od : -tx1z : 1バイトずつ16進数で、対応する文字を行末にまとめて表示。
  BSD, Solaris : -tx1c : 1バイトずつ16進数で、対応する文字を次の行に表示。
$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | od -Ax -tx1z
000000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70  >abcdefghijklmnop<
*
000020 71 72 73 74 75 0a                                >qrstu.<
000026

$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | od -Ax -tx1z -v
000000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70  >abcdefghijklmnop<
000010 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70  >abcdefghijklmnop<
000020 71 72 73 74 75 0a                                >qrstu.<
000026

$ echo "abcdefghijklmnopqrstu" | od -v -Ax -tx1c
000000  61  62  63  64  65  66  67  68  69  6a  6b  6c  6d  6e  6f  70
         a   b   c   d   e   f   g   h   i   j   k   l   m   n   o   p
000010  71  72  73  74  75  0a
         q   r   s   t   u  \n
000016

hexdump

from http://linuxjm.sourceforge.jp/html/util-linux/man1/hexdump.1.html :

-C : 標準的な 16進数 + ASCII での表示。 
-v : odの"-v"と似た機能。事実上、必須。
$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | hexdump -C
00000000  61 62 63 64 65 66 67 68  69 6a 6b 6c 6d 6e 6f 70  |abcdefghijklmnop|
*
00000020  71 72 73 74 75 0a                                 |qrstu.|
00000026

$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | hexdump -C -v
00000000  61 62 63 64 65 66 67 68  69 6a 6b 6c 6d 6e 6f 70  |abcdefghijklmnop|
00000010  61 62 63 64 65 66 67 68  69 6a 6b 6c 6d 6e 6f 70  |abcdefghijklmnop|
00000020  71 72 73 74 75 0a                                 |qrstu.|
00000026

xxd

-g N : Nバイトごとにグルーピング。1バイトずつ見たいなら "-g 1"
-b : 2進数表示
$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | xxd -g 1
0000000: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70  abcdefghijklmnop
0000010: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70  abcdefghijklmnop
0000020: 71 72 73 74 75 0a                                qrstu.

$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | xxd -g 2
0000000: 6162 6364 6566 6768 696a 6b6c 6d6e 6f70  abcdefghijklmnop
0000010: 6162 6364 6566 6768 696a 6b6c 6d6e 6f70  abcdefghijklmnop
0000020: 7172 7374 750a                           qrstu.

$ echo "abcdefghijklmnopabcdefghijklmnopqrstu" | xxd -g 1 -b
0000000: 01100001 01100010 01100011 01100100 01100101 01100110  abcdef
0000006: 01100111 01101000 01101001 01101010 01101011 01101100  ghijkl
000000c: 01101101 01101110 01101111 01110000 01100001 01100010  mnopab
0000012: 01100011 01100100 01100101 01100110 01100111 01101000  cdefgh
0000018: 01101001 01101010 01101011 01101100 01101101 01101110  ijklmn
000001e: 01101111 01110000 01110001 01110010 01110011 01110100  opqrst
0000024: 01110101 00001010                                      u.

参考:



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-27 18:47:09
md5:8069e48a8700371199182db924d7b8e1
sha1:8a011b14e1174cb8952effa671e9053d66053c3a

日記/2013/07/27/調べ物 : Node.js  

所有者: msakamoto-sf    作成日: 2013-07-27 17:45:02
カテゴリ: Node.js 

いい加減勉強しないとヤバイかなぁ・・・

  • GREEが悩むNode.jsの問題を考えるヒント - ぼちぼち日記

WindowsへのNode.jsのインストール、というか"nvm"のインストール:

・・・なんでPythonが必要なのか?


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-27 17:49:41
md5:70d083597b8f72303ef3a0ecbe7d6dd0
sha1:b3f2ce3399254fbda3437d04c0230f073941f48a

日記/2013/07/27/調べ物:Javaで書かれたWikiエンジン  

所有者: msakamoto-sf    作成日: 2013-07-27 17:39:47
カテゴリ: Java 

会社内でのみ利用する業務アプリケーションでLGPL, EPLは使えるか?
→多分・・・大丈夫な気がするんだが・・・。
ライブラリ自体を変更しない限りは、そのライブラリとリンクしたソフトウェアのソースコードについては公開義務は生じない、という認識。仮にその認識が間違っていたとしても、社内でのみdeployし、利用者も社内のみで、利用者=社員から求められればソースコードは開示出来る状況であればGPLにすら違反していないのでは?

バイナリだけ配布する場合が問題となるか。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-27 17:44:01
md5:1bfd68ca0be45e29c42513ee06a843f9
sha1:5aef010e751c91bdaa58cf07e02f22a2228e7c6c

技術/OSSライセンス/"Stack Overflow"上のソースコードスニペット  

所有者: msakamoto-sf    作成日: 2013-07-27 10:41:17
カテゴリ: License 

"Stack Overflow" ( http://stackoverflow.com/ ) は最近(2011-2013)、特にお世話になることが多いITエンジニア向けのQAサイトで、質問や回答の中にサンプルコードが記載されていることも多々あります。

これらのソースコードスニペットのライセンスってどうなってるの?というところですが、既にStack Overflowでも話題になっていたようです。

結論から言うと、"Stack Overflow"のlegalページで "Creative Commons Attribution Share Alike license" が適用されるということが書いてありました。

SO上に投稿されたコンテンツは上記のCCライセンスが適用されるので、使う側としては大変助かります。
投稿する側として気をつけなければならないのは、プロプライエタリなソースコードを抜粋などで投稿してしまうとライセンスを侵害してしまうことになりかねないので、非常に注意が必要というところでしょうか。

ただ、自分もソフトウェアやコンテンツに関する著作権・ライセンスの専門家ではありませんので、上記理解で問題ないと断言できる状態ではありません。

よほど単純なサンプルコードでない限りは、自分の手元で検証した上で、自分なりにスクラッチで作りなおしたのを使う方が安全かもしれません。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-27 11:15:02
md5:a2290b322e6bd73d1f68c606ded2ed89
sha1:15594ad973f9d7afc36665503c3d817bc00e7164

技術/UNIX/hostname  

所有者: msakamoto-sf    作成日: 2013-07-27 10:33:33
カテゴリ: Linux UNIX シェルスクリプト 

あまり使っててトラブルになるようなコマンドではないが・・・

ただし、rootユーザで誤って

# hostname www.example.com

とすると、ホスト名を変更してしまうので注意が必要か。

また、ドメイン部分を削ったホスト名を表示してくれる(Linux, BSD) "-s" オプションだが、一部のSolarisではホスト名変更オプションになっていたことがあるらしく、うっかり

# hostname -s

とかするとホスト名が空文字・・・になるのかな・・・とにかく、変更されてしまう場合が在ったらしい。
その場合、

HOST=`hostname | cut -d. -f1`

のようにしてホスト名を取り出している、という技法を紹介してるblogがあった。

なおSolaris 10, 11ともに "-s" オプションはなくて単にホスト名を指定してればセット、引数が無ければホスト名を表示、というだけのシンプルなコマンドになっている。上記の話は、もうちょっと一昔前のSolarisの話かもしれない。特にどのバージョンで、というのも記載が無かったきがする。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-27 10:40:13
md5:8da7480373e24c19dcdf0dcef531a4f5
sha1:ba7120b744cda660c049f56cd67277b250b4cce7

Java/ClassLoaderの分割 : kamranzafar/JCL  

所有者: msakamoto-sf    作成日: 2013-07-21 11:16:56
カテゴリ: Java 

ClassLoaderを分割したい場合のメモ。

kamranzafar/JCL

Jarファイルをロードするカスタムクラスローダ。
https://github.com/kamranzafar/JCL

特色としては、単にクラスローダを分割するだけでなく、分割したクラスローダ間でのクラスキャストに対応していること。
Javaでは異なるクラスローダでロードされたClassは別物として扱われるため、以下の様なケースでは一般にClassCastExceptionが発生する。

  1. クラスローダAでHogeクラスをロード、インスタンスa生成
  2. クラスローダBでHogeクラスをロード、インスタンスb生成
  3. インスタンスa = インスタンスb で参照代入 -> 同じHogeクラスでもロードしたクラスローダが異なるためClassCastException

JCLでは、これを解決するために二種類の方式を提供している。

  1. (デフォルト)JDKのリフレクションAPIを使って、java.lang.reflect.ProxyによるProxyクラスで別クラスローダで生成したインスタンスをラップする。内部ではリフレクションを使ってインスタンスのメソッドを参照し、委譲する。
  2. cglibを使ったProxyクラスでラップする。内部ではリフレクションを使ってインスタンスのメソッドを参照し、委譲する。

詳しくはJCLのソースコード、"org.xeustechnologies.jcl.proxy"パッケージを参照。



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-21 11:40:58
md5:619289d2a8fc219d22cb40296f3883a8
sha1:d033c96fbd82156390ba6ce8685f27eedfa1e969

Groovy/Gradle/Eclipseとの連携/SpringのEclipsePlugin使用メモ  

所有者: msakamoto-sf    作成日: 2013-07-15 11:09:24
カテゴリ: Eclipse Groovy 

おおよその動作確認環境:

JDK 1.7
Eclipse 4.2 Juno SR2
Gradle IDE(=eclipse-integration-gradle) 3.1.0.xxxxx

使用時の細かいメモ。

Gradleプロジェクトをインポートするときのソースフォルダ・出力フォルダについて

  • Gradleプロジェクトをインポートすると出力フォルダが"bin/"になる。
    • 必要に応じてプロジェクトのプロパティから "Java Build Path" にてカスタマイズする。(".classpath"も目で見て確認しつつ)
    • カスタマイズする場合は "Allow output folders for source folders" にチェックを入れるのを忘れずに。このチェックが入ってないと、ソースフォルダ毎の"Output folder"設定は無視され、まとめて "Default output folder:"に指定したフォルダに出力されてしまう。
  • "resources" はソースフォルダに登録されない。
    • こちらも "Java Build Path" にて手動でソースフォルダとして登録する。
    • この時、"resources"のソースフォルダの"Excluded"に"**"を指定しておく。これを指定しないと、例えばlogback.groovyを実行時用とテスト用とで "src/main/resources/logback.groovy" と "src/test/resources/logback.groovy" に分けて配置していた場合、"logback.groovy" という名前が重複しているためEclipse側でビルドエラーになってしまう。
      • エラー・メッセージ例 : "Groovy:Invalid duplicate class definition of class logback : The sources .../src/test/resources/logback.groovy and .../src/main/resources/logback.groovy are containing both a class of the name logback."
      • "Excluded"に"**"を指定することでリソースファイルについてはEclipse側でコンパイル対象外となるため、".groovy"がコンパイルされることも無くなり、よって、衝突も起きない。

本家Issue Trackerに登録されてる、ちょっと気になるIssue

  • [#STS-2421] STs-Gradle should preserve already configured output folders - SpringSource Issue Tracker
  • [#STS-3057] Do not add Groovy Libraries to buildpath - SpringSource Issue Tracker
    • https://issuetracker.springsource.com/browse/STS-3057
      • インポートするときにGroovyライブラリをビルドパスに加えるの止めてくんない?という話。"afterEclipseImport"というタスクを定義して、インポート直後におそらく".classpath"のエントリをGradleで調整して回避する方法が掲載されています。これはこれで勉強になりますが、やっぱりある程度は手動調整の必要があるのかもしれません。
  • [#STS-2366] jar dependencies in war projects doubly declared in deployment assembly - SpringSource Issue Tracker
    • https://issuetracker.springsource.com/browse/STS-2366
      • なんかwarファイル作成すると依存jarが重複して登録されてない?という話。(これ、自分もどっかで見たような気が・・・)
      • ちょっと読み切れてないのですが、なんだかややこしそうな話が書かれてるっぽい・・・。

他にも、未解決のIssueは以下で見れます。マルチプロジェクト構成だったり、依存関係が複雑だったりすると色々トラブルが発生しているようです。Eclipse WTPとの連携もまだまだこれからでしょうね・・・。MavenのEclipseプラグインであるm2eがようやくm2e-wtpとしてKeplerで安定してきたばかりですし・・・。

プラグインアップデート時の謎のエラー

スクリーンショットとか取ってないので分かりづらいんですが、最初Gradle IDEの3.1.0.xxxxxxを入れました。他にもSpringのGGTSとか入れてましたので、その辺りで何かおかしくなったと思うんですが、"Help" -> "About Eclipse" -> "Installation Details" で見ると、なぜか

Gradle IDE
     Gradle Tooling API
Gradle Tooling API

というように、"Gradle Tooling API"が2つ、しかも一方は"Gradle IDE"の下に、もう一方はトップレベルに入ってるんです。バージョン番号は一緒。

で、この状態でアップデートしようとすると

Cannot complete the install because of a conflicting dependency.
Software being installed: Gradle IDE 3.3.0.201307040643-RELEASE (org.springsource.ide.eclipse.gradle.feature.feature.group 3.3.0.201307040643-RELEASE)
Software currently installed: Gradle Tooling Api 3.1.0.201210040512-RELEASE (org.gradle.toolingapi.feature.feature.group 3.1.0.201210040512-RELEASE)
Only one of the following can be installed at once: 
SpringSource Tool Suite Gradle Integration (Core) 3.3.0.201307040643-RELEASE (org.springsource.ide.eclipse.gradle.core 3.3.0.201307040643-RELEASE)
SpringSource Tool Suite Gradle Integration (Core) 3.1.0.201210040512-RELEASE (org.springsource.ide.eclipse.gradle.core 3.1.0.201210040512-RELEASE)
Cannot satisfy dependency:
From: Gradle Tooling Api 3.1.0.201210040512-RELEASE (org.gradle.toolingapi.feature.feature.group 3.1.0.201210040512-RELEASE)
To: org.springsource.ide.eclipse.gradle.core [3.1.0.201210040512-RELEASE]
Cannot satisfy dependency:
From: Gradle IDE 3.3.0.201307040643-RELEASE (org.springsource.ide.eclipse.gradle.feature.feature.group 3.3.0.201307040643-RELEASE)
To: org.springsource.ide.eclipse.gradle.core [3.3.0.201307040643-RELEASE]

というエラーになるんですね。多分Gradle Tooling APIが2つあるために依存関係がおかしくなってると思うのですが・・・。

試しにトップレベルの"Gradle Tooling API"をアンインストールして、その後、"Gradle IDE"をアップデートしたら成功しました。

ただ、"Gradle IDE"を3.3にアップデートしたら"Gradle Tooling API"が今度は表示されなくなったんですよね・・・。でもGradleプロジェクトは正常に操作できてて・・・謎・・・。
もしかしたら何かの表紙にトラブルになるかもと考えると多少心配ですが、まぁ最悪クリーンインストールすれば良いので考えないでおきます。

Gralde IDEのインストール方法が悪かったんですかね?GGTSでくっついてくるSTS Dashboardから / Market Place から / UpdateSite登録して手動で / のどれか忘れたのですが・・・。(ただ、少なくともUpdate Site手動登録はしてない。)



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-15 12:07:25
md5:c70e0c028863a7e0d1fad3432027c636
sha1:5d142092458178ab8532ebe2c97af4200a0fc81b

Groovy/Maven/Eclipse + GGTS使用時のメモ  

所有者: msakamoto-sf    作成日: 2013-07-15 11:47:51
カテゴリ: Eclipse Groovy 

Eclipse + GGTS(Groovy/Grails Tool Suite) でMaven仕立てのGroovyプロジェクトを使う時のメモ。

・嵌ったところ:

  • GGTSが追加する"Groovy Libraries"と、pom.xml経由で入ってくる"Maven Dependency"とで、"groovy-all"のバージョンが違うと"Module [groovy-all is loaded in version x.x.x and you are trying to load version y.y.y" というエラーが発生し、GroovyをEclipseのRun/Debugから実行できなくなる。
    • "Window" -> "Preference" -> "Groovy" -> "Compiler" -> "Groovy Compiler settings" で "Enable checking mismatches between..." のチェック外しても解決しない。
    • → プロジェクトを右クリックして、"Groovy" -> "Remove Groovy Libraries"すれば "Groovy Libraries"のセットが消えて、"Maven Dependencies"のセットだけになるので、実行時エラーは消え、実行できるようになる。
    • なお、MavenとGGTS側のバージョン衝突の話なので、"Enable checking mismatches..."のチェックは安全弁としてチェックしておいた方が良いだろう。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2013-07-15 11:52:51
md5:feec51493d184d853e6fca1525482e01
sha1:12622f5503eeb0b2d92cf9a2133cbbe02f940efb