2019.06.21：Fess 13.1.0をインストールした記事を書きました
昨年まで、Googleカスタム検索の検索窓を自社サイトに置いていたんですが、そこから検索すると、検索結果欄に競合他社の広告が出てるので、せっかくSEOとかリスティングで集めたユーザーを、よりによって競合他社にアシストするのは流石にどうなのってことで一旦、検索を無くしました。しかも、Google Site Searchが終了してしまい、GSSという選択肢は無くなってしまいました。
それで、昨年に検索サーバーを導入しようという方向性になりました。
そんな中で自分がサーバーを導入することになったのですが、経緯を簡単に説明すると
- 流石にサイト内検索がないのはユーザビリティー的によろしくない
- Fessというオープンソースソフトウェア（OSS）の全文検索サーバーがあるみたいだし、JSONで検索結果を出力できるようだ
- Windows版で検索としての動きをみて、ひとまずこれでよいのでは？
- レンタルサーバーにUbuntu版を入れて運用
- 社内のサーバーが余っているらしいから情シスに構築お願いしよう
- 情シス無理ってことで、セットアップをしている工場部隊にお願い
- 要件を伝えたらところCentOSインストールまでしかわからない
- サーバーのセットアップ、自分がするのか・・・
そんなわけで、サーバーのユーザーになることはあっても、サーバー管理者は初ということになります。以前、サーバのネットワーク設定の情報など見た際に、「サーバー管理ってめんどくさそう・・・」と思っていたもののもう腹をくくってやるしかありません。
そんな訳で、5分で簡単に構築可能な全文検索サーバーという謳い文句のOSS全文検索サーバーFessを導入するまで。
※Fess自体の導入は確かに楽ですが、自分の場合サーバー自体の知識が乏しいのでそこから説明しています。
ローカルネット上で一連の設定する
よくよく考えたら社内にあるサーバーをいじるのは、新卒で入社した会社でいじった以来、8年ぶりです。サーバールームの管轄部署以外だと、サーバールームへのアクセス（物理）が不便なので、SSHとリモートデスクトップ接続できるようにしなくちゃということで。その後、Fessのインストールとローカルネット上での動作確認としていきました。以下に流れを説明します。
リモートデスクトップ接続
以下を参照して、Windowsからリモートデスクトップ接続できるようにしました。
CentOS7にxrdpを導入しWindowsからリモートデスクトップで接続
https://qiita.com/SkyLaptor/items/56c9b5f5784f19cac225
Webサーバーの有効化（httpとhttpsの有効化）
// デフォルトで起動を許可するサービスにhttp,httpsを追加することでポートを解放
#firewall-cmd --add-service=http --permanent
#firewall-cmd --add-service=https --permanent
// firewallの設定をリロード
#firewall-cmd --reload
SSHの有効化&永続化
#firewall-cmd --add-service=ssh --permanentFessのインストール
さて、ここからが本番です。まずは、Fessのインストールです。公式サイトは、Ubuntu版と書いてありますが、CentOS 7にもインストールできるみたいなので、以下を参考にインストール。
https://kapibara-sos.net/archives/500
この中で、ファイアーウォールの8080ポートの許可をしています。
Elasticsearchの”Too many open files”エラーを解消する
さて、これでFessが動くかなと思ったら、どうも動かないので、systemctlコマンドで”systemctl status”を打って見てみると、elasticsearchが”Too many open files”というエラーが・・・
色々調べてみると、以下に近しい情報がありました。
https://www.manageengine.jp/support/kb/EventLog_Analyzer/?p=1862
どうやら、簡単に言うと「Elasticsearchは処理スピード向上の過程で、ファイルディスクリプタを大量に使うのですが、Linuxのデフォルトだと最小設定で、その上限値を越えると、”Too many open files”エラーが発生し、Elasticsearchが止まる」とのこと。
上記URLの通りに、
“/etc/security/limits.conf”
を編集し、ソフトリミットとハードリミット（ファイルディスクリプタにはソフト/ハードの2種類があるそうです）の設定を”32000″に変更しました。
* soft nofile 32000
* hard nofile 32000
再ログイン後、以下で、設定の変更が反映されているを確認。
#ulimit -n
これでFessが動く、と思ったものの、なぜかまだ”Too many open files”エラーが消えない・・・。他にも何か原因があるのかと数時間調査していたのですが、原因となりそうな情報が見つからず・・・Fessのソースファイル（Java）を見ながら解決策を探すしかないのかな（Javaなんて何年ぶりだとよ）と思っていたものの、ふとサーバーの再起動をしたら普通に反映されました・・・！
こんなことで、貴重な時間を無駄にしていたなんて・・・そう、困った時は再起動でした。今思えば、FessとElasticsearchの再起動しただけで良かったんじゃ？と思うのですが、その時はFessとかElasticsearchの再起動は試した気もしなくもなくで。
さて、これでFessも動くようになったし、クローラーを動かして検索インデックス作成です。情報が溜まって、Fessの検索結果に自社サイトのページがでてくるようになりました。
グローバルネットワーク環境に切り替え、その後サーバーが落ちる
ここまでは、イントラネットワークにて、DHCPで接続してましたが、準備も整ったし、グローバルのネットワークに切り替えました。
週末にグローバル切り替えて、週明けに見たらサーバーが落ちてました・・・！起動はできるし、しばらくはSSHなどでも接続できるので、どうやらどっかのタイミングで落ちているようでした。
“systemctl status”コマンドを見ると、Failedが2つ。
#systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● network.service loaded failed failed LSB: Bring up/down networking
● rngd.service loaded failed failed Hardware RNG Entropy Gatherer Daemon
“network.service”と”rngd.service”がおかしい模様・・・
network.servceのエラー
以下に解決方法がありました。
http://zacodesign.net/blog/?p=862
結論からいうと、ケーブルを挿してないインターフェースがautoconnect onになっていると、インターフェースを起動しようとするがケーブルに繋がってないとエラーになるってことみたいです。だからautoconnect offにしましょうってことで。
※参照先にあった、デフォルトだと/etc/init.d/のスクリプトを使うとsystemcltにリダイレクトするってことも勉強になりました。
うちのサーバーはインターフェースが4つありますが、使っているインターフェースが1つだけなので、3つのautoconnectをoffにして、インターフェースのエラーは解消。
これで解決かと思ったら、まだエラーが。
#journalctl -xeを実行すると、
（中略）
2月 12 10:42:47 localhost.localdomain network[10549]: インターフェース ens2f3 を活性化中:
2月 12 10:42:47 localhost.localdomain dhclient[10727]: dhclient(9204) is already running - exiting.
（中略）dhclient周りが怪しい。対象のインターフェースをDHCPが使っているっぽいです。ローカルネットワークでDHCP使ってましたが、グローバルネットワークに切り替えた後はDHCP使わないものの、ローカルの時のDHCPプロセスが残っちゃっているのかもしれません。
以下を見て解決。
https://qiita.com/marshmallow-sun/items/a1989a5ff1f0d93fa3e2
mgd.serviceのエラー
以下を見て解決しました。
https://www.theurbanpenguin.com/centos-7-rngd-will-not-start/
どうやら、CentOS 7では、rngdサービスはデフォルトでは起動しないらしいので、”/usr/lib/systemd/system/rngd.service”のxecStart行を変更しました。
xecStart = / sbin / rngd -f -r / dev / urandomその後、リロードが必要なので、リロードして、起動して終了です。
＃systemctl daemon-reload
＃systemctl start rngd
＃systemctl status rngd
サーバーに接続できなくなる
サーバーが落ちなくなったものの、なんか今度はしばらくすると、SSHやPingが通らなくなりました。ログを見ると、バックアップにコピーしておいた”/etc/sysconfig/network-scripts/ifcfg-eth2f3.bak”を読みにいっているみたいです。もしかして、あるファイルを全部見るとかっていう仕様なんでしょうか？
一旦、ログが再起動後に消える設定になっているので、ログの永続化をして様子見することにしました。
#mkdir /var/log/journal
#systemctl restart systemd-journald.service
#systemctl restart rsyslog.service
※/var/log/journalを作成すると、ログが消えずに残るようになります。
network.serviceも上の原因でエラーを起こしたままなので、一旦、サーバーの再起動しました。
いよいよFessだが・・・
グローバル環境に移してからネットワークの起動に関してのエラーに格闘してて、サーバーが安定するようになったので、ようやくFessです。グローバル環境で初めて、FessのURLにアクセスできない・・・
ElasticsearchやFessのクローラーのポートが空いてないのだろうか？と思って色々してみるものの、全くダメでした。ログ見てもエラーが出てないので、今度こそFessのソースコード深掘りか？（恐怖）と思っているたが、Webサーバーとしては見れていたことで、ふと、もしかして、Fessに設定しているポートがどこかでブロックされているんじゃ？と確認した所、社内から外への大元のFWでFess用のポートが遮断されているだけでした。
そりゃなにやってもだめなわけだ・・・こういうの外的要因もあるっていうのが、勉強になりました。
これでFessも見れるようになって万事準備が整いました。
Fessの検索結果がリセットされる？
なんかずっと前からですが、検索結果の数が減ったり増えたりしていて、そういう仕様なのかなと思っていたんですが、ある時見たらほとんど検索結果がなくて、焦りました。クローラーの設定が間違っているのかなと思ったりして、色々設定を変えていたんですが、よく分からず。で、色々検索していた結果、
https://news.mynavi.jp/itsearch/article/bizapp/3341
（略）3日後には収集したデータが削除されます。削除されないようにするためには、管理画面から「全般」のクローラの設定で「以前のドキュメントを削除」の値を-1日に設定してください。
とありました。「以前のドキュメントを削除」って、「以前」ってあるから「再クロールかけた際に今まであったのに見つからなかったページは3日保持するよ」というような意味かと思ってたら、インデックスデータの寿命だったんかい・・・。ってことで、-1に設定したら、ちゃんと検索結果が保持されるようになりました。今まで、増減しているなと思ったのは、インデックス作成から3日経ってしまったページが減っていたからなんですね。ちなみに、サイト規模が小さく、3日以内にクロール完了するなら、消えることはないそうなのですが、うちのサイトは1回のクロール完了に5日かかるため、消えてしまうタイミングがどうしても発生してしまうようでした。
ともあれ、これで、ちゃんとFessが使えるようになってめでたしめでたし。