いまさらCentOS3.9 serverをインストール

いまさらだが、CentOS3.9 Serverをインストールする機会があった。
OS自体のインストールが終わった後、追加プログラムをインストールするために、yumからgccをインストールする。

# yum install gcc

ところが、署名が検証できない、みたいなメッセージで失敗する。（ごめん、またメッセージを転記しておくの忘れた！）
そこで次のコマンドで署名を取得。

# rpm --import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-3

これで先ほどのyum install gccは問題なく進む。
前からこんなだっけ？

レンタルサーバー上にSubversionを入れる

以前メインにしていた別のブログに、「SAKURAインターネットのレンタルサーバーにSubversionを導入する方法」について書いた。
その続編としてサーバーのSubversionのバージョンを上げた顛末について書こうと思う。

今回、BlackBerry Boldでの辞書アプリを開発するにあたり、EB4JというOSSのライブラリを改変して利用している。
このEB4JのライセンスはLGPLのため、改変したライブラリもLGPLで公開しなければいけない。じゃあ、どこで公開するかということで、SourceForgeとGoogle Codeで迷ったが、近い将来に仕事でGoogle Codeを使う必要がありそうなので、その練習も兼ねてGoogle Codeを選択した。

ところがeclipseからコミットしようとするとエラーになる。
（エラーメッセージは記録していない。ごめん。）

ネットで情報収集してみると、eclipseにインストールされているSubclipseプラグインのバージョンが古いのが原因のようだ。

(A) Subclipse 1.2.x ---> Subversion1.4
(B) Subclipse 1.4.x ---> Subversion1.5
(C) Subclipse 1.6.x ---> Subversion1.6

という対応関係になっているのだが、今回は、サーバー側（Google）が1.5.4(B)に対して、1.2.xのSubclipse(A）からコミットしようとしていた。
じゃあクライアントをバージョンUPすればいいじゃん、ということになるのだが、実はこのeclipseからSAKURA上にあるSubverionサーバーも利用していてそのサーバーが1.4.3（A)なのである。Subversionのサイトを見ると互換性についていろいろ書かれているが、いまいち不安。
じゃあ、いっそのことSAKURAのほうをバージョンUPしてしまえ、ということでその手順。

まずはサーバー側。
Subversionはバージョンが異なるとリポジトリの構成も異なるので、ちゃんとバックアップしないとあとから復元できなくなる。
レンタルサーバーにSSHでログインし、次のようにしてバックアップを取得する。

svnadmin dump $HOME/svn-respos/projects | bzip2 > svn-projects.dump.bz2

Subversionのダウンロードとコンパイルを実行する。GoogleにあわせてSubversionは1.5.4にした。

mkdir -p $HOME/local/src
cd $HOME/local/src

wget http://subversion.tigris.org/downloads/subversion-1.5.4.tar.bz2
wget http://subversion.tigris.org/downloads/subversion-deps-1.5.4.tar.bz2

tar xvf subversion-1.5.4.tar.bz2
tar xvf subversion-deps-1.5.4.tar.bz2

cd subversion-1.5.4
./configure --prefix=$HOME/local/subversion --without-serf

make
make install

インストールが終わったらコマンドが使えるようにするために、.cshrcを編集してインストール先（$HOME/local/subversion/bin）にPATHを通す。必要があれば再ログインする。

次にリポジトリを復元する。

mkdir $HOME/svn-repos
svnadmin create $HOME/svn-repos/projects
bzcat svn-projects.dump.bz2 | svnadmin load $HOME/svn-repos/projects

復元が終わったら、eclipseにSubclipseの最新版を入れて完了となる。

この手の情報って探している人が多いので、参考までに、クライアント側のセットアップ手順も全部書いておく。

まずはサーバー側の公開鍵とクライアント側の秘密鍵を作成する。
今回はsshクライアントにはTortoiseSVNに含まれているTortoisePlink.exeを、鍵生成にはPuTTYgenを使う。それぞれのソフトはググって探す。

    1. PuTTYgenを起動し[Generate]ボタンをクリック。
    2. マウスを適当に動かして鍵を生成。
    3. Public key for pasting･･･というテキストエリアの内容を$HOME/.ssh/authorized_keysにコピペする。
    　ファイルがなければ作成するが、.sshディレクトリのパーミッションは0700でauthorized_keysファイルのそれは0600にする
    4. PuTTYgenでKey passphraseは入れないで[Save private key]ボタンを押して秘密鍵を保存する。
    　警告が表示されるが、今回は無視。また秘密鍵の保存先は任意でいいが、例えばC:\Sakura\id_rsa.ppkファイルに保存する。

次にスタートアップにC:\Program Files\PuTTY\pageant.exeのショートカットを登録して、Windows起動時に自動起動するようにする。
その際、ショートカットのプロパティで、リンク先に"C:\Program Files\PuTTY\pageant.exe" "C:\Sakura\id_rsa.ppk"と設定すると良い。

次に、マイコンピュータのプロパティから、システム環境変数に

SVN_SSH = "C:/Program Files/PuTTY/TortoiseSVN/TortoisePlink.exe"

を設定しておく。（""で囲む必要あり。）

これでSubclipseがTortoisePlinkを起動し、pageantが先ほど作成した鍵を使用して認証してくれる。

最後にeclipseからリポジトリに接続して検証してみよう。
リポジトリロケーションの新規作成を選択して、

svn+ssh://サーバーのユーザー名@サーバーのIPアドレス/$HOMEのパス/svn-repos/projects

と入力してみる。
復元した内容が表示されれば成功だ！

ちなみに以前も書いたのだが、レンタルサーバーは普通何人のユーザーで共有しているので、ポートが競合するんじゃないか、などと心配してしまうかもしれない。しかしSubversion 本家サイトの説明に書かれているとおり、SSHで接続することにより、その接続にのみ有効なSubversionのプロセス（svnserve）が起動するので、全く問題なく動作する。
SAKURAのレンタルサーバ（スタンダード）は年6,000円で容量3GBというなかなか良心的な価格になっているので、個人的には気に入っている。

なお、BlackBerry用のライブラリは、ここ で公開している。