Home > Tags > git

git

WordPress を最新版にアップグレードするときのメモ

openbooth.org は今現在(2009-06-01) ブログシステムに WordPress を使用しています。WordPress を使っている理由はプラグインが豊富でかつ、まだ開発が活発なのでずーっと使い続けていけるかなぁと思ったからです。

ただ開発が活発な分、システムをアップグレードする時の不安はあります。「システムのアップグレードに失敗したらどうしよう」といった。アップグレードする際に、事前にバックアップを取っておけば良いのでしょうが、面倒臭く感じてしまう。あまりコピーを持っておきたくないのです。

という背景があるので、今はこのシステム自体を Git でバージョニングしています。別に Git である必要はないのですが (Subversion でも Bazaar でも…) このブログを開設した当時「これはいい」と思ったバージョン管理システムが git だったのでそれを使ってます。

以下はシステムアップグレードの際の作業メモです。

% cd ~/public_html_openbooth.org/public
% git commit -m 'for now'
% git tag -a wp2.6.3 # 念のためタグ付けして、パッチあてに失敗したときのための保険としておく

% cd
% mkdir workspace
% cd workspace
% wget http://ja.wordpress.org/wordpress-2.6.3-ja.zip # 現在のバージョンのコードをダウンロード
% wget http://ja.wordpress.org/wordpress-2.7.1-ja.zip # アップグレードしたいバージョンのコードをダウンロード
% unzip wordpress-2.6.3-ja.zip
% mv wordpress wordpress-2.6.3
% unzip wordpress-2.7.1-ja.zip
% mv wordpress wordpress-2.7.1
% diff -urN wordpress-2.6.3 wordpress-2.7.1 > wp2.6.3_to_wp2.7.1.patch # 2つのバージョン間の差異を取ってパッチを作る

% cd ~/public_html/openbooth.org/public
% patch -p1 < ~/workspace/wp2.6.3_to_wp2.7.1.patch # パッチをあてる

ここまで終わったら動作確認。正常に稼動していたら

% git commit -m 'upgrade to wordpress-2.7.1'

で変更をコミットしておく。

上手く動かなかったら

% git checkout -f

でシステムをパッチ適用前に巻き戻す。バージョニングしていると、「やりなおし」が効くので便利ですね。
バージョン管理システムは素晴しい保険だ!

gitosis - Git リポジトリ群の管理とアクセス制御 vol.2

gitosis - Git リポジトリ群の管理とアクセス制御 vol.1 の続編です。

前回までで、gitosis のインストールと疎通確認まで終わりました。もしエントリの通りに手を動かしていれば、手元には gitosis-admin.git のクローンがある状態のはずです。このエントリは gitosis の設定編ということで、gitosis-admin.git の説明をしていきます。

gitosis はアカウント情報やアクセス制御の情報を gitosis-admin.git を用いて管理します。アカウントの追加や削除やアクセス制御の変更を行うときには、僕たちは gitosis-admin.git の内容を変更することになります。

gitosis の設定変更の基本は以下の2ステップです。

  1. ローカルで gitosis-admin ディレクトリ以下のファイルを追加/変更/削除
  2. サーバ上の gitosis-admin.git に反映(git push)

それでは、まずはサーバ上の gitosis-admin.git を git clone して、ディレクトリ階層を見てみます。まだ gitosis-admin.git を手元に落としていない場合は以下の操作で手元に落としておきます。

local% git clone ssh://git@remote-name.com/gitosis-admin.git

ディレクトリの中を眺めてみます。以下のような構成になっており、非常に単純です。

gitosis-admin
|-- gitosis.conf # アクセス制御用の設定ファイル
`-- keydir
    `-- keiji.pub # 登録されてるアカウントの公開鍵、keiji.pub は gitosis-init で指定した公開鍵

では gitosis.conf と keydir を個別に見ていきます。

gitosis.conf
gitosis.conf の中身は INIっぽいフォーマット で記述されいます。初期状態では以下のように自分自身(gitosis-admin)の設定のみが記述されています。

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = keiji

上記の内容は、ユーザ keiji がサーバ上のリポジトリ gitosis-admin.git を編集可能(writable) であることを定義しています。リポジトリコンテナの管理アカウントは、現時点では keiji のみとなります。

それでは、fred というアカウントを追加してこのアカウントがリポジトリコンテナの管理者としてふるまえるようにしてみます。

まずは上記 gitosis.conf の内容を編集します。

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = keiji fred

gitosis.conf の変更はこれだけです。簡単ですね。

ですが、これだけでは fred は git clone ssh://git@remote-name.com/gitosis-admin.git することはできません。fred はまだ gitosis のアカウントとして認証されていないからです。ここでようやく keydir の出番です。

