さくらのVPS を改めて使いはじめる 9 – Ruby、Redmine、Subversion

さくらのVPS(v3) 2GB プランへの環境構築メモ 9。今回は Ruby、Redmime、Subversion のセットアップとデータ移行について書く。

もくじ

Ruby

前に借りていた VPS 環境 ( さくらのVPS 512MB ) では、Ruby Enterprise Edition 上で Redmine を動かしていたのだが、Redmine 1.4 から Ruby 1.9 系に正式対応したので、今回は Ruby + Passenger の組み合わせで運用することにした。Ruby 自体も最新のものを利用する。

まず、Ruby をコンパイルするために必要なパッケージと関連ツールをまとめてインストールする。

$ sudo yum install openssl-devel readline-devel zlib-devel curl-devel libyaml-devel mysql-devel httpd-devel ImageMagick ImageMagick-devel

余談だが、さくらのVPS(v3) の CentOS 6.2 環境だと EPEL リポジトリがはじめから有効らしい。バージョンの新旧さえ気にしなければ、有名どころのパッケージはたいてい揃うのでありがたい。

次に Ruby 本体の最新版ソースを入手する。公式ページのダウンロードから、HTTP ミラーへゆき、ソースを固めたファイルの URL を調べておく。

現時点の最新版ソースは ruby-1.9.3-p194 らしいので、これをユーザー HOME へダウンロード & 展開。

$ cd
$ wget http://core.ring.gr.jp/archives/lang/ruby/1.9/ruby-1.9.3-p194.tar.gz
$ tar zxvf ruby-1.9.3-p194.tar.gz
$ rm ruby-1.9.3-p194.tar.gz

展開した Ruby のソースをコンパイルする。RPM 化するのでインストールは実行せず、make までにしておくこと。

$ cd ruby-1.9.3-p194
$ ./configure
$ make

Ruby をコンパイルできたら、前回セットアップした checkinstall を使って RPM 化する。

途中で「それらをパッケージから除外しますか?」というメッセージが表示されたら、n を入力して Enter キーを押す。下記のコマンド例にも書いているが、RPM 化の途中で 1 時間ぐらい待たさせる。その間、特にすることはないので放置してもよい。

$ sudo checkinstall --fstrans=no
Some of the files created by the installation are inside the home directory: /home

You probably don't want them to be included in the package.
それらを表示しますか? [n]:
それらをパッケージから除外しますか?(yesと答えることをおすすめします) [n]: n

tempディレクトリにファイルをコピー..

... 中略 ( ↑のメッセージで 1 時間ぐらい待たされた )

**********************************************************************

Done. The new package has been saved to

/root/rpmbuild/RPMS/x86_64/ruby-1.9.3-p194-1.x86_64.rpm
You can install it in your system anytime using:

      rpm -i ruby-1.9.3-p194-1.x86_64.rpm

**********************************************************************

RPM 化が終わると、生成されたファイルのパスが表示される。それを参考にしてインストールを実行する。

$ sudo rpm -ivh /root/rpmbuild/RPMS/x86_64/ruby-1.9.3-p194-1.x86_64.rpm
準備中...                ########################################### [100%]
   1:ruby-1.9.3             ########################################### [100%]

インストールされたことを確認するために、Ruby のバージョンを表示。

$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

RPM パッケージの詳細情報も確認しておく。

$ sudo rpm -qi ruby-1.9.3
Name        : ruby-1.9.3                   Relocations: (not relocatable)
Version     : p194                              Vendor: (none)
Release     : 1                             Build Date: 2012年04月30日 11時16分49秒
Install Date: 2012年04月30日 13時31分41秒      Build Host: akabeko.me
Group       : Applications/System           Source RPM: ruby-1.9.3-p194-1.src.rpm
Size        : 475428049                        License: GPL
Signature   : (none)
Packager    : checkinstall-1.6.3
Summary     : Package created with checkinstall 1.6.3
Description :
Package created with checkinstall 1.6.3

きちんとインストールされてるので、不要になった Ruby のソースを消しておく。

$ cd
$ rm -rf ruby-1.9.3-p194

これにて、Ruby のセットアップは完了。

Bundler と Passenger

Redmine を動作させるために必要な Ruby Gem モジュールをセットアップする。

はじめに Bundler を入れる。これは、Redmine のような Ruby on Rails アプリのための Gem 管理ツールである。Redmine 1.4 から、アプリの Gem 依存管理で使用されるようになった。

$ sudo gem install bundler --no-rdoc --no-ri
Fetching: bundler-1.1.3.gem (100%)
Successfully installed bundler-1.1.3
1 gem installed

つぎは Phusion Passenger。これは Apache や Nginx 上で Rails アプリを動かすために使用する。

