2012-04-30
■[CentOS][RoR] CentOS で Ruby on Rails
Cent OS 5.8（64bit版）にRuby on Railsをインストール。以下、方針。
CentOSのバージョン確認方法
% more redhat-release
パッケージ管理ソフト yum
% yum update
パッケージ検索
% yum search キーワード
インストール
% yum install パッケージ名
Ruby 1.9.xのインストール
ぷろぐらま：CentOSでのRails環境構築手順を参考にする。
LibYAMLからソースコードをダウンロードし、libyamlをインストールする。
% wget http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz % tar xvfz yaml-0.1.4.tar.gz % cd yaml-0.1.4/ % ./configure |& tee configure.log % make |& tee make.log % sudo make install
zlib、OpenSSLをパッケージでインストール。
% sudo yum install openssl-devel zlib-devel
オブジェクト指向スクリプト言語 Rubyより、Ruby 1.9.3-p194のソースコードをダウンロードする。
% tar xvfj ruby-1.9.3-p194.tar.bz2 % cd ruby-1.9.3-p194 % ./configure --prefix=/usr/local % make |& tee make.log % make test % sudo make install
alternativeでrubyを有効にする。
% sudo mv /usr/bin/ruby /usr/bin/ruby1.8 % sudo /usr/sbin/alternatives --install /usr/bin/ruby ruby /usr/local/bin/ruby 1000 % sudo /usr/sbin/alternatives --install /usr/bin/ruby ruby /usr/bin/ruby1.8 2000 % sudo /usr/sbin/alternatives --config ruby （これで/usr/local/bin/rubyを選ぶ） % ruby -v ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
rubygemのインストール
RubyGems.orgからソースコードダウンロードしてコンパイル。
% tar xvfz rubygems-1.8.24.tgz % cd rubygems-1.8.24 % sudo ruby setup.rb % which gem /usr/local/bin/gem % gem -v 1.8.24
Ruby on Railsのインストール
SQLite3をパッケージでインストール
% sudo yum install sqlite.x86_64 sqlite-devel.x86_64
SQLite3とrubyとのパッケージをインストール
% sudo gem install sqlite3
新しいプロジェクトを作成する
% rails new demo % cd demo % vi Gemfile
Gemfileに以下を付け加える。
gem 'execjs' gem 'therubyracer'
% sudo bundle install
nginxのインストール
事前準備。
% sudo yum install pcre-devel.x86_64
nginxをへびにっき：CentOS 5にNginxをインストールするを参考にソースファイルからコンパイルする（Rails用に使う予定なので、 --http-fastcgi-temp-path は省略）。
% sudo /usr/sbin/useradd -s /sbin/nologin -d /usr/local/nginx -M nginx % tar xvfz nginx-1.2.0.tar.gz % cd nginx-1.2.0 % ./configure \ --prefix=/usr/local \ --conf-path=/etc/nginx/nginx.conf \ --error-log-path=/var/log/nginx/error.log \ --pid-path=/var/run/nginx/nginx.pid \ --lock-path=/var/lock/nginx.lock \ --user=nginx \ --group=nginx \ --with-http_stub_status_module \ --with-http_ssl_module \ --with-http_gzip_static_module \ --with-http_realip_module \ --http-log-path=/var/log/nginx/access.log \ --http-client-body-temp-path=/var/tmp/nginx/client/ \ --http-proxy-temp-path=/var/tmp/nginx/proxy/ \ --with-cc-opt="-O3" |& tee configure.log % make |& tee make.log % sudo make install
nginxの起動確認。
% sudo /usr/local/sbin/nginx （起動） % sudo /usr/local/sbin/nginx -s quit （終了）
http://ホスト名/ でアクセスできなかったら、SU Linuxを疑う（私はそうだった）。以下のコマンドでHTTPとHTTPSを有効にする。
% sudo system-config-securitylevel-tui
起動スクリプトを作成する。Red Hat Nginx Init Scriptから起動スクリプトをダウンロードし、編集する。
% cp -p nginx nginx.org % vi nginx % % diff nginx.org nginx 22c22 < nginx="/usr/sbin/nginx" --- > nginx="/usr/local/sbin/nginx" 29c29 < lockfile=/var/lock/subsys/nginx --- > lockfile=/var/lock/nginx.lock
有効にする。
% sudo mv nginx /etc/init.d/ % sudo chmod 755 /etc/init.d/nginx % sudo /sbin/chkconfig --add nginx % sudo /sbin/chkconfig nginx on
ログローテートの設定（参考）
% cd /etc/logrotate.d
% sudo touch nginx
% sudo vi nginx
% more nginx
more nginx
/var/log/nginx/*log {
missingok
notifempty
delaycompress
sharedscripts
postrotate
/usr/local/sbin/nginx -s reopen
endscript
}
% sudo /usr/sbin/logrotate -d /etc/logrotate.conf （設定ファイルの確認）
unicornの設定
passengerではなくunicornを使ってみることに。
milk1000cc：nginx + Unicorn を試してみたを参考に設定する。
unicornをインストール
% sudo gem install unicorn
続いて、RailsアプリのGemfileに追加し、読み込ませる。 /path/rails_app にRailsアプリがあるとき
% vi /path/rails_app/Gemfile % cd /path/rails_app/ % bundle install
http://unicorn.bogomips.org/examples/unicorn.conf.rb をダウンロードし、 Tech Racho：次世代RailsサーバーUnicornを使ってみたとmilk1000cc：nginx + Unicorn を試してみたを参考に書き直した（ほとんどそのまま。ログの吐き出し先だけ違う）。
% wget http://unicorn.bogomips.org/examples/unicorn.conf.rb
% mv unicorn.conf.rb /path/rails_app/config/unicorn.rb.org
% cd /path/rails_app/config/
% cp -p unicorn.rb.org unicorn.rb
% vi unicorn.rb
% diff unicorn.rb.org unicorn.rb
24c24
< working_directory "/path/to/app/current" # available in 0.94.0+
---
> #working_directory "/path/to/app/current" # available in 0.94.0+
28c28
< listen "/tmp/.sock", :backlog => 64
---
> #listen "/tmp/unicorn.sock", :backlog => 64
35c35
< pid "/path/to/app/shared/pids/unicorn.pid"
---
> pid File.expand_path('log/unicorn.pid', ENV['RAILS_ROOT'])
40,41c40,41
< stderr_path "/path/to/app/shared/log/unicorn.stderr.log"
< stdout_path "/path/to/app/shared/log/unicorn.stdout.log"
---
> stderr_path File.expand_path('log/unicorn.log', ENV['RAILS_ROOT'])
> stdout_path File.expand_path('log/unicorn.log', ENV['RAILS_ROOT'])
64,71c64,71
< # old_pid = "#{server.config[:pid]}.oldbin"
< # if old_pid != server.pid
< # begin
< # sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
< # Process.kill(sig, File.read(old_pid).to_i)
< # rescue Errno::ENOENT, Errno::ESRCH
< # end
< # end
---
> old_pid = "#{server.config[:pid]}.oldbin"
> if old_pid != server.pid
> begin
> sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
> Process.kill(sig, File.read(old_pid).to_i)
> rescue Errno::ENOENT, Errno::ESRCH
> end
> end
稼働しているかどうかを確認する。ポート番号8080で動いていたらOK。
% unicorn_rails -c config/unicorn.rb -E development （開発環境＆プロセスとして起動） % unicorn_rails -c config/unicorn.rb -E production -D （公開環境＆デーモンとして起動）
nginxとunicornを連動させる
/etc/nginx.confの設定を該当部分だけ抜粋。
〜前略〜
http {
〜中略〜
upstream backend-unicorn{
server localhost:8080;
}
server {
listen 80;
server_name hogehoge.jp;
# keep less damage of XSS
# http://blog.monoweb.info/article/2012021823.html
add_header X-XSS-Protection "1; mode=block";
# keep less damage of Clicking jack
# http://blog.monoweb.info/article/2012021823.html
add_header X-Frame-Options DENY;
# Prevent sniffing of IE
# http://blog.monoweb.info/article/2012021823.html
add_header X-Content-Type-Options nosniff;
root /path/rails_app/public;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) { proxy_pass http://backend-unicorn; }
# proxy_passは上のupstreamで指定しているもの。
#アクセス制限
allow xxx.xxx.xxx.xxx/yy;
deny all;
}
# Asset pipelineの対応
# http://d.hatena.ne.jp/milk1000cc/20100804/1280893810
location ~* \.(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ {
expires 1y;
add_header Cache-Control public;
add_header Last-Modified "";
add_header ETag "";
}
〜中略〜
}
こうした上で起動。
% cd /path/rails_app/ % unicorn_rails -c config/unicorn.rb -E production -D % sudo /etc/init.d/nginx start
80番ポートで無事にアクセスできたら成功。サーバーの再起動時にunicornを自動起動させる方法を見つけないと。
PostgreSQL
続く。
■[発声練習] Web上での研究内容について何を書かない方が良いのか？
まとめ
- 行っている研究の価値が何から発生しているのかを理解し、価値を損じる可能性のあることを書いてはいけない。
- でも、そんなのがすぐにわかるんだったら、卒業研究や修士研究やる必要はない。研究の主責任者が教えるべき。
本文
論文や研究成果として「新規性」が求められる限り、以下の懸念は当然のこと。私もボスと相談して研究室メンバーの外部公開のポリシーを定めないといけない。
検索をしてみると、確かに期待した情報も数多く得られたのですが、学部や修士の学生が「俺こんな実験やってます！」とか「こういう研究テーマを行なっています！」という呟きがかなり引っかかり、非常に危機感を覚えました。「お前、正気か？」くらいのテンションでした。
なぜ研究テーマや実験内容をつぶやく（ネット上で公開する）のがまずいのかというと、競合する研究者に情報が漏れる可能性もあるからです。
ただし、この話は分野やテーマ、手法によって大きく異なる。一概に研究（開発も同様）についてWeb上で触れてはいけないとしてしまうとそれは羹（あつもの）に懲りて膾（なます）を吹くになってしまう。
- 研究への関わり方
- 自分一人で進めている研究：公開に伴う不利益は自分一人で受ければ良いので問題ない
- 自分が主責任者（予算執行者）として進めている研究：共同研究者に迷惑がかかるが、責任者は自分なので問題ない
- 自分は主責任者の下で研究の一部（すべて）を進めている研究：研究に不利益がでる可能性があるので注意が必要
- 競合者との関係
- 研究の売り
- 売りは結果：注意が必要。過程よりも結果が重要な場合は結果を他者に出されたら終わり
- 売りは過程：注意が必要。ただし、ある結果に至る過程は複数あるのが当たり前なので、その過程がわからければ良い。
- 売りはアイデア（机上の話）：予定された手段で外部に発表するまで黙っているべき。理論的な話は実験的・実現的話に比べて短時間で発表しやすい。
- 売りは解釈：解釈対象のデータが独占的なものでないならば注意が必要。その場合は視点や解析手法を公開してはいけない。解釈対象のデータが非公開かつ独占的なものであるならば、むしろ視点や解析手法について公開して情報交感したほうが良い。
自分が取り組んでいる研究の価値は何に由来するのかによって、何について論文公開前（製品発表前）に発信してはいけないのかが変わる。一方で、研究の質を高める一般的な手法（メタ研究技術、すなわち、クリティカルリーディング（批判的に本を読む方法の理解）、論理的思考法（演繹的思考法、帰納的思考法、仮説生成的思考法とこれらの思考法の限界の理解）、証拠に基づく議論術、技術文書作成法、あと研究分野によっては協調的作業の経験など）についてはいくら発信しても何の影響もない。むしろ、互いに教えあった方が有意義。
実験に関しても、実験手順（プロトコル）そのものに価値があるならばそれを類推できることを書いてはいけない。一方で、その分野においてある実験機器を使うのが当たり前の場合、その機器の使い方や注意事項などを公開して共有するのは問題ない（むしろ、した方がよい）。
で、ここいらへんの話を学生が理解できないのは当然。SNSおよびマイクロブログ全盛時代である今は、研究の主責任者が何を述べて何を述べてはいけないのかを説明しないといけない（すなわち、今やっている研究の価値はどこから発生しているのかを説明し、理解してもらわないといけない）。それを説明する気がないなら、研究経験の練習としてバレても問題ないことを学生にやってもらうのが良い。
不特定多数を対象とした研究関連SNSおよびQ＆Aサービス
企業の製品開発や企画立案もおなじだけれども、上記の「競合者に出し抜かれる」あるいは「研究・製品・企画の価値を損じる」という理由で、情報発信が難しい点が不特定多数を対象とした研究関連SNSおよびQ＆Aサービスが乗り越えるべき壁。
この部分で安心感を与えないかぎり、不特定多数を対象とした研究関連SNSおよびQ＆Aサービスはうまく載らない。正直なところ、私は、分野によっては、Mendeleyが行っているような論文推薦サービスすら忌避されると思っている。一番良いのは、実際に面識がありオフラインで信頼関係が構築されている人を支援する研究関連SNSおよびQ＆Aサービスだと思う。そういう意味で、Twitterやブログでのこみいった研究相談は非現実的に感じている（どの段階から公開すべきでない話題に切り替わるかわからないため）。
余談：このブログの場合
一応は気をつけている。プログラミング系、サーバー管理系、メタ研究技術系については隠しても何の価値もないと思うし、私が他の方が公開してくださっていることで助かっているので、私も備忘録の代わりにまとめて公開するようにしている。研究のアイデアやメモっぽいことも書いているけど、それは今は手が回らないので誰かが先にやるならばしょうがないと割り切って載せている（私が欲しいけど、私ができないからとりあえず公開して、誰かがやってくれるのを待っているという面も大きい）。
リンク先ブログのはてなブックマークコメントにある「学生さんや院生さんの悪口をつぶやいてる教員さんもだいぶ心配にはなるよね。」が耳の痛いところ。一応、単なる愚痴で終わらせず、じゃあどうすれば良いのかに発展させてエントリーを書いているつもり。たまに、純然たる愚痴をTwitterに流しているけど。
