V12 Early Access Program（以下EAP）で DAOS の新機能を試していた時にわかったことについてメモしておきたいと思います。
DAOS Tier2 という Domino バージョン11 の新機能があります。
ざっくり言うと、リポジトリ（Tier1）に存在するNLOのうち、指定した期間中に誰もアクセスしなかったものをさらに別の場所（Tier2）へ移動するというものです。高コストなTier1の容量削減が期待できる機能です。
今回 EAP で Tier2 の扱いを改善する機能が含まれていることを知り、試してみようと思い立ち早速環境構築しているのですが、慣れない Docker 環境ということもあり苦戦しています...
さて、Tier2 として利用可能な「S3互換ストレージ」はオンラインヘルプ等を参照していただくとして、その中のひとつ AWS S3 へアクセスするには AWS の認証情報が必要なのですが、この認証情報を Domino 側に保持する場所が必要になります。
Tier2 有効化の手順の中で、認証情報を保存しておく場所として「資格情報ストアアプリケーション（CredStore.nsf）」を作成します。この作成過程で、サーバーIDに NEK というものを追加しなければなりません。
NEK とは Named Encryption Key の略語です。日本語のヘルプ文書では「名前付き暗号化キー」とか「文書暗号化キー」と表記されていました。
"Named" が示すとおり、NEK には名前を付けます。
暗号化キーですので、何かを暗号化する時に使用するキーとなります。ヘルプによるとこの「何か」とは「資格情報ストアに格納する文書」のようです。Tier1 や Tier2 へ NLO を格納する際に（デフォルトでは）暗号化しますが、このとき使用されるキーはサーバーIDの公開鍵（バージョン12ではNLOの暗号化キーとしてサーバーIDと（新たに追加される）Shared Key のどちらか選択可能になる模様）であり NEK ではありません。
Notes/Dominoにおけるフィールドや文書の「暗号化」についてはここでは説明を省きますが、ノーツクライアントでフィールドの暗号化を行う際に指定する「シークレットキー名」が、NEK につける名前に相当するもののように思います。
参考までに NEK に付ける名前ですが、オンラインヘルプの例では "credstorekey" とか "credstorenek" でした。どちらでもいいと思いますが、忘れないようにしてください。
NEK を扱うコマンドは「KEYMGMT」です。
NEK をサーバーIDへ追加する場合、create nek というオプションに続けて、暗号化キーの名前を指定します。例えば次のようになります。
| keymgmt create nek credstorenek |
このコマンドが成功するとコンソールに Fingerprint が表示されます。
[1D78:000A-1D74] keymgmt create nek credstorenek [1D78:000A-1D74] 2020/12/10 13:13:04.37 NEK > NEK credstorenek - Fingerprint 1F64 4DB7 1F8A 4CD0 CE3F 8ED7 A5AD AE65 FC10 3091 [1D78:000A-1D74] NEK credstorenek created successfully |
この Fingerprint の長い文字列はぜひ控えておいてください。その理由を説明します。
先ほども言いましたように NEK はサーバー IDファイルに追加されます。
ノーツユーザーのID（ファイル）に追加されている情報ならばノーツクライアントを使って確認することができますが、サーバーのID（ファイル）に追加した NEK の情報を確認する方法は現在のところないのです。※機能改善要望提出済み ※2020/12/14追記：確認する手段が無いこともないことがわかったので本エントリの最後に追記します
従って、現在のIDファイルにどの（名前の） NEK が含まれているのか、あるいは NEK が全く追加されていないのか、といったことは確認できません。
代替策ではありませんが keymgmt コマンドで NEK を export する際、export に成功するとコンソールに Fingerprint が表示されます。これが NEK の作成時のものと同じ値かどうかで判断することができます。
[1D78:000A-1D74] keymgmt export nek credstorenek credstorenek.key passw0rd [1D78:000A-1D74] 2020/12/10 14:47:24.61 NEK > NEK credstorenek - Fingerprint 1F64 4DB7 1F8A 4CD0 CE3F 8ED7 A5AD AE65 FC10 3091 [1D78:000A-1D74] NEK credstorenek exported successfully |
ちなみに export する際、誤ってIDに追加されていない NEK の名前を指定すると叱られます。
[1D78:000A-1D74] keymgmt export nek credstorekey credstorekey.key passw0rd [1D78:000A-1D74] You don't have any of the specified encryption keys |
話を元に戻します。
複数の Domino サーバーがあってそれぞれに DAOS を有効にしている場合、それぞれのサーバーで Tier2 の有効/無効を設定できます。ヘルプでは、Tier2 を有効にする複数の Domino サーバーで（Tier2 として設定する S3 互換ストレージ内の保管エリア：これを「バケット」と呼んでいます）同じバケットを使う場合、1つの Dominoクラスタ内に複数のDominoサーバーを設定することを推奨しています。その場合、設定済みの NEK を export して、他の Domino へ import する（そしてcredstore.nsfの複製を作成する）ことで共通の NEK を使用する手順となっています。
[1D78:000A-1D74] keymgmt import nek credstorenek.key passw0rd [1D78:000A-1D74] 2020/12/10 16:47:00.90 NEK > NEK credstorenek - Fingerprint 1F64 4DB7 1F8A 4CD0 CE3F 8ED7 A5AD AE65 FC10 3091 [1D78:000A-1D74] NEK credstorenek imported successfully |
ここで他の Domino（の ID ファイル）へ import する時、すでに同じ名前の NEK が ID に追加されていれば、既存の NEK が上書きされることはなく「ID ファイルに暗号キーを追加できません。同じ名前のキーがあります。」と叱られます。
[1D78:000A-1D74] keymgmt import nek credstorenek.key passw0rd [1D78:000A-1D74] Cannot add the encryption key to your ID file. A key with that name already exists. |
※ create nek の場合も同名の NEK があれば同じメッセージが表示されました
こういった場合に ID から NEK を削除することが可能です。
NEK を削除するには delete nek オプションに削除したい NEK の名前を付けて実行します。
[1D78:000A-1D74] keymgmt delete nek credstorenek [1D78:000A-1D74] 2020/12/10 16:06:32.59 NEK > NEK credstorenek - Fingerprint 0FA8 40BB E4FF 6378 C0CC BC7E 7187 3A18 AB6C BF43 [1D78:000A-1D74] NEK credstorenek deleted successfully |
と、ここまで NEK の全ての操作（Create, Export, Import, Delete）について説明しました。
ここからは検証中のアクシデントから得たことです。
今回私は検証中に誤って既存の NEK を削除してしまいました。
あわてて create nek オプションに同じ名前を指定して NEK を追加し直したのです。
ところが、この後から S3 へのアクセスに失敗していることを示すようなメッセージがコンソールに現れるようになりました。
[2C10:0002-2EB8] AWS:Initialize: Error loading pIDaosConfig. Error: 107 (Insufficient memory.) |
Domino の再起動後は、上のエラーに加え、Tier2 サービスが not avairable というメッセージまで表示されてしまいました。
[24A4:0002-24A8] DAOS Tier 2 storage services are not available. : Program library not loaded. Required .DLL missing or could not load. |
NEK を作成し直す場合、その名前が以前と同じであることが重要では無いようです。
あわてて追加した NEK により暗号化キーが変わってしまったことにより、暗号化された認証情報の文書を復号できなくなり、AWSへのアクセスができなくなってしまったように思います。
この後、私自身がその存在を忘れていましたが、以前たまたま export してあった NEK（credstorenek.key ファイル）が見つかったのです。そこで、あわてて追加したほうの NEK を削除し、元々追加されていた NEK を credstorenek.key から import すれば復元できるのではないかと考え、実施してみました。
すると Tier2 へのアクセスが復活したのです。
AWS:AWSSelfTest: Success. AWS connection for DAOS is up and running. |
削除（delete nek）した時と import（import nek）した時に表示された Fingerprint を比較すると、それらの値は全く異なるものした。
Fingerprint が同じであれば NEK が同じものであることが保証されるのかどうかを試してみようと考え、NEK の削除と credstorenek.key からの import を繰り返し実施してみたところ、Fingerprint は削除の時と import の時で同じ値が表示されました。さらに import の後に Tier2 のエラーは見られないことから、問題なさそうだという結論を得ました。
もし export した NEK が無かった場合、CredStore.nsf を削除して新たな NEK で CredStore.nsf を作り直し、AWSの認証情報を登録しなおすことが必要だったことでしょう。おそらくサーバー再起動も必要になるため、負担の大きい面倒な作業になったことでしょう。
再びこういった事故があるかもしれないので、create nek で NEK を追加した後には、NEK を export nek でファイルに残したうえで、Fingerprint の値と export したときに指定したパスワードと export したファイルを大事に保管しようと決意した年の瀬でした。
2020/12/14追記：
サーバーIDに追加した NEK を確認する方法が無い、というのは誤りでした。ノーツクライアントを使い、確認したいサーバーのIDに切り替えることで、NEK の存在を確認することができました。
0 件のコメント:
コメントを投稿