$ sudo gem install passenger --no-rdoc --no-ri
Fetching: fastthread-1.0.7.gem (100%)
Building native extensions.  This could take a while...
Fetching: daemon_controller-1.0.0.gem (100%)
Fetching: rack-1.4.1.gem (100%)
Fetching: passenger-3.0.12.gem (100%)
Successfully installed fastthread-1.0.7
Successfully installed daemon_controller-1.0.0
Successfully installed rack-1.4.1
Successfully installed passenger-3.0.12
4 gems installed

Passenger の Apache 用モジュールをインストール。

$ sudo passenger-install-apache2-module

... 中略 ...

--------------------------------------------
The Apache 2 module was successfully installed.

Please edit your Apache configuration file, and add these lines:

   LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.12/ext/apache2/mod_passenger.so
   PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.12
   PassengerRuby /usr/local/bin/ruby

After you restart Apache, you are ready to deploy any number of Ruby on Rails
applications on Apache, without any further Ruby on Rails-specific
configuration!

Press ENTER to continue.

--------------------------------------------
Deploying a Ruby on Rails application: an example

Suppose you have a Rails application in /somewhere. Add a virtual host to your
Apache configuration file and set its DocumentRoot to /somewhere/public:

   <VirtualHost *:80>
      ServerName www.yourhost.com
      # !!! Be sure to point DocumentRoot to 'public'!
      DocumentRoot /somewhere/public
      <Directory /somewhere/public>
         # This relaxes Apache security settings.
         AllowOverride all
         # MultiViews must be turned off.
         Options -MultiViews
      </Directory>
   </VirtualHost>

And that's it! You may also want to check the Users Guide for security and
optimization tips, troubleshooting and other useful information:

  /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.12/doc/Users guide Apache.html

Enjoy Phusion Passenger, a product of Phusion (www.phusion.nl) :-)

http://www.modrails.com/

Phusion Passenger is a trademark of Hongli Lai & Ninh Bui.

最後の方に、Apache 用の設定が表示されるのでメモしておく。この内容は Apache の httpd.conf 本体に書くのではなく、専用ファイルを用意する。今回は passenger.conf という名前で作成することにした。

$ sudo vi /etc/httpd/conf.d/passenger.conf

passenger.conf にさきほどの Apache 用設定を記述し、ついでに Redmine を公開するときのディレクトリ設定も加えて保存する。今回は http://ホスト名/projects に公開するので、以下のようになる。

LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.12/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.12
PassengerRuby /usr/local/bin/ruby

RailsBaseURI /projects

前の VPS では redmine というサブディレクトリにしていたが、今回はサービス名を用いず、projects という汎用な名前にした。このようにすることで、プロジェクト管理を他のサービスに変更したくなった場合でも、サブディレクトリまでなら URL を維持できる。

Apache の設定チェックと再起動をおこない、passenger.conf を読ませる。

$ sudo apachectl configtest
Syntax OK
$ sudo service httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中:                                            [  OK  ]

これで Redmine を動作させるための環境が整った。

Redmine

Redmine をセットアップしてゆく。

はじめに MySQL 上へ Redmine 専用のデータベースとユーザーを作成する。XXXXXXXXXXXXXXXX の部分はパスワードになるので、あるていど複雑な文字列を指定すること。ユーザーは redmine@localhost にした。

$ mysql -u root -p
mysql> CREATE DATABASE redmine DEFAULT CHARACTER SET utf8;
mysql> GRANT ALL PRIVILEGES ON redmine.* TO redmine@localhost IDENTIFIED BY 'XXXXXXXXXXXXXXXX';
mysql> FLUSH PRIVILEGES;
mysql> exit;

Redmine をインストールする。現時点の最新版は 1.4.1 になる。

イメージは RubyForge の Redmine プロジェクトに公開されているので、最新版の tar.gz の URL をメモしておく。これをユーザー HOME にダウンロード、展開して /var/lib/redmine に移動する。

$ cd
$ wget http://rubyforge.org/frs/download.php/76033/redmine-1.4.1.tar.gz
$ tar zxvf redmine-1.4.1.tar.gz
$ rm redmine-1.4.1.tar.gz
$ sudo mv redmine-1.4.1 /var/lib/redmine

Redmine をインストールしたディレクトリに移動し、Bundler を使って必要な Gem を入れる。PostgreSQL や SQLite などは利用しないので、without オプションをつけて除外している。

$ cd /var/lib/redmine
$ sudo bundle install --without development test postgresql sqlite
Fetching gem metadata from http://rubygems.org/.......
Using rake (0.9.2.2)
Installing activesupport (2.3.14)
Installing rack (1.1.3)
Installing actionpack (2.3.14)
Installing actionmailer (2.3.14)
Installing activerecord (2.3.14)
Installing activeresource (2.3.14)
Installing coderay (1.0.6)
Installing i18n (0.4.2)
Installing mysql2 (0.2.18) with native extensions
Installing net-ldap (0.3.1)
Installing rails (2.3.14)
Installing rmagick (2.13.1) with native extensions
Installing ruby-openid (2.1.8)
Installing tzinfo (0.3.33)
Using bundler (1.1.3)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

