Ubuntu: lsyncd によるディレクトリのリアルタイム同期（追記あり）

目標

• Ubuntu 16.04 Server がインストールされた 2 台のサーバー host1 と host2 がある。
• host1 と host2 の間で /home/foo/share ディレクトリの内容を常に同期する。
• 一般ユーザー（root 以外のユーザー）で rsync コマンドを実行する。

準備作業

RSA鍵ペアの作成

foo ユーザーで host1 と host2 に ssh でログインし、それぞれ次のコマンドを実行する。

$ ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa.rsync

RSA鍵公開鍵を設置

• host1 の ~/.ssh/id_rsa.rsync.pub の中身を host2 の ~/.ssh/authorized_keys の末尾に貼り付ける。
• host2 の ~/.ssh/id_rsa.rsync.pub の中身を host1 の ~/.ssh/authorized_keys の末尾に貼り付ける。

注意: ~/.ssh のパーミッションが 700 であり、~/.ssh/authorized_keys のパーミッションが 400 または 600 であることを確認すること。

接続確認

$ ssh -i ~/.ssh/id_rsa.rsync host2 # host1 から
$ ssh -i ~/.ssh/id_rsa.rsync host1 # host2 から

rsync コマンドの動作確認

host1 で次のコマンドを群を実行する。

$ mkdir ~/share
$ echo TEST ~/share/test.txt
$ rsync -av -e ssh ~/share/ foo@host2:/home/foo/share

~/share/ の末尾のスラッシュ（/）は必須である。

host2 の /home/foo/share ディレクトリに test.txt というファイルができていればOK。

lsyncd のセットアップ

ソフトウェアのインストール

$ sudo apt-get install -y lsyncd

設定ファイルの作成

/etc/lsyncd/lsyncd.conf.lua を作成。

settings {
        logfile    = "/var/log/lsyncd.log",
        statusFile = "/tmp/lsyncd.stat",
        delay        = 1
}

sync {
        default.rsync,
        source="/home/foo/share/",
        target="foo@host2:/home/foo/share/",
        delete=false,
        rsync = {
          rsh = "/usr/bin/ssh -i /home/foo/.ssh/id_rsa.rsync -o UserKnownHostsFile=/home/foo/.ssh/known_hosts"
        }
}

注意事項:

• delay の値（デフォルト: 15）は、ファイル更新イベント発生から rsync 実行までの遅延時間（秒単位）である。リアルタイム性を追求するなら値は小さいほうがよいが、ファイル更新イベントが頻発するサーバーでこの値を小さくし過ぎると、かえって更新に時間がかかるかもしれない。
• source の末尾のスラッシュ（/）は必須である。
• host2 側の lsyncd.conf.lua では、target の値を "foo@host1:/home/foo/share/" とする。
• delete=false については本稿末尾の「備考」を参照。
• -o UserKnownHostsFile-... の記述を省略すると、Host Key Verification Failed というエラーが発生する。

lsyncd の起動

lsyncd を起動。

$ sudo systemctl restart lsyncd

動作確認

• host1 の /home/foo/shared ディレクトリに新しいファイルを追加し、host2 の /home/foo/shared ディレクトリにそのファイルが転送されることを確認。
• host2 の /home/foo/shared ディレクトリに新しいファイルを追加し、host1 の /home/foo/shared ディレクトリにそのファイルが転送されることを確認。

うまく行かない場合は、/var/log/lsyncd.log を見て調べる。

備考

本稿で使用した lsyncd の設定では delete=false オプションを使用しているため、host1 または host2 でファイルが削除されても、もう一方の側でそのファイルは削除されない。

ファイルが削除される可能性のある環境で lsyncd による「双方向同期」を使用する場合の注意点については、lsyncdで双方向同期するなら、delete='running' がいいを参照せよ。

---

追記

「備考」で触れたが、lsyncd で双方向同期を行う場合、ファイル削除の扱いが難しい。

host1 がダウンしている間に host2 に追加されたファイル X があるとき、host1 の再起動時に X が削除される可能性がある、ということだ。

この問題を回避するため、参照したブログ記事では「lsyncd の起動時にファイルの同期をしない（delete="running"）」という設定を勧めている。

