第 56 回 関西 Debian 勉強会資料
関西 Debian 勉強会担当者 佐々木・ 倉敷・ のがた・ かわだ
2012 年 2 月 26 日
第 56 回 関西 Debian 勉強会 2012 年 2 月
1 Introduction
Debian JP
関西 Debian 勉強会は Debian GNU/Linux のさまざまなトピック (新しいパッケージ、 Debian 特有の機能の仕組、
Debian 界隈で起こった出来事、などなど）について話し合う会です。
目的として次の三つを考えています。
• ML や掲示板ではなく、直接顔を合わせる事での情報交換の促進
• 定期的に集まれる場所
• 資料の作成
それでは、楽しい一時をお楽しみ下さい。
1
第 56 回 関西 Debian 勉強会 2012 年 2 月
2 最近のDebian関係のイベント
報告
Debian JP
2.1 第 55 回関西 Debian 勉強会
55 回目の関西 Debian 勉強会は 1 月 28 日と 29 日の二日間の温泉合宿として開催されました。
用意した apt のミラーサーバにソースパッケージが含まれていないという思わぬ状況になりましたが、いつもの勉強会会
場とは違った場所で集中して Hack ができました。
2.2 第 85 回東京エリア Debian 勉強会
85 回目の東京エリア Debian 勉強会が 2 月 18 日に開催されました。
参加者が少なかったようですが KDE 開発、月刊 debhelper についての発表がありました。
2.3 第 0 回福岡 Debian 勉強会
同じく 2 月 18 日に福岡でも Debian 勉強会が開催されました。
0 回目となる今回の勉強会では Debian サーバの量産方法、 DKMS とパッケージ作成、キーサインパーティなどが行な
われたようです。
今後も Debian 勉強会が開催されていくとよいですね。
3
第 56 回 関西 Debian 勉強会 2012 年 2 月
3 事前課題
Debian JP
今回は以下の課題を出題しました.
事前課題 1 chroot について知っていますか。
1. 知らない人、 chroot について調べたことを記入してください。
2. 知っている人、 PAM とオートマウンタの設定を触ったことはありますか?
設定を触ったことがあるかたはその内容も記入してください。
事前課題 2 DebianPolicy の 7 章に目を通しておいてください。
参加者の皆さんの解答は以下の通りです.
3.1 kozo2
1. 知ってます
2. ないです
3. 読みます
3.2 西山和広
1. 知っています。
• PAM は pam-auth-update がなかった頃に libpam-ldap や libpam-tmpdir を使う設定をしました。オート
マウンタは LDAP と組み合わせてホームディレクトリをマウントするのに使ったことがあります。
3.3 佐藤誠
1. Yes.
Linux From Scratch や Gentoo Linux のインストールのときに使っていました。
Debian でもあれこれしたいときによく使います。
最近は chroot が進化したような jail(8) とか lxc とかをちょこちょこ触っています
2. ありません (汗
3.4 川江
1. 同一 PC 上で、「 異なる」 root directory 環境を提供する。
4
• 触った事はありません。
2. All right
3.5 山下康成
1. 知ってます
• ずっと以前に触ったことはありますが、もう忘れてます。
2. ざっと
3.6 酒井 忠紀
1. chroot は、以下のように使用したことがあります。
• Debian ベースにシステムにおいて、 Linux Kernel を Android 拡張し、 chroot で Debian から Android
に切り替える
• Andorid から Android の init プロセス配下を全て kill し、 chroot 起動元の Debian のコンソールに戻る
2. PAM や オートマウンタ の設定を触ったことはありません。 Debian の GNOME だと、 USB などの自動マウン
トは autofs ではなく、 nautilus で行っているのを見たことがあります。
3.7 かわだてつたろう
1. 知っています。
• 触ったことはありません。発表を楽しみにしています。
2. みておきます。
3.8 gdevmjc
1. chroot について、知っています。
PAM は、 pam limits, pam chroot, pam ldap などの設定を触ったことがあります。 pa wheel を追加したこと
もあります。オートマウンタは、マスターマップファイル、間接マップファイルともに触ったことが余す。 NFS や
bind のマップを定義しました。
2. はい、とりあえずチラ見しました。
3.9 0xBCD1BC92
1. Yes
• chroot で、 PAM とオートマウンターの設定をしたことがない。
2. Debian Policy の 7 章を眺めました。
3.10 水野源
1. Yes
2. autofs は Yes、 PAM は……忘れた
3. ぉぅぃぇー
5
3.11 Y.YATSUO
1. いいえ。
概要:
ルートディレクトリを変更してプロセスがその外にアクセスできないようにする
使われ方:
• Debian ではクリーンなビルド環境を作る
• セキュリティ強化の為にデーモン系を chroot 環境で動かす
2. 読んでおきます
3.12 lurdan
1. yes
2. no
3. yes
3.13 のがたじゅん
1. 知ってます。
交野市の Xubuntu の話の中で、 LDAP で認証してホームをマウントするのに pam mount を使っただか使いたい
とか話しがあって、その辺調べようと思ってたけどそのまま棚上げになってます。
2. 日本語で読んでもいいですか (´； ω；｀ )
http://www.debian.or.jp/community/devel/debian-policy-ja/policy.ja.html/ch-relationships.
html
3.14 佐々木洋平
1. 知ってます。 git-buildpackage 用に cowbuilder を走らせる git-builder という shell script を使ってます。
2. はい。某所ではサーバ御本尊の $HOME を NFS でクライアントに提供していて、 LDAP で認証後に autofs で
mount しています。
3. 読んでおきます。
6
第 56 回 関西 Debian 勉強会 2012 年 2 月
4 Autofs と pam chroot で作る
マルチユーザー環境
山城国の住人 久保博
4.1 はじめに
皆さんの職場などの組織内ではファイル共有サーバーやメール受信サーバーなど、組織内で情報を共有するためのサー
バーを建てている場面もあるかと思いますが、
• 他のユーザーのホームディレクトリ内が覗けると不都合がある。
• システム内の見せなくて良いファイルは見せたくない
など、運用面の制約があって、一般ユーザーにログインさせることを躊躇することはないですか?
そんな場合には、ユーザー毎に chroot 環境を用意できれば安心してログインさせられるようになります。しかし、一般
に知られた方法で実施しようとすると、ユーザー毎に chroot 先のシステム環境を用意することになりますし、ユーザーを
追加するたびに新しい chroot 環境を用意したりすれば、それだけ多くのディスクスペースも必要です。
ところが、 一工夫すると、一つの chroot 環境を複数のユーザー間で共用しながらユーザー間の chroot 環境は分離さ
せることができるという、うまい話があるのです。
4.2 道具立て
そのための主な道具が autofs と pam chroot です。まずはそれぞれについて紹介をしておきましょう。
4.2.1 pam chroot
PAM とは Pluggable Authentication Modules の略
*
1
です。今はなき Sun Microsystems が世に出した認証処理の枠
組で、動的ライブラリとしてモジュール化された処理、設定ファイル、呼出側への API などから成ります。 pam chroot
はその中で、認証処理の途中で認証されたユーザーセッションのプロセスを chroot 環境に放り込んでしまう処理を担当し
ます。次のコマンドでインストールしましょう。
$ sudo aptitude install libpam-chroot
4.2.2 Autofs
Autofs は、オートマウンターと呼ばれるコマンドです。 Sun Microsystems には NFS の拡張機能の automount とい
うコマンドがあり、 NFS のボリュームのマウントをオンデマンドで行なってくれるデーモンでしたが、 Linux の autofs
*
1
pam(5) の pam ではなく、 PAM(7) の PAM です。
7
は NFS に限らず、他のファイルシステムもオンデマンドでマウントしてくれます。次のコマンドでインストールしま
しょう。
$ sudo aptitude install autofs5
4.3 マルチユーザー環境の設計
道具立てが揃ったら、次はどのように環境を構築をするか、考えます。ログインしさえすればどんな場合でも chroot 環
境に放り込んでしまうと、システム管理ができなくなりますから、どんな条件でログインしたら chroot 環境に放り込むの
か、そして、どういう機構を使って放り込むかを考えて決めてゆきます。
4.3.1 アカウント
「 chroot させるユーザー」をどのように指定するか、まず問題になりますが、ユーザーのグループ設定を使うと後々設
定が便利になりますので、お勧めします。ここでは、 chroot させるユーザーは staff グループに属することにします。
root と管理用アカウント（ admin など）は、 staff グループに属させないように注意しましょう。
4.3.2 ログインの経路
次に、 ログイン処理のいずれかの段階でユーザーのプロセスを chroot 環境に放り込むわけですから、どのようにログ
インするかを特定しておく必要があります。いわば、システム内に足を踏み入れる玄関口を把握しておく、というわけで
す。筆者の思いつく代表的な玄関口を挙げてみましょう。
• VGA コンソール
• シリアルコンソール
• ssh, sftp
• rlogin, rcp, rsh
• telnet
• ftp
• X セッションマネージャー (xdm, gdm,. . . )
• su, sudo
どうでしょう、読者のみなさんにとって、十分でしょうか。基本的には、これらの数だけ chroot の設定が必要です。
4.3.3 chroot の処理を何に任せるか
chroot する操作は、結局 chroot システムコールを呼び出す処理に帰着するわけですが、ログインを司るアプリケー
ションサーバープログラムそのものが、 chroot に対応している場合もあります。そうでない場合は、 PAM で認証の処
理をする際に、 pam chroot で chroot するようにします。
設定さえすれば chroot させられるサーバーには、
• OpenSSH 4.8 以降
• ProFTPD
• vsftpd
がありますので、これらはサーバーの機能を活用し、他の経路でのログインでは pam chroot で chroot させることにし
ます。
8
4.4 設定
4.4.1 chroot の設定
ここでは、/jail/chroot の下にユーザー名と同じ名前のディ レクトリを作り、各ユーザーがログインした
ら、そのディ レクトリの下に chroot させるようにします。例えば、ユーザー名 hiroshi でログインしたら、
/jail/chroot/hiroshi の下に chroot することになります。まずは、 chroot 先として必要なディレクトリを作り
ます。
mkdir /jail/chroot
OpenSSH の設定
/etc/ssh/sshd config に、次の設定行を追記します。
Match Group staff
ChrootDirectory /jail/chroot/%u
ProFTPD の設定
一般ユーザーの FTP のセッションでは、自分のホームディレクトリにさえアクセスできれば、十分なはずです。また、
ProFTPD の場合、ユーザーセッションから /dev/ 以下のスペシャルファイルにアクセスさせる必要さえありません。で
すので、各人のホームディレクトリに閉じ込めてしまうことにします。
ProFTPD の設定ファイル /etc/proftpd/proftpd.conf で
DefaultRoot ~ staff,!root
のようにしておきます。
pam chroot による設定
VGA モニターのコンソールやシリアルコンソールのログインを担当する /bin/login, r 系コマンド
*
2
、 telnet などか
らのログインでは、ログイン処理を担当するプログラム処理が自力で chroot を呼んだりはしません。これらの認証処理で
は PAM を利用するので、 PAM のモジュール、 pam chroot で chroot するように設定します。
/etc/pam.d/login , /etc/pam.d/rlogin, /etc/pam.d/rexec, /etc/pam.d/rsh そして /etc/pam.d/other
に設定を追記します。
session required pam_chroot.so use_groups
また、 /etc/security/chroot.conf に、次の一行を追加します。
@staff /jail/chroot/%u
なお、筆者の調べた範囲では、 krb5-telnetd パッケージで提供される telnet サーバーデーモンや krb5-rsh-server
パッケージで提供される rlogin サーバーデーモンは PAM に対応しておらず、 chroot はできません。認証に Kerberos
を利用したい場合は PAM に対応した telnetd などを提供する heimdal-servers パッケージを使うと chroot できます。
また、 xdm, gdm については、 Debian squeeze の場合、 xdm は xdm パッ ケージ、 gdm は gdm もしく
は gdm3 パッ ケージで提供されます。筆者の環境では gdm3 と xdm を用意していますので、/etc/pam.d/gdm3,
*
2
rlogin, rsh, rexec, rmt, . . .
9
/etc/pam.d/xdm に設定を追記しています。
session required pam_chroot.so use_groups
なおこの場合、 X サーバーと X クライアントの間の認証のために利用する $XAUTHORITY 認証ファイルの設定が、
chroot 前後で整合していないといけません。筆者の環境ではうまくいきましたが、 chroot 環境の設定が変わると X サー
バーと X クライアントの間の認証に問題が発生する可能性はあります。
4.4.2 Chroot 環境を構築する autofs の設定
次に、/jail/chroot 以下に、各ユーザー毎の chroot 環境を構築するための autofs の設定を紹介します。編集する
設定ファイルには、マスターマップファイル
*
3
の /etc/auto.master と間接マップファイル
*
4
/etc/auto.jailstaff
の二つあります。
/etc/autofs.master
/jail/chroot auto.jailstaff
/etc/autofs.jailstaff
* / -ro :/jail/root \
/home/staff/& -rw :/home/staff/& \
/dev -rw :/dev \
/etc -ro :/etc \
/bin -ro :/bin \
/usr -ro :/usr \
/lib -ro :/lib \
/var -rw :/var \
/proc -fstype=proc proc \
/tmp -fstype=tmpfs,rw tmp \
/dev/pts -fstype=devpts,rw devpts
設定できたら、 mkdir /jail/root をしてから、 autofs を起動しましょう。
# /etc/init.d/autofs start
もちろん、/etc, /bin, /usr, /lib などのディレクトリを dchroot や schroot で構築した別のバージョンの Debian
のものにすることもできます。
4.5 別の方法
4.5.1 OpenSSH で ChrootDirectory を使わない方法
OpenSSH は PAM に対応しているので、 pam chroot を使うこともできるのですが、 4.4.1 節では、 pam chroot を
使わずに chroot させる方法を紹介しました。その理由は、 4.4.1 節の方法では特権分離の機能が有効なままで chroot を
伴うログインができるので、より安全な方法だからです。
一方、特権分離の機能を無効にしなくてはいけませんが、 pam chroot を使うこともできるので、ここでトリビアとし
て紹介しておきます。
pam chroot に chroot の処理を委ねる場合、ログインユーザーの認証が済んで、 pam chroot が chroot システムコー
ルを呼ぶ処理の段階で、 sshd が root 権限で動いていないといけないので、 OpenSSH の「 特権分離」と呼ばれる機能を
無効にする必要があります。
その設定ですが、/etc/ssh/sshd config の
*
3
詳しくは man auto.master を参照。
*
4
詳しくは man 5 autofs を参照。
10
UsePAM no
の行を
UsePAM yes
に変更すると、 PAM が有効になります。これで特権分離は利かなくなりますが、明示的に禁止する場合は
UsePrivilegeSeparation yes
の行を
UsePrivilegeSeparation no
にします。その上で、 /etc/pam.d/sshd に 4.4.1 節に掲げた設定を追記して、 chroot を pam chroot に委ねるよ
うにします。
4.5.2 rssh
rsh の書き間違いではありません。 rssh という、 scp や sftp 専用アカウントでログインシェルとして利用する目的の
シェルがあります。 rssh の設定ファイルには、 chroot を指定できるので、ユーザーのログインシェルを rssh にすると、
rssh が chroot を担当してくれます。 SSH での接続でファイル転送しか許さないユーザーには、このシェルを使うと良い
でしょう。
4.5.3 wu-ftpd, vsftpd
Ftp サーバーのいくつかの実装には、グループ単位ではない、別の記法で chroot 先を指定する機能があります。もとも
とは、 wu-ftp d という古い ftp サーバーの実装で導入された記法で、/etc/passwd にあるユーザーのホームディレクトリ
のパスの設定に於いて “/home/./foo” のように、 “/./ “ という区切り子があると、 ftp のログイン時にそこへ chroot
させます。最近は Wu-ftpd を使う人もほとんどいないと思いますが、新しくて人気のある ftp サーバーの実装の vsftpd
もこの記法を引き継いでおり、設定すれば “/./ “ のディレクトリに chroot させられます。
4.6 応用
Autofs の間接マップファイルにファイルシステムのマッピングの定義を追加することで、いろいろなことができそう
です。
• Apache httpd の userdir の public html を autofs の別の場所からマウントする。
• Git のベアリポジトリを autofs で各ユーザーの chroot 配下にマウントして、 ssh://· · · でアクセスできるように
し、共有リポジトリを提供する。
• Subversion の共有リポジトリを autofs で各ユーザーの chroot 配下にマウントして 、 ssh+svn://· · ·/ でアクセ
スできるようにする。
4.7 まとめ
一般ユーザーのログインする環境を chroot 環境に閉じ込めるための Debian GNU/Linux システムの設定の問題を取
り上げ、特に、 chroot 環境を作るために autofs が有用であることを紹介しました。
また Debian の文化では、 pbuilder や schroot など、一人で占有する PC で別の OS 環境を構築するために chroot
の機構を使うことが多いですが、 chroot をマルチユーザー環境を舞台した別の発想の使い方が紹介できたのではないかと
思います。
謝辞
関係する全てのソフトウェアの開発者の皆様に感謝致します。
11
第 56 回 関西 Debian 勉強会 2012 年 2 月
5 emacs24で問題なく使える
t-code.deb を作った話
西田 孝三
第 54 回関西 Debian 勉強会では「 t-code のバグレポをしてみた」という題で発表しました。前回の発表では Debian
のバグトラッキングシステムを使って t-code パッケージのバグレポートから Debian パッケージの作成を試み、失敗する
ところで止まっていました。今回はまず問題なく動作するパッケージを作成すると共に、とりあえずパッケージを作成する
(いわゆるオレオレパッケージ) にはどのようなことを行えばよいかを下記の 4 点に分けてお伝えします。
1. (バグを含む) 現在の Debian パッケージのソースコードの取得と、ビルド方法の確認
2. バグ修正を含むソースコードへの置き換えとビルド、オレオレパッケージの作成
3. オレオレパッケージの動作確認
4. (修正が必要な場合)Debian ディレクトリ下のファイルの変更
5.1 現在の Debian パッケージのソースコードの取得と、ビルド方法の確認
まず既存の Debian パッケージのソースコードを取得し、ビルドすることでパッケージ作成方法の確認をします。パッ
ケージのソースコードの取得を行うには apt-get コマンドに source オプションを付けパッケージを指定します。
kozo2@debian:~/sandbox$ apt-get source t-code
kozo2@debian:~/sandbox$ ls
t-code-2.3.1 t-code_2.3.1-3.dsc
t-code_2.3.1-3.diff.gz t-code_2.3.1.orig.tar.gz
これでソースが取得できます。今回はとにかくパッケージを作ることが目的ですので*.dsc, *.diff.gz, *.orig.tar.gz の意
味は説明せず、 t-code-2.3.1 へ移動し、まずこのソースを用いてビルドを行いパッケージ (.deb ファイル) を作成してみ
ます。これには debuild コマンドを用います。
kozo2@debian:~/sandbox$ cd t-code-2.3.1/
kozo2@debian:~/sandbox/t-code-2.3.1$ ls
acinclude.m4 ChangeLog.old COPYING install-sh mazegaki skkinput3
aclocal.m4 config.guess debian kinput2 missing
AUTHORS config.sub doc lisp mkinstalldirs
bushu-util configure etc Makefile.am NEWS
ChangeLog configure.in INSTALL Makefile.in README
kozo2@debian:~/sandbox/t-code-2.3.1$ debuild -us -uc
debuild コマンドのオプション -us -uc は署名はせずに単に package に build する時に用います。これで一つ上の
directory に.deb ファイルができます。
kozo2@debian:~/sandbox/t-code-2.3.1$ ls ..
t-code-2.3.1 t-code_2.3.1-3_amd64.build t-code_2.3.1-3.diff.gz t-code_2.3.1.orig.tar.gz
t-code_2.3.1-3_all.deb t-code_2.3.1-3_amd64.changes t-code_2.3.1-3.dsc
13
5.2 バグ修正を含むソースコードへの置き換えとビルド、オレオレパッケージの作成
次にバグのあるソースコードを新しいソースコードに置き換え、ビルドができるかどうか試してみます。新しいソース
コードは http://code.google.com/p/tcode/から取得します。
kozo2@debian:~/sandbox/t-code-2.3.1$ cd ..
kozo2@debian:~/sandbox$ svn co http://tcode.googlecode.com/svn/trunk/ tcode-read-only
置き換えが必要なファイルを新しいソースコードをコピーすることで上書きします。
kozo2@debian:~/sandbox$ cp tcode-read-only/tc/bushu-util/* t-code-2.3.1/bushu-util/
kozo2@debian:~/sandbox$ cp tcode-read-only/tc/etc/* t-code-2.3.1/etc/
kozo2@debian:~/sandbox$ cp tcode-read-only/tc/lisp/* t-code-2.3.1/lisp/
kozo2@debian:~/sandbox$ cp tcode-read-only/tc/mazegaki/* t-code-2.3.1/mazegaki/
これでビルドが通るか試します。 (通ります)
kozo2@debian:~/sandbox$ cd t-code-2.3.1
kozo2@debian:~/sandbox$ debuild -us -uc
とりあえず、置き換えたソースコードでパッケージができました。次はこれをインストールし動作確認してみます。
5.3 オレオレパッケージの動作確認
先程作成した用いるソースコードに変更を加えた Debian パッケージをインストールし、動作に問題がないか確認しま
す。インストールするには dpkg コマンドに-i オプションをつけてインストールしたい.deb ファイルを指定します。
kozo2@debian:~/sandbox$ sudo dpkg -i t-code_2.3.1-3_all.deb
Selecting previously unselected package t-code.
(Reading database ... 97587 files and directories currently installed.)
Unpacking t-code (from t-code_2.3.1-3_all.deb) ...
Setting up t-code (2:2.3.1-3) ...
install/t-code: Handling install for emacsen flavor emacs23
Processing triggers for install-info ...
kozo2@debian:~/sandbox$
インストールは問題ないようです。それでは t-code が問題ないか emacs を起動し試してみます。試しに t-code 練習プ
ログラム eelll の起動を試みると emacs が下記のメッセージを出し、何か問題があることがわかります。
Debugger entered--Lisp error: (error ‘‘ファイル /usr/share/tc/EELLLTXT が存在しません。’’)
signal(error (‘‘ファイル /usr/share/tc/EELLLTXT が存在しません。’’))
error(‘‘ファイル %s が存在しません。’’ ‘‘/usr/share/tc/EELLLTXT’’)
tcode-set-work-buffer(‘‘ *eelll: text*’’ ‘‘EELLLTXT’’)
eelll-completing-read()
call-interactively(eelll t nil)
execute-extended-command(nil)
call-interactively(execute-extended-command nil nil)
5.4 Debian ディレクトリ下のファイルの変更
先程の問題は t-code が用いる交ぜ書き、部首合成変換用データがインストールされているディレクトリを指定する
emacs の変数 tcode-site-data-directory の設定によるものです。この tcode-site-data-directory を指定し直すにはパッ
ケージ作成用 directory 下の debian/emacsen-startup に下記の設定を追加しビルドし直します。
14
;;; 50t-code.el --- Debian t-code startup file -*-mode: emacs-lisp;-*-
;;; Code:
(let ((lispdir (concat ‘‘/usr/share/’’ (symbol-name flavor) ‘‘/site-lisp/t-code’’)))
(when (and (featurep ’mule) (file-exists-p (concat lispdir ‘‘/tc.elc’’)))
(if (fboundp ’debian-pkg-add-load-path-item)
(debian-pkg-add-load-path-item lispdir)
(setq load-path (cons lispdir load-path)))
;;
(require ’tc-setup)
(defconst tcode-site-data-directory ‘‘/usr/share/t-code/’’)
;;
))
;;; 50t-code.el ends here
kozo2@debian:~/sandbox/t-code-2.3.1$ debuild -us -uc
kozo2@debian:~/sandbox/t-code-2.3.1$ sudo aptitude purge t-code
kozo2@debian:~/sandbox/t-code-2.3.1$ sudo dpkg -i ../t-code_2.3.1-3_all.deb
これで emacs23 や 24 といっ た新しい emacs で t-code の交ぜ書き、部首合成変換が問題なく使えるようにな
っ ていると思います。ちなみにこの emacsen-startup の elisp の内容は Debian パッ ケージのインストールによっ
て/etc/emacs/site-start.d/50t-code.el にコピーされます。
5.5 おわりに
いかがでしたでしょうか。今回はとりあえず Debian パッケージを作るという目的でソースコードは変更を上書きした
だけですが、本来は差分の変更などを記録する必要があるためまだまだやらねばならないことはあります。 upstream の
t-code の継続開発を行なっている方、これまでの t-code Debian パッケージメンテナの方への連絡といったこともそうで
す。そういったことに関してはまた次回の関西 Debian 勉強会で発表させて頂ければと思っています。
15
第 56 回 関西 Debian 勉強会 2012 年 2 月
6 月刊 Debian Policy「 パッケー
ジの依存関係についての
ルール」
倉敷 悟
分量も多くてなかなか読み辛いのが Debian Policy。敬遠している方もいると思います。とはいえ、「 ポリシー」と大
仰な名前がついてはいますが、結局のところ書かれている内容は
「 パッケージの作り方についてのルール、ガイド、ベストプラクティス」
を集めたものです。パッケージの開発をしていないとしても、ファイルの配置や依存関係に不可解なものを感じたことが
あれば、その答えがきっと見つかるはずです。
というわけで、勉強会で連続コマとして少しずつ読んでいってみることにします。いろいろ含めて、おおよそ 1 年かけ
て終了することになると思います。担当した人は、まだ担当していない人から次回の担当者を指名します。指名された人
は、まだ読まれていない章から順不同で好きな部分を選んでください。
さて、今回読むのは、パッケージの依存関係のポリシーについて記載されている 7 章です。
依存関係といって思い浮かぶのは Depends に代表される「 前提として事前に必要」ですが、 dpkg では他にも色々な形
で「 そのパッケージと他のパッケージの関係」を表現することができます。
さて、ポリシー本文は事前課題として当然
*
6
読み終わっているはずですが、簡単におさらいしていきましょう。空いた時
間は四方山話として、フリーディスカッションのような形で、皆さんが舐めてきた辛酸を肴にして頂こうと思います。
6.1 おさらい
6.1.1 debian/control の書式
依存関係の指定は、 debian/control ファイルに、依存関係の種類に応じたフィールドとその値をセットすることで行い
ます。
Depends: libqdbm14, libestraier
必要があれば、カンマで区切って複数のパッケージ名を列挙することができます。これにバージョン指定が入ると、
Depends: libqdbm14 (>> 1.8.77 ), libestraier
となります。この場合、 libqdbm14 の 1.8.77 では依存を満たせません。
同類がいくつかあって、そのうちどれかがあればよい、という場合はパイプ (|) を使って
Depends: emacs23 | emacs22 | emacs21
*
6
実は事前課題を指定した時点では、日本語訳の存在をすっかり忘れていました
16
と書くことができます。
6.1.2 バイナリパッケージ用フィールド
バイナリパッケージでは、そのパッケージをインストールするために必要な情報として依存関係が使われます。まずは基
本的なものから。
Depends なくては動かないパッケージを指定します。
Recommends なくても動きはするけれど、できれば一緒に使った方がいいパッケージを指定します。
Suggests 一緒に使うと便利なパッケージを指定します。主体はこのパッケージです。
Enhances 一緒に使うと便利なパッケージを指定します。主体は指定されたパッケージです。
Pre-Depends 通常の Depends よりも前の段階で依存先のパッケージがチェックされます。非推奨なので、使われている
場合は何か地雷があるのかもしれません
一方で、少しややこしい関係性として、次のようなものがあります。
Breaks 比較的最近追加されました。このパッケージをインストールすることで動作しなくなるパッケージを指定しま
す。通常は、自パッケージの再編成で使われるようです
Conflicts 完全に両立不可能なパッケージを指定します。システムにはそのうち 1 つしかインストールできません
Replace 指定したパッケージ全体、もしくは一部のファイルを、このパッケージで置き替えます
Provides (存在する場合) このパッケージが代替し得る、特定の仮想パッケージを指定します
6.1.3 ソースパッケージ用フィールド
ソースパッケージは、いわゆるインストールをして使うものではないので、 Depends は意味を持ちません。ソースパッ
ケージの依存関係では、そのソースパッケージをビルドするために必要な情報として依存関係が使われます。
Build-Depends ビルドするために必要なパッケージを指定します
Build-Conflicts ビルドする時にインストールされていてはいけないパッケージを指定します
Build-Depends-Indep build-indep ターゲットをビルドするために必要なパッケージを指定します
Build-Conflicts-Indep build-indep ターゲットをビルドする時にインストールされていてはいけないパッケージを指定し
ます
6.2 四方山話
時間次第ですが、ここでは次のような話をざっくりとする予定です。
• Depends と Recommends と Suggests の違い
• Provides と仮想パッケージ
会場で特にこれといって話題が出なさそうであれば、抜きうちで事前課題の理解度テスト、みたいなことをするかも知れ
ません。
6.3 次号予告
次回の担当は、 yyatuo さんにお願いします (本人承諾済み)。
17
第 56 回 関西 Debian 勉強会 2012 年 2 月
7 今後の予定
Debian JP
7.1 次回
次回は、 2012 年 3 月 25 日に福島区民センターで行います。
発表については未定ですので、みなさまの発表をお待ちしております。
18
関西Debian 勉強会
Debian 勉強会資料
2012 年 2 月 26 日 初版第 1 刷発行
関西 Debian 勉強会（ 編集・ 印刷・ 発行）
19