これまでのバージョンだと、よく ImageMagick と rmagick で互換や設定のトラブルが起きたものだが、今回は特に問題なく終了。ほっとした。

次は Redmine のデータベース接続に関する設定。これは database.yml というファイルに対しておこなう。初期状態では database.yml.example というサンプル ファイルが置かれているので、これをコピーして編集する。

$ cd /var/lib/redmine/config/
$ cp database.yml.example database.yml
$ vi database.yml

このファイルを以下のように編集して保存する。

ハイライトした部分が変更箇所。adapter は mysql ではなく mysql2 になるので注意する。username ( ユーザー名 ) と password ( パスワード ) は、さきほど MySQL 上へ設定した内容になる。

# Default setup is given for MySQL with ruby1.8. If you're running Redmine
# with MySQL and ruby1.9, replace the adapter name with `mysql2`.
# Examples for PostgreSQL and SQLite3 can be found at the end.

production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  password: XXXXXXXXXXXXXXXX
  encoding: utf8

セッション管理用の秘密鍵を生成する。これがないと Redmine の起動でエラーが発生する。

$ rake generate_session_store
(in /var/lib/redmine)

データベースを初期化する。

$ rake db:migrate RAILS_ENV=production
(in /var/lib/redmine)

必要な gem が足りなかったり、database.yml の設定を間違えてる ( adapter が mysql2 ではなく mysql になっているとか ) 場合はエラーになるので、メッセージをよく読んで修正すること。

これで Redmine のセットアップは完了。さっそく、Apache の DocumentRoot 以下にシンボリックリンクを作成して Web に公開してみる。

$ sudo ln -s /var/lib/redmine/public /var/www/html/projects

ブラウザから http://ホスト名/projects にアクセスすると、Redmine のホーム画面が表示されるはず。

Redmine

Redmine

初期状態だと、admin ユーザーのパスワードが admin になっており非常に危険なので、すぐに admin でログインしてパスワードを変更すること。

Subversion

Subversion をセットアップする。まずインストールされていることを確認。

$ svn --version
svn, バージョン 1.6.11 (r934486)
   コンパイル日時: Sep 27 2011, 15:29:25

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

入っているので、リポジトリのルートになるディレクトリを作成。

$ sudo mkdir /var/lib/svn

次にリポジトリをひとつ作成してみる。ここでは仮に example という名前にしておく。

$ sudo svnadmin create /var/lib/svn/example

sudo 経由で作成したディレクトリとファイルの所有者は root になるのだが、Apache 経由でリポジトリにアクセスしたいので、所有者を変更しておく。変更したら、確認のために中身を表示してみる。

$ sudo chown -R apache:apache /var/lib/svn/example
$ ls -l /var/lib/svn/example
合計 24
-rw-r--r-- 1 apache apache  229  4月 30 16:47 2012 README.txt
drwxr-xr-x 2 apache apache 4096  4月 30 16:47 2012 conf
drwxr-sr-x 6 apache apache 4096  4月 30 16:47 2012 db
-r--r--r-- 1 apache apache    2  4月 30 16:47 2012 format
drwxr-xr-x 2 apache apache 4096  4月 30 16:47 2012 hooks
drwxr-xr-x 2 apache apache 4096  4月 30 16:47 2012 locks

mod_dav_svn をインストールする。これを利用すると、Apache 経由で Subversion のリポジトリを操作できる。Subversion 専用のポートを開放する必要がなくなり便利。

$ sudo yum install mod_dav_svn
... 中略 ...
Installed:
  mod_dav_svn.x86_64 0:1.6.11-2.el6_1.4

Complete!

mod_dav_svn は Apache 用のモジュールなので /etc/httpd/conf.d に専用の設定ファイルを追加する。

$ sudo vi /etc/httpd/conf.d/svn.conf

以下のように編集して保存する。

<Location /svn>
    DAV           svn
    SVNParentPath /var/lib/svn
    AuthType      Digest
    AuthName      "Subversion Repository"
    AuthUserFile  /etc/httpd/conf.d/svn_auth
    Require       valid-user
</Location>

Location ディレクティブにはリポジトリのルートを指定し、DAV も同様としている。

この指定の場合、すべてのリポジトリに同じ設定が適用される。リポジトリを追加した場合でも conf ファイルの変更や Apache の再起動が不要なので便利である。リポジトリごとに設定を分ける場合は、ディレクティブの指定を /svn/リポジトリ名として、SVNParentPath の代りに SVNPath、内容はリポジトリへのパスとする。

