Rails4+DeviseでActiveDirectory（LDAP）認証を試してみた。

Rails4+Deviseで、ActiveDirectory認証を試してみました。

ActiveDirectoryはユーザ名がcnではなくてsAMAccountNameなんて項目に入っていたり、
標準でうっかり日本語でユーザつくろうものなら嵌ること間違いなしな罠が地味にあります。

幸いRubyは日本製なので、日本語でも問題ありませんでしたが・・・


詳細はWiKiにまとめておきます。

俺的メモ:RailsでCronで動かすバッチ処理を書きたい。でもActiveRecordは使いたい。

RailsなWebアプリケーションフレームワークでcronで動かす前提なバッチ処理プログラムを書くという変態奇特な方がいらっしゃったのでメモ。

【Rails】バッチ処理を実装したいけどActiveRecordを中で使ったりもしたいし

RAILS_ROOT/lib/tasks/直下にdel_user.rbってな感じで作成する(実は/lib配下ならどこでもいい)
実行は

rails runner Tasks::DelTmpUsers.execute

な感じ。

クラス名は、/lib/に作成したディレクトリ名の先頭大文字にしたもの::Hogehogeって名前にしないといけない。

例えば、/lib/crontask/hogehoge.rbに配置したら、

クラス名は

Crontask::Hogehoge

になる。

注意点は、モデルクラスの読み込みはされないので、使うモデルはrequireしないといけない。

Railsのテストサーバ(WEBric)はシングルスレッド？！

このところ、Rails漬けな生活を余儀なくされつつあって、四苦八苦しながら日々少しづつ山を崩していますが、地味にハマったのでメモ。

Railsな人には常識なのかもしれませんが、Railsの開発サーバである、WEBrickは、実はシングルスレッドで動作しているので、同時に複数のリクエストを処理できません。

なお、当然これはWEBrickの制約なので、Rails自体がマルチスレッドで動作しないわけではありません。

簡単に実験してみました。(Ruby 2.1.2 + Rails4)

rails g controller test1 index
rails g controller test2 index

っと、２つページを作成し、test1のindexアクションにこんな感じでスリープを入れます。

class Test1Controller < ApplicationController
  def index
    sleep(30)
  end
end

rails s
でWEBrickを起動し、localhost:3000/test2/indexにアクセスします。
普通にtest2のページが表示されるはずです。
では、その状態で別のブラウザまたは別のタブを開いて、localhost:3000/test1/indexにアクセスします。

開くのに30秒ほどかかるはずです。

では、test1にアクセスして、読み込み中のときに、test2を開いてみましょう。
おそらくtest2も応答待ちになったと思います。

ちなみに、Productionモードで起動しても同じでした。

開発用簡易サーバということで、あまり負荷がかかるのを想定されていないのでしょうが、
コントローラに重いトランザクション処理をさせて、別ブラウザで他のページを参照するテストが全く動かなくて焦りました・・・
（RubyというかRails的には、そもそも長時間サーバを専有するようなコードは書くべきではないし、やるなら別スレッドで非同期処理しろってことなんでしょうけど。)

なお、Apache＋Passengerの環境では、普通にマルチスレッドで処理されるので、上記のような問題はありませんでした。

開発サーバでもマルチスレッドで動作させたい場合は、unicornなどを使用すると良さそうですが、
開発マシンのメモリがガシガシ食われるのでvagrant環境だとちょっと厳しい。

Windows7+VagrantでRails4の開発環境構築

Vagrant+Rails4での開発が思った以上に快適だったのでメモ。

まずは、この辺りからVertualBoxをダウンロードし、インストールします。

次に、Vagrantをダウンロードし、インストールします。
*古いブログとかで出てくるDLサイトは古いバージョンなので注意！

開発用ディレクトリを適当に作成し、コマンドプロンプトでそのディレクトリに移動します。
以下コマンドを実行。

vagrant box add centos6 http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-i386-v20131103.box

他のOSや64bit版がほしいとかは、この辺りを参照して、DL用のURLを適宜セット。

centos6の部分はラベルなので、適当な名前をつける。