keydir
keydir ディレクトリは認証された gitosis アカウントの公開鍵一覧を含みます。現時点では gitosis-init を実行したときに登録された最初のアカウント(keiji の公開鍵 keiji.pub)のみ登録されています。fred アカウントを有効にするには fred の公開鍵を keydir 以下に保存する必要があります。

ここでは仮に fred から公開鍵 id_rsa.pub を受け取ったとします。この鍵を gitosis-admin/keydir に保存します。

local% ls -F
id_rsa.pub gitosis-admin/
local% mv id_rsa.pub fred.pub
local% mv fred.pub gitosis-admin/keydir/
local% ls gitosis-admin/keydir/
keiji.pub fred.pub

id_rsa.pub のファイル名を変更したのには理由があります。gitosis はアカウント名として公開鍵のファイル名から拡張子 .pub を除いた部分を使用します。そのため keydir に保存するときは、公開鍵のファイル名を gitosis.conf で指定したアカウント名と併せておく必要があるのです。

さて、現時点ではローカル上では fred が存在して、サーバ上には存在しない状態です。これをサーバ上の gitosis-admin.git に反映する必要があります。ここからは git オペレーションになります。

local% cd gitosis-admin
local% git commit -a -m "account 'fred' added. this account is administrator."
local% git push

git push が上手くいけば、サーバ上の設定ファイルが自動的に更新されて fred が有効になります。1

これで fred は gitosis-admin.git をクローンすることができるようになっているはずです。fred ユーザで試してみます。

local% sudo su - fred
local% mkdir -p workspace/hosting-self
local% cd workspace/hosting-self
local% git clone ssh://git@remote-name.com/gitosis-admin.git
Initialized empty Git repository in /home/fred/workspace/hosting-self/gitosis-admin/.git/
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 24 (delta 6), reused 3 (delta 0)
local% ls -F
gitosis-admin/

上記のように gitosis-admin.git をクローンできれば成功です。2

ここまでで、アカウント追加の作業は終了です。

次は、現在存在するアカウント(keiji, fred)にそれぞれプライベートな(それぞれ自分だけが編集できる)リポジトリを与えてみます。gitosis.conf を以下のように変更して git push します。

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = keiji fred

[group keiji]
writable = private/keiji
members = keiji

[group fred]
writable = private/fred
members = fred

これで keiji は private/keiji.git、fred は private/fred.git。というリポジトリを与えられました。gitosis はコンテナ内にディレクトリ階層を作れるというのがポイントです。ここでは private というディレクトリを掘ってみました。private という名前に特に意味はありません(hoge でも fuga でも何でも良い)。

ただし gitosis.conf を push したら、サーバ上のコンテナに勝手に Git リポジトリが作られるわけではありません。単に push する権限を与えられるだけです。

ということで private/keiji の領域に収める Git リポジトリを作ってみたいと思います。まずはローカルの keiji ユーザで新しい Git リポジトリを用意します。

local% mkdir private-repo
local% cd private-repo
local% git init
local% git remote add origin ssh://git@remote-name.com/private/keiji.git
local% echo 'This git repository is private.' > README
local% git commit -a -m 'Initial commit'

git remote add ssh://git@remote-name.com/private/keiji.git の指定が重要ですので間違えないように気をつけて下さい。そうしたら後は git push するだけです。

local% git push origin master

サーバ上に存在しないリポジトリを push すると、gitosis は以下のプロセスを経てリポジトリを同期します。

  1. コンテナ内にリポジトリが存在するかをチェック
  2. gitosis.conf に記述されているリポジトリ名かチェック
  3. 権限はあるかチェック
  4. Bare リポジトリを新しく作成
  5. git push されたリポジトリの内容とコンテナ内のリポジトリを同期

これで gitosis の一連の操作はカバーできたかなという感じがします。まだ触れていないものは、(現時点で僕が把握してる限り)以下の5つですね。

  • アカウントの削除
  • リポジトリの削除
  • gitosis.conf のその他の細かい設定
  • git-daemon について
  • gitweb について

gitosis はリポジトリの削除はサポートしないようです。まぁ、削除は危険ですからね。リポジトリを本当に削除したい場合はサーバにログインして rm -rf すればいいでしょう。アカウントの削除は、単純に keydir ディレクトリから該当の公開鍵を削除して git push すれば ok です。簡単ですね。

git-daemon と gitweb については試してないので説明はできません。gitosis.conf の細かい設定については git://eagain.net/gitosis.git の中にある example.conf を見て頂ければ分かるでしょう。