4 行目以降はダイジェスト認証に関する設定となる。これをおこなっておくことで、ブラウザや Subversion クライアントからリポジトリにアクセスしたとき、ユーザーとパスワードによる保護をおこなえる。

次は認証用のファイルを作成する。

前述の svn.conf の AuthUserFile で指定したディレクトリに touch コマンドでファイルを用意し、パスワード設定をおこなう。USERNAME の部分は SVN のリポジトリにアクセスするユーザーとなる。

Redmine プロジェクトからのリポジトリ参照も、ここで設定した内容が必要となる。Redmine にユーザーを作成済みならば、そのユーザーとパスワードを指定することで、Redmine のログイン情報を利用したリポジトリ参照がおこなえて便利である。

$ sudo htdigest -c /etc/httpd/conf.d/svn_auth "Subversion Repository" XXXX
Adding password for XXXX in realm Subversion Repository.
New password:
Re-type new password:

最後に Apache の設定チェックと再起動をおこない、svn.conf を読ませる。

$ sudo apachectl configtest
Syntax OK
$ sudo service httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中:                                            [  OK  ]

セットアップが完了したので、ブラウザからアクセスしてみる。

さきほど作成した example リポジトリの場合、URL は http://ホスト名/svn/example になる。ここにアクセスすると、ダイジェスト認証によってユーザーとパスワードを問い合わせられるはず。正しい内容を入力すれば、リポジトリの内容が表示される。

Subversion リポジトリ

Subversion リポジトリ

リポジトリと Redmine の関連付けについては、以下の説明がわかりやすい。

環境の移行

既に運用されている Redmine から、新環境へ移行する場合の手順を書く。対象は Redmine と Subversion リポジトリ。

まずは Redmine のデータベースを出力する。出力先はユーザー HOME にしておく。ユーザー名が XXXX で、データベースが redmine なら、以下のようなコマンドになる。出力されるファイル名は redmine.sql にした。

$ cd
$ mysqldump -u XXXX -p redmine > redmine.sql

今回はデータベースの移行だけ取り上げるが、添付ファイルなどがあるなら、それらも保存しておく。バックアップ対象となりえる構成物については、以下を参照のこと。

つぎに Subversion のリポジトリを出力する。こちらも同様に、ユーザー HOME へ保存する。出力はリポジトリ単位になるので、ファイル名はリポジトリ.svndumpとしておく。XXXX の部分がリポジトリ名になる。

$ cd
$ svnadmin dump /var/lib/svn/XXXX > XXXX.svndump

出力されたファイルを新環境に送る。旧環境サーバーから直接 SCP コマンドで送信してもよいが、手元に保存しておきたいので、いったんローカルにダウンロードする。その後、Tera Term や WinSCP などで新環境へ送る。

以降は、これらのファイルが新環境のユーザー HOME 直下に置かれていると仮定して話を進める。

はじめに新環境の Redmine を非公開にする。

この記事の手順で環境構築したなら Redmine はシンボリックリンクで公開されているため、これを消すだけで非公開になる。本来ならメンテナンス用のページ ( 作業中です…とか表示しておく ) を用意し、移行が終わるまでそちらにリンクさせるほうが望ましいのだが、今回はやらない。

$ sudo rm -rf /var/www/html/projects

次に Redmine のデータベースを移行する。念のため、新環境で稼働中のデータベースを redmine-current.sql という名前でバックアップしておく。

$ mysqldump -u XXXX -p redmine > redmine-current.sql

データベースを作成し直す。redmine が空の状態になる。

$ mysql -uroot -p
mysql> DROP DATABASE redmine;
mysql> CREATE DATABASE redmine DEFAULT CHARACTER SET utf8;
mysql> exit;

旧環境から持ってきたバックアップを新環境のデータベースに取り込む

$ cd
$ mysql -u redmine -p redmine < redmine.sql

Redmine のインストール先ディレクトリに移動してから、データベースのマイグレートを実行。

$ cd /var/lib/redmine/
$ rake db:migrate RAILS_ENV=production
(in /var/lib/redmine)

その他、テーマやプラグイン、添付ファイルなどがあれば移行しておく。

Redmine 側の作業が終わったら、Subversion のリポジトリを移行する。先に移行先リポジトリを用意し、そこへ旧環境で出力したファイルを読みこむ。

$ cd
$ sudo svnadmin create /var/lib/svn/XXXX
$ svnadmin load /var/lib/svn/XXXX < XXXX.svndump
$ sudo chown -R apache:apache /var/lib/svn/XXXX

以上で移行は完了。シンボリックリンクを張り直して Redmine を公開する。

$ sudo ln -s /var/lib/redmine/public /var/www/html/projects

ブラウザでアクセスして、Redmine の移行に成功していることを確認する。

移行した後の Redmine

移行した後の Redmine

ちなみに上記のスクリーンショットで使用しているテーマは A1 theme – Redmine plugins である。かっこよくて見やすい。かなりオススメ。

