質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

nginx

nginixは軽量で高性能なwebサーバーの1つです。BSD-likeライセンスのもとリリースされており、あわせてHTTPサーバ、リバースプロキシ、メールプロキシの機能も備えています。MacOSX、Windows、Linux、上で動作します。

Redis

Redisは、オープンソースのkey-valueデータストアで、NoSQLに分類されます。すべてのデータをメモリ上に保存するため、処理が極めて高速です。

Q&A

解決済

2回答

2262閲覧

redis dirおよびdbfilenameの値が勝手に書き換えられる

H.Maseda

総合スコア7

CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

nginx

nginixは軽量で高性能なwebサーバーの1つです。BSD-likeライセンスのもとリリースされており、あわせてHTTPサーバ、リバースプロキシ、メールプロキシの機能も備えています。MacOSX、Windows、Linux、上で動作します。

Redis

Redisは、オープンソースのkey-valueデータストアで、NoSQLに分類されます。すべてのデータをメモリ上に保存するため、処理が極めて高速です。

0グッド

0クリップ

投稿2018/02/13 04:23

編集2018/02/19 09:42

前提・実現したいこと

複数のウェブサーバ(CentOS7, nginx使用)で負荷分散およびセッション同期を
実現したいと考えています。

発生している問題・エラーメッセージ

redisを使用してセッション同期をしていますが、頻繁に同期が取れなくなります。
/var/log/redis/redis.logには以下のようなエラーが表示されます。(タイムスタンプ等省略)

10 changes in 300 seconds. Saving...
Background saving started by pid xxxxx
Failed opening the RDB file root (in server root dir /etc/cron.d) for saving: Permission denied
Background saving error

このログの例では
dir:/var/lib/redis→/etc/cron.d
dbfilename:dump.rdb→root
に書き換えられています。書き換えられる値は上記に限りませんが
dirがroot権限のディレクトリに書き換えられてしまうとredis ID
がRDBファイルを書き込めなくなりこのエラーになっているようです。

該当のソースコード

ソースコード

試したこと

現状ではredis-cliコマンドを使用してdirおよびdbfilenameの
値が/var/lib/redisおよびdump.rdb以外に書き換えられていたら
デフォルトに戻すツールを作成し、crontabで5分毎に実行する
ということで、エラーを抑止しています。
なぜこのような状況が発生し、どうすれば解決できるのか
ご教授いただけないかと考えます。
よろしくお願いいたします。

補足情報(FW/ツールのバージョンなど)

redis.confの修正について(マスター、スレーブ×1)

bind 127.0.0.1→#bind 127.0.0.1
protected-mode yes→protected-mode no
timeout 0→timeout 60
tcp-keepalive 300→tcp-keepalived 0
stop-writes-on-bgsave-error yes→stop-writes-on-bgsave-error no
↑変更した記憶がないのでredisが自分で変更したのではないかと(かつ2台中マスター側のみ)
slave-read-only yes→slave-read-only no
slaveof (スレーブ側のみ)

redis-sentinel.confの設定について(redisとは別サーバ×1)

protected-mode no
daemonize no
sentinel monitor redis_www_session (マスターIP) 6379 1
sentinel down-after-milliseconds redis_www_session 3000

Generated by CONFIG REWRITE

sentinel failover-timeout redis_www_session 90000
sentinel known-slave redis_www_session (スレーブIP) 6379

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

hichon

2018/02/13 12:45

redisはどのようにインストールして、どのように起動していますでしょうか?
H.Maseda

2018/02/14 00:37

redisはyumでインストールしており、redis-3.2.10-2.el7.x86_64になります。systemctl enable redisでサーバ起動時に起動しています。
H.Maseda

2018/02/14 05:05

どのように起動と言われるのがdaemonizeのことだとしたらdaemonize noで起動しています。
hichon

2018/02/14 08:25

redis-serverを引数無しで起動すると、redis.confが読み込まれず、dump.rdsの保存先がカレントディレクトリになりますが、そういう処理が何処かで行われていませんか?
H.Maseda

2018/02/14 08:51

redis-server起動時の引数の有無は分かりませんが、ps -ef | grep redisの結果が/usr/bin/redis-server *:6379となっているので、引数有ではないかと思います。
H.Maseda

2018/02/16 08:33

/usr/lib/systemd/system/redis.serviceを参照したところExecStart=/usr/bin/redis-server /etc/redis.conf --daemonize noとありましたのでredis.confは読み込まれていると考えます。
guest

回答2

0

ベストアンサー

redis はネットに公開された場所で稼働されてますか?
(ウェブサーバと同じサーバとか)

補足に bind 127.0.0.1→#bind 127.0.0.1 とあるので、気になりました。

bind は redis に接続できるサーバのIP(ローカルIP)を指定するものです。

コメントアウトしてしまうと全解放となるので、もしネット公開されていれば
どこのサーバからでも接続でき、データ取得・更新、停止・再起動までできてしまいます。

危険です。

https://github.com/kurosawatsuyoshi/doshelper/wiki/1.-redis-Setup%EF%BC%88redis%E3%81%AE%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%EF%BC%89
の Appendix に記載した crackit/crack@redis.io をみてもらえばわかると思います。

redis-cli で config get bind と打ったらどうなりますか?

もし閉じた環境であったり、 iptables で制御していれば大丈夫です。

ただ、、、 dir とか dnfilename は勝手に変わらないので誰かが外から変更しているように見えますね。

投稿2018/03/14 12:28

kurosawa

総合スコア780

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

H.Maseda

2018/03/15 00:35

回答ありがとうございました。 たまたま昨日redisのポートがローカルIPだけでなくグローバルIPにも 開放されていることに気づいて、ローカルIP専用のゾーンを作成し ゾーン内のみ開放するよう設定変更したところでした。 kurosawa様の回答でこの設定変更で正しいという確証が得られました。 あらためてありがとうございました。
kurosawa

2018/03/15 07:55

原因がわかって良かったです。 ただ、これまで外部公開されていたということになると イタズラや攻撃目的でサーバに侵入されていないか確認したほうが良いです 私が実際に redis を利用して攻撃されました。 (それが紹介した記事です) redisのDirやdbfilenameを ssh 鍵の内容とパスに変更され、save コマンドでファイルを作成して shutdown されてました。 管理者の私はredisが落ちたことに気づき再起動させますが、この段階では redisは設定ファイルからDirとdbfilenameを読み込むので、変更されてファイル作成されたことに気づきません。(たまたま再起動前に気づいたので即除去しました) 今回は root というファイルを cron.d にセットする過程に見えます。 既に外部から怪しい実行ファイルが配置され、それを定期的にキックしようと試みていたが、たまたま redis を起動しているユーザが root じゃなかったため配置に失敗していただけ。という見方もできます。 念のため、以下を確認したほうが良いです ・不明なOSユーザが登録してないか ・全員のsshキーが改ざんされていないか ・Redisのキー&バリューに変な値がないか(16個のDBすべて) 私ならパスワードの全変更とログ調査に取り掛かります
guest

0

めちゃくちゃ助かった。ありがとう。

投稿2019/09/09 23:55

ma7ma7pipipi

総合スコア85

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問