ひとまずこれで終わりですが、gitosis 側で個々のリポジトリのフックを操れるようになれば post-receive にメール送信を仕込むとかより簡単に設定できるようになると思ってるので、今後ちょくちょく gitosis をいじっていくかもしれません。

  1. gitosis は git をトランザクション機能のあるミラーリングツールとして上手く使っているなと感じます。gitosis は git の post-update と post-receive フックを上手く使ってサーバ上の設定ファイルを更新しています
  2. 「これではきちんとアクセス制御できているか分からない!」と感じる人がいると思います。そういう人は fred でクローンした gitosis-admin の gitosis.conf から fred の権限を削除して git push して、git pull してみると良いと思います。git push は成功しますが、git push した後の git pull は失敗するはずです。

gitosis - Git リポジトリ群の管理とアクセス制御 vol.1

gitosis - Git リポジトリ群の管理とアクセス制御 vol.0 の続編です。

前回のエントリでは、Git リポジトリの管理に対する不満と、それを少し改善してくれる gitosis を簡単に紹介をしました。このエントリでは gitosis のインストール編ということで話を進めていきます。

基本的に Hosting Git repositories, The Easy (and Secure) Way のエントリと同様です。本家の方が安心という人はそちらのエントリをどうぞ。

サーバ/クライアント(ローカル)両方で作業する必要があるので、識別しやすいように以下の表記をします。

サーバ作業のプロンプト表記

remote% 

クライアント(ローカル)作業のプロンプト表記

local% 

また、サーバアドレスを便宜上 remote-name.com とします。

まずは Git リポジトリをホストするサーバに git 及び gitosis をインストールします。サーバにログインしてインストールを開始します。

local% ssh keiji@remote-name.com
remote% sudo aptitude install git git-core
remote% sudo aptitude python python-setuptools # gitosis は python で書かれてるため必要に応じてインストールする。
remote% mkdir ~/src
remote% cd ~/src
remote% git clone git://eagain.net/gitosis.git
remote% cd gitosis
remote% sudo python setup.py install # gitosis をシステムにインストールする。

ここまでで gitosis のインストールは終了。僕は ubuntu 8.04 server edition で試していますが特に問題なくインストール完了しました。

次に、サーバ上にホストする Git リポジトリの管理用ユーザを作成します。gitosis は ~/.ssh/authorized_keys をいじる(生成する)ので、~/.ssh/authorized_keys を編集している場合は gitosis によって勝手に上書きされてしまって「うわーん」な状況になってしまいます。そのため Git 用に新しくユーザを作った方が無難です。

そういうことで、ここでは git ユーザを作成します。このユーザは公開鍵によるログインしか行わないのでパスワードログインは無効にしておきます。

remote% sudo adduser
--system
--shell /bin/sh
--gecos 'git version control'
--group
--disabled-password
--home /home/git
git

git ユーザの作成が完了したら、gitosis が管理する Gitリポジトリコンテナ1 を作成します。このコンテナを作成するには、少なくとも一つはアカウントを登録しなければなりません(ここで登録するアカウントはコンテナの管理アカウントになります。管理アカウントは後で変更できます)。gitosis は公開鍵 によってアカウントを識別するので、まずは自分自身のアカウントを作るために自分の公開鍵をサーバに転送することにします(公開鍵を持っていない場合は適宜作成する)。

local% % scp ~/.ssh/id_rsa.pub keiji@remote-name.com:/home/keiji # 自分の公開鍵をサーバに転送

さて、ようやく gitosis のリポジトリコンテナを作成するときがきました!コンテナの作成には gitosis に付属する gitosis-init スクリプトを使用します。このスクリプトは gitosis のインストールが完了していれば、既にシステム上に存在しているはずです。

% sudo -H -u git gitosis-init < /home/keiji/id_rsa.pub # gitosis-init を用いて先程転送してきた鍵を登録。上で作ったユーザ(git)で実行
Initialized empty Git repository in ./
Initialized empty Git repository in ./
% sudo ls /home/git # git ユーザのホームディレクトリに gitosisrepositories という二つのディレクトリが作られてる
gitosis  repositories

gitosis-init を実行すると /home/git は以下のファイルとディレクトリが作られているはずです。

/home/git/
|-- .gitosis.conf -> /home/git/repositories/gitosis-admin.git/gitosis.conf
|-- .ssh
|   `-- authorized_keys # gitosis-admin.git の内容が push されると、gitosis-admin.git の内容に応じて再生成される
|-- gitosis
|   `-- projects.list
`-- repositories
    `-- gitosis-admin.git