…今回はここまで。次回の内容はとくに決めていない。phpMyAdmin か Git について書くかもしれない。

さくらのVPS を改めて使いはじめる 8 – checkinstall

さくらのVPS(v3) 2GB プランへの環境構築メモ 8。今回は checkinstall について書く。

もくじ

checkinstall とは?

CheckInstall は、ソフトウェアのソースから RPM パッケージなどを生成できる非常に便利なツールである。

RPM パッケージはプログラムの配布形式で、ソフトウェア本体や構成情報、セットアップ用スクリプトなどが格納されている。いわば、インストーラのようなものである。

よく、Linux 関連のソフトウェアで「ソースから make」→「 make install」するものがあるけれど、この方法でインストールした場合、管理が非常に面倒である。

例えば Makefile に uninstall が定義されていない場合、きれいに削除するのは困難である。また、新バージョンを make install で上書きしたら、旧バージョンの余計なファイルが残っていて不具合が…ということもある。

RPM で管理すれば、このようなメンテナンス上の問題は起きにくい。これまでのシリーズで利用してきた yum も、管理しているものは RPM である。

今後このシリーズで、ソースからインストールするタイプのソフトウェアが必要になったら、checkinstall で RPM 化して管理する予定である。

というわけで、今回は chekcinstall を利用するための方法について書く。

インストール

checkinstall の公式サイトから入手した最新ソースをコンパイルするとエラーになる。原因を調べていたら以下の記事を見つけた。

git リポジトリ上の最新ソースなら問題は修正されているそうなので、そちらから取得する。場所はユーザー HOME 直下としておく。

$ cd
$ git clone http://checkinstall.izto.org/checkinstall.git
Initialized empty Git repository in /home/XXXX/checkinstall/.git/

前述のサイトを参考にファイルを修正する。checkinstall のディレクトリ内に移動して、Makefile を vi で開く。

$ cd checkinstall
$ vi Makefile

7 行目のパスを以下のように修正して保存する。

# $Id: Makefile,v 1.6.2.1 2008/11/09 07:48:18 izto Exp $

# Where to install.
PREFIX=/usr/local
BINDIR=$(PREFIX)/sbin
LCDIR=$(PREFIX)/lib/checkinstall/locale
CONFDIR=$(PREFIX)

次は checkinstallrc-dist を vi で開く。

$ vi checkinstallrc-dist

120 行目の EXCLUDE に /selinux を指定して保存。

# Comma delimited list of files/directories to be ignored
EXCLUDE="/selinux"

最後の修正。installwatch ディレクトリの Makefile を vi で開く。

$ cd installwatch
$ vi Makefile

14 行目の LIBDIR に指定されたパスの lib を、lib64 に変更して保存。

# End of configurable part

VERSION=0.7.0beta7

BINDIR=$(PREFIX)/bin
LIBDIR=$(PREFIX)/lib64

すべての変更が完了したら、checkinstall ディレクトリに戻り、git diff でリポジトリとの差分を確認する。

$ cd ..
$ git diff

おそらく以下のように出力されるはず。ハイライト表示している部分が差分となる。

diff --git a/Makefile b/Makefile
index 2e28adc..b6d217c 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@
PREFIX=/usr/local
BINDIR=$(PREFIX)/sbin
LCDIR=$(PREFIX)/lib/checkinstall/locale
-CONFDIR=$(PREFIX)/lib/checkinstall
+CONFDIR=$(PREFIX)

all:
        for file in locale/checkinstall-*.po ; do \
diff --git a/checkinstallrc-dist b/checkinstallrc-dist
index d4feb4e..fe5f56e 100644
--- a/checkinstallrc-dist
+++ b/checkinstallrc-dist
@@ -117,7 +117,7 @@ RESET_UIDS=0
NEW_SLACK=1

# Comma delimited list of files/directories to be ignored
-EXCLUDE=""
+EXCLUDE="/selinux"

# Accept default values for all questions?
ACCEPT_DEFAULT=0
diff --git a/installwatch/Makefile b/installwatch/Makefile
index ae34fc1..fb41eb3 100644
--- a/installwatch/Makefile
+++ b/installwatch/Makefile
@@ -11,7 +11,7 @@ PREFIX=/usr/local
VERSION=0.7.0beta7

BINDIR=$(PREFIX)/bin
-LIBDIR=$(PREFIX)/lib
+LIBDIR=$(PREFIX)/lib64

コンパイルとインストールの準備が整ったので、さっそく実行する。

$ make
$ sudo make install

これでインストール完了。試しにバージョンを表示してみる。

$ checkinstall -v

checkinstall 1.6.3, Copyright 2010 Felipe Eduardo Sanchez Diaz Duran
           このソフトウェアはGNU GPLの下でリリースしています。

