第 36 回 関西 Debian 勉強会資料
関西 Debian 勉強会担当者 佐々木・ 倉敷・ のがた
2010 年 06 月 27 日
第 36 回 関西 Debian 勉強会 2010 年 06 月
1 Introduction
Debian JP
関西 Debian 勉強会は Debian GNU/Linux のさまざまなトピック (新しいパッケージ、 Debian 特有の機能の仕組、
Debian 界隈で起こった出来事、などなど）について話し合う会です。
目的として次の三つを考えています。
• ML や掲示板ではなく、直接顔を合わせる事での情報交換の促進
• 定期的に集まれる場所
• 資料の作成
それでは、楽しい一時をお楽しみ下さい。
1
関西Debian 勉強会
目次
1 Introduction 1
2 最近の Debian 関係のイベント報告 3
3 事前課題 4
4 dh ∼source format 3.0, the magic debhelper rules∼ 7
5 puppet に $HOME を管理させてみよう 15
6 今後の予定 22
2
第 36 回 関西 Debian 勉強会 2010 年 06 月
2 最近のDebian関係のイベント
報告
Debian JP
2.1 前回の関西 Debian 勉強会
前回の関西 Debian 勉強会は, 5 月 23 日に大阪港区民センターで行なわれました。 Ubuntu Japanese Team のあわし
ろいくやさんによる「 Debian ユーザのための Ubuntu 入門」とのがたじゅんさんによる「 次期リリースの Squeeze を見
てみよう」でした。リリースされたばかりの Lucid Lynx 入門が目玉でした。いくやさんのトークも好調で、オフレコ話
あり、 Debian との差異ネタありでいい感じの盛り上がりを見せていたと思います。
続いて、お約束通りにフリーズの遅れている squeeze について、のがたさんに現状をまとめてもらいました。特に日本
語まわりで課題が残っている squeeze、リリースまで目が離せませんね。
2.2 第 65 回東京 Debian 勉強会
6 月 19 日に第 65 回東京エリア Debian 勉強会が開催されました。
内容は OSC 北海道直前ということで、岩松さんによる Debian GNU/kFreeBSD の話と、荒木さんによる「 あなたは
どっち?クラウドで Debian, Debian でクラウド」という Debian でクラウドの話をされたそうです。
Debian でクラウド話の中では、今回、倉敷さんが発表する puppet の話題も出たそうで興味深いですね。
*
1
*
1
あなたはどっち? クラウドで Debian // Debian でクラウド / 荒木靖宏 - http://www.slideshare.net/ar_maniacs/debian-debian
3
第 36 回 関西 Debian 勉強会 2010 年 06 月
3 事前課題
佐々木洋平
今回はパッケージ作成にまつわる以下の事前課題を設定しました
*
2
。
deb パッケージ (野良含む) を作成している方  
お手元のパッケージのどれか 1 つを source format 3.0、 cdbs or debhelp er 7 に移行して下さい。
提出事前課題としては、その感想をお願いします。 また、発表者宛に *debian.tar.gz を添付して下さ
れば幸いです (その際には勉強会登録システムでの参加者名を明記して下さい)。
deb パッケージを作成していない方  
パッケージ作成環境を一通り用意して来て欲しいので、お手元で適当なパッケージ (例えば GNU Hello)
などを作成してきて下さい。 提出事前課題としては、その感想をお願いします。
参加者の皆さんによる回答は以下の通りです。
3.1 佐々木洋平
unstable の howm、 rail パッケージの作成には debhelper 7.0、 rttools、 rabbit パッケージの作成には CDBS +
ruby-pkg-tools を使って rules を書きました。 ruby 関連については setup.rb、 install.rb、 extconf.rb と install に使
用する script が分かれているので debhelper より CDBS + ruby-pkg-tools の方が楽ですね。 gem だと Rakefile にな
るので、 debhelper 7.0 用に dh rubygems(仮) を作成するなら Rake を探すようにすれば良いかな、と妄想しました。
3.2 山田 洋平
deb パッケージを作成していないほうです。 Squeeze の hello および hello-debhelper と、「 佐々木流」の資料を参考
にしたら何とか作成できました。ですがもう少し中身を理解して作業したいです。
3.3 西山和広
cdbs を使ったパッケージはいくつか作ったことがあったので、 source format 3.0 (quilt) で chkbuild の deb を作っ
てみました。 http://chkbuild.deb.n-z.jp/ で公開しています。 cdbs と違って debian/rules に include がない
ので、 DEB UPDATE RCD PARAMS などを指定したくなった場合どうするのかが気になりましたが、今回は必要な
かったのでそこまでは調べませんでした
*
3
。
*
2
これまでと比べて思いっきりハードルを上げてしまったためか、参加登録者が少ない気がしますが...
*
3
DEB UPDATE RCD PARAMS の場合は dh installinit を override します (佐々木)
4
3.4 かわだてつたろう
GNU Hello でパッケージを作成。単一のソースから単一のパッケージを作成するなら debhelper と debuild ですんな
りとできるんだなぁと。手間取ったところ:
• lintian のエラー (package-contains-info-dir-file)
• pbuilder で basetgz 作成が何度も失敗
*
4
• piuparts での Broken symlinks で失敗
*
5
3.5 古川竜雄
私は deb パッケージを作成していないので、課題どおり GNU Hello をパッケージ化してみました。参考書は maint-
guide-ja です。記述が古かったこと、 dh-make が作るテンプレートの Standards-Version が 3.7.3 なのに対して Lintian
が 3.8.0 を要求 (?) したことなどの問題を除けば、参考書の通りすんなりとできました。感想ですが、私はよくできている
と思います。作業はめんどくさかったのですが、その原因は「 ちゃんとしたパッケージを作る」ことにあり、これは必須の
ことです。そのめんどくささをツールでできるだけ軽減するよう工夫されています。特に問題は感じませんでした。どう
「 進化」しているのか楽しみです!!
3.6 榎真治
(回答なし)
3.7 lurdan
source format 3.0  
debian/ への変更が patches に入るのはまだしっくりきません
*
6
。
debhelper7  
upstream がまともな Makefile を用意してくれてる場合は幸せになれそうです。
3.8 ”まさ”こと”甲斐正三”です
(回答なし)
3.9 IPv6waterstar
パラメータとエラーに悩まされた。以下、「 入門 Debian パッケージ」を参照にしながら、時系列に今の状態を記す。
• GNU Hello をダウンロード
• tar xvfz hello-2.6.tar.gz で解凍
• dh make –single –copyright=gpl で debina ディレクトリを作ろうとするも作ることができず、エラーを参照し、
dh make –createorig –single –copyright=gpl に修正し、 debian ディレクトリを作成。
•「 入門 Debian パッケージ」を参照し各ファイルを修正。
• debuild -uc -us をするも、 deb パッケージ作成されず、エラーを参照し、 debuild -d -uc -us でパッケージを作
成。エラー多し。
*
4
丁度 dennou-q のミラー障害時期に当たりましたかね?(佐々木)
*
5
piuparts の Broken symlinks は鬼門ですね。多くの場合「 オレの所為じゃねーよ」と叫びたくなります。
*
6
パッケージ作成の時に upstream へのソース変更が入っていて、 clean で変更が元に戻ってないのでは?(佐々木)
5
3.10 のがたじゅん
すみません。最近の流れについてきてないので「 deb パッケージを作成していない方」コースを選んでしまいました。
GNU Hello の debian/rules を見ると、ごりごり手で書いてるので、こういう方法もアリなんだと思いました。
3.11 山下康成
パス。廊下で立ってます。ハイ
6
第 36 回 関西 Debian 勉強会 2010 年 06 月
4 dh ∼source format 3.0, the magic debhelper rules∼
佐々木洋平
次期安定版 6.0(squeeze) での RELEASE GOALS の一つに「 new source package format support」があります
*
7
。
ここでの「 new source package format」が source format 3.0 です。
debhelper は deb パッケージの構築を補助する様々なツール群です
*
8
。多くのパッケージでは debhelper の呼び出
しはテンプレ化されているので共通している debhelper の呼び出しを隠蔽しパッケージ作成のルール (debian/rules) を
簡単にするのが dh(コマンド) と CDBS(Makefile のルールセット) です。
ここでは source format 3.0, dh, CDBS についてお話しします。ちなみに、告知タイトルに「 深追い」とか「 CDBS
2.0」とかいう文字列があった気がしますが気にしないで下さい。
4.1 source format 1.0 → 3.0
4.1.1 1.0 の問題点
source format 3.0 の前に、これまでの source format 1.0 について簡単に復習しましょう。 debian のソースパッケー
ジは主に以下の構成物からなります:
.orig.tar.gz  
オリジナルのソース一式
.dsc  
パッケージの情報 (パッケージの説明、メンテナ、ファイルのハッシュなど)
.diff.gz  
バイナリパッケージをビルドするための変更点。 Debian 固有のパッケージの場合には存在しない。
さて, このソースフォーマットの構成には, 以下の問題点があります:
1. アーカイブの圧縮形式として .gz しか使えない。
2. upstream のソースが複数のアーカイブから構成される場合が面倒。
3. パッケージメンテナの作成したパッチが全部単一のファイルにまとめられており、混然としている。
4. diff で表現されるので (画像などの) バイナリが置きにくい。
source format 1.0 の場合、これらの問題点は, だいたい以下の様に解決していました:
*
7
http://release.debian.org/squeeze/goals.txt
*
8
deb パッケージそのものは debhelper 無しでも作成できますが、普通は debhelper を使います。
7
1. アーカイブの圧縮形式として .gz しか使えない。  
例えば upstream が bzip2 で配布されている場合でも gzip で圧縮しなおす、 もしくは tarball in tarball
*
9
などの形式にする、などです。後述の CDBS を使用する場合には tarball in tarball 用のルールとして
tarball.mk が用意されています。
2. upstream のソースが複数のアーカイブから構成される場合が面倒。  
前述の tarball in tarball で対応しています。
3. パッケージメンテナの作成したパッチが全部単一の patch に。  
diff.gz は debian 以下のファ イルが全て単一のファ イルになっ ています。 debian/control や
debian/rules だけではなく、 upstream のソースへのパッ チも全て一つのファ イルになっ ています。
そこで、 upstream のソースへのパッ チは debian/patches 以下に意味のある単位で分割して配置し、
パッケージ作成の際にパッチの apply/unapply を行なうことにしています。このためのツールとしては
dpatch や quilt
*
10
があります。また、 CDBS にはパッチの apply/unapply をするためのルールとし
て patchsys-quilt.mk, dpatch.mk, simple-patchsys.mk が用意されていますし、 dh には--with
quilt というオプションが用意されています。ちなみに、各パッチの先頭にその意図を記述するタグを追加し
ておくことが推奨されています
*
11
。
4. diff で表現されるので (画像などの) バイナリが置きにくい。  
uuencode/uudecode で diff が取れる形式にしておくなどして対応します。
というわけで、これまでの source format でも問題点について対応はできます。しかしながら、こういった特殊な操作
を行なうことなく問題点を解決するための新たなフォーマットとして、新たに 3.0 (quilt) と 3.0 (native) が制定さ
れました
*
12
。
4.1.2 3.0(quilt) と 3.0(native)
3.0 (quilt) は以下のファイル群で構成されます:
.orig.tar.ext  
upstream のソース。複数のソースからなる場合には基本となるソースにこの名前をつける。 ext は圧
縮の拡張子であり、 gz, bz2, lzma, xz が使用可能。
.orig-component1.tar.ext  
upstream が複数のソースから構成される場合に作成する。-componet はソースの名前に対応してメン
テナが適宜名付ける。
.debian.tar.ext  
debian ディレクトリの中身。 ext は圧縮の拡張子であり、 gz, bz2, lzma, xz が使用可能。 1.0 の
diff.gz から.tar.ext になり、全てが混在した単一のパッチではなくなった。
.dsc  
パッケージに関する情報。
また 3.0 (native) は 1.0 での Debian 固有パッケージに対応しており、.orig.tar.ext と .dch ファイルからなり
ます。
これらの変更により 1.0 での問題点は以下の様に解決されました。
*
9
.orig.tar.gz を展開するとディレクトリ内に upstream の bzip2 が配置される。ビルドする際に tar を展開してからビルドする
*
10
こう書くと語弊があるかもしれませんが、 quilt は Debian 固有のツールではありません。一方で dpatch は「 patch maintenance system
for Debian source packages」とあるように Debian 固有のツールです。
*
11
http://dep.debian.net/deps/dep3/  面倒なので佐々木はサボリがちです。すいません。
*
12
http://wiki.debian.org/Projects/DebSrc3.0  ちなみに 2.0 はどういう状況知りません. だれかご存知ですか?
8
1. アーカイブの圧縮形式として .gz しか使えない。
→ .gzip, bzip2, lzma, xz を使用できるようになりました。
2. upstream のソースが複数のアーカイブから構成される場合が面倒。
→ .orig-component.tar.ext に よ り 複 数 の ソ ー ス を 使 用 で き る よ う に な り ま し た 。 こ れ ら.orig-
component.tar.ext はソースの展開時に compnent というサブディレクトリに展開されます。
3. パッケージメンテナの作成したパッチが全部単一のファイルに。
4. diff で表現されるので (画像などの) バイナリが置きにくい。
→ .diff.gz から .debian.tar.ext になったので全てが混然となった状態は解消されており、バイナリも含める
ことができます。また、 debian/patches に存在するパッチはソースパッケージの展開時に自動的に適用されるよ
うになりました (これについては後述)。
現在では、日々巨大化しつつある Debian アーカイブのサイズを抑制するために新規パッケージについては gzip より
も xz による圧縮が推奨されています。
4.1.3 3.0 への移行
さて source format 3.0 に以降するにはどうすれば良いでしょうか? 複雑なパッケージでないならば、
% mkdir debian/source
% echo ’3.0 (quilt)’ > debian/source/format
% dch ’Switch to dpkg-source 3.0 (quilt) format’
だけでです.
これま での diff.gz に upstream へのパッ チが含 まれ てい る場 合に は、 先ず パッ チを (意味のある単位に)
分 割 し 、 quilt で 管 理 で き る よ う に し て おき ま しょ う 。 そ う し な い 場 合 には分 割 さ れ て い な い パッ チ は
debian/patches/debian-changes-<version> という patch にまとめられてしまいます
*
13
。また、更新の度
に debian-changes-<version> というパッチが生成されてしまいます。また quilt は -p1 のパッチしか扱えませんの
で rules 内で明示的に patch -p0 とか patch -p2 としている場合や、 CDBS の simple-patchsys.mk を使用している
場合には -p1 で適用できるようにパッチを変更しておきます。
最後に debian/rules でのパッ チに関する rules を消しておくことが推奨されています。 dpkg (>=1.15.5.4) では
dpkg-source によってソースを展開する際に debian/patches 以下のパッチが自動的に適用されることは既に述べまし
た。古い buildd、とくに lenny 向けの buildd ではソースを buildd chroot の外で展開することがあるため, dpkg-source
の段階でソースにパッチが適用されていない場合には不具合が生じます。パッチを更新した場合には debuild を実行する
前にパッチを全て適用しておきます。こうして debuild を実行すると、 3.0 形式のソースパッケージが生成されます。
ちなみに lenny の dpkg は既に 3.0 に対応しています。これは lenny で squeeze のソースパッケージを使用する場合
(backports 等) に問題にならないようにするためです。 また、現在は debian/source/format で source format の
バージョンを指定していますが、将来的には全て新しい source format へ移行される予定です。
ではお手元のソースを 3.0 へ移行してみましょう
4.2 debian/rules の書き方
CDBS, dh 以前の debhelper コマンド群を使用した debian/rules は一番簡単な場合でも、例えば以下の様になりま
す
*
14
。
*
13
というわけです > lurdan
*
14
lenny で GNU Hello のパッケージを作成した場合です。ページに収めるために先頭のコメントを削っています。
9
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# - snip -
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
# These are used for cross-compiling and for saving the configure script
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
CROSS= --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
else
CROSS= --build $(DEB_BUILD_GNU_TYPE)
endif
config.status: configure
dh_testdir
# Add here commands to configure the package.
ifneq "$(wildcard /usr/share/misc/config.sub)’’ "
cp -f /usr/share/misc/config.sub config.sub
endif
ifneq ‘‘$(wildcard /usr/share/misc/config.guess)" ""
cp -f /usr/share/misc/config.guess config.guess
endif
./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man --info
dir=\$${prefix}/share/info CFLAGS=’’$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
build: build-stamp
build-stamp: config.status
dh_testdir
# Add here commands to compile the package.
$(MAKE)
#docbook-to-man debian/hello.sgml > hello.1
touch $@
clean:
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
[ ! -f Makefile ] || $(MAKE) distclean
rm -f config.sub config.guess
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/hello.
$(MAKE) DESTDIR=$(CURDIR)/debian/hello install
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs ChangeLog
dh_installdocs
dh_installexamples
# dh_install
# dh_installmenu
# dh_installdebconf
# dh_installlogrotate
# dh_installemacsen
# dh_installpam
# dh_installmime
# dh_python
# dh_installinit
# dh_installcron
# dh_installinfo
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
# dh_perl
# dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install
10
configure、 make、 make install 以外にも随所に dh から始まるコマンドが呼び出されています。この dh から始ま
るコマンドが debhelper コマンド群です。幾つかの例外を除いて dh * は適切なタイミングで呼び出すだけですので、こ
の呼び出しを隠蔽するだけで debian/rules は随分すっきりします。 CDBS, dh は異なる手法で dh * の呼び出しの隠蔽
とルールセットの追加を行なっています。
4.2.1 CDBS
CDBS については以前お話しました (2008 年 6 月, 第 18 回関西 Debian 勉強会
*
15
)。 debian/ruls は Makefile で
すので
• Makefile の target を細分化。
• ソフトウェアやパッケージの状況に応じて、呼び出す target を class としてまとめる。
としています。
CDBS を利用した場合のビルドターゲットの流れについては例えば杉浦さんの Web に良い絵が公開されています (こ
れは buildcore.mk + debhelper.mk を用いた場合です)。
図 1 CDBS Target flow: http://sugi.nemui.org/doc/cdbs/cdbs-targets.png
CDBS を使った場合、先程の GNU Hello のルールは
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
となります。以前書きましたが, いきなりコレだと今度は何をしているのかわからなくなりますね (笑)。
最初の include が dh * の呼び出しを設定する class, 二つ目の include が autotools を使用するソースからパッケー
ジを作成する場合の class です。 CDBS の詳細については本家のドキュメント
*
16
が参考になるでしょう。パッケージに
付属のドキュメントではソースには実装されていて使えるのにドキュメント化されていない便利機能が多いです。こういう
場合は「 ソース見れば良いじゃん」というのはまあ正論ではあります。実際、 class のカスタマイズに使用する変数はソー
ス冒頭に定義されてますし...。
*
15
http://tokyodebian.alioth.debian.org/pdf/debianmeetingresume200810-kansai.pdf
*
16
CDBS Documentation: http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml
11
4.2.2 dh - debhelper command sequencer
CDBS が make の target の細分化 →class 化という方向で dh * の呼び出しを隠蔽し、 Gnome、 KDE といった統
合環境や perl、 python といった言語用の class によって rules の作成を容易にしているのに対して、 dh のアプローチ
は以下の通りです:
• debhelper の呼び出しは隠蔽したまま
• パッケージ作成に使用するツール (autotools, make, MaikeMaker 等) の自動判定を行なう
例えば先程の GNU Hello の場合にはとなります。
#!/usr/bin/make -f
%:
dh $@
...CDBS よりさらに簡潔になりました (笑)。
さて、これでは CDBS 以上にナニをしているのかわかりませんね。実は dh コマンドには --no-act というオプショ
ンが用意されています。試しに rules を書き換えずに binary ターゲットを –no-act つきで実行してみましょう。
uwabami@vmguest-lenny:~/Packages/hello-2.6$ dh binary --no-act
dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test
dh_testroot
dh_prep
dh_installdirs
dh_auto_install
dh_install
dh_installdocs
dh_installchangelogs
dh_installexamples
dh_installman
dh_installcatalogs
dh_installcron
dh_installdebconf
dh_installcatalogs
dh_installemacsen
dh_installifupdown
dh_installinfo
dh_installinit
dh_installmenu
dh_installmime
dh_installmodules
dh_installlogcheck
dh_installlogrotate
dh_installpam
dh_installppp
dh_installudev
dh_installwm
dh_installxfonts
dh_lintian
dh_desktop
dh_gconf
dh_icons
dh_perl
dh_pysupport
dh_scrollkeeper
dh_usrlocal
dh_link
dh_compress
dh_fixperms
dh_strip
dh_makeshlibs
dh_shlibdeps
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb
と出力されます。 CDBS と違って、ビルド時の流れを見る事ができます。 dh コマンドの肝は
dh auto
で始まる 5 つのコマンドです。
12
何も設定しない場合には dh auto configure がパッケージのビルド時に使用するツールを判定します。この判定結果に
基づき auto build, auto test, auto install が実行されます。自動判定結果は基本的に良くある GNU な設定になってお
り、例えば configure 時の –prefix=/usr とか install 時の DESTDIR などは GNU のパッケージ用に設定されていま
す (なので GNU Hello は設定が不要です)。
注意して欲しいのは configure や configure.ac をパースしているわけではないので dh auto * は変数を自動設定をし
ているわけではない、という事です。 configure に対して Debian パッケージ用のフラグを適用したり、環境変数を追加
する場合には、適宜変数を設定してやったりする必要があります。また、ソフトウェアによってはビルド時に configure,
make, make install 以外の操作をする必要があったりします。このための機能が dh の override と before, after
です。
4.2.3 実践! the magic debhelper rules
例えば GNU Hello の configure オプションには--with-gnu-ld や --disable-nls といったオプションがありま
す。これらを configure 時に指定したい、と思ったらどうしたら良いでしょう? この場合には dh auto configure の呼び
出し時にオプションを与えるようにします。例えば lenny の場合には --before, --after を使用します。
#!/usr/bin/make -f
%:
dh $@
build: build-stamp
build-stamp:
dh build --before configure
dh_auto_configure -- --with-gnu-ld --disable-nls
dh build --after configure
touch build-stamp
squeeze/sid の dh には override という機能が追加されており、記述がさらに簡単になります
*
17
。
#!/usr/bin/make -f
%:
dh $@
overide_dh_auto_configure:
dh_auto_configure -- --with-gnu-ld --disable-nls
squeeze/sid 版の override の方が直感的にわかりやすいですね。また、 squeeze/sid の dh コマンドは –no-act の際
に override を表示してくれます。
uwabami@vmguest-sid:~/Packages/hello-2.6$ dh binary --no-act
dh_testdir
debian/rules override_dh_auto_configure
dh_auto_build
dh_auto_test
...
override の詳細までは表示されませんが override されていること、及び呼び出しの順番が参照できます
*
18
。
以下では squeeze/sid の dh コマンドについて解説します。残念ながら lenny の debhelper は若干古いですので、
sqeeze/sid の debhelper を導入しましょう。 dh コマンドの使い方については Debconf9 での Joey Hess 御大による
debhelper のプレゼン資料
*
19
が今の所一番まとまっている気がします。御大のプレゼン資料に掲載されている dh コマン
ドを利用した rules の例を以下に示します。
1. 自動判定結果とは別のビルドツールを使用
#!/usr/bin/make -f
%:
dh $@ --buildsystem perl_build
*
17
override は debhelper (>= 7.0.50) 以降の機能です。
*
18
西山さんの DEB UPDATE RCD PARAMS の場合は dh installinit を override すれば良いと思います.
*
19
http://joey.kitenet.net/talks/debhelper/debhelper-slides.pdf
13
2. upstream のソースファイルがサブディレクトリ src にありビルドを make -C で別ディレクトリ (ここでは build)
で実行
#!/usr/bin/make -f
%:
dh $@ --sourcedirectory=src \
--builddirectory=build
3. パッチ当てに quilt を使用して、 configure にフラッグを指定、 changelog として changelog.html を収録
#!/usr/bin/make -f
%:
dh $@ --with quilt \
--builddirectory obj \
--sourcedirectory source
override_dh_auto_configure:
autoconf
dh_auto_configure -- --with-sdl CC=/usr/bin/gcc-4.1
override_dh_installchangelogs:
dh_installchangelos changelog.html
などなど。
4.3 debhelper vs CDBS vs dh
Joey Hess 御大のプレゼン資料では
• debhelper で設定可能な項目は 138
• CDBS で設定可能な項目は 138 + 153
• dh で設定可能な項目は 138 + 12
となっています。
御大は「 私が比較するのは unfair だ」とおっしゃってますが、 rules の可読性/可変性は dh の方が圧倒的に優れ
ていると思います。特に、 dh の一番嬉しい所は–no-act による work frow が把握しやすいことでしょう。また、
Build-Depends が減る、というのは一つの利点かもしれません。
一方、 CDBS は work flow は把握しにくいですけれど対応しているビルドツールが多い事があげられます。 CDBS 本
体には Make, SCons(Make の代替品), Perl, Python, Cmake, Ant, Qmake, Gnome, KDE の class がありますし、
本体には収録されていませんが pkg-kde-tools, pkg-ruby-tools が提供されています。これらの class を使用することで
rules は共通化され非常に簡潔に記述できます。 dh の場合, 現時点で対応しているビルドツールは
uwabami@vmguest-sid$ dh_auto_build --list
autoconf GNU Autoconf (configure)
perl_makemaker Perl ExtUtils::MakeMaker (Makefile.PL)
makefile simple Makefile
python_distutils Python Distutils (setup.py)
perl_build Perl Module::Build (Build.PL)
cmake CMake (CMakeLists.txt)
ant Ant (build.xml)
qmake qmake (*.pro)
といった所です。
ではお手元のソースを CDBS or dh へ移行してみましょう.
既に CDBS を使用している場合には dh で書きかえて見て下さい。
最後に妄想など。現在手元で dh ruby 関連を作成中です。 setup.rb, extconf.rb ができれば多分 CDBS とは別の選択
肢になるだろう, と思っています (あとは rake 用の build 拡張ができれば dh make gems の完成です)。これについて
は... 時間と紙面の都合で今日は載せられません。そのうち勉強会でお話しします。というわけで、「 深追い」はタイトル
に偽りアリ、ですね。すみません...Orz
14
第 36 回 関西 Debian 勉強会 2010 年 06 月
5 puppetに $HOME を管理させ
てみよう
倉敷悟
今回は、皆さんの道具箱に入っていると便利な puppet というツールをご紹介します。
5.1 はじめての糸繰り
早速ですが、まずは動かしてみてもらおうと思います。 lv をネタに使うので、 lv の設定を ˜/.lv に書いている人は、
一旦適当に退避してください。
念の為、進む前に ˜/.lv が存在しないことを確認しておきましょう。
5.1.1 実行サンプル
なにはともあれ、 puppet をインストールします。
puppet-el は、 emacs でシンタックスハイライトさせるためのものなので、 emacs を使わない人はなくても OK です
が、なしでは割とやってられません。
$ sudo aptitude install puppet puppet-el
$ emacs site.pp
エディタが起動したら、 site.pp には次のように入力してください。 site.pp は糸繰りの譜面、つまり設定ファイルで
す。なお、# はコメントなので無視して頂いて構いません。
# sudo が必要
package { "lv":
ensure => installed,
}
file { "/home/yourname/.lv":
content => "-c",
}
入力が終わったら、保存してコマンドに戻ります。では、いよいよ puppet に踊ってもらうことにします。ネットに接
続できるなら、 aptitude purge lv してからでもいいでしょう。
$ puppet site.pp
何が起きたか確認してみてください。予想通りすぎて、ちょっと拍子抜けかも知れませんが……。
15
5.2 概要
5.2.1 用語の整理
先に進む前に、用語の紹介だけしておきます。
site.pp に入力してもらった設定のことをマニフェストと呼び、ここに、必要なリソースを宣言することで、 puppet を
操っていきます。
先ほど書いてもらったマニフェストでは、 package と file がそれぞれリソースの宣言になります。 puppet が理解でき
るリソースはあらかじめ決まっていますが、自分で新しくリソースを作ることもできます。
リソースの構成要素と、基本的な書式は次のようになります。区切りの記号に注意してください。
• タイプ : リソースの種類
• タイトル :「 その」リソースの名前
• 属性 : 様々なパラメータ
タイプ {
"タイトル":
属性 => 値,
属性 => 値,
...
属性 => 値;
"タイトル":
...
}
5.3 puppet の概要
ここで一旦手を休めて、 puppet そのものについて、もう少し説明しておきます。
puppet が何か、を一言でいえば、システム構成の管理ツールということになります。普段、 sudo を使ってやるような
「 パッケージ操作」「 /etc 配下の設定変更」「 プロセスの起動停止」といった作業内容を、事前にレシピを書いておくこ
とで、 puppet に任せることができます。
5.3.1 構成
puppet は、だいたい次のような構成で動きます。
• puppet : マニフェストを実行するコマンド
• puppetd : puppetmasterd にマニフェストをリクエストして、それを実行するデーモン
• puppetmasterd : マニフェストの束をもっていて、 puppetd のリクエストにあわせて適切に配布するデーモン
実は、 puppet を使う場合は、 puppetmasterd と puppetd の組み合わせで多数のホストを集中管理するのが普通だっ
たりします。
ですが、今回はそれは一旦おいておいて、 puppet コマンドを使ったお手軽な方法をベースに進めていきますのでご承
知置きください。
最後でもご紹介しますが、普通の構成についても既に山ほど記事や資料はあるので、興味がある方はそちらをご参照頂け
ればと思います。
16
5.3.2 ディレクトリ配置
puppet が使用するディレクトリですが、典型的にはこんな感じです。設定でどうとでも変えられるので、配置されるも
のの種類がこんな感じなのだと思ってください。
実際のところ、 puppet コマンドを使う場合は、/etc/puppet ではなくて˜/.puppet が主な作業場所として想定され
ます。
• /etc/puppet/ : puppet 自体の動作設定ファイルが配置されます
• /etc/puppet/manifests : マニフェストが配置されます
• /etc/puppet/templates : テンプレートファイルが配置されます
• /etc/puppet/modules : puppet module が配置されます
• /var/lib/puppet : マニフェストのキャッシュや、 SSL 証明書が配置されます
ここで、最初に作ったマニフェストを、˜/.puppet/manifests に移動させておいてください。 puppet を実行した時点
で、˜/.puppet は作成されているはずです。
5.4 設定を増やす
では、実践に戻ります。 lv だけでは寂しいので、他にもレシピを追加してみることにします。ちょっと時間をとるの
で、自分的に必須なツールなど、適当に書いてみてください。 emacs でも screen でも何でも OK です。
5.5 リソースの整理
設定をどんどん追加していくと、 site.pp にずらずらとリソースが並んで、大変見通しが悪くなってきます。そこで、リ
ソースをグルーピングすることにしましょう。
puppet で用意されているリソースのグルーピング方法には、ノード、クラス、デファイン、モジュール、といったもの
があります。
5.5.1 ノード
ノードは、ホストの fqdn と関連づけられるリソースのグループです。「 この fqdn のホストに、このリソースをまとめ
て反映しといて！ 」というイメージです。
実際の定義はこんな感じになります。
node myhost01.localdomain {
file {.....}
service {.....}
}
node の中に書いた定義は、ホスト名が指定されたものと一致しているホストでのみ有効になります。
emacs はマシン全部に入れるけど、 wicd はデスクトップには要らないや、みたいな使い分けが考えられます。
5.5.2 クラス
クラスは、ノード程具体的ではないのですが、「 何となく関係しているリソースをまとめて名前つけとこ！ 」というイ
メージのものです。実際に使うときは、事前に定義した class をマニフェスト中で include する必要があります。
実際の定義はこんな感じになります。
class myconfig {
file {.....}
package {.....}
}
include myconfig
17
5.5.3 デファイン
デファインは、クラスと似ているのですが、引数を取れるところと、デファインで定義したリソースは複数回設定できる
ところが違っています。
実際の定義はこんな感じになります。
define emacs::config ( $content, ){
file { $name.el:
content => $content,
}
}
emacs::config { "howm":
content => ” (require ’howm)"
}
個人的には、クラスを補完する目的で使うことが多いでしょうか。クラスとの比較例でもよく使われますが、 apache ク
ラス (1 回だけ登場) の補助で、デファインしておいた apache::vhost (複数回登場) を使う、などです。
5.5.4 モジュール
モジュールは、前述したノードやクラスとはちょっと位置付けが異なっていて、マニフェストの書き方というよりは、
ファイルの配置の仕方でグルーピングをするものです。
基本的には、先に触れた puppetdir/modules の下に、ミニ puppet 設定ディレクトリを作ります。よく使うので一応
fles と templates も書いていますが、モジュールとしては少なくとも init.pp があれば機能します。
modules/
モジュールの名前/
manifests/
init.pp
files/
templates/
一まとまりの大きな機能をモジュールとして構成しておいて、必要な場合だけ読み込む、といったことができます。
また、自分が書いているマニフェストの中でも、独立性を高くして切り離すことができるので、他の人とマニフェストを
交換する場合に便利です。 github などで、モジュール個別のリポジトリが公開している人などもいて、お手本としても役
立ちます。
5.6 モジュールの切り出し
書いたマニフェストが充実してきたら、モジュールとして切り出すようにしたいのですが、今回は時間もないので、充実
していないながら一度切り出しを試してみようと思います。
5.6.1 lv モジュール
では、一度 .puppet/modules に移動して、モジュールのためのディレクトリを用意して、モジュールを作ってみま
しょう。
mkdir -p ~/.puppet/modules/lv/manifests
emacs ~/.puppet/modules/lv/manifests/init.pp
class lv {
ここに最初に書いた内容をコピー
}
site.pp に書いていた、同じ内容は消しておいてください。 puppet では、同じ名前をもったリソース宣言は重複として
エラーになります。
18
5.6.2 モジュールの読み込み
さて、設定を切り出したのはいいですが、さっきと同じように puppet コマンドを実行しても、切り出した部分は動い
てくれません。 init.pp を直接引数にすれば動かなくもないですが、設定が複雑になったり、複数のモジュールを使いたく
なったら破綻します。
puppet にモジュールを認識させるには、次のステップが必要です。
1. puppet の設定 (modulepath) でモジュールの配置場所を教える
2. site.pp からそのモジュールで定義したクラスを include する
これを実現するため、 site.pp に、 include lv という一文を追加して、こういうコマンドラインでもう一度実行してみ
ましょう。
puppet --modulepath ~/.puppet/modules ~/.puppet/manifests/site.pp
さて、無事に動いたでしょうか。
5.6.3 切り出しで迷ったら
愛情こめて育てた site.pp からモジュールを切り出そう、と思ったときに、どういう名前でどの範囲を切り取るか、迷う
ことがあるかも知れません。
そんな時は、使おうとしている機能を提供するパッケージとモジュールを対応づけるのがおすすめです。
すでに作った lv モジュールや、 emacs モジュール、 apache モジュール、 xmonad モジュール、 platex モジュー
ル……などと考えるわけです。
切り分けの単位としてわかりやすいことと、 puppet が OS のパッケージシステムとうまく連携してくれるために、後
で複数のモジュールを組み合わせたくなった時にやりやすい、のがポイントです。
また、後で別の用途にそのモジュールを使い回すには……と考えながら作ると、機能面でもいい具合に切り分けできるの
ではないかと思います。
5.6.4 puppet-module ツールの紹介
puppet を作っている puppetlabs という企業が、最近モジュール用のリポジトリとして alioth のようなサイトをオー
プンしました。
http://forge.puppetlabs.com/
ブラウザでジャンル毎に公開されているモジュールを探したりできるようになっています。今はまだ登録されているモ
ジュールの数が少ないですが、そのうち充実してくれば、モジュールのカタログとして便利に使えるようになるのではと思
います。
このサイトと連動して、検索や取得 (その気があれば公開も) をするためのコマンドラインツールもあります。それが
puppet-module です。
今のところ github からの取得になりますが、そのうち ruby 関連のメンテナがパッケージにするでしょう。
実際に使うとこんな感じです。
puppet-module search [keyword]
で欲しいモジュールを探して、
puppet-module install xx-yyy
でダウンロードしてきます。指定している xx-yyy ですが、 forge での名前空間は、 xx (作者名)/yyy (モジュール名)
となっていて、それを指定します。自分の名前が頭につくので、モジュール名は他の人とかぶっても大丈夫、ということで
すね。
19
注意が必要なのは、 install とはいいながら、コマンドを実行したカレントディレクトリに展開するだけで、 pup-
petdir/modules に自動で配置してくれるわけではないところです。ダウンロードした後で、自分で移動させてくだ
さい。
puppet-module には generate という機能もあり、モジュールの雛形を作ってくれます。この場合も、 forge の名前空
間を指定する必要があるので、使用例は次のようになります。
$ bin/puppet-module generate lurdan-homedir
$ mv lurdan-homedir ~/.puppet/modules
$ cd lurdan-homedir
$ emacs manifests/init.pp
generate で作成されるディレクトリ構造はこんな感じになります。モジュールとしてフル機能が実装できるように、あ
れこれ気を利かせてくれている感じがしますね。
Modulefile
README
manifests/
files/
templates/
tests/
lib/
spec/
metadata.json
モジュールを作るのに慣れてきたら、これを使っていくのもいいと思います。逆に、慣れないうちは余分なものが多くて
邪魔かも。
5.7 $HOME の管理に使う
さて。長い長ぁい前置きが終わり、ようやくここからが本題です。
puppet はその目的 (システムの構成管理) を考えても、 root で実行するのがほぼ前提です。
でも、そんな大げさにシステムあっちゃこっちゃいじらないし、自分の home ディレクトリで設定ファイルを適当に管
理してくれたらいいから、というのが今回のお題だったりするわけです。
package 操作などもあるので、やっぱり実行は root でやってもらう必要がどうしてもあります。でも、そのままファイ
ルを作られたら、パーミッションが root:root になってしまいますし、そもそも puppet はマニフェストの中で実行ユー
ザのホームディレクトリを認識するようには作られていません。
5.7.1 環境変数の受け渡し
では、どうしましょう。半ば無理矢理ではありますが、$HOME と $USER を puppet に渡して、それをマニフェスト側
で受けとればいいわけです。
渡す方は、「 FACTER 環境変数」というものを使って実現します。 FACTER 環境変数についての詳細は省きます
が、ひとまず一種のおまじないとして、渡したい環境変数の頭に、「 FACTER 」をつけるのだと思っておいてください。
具体的には、こういう感じで使います。
sudo FACTER_HOME=$HOME puppet /path/to/site.pp
こうして渡した環境変数は、マニフェストの中でこのように受けとることができます。
...
file { "$home/.lv":
}
...
最初に作ってもらったマニフェストを見直してみてください。この仕掛けを使えば、ユーザ名を直接書かずに、使い回せ
る形で書き直すことができます。モジュールにすることを考えても、こちらの方がより融通がきくようになりますね。ユー
ザ名埋め込みとか、ゾッとしませんよね。
当面必要になるのは、$HOME と $USER、後は group くらいなので、このあたりを埋めこんでシェルスクリプトにして
おきます。
20
#!/bin/sh
FACTERENV="FACTER_HOME=$HOME FACTER_USER=$USER FACTER_GROUP=‘id -gn‘"
sudo $FACTERENV puppet ~/.puppet/manifests/site.pp --modulepath ~/.puppet/modules --debug --verbose
これを適当に ˜/.puppet/puppet.sh あたりに保存しておいて、実行する時は
$ ~/.puppet/puppet.sh
とすれば、マニフェストのどこでも、$home と $user 、$group にアクセスすることができます。実行ユーザの環境変
数を拾っているので、シェルスクリプト自体には sudo は不要です。
これで下準備も整いましたので、どんどんマニフェストやモジュールを書いていってみてください。
5.8 もっと深みに
入門セッションということで、今日扱った内容からは、いろいろと重要なポイントが抜けています。一応キーワードだけ
列挙しておきますので、後述の資料とあわせて、参考にしてみてください。
• facter : 実行環境のデータを集めて変数として提供。 puppet の裏方
• ファイルサーバ : 事前に準備したファイルを各ノードに配布
• テンプレート : eruby で配布ファイルに変数埋め込み
• 仮想リソース : 定義の依存が被ってしまう場合に共用可能とする
• puppet 拡張 : ruby であれこれいじれるらしいです
• 環境 : 本番と検証と開発を分けたりできる
個人的に面白いなーと思っているトピックとして、
• puppetdoc : モジュールにマニュアルを埋め込む
• puppet のテスト
というのもあります。興味がある方はまた宴会ででも。
5.8.1 資料は英語
puppet の公式な資料は、 puppetlabs のサイトでメンテナンスされています。使うために必要な文書は比較的よく整備
されていると思いますが、基本的には英語です。
私は下記をよく参照しています。
• language tutorial : http://docs.reductivelabs.com/guides/language_tutorial.html
• type reference : http://docs.puppetlabs.com/references/stable/type.html
• meta parameter reference : http://docs.puppetlabs.com/references/0.25.5/metaparameter.html
5.8.2 日本語の資料
puppet は国内でも素晴しい先達によってすでに語り尽くされていたりしますので、もうちょっと慣れるまで英語は……
という方は、下記の資料などにあたってみてください。
今回のセッションで扱った内容は、ほぼこれらの資料でカバーされてる範囲を出ていなかったりしますが、とっかかりに
はなるのではと思います。
• オープンソースなシステム自動管理ツール Puppet : http://gihyo.jp/admin/serial/01/puppet
• Puppet によるインフラ管理入門 : http://www.sssg.org/
~
naoya/puppet/project.html
• puppet のススメ : http://www.slideshare.net/mizzy/puppet-3258268
21
第 36 回 関西 Debian 勉強会 2010 年 06 月
6 今後の予定
Debian JP
6.1 次回の関西 Debian 勉強会
次回、 2010 年 7 月の関西 Debian 勉強会はオープンソースカンファレンス 2010 Kansai @ Kyoto において「 第 37 回
関西 Debian 勉強会@OSC2010 Kyoto」を行ないます.
ブースではのがたさんの最新 Debian T シャツの販売や LiveDVD の配布、セッションでは佐々木さんの「 野良ビルド
から始める Debian パッケージ作成」を予定していますので、是非ご来場くださいです。
6.2 次々回の関西 Debian 勉強会
次々回、 2010 年 8 月の関西 Debian 勉強会は、 8 月 22 日 (日) に実施する予定です。
22
関西Debian 勉強会
Debian 勉強会資料
2010 年 06 月 27 日 初版第 1 刷発行
関西 Debian 勉強会（ 編集・ 印刷・ 発行）
23