Fess CrawlerのHttpClient 5でSOCKS5プロキシを設定する

Fess CrawlerのHTTPクライアントに、SOCKS5プロキシを指定する機能が追加されました。対象はHc5HttpClientです。

ホストとポートを両方指定する

初期状態ではsocksProxyHostもsocksProxyPortも未設定で、SOCKSプロキシを使いません。両方を設定した場合だけ、接続マネージャーにSOCKSプロキシを渡します。ポートだけの指定では有効にならず、1080などが自動補完されるわけでもありません。

Hc5HttpClientを直接生成・設定するJavaアプリケーションでは、初期化前に次のように指定します。1080は例で、実際のプロキシの待受ポートへ変更します。

Hc5HttpClient client = new Hc5HttpClient();
client.setSocksProxyHost("proxy.internal.example");
client.setSocksProxyPort(1080);
// この後、アプリケーション側の通常の初期化・実行処理を行う

初期化パラメーターマップを使う場合のキーもsocksProxyHostとsocksProxyPortです。HTTPプロキシのproxyHost・proxyPortとは別の指定です。Fess管理画面にSOCKS専用入力欄を追加するPRではないため、画面にこの名前を入力すればそのまま使えるとは判断しません。Fessへ組み込む場合は、実際にHc5HttpClientが選ばれ、パラメーターが渡る構成かを確認します。

認証と名前解決の制限

SOCKS認証には対応していません。また、宛先ホスト名はクローラー側で解決し、プロキシへはIPアドレスを渡します。プロキシ側だけが社内ホスト名を解決できる構成や、リモートDNSを前提とする接続では、この設定だけでは届きません。

Hc4HttpClientの動作は変わりません。導入時は小さなHTTP取得でプロキシを通ること、SOCKSを未設定に戻した場合の経路、クローラー環境からのDNS解決を確認します。PRでは組み込みSOCKS5サーバーを使った中継テストが報告されていますが、本記事では実環境のFessクロールを検証したとはしていません。

関連PR

Fessのファイルクロールで親へ戻るシンボリックリンクを避ける

ファイルクロールで、同じファイルが長いパスを伴って何度も登録されることがあります。sub/up -> ..のように、子ディレクトリのシンボリックリンクが親へ戻る場合の巡回を避ける修正が、Fess Crawlerへマージされました。

file:のパスが長くなり続ける場合

従来はfile:でディレクトリを一覧すると、リンク経由で同じ木構造へ戻り、sub/up/a.txt、sub/up/sub/up/a.txtのように別URLとして取得を繰り返す場合がありました。深さの上限で止まっても、同じ内容が多数登録されます。

修正では子要素が「ディレクトリへのシンボリックリンク」であるとき、実パスを確認します。現在のディレクトリ自身や実際の親へ戻るリンク、URL上で既に通過したディレクトリへ戻るリンクを、次の取得対象から除外します。a/x -> bとb/y -> aのような相互リンクも対象です。

シンボリックリンクをすべて禁止する変更ではない

FileSystemClientのfollowSymlinkは初期値trueで、既存の指定方法は変わりません。新しい設定項目もありません。通常ファイル、別の場所を指すリンク、壊れたリンクの一覧処理は従来の扱いを維持します。

followSymlink=falseは従来どおりリンクをたどらないための指定ですが、今回の修正は、リンクを利用する構成で特定の循環を除外するものです。このプロパティはCrawlerの初期化パラメーターで、同じ名前のFess全体プロパティが新設されたわけではありません。SMBなど別クライアントの動作を一律に変えるものでもありません。

既存の重複は別途確認する

修正はこれから列挙するURLを抑えます。既にインデックスへ登録された重複文書を自動で削除する機能ではありません。

対象ディレクトリのリンク先を確認し、修正入りのCrawlerを含む環境で小さな範囲を再クロールします。ログのSkipped a symbolic link that leads back to a parent directoryと、繰り返しパスが増えなくなったことを確認してから、古い文書の整理を検討します。実パスの解決に失敗した場合もあるため、深さや対象範囲の既存の制限も引き続き必要です。

関連PR

Fessの文書IDによる取得にも仮想ホストの範囲を適用する

1つのFessで複数の仮想ホストを使うとき、検索結果だけでなく、文書IDを指定して取り出す経路も確認しておきたいところです。文書IDによる取得に、通常検索と同じ仮想ホストの条件を加える修正がマージされました。

ロールが同じでも仮想ホストが違う場合

従来のgetDocumentByDocIdとgetDocumentListByDocIdsはロールの条件を適用していましたが、仮想ホストの条件がありませんでした。利用者のロールが一致すると、別の仮想ホストに属する文書をID経由で取得できる場合がありました。

修正は、v2のキャッシュAPI、/go/による転送、サムネイル、お気に入りなどで使う共通の文書取得処理に条件を加えます。対象文書の仮想ホストが現在のリクエストと違えば、取得処理は文書を返しません。各エンドポイントの応答形式はそれぞれの実装に従います。

有効になる条件と例外

新しいオン・オフ設定は追加されません。リクエストから仮想ホストのキーが解決された場合、そのキーと文書のvirtual_hostフィールドを照合します。キーが設定されたリクエストでは、仮想ホストの値を持たない文書も通常検索と同様に対象外です。

初期設定のindex.field.virtual_hostはvirtual_hostで、virtual.host.headersは空です。ただし、この値だけでリクエストにキーが付くわけではありません。既存の仮想ホスト設定と、実際に解決されるキーを確認してください。

キーが解決されないデフォルトホストやリクエストのないバックグラウンド処理には、この条件は加わりません。管理者検索の一覧取得も対象外です。この変更を、すべての経路を無条件に分離する仕組みとして扱うことはできません。

更新前後で試したいこと

同じ検索ロールの利用者を使い、ホストAの文書がAの通常検索とキャッシュで表示されること、ホストBから同じIDを使った取得では返らないことを確認します。仮想ホスト未設定の文書と、管理者検索も別に試します。

通常検索の条件を共通の取得処理へそろえる修正なので、文書を登録し直すこと自体は変更の必須条件ではありません。ただし、既存文書の仮想ホスト値が誤っている場合は、元のクロール設定と再登録を含めて修正します。ユーザータグの仮想ホスト別管理とは別の変更です。

関連PR