利用環境：
fess: 14.18（docker版、docker-composeによる起動、ホストはRHEL9.4）
別環境で動かしているNFSサーバでexportされているファイルシステム「/export/nfs」配下に格納されているファイルをFess上でクロールし、検索結果に表示させたいと考えています。
この場合、fessを稼働させているdockerコンテナでNFSクライアントに必要なパッケージ等をダウンロードしたうえで、任意のディレクトリにマウントさせ、そのパスをファイルシステムのクロール設定で「file:/マウントしたディレクトリへのパス/」を指定すればクロール可能でしょうか？
ホスト側でNFSマウントしておいて、Dockerコンテナはホストのマウントしたディレクトリをマウントすれば良いと思います。
ご教授ありがとうございます。
ホスト側でNFSマウントして、Dockerコンテナはホストのマウントしたディレクトリをマウントし、Fessのファイルクロールで検索結果に各ファイル名と中身の文章が表示されるようにはなりました。
しかし、ファイル名のリンクをクリックしてもそのファイルがダウンロードされず、何も起こりません。
ファイルクロールしたファイルのダウンロードまでを行えるようにしたいのですが、何か設定等必要でしょうか。
Fessでなく、ブラウザの仕様として、file://のリンクは機能しないので、Fessのコンテンツプロキシー機能を使ったりしないとファイルは取得できないと思います。
ありがとうございます。
てっきり私はファイルシステムをクロールした際には、そのファイルをFESS自身でダウンロードしているものかと思っていましたが、そういう訳ではないという認識でよろしいでしょうか。
私の場合は、FESSが起動しているdockerコンテナにマウントしているファイルサーバのファイルをクロール対象としております。
しかし、検索結果を参照したりファイルをダウンロードしたいクライアントは、FESS稼働&ファイルサーバをマウントしているdockerとは別の端末からFESSにアクセスしています。
そうなると、FESSの検索画面にアクセスしてコンテンツプロキシー機能を無効化したとて、ファイルパスはdocker上でのパスに相当するため、ファイルのダウンロードは実現できないでしょうか？
ファイルシステムをクロールした際には、そのファイルをFESS自身でダウンロードしているものかと思っていました
クロール時：Fessが直接ファイルを参照してインデクシング
検索時（コンテンツプロキシーあり）：Fessがファイルを取得して、検索者に渡してダウンロード
検索時（コンテンツプロキシーなし）：検索者がファイルにダウンロード
みたいな感じです。
そして、ブラウザの仕様として、http:// の検索結果ページ上でfile:// のリンクは機能しません。
なので、コンテンツプロキシーを使わない場合、file:// からは取得できないので、WebDAVとかで参照できるようにして、パスマッピングで書き換えて対応したり、別な手段が必要です。file://が使えないのを認識している利用者では、リンクをコピペして開くからOKみたいな人もいるので、検索結果画面にコピペ用リンクがあったりします。
この辺の話を踏まえて、シンプルな対応手段として、Fessではコンテンツプロキシー機能をデフォルトで提供しています。
ご教授ありがとうございます。
私の理解力がなく大変恐縮なのですが、改めて確認させてください。
「コンテンツプロキシー機能を有効（デフォルト）にすれば、検索時にはFessが代わりにファイルを取得してくれて、file://〜というリンクで検索一覧に表示される」と理解しましたが、
このFessが取得したファイルを検索者がダウンロードする手段は、リンクをコピーしてブラウザの検索窓にコピペしてダウンロードするしかないという理解でよろしいでしょうか？
すなわち、コンテンツプロキシー機能をデフォルトの有効にしてようが、無効にしてようが、FESSの検索一覧でファイル名を押しただけでファイルがダウンロードされるという実装は既存機能ではブラウザの仕様で不可。という認識で間違いないでしょうか？
クロール時の話と検索時の話は分けて考える必要がありますが、
コンテンツプロキシー機能を有効（デフォルト）にすれば、検索時にはFessが代わりにファイルを取得してくれて、file://〜というリンクで検索一覧に表示される
「コンテンツプロキシー機能を有効（デフォルト）にすれば、検索時にfile://のデータをFessが代わりにファイルを取得して、ダウンロードできる」であって、「file://〜というリンクで検索一覧に表示される」は関係ありません。コンテンツプロキシー機能に関係なく、クロール時にはfile://を取得して、検索結果に表示されるようにインデクシングされます。
このFessが取得したファイルを検索者がダウンロードする手段は、リンクをコピーしてブラウザの検索窓にコピペしてダウンロードする
Fessがコンテンツプロキシー機能で取得してダウンロードする話と、コピペリンクの話は関係ないです。コピペリンクは、ブラウザでfile://を開くことができないので、リンクのコピペアイコンをクリックして、file://のURLが取得できるので、それをエクスプローラーとかに貼り付けて、開くみたいな運用です。
コンテンツプロキシー機能を有効にしていれば、検索結果をクリックしたときにFessサーバーにアクセスして、対象のファイルをダウンロードできます。Fessの標準の検索画面を利用していれば、そのような動きになります。
コンテンツプロキシー機能を有効にしていれば、検索結果をクリックしたときにFessサーバーにアクセスして、対象のファイルをダウンロードできます。Fessの標準の検索画面を利用していれば、そのような動きになります。
→承知しました。現在の私は「コンテンツプロキシー機能が有効なはずなのに、検索結果をクリックしても対象のファイルをダウンロードできていない」という課題に直面していると認識しました。
度々の確認で恐縮ですが、検索者の環境はFessをインストールしているローカル環境（私の場合はdocker環境）と違うところからFessのWeb画面にアクセスしていても、ファイルをダウンロードできるはず（→なぜならば、対象のファイルはFessサーバが取得しているから）という認識でよろしいでしょうか。
クロールできていて検索できる状態であれば、コンテンツプロキシー機能で検索結果画面からファイルをダウンロードできると思います。
承知いたしました。
Fessでファイルが取得されたかどうかを確認したいのですが、Fessが取得したファイルはFessの環境（私の場合はdocker版ですが）においてどのディレクトリに保存される等決まっておりますでしょうか？
オープンソースなので、デバッグログなどにして、処理内容を確認してください。検索時にFessがファイルを取得する際にファイルを保有はしていません。
検索時にFessがファイルを取得する際に、ファイルを保有しているわけではない旨、承知いたしました。
となると、私の場合はFessを稼働させ、対象のファイルシステムをマウントしているサーバとは違う端末のブラウザからFessの検索画面を参照していますので、コンテンツプロキシー機能有効無効に関わらず、検索画面に表示されるリンクからではダウンロードできない認識です。（file://だとローカルにファイルがないとアクセスできない思うので。）
すなわち、ファイルクロールで検索画面から対象ファイルをダウンロードしようと思えば、
・Fessの稼働環境
・NFSファイルシステムをマウントする環境
・Fessの検索ユーザがブラウザアクセスする環境
以上の環境が全て同一環境（同じサーバ）でなければならないということでしょうか？
まだ認識が異なります。その環境だとしても、Fessがクロールしてインデックスできて、コンテンツプロキシーが有効であれば、検索結果に表示されたファイルをダウンロードすることはできます。検索結果の見た目上のURLがfile://だとしても、クリックした瞬間にFessのURLに書き換えているので、Fessがコンテンツプロキシーでファイルを返してくれます。
クロール後にアンマウントして、Fessから参照できなくするなど、特殊なことをしていれば、コンテンツプロキシーで取得はできないとは思いますが…。
反応が遅くなりまして申し訳ございません、ご教授ありがとうございます。
FESSサーバ（NFSクライアント）とFessアクセスユーザが同一環境ではなくても、コンテンツプロキシー機能が有効化されていて、特殊な設定を組んでない限りはファイルのダウンロードができる旨、承知いたしました。
何が原因でファイル取得ができないのか、引き続き検討してみます。
© 2020. All Rights Reserved - CodeLibs, Inc.