そして最後に gitosis がアクセス制御に使用する Git リポジトリ(gitosis-admin.git) に含まれる post-update フックスクリプトのパーミッションをチェックしておきます。post-update フックスクリプトには実行権限が付与されている必要があります。通常 755 になっているはずですが、なっていなかったら適宜 chmod して下さい。これは重要な作業です。

パーミッションが以下のようになっていれば問題ありません。

remote% sudo ls -l /home/git/repositories/gitosis-admin.git/hooks/post-update
-rwxr-xr-x 1 git git 69 2008-11-06 15:26 /home/git/repositories/gitosis-admin.git/hooks/post-update

これでサーバ上のリポジトリコンテナのセットアップは完了!
クライアントからこのリポジトリコンテナにアクセスできるかどうか試してみます。

local% mkdir -p ~/workspace/hosting-self
local% cd ~/workspace/hosting-self
local% git clone git@remote-name.com:gitosis-admin.git # or ssh://git@remote-name/gitosis-admin.git

gitosis-admin.git を git clone することができれば完了です。

gitosis-admin.git リポジトリについて簡単に説明します。 このリポジトリはアカウントを登録/削除したり、アクセス制御を設定するために使用します。アカウントを追加登録したい場合には、リポジトリ内の keydir ディレクトリ以下に追加アカウント用の公開鍵を git add することで行います。アクセス制御を設定するにはリポジトリ内にある gitosis.conf を編集します。

もちろん、この gitosis-admin.git リポジトリ自体もアクセス制御の対象です。

gitosis-admin.git については次のエントリでもう少し詳しく紹介します。

  1. 複数の Git リポジトリを収容するという意味で僕が勝手にリポジトリコンテナと表現した

gitosis - Git リポジトリ群の管理とアクセス制御 vol.0

最近流行りの Git。現段階で github 等のホスティングサービスを使う人が多いと思います(もしくはローカルだけで使ってるか)。github のようなホスティングサービスを使っている場合は、github 自身がリモートリポジトリの管理をしてくれるため、ssh の鍵を github に登録するだけで僕たちは Git の恩恵に預ることができます。リポジトリの操作は大概 github のウェブアプリケーション越しで済んでしまいます。楽です。

しかし、このリモートリポジトリを自前のサーバでホストする、あるいは企業のバージョン管理ツールとして Git を使うとなると俄然敷居が高くなるように感じます。github のウェブアプリケーションとその周辺ツールがオプソで公開されていれば非常に嬉しいのですが、まぁ現時点ではそんなおいしい話はない訳で、ないものねだりになってしまいます。

そのため、特に企業で導入する際にはリポジトリ群を管理するスクリプトを自前で作る必要がでてきます。というのも、リポジトリの管理スクリプト(例えば、ローカルにあるリポジトリをリモートに配備する、リモートのリポジトリを削除する等々…)がないと、新しいプロジェクト用にリポジトリを作成する度に一々サーバにシェルログインして git init –bare hoge.git とかしなければならなくて非常に面倒です。しかも、皆がリポジトリをホストしているサーバにログインできる状態はセキュリティ的にも酷い状況になり良くありません(これは git-shell 使うという手はあります)。

僕もこのGitリポジトリ群の管理に関しては何か良い管理ツールはないものかと探していました。ですが、すぐに良いものを見つけることができなかったので、必要に迫られて結局自前でスクリプトを書くことにしました。サーバにリポジトリを作成して git remote add してサーバ側の bare リポジトリに push するとか、サーバ上に存在するリポジトリ一覧の URL を取得するとか、リモートリポジトリを削除するとか、そんなタスクをコマンド化しました。(中途半端な状態で開発止まってしまってますけどね…)

Git は、それを使ってプロジェクトのバージョン管理をするといった面ではブランチをバンバン切って、それらのブランチを簡単にマージすることができるので快適で良いです。好きです。Git を使って何かを開発している時はね。

開発中に恩恵をくれる Git も、リポジトリ自体を管理するということになると面倒になる(リポジトリの数が増えれば増える程しんどくなる)。責務の切りわけという意味で正しいですけど、Git 自体はそこをサポートしてくれません。

ここに一つ、Git 導入への壁が存在するような気がします。

さて、ここからが本題です。Git 導入には上に書いたような問題があります(少なくとも僕はそう思ってる)。これは解消しておきたいと思い、自分でそれっぽいもの作ったり、ググってそれっぽいものがないか調べたりしてきました(ごく最近ですけどね)。

そんなこんなでようやく gitosis というソフトウェアを見つけました。前フリがやたらと長くなってしまいましたが、このエントリは、この gitosis を紹介するというのが主旨です。

