この章では、N1 Grid Service Provisioning System ソフトウェア (これ以降、プロビジョニングシステム) に関連するプランとコンポーネントの概念について説明します。
この章の内容は次のとおりです。
componentは、アプリケーションを定義するresourcesの論理的なグループです。アプリケーションを構成するリソースの扱い方を規定した一連の命令も含まれます。コンポーネントは、以下のように分けることができます。
ファイルとディレクトリ
自律型アーカイブ (J2EETM Enterprise Archives (EAR)、COM コンポーネントなど)
完結したアプリケーション (BEA WebLogic Server など)
オペレーティングシステムレベルの更新 (パッチ、サービスパックなど)
ほかのコンポーネントを示すポインタ
プロビジョニングシステムを使用して、データセンター内のアプリケーションを管理できます。この製品でアプリケーションを管理するには、先にアプリケーションをコンポーネントとしてmodelしておく必要があります。プロビジョニングシステムを使用すると、次の作業を行えます。
アプリケーションのインストール、構成、および分析に関する情報とともに、各アプリケーションごとに慎重に定義したソフトウェアリソースが含まれる、アプリケーションモデルを作成できます。
バージョン管理が採用されているコンポーネントリポジトリにコンポーネントを格納できます。バージョン管理により、任意のバージョンのコンポーネントを取得できます。
プランでコンポーネントを利用できるようにします。プランでは、手順を追ってデータセンターオペレーションを実行し、各コンポーネントに組み込まれているナレッジを活用します。
コンポーネント間の比較およびコンポーネントとソフトウェア導入先との比較
プロビジョニングシステムがサポートするコンポーネントの基本タイプは、次の 2 種類です。
単純コンポーネント。simple componentには、単一リソースが含まれ、ほかのコンポーネントへの参照は含まれません。
複合コンポーネント。composite componentには、ほかのコンポーネント (単純と複合の両方) への参照だけが含まれ、リソースは含まれません。
複合コンポーネントには、コンポーネントの参照が含まれます。参照先のコンポーネントをcontained components(子コンポーネント) といいます。参照する側のコンポーネントをcontained components(親コンポーネント) といいます。
複合コンポーネントは、各包含コンポーネントについて、top-level componentとしてインストールするのか、それともnested componentとしてインストールするのかを宣言します。上位レベルとしてインストールされた包含コンポーネントは、プランによって直接インストールされた場合と同様、どのコンポーネントでも使用されます。ただし、包含コンポーネントが入れ子としてインストールされた場合、そのサービスを利用できるのはコンテナコンポーネントに限られます。入れ子の包含コンポーネントでは、コンテナコンポーネントが必要とする機能を非常に細かい単位で定義しますが、ほかのコンポーネントには無意味です。一方、上位レベルの包含コンポーネントでは、コンテナコンポーネントが使用するサービスを定義しますが、定義されたサービスはほかのコンポーネントも使用できます。
複合コンポーネントにはコンポーネントそのものではなく、ほかのコンポーネントの参照が含まれます。参照コンポーネントは、別の既存コンポーネントであり、コンテナコンポーネントとは別に更新され管理されます。1 つのコンポーネントを、任意の数の複合コンポーネントが参照できます。ほかの複合コンポーネントから参照されるかどうかで、コンポーネント名が変わることはありません。名前の衝突はパスを使用して解決されます。
プロビジョニングシステムは、コンポーネントに関連付けられる物理リソースを管理します。これには事前に定義された一連のコンポーネントも含まれます。このようなコンポーネントは直接使用することも、ほかのコンポーネントを作成するためのサンプルとして使用することもできます。
コンポーネントには手続きも組み込まれます。procedureは、コンポーネントに格納され、コンポーネントの配置を制御するプログラムです。コンポーネント手続きは通常、インストール、アンインストール、およびキャプチャのsnapshotsとして定義します。その他の手続きは制御ブロックで定義できます。controlとは、コンポーネントに組み込まれた一連の命令であり、配備されたアプリケーションを管理する目的で使用できます。たとえばアプリケーションの起動や停止などを制御できます。コンポーネントには、ほかのコンポーネントへの依存を検査したり、特定のプロセスが動作しているかどうかを検証したりする命令を組み込むことができます。
コンポーネントではsubstitution variablesも宣言できます。置換変数は、コンポーネント内で使用することも、コンポーネントに含まれる任意のリソースに使用することもできます。置換変数は、プランの実行時に置換する値のプレースホルダとして使用できます。
プロビジョニングシステムでは、非常に柔軟にコンポーネントをモデル化できます。モデル化するアプリケーションによって、次のどの方式を使用するかが決まります。
完全自動のモデル化。gold serverから、またはソースコード制御システムから、コンポーネントにチェックインできます。チェックインが完了すると、プロビジョニングシステムがcomponentを自動的に生成するので、生成されたコンポーネントからインストール、構成、comparison手続きを実行できます。
この方式は、プラグインがすでに定義されてインポートされているアプリケーションをモデル化する場合に使用します。組み込みコンポーネントタイプまたはインポートされたコンポーネントタイプを使用すると、アプリケーションコンポーネントを構成する一般的なリソースを自動的にモデル化できます。コンポーネントタイプのテンプレートには、インストールなど、基本的な動作に関する組み込み手続きが含まれています。したがって、プランを作成しなくても、一般的なコンポーネントタイプの基本動作を実行できます。
組み込みコンポーネントタイプについては、第 3 章「組み込みコンポーネントタイプ」を参照してください。プラグインによって取得したコンポーネントタイプについては、 http://docs.sun.com/db/coll/1223.1 にアクセスして、『 N1 Grid Service Provisioning System 5.0 Plug-In Collection 』を参照してください。
XML オーサリングによる組み込みコンポーネントタイプの拡張。ブラウザインタフェースの「Advanced Edit」ページで XML を直接編集することによって、自動生成されたコンポーネントをカスタマイズできます。XML が指定されているファイルをシステムにダウンロードし、Turbo XML などの XML スキーマ検証エディタで編集することによって、コンポーネントをカスタマイズする方法もあります。
XML の編集時には、次の作業が可能です。
変数の追加によるコンポーネントのカスタマイズ
拡張制御手続きの呼び出しの追加 (IIS または Microsoft Windows サービスの起動/停止など)
XML でのコンポーネントモデルのオーサリング。XML エディタを使用して、『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の第 2 章「コンポーネントと単純プランにより使用される共有スキーマ」、『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の第 3 章「コンポーネントのスキーマ」、および『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の第 4 章「プランのスキーマ」に記載されているコンポーネントスキーマを参照することによって、独自のコンポーネントを作成できます。
コンポーネントを使用する前に、そのコンポーネントの XML ファイルとリソースをリポジトリにチェックインしておく必要があります。
ブラウザインタフェースを使用したコンポーネントモデルのオーサリング。ブラウザインタフェースを使用してコンポーネントを作成できます。保存すると、コンポーネントが自動的にビルドされます。その後、次のいずれかによってコンポーネントをインストールできます。
1つ以上のホストまたはホストセットにコンポーネントをインストールするプランの作成
プランについての詳細は、第 4 章「プラン」を参照してください。
コンポーネントを使用するには、そのコンポーネントをリポジトリにチェックインしておく必要があります。
コンポーネントをチェックインすると、コンポーネントがビルドされ、特定のバージョンのリソースが割り当てられます。ビルドによりコンポーネントにもバージョン番号が割り当てられるため、そのバージョンのコンポーネントは特定のバージョンのコンポーネントリソースと常に関連付けられるようになります。
コンポーネントはさまざまな特性に基づいて識別されます。次に、代表的なコンポーネント特性について説明します。
コンポーネントタイプ名。コンポーネントに関連付けられるコンポーネントタイプの名前です。「コンポーネントタイプの概念」を参照してください。
プロビジョニングシステムには、ファイル、ディレクトリなどの汎用モデルをサポートするコンポーネントタイプがいくつか組み込まれています。Microsoft Windows および WebLogic など、アプリケーションドメインに固有のプラグインをインポートすることによって、ほかのコンポーネントタイプをシステムに追加できます。
バージョン番号。コンポーネントのバージョン番号です。コンポーネントを変更するたびに、バージョン番号が増えます。
チェックイン時に、バージョン番号の増分方式を選択します。メジャー番号 (小数点の左側) を増やすことも、マイナー番号 (小数点の右側) を増やすこともできます。
チェックイン日付。コンポーネントがチェックインされた日時です。
チェックインユーザー。ユーザー IDです。 この属性は、プロビジョニングシステムのプロセスを監査する場合に便利です。
カテゴリ。コンポーネントリストをフィルタリングするために、任意で使用するオブジェクトです。カテゴリオブジェクトを作成すると、以後はそのオブジェクトを使用してコンポーネントを分類できます。
ソース。このコンポーネントに組み込まれているリソースです。ソースは、単一ファイルリソースにすることも、ほかのコンポーネントを含むリストにすることもできます。
コンポーネント変数。コンポーネントリソースの配備に必要な変数と値 (名前と値のペア) です。「コンポーネント変数」を参照してください。
隠し。コンポーネントリストでコンポーネントを表示するかどうかを指定するための特性です。デフォルトでは、コンポーネントは表示されます。
バージョンの古いコンポーネントや管理対象ではないコンポーネントを隠すと、コンポーネントリストを短縮できます。短縮リストには、隠されていない、つまり現在管理しているコンポーネントが含まれます。隠しコンポーネントは、表示を要求しないかぎり、リストには含まれません。
component procedure (またはprocedure) は、コンポーネントに組み込まれ、コンポーネントを管理するプログラムです。コンポーネント手続きはコンポーネントのインストール、アンインストール、または制御を行います。手続きはコンポーネントのビルド時に作成されます。
コンポーネントには複数の手続きを指定できます。たとえば、制御手続きをコンポーネントに組み込むことで、そのコンポーネントがモデル化するアプリケーションの起動と停止を行います。
コンポーネントタイプの拡張により作成されたコンポーネントは、そのコンポーネントタイプによって定義された手続きを継承します。
複合コンポーネントを作成した場合は、デフォルトのインストールおよびアンインストール手続きを継承します。通常、コンポーネントは関連付けられるコンポーネントタイプから手続きを継承します。
Component inheritanceとは、コンポーネントが別のコンポーネントから属性や動作を取得する手段です。作成したコンポーネントは、関連付けられるコンポーネントタイプからvariables、snapshots、およびproceduresを継承します。
継承を用いることによって、強力かつ柔軟性の高いコンポーネントモデルになります。たとえば、IIS Aplication コンポーネントタイプに基づくコンポーネントが 1000 個あるとします。これらのコンポーネントに機能を追加するとします。IIS Application コンポーネントタイプに機能を追加することで、そのコンポーネントタイプに属する 1000 個のコンポーネントが新しい機能を継承することになります。
コンポーネントではvariablesを使用できます。変数は値を格納するユーザー定義のコンテナであり、deployment時に使用されます。
component variableは、コンポーネントの外部にあるオブジェクトからコンポーネントの一部にアクセスして設定できるようにするために使用します。たとえば、コンポーネントにホスト単位で変更される installPath という変数を設定できます。この変数では、各コンポーネントのインストール先を定義します。
コンポーネント変数の値を別のコンポーネント変数への参照にすることができます。これには、コンポーネントのコンテナによって定義された変数が含まれます。コンテナコンポーネントに入れ子のコンポーネントを追加すると、ブラウザインタフェースは、参照変数がコンテナで定義されているかどうかを検証します。その変数がコンテナコンポーネントで定義されていない場合、ブラウザインタフェースは自動的に参照変数をコンテナの変数リストに追加します。
たとえば、単純コンポーネントは通常、installPath 変数がコンテナコンポーネントの installPath 変数の値を持つように定義します。この場合、参照変数の構文は :[container:installPath] です。変数置換についての詳細は、第 6 章「構成の生成」を参照してください。
コンポーネント変数は、コンポーネントの配備時に評価されて値が割り当てられます。コンポーネント変数を使用して、配備の実装に必要な情報 (ホスト名、IP アドレス、パスなど) を指定します。
変数設定値 は、変数の値の集まりであり、1 つ以上のコンポーネント変数について、デフォルト値を変更する目的で使用できます。使用する変数設定値に基づいて、コンポーネント変数にさまざまな値を指定できます。どの変数設定値を使用するかは、プランの実行時に指定します。
たとえば、コンポーネントを運用環境および開発環境など、異なる環境に配備します。定義したコンポーネント変数が、環境間の相違を認識するように設定されている場合、変数設定値を使用することによって、各環境に合わせてコンポーネントを設定できます。たとえば、あるセットを使用して運用環境を設定し、別のセットで開発環境用にコンポーネントを設定することが可能です。
変数のオーバーライドによって、複合コンポーネントの変数のデフォルト値を無効にできます。単純コンポーネントでこの機能を使用することはできません。
コンポーネントにほかのコンポーネント (child components) が含まれている場合、変数設定値が有効なのは上位レベルのparent componentに限られます。すべての子コンポーネントは、デフォルトの変数値を使用します。子コンポーネントは、次の 2 通りの方法で、親コンポーネントから変数値を取得できます。
コンテナ (親) コンポーネントは、包含 (子) コンポーネントに変数値を「プッシュ」します。子コンポーネントのデフォルト値を変更するには、子コンポーネントを収容するコンポーネントを作成するときに、変数のオーバーライドを設定します。参照コンポーネントごとに、使用できる変数のオーバーライドセットを設定します。
包含 (子) コンポーネントは、コンテナ (親) コンポーネントから変数値を「プル」します。包含コンポーネントの変数値は 1 つ以上がコンテナコンポーネントの変数値に基づいて定義されます。包含コンポーネントは、変数置換構文 :[container:varname] を変数のデフォルト値に使用します。
ステップは、プランとコンポーネントの両方に組み込むことのできる単純な命令です。
ステップについては、「ステップの概要」を参照してください。
component typeとは、動作をカプセル化してほかのコンポーネントで再利用できるように設計されたコンポーネントです。コンポーネントタイプは通常、特定のアプリケーションタイプに固有の動作を意味します。たとえば、Enterprise JavaBeansTM (EJBTM) コンポーネントタイプには、アプリケーションサーバーとの間で相互に EJB アーカイブを配備したり配備を解除したりするための、汎用手続きが組み込まれます。コンポーネントをコンポーネントタイプからextendsすると、そのコンポーネントタイプで定義されている動作が自動的に継承されます。
コンポーネントは通常、コンポーネントタイプと関連付けられます。ブラウザインタフェースで untyped を選択した場合は、コンポーネントがほかのコンポーネントタイプから拡張されることはありません。プロビジョニングシステムには組み込みコンポーネントタイプがいくつかあります。第 3 章「組み込みコンポーネントタイプ」を参照してください。
単純コンポーネントが参照するファイル、ディレクトリ、およびその他のツリー構造は、コンポーネントに含まれる別々の単位として管理されます。
たとえば、プロビジョニングシステムが IIS アプリケーションを参照リソースとして管理する場合、IIS アプリケーションには下記が含まれます。
ディレクトリとその内容
IIS Web サイトの設定値
COM+ アプリケーション
Microsoft Windows のレジストリ設定値
ファイル、ディレクトリなど、コンポーネントが参照するリソースの一部は、ゴールドサーバーまたは別のデータソースからコピーできます。IIS Web サイトの設定値、Microsoft Windows のレジストリ設定値など、その他については、独立した管理可能な要素として扱えるように、特殊な方法でデータソースから抽出する必要があります。
組み込みコンポーネントタイプに関して、プロビジョニングシステムは JavaTM 2 プラットフォーム、Enterprise Edition (J2EE プラットフォーム)、および Microsoft Windows アプリケーションに使用する、一般的なソースアイテムを認識できます。これらのコンポーネントタイプでは、コンポーネントリソースとして使用するデータを正確に抽出し、リポジトリにコンポーネントリソースを格納して、指定された場所にリソースを正しくインストールすることができます。
System servicesは、ホストを準備するときに、該当するすべてのホストに自動的に配備されるコンポーネントです。システムサービスは、コンポーネントのインストールと管理で、ほかのコンポーネントによって使用されるユーティリティ制御とリソースを定義します。
システムサービスによって、プランの実行時に利用できるサービスセットが充実します。
planはexecution planともいい、特定のホスト上で 1 つ以上のコンポーネントを管理するために使用する命令のシーケンスです。たとえば、実行プランで 3 つのコンポーネントをインストールして、別のコンポーネントの「起動」制御を開始することができます。
プランは、ほかのプランのシーケンスを含むことができます。これにより、共通の命令シーケンスをプランとして作成し、複数のプラン間で共有できます。たとえば、3 つのコンポーネントをインストールし、別のコンポーネントに対して起動を開始するように、プランでプロビジョニングシステムに指示します。
プロビジョニングシステムは、XML schemaで表すオブジェクトのメモリー内表現を提供します。この表現は、これらのオブジェクトの妥当性検査、持続性、バージョン管理のプロセスも定義します。
プロビジョニングシステムがプランを実行するときに、コンポーネントで宣言された置換変数が実際の値に置き換えられます。プロビジョニングシステムは通知機能もサポートするので、プランの実行に関連したイベントに対して電子メールを送信できます。
プロビジョニングシステムがサポートするプランは、次の 2 種類です。
単純プラン。simple planには、単純ステップの集まりが含まれます。このプランは、ほかのプランを呼び出すことはできません。
複合プラン。composite planには、ほかのプラン (サブプラン) だけが含まれます。
XML スキーマで 2 種類のプランを区別します。したがって、ほかのサブプランの呼び出しが含まれる上位レベルのプランを使用することも、単純なステップからなり、サブプランの呼び出しは含まれていない単純プランを使用することもできます。
単純プランのステップの実行が同一ターゲットホストセット上に限定されるのに対して、複合プランのステップは複数の異なるターゲットホストセット上で実行できるので、この区別は重要です。複合プランでは、含まれる単純プランごとに、ターゲットホストセットを 1 つずつ使用できます。
Steps は、プランとコンポーネントの両方に組み込むことのできる単純な命令です。プロビジョニングシステムがサポートするステップの種類は、次のとおりです。
コンポーネント内部からのみ呼び出すことのできるステップ。このタイプのステップを呼び出すことができるのは、インストールブロックまたはアンインストールブロックからだけです。『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の「コンポーネントのインストール専用のステップ」と『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の「コンポーネントのアンインストール専用のステップ」を参照してください。
プランからのみ呼び出すことのできるステップ。このタイプのステップを呼び出すことができるのは、複合プランまたは単純プランからだけです。『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の「複合プラン専用のステップ」と『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の「単純プラン専用のステップ」を参照してください。
プランまたはコンポーネントから呼び出すことができるステップ。『N1 Grid Service Provisioning System 5.0 XML スキーマリファレンスガイド』の第 2 章「コンポーネントと単純プランにより使用される共有スキーマ」を参照してください。
まだインストールされていないコンポーネントは <install> ステップを使用できます。
まだインストールされていないコンポーネントを参照するステップは、コンポーネント名とオプションのバージョンを指定するだけです。
すでにインストール済みのコンポーネントは、次のステップを使用できます。
<uninstall>
<call>
<checkDependency>
<createDependency>
<addSnapshot>
インストール済みコンポーネントを参照するステップは、installPath 属性を指定する必要があります。同じサーバーに同じコンポーネントを繰り返しインストールできるからです。
「Apache」コンポーネントが次の属性値とともに、ホストにインストールされているものとします。
コンポーネントインスタンス |
installPath |
version |
installDate |
---|---|---|---|
A |
/opt |
1.3 |
6/1/01 6:00 p.m. |
B |
/usr/local |
1.4 |
6/1/01 5:00 p.m. |
C |
/opt |
1.2 |
6/2/01 5:00 p.m. |
D |
/usr/local/bin |
1.4 |
6/3/01 5:00 p.m. |
E |
/export |
1.1 |
6/4/01 5:00 p.m. |
以下に、installPath 属性と version 属性の組み合わせに応じて、値が供給されたときに、どのインストール済みコンポーネントが参照されるかを示します。
installPath |
version |
versionOp |
結果 |
説明 |
---|---|---|---|---|
なし |
なし |
なし |
E |
version および installPath の値に関係なく、ターゲットホストに最後にインストールされたコンポーネントが使用されます。 |
/opt |
なし |
なし |
C |
version の値に関係なく、指定のインストールパスに最後にインストールされたコンポーネントが使用されます。 |
/usr/bin |
なし |
なし |
エラー |
指定のパスにコンポーネントはインストールされていません。 |
なし |
1.4 |
= |
D |
installPath の値に関係なく、指定のバージョンが含まれているコンポーネントのうち、最後にインストールされたものが選択されます。 |
なし |
1.5 |
任意 |
エラー |
指定されたバージョンのコンポーネントはインストールされていません。 |
/usr/local |
1.4 |
=, >= |
B |
指定の installPath 属性値および version 属性値と一致するコンポーネントが選択されます。 |
/usr/local |
1.2 |
= |
エラー |
指定のインストール パスにこのバージョンはインストールされていません。 |
/usr/local |
1.2 |
>, >= |
B |
installPath、version、および versionOp の値と一致したもの。 |
/opt |
3 |
任意 |
エラー |
2 つ以上のコンポーネントが同じパスにインストールされ、なおかつ名前が同じ場合は、事実上、最後にインストールされたコンポーネントがインストール済みコンポーネントを上書きします。それまでにインストールされていたコンポーネントは、直接指定してもアクセスできません。 |
sessionが開始されるのは、ブラウザインタフェースにログインしたとき、または CLI を使用したときです。セッションは、ユーザーがログアウトするまで、または非アクティブな状態によりセッションが終了するまで続きます。論理上、セッションは、特定のユーザーの認証済みの資格情報を表します。セッションにより、再認証されなくても、一連の関連要求を通してユーザーが識別されます。
各セッションは、一組のsession variablesを持ちます。この変数は、ユーザーのログイン時にデータベースに基づいて初期化されます。セッション変数を使用して、ユーザー認証やその他の資格など、セッション関連の情報を維持できます。現在のセッションのセッション変数は、データベースに保存されているセッション変数に影響を及ぼすことなく変更できます。セッション変数とその値を変更した場合、それらをデータベースに保存できます。保存する場合は、すべての変数とその値が保存され、以降のセッションで使用できるようになります。プランや比較の実行時に、セッション変数を参照できます。
複数のセッションを開始していて、セッション変数を同時に保存しようとした場合、最初のセッションの変数のみが保存されます。最初のセッションのセッション変数が保存されたあと、ほかのセッションのセッション変数の変更を保存しようとしても保存できません。このような場合に変更を保存する方法は、次のとおりです。
すべてのセッションからログアウトします。
もう一度ログインしてセッションを開始します。
正常に完了した最後の保存に基づいて、データベースからセッション変数と値の新しいセットを取得します。
セッション変数を適切に変更します。
変更したセッション変数を保存します。
セッション変数は大域名前空間に存在するので、宣言したセッション変数名をすべてのユーザーセッションで使用できます。たとえば、セッション変数名として passwd を定義したとします。passwd セッション変数を要求するプランは、いずれも同じ変数を参照します。セッション変数名の有効範囲は現在のプラン、コンポーネント、ブロック、またはホストに限定されません。したがって、セッション変数名が一意になるように配慮する必要があります。たとえば、自分のイニシャルと生年月日、またはその他の識別情報を使用して、セッション変数の一意性を確保してください。
セッション変数は名前、値、および secure フラグで構成されます。セッション変数名に関する制約は、ホストタイプ変数名の場合と同じです。secure フラグは、セキュリティを保護して値を格納するかどうかを指定します。
セキュリティを保護して値を格納する場合は、secure フラグを true (真) に設定します。この場合、セッション変数の値は *** で表示され、保存時には変数が暗号化されます。プランの実行時にこの値が使用された場合、この変数の値はプランの履歴に反映されません。この secure フラグは、パスワードなど、変数値が機密データの場合に使用します。セッション変数はデフォルトで、secure フラグを true に設定して作成されます。
セキュリティ保護された変数をデータベースに保存する場合は、暗号鍵として自分のパスワードを入力する必要があります。パスワードを間違って指定すると、パスワードの再入力が求められます。
入力したパスワードが認識されないと、エラーが発生します。システム管理者によってパスワードまたはログイン構成が変更されている場合などに、このよう状況が発生します。次の 2 つのオプションがあります。
セッション変数の再暗号化。ユーザー名、セッション変数の暗号化に使用したパスワード、さらに新しいパスワードを入力します。
セッション変数のフラッシュ。宣言したすべてのセッション変数を削除します。ユーザー名と新しいパスワードを入力します。
このオプションは、セッション変数の暗号化時に使用したパスワードを忘れた場合に使用します。