2011-10-22 Git
■[開発][ソフトウェア][Linux][Git] git-daemon と xinetd 
CentOS 6 で xinetd を介して git-daemon を利用するとうまくうごかなかった。
なんとかうごくようになったが、なぜうまくいかなかったのか原因がはっきりわからない。また、自分がやった対応が妥当なものかも自信はない。
ただ、とりあえず、自分とおなじようにすれば、うごくようになる環境はあると思われる。
git プロトコルでのアクセスはリードオンリーにしておくのがよくて、cloneとかが成功すればいい、push が失敗しても気にしないでおく、というのでもいいかもしれないが、なんか気になったので、いろいろと試行錯誤した。
リモートリポジトリ用マシン
リモートリポジトリ用マシンは Oracle VirtualBox の仮想マシンとして構築した。
- 仮想マシン
- ホストOS Windows 7 x64 の Virtual Box 4.1.4 上の仮想マシン。
仮想マシンは「オペレーティングシステム"Linux"。ヴァージョン"Rad Hat(64 bit)"」として構築した。 - OS
- CentOS 6。Minimum でインストール。
yum update はかけた。VBoxLinuxAdditions はインストールした(X Window Systemを入れていないので、X関連のVBoxLinuxAdditionsは入っていない)。 - IPアドレス
- 192.168.108.3
- Git
- v1.7.1(CentOS 6 リポジトリのもの)とv1.7.6.1(RPMForge extras リポジトリのもの)を試した。
試行錯誤と、その結果
リモートリポジトリのベースディレクトリーは "/var/lib/git" である。"/var/lib/git" のオーナーは以下のように設定した。
グループ:git
ユーザー:git
ユーザー git は git-daemon 用のユーザーとしてのみ利用し、作業は別のユーザーで行った。
なお、実験に使ったリポジトリのディレクトリーは "test0001.git" であり（フルパスで"/var/lib/git/test0001.git"）、実験のたびに作り直している。テスト時には下のようなシェルスクリプトを書いて、リポジトリの作成や、コピーをしていた。
if test -d test0001.git; then rm -Rf test0001.git fi mkdir test0001.git git init --bare test0001.git
if test -d /var/lib/git/test0001.git; then
rm -Rf /var/lib/git/test0001.git
fi
cp -Rf test0001.git /var/lib/git
chown -R git:git /var/lib/git/test0001.git
下のようにコマンドを叩いて、 git-daemon を起動した。
# 実行例1 $ sudo -u git git daemon --base-path=/var/lib/git --export-all --enable=receive-pack --reuseaddr --port=9418
# 実行例2 $ sudo -u git /usr/libexec/git-core/git-daemon --base-path=/var/lib/git --export-all --enable=receive-pack --reuseaddr --port=9418
実行例1、2のときは、リモートリポジトリへの push は成功した。
# リモートリポジトリへの push 。 $ git push git://192.168.108.3/test0001.git master
そのときに出力されたメッセージは下のようなもの。
$ git push git://192.168.108.3/test0001.git master Counting objects: 34, done. Delta compression using up to 8 threads. Compressing objects: 100% (18/18), done. Writing objects: 100% (34/34), 9.12 KiB, done. Total 34 (delta 2), reused 0 (delta 0) To git://192.168.108.3/test0001.git * [new branch] master -> master
確認に clone も行ってみた。これも成功した。（出力されたメッセージは省く）
# リモートリポジトリからのクローン clone 。 $ git clone git://192.168.108.3/test0001.git
ところが、 xinetd を介して git-daemon コマンドを起動すると push に失敗する。以下のようなメッセージが出力される。
$ git push git://192.168.108.3/test0001.git master Counting objects: 34, done. Delta compression using up to 8 threads. Compressing objects: 100% (18/18), done. fatal: Writing objectsThe remote end hung up unexpectedly: fatal: sha1 file '<stdout>' write error: Connection reset by peer error: failed to push some refs to 'git://192.168.108.3/test0001.git'
/var/log/messages を見ると、リモートリポジトリ側でデータは受け取ったが、受け取ったデータを書き込めない、といったような内容のメッセージが出力されていた。権限が足りないとかあった*1。
単純に、git-daemonを起動したときには、何も問題はなかったのに？ 試しにリモートリポジトリのディレクトリー内のファイル／サブ・ディレクトリーに、otherにまで書き込み権限など与えたりしてみても、ダメだった*2。
このときの xinetd 用の設定ファイル git は以下のようなもの。
#CentOS 6 では /etc/services のなかに git の情報があるので、 type と port は書かなくてもよい（書かないほうがよい？）。 service git { disable = no socket_type = stream wait = no user = git server = /usr/libexec/git-core/git-daemon server_args = --base-path=/var/lib/git --export-all --enable=receive-pa ck --syslog --inetd --verbose log_on_failure += USERID }
これを git-daemon コマンドを直接叩くのではなく、git コマンドを使って外部コマンドの git-daemon を叩くようにしてやった。
# なぜか、git コマンドから外部コマンド git-daemon を起動するとうまくいった。
service git
{
disable = no
socket_type = stream
wait = no
user = git
server = /usr/bin/git
server_args = daemon --base-path=/var/lib/git --export-all --enable=receive-pa
ck --syslog --inetd --verbose
log_on_failure += USERID
}
すると成功した。
Solaris であって、 Linux の事例じゃないが、次のページにあるようなことが、自分の環境でも起こっているのか？と思う。
[solaris - git push failing - Stack Overflow]
xinetd を介して起動する際に、ライブラリがうまくロードされていないとか、なんか必要なものがそろってないとか、な。git コマンドを叩いて、 git-daemon コマンドを起動すると、git コマンドがいろいろ準備するからうまくいく……というものだろうか？ Linuxはときどきしか使わんから細かいことはようわからん。xinetd が git コマンドから git-daemon を叩こうが、xinetd から直接 git-daemon を叩こうが、xinetd を介すると、どんな方法をとっても、どうしようもないようだったら、 xinetd を介さず、 init で git-daemon コマンド叩くようスクリプトを書いて、デーモンが常駐するようにする必要があるかもな*3。
2011-07-15 TakaoフォントのWindowsでのビルド
■[開発][フォント] TakaoフォントのWindowsでのビルド 
配布されているTakaoフォントは、古いIPAフォントにパッチをあてたもの。自分の手元で最新のIPAフォントにパッチをあてて、Takaoフォントをビルドした。
その覚書。
使ったもの、必要なもの。
- MinGW & MSYS
- bashなど使うために利用した。2011/05/30に公開されたインストーラーを用いてインストールした。
- Perl
- MSYS上のものを使った。Ver. 5.8.8。
- Sed
- MSYS上のものを使った。Ver. 4.2.1。
- Python
- 公式サイトで配布されているものをインストールした。python-2.7.2.msi。
- numpy
- Pythonのライブラリ。公式サイトで配布されているものをインストールした。numpy-1.6.0-win32-superpack-python2.7.exe。
- TTX/FontTools
- Pythonのライブラリ。フォントにパッチをあてるための主となるソフトウェア。公式サイトで配布されているものをインストールした。FontTools 2.3。
- IPAフォント
- 現在、最新の IPAfont00303.zip、IPAexfont00103.zip を利用した。
- Takaoフォント変換スクリプト
- takao-fonts-additions-003.02.01.tar.gz に同梱されているものを利用した。
MinGWのインストール
"mingw-get-inst"を使ってインストールする。
2011/07/15 時点で最新の "mingw-get-inst-20110530.exe" を使った。
インストーラー時に選択したものを下に書く。
- Repository Catalogues
- "Use pre-packed repository catalogues"(デフォルト)と"Download latest repository catalogues"のどちらかを選ぶ。自分は"Download latest repository catalogues"を選んだ。カタログのダウンロード分よけいに時間がかかるから、インストーラーが作成された時点からそれほど日がたっていなければ、やらなくてもいいと思う。
- インストール先ディレクトリー
- デフォルトの"C:\MinGW"のままにした。
- Select Components
- すべてにチェックを入れた。"Fortran Compiler"や"ObjC Compiler"は使わないと思ったが、とりあえず全部インストールした。
これで、Perl 5.8.8 や Sed 4.2.1 はインストールされているはず。MSYSを起動して、perlやsedがあるか確認しておく。なければ、mingw-get を使ってインストールする。なお、古い MinGW & MSYS だと Perl のヴァージョンが 5.6.x の場合がある。5.6.x は内部が UTF-8 に切り替わったばかりのもので、大量のバグを含んでいる。5.6.xでもなんとか大丈夫かもしれないが、ねんのため 5.8.8 にしておくことをすすめる。
mingw-get update mingw-get upgrade msys-perl-bin
- mingw-get update
- カタログをアップデートする。
- mingw-get upgrade msys-perl-bin
- perlをアップグレードする。Perl そのものが入っていないときは mingw-get install msys-perl-bin となるかと思う。
参考ページ(英語)：http://comments.gmane.org/gmane.comp.gnu.mingw.user/36263
Pythonなどのインストール
- Python 2.7.2
- "python-2.7.2.msi"をインストールした。最新の3系列でないのは、ちょっとした自分の都合である。3系列でも大丈夫じゃないかとは思うが試してはいない。"C:\Python27"にインストールしたと仮定する。
- numpy 1.6.0
- "numpy-1.6.0-win32-superpack-python2.7.exe"をインストールした。
- FontTools 2.3
- "fonttools-2.3.tar.gz"をインストールした。配布されているTakaoフォントの作成には2.2が使われているが、2.2はPython 2.5以降で使う場合、ソースに修正が必要になる。面倒なので、2.3を使う。次のようにコマンドを叩いてインストールする。"python setup.py install"。
"C:\Python27"はPATH環境変数に加えておく。
IPAフォントとTakaoフォントへの変換スクリプトを取得する
IPAから、次のファイルをダウンロードする。IPAフォントとIPAexフォントの最新版（2011/07/15時点）。
- IPAfont00303.zip
- IPAexfont00103.zip
Takao FontsからIPAフォント→Takaoフォント変換用スクリプトを取得する。
- takao-fonts-additions-003.02.01.tar.gz
上のファイルのなかにある"ipa2takao.sh"を利用する。
Takaoフォントのビルド
IPAフォント書庫ファイル中の *.ttf ファイル（6種類）と"ipa2takao.sh"を一箇所に集める。また、同じ場所に "ttx" というテキストファイルを作る。中身は次のようなもの。"ipa2takao.sh"が利用する"ttx"スクリプトを呼び出せるようにする。
#!/bin/sh python 'c:/python27/scripts/ttx' $*
MSYSを実行し、ファイルをあつめたディレクトリーに移り、つぎのコマンドを実行して、6種類のIPAのttfファイルをTakaoフォントに変換する。
bash ./ipa2takao.sh *.ttf
2011-07-11 TakaoExフォント
■[開発][フォント] TakaoExフォント 
[いわにぃのブログ : TakaoExには「§」がない！]から。
他にも無い文字があるかも……と思い、IPAexとTakaoExのcmapの差を見たら、無い文字がわかるかな？とTTX/FontToolsを使って、cmapをダンプし、比べてみた。
IPAexGothicとTakaoExGothicのcmapを比べると、TakaoExGothicの方には、下の文字に対応するものが存在しなかった。
| U+00A7 | SECTION SIGN |
| U+00B0 | DEGREE SIGN |
| U+00B6 | PILCROW SIGN |
| U+0336 | COMBINING LONG STROKE OVERLAY |
| U+2014 | EM DASH |
| U+2032 | PRIME |
| U+2033 | DOUBLE PRIME |
| U+22BF | RIGHT TRIANGLE |
| U+5307 | (略)*1 |
| U+E0101 | U+5307 の異体字 |
自分の調べ方はざっとしたものなので、上は正確じゃないかもしれないが、とりあえず、最初に引用した記事と一致する U+00A7 はきちんとマップされていないと思ってまちがいなさそう。
これは何かの意図があって無い……のじゃなくて、単純にバグなんだろうな。日本語フォントは文字数多いから、こういうの大変そう。
それに、ソフトによっては、ない文字を別のフォントの文字で代替えしたりするから、はっきりと失敗してくれるソフトじゃないとわかりにくそう。Wordだとデフォルトフォントが表示され、LibreOfficeだとなんか文字は表示されているんだけど、カーソル位置がおかしなことになり、選択したときに文字化けしたりする。テキストエディターでも、なんか文字が表示されたりする。文字の幅とか微妙にへんなことになってたりするけど。
あとTakaoExGothicとTakaoExMinchoのcmapは同じなんだけど、IPAexGothicとIPAexMinchoのcmapは微妙に異なる。
あまりフォントのデータ構造の詳細やら事情やらを知らないので、妙な感じはするが、それ以上のことは、ようわからんな。
追記 2011/07/12
IPAフォントからTakaoフォントを作るスクリプトを見たんだけど、とくに複雑な処理はしていない（ように見える）。それなのに、なぜに cmap に違いができるんだろうか……。
なんのことはない。公開されているTakaoExは、IPAexの2010年2月公開のVer.001.01から作られたものだった（Exなしのものも古いIPAフォントから作られている）。最新のIPAフォントから作られているものが公開されていると思い込んでいた……。
IPAexの001.01は、IPAのサイトからもうダウンロードできない（旧ヴァージョンのページを見ていっても、IPAexは001.02以降しかみあたらない）から、実際のところはわからないけど、古いIPAexが持ってた不具合をそのまんまTakaoExが取り込んだってことなんだろう。
最新の IPAexGothic 001.02、IPAexGothic 001.03 から TakaoEx フォントを作ればセクション記号がないとか、そういう不具合は回避できるんだろうな。作成用のスクリプトがあるから、それを実行してみればいいのだろうけど……。でも、Windowsでやるのは、たいへん面倒くさそう……。スクリプトはshのもので、そのなかでperlとかsedとか呼んでるんだよなあ……。