gitosis について書かれてるブログエントリの一部を引用します。

Hosting Git repositories, The Easy (and Secure) Way

how to host and manage Git repositories with access control, easily and safely. I use an up and coming tool called gitosis that my friend Tv wrote to help make hosting git repos easier and safer. It manages multiple repositories under one user account, using SSH keys to identify users. However, users do *not* need shell accounts on the server,

まじ!僕が欲しかったものですよ。エントリの上記の部分を読んで思わずニヤッとしてしまいましたw

gitosis にはこんな特徴があるようです。

  • リポジトリに対するアクセス制御
  • 安全 # 認証は公開鍵で行い、通信にはSSHを使う。設定が簡単かどうかは人によるので一概に簡単とは言えない
  • 一つのアカウントで複数リポジトリを管理 # もちろん複数アカウントでも運用できる
  • 公開鍵でユーザを識別する
  • リポジトリにアクセスするアカウントはサーバへのログインを許可されてなくてイイ! # 自分で ~/.ssh/authorized_keys を管理する必要はない

これを知らずに自前でスクリプト書いてしまったことを悔やむ。しかもリンク先のエントリは去年のだし…無念

無念なのは別に良いとして、良いもの見つけたので早速使ってみました。エントリが長くなってきたので次回に持ち越しますが、gitosis のインストールや設定やらをエントリにしておこうと思います。↑のエントリ読めば使えますけどね…

gitosis については何回かに分けてエントリを書きます。

  1. gitosis - Git リポジトリ群の管理とアクセス制御 vol.1
  2. gitosis - Git リポジトリ群の管理とアクセス制御 vol.2

インストール済みの Git を 1.6 系にアップグレードする

Ubuntu 8.04 のパッケージリポジトリから Git をインストールすると 1.5.4 くらいのバージョンのものが入ります(2008-10-07now)。1.6系は既にリリースされているようですが、特に必要に迫られることもなかったのでそのまま 1.5 系を使っていました。しかし、今日 git.git のクローンを久々に git pull したらかなりの変更がおっこちてきました。そのうち、graph.c というファイルが追加されていたので試しに最新版の Git をビルドして使ってみました。

すると git log --graph --pretty=oneline で、前から「こんなのあったらいいなぁ」と思ってた表示形式でログを一覧できることが分かりました。こんな表示。

*   38f7950acc657b03265c488b301fd779a4d09512 Merge branch 'branch-a'
|\
| * 54a96d32e7add6d89532666bf6f39ac322d2da42 modified
* | 4a3cd0a96e26684bdc17336f451f355b37aa43f5 MANIFEST.SKIP file added
* | 17636f86133c3dc6cb6d78d7ee9d2c6671042388 modified at master
|/
* 7f5bf37677b166506a209b215274510316bec791 initial

ということで最新版をインストールすることにしました。ただ、ソースからビルドすると後々管理が面倒になるので、Git 1.6 の debパッケージをホストしてるリポジトリを探してインストールすることに。以下は Git 関係のパッケージをアップグレードする手順です。

まず、/etc/apt/sources.list に Git の最新版をホストしてるリポジトリを追加します。以下の二行を追加します。hardy 以外のバージョンを使ってる場合は適宜 https://launchpad.net/~smartlounge/+archive から探すと良いと思います。

deb http://ppa.launchpad.net/smartlounge/ubuntu hardy main
deb-src http://ppa.launchpad.net/smartlounge/ubuntu hardy main

次に、 インストール作業。

% sudo aptitude update
% sudo aptitude safe-upgrade
% sudo aptitude install git-core gitk git-gui git-doc

これでパッケージの更新は終わり。 apt 素晴らしい。ただし、今回はサードパーティのリポジトリを追加しているのでインストール途中に脅されます。

警告: 以下のパッケージは信頼できないバージョンがインストールされます!

信頼できないパッケージはシステムのセキュリティを危うくする可能性があります。
自分がこのインストールを望んでいると確信できる場合のみ、インストールを先に進め
てください。

git-gui gitk git-core

この警告を無視して意地でも先に進みますか?
続行する場合は "Yes" を、中断する場合は "No" を、入力してください:

ですが承知の上ですので、サクっと Yes と応えました。

念のため、ちゃんと最新のバージョンが入ったかどうか確認しておきました。

% git --version
git version 1.6.0.2

ちゃんと入ったみたいです。 zsh 用 completion の更新はどうすれば良いか分かってないのでそのままです。completion は非常に重宝してる(というか無いと非常にイライラする)のではやいところ方法を見つけたいところです。

Home > Tags > git

Search
Feeds
Meta

Return to page top