しかし、そもそもなぜファイルを削除するのかを考えると、この回避策でよいだろうか。

host1 がダウンしている間に host2 でファイル Y が削除されたとする。「lsyncd の起動時にファイルの同期をしない」設定の場合、host1 の再起動後も host1 上でファイル Y が残り続けることになる。

おそらく、ファイル Y を削除する目的は、ディスクスペースの節約かファイル Y の内容を残したくない（内容がまずい）かのどちらかだろう。

つまり、「lsyncd の起動時にファイルの同期をしない」設定では、この目的が達成されない。

とすれば、正しい回避策は、「lsyncd の起動時にファイルの同期をするが、ファイルの削除はしない（delete=false）」設定にしておいて、ファイル Y を削除したいときにはファイル Y を空にする（ファイルサイズを 0 にする）運用をすることではないだろうか。これならば、host1 が復活したときに、host1 上のファイル Y が消える。

ちなみに、サイズが 0 のファイルも一定のディスクスペースを占めるし、あまりに数が多いと「inode枯渇」という別の問題を引き起こす。

だから、ファイル削除が頻繁に行われる環境では、サイズが 0 のファイルを削除する仕組みを別途考えたほうがいいだろう。

例えば、毎朝 4:01 に host1 と host2 の両方が動いていることを確かめた上で、4:00 以前に書き換えられたサイズ 0 のファイルをすべて削除するような処理を cron にやらせればいい。

なお、この「追記」の内容は筆者が頭の中で考えたことに過ぎず、実績があるわけではない。参考にされる方は、この点に留意していただきたい。

Ubuntu: init system を systemd から upstart に変える

Ubuntu 16.04 がインストールされている私の職場PCがハードディスクの故障で動かなくなり、修復のためにいろいろやっている過程で、

• ブート時のメニューで「Ubuntu」を選んでも起動しない。
• 「Advanced options for Ubuntu」を選んでから「upstart」という文字を含むエントリーを選ぶと起動する。

という現象に遭遇した。init system を systemd から upstart に変えればよさそうだ。

GRUBのメニューを自分で書き換えればいいのかなと思ったが、正しい手順は以下の通りであった。

sudo apt-get install upstart-sysv
sudo update-initramfs -u

参考資料:

• https://askubuntu.com/questions/582200/revert-to-upstart
• https://wiki.ubuntu.com/SystemdForUpstartUsers

PostgreSQL: キャッシュした計画は結果型を変更してはなりません

PostgreSQL を用いた Rails アプリケーション開発で

キャッシュした計画は結果型を変更してはなりません

あるいは

cached plan must not change result type

というエラーメッセージに遭遇することがある。

解決法は簡単で、Rails サーバーを再起動すればよい。

なぜこのエラーが出るのか知りたい方は、Qiitaの次の記事を読むとよい。

cached plan must not change result type なんてエラーが出たら

簡単に言えば、Rails サーバーを起動したままマイグレーションを実行すると、この現象が出る。

Phusion Passenger: permission denied で ruby を実行できない問題

問題

Rails あるいは Sinatra を Phusion Passenger で動かしている状況で、permission denied により ruby を実行できない。

解決策 (1)

Rails なら config/environment.rb、Sinatra なら config.ru の持ち主が ruby を実行できるユーザーかどうかを確認し、そうでなければ直す。

デフォルトで Phusion Passengerはこのユーザーとして起動する。ただし root ユーザーが持ち主の場合は nobody ユーザーで動く。

解決策(2)

ps auwx | grep Passenger で Phusion Passenger の実行ユーザーを調べて、そのユーザーが ruby を実行できるようにする。

例えば、そのユーザーが apache で、ruby が /home/app/.rbenv ディレクトリの下にあり、/home/app の user:group が app:app なら、sudo gpasswd -a apache app で apache を app グループに追加する。また、chmod g+rx /home/app も実行する。

解決策 (3)

PhusionPassenger の設定ファイルで PassengerUser を設定する。

Rails: send_data/send_file でデータの中身がテキストとして表示される問題

問題

次のようなRailsのアクションにより files/example.pdf の中身をユーザーにダウンロードさせたい。

