visenere_cipher 1.0.0 リリース 笑

先日お知らせした ヴィジュネル暗号処理用ライブラリ「vigenere_cipher」1.0.0 を本日リリースした。
探し方：

> gem search ^vigenere

*** REMOTE GEMS ***
...
...
vigenere_cipher (1.0.0)

インストール方法：

> gem install vigenere_cipher

もし興味があったら試してみてやってください。
ソースコードはこちら

ヴィジュネル暗号用のgemを公開してみた。

ヴィジュネル暗号というのはその名の通り暗号処理方式の一種で、その詳しい歴史についてはwikipediaを参照してもらうとして、本日その処理をrubyで簡単に行うためのライブラリ(vigenere_cipher 1.0.0.pre)を公開した。（ソースコードはgithubから入手可能）

gemを作るのもgithubを使うのも初めてだったので結構大変だった。
そのあたりについては後日、手順等をまとめておこうと考えている。

現在の暗号技術から言ってヴィジュネル暗号自体は大したものとは言えない。
しかし鍵となるキーワードが十分に長く、暗号方式が秘密であれば、簡易的用途で用いる分には、今でもある程度使える余地はある。

要望等はgithubの方か、もしくは当ブログにてお願いします。

rubygem が反応しなくなったら

仮想マシンを使っていくつもOSをインストールし、Ruby on Rails の環境を作っていると、ときたまrubygemが全く反応しなかったり、反応しても不安定になることがある。筆者が確認できた特徴は以下である。
・gem list --remote が反応しない。(ごくたまに反応することはある)
・gem install が反応しない。
なお gem install については、V オプションを付けて実行すると、現在の通信状況が分かるので便利だ。
例) gem install -V gem名
(--no-ri --no-rdoc オプションを付けるとインストール時間の節約にもなる)

gem install にVオプションを付けて実行して以下のようなエラーが出たら要注意。

Unable to resolve dependencies: 
sprockets-rails requires sprockets (~> 2.8); 
railties requires thor (< 2.0, >= 0.18.1); 
actionmailer requires mail (~> 2.5.4); 
activerecord requires activemodel (= 4.0.1), arel (~> 4.0.0), activerecord-deprecated_finders (~> 1.0.2); 
actionpack requires builder (~> 3.1.0), rack (~> 1.5.2), rack-test (~> 0.6.2), erubis (~> 2.7.0); 
activesupport requires thread_safe (~> 0.1)

ERROR:  Could not find a valid gem 'rails' (>= 0), here is why:
Unable to download data from https://rubygems.org/ - no such name (https://rubygems.org/latest_specs.4.8.gz)

上記2点のエラーには非常に手こずらされた。
結論から言うと、これらのエラーは大体、次の問題のどれかまたは全てに起因している。
・DNSの問題で「rubygem.org」の名前解決ができない
・SSLの問題でHTTPSアクセスを拒否されてしまっている（ように見える)
・ファイアウォールで443番ポートへの送信を拒否している

ファイアウォールに関しては確認の上、443番ポートへの外部送信を許可すればよいとして、DNSを原因とする場合は、wget コマンドを使って確認することができる。