Copyright (c) 2010 Felipe Eduardo Sanchez Diaz Duran <izto@asic-linux.com.mx>

    This program is free software; you can redistribute it and/or modify
    it under the terms of the version 2 of the GNU General Public License
    as published by the Free Software Foundation.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

ばっちり。

checkinstall のパスについて

checkinstall は /usr/local/bin にインストールされているのだが、CentOS 6.2 の場合、コマンドを sudo 経由で実行すると環境変数 PATH を引き継がないため、command not found になってしまう。

これは、一般ユーザーに依存するものを、安易に管理者権限で実行させないためのセキュリティを考慮した措置である。この方針に従うならば、コマンドは /usr/local/bin/checkinstall のようにフルパス指定で実行する。

もし、リスクを承知したうえでパス入力を省きたいなら、.user_profile に設定を追加してパスを通す。

$ cd
$ vi .user_profile

sudo に対して環境変数 PATH を継承させる設定は、以下のようになる。

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin
PATH=$PATH:/sbin
PATH=$PATH:/usr/sbin
PATH=$PATH:/usr/local/sbin

export PATH
alias sudo='sudo env PATH=$PATH'

ハイライト表示している 17 行目が sudo への設定となる。

.user_profile の変更を反映させる場合は、再ログインするか以下のコマンドを実行する。

$ source ~/.bash_profile

個人的には、sudo の実行ユーザーを限定しているのと、sudo コマンドを経由している時点でリスクの高い処理をしていることを強く意識させる効果があるので、パスを通してしまってもよいと考えている。

以降の説明は、/usr/local/bin にパスが通っているものとして書く。もしパスを通さない場合、sudo checkinstall を実行している箇所は sudo /usr/local/bin/checkinstall に置き換えること。

RPM 化

管理を楽にするため、checkinstall 自身を RPM 化する。これは checkinstall の動作テストも兼ねている。

まず、RPM 化するためのビルドを実行するディレクトリを作成する。これを用意しておかないと、RPM 化に失敗する。

$ sudo mkdir -p /root/rpmbuild/SOURCES

checkinstall をコンパイルしたディレクトリに移動して checkinstall コマンドを実行する。パッケージ方式をきかれたら、R を入力して Enter キーを押す。

$ cd
$ cd checkinstall
$ sudo checkinstall

checkinstall 1.6.3, Copyright 2010 Felipe Eduardo Sanchez Diaz Duran
           このソフトウェアはGNU GPLの下でリリースしています。

使用するパッケージ方式を選んでください。
Slackwareなら[S], RPMなら[R], Debianなら[D]を入力R

少し待つと、RPM パッケージの構成確認となる。特に変更する必要もないので、Enter キーを押して続行。

**************************************
**** RPM package creation selected ***
**************************************

このパッケージは以下の内容で構成されます:

1 -  Summary: [ CheckInstall installations tracker, version 1.6.2 ]
2 -  Name:    [ checkinstall ]
3 -  Version: [ 20120430 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ Applications/System ]
7 -  Architecture: [ x86_64 ]
8 -  Source location: [ checkinstall ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ checkinstall ]

変更するものの番号を入力してください。Enterで続行します:

しばらく待つと、RPM 化される。

Installing with make install...

... 中略

**********************************************************************

Done. The new package has been saved to

/root/rpmbuild/RPMS/x86_64/checkinstall-20120430-1.x86_64.rpm
You can install it in your system anytime using:

      rpm -i checkinstall-20120430-1.x86_64.rpm

**********************************************************************

作成された RPM のパスは /root/rpmbuild/RPMS/x86_64/checkinstall-20120430-1.x86_64.rpm となった。Version を変更しなかった場合、作成日時がファイル名にバージョンとして入る。

さっそく、RPM 化された checkinstall をインストールする。

$ sudo rpm -ivh /root/rpmbuild/RPMS/x86_64/checkinstall-20120430-1.x86_64.rpm
準備中...                ########################################### [100%]
   1:checkinstall           ########################################### [100%]

インストール情報を確認。

$ sudo rpm -qi checkinstall
Name        : checkinstall                 Relocations: (not relocatable)
Version     : 20120430                          Vendor: (none)
Release     : 1                             Build Date: 2012年04月30日 01時10分54秒
Install Date: 2012年04月30日 01時24分01秒      Build Host: akabeko.me
Group       : Applications/System           Source RPM: checkinstall-20120430-1.src.rpm
Size        : 453050                           License: GPL
Signature   : (none)
Packager    : checkinstall-1.6.3
Summary     : CheckInstall installations tracker, version 1.6.2
Description :
CheckInstall installations tracker, version 1.6.2

CheckInstall  keeps  track of all the files created  or
modified  by your installation  script  ("make install"
"make install_modules",  "setup",   etc),   builds    a
standard   binary   package and  installs  it  in  your
system giving you the ability to uninstall it with your
distribution's  standard package management  utilities.