なお、DLはかなり時間がかかるので注意！

DLが完了したら、開発するディレクトリ上でvagrant init centos6を実行。（centos6の箇所はラベルなので以下略）

実行したディレクトリ内にvagrantfileというファイル（仮想マシンの動作を設定するファイル）が作成される。

vagrant upコマンドを実行すると、しばらく後仮想マシンが起動する。

TeraTermなどのSSHクライアントで、127.0.0.1:2222にアクセスする。

ID:PWはともにvagrant。鍵認証でも入ることが出来る。
（鍵ファイルの場所はvagrant initした際に画面に表示されている）

こんなかんじでログインできます。
sudo su -でrootになれます。

デフォルトで入っているRubyは1.8系と古いので、rbenvでサクッと最新を入れます。

まずはgitを入れます。(操作はvagrantユーザ)

sudo yum -y install git

rbenvを入れます。

git clone git://github.com/sstephenson/rbenv.git .rbenv

環境変数をセットします。

echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ./.bashrc
echo 'eval "$(rbenv init -)"' >> ̃/.bashrc

セットした環境変数を読み込ませます。

source ̃/.bashrc

ruby-buildをインストールします。

git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

インストール可能なリストを表示します。

rbenv install --list

今回はRuby 2.1.2をインストールします。

rbenv install 2.1.2

自動的にソースのDLとコンパイル、インストールが走ります。しばらく待ちましょう。

終わりましたら、忘れずrbenv rehashを打ちます。

毎回打つのは面倒なので、便利なgemを入れます。

gem install rbenv-rehash

vagrantは、/vagrantディレクトリと、windows上のvagrantfileが置いてあるディレクトリが共有されています。

なので、

ln -s /vagrant /home/vagrant/deverop

とシンボリックリンクを貼って、

cd deverop
rails new new-app

っとかすると、windows上でファイル編集しながら、vagrant上で動かせます。

最後に、vagrantでポートフォワードをする方法です。

vagrantfileに

  # config.vm.network "forwarded_port", guest: 80, host: 8080

という行があるので、その下に

config.vm.network "forwarded_port", guest: 3000, host: 3000

って感じで記述し、保存後、

vagrant reloadして、仮想マシンを再起動させると、仮想マシン上の3000ポートが、localhostの3000ポートにポートフォワードされます。

*Tips

仮想マシンにvagrantユーザでSSH接続ができなくなった場合、
virtualboxを起動し、該当マシンを強制電源断後、virtualboxで起動させ、

root/vagrantでログインし、復旧させます。

Rails4メモ

Rails4に限らず、Rails周りのメモ書きをWiKiにまとめ中・・・

Railsで自己認証局＋自己証明書を発行するWebシステムを作ってみた。

このところ色々忙しくて、ネタはあったのですが中々書けていませんでした。
まぁ表題の通りなのですが、練習がてら、Railsで自己認証局(CA)＋自己証明書を発行する俺得ツールを作成してみした。

実はRailsで作るのは初ですｗ
ソースはこちら。
作りたい！という勢いだけで作ったので、まだバグや動作がおかしいところがあります。
当初Herokuにおいておいたのですが、どうもデータが永続的に保存できないようで、
自宅サーバに試験的においています。

これはなんなのか？というと、AWSなどの仮想サーバにChefなどでサーバを大量生産できるのに、SSL証明書のテストをするためにいちいちOpensslコマンド叩くのがいい加減面倒になったのと、地味に自己認証局を建てるのがしんどかったので。

SSLのテストだけであれば、自己証明書だけでいいのですが、実際のサーバにはCAもセットします。
Chefのレシピとかで証明書のセットを作成していると、そこのテストができないんですね。
適当につくると、最近のブラウザは賢くて開かなかったりしますし・・・

あと、Webアプリなので、手元にLinuxやCygwinがいらないですし、いつどのサーバの証明書を作成したのか管理できるようになります。

現在、証明書の有効期限は意図的に短く設定しています。
これは、さすがに自己証明書を１年を超えて使わないだろうという前提があるからです。

応用すれば、クライアント証明書を発行したりもできると思います。