FessのFileSearchで1000件を超えるフォルダーの表示を調整する

FileSearchでファイル一覧には見つかるのに、左側のツリーに一部のサブフォルダーが現れないことがあります。フォルダーの深さではなく、ツリーを作るために取得するURLの件数上限が原因になるケースです。

サブフォルダー数ではなくURL数で制限される

ツリーはフォルダー階層を直接問い合わせるのではなく、検索対象のurlファセットから階層を組み立てます。従来のテーマはfacet.size=1000を固定で指定しており、サーバー側の上限だけを増やしても1000件までしか取得できませんでした。

修正後はフォルダー内のURLを最大65535件要求し、Fess側のquery.facet.fields.size.maxで制限します。この設定の初期値は1000なので、テーマを更新しただけでは実際の取得上限は変わりません。ソース一覧に使うhostファセットへの要求は引き続き1000件です。

対応テーマを導入してサーバー設定を変更する

15.9.x系列では修正後のtheme.ymlが15.9.7、最低対応Fessは15.9です。main系列では15.10.4です。本体に合う系列から修正を含むテーマを用意し、管理画面の「テーマ」(/admin/theme/)で導入・既定テーマの選択を行います。テーマ番号をFess本体のリリース番号と混同しないようにします。

次にfess_config.propertiesへ、例えば次の値を設定してFessを再起動します。5000は調整例で、初期値ではありません。

query.facet.fields.size.max=5000

Dockerでは実際に読み込まれる設定ファイルやマウントを変更します。更新後に対象フォルダーを開き直し、これまで欠けていたサブフォルダー、件数表示、応答時間を確認します。これは表示用ファセットの取得範囲を変える設定なので、この修正のためだけの再クロールは不要です。

件数と負荷を一緒に確認する

取得できたURLが全件に満たない場合、件数は下限として「≥123」のように表示され、サブフォルダーが欠ける旨の注意も出ます。5000件より大きいフォルダーなら、この例の設定でも完全には表示できません。キーワードや表示中のサブフォルダーで対象を絞る方法もあります。

READMEでは65535までの調整が案内されていますが、これは無制限に取得できるという意味ではありません。OpenSearchのsearch.max_bucketsなど実環境の制約もあり、開くフォルダーごとの応答サイズとサーバー負荷が増えます。必要な件数から段階的に上げ、フォルダーの深さを増やす設定では解消しない点も確認します。

関連PR

FessのBoxクロールで初回認証の待ち時間を制限する修正案

Boxクロールが最初の接続で止まったように見えるとき、ファイル取得より前のトークン交換で待っている可能性があります。fess-ds-boxに、初回の認証通信にもタイムアウトを適用する修正が提案されています。

タイムアウトを設定する前に認証していた

従来の接続生成は、キャッシュにトークンがなければBox SDKのファクトリー内部で認証を始めます。connect_timeoutやread_timeoutの設定は、その接続が返された後でした。クロールの最初の接続では、設定値が最初のトークン交換へ届かない問題がありました。

提案では未認証の接続を作り、プロキシ、接続・読み取りタイムアウト、再試行回数を設定してからトークンを取得します。ユーザーを指定する接続にも同じ順序を適用します。

初期値は待ち時間を制限しない

両パラメーターの初期値は0で、正の値の場合だけSDKへ設定します。単位はミリ秒です。たとえば次は接続5秒、読み取り30秒という設定例です。

connect_timeout=5000
read_timeout=30000

修正案を含む対応プラグインを用意した検証環境で、データストアのパラメーターとして設定し、認証から少量の文書取得まで確認します。これは推奨初期値ではなく、回線やBox側の応答時間に合わせて調整する例です。再試行を含むジョブ全体が30秒以内に終わるという保証でもありません。

最深部の例外だけで判断しない

27では接続失敗の例外チェーンを順番に表示します。従来はSocket closedという最深部だけが見え、その途中のSocketTimeoutExceptionが隠れる場合がありました。原因が複数段あれば、途中のtimeoutも確認します。

応答が不正な場合の例外までタイムアウトとして扱う変更ではありません。たとえば認証先が必要なトークンを欠くJSONを返した場合は別の原因になります。ログの改善と待ち時間の制御を分けて確認すると、ネットワークと認証設定の切り分けがしやすくなります。

関連PR

Fessのフォームログイン制限とプロキシ越しのIP記録を確認する

Fessの通常のログインフォームにも、v2ログインAPIと同じ試行制限を適用する変更が入りました。PR #3675に加え、ログのIPを信頼済みプロキシの規則へ合わせる #3673、複数行のX-Forwarded-Forを読む #3680、SPNEGO Basicの名前表記をまとめるプラグインの #10を整理します。

フォームとAPIが同じ試行枠を使う

POST /login/loginは、POST /api/v2/auth/loginと同じLoginRateLimiterを使うようになります。IP枠は試行時、ユーザー枠は認証失敗時に使い、制限を超えるとログインエラーとして扱います。フォーム専用に新しい設定を追加するわけではありません。

設定初期値
theme.api.login.rate.limit.per.ip.per.minute10
theme.api.login.rate.limit.per.user.per.minute5
theme.api.login.lockout.seconds900
theme.api.login.rate.limit.max.entries100000

ユーザー枠は「IPとユーザー名」の組み合わせです。フォームで5回失敗すると、同じ組み合わせのv2ログインにも影響します。ログイン成功時はそのユーザーの失敗と、その試行が使ったIP枠1件分を戻し、別ユーザーへの失敗までリセットしません。以前の記事「Fessのログイン成功後もIP単位の試行制限を維持する」に対し、今回は通常フォームへ適用範囲が広がる点が違いです。

監査ログ・検索ログのIPが変わる条件

rate.limit.trusted.proxiesの初期値は127.0.0.1,::1です。修正後は監査ログのipと検索ログのclientIpも、試行制限と同じ規則でクライアントIPを求めます。信頼対象に含まれないリバースプロキシ経由では、転送ヘッダーではなくプロキシのアドレスが記録されます。

実際にFessへ接続するプロキシのアドレスを確認し、管理下のプロキシだけを信頼対象へ追加します。設定反映後は直接アクセスとプロキシ経由の両方で、ログへ記録されるIPを確認します。NATなどで複数利用者が1つのIPに見える場合、試行枠を共有することにも注意します。

X-Forwarded-Forが複数のヘッダー行で届く場合は、すべてを受信順に連結して右側から信頼関係をたどります。最初の1行だけを使う動作を直すもので、任意のクライアントが送る転送ヘッダーを無条件で信じる変更ではありません。

SPNEGOのBasicフォールバック

SPNEGOプラグインでBasicフォールバックを有効にしている場合は、alice・ALICE・alice@REALM・DOMAIN\aliceといった同一アカウントの表記を正規化し、同じ失敗枠で数えます。ドメイン接頭辞とrealm接尾辞を除き小文字にする処理で、別のアカウントの枠まで統合しません。Basicを新しく有効化する手順ではありません。

関連PR