ばっちり。

…今回はここまで。次回は Ruby と Redmine 関連のセットアップについて書く。

さくらのVPS を改めて使いはじめる 7 – WordPress

さくらのVPS(v3) 2GB プランへの環境構築メモ 7。今回はWordPress のセットアップと環境の移行について書く。

もくじ

WordPress のセットアップ

WordPress が動作するために必要な環境を準備する。ここでは、前回までの手順により MySQL と Apache が稼働していることを前提としておく。

まず、PHP 系のパッケージをひととおりインストール。

$ sudo yum install php php-mbstring php-mysql php-mcrypt php-gd php-devel php-pear php-pecl-apc

次に WordPress 用のデータベースとユーザーを作成する。今回は両方とも wordpress という名前にした。

$ mysql -uroot -p
mysql> CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8;
mysql> GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost IDENTIFIED BY 'XXXXXXXXXXXXXXXX';
mysql> FLUSH PRIVILEGES;
mysql> exit;

準備ができたので、WordPress をインストールする。日本語ローカルサイトのダウンロード欄から、最新版の URL をコピーしておく。

コピーした URL から WordPress 本体をダウンロードし、展開、インストール、所有者の変更まで実行。

$ cd
$ wget http://ja.wordpress.org/wordpress-3.3.1-ja.zip
$ unzip wordpress-3.3.1-ja.zip
$ rm wordpress-3.3.1-ja.zip
$ sudo mv wordpress /var/lib/wordpress
$ sudo chown -R apache:apache /var/lib/wordpress

ここまでの手順が完了したら、Apache の DocumentRoot 以下に WordPress をインストールしたディレクトリへのシンボリックリンクを貼る。今回は blog というサブディレクトリにしておく。

$ sudo ln -s /var/lib/wordpress /var/www/html/blog

これで Web 上に WordPress が公開された。ブラウザから http://ドメイン名/blog/ にアクセスすると、WordPress のセットアップ画面が表示されるはず。

WordPress Codex 日本語版 のインストール手順などでは wp-config.php を手動作成 & 編集する方法を紹介しているが、最近のバージョンだと WordPress が作成してくれる。

設定ファイルの作成

設定ファイルの作成

事前に必要な情報も教えてくれる。

親切な説明

親切な説明

wp-config.php に設定していた内容は、以下のように問い合わせられる。

データベース情報の入力

データベース情報の入力

サイトとユーザー情報。

サイトとユーザー情報

サイトとユーザー情報

特に難しい設定もなく、画面の指示に従ってゆくだけで WordPress を利用できるようになる。実に簡単・便利。

完了

完了

作業が完了したときの「これだけです!」というメッセージに、強い自信を感じる。

環境の移行

既に運用されている WordPress から、新環境へ移行する場合の手順を書く。

はじめに、旧環境から必要なデータをバックアップする。

データベースに MySQL を利用しているなら、その内容を mysqldump コマンドで出力する。-u パラメータにユーザー名 ( XXXX の部分 )、-p でパスワード指定、その後にデータベース名 ( wordpress の部分 ) を指定する。phpMyAdmine を利用できるなら、そちらから出力してもよい。

$ cd
$ mysqldump -u XXXX -p wordpress > wordpress.sql

次に、WordPress で利用していたテーマやプラグイン、メディア ファイルなどをバックアップする。これらは WordPress のインストール先にある wp-content ディレクトリ内へ格納されている。ファイルを個別にバックアップするのが面倒なら、wp-content を丸ごと保存してもよいだろう。

バックアップが完了したら、データの移行を開始する。

移行先の環境については、前述の WordPress 新規インストール & セットアップが完了し、移行元の WordPress データベースを出力したファイル wordpress.sql と wp-content が新環境のユーザー HOME に保存されているものとする。

まず、シンボリックリンクを消してブログを非公開にする。移行作業が終わるまで、この状態にしておく。

$ sudo rm /var/www/html/blog

以下のコマンドを実行し、データベースの作り直し & 旧データの移行を実行する。

$ mysql -uroot -p
mysql> DROP DATABASE wordpress;
mysql> CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8;
mysql> exit;
$ cd
$ mysql -u wordpress -p wordpress < wordpress.sql

もしドメイン名の変更があり、ブログの URL が変わっているならば、書き換えておく。まず WordPress のデータベースにログインし…

$ mysql -u wordpress -p wordpress

以下のような SQL を実行してゆく。私の場合、旧ドメイン ( old の部分 ) が akabeko.sakura.ne.jp、新しいもの ( new の部分 ) は akabeko.me となる。

