Fess開発版のinitコマンドで初回起動前のパスワードと暗号鍵を設定する

Fessを新規に導入するときは、管理者の初期パスワードと、保存した認証情報の暗号化に使う鍵を最初に決めておきたいところです。開発版に追加されたfess-setup initで、この2項目を初回起動前に設定できるようになります。

初回起動前に実行する

出荷時のindex.user.initial_passwordはadmin、app.cipher.keyは___change__me___です。対応する開発版を展開し、まだFessを起動していない状態で、Fessの配置ディレクトリーから次を実行します。設定ファイルを書き換えられる権限が必要です。

bin/fess-setup init

オプションを省略すると、英数字16文字の管理者パスワードと英数字32文字の暗号鍵をランダム生成します。既定の設定ファイルはFess配下のapp/WEB-INF/classes/fess_config.propertiesです。RPM・DEB形式の配置では、対象ファイルを明示します。

bin/fess-setup init --config /etc/fess/fess_config.properties

成功後に表示される生成パスワードを安全に控えてから、Fessを初めて起動します。生成パスワードはコマンド実行時に表示され、設定ファイルにも書き込まれます。ターミナル出力や設定ファイルを不必要に共有しないようにします。暗号鍵そのものは通常の成功メッセージには表示されません。

既存環境のパスワード変更には使わない

初期パスワードはユーザーインデックスの作成時に読み込まれます。既に起動してユーザーを作成した環境で設定ファイルを変更しても、既存の管理者パスワードは変わりません。

また、暗号鍵を変えると、以前の鍵で保存したクロール設定などの認証情報を復号できなくなります。出荷時の値から変更済みの鍵がある場合、通常はコマンドが書き換えを拒否します。--forceで上書きはできますが、既存データを新しい鍵で暗号化し直す機能ではありません。新規導入向けのコマンドと考え、既存環境の鍵を安易に置き換えないようにします。移行や復元のためにも、設定ファイルと暗号鍵を安全に保管します。

値を指定する場合の条件

--admin-passwordと--cipher-keyで値を指定することもできます。ただし、コマンドライン引数は同じマシンの他の利用者から見える場合があるため、通常は自動生成を使う方が扱いやすいでしょう。

パスワードには空文字、前後の空白、制御文字、出荷時のadminを指定できません。明示する暗号鍵は空白を含まない印字可能なASCII文字の16・24・32文字で、出荷時の鍵も拒否されます。暗号方式がaes以外に設定されているファイルには対応しません。

対象の設定ファイルは既に存在する必要があります。2項目の既存行を置き換え、項目がなければ追記します。Fessを起動したり、既存ユーザーをリセットしたりするコマンドではないので、実行後の設定内容と初回ログインを確認して導入を進めます。

関連PR

FessのOIDCログインにnonce検証を追加する修正案

FessのOIDCプラグインに、認証要求とIDトークンをnonceで対応付ける修正が提案されています。以前のissuer・有効期限・対象クライアントの検証に加わる変更で、プロバイダーとの互換性に影響します。

ログインごとに発行してコールバックで照合する

修正案では、認証要求ごとにランダムなnonceを作り、stateとともにセッションへ保存します。プロバイダーから返ったIDトークンのnonceクレームが文字列で、保存値と一致することを確認します。

nonceがない、文字列ではない、値が違う、セッションに対応値がない場合は拒否します。コールバック到着時にセッションのnonceを取り除くため、同じコールバックを再利用する前提にもできません。nonceそのものは警告ログへ出しません。

初期値や無効化スイッチはない

この検証を任意で緩める設定は提案されていません。修正を含むプラグインを使う場合、プロバイダーが認証要求のnonceをIDトークンへ反映する必要があります。

検証環境で通常のログインを試し、認証要求からトークンまで対応する値が返ることを確認します。ログへトークンやnonceの値を出す運用は避け、拒否時はログインをやり直して設定を確認します。

プラグイン更新前に開始したログインは、セッションにnonceを持たないため一度失敗し、最初からやり直す必要があります。更新時の問い合わせ対応へ織り込んでおくとよい点です。

ほかの検証も引き続き確認する

nonceを追加しても、すべてのOIDC機能を実装するわけではありません。このPRではPKCE、iat、nbfの検証は追加されません。issuerの指定やHTTPS、既存のクレーム検証と併せて確認してください。

以前の記事にある「nonce未実装」という制限を変える提案ですが、マージ・配布を確認するまでは実運用で利用可能と判断しないでください。

関連PR

FioneのAutoML開発版で探索と派生特徴量の設定を確認する

FioneのAutoML開発版に、探索が早く終わりすぎる問題の修正、モデル種類の追加、派生特徴量の自動選別が入りました。従来のPython刷新の紹介に続き、今回は学習条件と結果の評価に関わる変更を整理します。

探索の初期値とモデルの種類が変わる

従来の探索では、Optunaの最初のランダム試行中に改善停止の判定が働き、十分に探索できない場合がありました。修正後はモデル種類ごとの最初の10試行を停滞の判定から除き、stopping_roundsの初期値も3から10へ変更します。時間上限やmax_modelsなど別の停止条件は引き続き働くため、試行回数が固定で保証されるわけではありません。

LightGBM、XGBoost、CatBoost、ExtraTreesにRandomForest、Linear、DeepLearningが加わります。Linearは分類でロジスティック回帰、回帰でリッジ回帰、DeepLearningは2層のMLPです。H2Oと同じ実装や学習結果になるという意味ではなく、アンサンブルもGLMによるスタックではありません。

派生特徴量は初期値で有効

feature_engineeringの初期値はtrueです。学習画面の該当チェック項目で有効・無効を選びます。エンジンをPythonから利用する検証では、例えば次のように無効化できます。targetは実データの目的列へ置き換えます。

from fione.engine.config import TrainConfig
config = TrainConfig(target="label", feature_engineering=False)

候補には文字列の語や形、カテゴリや数値の頻度、行単位の件数、日付の要素と差、数値列の組み合わせ、グループ平均、クラスタなどがあります。特徴量の値を作る処理自体は目的変数を読みません。ただし採否の判断には予測誤差を使います。

最大約2万行のサンプルと小さなLightGBMで候補群を比較し、平均損失の0.1%と差の標準誤差3倍を超える改善があり、分割の70%以上で改善することなどを求めます。さらに別の分割で最終確認します。選別に使う時間は残り時間の最大10%で、確認を完了できなかった候補は採用されません。短い実行で派生特徴量が追加されなくても、それだけで異常とはいえません。

精度と資源消費は手元のデータで比較する

探索が早く終わらなくなる分、以前より時間を使う場合があります。PR内の測定でも新モデル種類による明確な改善は出ておらず、派生特徴量の改善は小さいものでした。有効・無効を同じ条件で比較し、学習に使わないテストデータで評価します。採否判定と交差検証が同じ行を使うため、交差検証のスコアはやや楽観的です。

LinearとDeepLearningはone-hot展開したデータが1億セルを超える場合、通常の全モデル探索から通知付きで外れます。全データをメモリーに読むため、モデル種類が増えても大規模データを無制限に扱えるわけではありません。複数列から作った特徴量の寄与度・重要度は元の列へ等分され、因果関係を示すものでもありません。

関連PR