class FilesController < ApplicationController
  def show
    filename = 'example.pdf'
    path = Rails.root.join('files', filename)
    send_file(path, type: 'application/pdf', filename: filename)
  end
end

しかし、ブラウザでこのアクションにアクセスするとファイルの中身がテキストとして表示される。

解決法

<a> タグに data-turbolinks="false" 属性を付ける。例えば、

<%= link_to "example.pdf", file_path %>

を

<%= link_to "example.pdf", file_path, 
  data: { turbolinks: false } %>

に変える。

参考資料

• https://stackoverflow.com/questions/14818015/rails-wont-send-data-as-file

OmniAuth: ロードバランサ配下での redirect_uri_mismatch 問題

問題

最近、OmniAuthを使ってGithub経由でのユーザー認証機能を既存のRailsアプリに組み込んだ。

その際、開発環境ではすんなり動いたのだが、本番環境にデプロイすると redirect_uri_mismatch エラーが出てしまう。

解決法

config/initializers/omniauth.rb に次のような記述を追加する。

if Rails.env.production?
  OmniAuth.config.full_host = "https://example.com"
end

原因

本番環境のRailsアプリがロードバランサ（Nginx）配下で動いていたためであった。OmniAuth は request.url が返す文字列を使って、redirect_url を作る。例えば、https://example.com/shopping_cart なら https://example.com/auth/github/callback になる。

しかし、私の環境では Nginx が https を http に置き換えていたため、s のない http://example.com/auth/github/callback がredirect_url となり、Github の「Authorization callback URL」に登録してあった URL と食い違ってしまうのである。

参考資料

• Dealing With Omniauth Redirect_uri_mismatch (Invalid Port Number Gotcha)

Ruby: case 式における何もしない else の扱い

先週末に WEB+DB PRESS Vol.99の「良いコード」を本気でコードレビューしてみた という興味深いブログ記事が書かれました。

はてなブックマークでのコメントを見ると、多くの人がブログ記事の内容に賛同しているようですが、「P12: 何もしないelseは必要か？」の節には異論が散見されました。

---

ブログ記事全体の趣旨は、WEB+DB PRESS Vol.99の「Rubyで学ぶ！良いコードって何だろう？」という特集記事への批判です。

特集記事では、次のような例が掲載されていて、

case hour
when 9
  say_hello()
when 18
  say_goodbye()
end

これは意図が伝わりにくいから、次のように空の else 節を加えるべしと書かれています。

case hour
when 9
  say_hello()
when 18
  say_goodbye()
else
  # 何もしなくてよい
end

これに対して、ブログ記事の筆者（伊藤氏）は空の else 節は不要だと主張しています。

---

プログラミング初心者が else 節を書き忘れる可能性を考えると、このケースでは空の else 節を書いたほうが親切かなと私は思います。

しかし、まったく空の else 節が残ることに「座りの悪さ」を感じるのも確かです。

はてなブックマークのコメントで知ったのですが、Python には「何もしない」 pass 文というのがあるそうですね。

これが使えればいいのですが、残念ながら Ruby には存在しません。

---

特集記事があげている例があまりよくなかったのかもしれません。関数 say_hello と say_goodbye の中身まで含めたリファクタリングを検討すべき場面じゃないでしょうか。

おそらく、ソースコード全体はこんな感じです。

def say_hello
  puts "Hello!"
end

def say_goodbye
  puts "Good bye!"
end

hour = Time.now.hour

case hour
when 9
  say_hello()
when 18
  say_goodbye()
end

であるとすれば、まずこう書き換えるべきです。

def say(message)
  puts "#{message}!"
end

hour = Time.now.hour

case hour
when 9
  say("Hello")
when 18
  say("Good bye")
end

すると、次のように自然な形で else 節を導入できます。

def say(message)
  puts "#{message}!"
end

hour = Time.now.hour

message = case hour
  when 9
    "Hello"
  when 18
    "Good bye"
  else
    nil
  end

say(message) if message

---

元のコードの問題点は、(1)メッセージを選択する論理と(2)メッセージを出力するかどうかを決定する論理を単独の case 式に混在させてしまった点にあります。

私のコードでは、二つの論理が明確に分離されています。(1)の論理は case 式で表現され、(2)の論理は「後置の if」で表現されています。

いかがでしょうかね。