UPDATE wp_options  SET option_value = REPLACE( option_value, 'http://old/', 'http://new/' );
UPDATE wp_posts    SET post_content = REPLACE( post_content, 'http://old/', 'http://new/' );
UPDATE wp_posts    SET guid         = REPLACE( guid,         'http://old/', 'http://new/' );
UPDATE wp_postmeta SET meta_value   = REPLACE( meta_value,   'http://old/', 'http://new/' );
UPDATE wp_usermeta SET meta_value   = REPLACE( meta_value,   'http://old/', 'http://new/' );

以上でデータベースの移行が完了した。

wp-content 以下の構成ファイルについては、移行元と新環境の WordPress バージョンが一緒なら一括で移行してもよい。心配なら個別に作業する。以下はユーザー HOME の wp-content を一括で移行させる例。

$ cd
$ sudo mv /var/lib/wordpress/wp-content /var/lib/wordpress/wp-content.original
$ sudo mv wp-content /var/lib/wordpress/
$ sudo chown -R apache:apache /var/lib/wordpress/wp-content

元々あった wp-content を wp-content.original にリネームしてから、移行元のものに置き換えている。もし移行したもののファイルに不足があった場合は、wp-content.original から持ってくる。移行して問題なければ、wp-content.original は消しても良い。

すべてのデータを移行し終えたなら、シンボリックリンクを貼ってブログを公開する。

$ sudo ln -s /var/lib/wordpress /var/www/html/blog

正しく移行できているなら、ブラウザから http://ドメイン名/blog/ にアクセスすることで新ブログが表示される。また、ユーザー情報やパスワードも引き継がれているので、いままでどおりログインできるはず。

もし状態がおかしい場合は、データベースや wp-content 内のファイル構成を確認すること。

備考

その他の移行作業や考察、遭遇したトラブルなどを記録しておく。

301 リダイレクト

ドメイン変更により URL が変わったので、旧サイトから新サイトへ 301 リダイレクトするようにした。

旧ブログはさくらのレンタルサーバー スタンダードで稼働していたので、Web サーバーは Apache になる。また、.htaccess も有効だ。よって、以下の内容を記述した .httaccess ファイルをサイトのルートに配置。

Redirect 301 / http://akabeko.me/

これで旧サイトへのアクセスは、すべて新しいものに変更される。301 リダイレクトは Google のウェブマスター ツールでも、サイト移転の方法として推奨されている。

リダイレクトを開始すると、Google 検索の結果も新しい URL に切り替わってゆく。私の場合、2 週間ほどで主要なページの URL が変更されることを確認できた。

外部サービスに登録している URL 変更

ブログの移転にともない、外部サービスのユーザー情報などに登録している URL を変更したのだが、いくつか気になるものがあったので、それについて書く。

WordPress.com Stats や Akismet のように、WordPress.com の API キーを必要とするプラグインは、前のものがそのまま利用できる。Stats の登録 URL を変更した場合、前のアクセス解析を引き継いでくれるのは地味にありがたかった。

Zenback は URL を変更する術がないようなので、いままでのものを削除して、新しい URL を登録し直した。

あわせて読みたいは、そもそも URL 変更という概念がないらしい。ブログパーツを外すことで退会 ( 解除 ) し、新しいサイトについては改めて登録が必要となる。

ただし登録はしてみたものの、WordPress のあわせて読みたいプラグインがデータを取得してくれない。はじめは開発 API で説明されている、以下の事情によるものだと思っていた。

なお、2010年秋のバージョンアップ以降の登録ユーザーについては、このJSONP配信機能は現在準備中です。

しかし、この条件にあたりそうなサイトでも JSONP を取得できているところがあるので、集計期間の問題だと推定。しばらく標準ブログパーツ ( 画像になっているもの ) を配置して様子を見ることにした。

この対応が正しかったのかは謎だが、4 月の半ばあたりからプラグイン側でもデータ取得できるようになったので、標準ブログパーツは削除した。

WordPress のアップロード ディレクトリ

新ブログのほうで画像をアップロードしようとしたら、エラーになった。ググってみると、wp-content/uploads のパーミッションが原因という指摘がたくさん見つかるのだが、その点については問題なかった。

途方にくれつつ、エラーメッセージをよく見ると….

“example.png” は、エラーのためアップロードに失敗しました
ディレクトリ /home/XXXX/www/blog/wp-content/uploads/2012/04 を作成できませんでした。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか ?

なんだかパスがおかしい。wp-content/uploads の前に余計なディレクトリが付いている。

さくらのレンタルサーバーは、DocumentRoot がユーザー HOME 直下の www ディレクトリに割り当てられるため、WordPress のインストール先もその下になる。どうやらその設定を引き継いでしまったようだ。

というわけでパスを変更する。WordPress の管理画面から「設定」→「メディア」を開き、「アップロードするファイルの保存場所」欄の内容を標準の wp-content/uploads に設定。すると、無事、アップロードに成功した。めでたしめでたし。

…今回はここまで。次回は checkinstall のセットアップについて書く。