> wget https://rubygems.org/specs.4.8.gz
--2013-11-04 13:18:16--  https://rubygems.org/specs.4.8.gz
rubygems.org をDNSに問いあわせています... 失敗しました: ホスト名に対応するアドレスがありません.
wget: ホストアドレス `rubygems.org' を解決できませんでした。

この反応が出たら、何らかの理由でDNSが名前解決をできていない可能性を疑うべきだろう。
それに加えて、SSLの問題が絡んでいる可能性もある。それについてはGitHubに掲載されている。

ではここまでに書いた状況に陥ってしまったらどうすればいいのだろう？

gemコマンドの入力を通常とは変える、というのがその答えとなる。

> nslookup rubygems.org
;; Question section mismatch: got rubygems.org/AAAA/IN
Server:         220.152.38.201
Address:        220.152.38.201#53

Non-authoritative answer:
Name:   rubygems.org
Address: 54.245.255.174

> gem install -V rails --source http://54.245.255.174

まずはnslookup(またはdig)コマンドでrubygems.org のIPアドレスを特定する。
次にgem install で --source オプションを指定し、gemのダウンロード元のサーバーを特定するのだが、このときに先のIPアドレスを指定する。またプロトコルはhttps ではなく「http」とする。この対応で正常にgemをインストールできるようになるはずだ。

リモートサーバー（ダウンロード元サーバー）にあるgem の一覧を見るときもこれと同じ工夫をすれば良い。

> gem list --remote --source http://54.245.255.174

---

が、しかし、

まだこれで終わりではなかった……笑

恐らくこのブログを見ている人の少なくない数がRailsを使っていると思われるが、もしその人の環境で上述したようにrubygem が動かない場合、それは

bundlerも動かない

ことを意味している。
そして筆者もすぐにその穴に落ちてしまったのだった　笑
この場合、良いのか悪いのか別にして筆者の場合は/etc/hosts ファイルに直接 rubygems.org のアドレスを書くことで回避できた（ように見えるが確信はない）。

vi /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
54.245.255.174  rubygems.org

Enumerator がなんで必要なのかようやく分かった(2)

以前のエントリ「Enumerator がなんで必要なのかようやく分かった」でEnumratorクラスの存在意義について書いたが、少し補足をば。
以前の内容では本来enumerableモジュールをincludeしていないクラスでも、その代替となるメソッドを指定し、eachメソッドを持つかのように見せかけるラッパークラスとしてEnumerator の存在意義を紹介した。
irbを使って具体的に示すと以下のようになる。

irb(main):036:0> class Abc
irb(main):037:1>   def initialize
irb(main):038:2>     @arr = [1,2,3,4,5,6]
irb(main):039:2>   end
irb(main):040:1>
irb(main):041:1*   def my_each
irb(main):042:2>     @arr.each{|n| yield n}
irb(main):043:2>    end
irb(main):044:1> end
=> nil
irb(main):045:0>
irb(main):046:0* abc = Abc.new
=> #
irb(main):047:0> enum = Enumerator.new(abc, :my_each)
=> #:my_each>
irb(main):048:0> sum = enum.inject(0, :+)
=> 21

見ての通り、クラスAbcはenumerable をinclude してないが、my_eachメソッドを指定してEnumerator オブジェクトを生成すると、そのEnumeratorオブジェクトを通じてmapやinject等の、enumerableモジュールをinclude しなければ使えないメソッドが使えるようになる。
ここまでが以前のエントリ内容であった。

しかし現在、Object#to_enum, Object#enum_for というメソッドの存在により（enum_for はto_enum の別名メソッドで機能は同じ)、直接Enumeratorをnewメソッドで呼び出すことは滅多にない、と「プログラミング言語Ruby」(David Flanagan/まつもとゆきひろ著)には記されている。
「プログラミング言語Ruby」の「5.3.4 Enumerator」の章ではこれらのメソッドを引数無しで呼び出すと、呼び出し主体であるオブジェクトのeachメソッドを呼び出すだけのeachメソッドを持ったEnumeratorオブジェクトを返す。つまり a.to_enum と記述すると、Enumerator.new(a, :each) を実行するということだ。Object#to_enum に引数をつけると、Enumerator.new の第二引数の部分に任意のメソッド名を指定できる。その場合、to_enum よりも enum_for を使う方が名前として適しているかもしれないとも記されている。

実際にやってみるとこういうことだ。

irb(main):049:0> enum = "1234".enum_for(:each_char)
=> #<Enumerator: "1234":each_char>
irb(main):050:0> enum.map{|c| c.to_i * 2}
=> [2, 4, 6, 8]

さらにRuby 1.9からは、引数無で呼び出された場合にEnumeratorオブジェクトを返すイテレータメソッド(あるいはイテレータ的なメソッド)が増えた。特にEnumerableモジュールをミックスインした場合、each, map 等は引数無しだと全てEnumeratorオブジェクトを返す。そうした場合では、to_numもenum_for も記述不要となる場合も多くなった。

irb(main):051:0> "1234".each_char.select{|c| c.to_i.even?}
=> ["2", "4"]

これはまぁ、便利っちゃー便利な機能だと思う。

ruby-1.9.3-p392とrails3.2.13 を CentOS 6.4 にインストールするまで (その後)

Rails が入ったのはいいが、まだ一つ課題が残っていた。
それは…

DB

PostgreSQLを使用するRailsのプロジェクトなので、当然このRDBSを使用するようにまずはPostgreSQLをインストールしなければいけない。バージョンは9.2。
CentOS 6.4 が標準でyumに保持しているのはバージョン8までのpostgreSQLなので、その辺も乗り越えなければいけない。まあ、知っている人からすれば大したことじゃないんだろうけどね。

そうはいってもこちらはズブの素人であるからして、何をするにも不安なのは仕方ない。色々探してみて、ここのページにお世話になりました。
迷い家の白猫 技術部　CentOS 6.3にPostgreSQL9.2をインストール
ほぼここに書かれている通りのことをなぞったらうまく行った。ありがとうございます、先輩。
一応備忘録としてポイントを残しておく。

パッケージはPostgreSQLの提供するRPMリポジトリから入手

PostgreSQLは有難いことにRedhat系のLinuxOSに対してパッケージ(RPM)を用意してくれているようだ。[PostgreSQL RPM Building Project - Repository Packages]
そもそもRPMが何かということすら良く分かってない筆者が訳知り顔で言うのもおこがましいが、ここからRDBSをパッケージごと入手するのがベターのようだ。

> wget -P /tmp http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/pgdg-centos92-9.2-6.noarch.rpm
> rpm -ivh /tmp/pgdg-centos92-9.2-6.noarch.rpm
> yum list | grep postgresql92
postgresql92.x86_64                    9.2.4-1PGDG.rhel6     pgdg92
postgresql92-contrib.x86_64         9.2.4-1PGDG.rhel6     pgdg92
postgresql92-devel.x86_64            9.2.4-1PGDG.rhel6     pgdg92
postgresql92-libs.x86_64              9.2.4-1PGDG.rhel6     pgdg92
postgresql92-server.x86_64          9.2.4-1PGDG.rhel6      pgdg92

yumは以下の通り

> yum install -y postgresql92-server.x86_64 postgresql92-devel.x86_64 postgresql92-contrib.x86_64
...
...
Installed:
  postgresql92-contrib.x86_64 0:9.2.4-1PGDG.rhel6         postgresql92-devel.x86_64 0:9.2.4-1PGDG.rhel6         postgresql92-server.x86_64 0:9.2.4-1PGDG.rhel6

Dependency Installed:
  postgresql92.x86_64 0:9.2.4-1PGDG.rhel6                   postgresql92-libs.x86_64 0:9.2.4-1PGDG.rhel6                   uuid.x86_64 0:1.6.1-10.el6

Complete!

インストール後の作業

インストールが完了したらシステムの初期化と利用する上での設定を行う。ファイル権限等で失敗することがあるので注意。ちなみにpostgresユーザーはシステムインストール時に勝手にできるもの？なのか既に存在していた。いなければ作らなければならないのだろうが、その設定は調べてない……

> vi /var/lib/pgsql/9.2/data/postgresql.conf
listen_addresses = '*'  # この行だけこのように変更
# shift + zz で保存終了

 #システムのスーパーユーザーをpostgres, 文字コードをUTF-8に設定
> /etc/rc.d/init.d/postgresql-9.2 initdb -E UTF-8 -U postgres

> /etc/rc.d/init.d/postgresql-9.2 start
postgresql-9.2 サービスを開始中:                           [  OK  ]
> chkconfig --list postgresql-9.2
postgresql-9.2  0:off   1:off   2:off   3:off   4:off   5:off   6:off
> chkconfig postgresql-9.2 on  # 自動起動設定
> su - postgres
-bash-4.1$ psql -l
                                         データベース一覧
   名前    |  所有者  | エンコーディング |  照合順序   | Ctype(変換演算子) |      アクセス権
-----------+----------+------------------+-------------+-------------------+-----------------------
 postgres  | postgres | UTF8             | ja_JP.UTF-8 | ja_JP.UTF-8       |
 template0 | postgres | UTF8             | ja_JP.UTF-8 | ja_JP.UTF-8       | =c/postgres
                                                                           : postgres=CTc/postgres
 template1 | postgres | UTF8             | ja_JP.UTF-8 | ja_JP.UTF-8       | =c/postgres
                                                                           : postgres=CTc/postgres

上記の作業でPostgreSQLの初期化が終わり、/var/lib/pgsql/9.2/data/にデータ領域が用意される。またコマンド類は/usr/pgsql-9.2/binに配置される。但しこのままだとPostgreSQL8のコマンド群が残っているので、パッケージごと削除する必要がある他、新しいコマンドを簡単に使えるようにユーザーpostgresには環境変数の調整が必要だ。

> yum remove postgresql.x86_64 postgresql-libs.x86_64 postgresql-odbc.x86_64
> su - postgres
$ cp .bash_profile .bash_profile.org
$ sed '3a\PATH="/usr/pgsql-9.2/bin:$PATH\nexport PATH"' .bash_profile.org > .bash_profile
$ exit
> su - postgres # 確認のため再度postgresユーザーでシェル起動
$ psql
psql (9.2.4)
"help" でヘルプを表示します.

postgres=# \q

ここまで行けば後はcreatedb コマンドで実際に開発するDBを追加していくだけだろう。

---

補足
実はこれでは終わらなかった。DBを作成後、新しいRailsアプリを作った後、bundler がエラーを起こした。RubyからpostgreSQLにアクセスするための「pg」というrubygemモジュールを使うようGemFile(Railsアプリをサクセスるとアプリのルートディレクトリに作成される)を修正し、「bundle update」を実行するとエラーになってしまう。
どうやらpostgreSQL9.2をインストールした際、通常の/usr/lib 等にあったバージョン8をきれいに置き換えず、/user/pgsql-9.2なるディレクトリにインストールしてしまったことが問題の根幹らしい。それによりpg_config というコマンドのパスが変わってしまい、それでpgの作成ができないようだった。
対処としては、一時的にrootの環境変数PATHに /usr/pgsql-9.2/bin を加える方法を取った。多分自分しか使わない仮想マシンだから許される手段ではないかと思う。

-- .bash_profile(修正前) --
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs
PATH=$PATH:$HOME/bin:
export PATH

-- .bash_profile(修正後) --
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs
PGDATA=/var/lib/pgsql/9.2/data
export PGDATA

PATH=$PATH:$HOME/bin:/usr/pgsql-9.2/bin
export PATH

この処置の後、「bundle update」を実行したところ問題なく処理を完了した。

ところがこの他にもDBの設定で引っかかってしまった。
WebRick を起動するために「rails server」と入力すると、DBエラーが発生する。Ident認証に失敗した、という旨のメッセージが表示されWebRick を起動できないのだ。
これも初期設定の見落としで、pg_hba.conf というファイルを修正しなければならなかった。このファイルは前述のinitdb を実行した際にpostgresql がデータファイルを作成する場所にある。筆者の場合は、/var/lib/pgsql/9.2/data にあった。
このファイルの説明については、マニュアルを参照するのがいいだろう。
PostgreSQL 9.2.4文書 第 19章クライアント認証
要するに、このファイルで ident とかpeer とか書かれれている部分を全部 trust にしてしまえばいいわけだ。勿論これは開発環境だからできることで本番稼働環境ではもっと権限に厳密な作業をしなければいけない。

-- pg_hba.conf (修正前:抜粋) --
# TYPE  DATABASE        USER            ADDRESS                 METHOD
# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident

-- pg_hba.conf (修正後:抜粋) --
# TYPE  DATABASE        USER            ADDRESS                 METHOD
# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

このようにファイルを編集した後にサービス再起動する。（/etc/rc.d/init.d/postgresql-9.2 restart）
それからRailsアプリのルートディレクトリに戻り再度WebRickを起動してみた。

# rails server
=> Booting WEBrick
=> Rails 3.2.13 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2013-05-01 14:36:11] INFO  WEBrick 1.3.1
[2013-05-01 14:36:11] INFO  ruby 1.9.3 (2013-02-22) [x86_64-linux]
[2013-05-01 14:36:11] INFO  WEBrick::HTTPServer#start: pid=12947 port=3000

どうやら今度こそ上手くいったらしい……

と思ったら、まだ続きがあんのかよ！？　笑
何べんブラウザでアクセスしても当該アプリのトップページが表示できない。「このページは表示できない」となるので、恐らくステータスコード404とか500あたりでhttp接続が終わってしまってるんだろう。覚えたてのnetstat コマンドを使ってみたが、何が何だかわからず。

# netstat -at
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 *:sunrpc                    *:*                         LISTEN
tcp        0      0 *:40561                     *:*                         LISTEN
tcp        0      0 *:ssh                       *:*                         LISTEN
tcp        0      0 localhost:ipp               *:*                         LISTEN
tcp        0      0 *:hbci                      *:*                         LISTEN
tcp        0      0 *:postgres                  *:*                         LISTEN
tcp        0      0 localhost:smtp              *:*                         LISTEN
tcp        0    308 192.168.1.24:ssh            192.168.1.20:59725          ESTABLISHED
tcp        0      0 192.168.1.24:ssh            192.168.1.20:59804          ESTABLISHED
tcp        0      0 *:sunrpc                    *:*                         LISTEN
tcp        0      0 *:ssh                       *:*                         LISTEN
tcp        0      0 localhost:ipp               *:*                         LISTEN
tcp        0      0 *:postgres                  *:*                         LISTEN
tcp        0      0 localhost:smtp              *:*                         LISTEN
tcp        0      0 *:43777                     *:*                         LISTEN
tcp        0      0 localhost:postgres          localhost:54429             ESTABLISHED
tcp        0      0 localhost:54429             localhost:postgres          ESTABLISHED

良く分からないが、一番可能性があるのが小耳に挟んだことのある「パケットフィルタリング」の結果であろうと筆者は推測し、例によって書籍とWeb検索の力を借りて現在の状況を確認してみた。

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

むぅ……
確かにこの設定では3000番ポートを開けても駄目だろう。それで素人なりに色々やってはみるのだが、何を勘違いしているのかこれがどうもうまくいかない。
しかたなく「パケットフィルタリングそのものを無効化」することにした。

> /etc/init.d/iptables stop
> chkconfig iptables off    # 自動起動もさせない

勿論こんなことは開発用のOSだからできることなので、通常の運用にはこうしたことはやるべきではないのは言うまでもないことだ。根本的なところを解決する方策を理解して進みたかったが時間がない中での作業なので仕方なかった。
少し残念な課題を残したが、以上の作業を経て無事WEBrickで起動したRailsアプリを確認できたので、次回はこの辺の課題も解決できるようになりたい。

---

まだあった(5/2 追記)　笑
rails console コマンドが使えなくなっていたので、その解決方法をば。GemFile の rb-readlineの行を以下のように修正した後に、「bundle update」を実行する。

 -- GemFile ---
#gem 'rb-readline'
gem 'rb-readline', '~> 0.4.2'