Home > server Archive
server Archive
Slicehost to Linode
- 2009-12-05 (土)
- server
openbooth.org をホストするサーバを Slicehost から Linode に変更しました。理由はもちろんレスポンスタイムの向上です(特に ssh アクセス時)。計ってはいませんが、おそらく当サイトを http でアクセスする際のレスポンスタイムも向上しているはず。
Linode を契約したのは大分前(2009-07頃)ですが、忙しさが続いて中々移行することができませんでした。ようやく bzr のリポジトリも含めて移行が完了しそうです。
- Comments: 0
- Trackbacks: 0
WordPress を最新版にアップグレードするときのメモ
- 2009-06-01 (月)
- server
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
でシステムをパッチ適用前に巻き戻す。バージョニングしていると、「やりなおし」が効くので便利ですね。
バージョン管理システムは素晴しい保険だ!
- Comments: 0
- Trackbacks: 0
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 ユーザのホームディレクトリにgitosisとrepositoriesという二つのディレクトリが作られてる 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 については次のエントリでもう少し詳しく紹介します。
- 複数の Git リポジトリを収容するという意味で僕が勝手にリポジトリコンテナと表現した ↩
- Comments: 0
- Trackbacks: 4
gitosis - Git リポジトリ群の管理とアクセス制御 vol.0
- 2008-11-08 (土)
- server
最近流行りの 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 については何回かに分けてエントリを書きます。
- Comments: 2
- Trackbacks: 2
iptables の設定を変更する際の作業手順
- 2008-11-08 (土)
- server
自分用メモ。
/etc/iptables.up.rulesに、現在の設定情報を退避させる。/etc/iptables.test.rulesに、現在の設定情報を保存して、変更内容をこのファイル(/etc/iptables.test.rules)に記述する。- 変更した
/etc/iptables.test.rulesの内容をシステムに反映してみる。 - 設定内容が ok なら
/etc/iptables.up.rulesに現在の設定内容を保存する。
上記一連の作業をターミナル上で作業すると。
% sudo sh -c "iptables-save > /etc/iptables.up.rules"
% sudo sh -c "iptables-save > /etc/iptables.test.rules"
% sudo vim /etc/iptables.test.rules
% sudo iptables-restore < /etc/iptables.test.rules
% sudo iptables -L
# /etc/iptables.test.rules が ok なら
% sudo sh -c "iptables-save > /etc/iptables.up.rules"
因みに /etc/iptables.up.rules はシステムを再起動した際に(iptables によって)自動的に読み込まれるファイル。こいつにメモリ上にしかない設定内容を保存しておかないと、システムを再起動した際に全て破棄されてしまう。
- Comments: 0
- Trackbacks: 1
Home > server Archive
- Search
- Feeds
- Meta