なくてもなんとかなるけど、あると便利な「全文検索」機能。私のようなズボラ者にはピッタリの機能です。これから紹介するFessはパソコン（クライアントPC）にももちろん入れられますが、主にファイル共有サーバーでの利用方法を紹介します。
このページの目次
共有サーバーのどこに保存したか分からないファイルを一発検索
それならクライアントPCのエクスプローラーで共有サーバーを検索でしょ～と思った方、「全文検索」です。英語で言うと「Full Text Search」、つまりファイル名だけじゃなくて、ファイルの中身までも検索してくれます。もちろんファイル名で検索することも出来るようですよ。検索キーワードの前に、検索条件として「title:」と書きましょう。
5分で構築できる出来ると豪語している！
公式サイトhttp://fess.codelibs.org/ja/ のトップに記載されていますね。
実際私のケースではどうだったのか。そうですね、2時間くらいはかかってたと思います。遅い？いや事前調査から実際のインストール作業、動作確認まで入れたらそんなもんじゃないですかね。そんなこと無いかな・・・遅くてすみません！！
FessはJAVAベースのプログラムです
そのためOSによらず、JAVAのJDKバージョンが用件を満たしていれ動作します。ただ個人的にはJAVA、あまりいい思い出がありません。「JAVAですか～。TOMCATですか～。あんまりうしくないな。」と思ってしまったことも事実です。すみません。
最新版は10.2系みたいですが、あえて9.4を選択
もちろん最新版を使ってみたかったのですが、導入条件を見るとJAVA8が必要とあります。さて私のサーバーはCentOS5.3、安全安心なyumで更新できるバージョンは・・とチェックすると。
#yum list \*java-1\* | grep open
java-1.7.0-openjdk.i386 1:1.7.0.111-2.6.7.1.el5_11 updates
java-1.7.0-openjdk-devel.i386 1:1.7.0.111-2.6.7.1.el5_11 updates
java-1.6.0-openjdk.i386 1:1.6.0.40-1.13.12.4.el5_11 updates
java-1.6.0-openjdk-demo.i386 1:1.6.0.40-1.13.12.4.el5_11 updates
java-1.6.0-openjdk-devel.i386 1:1.6.0.40-1.13.12.4.el5_11 updates
java-1.6.0-openjdk-javadoc.i386 1:1.6.0.40-1.13.12.4.el5_11 updates
java-1.6.0-openjdk-src.i386 1:1.6.0.40-1.13.12.4.el5_11 updates
java-1.7.0-openjdk-demo.i386 1:1.7.0.111-2.6.7.1.el5_11 updates
java-1.7.0-openjdk-javadoc.i386 1:1.7.0.111-2.6.7.1.el5_11 updates
java-1.7.0-openjdk-src.i386 1:1.7.0.111-2.6.7.1.el5_11 updates
JAVA8系がありません。どうしよっかな～と暫く悩みましたが、お試しが目的なのに余計な作業をするのを避け、ここはJAVA7を選ぶことにします。ということで、まずはjava-1.7.0-openjdk-devel.i386をインストール。
仕方なくバージョンを下げたJAVA7で使える最新のFessのバージョンは～と探すとFess9.4が対応していました。
ダウンロードはこちら https://ja.osdn.net/projects/fess/releases/
インストール手順はこちら http://fess.codelibs.org/ja/archives.html#id4
確かにこの作業自体はあっという間に終わりました。
ポート番号の変更
ポート8080がデフォルトでのアクセスポートとなるのですが、PROXYサーバーとして使用してしまっています。そこで以下の手順に従って8088に変更しました。
ポート変更手順：http://fess.codelibs.org/ja/9.4/config/server-port.html
このあと、起動シェル(bin/startup.sh)を実行し、問題なく起動。
サーバー名：8088/fess/admin/で管理画面にアクセス、ログイン出来ました。
管理画面からクロール対象のファイルを指定
詳しくは設定資料を見ればわかると思いますが、クロール対象（インデックス作成対象）のディレクトリをGUI管理画面から指定します。
私はsambaで管理しているフォルダを対象にしたかったので、以下のように書きました。
file:/home/samba-data/
NAMAZUの呪いか？？
管理画面の「今すぐクロールしますか？」の問いかけに応じ、すぐにクロール開始すると、CPU負荷が100%近くに・・・「ああ、いっぺん大量にインデックスしようとしたのが、いけないのかなと」と一旦停止。
比較的ドキュメントの少ないディレクトリを指定し、クロール開始しても、やっぱり100%。嫌な予感が頭をよぎります。やっぱりJAVAと私は、相性悪いのか。そのとき思いついたのです、これは「ひょっとしてNAMAZUの呪いか？」と。
EUC-JPをファイル名で使っていると駄目なようです。
SAMBAのデータはNAMAZUと相性よくするためにEUC-JPでファイル名を指定していましたが、CPU100%現象は、どうもこれが理由のようです。以下のスクリプトを使ってUTF8に変換し、再度クロールしてみると今度は100%負荷になることなく終了。ある意味NAMAZUがらみでしたが、根本的には文字コードEUC-JPをファイル名で使っていると出る症状ということで理解しました。
文字コードをマウントする際に調整する
現在のディレクトリ以下のフォルダ/ファイル名でEUC-JPのものを全てUTF8に変換
convmv -r -f euc-jp -t utf8 * –notest
検索結果からファイルを開く：IE11/ChromeはOK、EdgeとFirefoxはうーん？
これが9.4の限界なのかもしれませんが、検索結果のリンクをクリックするとIE11/Chromeでは読み取り専用ですがWORD/Excelファイルなども普通に開くことが出来ました。保存することも出来ます。EdgeとFirefoxは表示できるのですが、何か変になってますね。とりあえず試用なので深くは追求しませんが、ブラウザによっては直接リンクは使えないということのようですね。
最新の10.2ならもっと便利になっているのかもしれない
一通り体験してみて確かにNAMAZUを始めて設置したときよりははるかに簡単に作業を終えることが出来ました。しかし、まだドキュメントを読み込んでいないので、どの程度のことが出来るのかわかりませんが、sambaとの連携とかをやろうと思ったときに楽なのかどうかが不明ですので、このあたりを踏み込めたら、更新記事を書こうと思います。
smb://host1/share/
みたいな感じで書くみたいなんですけどね。上記の通りテストサーバーのsambaがEUC-JPなのでまた今度にします。