Deb 専 (旧あんどきゅめんてっど でびあん) 2011 年夏号 Deb専 日本唯一のDebian専門誌 2011 年 08 月 13 日 初版発行 ア リ エ 東京 関西 会 強 勉 n a i b De 会 強 勉 n a i b De デビアン勉強会 目次 1 Introduction 2 2 「フリー」って、どういうこと? 3 3 Squeeze の変更点をみんなで見てみよう 7 4 Squeeze をみんなインストールした結果を語る会 10 5 Debian のドキュメントをみてみよう 11 6 ハッカーに一歩近づく Tips:vi 編 16 7 Debian GNU/kFreeBSD で便利に暮らすための Tips 19 8 Debian Games Team 体験記 23 9 Kinect を Debian で使ってみた 26 10 俺の libsane が火を噴くぜ! 35 11 Proxmox VE の紹介 39 12 Apache2 のモジュールをつくってみた 42 13 CAcert の準備に何が必要か 46 14 CACert Assurance 58 15 月刊 PPC64 ポーティング 2011 年 04 月, 05 月 60 16 Debian/m68k 開発 63 17 バグ報告はバグのためだけじゃないよ 67 18 dpkg のおさらい 73 19 backports.debian.org 76 20 pbuilder を使ってみよう 82 21 Debian 勉強会予約システムにアンケート追加 87 22 2010 年の東京エリア Debian 勉強会をふりかえって 91 23 関西 Debian 勉強会 2010 年度各種イベント開催実績と総括 94 24 執筆者紹介 97 25 Debian Trivia Quiz 98 26 Debian Trivia Quiz 問題回答 1 102 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 1 Introduction 上川 純一, 山下 尊也 1.1 東京エリア Debian 勉強会 Debian 勉強会へようこそ。これから Debian の世界にあしを踏み入れるという方も、すでにどっぷりとつかってい るという方も、月に一回 Debian について語りませんか? Debian 勉強会の目的は下記です。 • Debian Developer (開発者) の育成。 • 日本語での「開発に関する情報」を整理してまとめ、アップデートする。 • 場 の提供。 – 普段ばらばらな場所にいる人々が face-to-face で出会える場を提供する。 – Debian のためになることを語る場を提供する。 – Debian について語る場を提供する。 Debian の勉強会ということで究極的には参加者全員が Debian Package をがりがりと作るスーパーハッカーになっ た姿を妄想しています。情報の共有・活用を通して Debian の今後の能動的な展開への土台として、「場」としての空 間を提供するのが目的です。 1.2 関西 Debian 勉強会 関西 Debian 勉強会は Debian GNU/Linux のさまざまなトピック (新しいパッケージ、Debian 特有の機能の仕 組、Debian 界隈で起こった出来事、などなど)について話し合う会です。 目的として次の三つを考えています。 • ML や掲示板ではなく、直接顔を合わせる事での情報交換の促進 • 定期的に集まれる場所 • 資料の作成 それでは、楽しい一時をお楽しみ下さい。 2 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 2 「フリー」って、どういうこと? 木下 達也 2.1 フリーソフトウェアとは Debian はフリーソフトウェアで構成されたオペレーティングシステムです。ここで言う「フリー」とは「無料」で はなく「自由」を意味しています。 Free Software Foundation (FSF) による『フリーソフトウェアの定義』では次のように説明されています。 「フリーソフトウェア」のフリーとはそのソフトウェアのユーザに与えられる 4 種類の自由を意味しています。 • 目的を問わず、プログラムを実行する自由 (第 0 の自由)。 • プログラムがどのように動作しているか研究し、そのプログラムに あなたの必要に応じて修正を加え、採 り入れる自由 (第 1 の自由)。ソースコードが入手可能であることはこの前提条件となります。 • 身近な人を助けられるよう、コピーを再頒布する自由 (第 2 の自由)。 • プログラムを改良し、コミュニティ全体がその恩恵を受けられるよう あなたの改良点を公衆に発表する自 由 (第 3 の自由)。ソースコードが入手可能であることはここでも前提条件となります。 (http://www.gnu.org/philosophy/free-sw.ja.html) 2.2 著作権とライセンス 著作物には、基本的に著作者に対して著作権が発生しており、著作物を変更したりコピーして配ったりするには、 著作者からの許可 (ライセンス) が必要になります。 フリーかどうかを判定する際には、変更や配布が許可されているか、それらに付随する制約はどうか、といった点 を確認します。 そのほかに、特許、商標など個別の事情についても検討します。 2.3 Debian フリーソフトウェアガイドライン ある著作物がフリーかどうか、Debian の構成要素として適しているかどうかを判定する際の基準、それが Debian フリーソフトウェアガイドライン (DFSG) です。 1. 自由な再配布 2. ソースコード 3. 派生ソフトウェア 4. 原作者によるソースコードの整合性維持 5. すべての個人、団体の平等 3 6. 目標分野の平等 7. ライセンスの配布 8. ライセンスは Debian に限定されない 9. ライセンスは他のソフトウエアを侵害しない 10. フリーなライセンスの例 (http://www.debian.org/social_contract#guidelines) DFSG の各条項について簡単に説明します。 1. 自由な再配布 (Free Redistribution) 有償・無償を問わず、別途の許可を必要とすることなく、プログラムを複数まとめて配布できます。 2. ソースコード (Source Code) ソースコード (変更に適した形式) が必要です。実行形式だけでなくソースコードでも配布できます。 3. 派生ソフトウェア (Derived Works) 同様のライセンスで変更版を配布できます。 4. 原作者によるソースコードの整合性維持 (Integrity of The Author’s Source Code) 変更版のソースコードを配布する場合に、元のソースコードと差分 (パッチ) という形式のみ許可という制約は 許容します。ただし非推奨です。 5. すべての個人、団体の平等 (No Discrimination Against Persons or Groups) いかなる個人・団体も差別せずに許可します。 6. 目標分野の平等 (No Discrimination Against Fields of Endeavor) 商用・非商用など、用途を制限しません。 7. ライセンスの配布 (Distribution of License) ライセンスは、再配布されたすべての人々に、別途の許可を必要とすることなく適用されます。 8. ライセンスは Debian に限定されない (License Must Not Be Specific to Debian) Debian の一部としてのみの許可ではなく、他のシステムにも適用できるようにします。 9. ライセンスは他のソフトウエアを侵害しない (License Must Not Contaminate Other Software) たとえば、同じ媒体で配布されるソフトウエアすべてがフリーであることを要求しないようにします。 10. フリーなライセンスの例 (Example Licenses) GNU General Public License (GPL), BSD License, Artistic License が例として挙げられています。 2.4 オープンソースの定義 Open Source Initiative (OSI) による『オープンソースの定義』(OSD) は DFSG を元に作られました。何度か改 訂されていますが、現状でも内容は DFSG とほぼ同等のものです。 ここでは、一見して異なる OSD 第 10 条についてのみ説明します。 10. ライセンスは技術中立的でなければならない (http://opensource.jp/osd/osd-japanese.html) たとえば、GUI 環境で「同意する」ボタンを押すことが必須であってはならない、ということになります。内容と しては DFSG/OSD の第 7 条に含まれているものとも言えそうですが、OSD では、いわゆるクリックラップについ て、この条項で特に注意を促しています。 2.5 コピーレフト コピーレフトとは、著作物やその変更版について、フリーであることを要求するための方法のことです。 4 GNU GPL は代表的なコピーレフトライセンスです。GNU GPL で配布されるソフトウェアは、その変更版の配 布についても GNU GPL が適用され、フリーソフトウェアであり続けます。 著作物全体への適用が「弱い」コピーレフトライセンスもあります。たとえば、GNU Lesser General Public License (LGPL) で配布されるライブラリは、リンクするプログラム全体についてはコピーレフトが適用されま せん。そのほかに、Mozilla Public License (MPL)、Eclipse Public License (EPL)、Common Development and Distribution License (CDDL) など、ファイル・モジュール単位でのコピーレフトライセンスもあります。 2.6 ライセンスの互換性 複数の著作物を組み合わせて一つの著作物にする場合、それぞれのライセンスによる要求が矛盾しないかどうか、 互換性が問題になることがあります。 たとえば、CDDL では GNU GPL とは違った要求をしているので、GNU GPL で配布されるソフトウェアと CDDL で配布されるソフトウェアを組み合わせた著作物は配布できません。 ライセンスの非互換を回避するには、複数のライセンスを適用する (デュアルライセンス)、例外条項を設ける、単 純で何でも許可するようなライセンスにする、といった方法があります。 2.7 ASP ループホール GNU GPL には、アプリケーションサービスプロバイダ (ASP) の抜け穴 (loophole) が存在することが知られてい ます。 手元のコンピュータではなく「あちら側」のコンピュータで実行されるウェブアプリケーションの場合、そのウェ ブアプリケーションが GNU GPL で配布されたソフトウェアを含んでいたとしても、ネットワークユーザーにソー スコード込みで再配布されるわけではありません。 その抜け穴をふさぐためのライセンスが GNU Affero General Public License (AGPL) です。ネットワークユー ザーへのソースコード提供を求める条文が GNU GPL に加えられたものになっています。 2.8 自由と協力 なぜソフトウェアをフリーにするのでしょうか。フリーソフトウェア、オープンソースの関係者それぞれに様々な 思惑があることと思いますが、ここでは一つの考えを挙げておきます。 個人の自由を促進し人々が協力し合うこと、自分のためにみんなのために実践できること、それがソフトウェアに 関することなのであれば、フリーソフトウェアがよく似合います。 Debian プロジェクトはフリーソフトウェアを強く支持しています。 Happy Hacking! 2.9 参考資料 参考文献 [1] フリーとは何だろう? あるいはフリーソフトウェアとは何を意味するのか?, http://www.debian.org/intro/ free.ja.html, http://www.debian.org/intro/free.en.html [2] フリーソフトウェアの定義, http://www.gnu.org/philosophy/free-sw.ja.html, http://www.gnu.org/ philosophy/free-sw.html [3] Debian 社会契約 / Debian フリーソフトウェアガイドライン (DFSG), http://www.debian.org/social_ contract.ja.html, http://www.debian.org/social_contract.en.html [4] Debian – ラ イ セ ン ス 情 報, http://www.debian.org/legal/licenses/index.ja.html, http://www. debian.org/legal/licenses/index.en.html 5 [5] DFSG and Software License FAQ (Draft), http://people.debian.org/~bap/dfsg-faq.html [6] オープンソースの定義, http://opensource.jp/osd/osd-japanese.html, http://opensource.org/docs/ osd [7] Open Source Licenses, http://opensource.org/licenses/index.html [8] コ ピ ー レ フ トって 何?, http://www.gnu.org/copyleft/copyleft.ja.html, http://www.gnu.org/ copyleft/copyleft.html [9] さまざまなライセンスとそれらについての解説, http://www.gnu.org/licenses/license-list.ja.html, http://www.gnu.org/licenses/license-list.html [10] GNU GPL に関して良く聞かれる質問, http://www.gnu.org/licenses/gpl-faq.ja.html, http://www. gnu.org/licenses/gpl-faq.html [11] Debian に つ い て http://www.debian.org/intro/about.ja.html, http://www.debian.org/intro/ about.en.html 6 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 3 Squeeze の変更点をみんなで見てみ よう 倉敷 悟 3.1 Squeeze の情報源 主な情報源としては下記のものがあります。このうち、リリースノートの読み方を簡単に紹介しつつ、目立った変 更をざっくり眺めていこうと思います。 • Debian – ニュース – Debian 6.0 “Squeeze” released: http://www.debian.org/News/2011/20110205a • Debian GNU/Linux 6.0 (squeeze) リリースノート (32 ビット PC 用): http://www.debian.org/releases/ stable/i386/release-notes/index.ja.html • NewInSqueeze - Debian Wiki: http://wiki.debian.org/NewInSqueeze 3.2 Debian リリースノートの読み方 3.2.1 大まかな構造 さて、リリースノートは、構造はほぼ決まっていて、各リリースでの違いだけが反映されていくようになってい ます。 その章立ては次の通りです。これは、原文自体がこのような形で分割されているので、基本的には今後のリリース でも踏襲されると思います。 • 前置き • 問題点 • 最新情報 • 参照情報 • インストーラの変更点 • oldstable での事前準備 • アップグレード • 目録 まずは、「最新情報」をざっくり読んだあと、「問題点」にしっかり目を通すのが大切です。結局、squeeze で何が 変化してどうなったのか、という情報はここに集っているからです。 「インストーラの変更点」は、新規にインストールする人は一応見ておきましょう。といっても、最近のインストー ラは、わりと「見ればわかる」ようになっているので、インストールするだけなら読まなくても問題になることは少 ないと思います。ちなみに、今回からは、最新のインストーラが以前のバージョンもインストールできるようになっ たらしいです。最新のインストーラで woody とか sarge を入れたらどんな (目もあてられない) ことになるのか、興 味深いですね。 「アップグレード」と「oldstable での事前準備」は、インストーラを使わずに以前のリリースから更新する人はと にかく必読です。これは言わば、「既に踏まれた地雷」を考慮に入れたアップグレード作業の手順書です。従って、こ 7 こに書かれた内容にハマってしまうというのは、なんというか (政治的に正しくない言葉をお好みで) ということに なってしまいますので注意してください。 ちなみに、「なんだ用語集か」と思って見過ごしてしまいがちなのですが、「目録」のページには、パッケージ名か らの逆引きインデックスが含まれていたりしますので、「あのパッケージに何か (わざわざリリースノートで触れない といけないような) 変化があるかな」といった見方をすることもできたりします。一度くらいは見てみるといいかも 知れません。 3.2.2 どのように書かれるか さて、最初に書いた通り、リリースノートは、これまでの文章に随時継ぎ足したり削ったりして、秘伝のタレのよ うに作られていきます。 ここで、「前置き」の部分に着目してみましょう。そういった変更は、DDP (Debian Documentation Project) の メンバーが適宜行う他、主に BTS の release-notes に対するリクエストへの対応としてもなされます。あるパッケー ジのバグについてやりとりしている中で、「あ、これはリリースノートに書いとかないと」という流れになることも あります。 既に書いた「既に踏まれた地雷」はこういう形で集められたものですので、残念ながら網羅性があるわけではあり ません。皆さんも、何か新しい地雷を踏んじゃったなー、という時は、遠慮なく BTS へ報告してください (英語で)。 ここで注意が必要なのは、こういった BTS の動きもあって、「リリースノートはリリースされた後にも更新される 場合がある」ということです。今自分が読んでいるのが最新かどうか、ということにはちょっと注意しておくといい でしょう。http://svn.debian.org/viewsvn/ddp/manuals/trunk/release-otes/en/ を見て、各ファイルの最 終更新日をチェックするのがお手軽です。 翻訳が追いついていないこともあるので、その場合は頑張って英語で読んだ後、debian-doc あたりに原文更新を通 知しましょう。翻訳済みのパッチも歓迎されます。 3.2.3 ともあれ Squeeze になった後 リリースノートの「前置き」でも書かれていますが、基本的に、各パッケージ毎の些細な変更はわざわざリリース ノートに書かれたりしません。 普 段 使 い の パッケ ー ジ に つ い て は 、と り あ え ず 基 本 に 立 ち 帰って 、「/usr/share/doc/パッケ ー ジ 名 」に README.Debian や NEWS.Debian が追加されたり更新されたりしていないか、確認しておくようにしましょう。 おっかしーなー、想定と違う動き方をするなー、と思って散々ぐぐりまくったあげくに NEWS.Debian にちゃんと 書いてあった、というのはよくある話です。 3.3 システムのコア部分の変更 Squeeze になって Linux カーネルとシステム起動部分に大きな変更がありました。 Linux カーネルでは、カーネルにバイナリの形で含まれていた含まれていたファームウェアが分離され、non-free セクションに移動されました。これによって、Debian の main セクションにある linux カーネルイメージは完全に フリーになりました. 移動された non-free のファームウェアには AMD Radeon と Broadcom のファームウェアなど が入っており、NIC が使えない、インストール後に X が起動しないなどの影響が考えられます。 インストール中に non-free のファームウェアを読み込ませるには、http://cdimage.debian.org/cdimage/ unofficial/non-free/firmware/ からファームウェアをダウンロードし、あらかじめ USB メモリなどに展開して おき、インストーラの指示に従って読み込ませます。Debian インストール後に non-free のファームウェアをインス トールするには、apt-line の non-free セクションを有効にして、firmware-linux パッケージをインストールします。 (依存関係で firmware-linux-free と firmware-linux-non-free の二つがインストールされます。) システムの起動では、起動シーケンスが依存関係ベース (insserv) になり、デーモンが並列起動されるようになり ました。 8 デーモンの並列起動で問題が出た場合は、/etc/default/rcS に「CONCURRENCY=none」と設定すると無効に できます。(insserv は sysv-rc パッケージが依存しているので残念ながら外すことはできません。) 3.4 パッケージまわり “libs”、“network” などのパッケージセクションが分割された一方で、“embedded”、“haskell”、“video” などの 新しいセクションが追加されました。実際のところ、debian を単に使うだけなら、セクションは余り意識しなくても さほど困らないので、開発者向けの変更点と言えるかもしれません。 今まで backports.org で提供されていたバックポートされたパッケージが、backports.debian.org から提供される ようになりました。debian.org の公式サービスへと格上げされたため、これまでよりは敷居が下がって使いやすく なっっと思います。 volatile.debian.org で提供されていたパッケージが、stable-updates という形で提供されるように変更されました。 アンチウィルス系など、リリース後も継続してデータの更新が必要な種類のパッケージが volatile で提供されていま したが、パッケージ数も少なく、ほぼ機能していない状態でした。これが stable-updates となって状況が改善されれ ばいいですね。 いろいろと細かい変更のある APT まわりですが、まずは推奨 (Recommends) パッケージを全部自動的にインス トールされるようなっている、という点おおさえておきましょう。RedHat を思わせる勢いであれもこれも入ってく るので、ストイックにいきたい人は、-R オプションを活用してください。 また、apt-get と aptitude の位置付けがまた変更されています。コマンドラインでポンと投げる場合は apt-get を 使います。また、ディストリビューションのアップグレードにも、aptitude ではなく apt-get を使うことが推奨され ています。aptitude は引数なしで起動して、コンソール GUI で使うもの、ということになるようです。 3.5 ハードウェアまわり Squeeze のハードウェア周辺の対応を見ていきましょう。 対応アーキテクチャですが、一番目を引くのはテクノロジープレビューという形ですが、Linux カーネルではなく FreeBSD カーネルを使った、kfreebsd-amd64 と kfreebsd-i386 の追加でしょう。kFreeBSD については前回、杉本 さんの資料もご覧ください。 そのほかには、Lenny までサポートされていた HP PA-RISC (’hppa’)、Alpha (’alpha’)、ARM (’arm’) アー キテクチャが廃止になり、対応アーキテクチャは、32 ビット PC (’i386’)、64 ビット PC (’amd64’)、PowerPC (’powerpc’)、SPARC (’sparc’)、Intel Itanium (’ia64’)、ARM EABI (’armel’)、MIPS (’mips’ (ビッグエンディア ン)、’mipsel’ (リトルエンディアン))、S/390 (’s390’) の 9 つ +2 の 11 種類のサポートになりました。*1 X 関係のサポートを見ると、Intel, AMD, NVIDIA のメジャーなグラフィックチップにおいてカーネル内でグラ フィック設定を行う、カーネルモードセッティング (KMS) が有効化されています。 これらにより X の起動が早くなったり、サスペンド・レジュームで X が死ななくなるなど良い面もある反面、コン ソール画面の文字が出なくなったりするなどの影響もあります。 その場合は/etc/modprobe.d/(i915|radeon|nouveau)-kms.conf の設定を変更する必要があります。*2 細かいところでは X とコンソールのキーボード設定が統一化されました。 /etc/default/keyboard にキーボードの設定をしておくと、コンソールと X の設定は上書きされて同じ設定に なります。 lenny から基本的に xorg.conf は使わなくなったので影響は少ないと思いますが、xorg.conf を書いている人は注意 が必要です。 *1 *2 sh は wheezy? http://wiki.debian.org/KernelModesetting 9 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 4 Squeeze をみんなインストールした 結果を語る会 まえだ こうへい 事前課題では Squeeze になってうれしい点、変わった点を挙げてもらいましたが、実際にインストールしてみた結 果を語りましょう。 4.1 インストールした機器 メーカー 機種名 誰 HP MicroServer まえだ 4.2 インストールで困ったこと 困ったこと 解決したか? 解決方法 担当 プリンタの設定に少々悩んだ (詳細 解決? 解決方法を思い出して情報共有す キタハラ 忘れた) る。 4.3 改善した方が良いと思ったこと 改善した方良いと思ったこと Sid でも再現するか? あなたの宣言 担当 libvirt の nwfilter の設定によって、 未検証 /etc/libvirt/nwfilter にルールを追 まえだ 自分で設定している iptables のルー 加するか、その下をすべて削除して ルが上書きされる 自分で作っているスクリプトに集約 する。前者はルールの順番がよく分 からないので仕組みを理解する。 Klipper の挙動が変わり、中ボタン 「クリップボードのアクションを有 でのペースが面倒になった。 効にする」で解決するか確認する。 山本 しなければ改善案を考えて BTS。 心残りがあること そのまま Sid にある? すっきり解決する。 岩松 Debian Installer で LVM を一度設 Yes。シェル モ ー ド で lvre- メニューからも普通に削除できた方 まえだ 定すると削除できない。 move, vgremove, pvremove が良いんじゃね。 すれば削除できる。 10 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 5 Debian のドキュメントをみてみ よう かわだ てつたろう 5.1 はじめに Debian プロジェクトはユーザに向けたドキュメントを提供しています。ドキュメントパッケージを管理する doc-base のクライアントとともに Debian を使っていくうえで有用な Debian 固有のドキュメントをいくつか紹介し ます。 5.2 doc-base doc-base とは Debian システムにインストールされたドキュメントを管理するユーティリティとドキュメントのメ タデータのデータベースを提供するパッケージです。単なる man ページだけでなくオンラインドキュメントを提供 する Debian パッケージはインストール時に doc-base に登録し、アンインストール時に登録を解除することが推奨 されています。*3 doc-base に登録されたメタデータを利用するクライアントとして dwww, dhelp, doc-central など が提供されています。これらクライアントを利用すればドキュメントの検索、閲覧が容易に行えます。 5.3 doc-base クライアント doc-base クライアントをいくつか紹介します。 5.3.1 dwww dwww はウェブベースのドキュメントリーダです。 doc-base に登録されたドキュメント、man、info を参照することができます。ドキュメントはインデックス化され ており検索することができます。 インストール apt を使用してインストールするだけですが info を表示する info2www の設定が少し必要です。 info2www のシンボリックリンクを作成して info2www をドキュメントルート下 (ここでは /var/www) に公開さ せます。info2www を公開させなくても動作しますが info を表示する場合に画像などが表示されません。*4 またインストール直後はインデックスの作成に少し時間がかかりますのでしばらく待ってから dwww を使用して ください。 *3 *4 Debian Policy Manual: 9.10 Registering Documents using doc-base /usr/share/doc/info2www/README.Debian 参照 11 $ sudo aptitude install dwww $ sudo ln -s /var/lib/info2www /var/www/info2www 使い方 WEB ブラウザで http://localhost/dwww にアクセスするかコマンドラインで dwww と実行してください。ブ ラウザに dwww のホームが表示されます。後は WEB ブラウジングするようにリンクを辿るか入力フォームにキー ワードを入力して検索を行ない目的のドキュメントを探してください。残念ながら日本語での検索はできません。 検索はコマンドラインから行なうこともできます。例えば debian という検索をコマンドラインから行ないたい場 合は以下のように実行すれば WEB ブラウザに debian と検索した結果が表示されます。 $ dwww debian 5.3.2 dhelp dhelp はウェブベースのドキュメントリーダです。 WEB ブラウザから doc-base に登録されたドキュメントを参照することができます。ドキュメントはインデック ス化されており検索することができます。 インストール apt を使用してインストールするだけです。dhelp は WEB サーバを必要としていませんのでここで WEB サーバ はインストールされません。インストール直後はインデックスの作成に少し時間がかかりますのでしばらく待ってか ら dhelp を使用してください。 $ sudo aptitude install dhelp 使い方 WEB ブラウザで file://localhost/usr/share/doc/HTML/index.html にアクセスするかコマンドラインで dhelp と実行してください。ブラウザに dhelp のホームが表示されます。後は WEB ブラウジングするようにリンク を辿ってドキュメントを探してください。この状態では info pages, man pages の参照、ブラウザからの検索を行な うことはできません。 検索はコマンドラインから行なうことになります。例えば debian という検索をコマンドラインから行ないたい場 合は以下のように実行すれば WEB ブラウザに debian と検索した結果が表示されます。残念ながら日本語での検索 はできません。 $ dhelp debian WEB サーバの導入 WEB サーバを必要としないのは一つのメリットですが制限もあり不便ですので WEB サーバをインストールして WEB ブラウザからの検索、info と man の参照ができるようにします。dhelp パッケージが Suggests しているパッ ケージを参考に apache2 と info2www, man2html を追加インストールします。先と同様に info2www の設定を少し 行ないます。 $ sudo aptitude install apache2 info2www man2html $ sudo ln -s /var/lib/info2www /var/www/info2www 12 これで WEB サーバを経由で dhelp を使用できるようになりました。dhelp コマンドの結果は WEB サーバ経由 で表示されるようになりますが WEB ブラウザに直接アドレスを入力する場合はアドレスを http://localhost/ doc/HTML/index.html に変更してください。 5.3.3 doc-central doc-central はウェブベースのシンプルなドキュメントリーダです。 WEB ブラウザから doc-base に登録されたドキュメントを参照することができます。doc-central はドキュメント をインデックス化しませんが doc-base のメタデータに登録されたドキュメント名、作者、概要を対象として検索す ることができます。man は参照することができません。 インストール apt を使用してインストールするだけですが info2www の設定が少し必要です。 $ sudo aptitude install doc-central $ sudo ln -s /var/lib/info2www /var/www/info2www 使い方 WEB ブラウザで http://localhost/dc/ にアクセスするかコマンドラインで doccentral と実行してください。 doc-central ではなく doccentral です。ブラウザに Doc-Central のホームが表示されます。後は WEB ブラウジン グするようにリンクを辿るか入力フォーム*5 にキーワードを入力して検索を行ない目的のドキュメントを探してくだ さい。 検索はコマンドラインから行なうこともできます。例えば debian という検索をコマンドラインから行ないたい場 合は以下のように実行すれば WEB ブラウザに debian と検索した結果が表示されます。 $ doccentral debian 5.3.4 その他に Yelp Yelp は Gnome のヘルプブラウザです。 Yelp からは man と info そして Gnome のヘルプが参照できますが各パッケージのドキュメントは参照できま せん。 khelpcenter khelpcenter4 は KDE のヘルプセンタです。 khelpcenter4 からは man と KDE のヘルプが参照できますが info や各パッケージのドキュメントは参照できま せん。 5.4 The Debian Documention Project のドキュメント doc-base クライアントが使えるようになったところで、パッケージとして提供されている The Debian Documention Project (DDP) のドキュメントをいくつかざっとみていきます。 *5 左側フレームの最下部にあります 13 5.4.1 doc-debian Debian の基礎となる Debian 社会契約や Debian フリーソフトウェアガイドラインといった Debian プロジェク トの基礎となる文書群です。 5.4.2 installation-guide インストールガイドです。 squeeze では 12 種類のアーキテクチャ毎にパッケージが用意されています。*6 i386 アーキテクチャ用だとパッケー ジ名は installation-guide-i386 になります。 初めて Debian をインストールする場合に参照することになるでしょう。CD-ROM/DVD-ROM や USB メモリ といったメディアからのインストール以外にも debootstrap やネットブートを使用したインストール方法、preseed を利用したインストールの自動化についても説明されています。ちょっと違ったインストールをする場合にも参考に なることが記載されています。 手早くインストールの流れを確認するだけなら「付録 A. インストール Howto」を参照してください。もしもの場 合に供えて「5.4. インストールプロセスのトラブルシューティング」も見ておくことをおすすめします。 5.4.3 debian-reference Debian システムの広範な概論です。 日本語訳は debian-reference-ja として別パッケージで提供されています。 内容は大変多岐に渡りコンソールの基礎から Debian でのパッケージ管理、ネットワーク設定、プログラミングま で扱っています。DDP の中でも最も充実したユーザマニュアルです。 Unix ライクなシステムを使った経験があまり無いのであればぜひ「1. GNU/Linux チュートリアル」を参照して ください。Debian のパッケージについては「2. Debian パッケージ管理」で詳細に説明されています。unstable を 使いはじめようという時には「2.6. 壊れたシステムからの復元」が手助けになるかもしれません。その他 Debian を 使っている各局面にあわせて項目を参照してみるとよいでしょう。 5.4.4 maint-guide 新たにパッケージメンテナになろうという人向けの解説です。 「Debian 新メンテナガイド」、 「Debian メンテナ入門」、 「ニューメンテナガイド」、 「新規メンテナのためのガイド」 などと呼ばれています。日本語訳は maint-guide-ja として別パッケージで提供されています。 gentoo パッケージを例にとってパッケージの作成、アップロード、更新手順が説明されています。内容の大半が パッケージ作成に割かれて詳しく説明されていますのでパッケージメンテナになろうという人だけでなく、Debian のパッケージを作ってみようと思う方も是非参照してください。 5.4.5 developers-reference Debian 開発者向けのリファレンスです。 日本語訳は developers-reference-ja として提供されていますが翻訳途中です。 新規メンテナプロセスから始まり Debian Developer が使用できるリソース、パッケージの扱い方が説明されてい ます。特に技術的な事柄以外のパッケージ化についてありとあらゆる情報が記載されています。Debian Developer の 活動の一部を垣間見られるドキュメントです。 5.4.6 debian-policy Debian ポリシーマニュアルとポリシーを補足する文書群です。 *6 squeeze では hppa のサポートが外れ 11 種類のアーキテクチャがサポート対象ですが installation-guide-hppa パッケージが存在しま す。 14 Debian ポリシーマニュアルには Debian パッケージの内部構造 (アーカイブ構成、パッケージの各書式など) やオ ペレーティングシステムとして必要な設計部 (ファイルシステムの階層構造、システムや各種プログラムの設定など) について記載されています。日々議論され更新されています。 日本語訳されたパッケージはありませんが Debian JP Project で Debian ポリシーマニュアル (Version 3.8.3.0) を翻訳したものが WEB で公開されています。*7 過去に東京エリア Debian 勉強会でとりあげられていますのでその 資料も参考にしてみてください。*8 5.4.7 その他 debian-faq Debian に関する FAQ がまとめられています。 harden-doc Debian のセキュリティに関することをまとめたマニュアルです。システムのセキュリティに関することからプロジェ クトのセキュリティ取り組みについても記載されています。現在、日本語への翻訳が進められています。 debian-refcard いわゆるリファレンスカードです。一枚の紙 (A4 裏表) に重要なコマンドの一覧や参考となる情報をまとめてあり ます。 5.5 最後に ドキュメントは随時更新されており最新ドキュメントは Debian のユーザ文書*9 にまとめられていますので確認し てみてください。ここにはパッケージになっていないドキュメント (例えばリリースノートなど) もあります。ドキュ メントソースは Subversion で管理、公開されておりどなたでも確認することができます。興味があればこちらも覗 いてみてください。*10 ドキュメントに間違いを見つけた場合は BTS するか、日本語訳に関することであれば [email protected] に報告するとよいでしょう。 また、The Debian Documention Project が提供するドキュメント以外にもソフトウェアのドキュメントパッケー ジがたくさんありますのでパッケージの “doc” セクションも覗いてみてください。 5.6 参考資料 • Debian ユーザ文書: http://www.debian.org/doc/ • doc-base: http://wiki.debian.org/doc-base/ *7 *8 *9 *10 http://www.debian.or.jp/community/devel/debian-policy-ja/policy.ja.html/ 第 12, 13, 15 回東京エリア Debian 勉強会事前資料参照 http://www.debian.org/doc/ http://www.debian.org/doc/cvs.ja.html 15 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 6 ハッカーに一歩近づく Tips:vi 編 山下 康成 6.1 はじめに vi は、初心者は初心者なりに使え、使い込めば使い込むほど味の出るエディタだということは皆さんご存じの通り かと思います。皆さんも当たり前のように vi を使ってらっしゃると思いますが、さて、ハッカーのように vi を使い こなせてますでしょうか?ハッカーに近づくために、vi 使いこなしのちょっとした Tips を紹介します。 6.2 こんな経験ありませんか? k ↑ h ← → l ↓ j w 一語右へカーソルを移動 G ファイルの末尾へカーソルを移動 x 1 文字消す dd 1 行消す etc …… こんな教え方するから、バラバラなコマンドを覚えないとならず、なかなか「使い込めば味の出る」ところまで行 けないのでしょう。今日はもうちょっと体系立てて説明してみます 6.3 コマンドを整理してみる 6.3.1 繰り返し回数−コマンド 型 回数に続いてコマンドを入力すると、指定した回数繰り返されるコマンド。5yy として 5 行コピーとかは良く使わ れる。 例: 2l 2 文字分右にカーソルを移動する 2h 2 文字分右にカーソルを移動する 2x 2 文字消す 2X カーソルの左の 2 文字を消す 16 2r 2 文字を次に入力する文字と置き換える 2˜ 2 文字を英大文字 <- >小文字を切り替える 3w 3 ワード右にカーソルを移動する 3W 空白区切りで 3 ワード右にカーソルを移動する 3b 3 ワード左にカーソルを移動する 3B 空白区切りで 3 ワード左にカーソルを移動する 4yy 4 行コピーする 4dd 4 行削除する 5p 5 回ペーストする 5P カーソルの前に 5 回ペーストする 5i <string >[ESC ] カーソルの左に <string >を 5 回入力する 5I <string >[ESC ] 行頭に <string >を 5 回入力する 5a <string >[ESC ] カーソルの右に <string >を 5 回入力する 5A <string >[ESC ] 行末に <string >を 5 回入力する 5H 画面上から 5 行目にカーソルを移動する 5L 画面下から 5 行目にカーソルを移動する 6.3.2 事前課題 以下、それぞれどのようにキー操作をすれば良いか、最も少ないキー操作を考えてください。 • 現在行から最終行(の行頭)にカーソルを移動する→ G • 現在行から最終行までを消去する→ dG • 現在行から最終行までをコピー (yank) する→ yG • 現在行から最終行までを “x” 1 文字で置き換える→ cGx <ESC > 「カーソル移動」というコマンドが省略されていると考えれば、[コマンド]G という形になっていることに気が付 いていただいただろうか? 6.3.3 コマンド−目的地 型 コマンド: 省略 「目的地」にカーソル移動「カーソル移動」は「“目的地” までカーソルを移動する」ということ d 「目的地」までを削除 y 「目的地」までをコピー c 「目的地」までを変更 例: d3l 3 文字左まで削除 c3w 3 ワードを変更 d0 行頭までを削除 dˆ 空白をのぞく行頭までを削除 d$ 行末までを削除 (= D) y5j 5 行下までをコピー d% 対応するカッコまでを削除 dgg 先頭行までを削除 d/<string > “string” があるところまでを削除 17 6.4 そのほかの便利な機能 6.4.1 名前つきバッファ 例: ”ayy バッファ a に 1 行コピー ”by$ バッファ b に行末までをコピー ”ap バッファ a をペースト ”bP バッファ b をカーソルの前にペースト 6.4.2 コマンドの実行結果を追加 :r ! ls ls の実行結果をカーソル位置に挿入 6.5 最後に vi のコマンドは、バラバラのように見えて • 繰り返し回数−コマンド 型 • コマンド−目的地 型 と整理してみると、結構直行しているということがわかっていただけたかと思います。 皆さんの知ってるコマンドも、この型にあてはめてみると知らなかった用途が見えてきたのではないでしょうか。 vi を使いこなして、ハッカーに一歩近づこう! 18 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 7 Debian GNU/kFreeBSD で便利に暮 らすための Tips 杉本 典充 7.1 Debian GNU/kFreeBSD について Debian GNU/kFreeBSD とは, Debian Project で開発しているオペレーティングシステムのひとつです. Squeeze にて技術プレビュー版としてリリースされることになっています. *11 7.1.1 Debian GNU/kFreeBSD の現状 Debian GNU/kFreeBSD は現在次のような状況です. • カーネルは FreeBSD 8.1 ベースのものに一本化された. (7.3 カーネルは廃止).*12 • まだ Linux バイナリ互換機能は動かない模様. (linux.ko のロード自体に失敗する).*13 7.2 ZFS 環境下でリアルタイム系アプリケーションを使用する Tips 7.2.1 現象 私の PC 環境では, sftp を実行してサーバから 1GB のファイルをダウンロードすると, audacious で再生中の MP3 ファイルが音飛びします. ディスクのアクセス LED は「消灯, 数秒間連続点灯, 消灯」を繰り返すようなディ スクアクセスをしており, 音飛びは HDD LED が点灯中に発生します. なお, PC の環境は以下です. • ノート PC の VAIO TZ. 2.5inch HDD (SATA150 接続) の 250GB. • / は UFS, /home は ZFS としている. • ZFS の設定で, 圧縮はしない (compression=off) 設定にしている. • 再生する MP3 ファイルと sftp でダウンロードする 1GB のファイルは双方 ZFS 領域に読み書きする. 7.2.2 原因の推定 ディスクのアクセス LED が点灯しているときに MP3 ファイルの再生が音飛びするため, 1GB のファイルを書き 込み中に MP3 ファイルの読み込みが行えなかったためと推測します. そのため, 大きいファイルを書き込む場合はディスクへの連続書き込み時間を短くするように ZFS のパラメータを *11 *12 *13 http://www.debian.org/ports/kfreebsd-gnu/ 2011 年 6 月末現在、unstable では 8.2 系カーネル、experimental では 9.0 系カーネルをベースに開発が行われています. 2011 年 6 月末現在、まだ動作していません. 19 調整すれば現象は解決すると考えます. ZFS のパラメータ設定については FreeBSD を使う人たちで研究されており, その結果が公開されています. *14 7.2.3 ZFS のパラメータを調整する ZFS のパラメータを表示するには “sysctl” コマンドを使用します. 今回調整するパラメータは vfs.zfs.arc_max のため, 現在の値を確認します. $ sysctl -a | grep arc_max vfs.zfs.arc_max: 428705280 デフォルト値は約 400MB に設定されています. FreeBSD における ZFS のパラメータ設定は/boot/loader.conf に記述するのですが, Debian GNU/kFeeeBSD では/boot/loader.conf に記述しても効きません. また, カーネルの起動後に sysctl コマンドを直接実行してもす でに ZFS subsystem が起動しているため変更できない状況です. そのため, grub の起動パラメータとして設定する方法をとりました. $ sudo vim /etc/grub.d/10_kfreebsd # (省略) # 元から設定しているパラメータ set kFreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${kfreebsd_device} set kFreeBSD.vfs.root.mountfrom.options=rw # 今回新しい設定値を追加します. set kFreeBSD.vfs.zfs.arc_max="100M" # (省略) $ sudo update-grub $ sudo reboot 7.2.4 確認 $ sysctl -a | grep arc_max vfs.zfs.arc_max: 104857600 設定した通り, 100MB になりました. これでテストしてみると音飛びがしなくなりました. このパラメータ値はハードウェア環境, ディスク負荷で個々に違ってくるため, 皆さんの使い方に合わせてチューニ ングしてみてください. 7.3 USB メモリのマウントに関する Tips 7.3.1 まず普通にやってみる 私の Debian GNU/kFreeBSD 環境は ja JP.UTF-8 の locale を使用しています. FAT32 でフォーマットしている USB メモリに日本語ファイル名をもつファイルがある場合は mount 時に文字コードの変換が必要になります. その ため, 文字コード変換のオプションを指定してマウントを試みます. すると libiconv.so がないといわれ, エラーになります. $ sudo mount_msdosfs -L ja_JP.UTF-8 -D CP932 /dev/da0 /mnt/usb mount_msdosfs: Unable to load iconv library: libiconv.so: cannot open shared object file: No such file or directory : No such file or directory mount_msdosfs: msdosfs_iconv: No such file or directory 7.3.2 libiconv のビルド しかし Debian には libiconv.so というライブラリファイルは存在しません. そのため, GNU のサイトから tarball をダウンロードして build することにします. *14 http://wiki.freebsd.org/ZFSTuningGuide 20 $ cd $ mkdir tmp $ wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.1.tar.gz $ tar zxvf libiconv-1.13.1.tar.gz $ cd libiconv-1.13.1 $ ./configure $ make $ sudo make install $ ls /usr/local/lib charset.alias libcharset.so libiconv.la libiconv.so.2.5.0 libcharset.a libcharset.so.1 libiconv.so python2.6 libcharset.la libcharset.so.1.0.0 libiconv.so.2 site_ruby 再度 mount を試みます. コマンド自体はエラーになりませんが, /mnt/usb の中を ls してみると, 日本語部分が? で表示されています. 文字コードの変換に失敗したようです. $ sudo mount_msdosfs -L ja_JP.UTF-8 -D CP932 /dev/da0 /mnt/usb 7.3.3 文字コード変換の失敗原因 FreeBSD 本家のカーネルでも mount msdosfs で UTF-8 へ文字コードを変換する処理は動作しないようです. *15 そのため, 考えられる方法は以下の 3 つありそうです. • USB メモリに日本語ファイル名を使わない。(他人からもらったデータの場合は都合が悪い場合もある。) • locale の設定を ja JP.eucJP で運用する。(eucJP への変換は動作するため) • 一時的に locale を ja JP.eucJP に設定して USB メモリから HDD にコピーし、convmv で UTF-8 へファイ ル名を変換する。その後、locale を ja JP.UTF-8 に戻す。 私の環境ではすでに UTF-8 の文字コード環境を使っている都合上, convmv を使った方法を紹介します. まずは, ja JP.eucJP 環境で起動します. $ vim .xinitrc # UTF-8 の設定があったらコメントアウトして、 eucJP 設定を追加する # export LANGUAGE=’ja_JP.UTF-8’ # export LC_ALL=’ja_JP.UTF-8’ # export LANG=’ja_JP.UTF-8’ export LANGUAGE=’ja_JP.eucJP’ export LC_ALL=’ja_JP.eucJP’ export LANG=’ja_JP.eucJP’ $ startx ファイルを一度 HDD にコピーし, コピーしたファイル名の文字コードを変換します. $ $ $ $ $ sudo mount_msdosfs -L ja_JP.eucJP -D CP932 /dev/da0 /mnt/usb mkdir ~/usbtmp cd ~/usbtmp cp -r /mnt/usb/* ./ convmv -r -f eucjp -t utf8 * --notest locale を元に戻します. $ vim .xinitrc export LANGUAGE=’ja_JP.UTF-8’ export LC_ALL=’ja_JP.UTF-8’ export LANG=’ja_JP.UTF-8’ # export LANGUAGE=’ja_JP.eucJP’ # export LC_ALL=’ja_JP.eucJP’ # export LANG=’ja_JP.eucJP’ $ startx 一手間必要ですが, locale を ja JP.UTF-8 で使う場合はこのような回避策を行うことで対応することができます. *15 日本語の UTF-8 へファイル名を変換して mount できるようにするパッチは FreeBSD を使う有志によって作成されているようですが, GENERIC カーネルに取り込まれていないようです. 21 7.4 今後の課題 日常生活で使えると便利な以下の事項については, 現在調査中です. • iceweasel がよくフリーズする. • Flash はやはり鬼門で安定して動作できていない. *16 • VAIO TZ の液晶の明るさ変更 (Fn キーから音量は何もしなくても変更できているが…).*17 • 無線 LAN (iwn0 として内蔵無線 LAN カードの認識はできているがエラーになる) • IS03 を使ってテザリングする. (まずはドライバをなんとかしないと) 7.5 終わりに Debian GNU/kFreeBSD はこれから更に完成度を高めていけるオペレーティングシステムのため, オペレーティン グシステムの開発に関わりたい人には打ってつけのプロジェクトです. 今後も Debian GNU/kFreeBSD を使い, デ バッグしながらいろいろ勉強していきたいです. *16 *17 2011 年 6 月末現在、iceweasel + gnash の組み合わせで Flash の再生ができています. その後の調査でカーネルのパッケージビルド時に acpi sony.ko がビルドされていないことが判明しました. カーネルのパッケージを自前で ビルドし、その後に手操作で acpi sony.ko のみをビルドすることで液晶の明るさを変更できるようになっています. 22 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 8 Debian Games Team 体験記 野島 貴英 ひょんな事から Debian Games Team Project に参加してしまったドタバタの体験記となります。パッケージ初心 者の初心者視点の右往左往を楽しんでいただければ幸いです。 8.1 あれ?Xmris が無い! ? 学生の頃、初めて触ったライセンス Free の UNIX(linux。当時は Slackware)で遊びまくっていたゲームに、 Xmris というのがあります。Xmris は、当時、計算機科学の追求の為に導入されていたはずのあらゆる商用 UNIX マシンに 何故か必ず入っていたゲーム でした。自分の学校とは全く無関係の施設の UNIX マシンにすら入っていた ゲームだったので、思わず MIT X の配布物に梱包されているんだとずっと誤解していたりしました。 図1 Xmirs の画面 で、昔を懐しんでこの Xmris がやりたくなり、早速 aptitude search xmris してみたところ、 ごはっ、Xmris がどこにも無いっ! ? でした。で、「もしや?」と思い、方々捜し回ったところ、Debian Wiki の Games/Suggested のページ (http: //wiki.debian.org/Games/Suggested) のパッケージにして欲しいリストに Xmirs の名前が燦然と輝いているで 23 はありませんか。 8.2 Debian Games Team へ Xmris がとにかくやりたかった為、完璧にパッケージ作成初心者ではありましたが、Debian Policy 文章、apt-get source コマンド、lintian コマンドのお陰で苦労なくパッケージを作成できました。 が、パッケージは作ったものの、当時、自分の周りには DD は全くおらず、 「どうやったらパッケージを取り込んで もらえるのだろう?」と言う事で悩みまくることになりました。で、辿り着いたのが Debian Game Team でした。 右も左も分からない状況で Debian Games Team の ML([email protected] 以下 ML) でおそるおそるやり取りしたところ以下の事がわかりました。 参加資格 実際に Game のパッケージをつくろうとしている人はだれでも (初心者ならなおさら入って他の人のパッケー ジの作り方とやりとりを見てくれと言われた) 参加方法 こんな感じで進めます。 Step 1. まず ML に参加したい意志表明を流す(例:これこれのパッケージを作りたいので入れて欲しい等) Step 2. 次に alioth.debian.org(以下 alioth)にアカウントを作り(http://alioth.debian.org/account/ register.php)、alioth 上の Debian Games Team のページ (http://alioth.debian.org/projects/ pkg-games/) にある “Request to join” のリンクから参加のリクエストを送る。 Step 3. 後日 Debian Games Team の管理者から Wellcome レターが届き、alioth 上の Debian Games Team のページの Project Members の欄に名前が登録される。 実際の開発 マ ニュア ル (http://wiki.debian.org/Games/VCS,http://wiki.debian.org/Games/VCS/git) を 見 て VCS/ML/IRC を活用しながらパッケージ開発を進めることになります。(IRC は、irc.debian.org サーバー上 の#debian-games チャンネル) Step 1. マニュアルに従い作ろうとしているパッケージのリポジトリを堀る。(勝手にバンバン掘って良いと の事です) Step 2. git コマンドを使ってどんどんパッケージの修正をアップロードしていく。 Step 3. パッケージが完成したら、mentor.debian.net にアップロードして、mentor を募る。うまく mentor がつけば、Debian のパッケージリリースのプロセスにのるハズ。 8.3 私見 以下に Debian Game Team に関する私見をば。 • ゲームを debian パッケージにしたい人が情報交換をする為に単に集まる寄合い場所のような位置づけなので、 Debian Game Team として、ゲームのパッケージを作成する以外の明確なビジョンとかルールがあるわけで はない。その為、 Debian Game Team のエリアに自分の git リポジトリを掘るときに「こうしていいか?あ あしていいか?」といちいち許可を求めると、ウザがられるのは驚いた(最後はあなたの好きにしてくれ、本 当にまずかったら指摘を受けるからその時に覚えてくれといわれてしまった。まあ、聞き方の問題だったのか もしれない...) • きっと Debian Game Team の関係者と面識が在るといろいろやりやすいと思う。 • Debian Game Team 以外でも身の回りに相談できる DD がいると大変違う(Debian で常識、Debian Game Team で常識をうまく切り分けられる) • 規模大き目のゲームをパッケージにまとめる際、付属しているバイナリデータ群に別のライセンスが適用/良 24 くわからないライセンスが適用されていることがあり、こちらの扱いで頭を抱える事がある。 (キャラクタの画 像、背景の画像、ゲーム内部で使われているフォント、サウンド etc...) • 手のかかる問題の解決/ちょっと揉めるリスクのある問題の解決(ライセンス問題、以前のパッケージメンテ ナ/アップストリームに結局連絡取れない、upload に関してスポンサーがつかない等)については、消極的。 結局、こちらはパッケージメンテしようとする側にて解決が求められる。 • ML に流れるやりとりよりも、IRC でのやり取りの方が多い印象。また、話も早い事が多い。ML で回答が得 られなくてもがっかりせず、その場合は IRC へ突撃をお勧め。 • 空気を読むと package を作成する方法、debian policy などは基礎知識としてある事が前提。 • チームに所属している人の生活があふれるやり取りが IRC で日常的に行われているのは新鮮だった。例:今、 「会社でたよー。ちょっとまってねー」→ 「はい家についたから繋いだよー。∼の件はねー」と会話が続く。日 常生活の一部として、Contribution 活動が組み込まれてしまっているのは自分にとっては感動ものでした。 25 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 9 Kinect を Debian で使ってみた 山田 泰資 9.1 Kinectって何? Kinect は Microsoft が 2010/11 に XBox360 の新しい操作デバイスとして発売したゲームデバイスで、強力な画像 認識機能を持ち、一切コントローラなどを手にしないゲームプレイを実現します。 ハードウェアとしての最大の特徴は、画像認識と言っても単なるカメラではなく、深度センサを搭載していること です。この種の深度センサ付カメラは従来もあったのですが、Kinect は大量生産されることもあって価格が 1 万 4 千 円前後と従来と比べてまさに桁違いの安さで、このため PC などの周辺機器として流用できないかと発売前から高い 注目を集めました。 9.2 発売、そして Kinect ハックへ そして発売されると普通に USB 接続ができることが判明(単品販売品のみ。XBox360 同梱版はケーブルを加工す る必要あり)し、すかさず画像・深度データのキャプチャ方法が解析されます。こうしてまず生まれたのが libfreenect です。libfreenect は急速に開発が進み、 1. カメラ(通常、深度、赤外線)画像の取得 2. カメラのチルト制御 3. 加速度センサの読み出し 4. 筐体 LED の制御 とサウンド関係以外はほぼ制御できるようになり、各種言語へのラッパーが作られたり OpenCV などの既成の画像 認識ライブラリと組み合わせてデモが作成されるなど、あっというまに普及が進みました。ここまでが発売後1ヶ月 程の話になります。 しかし、libfreenect だけでは限界がありました。XBox360 では kinect を使ったゼスチャ認識などの高度な機能を 持ったアプリケーション(ゲーム)を作成できる環境が用意されているのですが、libfreenect はあくまでハードウェ アにアクセスするまでなので、その部分が欠けていたのです。 実は前評判では「本体側の負荷を下げるため、Kinect 側でジェスチャ認識などの高水準認識も分担する能力があ る」という話もあったのですが、最終的には深度センサまでがハードウェアで、残りは XBox360 向けのソフトウェ アライブラリで実現する形となっていたのでした。 しかし、ここで新展開が起こります。Kinect の深度センサと上記ライブラリの原型提供を行った PrimeSense 社 から、 1. Linux, Windows 用の Kinect 搭載センサ用ドライバを OSS として公開する 2. ゼスチャ認識機能を備えた OpenNI フレームワークを OSS として公開する 26 3. 骨格認識および高度なジェスチャ認識を行う NITE ライブラリを無償提供する*18 という発表が行われ、純正の XBox360 開発環境と遜色がなくなり、人気がさらに高まりました。 これを生かして年末にかけては 3D モデリングツール(MikuMikuDance)にモーションキャプチャエンジンとし て組み込んだり、年明けには AR ウルトラセブン(画面中の自分の姿にウルトラセブンのコスプレをオーバレイし、 ジェスチャにあわせて様々な必殺技を繰り出すことができる)が登場するなど、日本では現在進行形で爆発的な盛り 上がりを見せています。 ここでは OpenNI および NITE の利用方法を紹介しつつ、それを元に Debian 勉強会のプレゼンテーションをジェ スチャで行う支援ツールの作成までを紹介します。 9.3 OpenNI と NITE の導入 まずはインストールです。 1. 独自に拡張が始まっている OpenNI とドライバ (SensorKinect) は github から 2. NITE はバイナリのため PrimeSense 社サイト (http://www.openni.org/) から それぞれ入手します。 現段階ではバージョンの組み合わせによっては動作しないことがあり、ここでは以下の組み合わせで導入します: 1. OpenNI (stable) / https://github.com/OpenNI/OpenNI.git 2. SensorKinect (avin2 version) / https://github.com/avin2/SensorKinect.git 3. NITE-Bin-Ubuntu-x64-1.3.0.17.tar.bz2 いくつかのパッケージを入れるなどビルド環境を整えておく必要はあります*19 が、後は付属のドキュメントの通り に進めればトラブルなく導入できました。 まずは OpenNI 本体をインストールします: $ git-clone https://github.com/OpenNI/OpenNI.git $ cd OpenNI/Platform/Linux-x86/CreateRedist $ ./RedistMaker # ビルドおよびインストール用バイナリセットを作ります ... $ cd ../Redist $ pwd /d/src/openni/OpenNI/Platform/Linux-x86/Redist $ sudo ./install.sh copying shared libraries...OK copying executables...OK copying include files...OK creating database directory...OK registering module ’libnimMockNodes.so’...OK registering module ’libnimCodecs.so’...OK registering module ’libnimRecorder.so’...OK *** DONE *** $ 次にドライバ(といっても、Linux 版のものは単なる共有ライブラリです) : *18 *19 OSS ではなく、無償利用のためのライセンスコードが公開された apt-get install gcc python2.6 libusb-1.0-0-dev freeglut3-dev doxygen graphviz あたりで整うかと思います 27 $ git-clone https://github.com/avin2/SensorKinect.git $ cd SensorKinect/Platform/Linux-x86/CreateRedist $ ./RedistMaker # ビルドおよびインストール用バイナリセットを作ります ... $ cd ../Redist $ pwd /d/src/openni/SensorKinect/Platform/Linux-x86/Redist $ sudo ./install.sh creating config dir /usr/etc/primesense...OK copying shared libraries...OK copying executables...OK registering module ’libXnDeviceSensorV2.so’ with OpenNI...OK registering module ’libXnDeviceFile.so’ with OpenNI...OK copying server config file...OK setting uid of server...OK creating server logs dir...OK installing usb rules...OK *** DONE *** $ そして最後に NITE のインストールです: $ tar xf NITE-Bin-Ubuntu-x86-1.3.0.17.tar.bz2 -C /d/src/openni/ $ cd Nite-1.3.0.17 $ sudo ./install.bash -l=0KOIk2JeIBYClPWVnMoRKn5cdY4= ... バイナリを/usr/lib 等にコピーした後、サンプルコードをビルドする... $ 最後の NITE の導入で指定した「0KOIk2JeIBYClPWVnMoRKn5cdY4=」が無料利用のための公開ライセンス キーになります。 これらのインストールが終わると 1. /usr/lib に libnim*.so, libXn*.so, libXnV*.so 2. /usr/include/ni,nite に各種ヘッダファイル 3. /usr/bin に niReg, niLicense コマンド(モジュールやライセンスの管理用) 4. /var/lib/ni にモジュールやライセンスの管理用 XML ファイル 5. /usr/etc/primesense に OpenNI やモジュールの設定・データファイル という構成になります。/usr/etc/primesense は LFS 的におかしな位置のため、/var/lib/ni/modules.xml から参照 しているパス設定を変更の上、/etc に移動させるとよいかもしれません。*20 あと、サンプルコードを動かせるよう一部ファイルを修正しておきましょう。NITE を展開した Nite-1.3.0.17/Data/ 下の XML ファイルを以下の内容にします。ライセンスキーの書き込みと、キャプチャ設定の修正・追加になります。 Sample-Scene.xml の内容: <OpenNI> <Licenses> <License vendor="PrimeSense" key="0KOIk2JeIBYClPWVnMoRKn5cdY4="/> </Licenses> <Log writeToConsole="true" writeToFile="false"> <!-- 0 - Verbose, 1 - Info, 2 - Warning, 3 - Error (default) --> <LogLevel value="3"/> <Masks> <Mask name="ALL" on="false"/> </Masks> <Dumps> </Dumps> </Log> <ProductionNodes> <Node type="Depth"> <Configuration> <MapOutputMode xRes="640" yRes="480" FPS="30"/> <Mirror on="true"/> </Configuration> </Node> <Node type="Scene" /> </ProductionNodes> </OpenNI> Sample-Tracking.xml の内容: *20 OpenNI のパッケージを作成予定ですが、このあたりは検証後直す予定 28 <OpenNI> <Licenses> <License vendor="PrimeSense" key="0KOIk2JeIBYClPWVnMoRKn5cdY4="/> </Licenses> <Log writeToConsole="false" writeToFile="false"> <!-- 0 - Verbose, 1 - Info, 2 - Warning, 3 - Error (default) --> <LogLevel value="3"/> <Masks> <Mask name="ALL" on="true"/> </Masks> <Dumps> </Dumps> </Log> <ProductionNodes> <Node type="Depth" name="Depth1"> <Configuration> <MapOutputMode xRes="640" yRes="480" FPS="30"/> <Mirror on="true"/> </Configuration> </Node> <Node type="Gesture" /> <Node type="Hands" /> </ProductionNodes> </OpenNI> Sample-User.xml の内容: <OpenNI> <Licenses> <License vendor="PrimeSense" key="0KOIk2JeIBYClPWVnMoRKn5cdY4="/> </Licenses> <Log writeToConsole="true" writeToFile="false"> <!-- 0 - Verbose, 1 - Info, 2 - Warning, 3 - Error (default) --> <LogLevel value="3"/> <Masks> <Mask name="ALL" on="false"/> </Masks> <Dumps> </Dumps> </Log> <ProductionNodes> <Node type="Depth" name="Depth1"> <Configuration> <MapOutputMode xRes="640" yRes="480" FPS="30"/> <Mirror on="true"/> </Configuration> </Node> <Node type="User" /> </ProductionNodes> </OpenNI> これらの内容の意味については次項で解説します。 9.4 Kinect を叩いてみる - OpenNI を使ってみよう それでは OpenNI から使ってみましょう。以下はサンプルを少しいじって、深度カメラを叩いて深度情報を取得し、 それを PPM 画像の形でダンプするようにしてみたものです。 29 /*BINFMTCXX: -Wall -I/usr/include/ni -I/usr/include/nite -lOpenNI * * 深度情報のキャプチャを行い、PGM 画像として保存する。 * カメラからの距離がピクセルの濃淡で表される画像になる。 * */ #include <XnCppWrapper.h> #define log(...) do { \ fprintf(stderr, __VA_ARGS__); fprintf(stderr, "\n"); } while (0) \ #define die(...) do { \ fprintf(stderr, __VA_ARGS__); fprintf(stderr, "\n"); exit(1); } while (0) \ // 深度センサが返すデータは深度が 16bit 値で左上から並んでいるので、 // そのまま 16bit PGM としてダンプすれば画像になる。 void ppmsave(xn::DepthMetaData& meta, const char *outfile) { const XnDepthPixel* pix = meta.Data(); XnUInt32 xmax = meta.XRes(); XnUInt32 ymax = meta.YRes(); // dump 16bit depth data as 16bit PGM FILE* out = fopen(outfile, "w+"); fprintf(out, "P5\n%d %d 65535\n", xmax, ymax); fwrite(pix, sizeof(XnDepthPixel), xmax * ymax, out); fclose(out); } int main(int argc, char **argv) { xn::Context context; xn::EnumerationErrors errors; xn::DepthGenerator dgen; xn::DepthMetaData meta; if (argc < 3) { die("Usage: %s kinect.xml depth.pgm", argv[0]); } // XML 構成ファイルでの初期化、深度カメラへの参照取得、そしてキャプチャ context.InitFromXmlFile(argv[1], &errors); context.FindExistingNode(XN_NODE_TYPE_DEPTH, dgen); context.WaitOneUpdateAll(dgen); // キャプチャデータの取得と保存 dgen.GetMetaData(meta); ppmsave(meta, argv[2]); context.Shutdown(); return 0; } これを実行すると、*21 $ ./camera3d.cc kinect.xml depth.pgm 次のように各ピクセルの深さが画像として取れます: *21 binfmtc パッケージをインストールしておくと、実行権限をつけておいた C++ プログラムを直接シェルから実行するとコンパイル・実行 してくれるようになります。 30 正直何がなんだか?という画像ですが、右側にいるのがノート PC を膝において座っている私です。 ここでの中核部分は以下の3行です。 context.InitFromXmlFile(argv[1], &errors); context.FindExistingNode(XN_NODE_TYPE_DEPTH, dgen); context.WaitOneUpdateAll(dgen); OpenNI ではシステム中にどのようなデバイスが存在するか、また、それらの構成(カメラなら解像度など)はど うなるかを外部の XML で記述でき、それを元に初期化を行います。コードだけでも書くことはできるのですが、そ の場合は構成を変更するとコードの書き換えが必要になります。 このコンテキスト(context)を作成し、そこにデバイスやフィルタ(未登場ですが、センサデータの入力を受けて ゼスチャ認識を行い、登録されているフックをトリガするものなどがあります)といった OpenNI モジュール群を接 続する、というのが OpenNI/NITE のプログラムフローになります。 最後に、上で利用した kinect.xml も引用しておきます: <OpenNI> <!-- ログ設定。以下の設定で標準出力は使わず Log/*.log に書く --> <Log writeToConsole="false" writeToFile="true"> <LogLevel value="0"/> <Masks> <Mask name="ALL" on="true"/> </Masks> <Dumps /> </Log> <ProductionNodes> <Node type="Image" name="Kin2D"> <Configuration> <MapOutputMode xRes="640" yRes="480" FPS="30"/> <Mirror on="true"/> </Configuration> </Node> <Node type="Depth" name="Kin3D"> <Configuration> <MapOutputMode xRes="640" yRes="480" FPS="30"/> <Mirror on="true"/> </Configuration> </Node> <Node type="Scene" /> <Node type="User" /> <Node type="Gesture" /> <Node type="Hands" /> </ProductionNodes> </OpenNI> 以後の例もすべてこの XML を使って動かしています。 9.5 ジェスチャの検出方法 - NITE を使う それでは次はジェスチャの認識をさせてみましょう。こちらでは NITE ライブラリを利用します。 これも OpenNI フレームワーク上のプログラミングなのでコンテキストを生成する点は同じですが、NITE ではコ ンテキストを介した深度センサデータのやりとりのような低レベルの操作は隠され、 1. ジェスチャー操作の流れを管理する、コンテキストをラップするセッションマネージャ 2. セッションマネージャに登録される各種のジェスチャー検出器 3. それら検出器に登録される、操作検知時に呼び出されるコールバック という構造のコードになります。操作中・操作終了をセッションマネージャが判定し、「セッション中」の動作のみが 検出器にかかるよう調整しています。 実際にどのようなものになるか、見てみましょう: 31 /*BINFMTCXX: -Wall -I/usr/include/ni -I/usr/include/nite -lXnVNite -lOpenNI * * 簡単なジェスチャ認識のテスト。 * 手を振ってセッション開始すると、プッシュとスワイプ動作を認識する。 * */ #include <XnCppWrapper.h> #include <XnVNite.h> /********************************************************************** * Utility Functions **********************************************************************/ #define log(...) do { fprintf(stderr, __VA_ARGS__); fprintf(stderr, "\n"); } while (0) \ \ \ #define die(...) do { fprintf(stderr, __VA_ARGS__); fprintf(stderr, "\n"); exit(1); } while (0) \ \ \ \ /********************************************************************** * セッションマネージャや検出器に登録するコールバック関数 * 現在は個々のジェスチャーを認識した等のログを出すのみ。 **********************************************************************/ static void OnSessionStart(const XnPoint3D &p, void *data) { log("session start"); } static void OnSessionEnd(void *data) { log("session end"); } static void OnFocusStartDetected(const XnChar *focus, const XnPoint3D &p, XnFloat progress, void *data) { log("focus start"); } static void OnSwipe(XnVDirection dir, XnFloat speed, XnFloat angle, void *data) { log("swipe detected. dir=%d, speed=%f, angle=%f", dir, speed, angle); } static void OnPush(XnFloat speed, XnFloat angle, void *data) { log("push detected. speed=%f, angle=%f", speed, angle); } /********************************************************************** * Main **********************************************************************/ int main(int argc, char **argv) { xn::Context context; if (argc < 2) { die("Usage: %s kinect.xml", argv[0]); } context.InitFromXmlFile(argv[1]); // セッションマネージャと各種検出器の生成 XnVSessionManager* sm = new XnVSessionManager; XnVSwipeDetector* sd = new XnVSwipeDetector; XnVPushDetector* pd = new XnVPushDetector; // セッションマネージャの初期化 // // 手を振って(Wave)セッションに入り、休止状態からのセッション再開は // 手を上げる(RaiseHand)。セッション中は下で登録された検出器が操作を // 検出するようユーザの動きをそれらに伝達する。 sm->Initialize(&context, "Wave", "RaiseHand"); sm->RegisterSession(NULL, OnSessionStart, OnSessionEnd, OnFocusStartDetected); // ジェスチャー検出器と検知した際のコールバックを登録 sm->AddListener(sd); sm->AddListener(pd); sd->RegisterSwipe(NULL, OnSwipe); pd->RegisterPush(NULL, OnPush); // 後はずっと入力を待ってはイベント処理するループ context.StartGeneratingAll(); for (;;) { context.WaitAndUpdateAll(); sm->Update(&context); } return 0; } 32 最初の深度データの画像を保存する例よりも簡単になりました。上では XnVSwipeDetector と XnVPushDetector の2種類だけを使いましたが、NITE には 10 を超える様々な基本ジェスチャーの検出器があり、また、複数のジェス チャーを組み合わせた操作に対応するための複合処理などを行う補助クラスも用意されています。 このように、多種多様な検出器を用意して、煩雑な体の各部の動きのトラッキングや照合の手間を NITE は省いて くれます。 各種の操作と認識率 なお、動かしてみるとわかりますが、動作によって「きちんと認識される」度が結構違います。スワイプは「一 瞬手を止めて、それからさっと流す」動作なのですが非常に認識率が悪いです。一方、プッシュ操作はほぼ確実 に認識されます。プッシュ(Push, Click)動作は手振り(Wave)動作と並んで「セッション開始のシグナル動 作(focus gesture)」として実用的とマニュアルに書かれていますが、よくわかります。快適な操作感のために は結局カスタムの検出器を作成する必要がありそうです。 9.6 アプリケーションの制御方法 - XTest の話 さて、これまで OpenNI, NITE と例を出してきましたが、次はこれで認識したジェスチャでどう他のアプリケー ションを制御するかです。今回は X11 の xtst(XTest) 拡張でマウスやキーイベントを送り、それで(この資料の)プ レゼンテーションが行えるようにします。 XTest 自体の使い方は以下のようになります。 /*BINFMTCXX:-Wall -lXtst -lX11 * XTest を使ったキーとマウスの制御テスト */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <X11/Xlib.h> #include <X11/Xutil.h> #include <X11/extensions/XTest.h> #define log(...) fprintf(stderr, __VA_ARGS__) #define die(...) do { fprintf(stderr, __VA_ARGS__); exit(1); } while (0) enum { DOWN = 1, UP, DOWNUP }; void sendkey(Display *disp, unsigned int keysym, int mask) { unsigned int kc = XKeysymToKeycode(disp, keysym); if (mask & DOWN) { XTestFakeKeyEvent(disp, kc, True, CurrentTime); } if (mask & UP) { XTestFakeKeyEvent(disp, kc, False, CurrentTime); } XSync(disp, False); } int main(int argc, char **argv) { Display *disp; if ((disp = XOpenDisplay(NULL)) == NULL) { die("Unable to open display\n"); } // キー入力のテスト - とりあえず ls させてみる unsigned int key[] = { XK_L, XK_S, XK_Return }; for (int i = 0; i < (int)(sizeof(key) / sizeof(*key)); i++) { sendkey(disp, key[i], DOWNUP); } // 相対位置移動 XTestFakeRelativeMotionEvent(disp, -100, -100, CurrentTime); XSync(disp, False); sleep(3); // 絶対位置移動 XTestFakeMotionEvent(disp, -1, 100, 100, CurrentTime); XSync(disp, False); sleep(3); 33 // XTest の FakeMotion でなぜか XMing 上のポインターが動かないので、 // XWarpPointer を使ってみるテスト・ ・ ・これだと動くようだ。 XWarpPointer(disp, None, None, 0, 0, 0, 0, 200, 200); XSync(disp, False); sleep(3); // Control 押しながら右クリックを実行(メニューが出るか確認) sendkey(disp, XK_Control_L, DOWN); XTestFakeButtonEvent(disp, 3, True, CurrentTime); XTestFakeButtonEvent(disp, 3, False, CurrentTime); sendkey(disp, XK_Control_L, UP); XSync(disp, False); // 終了 XTestDiscard(disp); XCloseDisplay(disp); return 0; } 操作したいアプリケーションに合わせて 1. XTestFakeKeyEvent 2. XTestFakeButtonEvent 3. XTestFakeMotionEvent 4. XTestFakeRelativeMotionEvent で操作イベントを送りながら、XSync で同期を取る(ポインタを移動させて入力、のような操作で、移動が完了して から入力がされるようにする)というのが基本的な処理になります。 あとはこれを先の OpenNI/NITE のジェスチャ検知をトリガに発行してやれば、今回のデモは完成になります。 9.7 デモ さて当日うまくいくか・ ・ ・ (当日の結果:いくら Kinect の前で踊っても反応が鈍すぎで、スライドを3枚めくった 所で聴衆からお役御免を言い渡されたのだった・ ・ ・。NUI 難しい) 34 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 10 俺の libsane が火を噴くぜ! 本庄 弘典 SANE は Scanner Access Now Easy の頭文字を取ったもので、各種デバイスから画像を取り出すための汎用イン ターフェースです。主にスキャナから画像を取得するため、Linux や FreeBSD などフリーな OS で利用されます。 今回は SANE の仕組みと libsane を用いたプログラムの作成方法について解説します。 10.1 SANE の構造 SANE を利用するアプリケーションは libsane.so という共有ライブラリをリンクします。libsane.so は dll と呼ば れる仮想デバイスドライバを通し、各デバイスごとに作られたドライバにアクセスすることでデバイスを制御します。 また図に示されるように、net 仮想ドライバで他のマシンの saned に接続することで、リモートスキャナへのアクセ スを実現します。[1, 2, 3] 図 2 SANE の構造 なお、SANE を利用するユーザは scanner グループに所属させる必要があります。 35 10.2 Code Flow 図3 Code Flow 10.3 スキャンするためのコード とりあえずスキャンするだけのコードは次のようになります。 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sane/sane.h> #define MAXLEN 32768 int main() { SANE_Status stat; SANE_Handle hndl; SANE_Byte buf[MAXLEN]; SANE_Int len = MAXLEN; FILE *fp; stat = sane_init(NULL, NULL); printf("init: %d\n", stat); stat = sane_open("fujitsu:libusb:008:002", &hndl); printf("open: %d\n", stat); fp = fopen("foo.bin", "wb"); stat = sane_start(hndl); printf("start: %d\n", stat); while (len == MAXLEN) { stat = sane_read(hndl, buf, MAXLEN, &len); printf("read: %d\n", stat); printf("read_len: %d\n", len); fwrite(buf, len, 1, fp); } fclose(fp); sane_close(hndl); printf("close: %d\n", stat); sane_exit(); printf("exit: %d\n", stat); } このコードで保存される foo.bin は、ScanSnap S1500 の場合、ヘッダ無しの pbm ファイルとして保存されまし た。スキャナによっては pgm で保存されるものもあり、デフォルトで保存される画像のモードは特に決まっていない ようです。 36 10.4 カラーのスキャン オプションの設定にはいくつか注意点があるようです。 • sane get option descriptor() でオプションの説明文やフォーマットの取得が可能。 • sane control option(hndl, 0, SANE ACTION GET VALUE, &num, &info) でオプションの総数を取得で きる。 • sane control option() で Action に SANE ACTION GET VALUE を指定することで現在設定されているオ プションを読み出すことが可能。 • sane control option() で Action に SANE ACTION SET VALUE を指定することでオプションの設定が 可能。 • sane control option() を呼ぶ際には事前に sane get option descriptor() を呼び出しておく必要がある。 #include #include #include #include <stdio.h> <stdlib.h> <string.h> <sane/sane.h> #define MAXLEN 32768 int main() { SANE_Status stat; SANE_Handle hndl; const SANE_Option_Descriptor *opt; SANE_Int info = 0; SANE_Byte buf[MAXLEN]; SANE_Int len = MAXLEN; SANE_Parameters param; FILE *fp; stat = sane_init(NULL, NULL); printf("stat: %d\n", stat); stat = sane_open("fujitsu:libusb:008:004", &hndl); printf("open: %d\n", stat); int x=300, y=300; opt = sane_get_option_descriptor(hndl, 4); printf("get_option_descriptor: %03d: %d\n", 0, opt->size); stat = sane_control_option(hndl, 4, SANE_ACTION_SET_VALUE, &x, &info); printf("control_option: %d\n", stat); printf("info: %d\n", info); opt = sane_get_option_descriptor(hndl, 5); printf("get_option_descriptor: %03d: %d\n", 0, opt->size); stat = sane_control_option(hndl, 5, SANE_ACTION_SET_VALUE, &y, &info); printf("control_option: %d\n", stat); printf("info: %d\n", info); strcpy(buf, "Color"); opt = sane_get_option_descriptor(hndl, 3); printf("get_option_descriptor: %03d: %d\n", 0, opt->size); stat = sane_control_option(hndl, 3, SANE_ACTION_SET_VALUE, buf, &info); printf("control_option: %d\n", stat); printf("info: %d\n", info); stat = sane_start(hndl); printf("%d\n", stat); fp = fopen("foo.ppm", "wb"); stat = sane_get_parameters(hndl, ¶m); printf("get_parameters: %d\n", stat); sprintf(buf, "P6\x0a# SANE data follows\x0a%d %d\x0a%d\x0a", param.pixels_per_line, param.lines, 255); fwrite(buf, strlen(buf), 1, fp); while (len == MAXLEN) { stat = sane_read(hndl, buf, MAXLEN, &len); printf("read: %d\n", stat); printf("read_len: %d\n", len); fwrite(buf, len, 1, fp); } fclose(fp); sane_close(hndl); printf("close: %d\n", stat); sane_exit(); printf("exit: %d\n", stat); } 37 図4 スキャン結果 モノクロではわかりづらいと思いますが、ScanSnap S1500 でスキャンした結果、R と B が入れ替わってスキャン されました。 10.5 まとめ • やや不安定 (特に権限周り) – scanimage -L でたまに segmentation fault する • スキャナによってデフォルトの動作がまちまち – ScanSnap は.pbm でスキャン – CanoScan は.pgm でスキャン • スキャナによって RGB の順番すらまちまち – でもこれは ScanSnap が悪いのかも – ScanSnap は TWAIN 未対応だし • ドキュメント化されていない罠の存在 • スキャナのボタンをイベントとして使えないっぽい 参考文献 [1] SANE - Scanner Access Now Easy http://www.sane-project.org/ [2] SANE-tutorial-JP / 著者:David Mosberger / 翻訳:川岸 良治 http://archive.linux.or.jp/JF/JFdocs/SANE-tutorial-JP.html [3] SANE Standard Version 2.0 proposal 0.08 - rauch/beck http://www.sane-project.org/sane2/0.08/ 38 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 11 Proxmox VE の紹介 森山 京平 11.1 自己紹介・経歴・概要 森山 京平(23) NAIST(奈良の森の中の大学院) Ubuntu User Debian は、サーバ用途でしか触ったことがない。 最近は、もっぱら、仮想化技術に興味をもち、KVM を触って自己満足の世界にひたっている。某プロジェクト*22 の ネットワークエンジニア兼サーバエンジニアに任命され、四苦八苦しながらネットワーク・サーバの運用と管理を 行っている。今年 AI3 Project では、10 年ほど運用してきたサーバ(物理マシン)のリプレイスを行うようになっ た。そこで、近年話題になっている、仮想化技術を用いて、サーバの台数を減らし、可用性を増すことを試みた。機 器の設置や、dom0(仮想化のベースとなるサーバ)の設定は、ほぼ終了。仮想マシンで実行するサービスのテストも 無事に終わった。今後、次々に移行していく予定である。KVM を用いて完全仮想化を行うという要求があったので、 どうしようと迷っていた所、Debian ベースで開発が進んでいる、ProxmoxVE という OSS に出会い、それを採用さ せて頂いた。今回は、その ProxmoxVE について簡単にご説明させていただこうと思う。 11.2 Proxmoc VE とは ProxmoxVE とは、Proxmox Server Solutions GmbH によって開発されている、Debian ベースでかつ web、cli から仮想マシンを操作できる KVM&OpenVZ マネージメントツールである。perl と shell を使い qemu や kvm コ マンドをうまく組み合わせて web 上からの操作を可能にしている。競合しているツールとして同じく web から操作 できる KVM のマネージメントツールの karesansui がある。こちらは国内産であり、100%PurePython で書かれて いる。優位性云々は、karesansui をあまりあたったことがないのでわからない。ProxmoxVE のスタートは、メール ゲートウェイの仮想化を行い、セキュリティを高める目的の仮想化環境である proxmox という OSS からスタートし ている。proxmox から得た知見を proxmox VE にも適用している。現在の最新バージョンは、1.7 であり、2.0 のリ リースが予定されている。ダウンロードは http://www.proxmox.com/ からできる。 11.3 インストール さて、インストールの方法を説明したい。そのまえに、dom0 マシンに対しての要求がある。KVM による完全仮 想化を実現するために、お持ちのマシンの CPU が Intel-VT もしくは AMD-V に対応しておかなければならない。 *22 AI3 http://www.ai3.net 39 もしも、OpenVZ のみを使うのであれば、それらは、必須ではない。しかしながら、パフォーマンスとしては、完全 仮想化であるほうが、優位であると参考までに覚えておいていただきたい。 11.3.1 ダウンロード ProxmoxVE のイメージをダウンロードする。http://www.proxmox.com/ ここから donwnload リンクをたどっ て行くと iso をダウンロードできる。ダウンロードした iso を CD なり DVD に焼く。 11.3.2 ProxmoVE のインストール インストール手順は、至ってシンプル。マシンの性能にもよるが、15 分程度で仮想環境が手に入る。 11.4 web インターフェースからの各種操作 ProxmoxVE では、基本的に操作を web インターフェース上から行うように設計されている。ログイン画面から ログインを行うことで、Web 管理コンソールに入ることができる。ログインを終えると、ホストマシンのカレントス テータスが表示される。*23 11.4.1 VM マネージャ VM マネージャの欄には、仮想マシン、テンプレート、ISO イメージという項目が存在する。仮想マシンでは、仮 想マシンの状態、作成、マイグレートの操作を行うことができ、テンプレートでは、OpenVZ のテンプレートに関す る操作ができる。また、ISO イメージにおいては、OS のインストールディスクのイメージをアップロードできる。 テンプレートは OpenVZ から、ISO イメージは KVM から用いる。 ■リスト ここから、仮想マシンのそれぞれのメンテナンスタスク、カレントステータスを確認することができる。 仮想マシンの設定 実行中の仮想マシンの欄をクリックすることで仮想マシンの設定画面に遷移する。仮想マシンの 操作や設定はここから行う。 • 仮想マシンの設定 [仮想マシンのディスク領域、メモリ、スワップなどの設定] • 仮想マシン削除 [仮想マシンの削除をおこなう(復元不可)] • 仮想マシン起動 [仮想マシンの起動をおこなう] • 仮想マシン再起動 [仮想マシンの強制再起動をおこなう] • 仮想マシンシャットダウン [仮想マシンの強制シャットダウンを行う] • 仮想マシン停止(サスペンド?)[仮想マシンのサスペンドをおこなう(未実装?)] • VNC コンソールへのアクセス [JAVA アプレット-VNC でコンソールへアクセスする] ■作成 仮想マシンの作成をおこなう。KVM に対応していれば、KVM の項目が出てくる、そうでなければ、タイ プの欄に OpenVZ の項目しか出てこない。それぞれのパラメータの設定おこない、”作成する ”をクリックすること で、仮想マシンの作成をおこなえる。 ■マイグレート ProxmoxVE では、CLI から pveca コマンドを用いることでクラスタリングを行うことができる。 クラスタリングを行った物理マシン間で仮想マシンのマイグレートが可能である。今回は、端折らせていただくが、 物理マシンのメンテナンスの際に役立つ機能である。 仮想マシンの項目から、ほとんどの管理を行うことができる、その点が ProxmoxVE の素晴らしいとこである。詳 細な管理や設定を行いたい場合には、CLI(ssh によるアクセス)でおこなう。CLI のベースは debian であるので、 かなり使いやすい印象をうけた。 *23 CPU、メモリ、カーネルのバージョンなど 40 11.4.2 設定 設定には、システム、ストレージ、バックアップの項目が存在する。 ■システム ネットワーク、DNS、時刻、管理、オプションの項目があり、ネットワークでは、おもにネットワーク インターフェースの設定を行う。DNS では、DNS の設定を行い、サード DNS サーバまで設定を行える。時刻は、 時間帯の設定(JST など)の設定を行う。NTP サーバの設定ができるかと思ったらそうではなく、もし特定の NTP サーバの設定を行いたい場合は、CLI からの設定が必要であるように思う(未確認)。管理の項目からは、管理者の E-mail、パスワードの設定が行える。オプションからは、言語とキーボード、HTTP プロキシの設定を行える。 ストレージ ストレージの設定を行う。ストレージの追加削除を行う。iSCSI、NFS、LVM グループ、ディレクトリ の参照をおこなうことが可能である。 バックアップ ストレージの項目から、バックアップストレージの指定があれば、ここから、バックアップの設定を おこなうことができる。定期的な仮想マシンのバックアップを行うことができる。 ■管理 管理の項目には、サーバ、ログ、クラスタがある。 サーバ サーバのサービスの起動、停止、再起動を行うことができる。SSL 証明書もここからダウンロードできる。 またサーバそのものの再起動、シャットダウンも行える。 ログ タスクのログ、syslog の確認を行えることは、認識しており、仮想化初心者ユーザの敷居を低くする有用な OSS であるかと思う。もし、詳細をしりたい方がいらっしゃれば、ProxmoxVE の Wiki[1] を参照していただけたら と思う。 参考文献 [1] ProxmoxVE Wiki, http://pve.proxmox.com/wiki/Main_Page 41 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 12 Apache2 のモジュールをつくって みた 上川 純一 Apache httpd というウェブサーバがあります。おそらく定番と言われるウェブサーバで、多くの人が利用してい ると思います。ウェブサーバとして多くの機能を提供している Apache ですが、モジュールという仕組みで機能拡張 可能です。今回は Debian 上で Apache モジュールを作る方法をさぐってみることにします。 12.1 Apache モジュールをつくりたいとき Apache モジュールが作りたいときはどういうときでしょうか。作りたいと思ったときがつくりどき。cgi で fork する手間が惜しい、インタプリタ言語でインタプリタが走っている時間がもったいない、GC のある言語でときどき 反応が悪くなるのが気にくわない。いろんな理由があるとおもいますが、C 言語でがりがりとウェブリクエストを処 理したいとかそういう要望があるのではないでしょうか。 Apache モジュールでできることはどういうことでしょうか。Apache の受け取る入力 (HTTP Request) から出力 (HTTP Response) のほぼ任意の場所にフックとして割り込むことができて、入出力のデータを加工することが可能 です。 12.2 Debian の Apache パッケージの構成 ところで、httpd と Debian apache2 はどれくらい違うかご存知でしょうか。 Debian パッケージの README.Debian を見てみましょう。[1] ざっと眺めただけでも以下の点で特徴があります。 • apache2 コマンドが環境変数に依存している。 • apache2ctl / /etc/init.d/apache2 を利用しないと起動とかできない。 • 設定ファイルの配置が全然違う。 • a2enmod / a2dismod コマンドが追加されている。 • apxs コマンドが apxs2 という名前になっている。 12.3 Apache モジュールの作成 普通の Apache モジュールの作成の流れをみてみましょう。 12.3.1 パッケージの準備 とりあえず開発環境をインストールしましょう。 42 # apt-get install apache2-threaded-dev 12.3.2 テンプレート生成 apxs2 コマンドを利用してテンプレートを作成します。モジュール名でディレクトリが作成されます。 $ apxs2 -g -n dancerqps $ cd dancerqps $ ls Makefile mod_dancerqps.c modules.mk 12.3.3 ソースコード編集 ソースコードを編集しましょう。この場合、自動で生成された mod_dancerqps.c がメインのモジュールソース コードです。 まず一番下に一番重要な構造が定義されています。ここで重要なのは dancerqps_register_hooks を登録してい るところでしょうか。 module AP_MODULE_DECLARE_DATA STANDARD20_MODULE_STUFF, NULL, /* NULL, /* NULL, /* NULL, /* NULL, /* dancerqps_register_hooks }; dancerqps_module = { create per-dir config structures merge per-dir config structures create per-server config structures merge per-server config structures table of config file commands /* register hooks */ */ */ */ */ */ dancerqps_register_hooks で実際にフックの登録を行います。ここでは、アウトプットフィルタを登録してい ます。 static void dancerqps_register_hooks(apr_pool_t *p) { ap_register_output_filter(dancerqps_name, dancerqps_filter, NULL, AP_FTYPE_RESOURCE); } そして、実際に各リクエストのアウトプットに対して実効するフィルタのコードを書きます。 static apr_status_t dancerqps_filter(ap_filter_t *f, apr_bucket_brigade *bb) { /* ここでなにか処理をする */ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, f->r, "dancerqps processing was here!"); return ap_pass_brigade(f->next, bb); } 12.3.4 モジュールのファイルインストール モジュールをビルドしてインストールする一連の手順をしてくれるコマンドがあります。 $ sudo apxs2 -c -i mod_dancerqps.c 12.3.5 モジュールを有効にする apxs2 コマンドでモジュールを有効にする方法は Debian 独自の a2enmod などのコマンドの存在を無視している ようなので a2enmod などと整合性のとれるような方法をとるのがよいでしょう。で、それでは Debian 的な方法と はなんでしょうか。 Debian way 1 めんどくさい方法だけどシステム運用者としては便利かもしれない方法。a2enmod とかができます。 /etc/apache2/mods-available に hoge.conf, hoge.load ファイルを作成します。hoge.conf は設定が不要なら不要 ですが、httpd.conf に書くような内容を記述します。hoge.load には LoadModule 行を記述します。 この方法でファイルを作成しておけば、/etc/apache2/mods-enabled ディレクトリにシンボリックリンクが作成さ 43 れます。 Debian way 2 デフォルトでは空のファイルだけど、/etc/apache2/httpd.conf に書き込むとその設定が有効になります。 LoadModule test_module /usr/lib/apache2/modules/mod_test.so <Location "/hoge/"> SetHandler test </Location> Debian 的な方法から乖離しているっぽい方法 apache をコマンドラインから設定ファイルを指定して起動することができます。Debian の Apache は環境変数を 設定しないと直接は起動できなくなっているので、面倒な手続きが必要になります。 まず、適当にテスト用の http.conf をでっち上げます。 Listen 8080 LockFile /home/test/tmp/apache.1.lock PidFile /home/test/tmp/apache.1.pid # log configuration. LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog "/home/test/log/access_log" common ErrorLog "/home/test/log/error_log" # Order, Allow. LoadModule authz_host_module /usr/lib/apache2/modules/mod_authz_host.so # map from / -> /index.html LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm # .html -> content-type: text/html LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so TypesConfig /etc/mime.types # Document root DocumentRoot "/home/test/hoge" <Directory "/home/test/hoge"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> # Load my custom filter. LoadModule dancerqps_module /usr/lib/apache2/modules/mod_dancerqps.so SetOutputFilter DANCERQPS 適当な設定ファイルを指定して Apache を起動してみます。 APACHE_RUN_USER=dancer \ APACHE_RUN_GROUP=dancer \ /usr/sbin/apache2 -f $(readlink -f ./httpd.conf) -k restart 12.3.6 負荷テスト ab (apachebench) ツールが標準で入っているのでそれで計測します。適当に確認しましょう。 44 $ /usr/sbin/ab -c 100 -n 100 http://localhost:8080/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient).....done Server Software: Server Hostname: Server Port: Apache/2.2.9 localhost 8080 Document Path: Document Length: / 44 bytes Concurrency Level: Time taken for tests: Complete requests: Failed requests: Write errors: Total transferred: HTML transferred: Requests per second: Time per request: Time per request: Transfer rate: 100 0.056 seconds 100 0 0 29600 bytes 4400 bytes 1796.17 [#/sec] (mean) 55.674 [ms] (mean) 0.557 [ms] (mean, across all concurrent requests) 519.21 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median Connect: 7 9 0.5 9 Processing: 9 26 8.9 27 Waiting: 6 26 9.3 27 Total: 16 36 8.9 37 max 10 40 40 49 Percentage of the requests served within a certain time (ms) 50% 37 66% 41 75% 43 80% 45 90% 47 95% 48 98% 49 99% 49 100% 49 (longest request) 12.3.7 まとめ はじめて Apache モジュールを作成して、インストールして動かすところまでやってみました。 参考文献 [1] Debian の Apache2 パッケージの README.Debian ファイ, /usr/share/doc/apache2.2-common/README. Debian.gz 45 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 13 CAcert の準備に何が必要か 山田 泰資 13.1 CAcertって何? CAcert プロジェクトとは誰もが低コストに証明書を持てるようにすることで、安全な環境・通信を広く実現しよ うというプロジェクトです。2002 年に発足し、2003 年には非営利法人の CAcert Inc. がオーストラリアで設立され、 以来7万人のメンバーに対して18万件の証明書(クライアント認証用、サーバ認証用、S/MIME 署名用、コード署 名用、etc)を発行してきています。 通常、個人や組織内で自己発行した証明書は「オレオレ証明書」などと呼ばれてあくまで閉じた世界での利用にな ります。しかし、このプロジェクトでは CAcert がルート証明機関として、そのルート証明書が各種 OS やブラウザ に組み込まれ、VeriSign 社などによる商用サービスに近い水準で世界的に信頼される状態を目指しています。このた め、コミュニティベースのプロジェクトとは言っても、厳格かつ高い水準の認証基準や運営ポリシが定められていま す*24 。 この高い水準の認証局運営を低コストで行うため、CAcert は次の2つを運営の柱としています: 1.「信頼関係の構築・維持」と「証明書発行」の分離 2.「信頼度・経験値のポイント化」と、「ポイントによる発行制限」 まずは前者から説明します。通常、証明局の運営では申請者の身元確認などを法的文書に基づいて行い、その上で 証明書を発行します。この前者が高コストで、 1. 提出された申請内容が真正かどうかの確認 2. 後日の紛争に備えての関係書類の(法的に有効な)紙での保管 などで事務コストがかかります。一方、証明書の発行は秘密鍵の安全な保管などセキュリティ面のコストは必要なも のの、比較的安価です。そこで、CAcert では 1. 本人確認と関係書類の保管はコミュニティベースで各自が実施 2. それに基づいた証明書の発行は CAcert がルート CA となって実施 という認証と発行の分離を行っています。コミュニティ側で行った認証結果をポイントという形で CAcert に登録し、 CAcert はポイントに応じて各種の証明書を発行する訳です。 そしてこのポイント制度も CAcert の特色の1つです。CAcert Inc. 自身は本人確認を行っていないので、認証を する側もされる側もコミュニティメンバーという事になります。この仕組みの中で十分な認証を行うため、 1. 認証「される」人が申請できる証明書の形式・機能はポイントに応じる *24 実は途中沈滞していたものの、ここ数年で急速に整備されてきました 46 2. 認証「できる」ようになるのは 100pt に到達してからで、更に試験合格が必要 3. 認証時に付与できるポイントも 100pt の成り立てでは少なく、経験に応じて増える と1回の認証ではなく多人数間で認証を行う(Web of Trust と呼びます)方式を導入しています。 13.2 CAcert でできること - 証明書の作成、認証者としての活動 さて、まずは一番利用するであろう証明書の作成について紹介します。実際のところ、認証を受け、利用するのみ のメンバとしてであれば、これが CAcert の唯一の機能です。 これは https://cacert.org/ に行き、メンバ登録を行うことで作成できます。ただし、認証可能メンバ(CAcert Asurer)による認証・ポイント付与を受けていない場合、作成できるのは最低限の機能を持つ証明書のみとなります。 以下が保有ポイントによる作成可能な証明書などメンバ権限の一覧です: 保有ポイント ≥0 ステータス できること Member 実名抜き(メールアドレスのみ入る)のサーバ・クライアン ト用証明書の発行(半年有効) ≥1 Member 上と同様だが、署名元のルート証明書が Member Root 証明 書に格上げされる ≥ 50 ≥ 100 ≥ 100 + 試験通過 Assured Member 実名入りのサーバ・クライアント用証明書の発行(2年有効) Prospective Assurer 上に加え、コードサイニング証明書の発行(1年有効) Assurer 上に加え、オンライン試験に合格した場合、認証可能メンバ として他者を認証し、最大 10 ポイントまで付与できる。ま た、自身は以後の認証の度に 0-2EP を受領する ≥ 100 + 10EP + 試験通過 Assurer 上と同様だが、付与可能ポイント上限が 15 ポイントとなる ≥ 100 + 20EP + 試験通過 Assurer 上と同様だが、付与可能ポイント上限が 20 ポイントとなる ≥ 100 + 30EP + 試験通過 Assurer 上と同様だが、付与可能ポイント上限が 25 ポイントとなる ≥ 100 + 40EP + 試験通過 Assurer 上と同様だが、付与可能ポイント上限が 30 ポイントとなる ≥ 100 + 50EP + 試験通過 Assurer 上と同様だが、付与可能ポイント上限が 35 ポイントとな る。また、コミュニティ内において Experienced Assurer / Senior Assurer としての役割に進む入口に達したと見なさ れる 表1 ポイントによるアカウントステータスと権限の一覧 上の通り、証明書の発行を受ける利用者としては 100pt が上限となります。これ以上はどれだけ認証を受けても Assurance Point は増えません(システム的に増えたように見えても無効)。しかし、一方で試験を受け、Assurer と して他者を認証すると、その度に最大 2EP が与えられます。表中の 10EP/20EP/... とある部分がそれで、これを Experience Point と呼びます。以後はこちらを蓄積することで、更に上位のステータスを得る形になります。 ちなみに試験は選択式(25 問中 20 問正解で合格)で、実はそんなに難しくありません。100pt に達する前から受 けることができ、合格するまで何度やっても構いません(トレーニング的な意味で定期再受験が推奨されている)。合 格しておけば 100pt になった瞬間から Assurer になれるので、皆さん受けておいてはいかがでしょうか?*25 以下が試 験画面です: *25 https://cats.cacert.org/ から受けられますが、クライアント証明書が必要です 47 図5 オンライン試験(選択式)の画面(全25問) 最後に、さらに上位の Assurer として Experienced / Senior Assurer というものがあります。これらはイベント内 での認証会の開催では Experienced Assurer が最低3名必要であったり、コミュニティ内での調停やトレーナーには Senior Assurer が指名されるなど、より幅広い関わりを持つ上で必須の重要な立場となります。Experienced Assurer は 50EP 以上(つまり、100pt 分の認証を受けた後、最低 25 人以上を認証した状態)が条件ですが、SeniorAssurer の認定には 1. Experienced Assurer であること 2. さらに、co-auditor*26 の試問を受け、合格すること 3. さらに、各国*27 で開催される ATE(Assurer Training Event) に参加し、トレーニングを受けていること 4. さらに、宣誓(CARS - CAcert Assurer Reliable Statement)を行うこと という高いハードルがあります。組織としての CAcert が一通り機能するには Senior Assurer の存在がキーとなるた め、日本で CAcert が完全に立ち上がったと言えるのは、この Senior Assurer が生まれた時になるでしょう。 13.3 認証を(して|されて)みよう 最後までのハードルは高いのですが、まずは第一歩からということで、1対1で認証を(する|される)時の手順 を紹介します。 まずは双方で以下を用意します(標準的な手順の場合) : *26 *27 認証ポリシの策定や監査を統括する Assurance Office の委託を受けて活動している経験豊富な Experienced Assurer 現時点ではほぼ欧州でのみ開催・ ・ ・ 48 認証する側(Assurer)が用意するもの 1. 相手に名乗るための名刺(ただし、口頭でもよいa ) 2. 白紙・未署名の CAP(CAcert Assurance Program) Form(相手が忘れた時用)b 3. 紫外灯などの、証明書の偽造検出のための機材c 4. 法的責任や義務を説明するための CCA(CAcert Community Agreement)(できれば渡せるよう紙で) a 不特定多数のイベントでは、0点付与/調停となる可能性もあるので、口頭に留めるのが正解? b https://secure.cacert.org/cap.php c 日本政府発行のパスポートなどをこれで確認する 認証される側(Member)が用意するもの 1. CAcert に登録したメールアドレス(複数登録の場合はプライマリのもの) 2. 身元証明書。2つ以上が望ましく、最低1つは政府発行かつ誕生日入りである必要がある。また、最低1 つは写真入りである必要がある 3. 未署名の CAP Form(署名以外は事前記入・印刷 OK)a a https://secure.cacert.org/cap.php - なお、ログインすれば事前記入済みのものをメニューから選択・印刷もできる 中央集権型の CAcert では、証明書の階層構造の安全を守るためと、認証手続きが実際に法的責任が生じる契約で あることから、GPG キーサイン会よりも高い基準での偽造検出や確認を要請しています。上の紫外灯での真正性確 認と、未署名書類へ目の前で署名することの確認義務などがそれにあたります。 さて、続きです。お互いの準備が整ったら、以下の手順で説明・確認・署名を行います。 ! !手順は説明・確認・署名の順番です! ! 大事なことなので二回書きました。 1. まず、Assurer から CCA の概要、特に法的に発生する義務と責任について明確に説明して下さい。骨子とし ては以下の3点ですが、Assurer は下記の背景や CAcert の意義を合わせて説明する義務があります。 (a)係争となった場合、各国内の裁判所に提訴する権利は放棄し、CAcert が Assurer の中から任命する調停 者の裁定に従う義務があること (b)誤用や誤認証を行い損害が発生した場合、補償責任があること。ただし、最高でも 1000EUR(2010/12 の相場で約 10 万円強)となる (c)証明書の運用・保証範囲やプライバシ保護などに関して、公式文書群(COD - CAcert Official Document) の規定に従うこと 2. Member が上記の義務・責任に同意するなら次に進みます 3. 次に、Assurer は Member に CAP Form への記入と署名を求め、併せて証明書を受け取って下さい。なお、 署名と提出は目の前で行われる必要があります(事前署名は不可) 4. Assurer は内容を確認して下さい。確認ポイントは以下の通りです: (a)責任・義務を規定する CCA に同意する旨が明記・チェックされていること (b)氏名・誕生日が一致し、また、写真からも当人であることが確認できること (c)メールアドレスが cacert.org に確かに登録されていること (d)書類への署名が証明書に記載の署名(あれば)と同じであること (e)証明書が失効しておらず、真正と見えること(紫外灯チェック、写真の上にハンコがかかっているか、等) (f)相手が氏名・誕生日など、証明書記載事項の質問に対して正答すること 5. 不備があるなどで確信が持てない場合、以下の対応を行います: (a)仕組み上、付与ポイントが少なくなったり、調停が必要となる可能性があることを伝えて下さい (b)表記違いがある場合、証明書の記載内容が優先されます。CAcert 登録内容の修正について当人と調整し、 49 dispute(調停依頼*28 )を Assurer より提起して下さい。ポイント付与は修正後に行います。 (c)複数の証明書で氏名表記に揺れがあるものの同一人物と判断できる場合は、CAP Form にすべて列挙の上 で認証して下さい。 (d)芸名であっても、それが規定の証明書で証明可能であれば、認証して構いません (e)称号(PhD 等)は使わないで下さい。証明書の記載内容以上のものを認証してはなりません 6. 以上で両者の対面での手続きは終了です。ここで別れて下さい。 7. 最後に、CAP Form の裏面にメモを残します。困った点、書類が古かった、妙に急かされた等の引っかかっる 点があったらそれを、また、面白い用法や、相手が運営参加希望者だった場合はその得意分野などです。後日 の連絡や調停時に使います。 以上が当日のやりとりとなります・ ・ ・が、Assurer の仕事はまだ終わっていません!認証パーティが終わったら、 Assurer の手元には署名入り CAP Form が沢山残るはずです。これらを元に、以下の事後処理を行います: 1. CAP Form に対して認証者として署名する 2. cacert.org より、CAP Form 記載のメールアドレスに対してポイントを付与する。付与するポイント数は、裏 面メモなどを見ての確信度に応じて0点から最高点まで調整 3. 処理を終えた CAP Form を、7年間保管できる場所にしまう ← ← ← 説明後述 さて、ここで「0点を付与」と「手続き自体をしない」は意味が異なります。「0点」は「相手を信頼できなかっ た」ではなく 書類が未知すぎて、点数を付けたくてもできませんでしたー!mOm という意味になります。0点を貰った人は、誤解しないようにしましょう。一方、手続きをしないというのは いや、この(人|書類)はおかしいだろ JK という、どう見ても本物ではなかったなどの疑念が大きい場合です。この場合は裏面メモを取っておき、ポイント付 与ではなく調停依頼を [email protected] に要請することも考えましょう。 13.4 7年間の保管義務って? おそらく GPG キーサインとの最大の違いは、この点になります。 単に認証基準が高いというだけでなく、CAcert は デジタル空間の証明階層を実世界の法的文書でバックアップする という意義を持っています。このため、紙ベースで署名・作成された CAP Form は Assurer に保管義務があるだけ でなく、その電子化も禁止されています*29 。 もし自分では保管し続けることが困難になった場合は、[email protected] に調停依頼を要請し、指示を仰いで ください。 13.5 公式 CAcert イベントの開催方法 1対1での認証と違い、正式な認証会の開催となると多くのものが必要となります。基本要件は先の1対1と同じ なのですが、公式 CAcert 認定イベントとして開催する場合、各種の規定があります。要件としてあるのか、単に 「円滑な開催、信頼性の高い認証」のために推奨されているものか判然としない部分もありますが、マクロレベルで *28 *29 この単語だけだと紛争・係争ですが、このような修正依頼なども含まれるため、調停を用語としました CAP Form 毎に署名を付加して各自で保管とか考えましたが、再びデジタル空間に基盤が戻ってしまうので不可のようです… 50 の開催の流れは以下のようになります。 1. Event Office へ開催提案を送る (http://wiki.cacert.org/Officers) 2. CAcert との窓口になる主催者(EventOffier)を協議して決める 3. 開催日・場所を決め、スポンサーを付ける場合は予算案を詰める*30 4. 計画策定。出展内容や必要資材・搬入の調整、更には当日に Assurer として参加を求める場合は事前の Assurer 人員の教育や宿泊の手配を行う 5. 事前準備。ブースの設営、配布物の用意、買い出しなど 6. イベント実施 7. 後片付け。撤収の他、再利用可能なバナーなどの資材は回収・整理する 8. 完了報告。EventOfficer よりレポートを Event Office に送って終了 これはあくまで CAcert 公式イベントとする場合なので、そうでない場合は1対1の認証を基本として、この章の 内容は準備内容の参考に使って下さい。 13.5.1 準備チェックリスト ここでは推奨されている確保すべき人員・資材の一覧を列挙しておきます。これを満たさなくては正規の認証手順 を経たと認定されないということはなさそうですが、後から不備・無効となるのを避けるため、慣れるまでは心配な 点は CAcert 側の Event Office に相談するとよいでしょう。 役割 Event Organiser 人数 注記 1 主催者兼進行役。一番の経験者がよい。Event Office と相談 して決める Experienced Assurer 3+ 認証担当。他ブースを訪問して証明して回る巡回証明役もい るとよい Assurer 2+ EA の補助として CAP Form の事前確認を行い、EA をフ ル回転させる ガイド役 2+ 表2 資材 CAcert イベント開催に必要な人員 個数 注記 紫外灯 1+ 並行処理する認証手続きの個数だけ用意 机 1+ 並行処理する認証手続きの個数だけ用意 椅子 1+ 並行処理する認証手続きの個数だけ用意 ネット回線 0+ 事前印刷が十分できていれば必須ではないが推奨 PC 1+ 資料閲覧、ポイント付与作業、新規登録用(Knoppix 推奨) 1 CAP Form 不足や配布資料の現場量産用 10+ 参加人数や進行方法に基づいて本数は考える 1 経費のカバー用(事前告知があれば、正式に徴収してもよい プリンタ ペン 募金箱 表3 *30 行列の整理や質疑、派生して起こる問題の対処など CAcert イベント開催に必要な資材 本気で公式イベント化する場合、どうも色々支援がある? 51 資料 Assurer 連絡名簿 個数 注記 1 認証に関する疑義対応や後日のフォローアップ用 CAP Form(1p, 記入済) 30+ CAP Form(1p, 白紙) 20+ CCA (4p) 50+ 未署名。開催日、場所、Assurer 名まで記入 新規 Assurer に手伝ってもらう用 Assurance に伴う契約義務・責任の解説用 CCA (巨大張り出し用) 1 壁に張り出して使う Assurance Policy (8p) 1+ 質疑回答、参照用 Assurance Handbook (29p) 1+ 質疑回答、参照用 Root Distribution License (1p) 1 質疑回答、参照用 Dispute Resolution Policy (6p) 1 質疑回答、参照用 Practice On Names (4p) 1+ 各 Assurer に1部。表記揺れへの対応ガイド Practice On ID Checking (4p) 1+ 各 Assurer に1部。証明書内容の検査ガイド PoJAM (4p) 1 未成年への認証、未成年による認証に関する規定 CPS(28p) 1 発行証明書の内容・用法の規定 0+ CAcert Office と協力する場合、IR 資料や景品が多数用意さ その他 れる 表4 CAcert イベント開催に必要な資料 多人数を相手にあまり時間を取らずに説明・認証をするため、CCA(CAcert Community Agreement) の印刷・配 布や書類不備の防止のための確認員の準備が成功のキモになるようです。日本で開催する場合は、説明会の形式を 取って、各座席に一部ずつ置いておき、解説の進行と共に記入して貰うような形がよいのではないでしょうか。 13.5.2 当日の進行手順(案) 具体的な進行方法については特に案内が見当たらなかったため、開催未経験者ですが進行案をここに書き出してお きます。 1. まず、クラスルーム形式で CAcert および発生する義務・責任の説明を行う。入室時に各自に 3-5 枚*31 CAP Form を渡し、説明中に署名以外は全部記入してもらう。 2. 次に、Assurer と Member(予定者) で横並びに列を組んで、以下の図の通り Member にはカニ歩きをしてもら いながら認証をする。 3. 認証で新たな Assurer が生まれたら、Experience Point 獲得のためできるだけ Assurance 側に回ってもらう。 *31 その場にいる Assurer のランクや人数による 52 図6 CAcert サイン会の進行案 以上の進行で Assurer の数を早く増やすことができます。 13.6 CAcert の主要資料と組織構成 CAcert Wiki などを読んでも資料が大量にあって大変、しかも組織構成も訳がわからなかった、という方もいるの ではないかと思います(←自分のこと)。これは法的に監査を受け、商用の証明局並みの信頼度を獲得して普及を図る というゴールのために整備を重ねてそうなってきたのですが、理解しやすくなるように CAcert の主要ポリシ・資料 の関係図と位置付け、また組織構成をまとめてみました。 まずは主要文書の一覧から。なお、公式文書(組織内の文書として法的に有効なもの)はすべて COD (CAcert Official Document) というコード番号が振られています。 53 文書番号 COD1 タイトル(略称) 状態 内容 Policy on Policy (PoP) POLICY ポリシ策定に置ける IETF 風のコンセンサス ベースの運営方針およびドキュメント状態の管 理方法を定める COD2 Configuration-Control DRAFT 監査対象となる DOC/HW/SW またはそれらへ Specification(CCS) COD3 CAcert Official Docu- のポインタを定める 破棄予定 ドキュメント形式を定める予定だったが、不要 ments Policy (COD) COD4 Non-Related Persons – として破棄予定 破棄済 外部の非メンバとの関係を規定する文書だっ Disclaimer and Licence たが、COD14(Root Distribution License) にて (NRP-DaL) ルート証明書の配布ライセンスを別途定めたの で破棄された COD5 Privacy Policy (PP) POLICY サイトおよび証明書の利用においての個人情報 の扱いを規定する COD6 Certification Practice DRAFT 認証局および証明書の提供機能・管理方針・保証 Statement (CPS) COD7 Dispute Resolution 範囲など全側面に渡る運営方針を規定する POLICY CAcert の運営およびメンバ間において発生する Policy (DRP) COD8 Security Policy (SP) 各種の係争に関する裁定方法を定める DRAFT システムおよび鍵の管理システムが耐障害性・安 全性・可用性の各面で満たすべき事項を定める COD9 CAcert Community CAcert メンバーとして認証を受ける際に法的な 有効 Agreement (CCA) 束縛を行うための合意書 COD10 欠番 NA COD11 Oranisation Assurance POLICY 組織体が CAcert 認証を受けるにあたって必要 Policy(OAP) な手順と要件を定める COD12 欠番 NA COD13 Assurance Policy (AP) POLICY 認証の保証範囲、ポイントの付与基準、留意事 項など認証活動の全範囲を規定する COD14 Root Distribution Li- DRAFT CAcert のルート証明書の配布ライセンスを規定 cense (RDL) - Assurer Handbook する 有効 認証手順および実施要件の実務解説 各文書は WiP(Work in Progress - 策定中)、DRAFT(草案段階)、POLICY(正式ポリシ)の三段階を経て策定 されます。ちなみに、今年(2010 年)はすべての文書が出揃い、CAcert の最終ゴールである証明局としての法的監 査への準備が大きく進んだ年でした。 また、上記文書の中でも Member/Assurer の活動に特に密接なものを抜き出して関係を図示すると、以下の様にな ります: 54 図7 CAcert の主要ドキュメントの関係 各種文書では COD[0-9]+ や PoP/CCS/CCA/PP/DRL/... のような略称が頻繁に使われており初めて読むときは 混乱してしまいがちです。まずは、図中の DRP(調停規則)/CCS(証明書運用規定)/CCA(会則)/Handbook(実務 解説書)を押さえておくのがよいでしょう。 それでは次は組織構成です。問い合わせ先が見えにくいためまとめたのですが、実際に図にするとそう複雑でもな く、協同組合の CAcert Inc. を母体として、組織的な代表は通常組合員から選出・任命し、運営はコミュニティと共 同という形態になっています。 55 図 8 CAcert の組織構成(REF: http://wiki.cacert.org/Officers) なお、連絡を取る場合は CAcert Wiki で該当するオフィス(担当チーム)を探す、というのが「正しい」方法です が、情報が散らばっていたりして判断できないこともあるので、 とにかく [email protected] に連絡して、振り分けしてもらう というのがよいでしょう。この ML はトリアージ役の人がウォッチしている(ことになっている)ので、適切な所に 誘導して貰えるはずです。 13.7 まとめ CAcert は組織も文書も、本格的な証明機関を目指しているだけあってかなり複雑になっていますが、利用するだ けであればオンライン登録ですぐ証明書の発行を行えるので手軽に使うことができます。 これまでは欧州を中心*32 に展開してきているため日本ではそもそも Assurer が少ない状況ですが、CAcert も世界 巡業をするなど徐々に展開を図っているようです。あなたも CAcert に参加してみませんか? 13.8 おまけ この文書のために CAcert について調べなおしていたら、 1. Using Secure DNS to Associate Certificates with Domain Names For TLS https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ 2. 資料 - DNS に関わる技術動向 - KIDNS (Keys in DNS) *32 CAcert Inc. は豪州ですが、サーバの実体や活動は欧州が中心 56 http://dnsops.jp/bof/20101125/201011-DNSOPS-KIDNSv5.pdf というものを芋蔓式に見つけました。 要はアクセス先から証明書が送られてきたら、アクセス先ドメインの CERT/TLSA レコードを引いて、そちらか ら得られた証明書(またはそのハッシュ)で検証する仕組みや、同様の手法を SSH/PGP に適用する仕組みになりま す*33 。これが普及したらドメインが絡むものについては、現行のルート CA からの信頼の階層という枠組み自体が不 要になります。 実は 10 年近く前から検討されていたものの、最近ようやく DNSSEC が普及し始めた副産物として実用になってき たということですが、こういうものもあるということで、紹介しておきます。 *33 実は GnuPG はすでに対応しているそうです・ ・ ・知らなかった 57 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 14 CACert Assurance 山田 泰資 先月の CAcert 報告に引き続き、今回は CAcert の assurance 会*34 を行うので、その手順をまとめました。 また、手順について cacert.org の ML で質問していたところ、色々と話が転がって、3/4-5 のオープンソースカン ファレンス(OSC2011 Tokyo/Spring @ 早大)で、関係者が来日の上、CAcert の公式イベントとして CAcert ATE (Assurer Training Event) を開催できることになりました。日本初となります。これについても報告&協力募集し ます。 14.1 今日の手順 今日は練習を兼ねたミニサイン会を行います。必要な資材は用意してあるので、今日参加された方は政府発行の身 分証明書があり、cacert.org にアカウントがあればポイントを受けられます。 以下、手順: 1. 認証を受けたい方は、CAP Form に以下の内容をまず記入して下さい (a)表面は、署名および Assurer 用フィールド以外の各欄 に記入。名前や誕生日はローマ字と西暦で (b)裏面は、白紙部分に名前(漢字&カタカナ)と和暦での誕生日を補記として記入*35 2. Assurer は、以下の確認を行って下さい (a)CCA(CAcert Community Agreement) *36 に同意することの口頭確認、および、その旨のチェックボック スにチェックがあること (b)CAP Form の内容がすべて記入されており、また、提示された身分証明書の通りであること (c)身分証明書が真正であり、内容が以下を満たすこと*37 i. 誕生日記載の政府発行の物が1つはあること ii. 写真確認できるものが1つはあること 3. 最後に、CAP Form に目の前で署名をし、そのまま Assurer に渡して別れて下さい。署名がないと無効 です! 4. Assurer は、以下の追加作業を行って下さい (a)CAP Form に Assurer として署名し、それを最低 7 年間保管する (b)CAP Form 記載のメールアドレスを使って http://cacert.org で検索し、各人にポイントを付与する ポイントが 100pt を超えた方、超えそうな方は https://cats.cacert.org/ のオンライン試験を通しておくと、 100pt 以上になった時点から他の人を認証できるようになります。なお、アクセスには CAcert 発行のクライアント *34 認証会?サイン会?もう GPG と合わせてサイン会でいいか? これは来る OSC2011 で外国の方に認証してもらうための手順として策定中の方法です *36 CAcert に参加するにあたっての遵守事項 *37 可能ならば紫外灯などでの偽造チェックや、他の証明書(政府・民間発行は問わない)での追加確認をします *35 58 証明書が必要です。 14.2 CAcert@OSC2011 の計画 元々OSC2011 の Debian 枠の空き時間で GPG キーサイン兼 CAcert サイン会を企画していましたが、冒頭の通り cacert.org の方より打診があり、 日本初の CAcert 公式トレーニングイベント(ATE Tokyo) を開催できることになりました。 ATE(Assurance Training Event) というのは通常のサイン会とは若干異なり、主に Assurer になる・なれる人を対 象にした、上位 Assurer 養成(& CAcert の信頼性向上)のためのサイン会を兼ねたトレーニングイベントです。 たまたま期間中に来日する cacert.org の方(Peter Yuill 氏)がおり、OSC2011 の枠も別途確保できたため、日本 での CAcert 立ち上げの好機として緊急で開催決定となりました。 検討中の日程は以下の通りです: 1. 3/5 昼に OSC2011 の正式セッションとしてトレーニング講座を実施する(サインも残り時間やブースで実施) 2. その上で、3/5 夕刻から追加サイン会を実施する。実施場所・時間は以下の2案で検討中 (a)近隣の会議スペースや会場の空きスペースでサイン会をする (b)飲み屋やレストランのスペースを借りて、その中でサイン会をする OSC2011 は 17:00 に終了なので、サイン会は前者なら 17:00-19:00、後者なら 18:00-エンドレス (酔っ払うまで) で考えています。飲み会内開催案は 「酔っ払いそうだが大丈夫か?」「大丈夫だ、問題ない」*38 と、先にサインをするなど手順を工夫すれば、場所や時間の確保問題をクリアする案としてよいかもという事です (ドイツの ATE でもやってみるとか)。 なお、準備のため、特に運営やサインに協力して下さる方を絶賛大募集中です。現在の準備状況は以下の通り: 必要なもの 当日参加できる Assurer の方 当日参加できる運営の方 場外会場の確保 事前告知&申込ページの用意 CAP Form や CCA などの紙資料 ATE プレゼンや CCA の翻訳 準備状況 未調整(来場者に 100pt 渡せるとベスト) 未調整(Assurer 担当と別に、CAP Form 確認や引率に数名) 未了(隣接の区のスポーツセンタの優先権がある新宿区の人求む) 未了(wiki.cacert.org で行う?atnd 等を使える?) 準備可能(各 100 部程度なら市の印刷機で激安) 未了(これが次の山か?頑張ります・ ・ ・) 案内チラシ(場所案内など) 未了(内容が未作成。印刷は可能) ブラックライト(Assurer 人数分) 未了(製作計画中) プリンタ(紙資料印刷用) 準備 OK(持って行けます) プロジェクタ(場外でプレゼンの場合) 準備 OK(持って行けます) 終了後レポート 未了(実施レポートを cacert.org に出すまでが公式イベント、らしい。 これはやります) なお、開催規模ですが、CAcert の方には、「Assurer または 100pt 近い Assurer 見込み」の状態の ATE 参加者は 10 名内外、また、その中で 150pt 達成済みの Experienced Assurer は数名だろうという見込みを伝えています。 *38 意訳 59 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 15 月刊 PPC64 ポーティング 2011 年 04 月, 05 月 山本 浩之 15.1 2011 年 04 月編 ppc64 porting は、2005 年頃に amd64 porting に貢献した Andreas Jochens によって alioth を使って行われて いたのですが、ppc64 は amd64 と比較してネイティブサポートのメリットがそれほど大きくないとの結論に達し、 2007 年頃、一度捨てられたプロジェクトです。 メリットが少ないとの結論に達したのには、 • PowerPC32 から PowerPC64 へは、amd64 と違い、レジスタ数が変わっていない • PowerPC の命令は、PowerPC32 も PowerPC64 も、共に 32 bit の固定長のままである という理由があります。 特に問題になったのが 32 bit の固定長命令で、以下のようになっています。 -------------------------------------------------------------------------| opcode | src register | dest register | immediate value | | 6 bits | 5 bits | 5 bits | 16 bits | -------------------------------------------------------------------------- この中で即値が使えるのは「immediate value」である下位 16 bit だけです。 そのため、PowerPC32 では 32 bit の即値をレジスタにロードするためには、 16 bit 送る → 16 bit 送る の 2 つの命令だけでした。 しかし PowerPC64 では、64 bit GPR の上位ワードに直接ロードするための命令が無いため、64 bit の即値をレ ジスタにロードするのに、 下位に 16 bit 送る → 下位に 16 bit 送る → 下位ワードを上位ワードにシフト → 下位に 16 bit 送る → 下位に 16 bit 送る と、少なくとも 5 命令が必要です。 このため、通常だと、パフォーマンスが低くなることがあっても高くなることは無いのではないか、ということに なり、プロジェクトは破棄されました。まあこれを趣味で拾ったのが私でして、なんとか根本的にパフォーマンスを 上げていかなければならないという宿命を背負っています。 現在のところ、64 bit を使える CPU は PowerPC 970、POWER4、POWER5、POWER6、POWER7、Cell、 PX などがあります。32 bit 専用の CPU より新しいため、POWER4 と POWER5 を除き、全て VMX (IBM & モトローラ) または AltiVec (モトローラ) と言うベクトル演算ユニットを備えており、それぞれを動かす命令は、同 一な VMX 命令セットとして、完全に互換性があります。 60 さらに POWER6、POWER7、Cell、PX では VMX を拡張し、レジスタを 128 本とした VMX-128 ユニットが 搭載されていますが、現在の gcc では、VMX-128 ユニットを使いこなすオプションはまだありません。 着手してかれこれ 1 年なんですが、とりあえず VMX ユニットを持たない POWER4 と POWER5 は、既に公式 にある powerpc port を使ってもらうとして、ppc64 port ではこの VMX 命令をサポートする方向で、パフォーマ ンスが上がらないかと試しています。 ちなみに VMX 命令は、powerpcspe port でサポートされている、SPE 命令と全く同じところにデザインされて いて、完全に排他的になっています。 15.2 2011 年 05 月編 週末ハッカーなおいらですが、今月の進捗状況を報告します。 今月は perl 2.12 投入、eglibc 2.13 投入、gcc-4.6 のデフォルト化などと、公式でも FTBFS 続出な月でした。し かしそれにもめげず、debian-ports への応募の前段階として、buildd 環境に最低限必要なパッケージ群を公開し始め ました。 http://yama.fam.cx/debian/dists/unreleased/main/binary-ppc64 でも、まだ全ては揃っていません。足りないのは以下のパッケージです。 表5 パッケージ名 ppc64 で問題があるパッケージ(2011/05 の時点) 問題 aptitude build-deps なパッケージが FTBFS でビルドできていない corutils どうやら公式でも FTBFS らしいです。パッチが一ヶ月以上放置されて います。 debconf pam all なパッケージなんですが、ppc64 では FTBFS でした。 なんのパッケージが悪さをしているのかはっきりとしていませんが、あ る時点から Segment fault するようなパッケージしかビルドできなくな りました。 また、先月の宿題、 「nbench で、ppc64 port を powerpc port と比較してみよ」ですが、以下の結果になりました。 61 ppc64 port: ----BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:-----------NUMERIC SORT : 762.72 : 19.56 : 6.42 STRING SORT : 162.35 : 72.54 : 11.23 BITFIELD : 1.4628e+08 : 25.09 : 5.24 FP EMULATION : 165.36 : 79.35 : 18.31 FOURIER : 12004 : 13.65 : 7.67 ASSIGNMENT : 16.388 : 62.36 : 16.17 IDEA : 2479 : 37.92 : 11.26 HUFFMAN : 1095.6 : 30.38 : 9.70 NEURAL NET : 25.628 : 41.17 : 17.32 LU DECOMPOSITION : 806.48 : 41.78 : 30.17 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 41.242 FLOATING-POINT INDEX: 28.635 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : Dual L2 Cache : OS : Linux 2.6.38-2-powerpc64 C compiler : gcc version 4.6.1 20110428 (prerelease) (Debian 4.6.0-6) libc : libc-2.13.so MEMORY INDEX : 9.837 INTEGER INDEX : 10.646 FLOATING-POINT INDEX: 15.882 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. ----powerpc port: ----BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:-----------NUMERIC SORT : 781.12 : 20.03 : 6.58 STRING SORT : 99.52 : 44.47 : 6.88 BITFIELD : 1.8306e+08 : 31.40 : 6.56 FP EMULATION : 168.36 : 80.79 : 18.64 FOURIER : 11881 : 13.51 : 7.59 ASSIGNMENT : 17.011 : 64.73 : 16.79 IDEA : 3354.6 : 51.31 : 15.23 HUFFMAN : 1149 : 31.86 : 10.17 NEURAL NET : 23.981 : 38.52 : 16.20 LU DECOMPOSITION : 731 : 37.87 : 27.35 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 42.220 FLOATING-POINT INDEX: 27.013 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : Dual L2 Cache : OS : Linux 2.6.38-1-powerpc64 C compiler : gcc version 4.5.2 (Debian 4.5.2-7) libc : libc-2.11.2.so MEMORY INDEX : 9.118 INTEGER INDEX : 11.742 FLOATING-POINT INDEX: 14.982 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. ----- 概要を言うと、ppc64 port は powerpc port と比べ、誤差範囲程度で同じです。ただし、 「STRING SORT」で飛 躍的に良くなり、「IDEA」で若干悪く、「LU DECOMPOSITION」で若干良くなっている結果となっています。 また、VMX 命令サポートの効果ですが、どうやら nbench は CPU 性能を主に計測するベンチマークソフトらし く、各アプリケーション自体のベンチマークは測定できませんでした。 62 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 16 Debian/m68k 開発 岩松 信洋 Debian/m68k 開発環境を構築する機会があったのでまとめてみました。 16.1 m68k とは? m68k とはなにか?Motorola 680x0/m68000/68000 の事。省略して m68k。32bit で CISC。エンディアンはビッ グ。世界中で未だに人気にある CPU の一つ。今はフリースケール・セミコンダクタによって、Coldfire という名前 で製造および販売されています。なので今は 68k と言うことが多いです(モトローラじゃないから)。Apple 社の Macintosh SE やシャープの X68000、Palm Pilot の CPU として活躍していました。もちろん Linux でもサポート されており、Debian では hamm から正式にサポートアーキテクチャとして採用されましたが、etch から脱落しま した。Debian に最初にポーティングされ、最初に脱落したアーキテクチャということで覚えておくと良いでしょう。 16.2 Debian/m68k の現状 etch から脱落した後も開発は続けられており、今は debian-ports.org 表 6 m68k を使った主な機器 上で開発しています。1年前に開発が停滞しましたが、Thorsten Glaser メーカ ハードウェア 氏*39 が拾い上げ、数名の開発者と共に楽しく開発を続けています。 ATARI Atari Falcon ポーティング開始当時は Macintosh や ATARI 社の Amiga 上で開発 HP HP 9000 Series 200 していましたが、既にこれらのハードウェアは入手が難しくなっている SUN Sun-1 ので主にエミュレータを使って開発しています。Debian の bootstrap DEC VAXstation 100 が行える程度のパッケージは常に最新に近い状態が維持されているの SGI RIS 1000 SEGA メガドライブ SNK ネオジオ で、X や GUI を使わない環境程度ならすぐに構築可能です。 ち な み に 、Debian に 再 度 取 り 込 む こ と は 目 標 に し て お ら ず、 linux/m68k(68k) の開発用として生きる道を選んだようです。もし Debian で クロスコンパイルやエミュレータによる開発が許可されるよ うになったら、復活するかもしれません。 開発議論は ML(http://lists.debian.org/debian-68k/)と IRC(debian-68k@oftc)で行われています。 16.3 なぜ m68k に手を出してしまったのか? 先月、Ruby のコミッタになってしまったので、他になにかか自分でもできることないかなと思ってバグを見てい たら、Ruby1.9.1 パッケージのバグ #611691 (m68k が FTBFS)を見つけたのが事の始まりです。 *39 MirOS の開発者。OpenWRT の開発者でもある。 63 16.4 開発環境設定方法 先にも説明したように、実機での開発は行われておらずエミュレータを使って開発が行われています。エミュレー タといえば、ARM や SH などが使える qemu が有名ですが、qemu の 68k は不具合が多いので、Debian では ARAnyM *40 という 68k エミュレータを使って開発しています。ここでは ARAnyM を使った開発環境の構築方法 を説明します。 16.4.1 ARAnyM とは ARAnyM(Atari Running on Any Machine) は 68040 + MMU + FPU(68882) を実装したエミュレータです。 全ての 68k をサポートしているわけではなく、人気のあった CPU、特に Atari のハードウェアがサポートしていた CPU をサポートしています。グラフィックス、ディスクドライブ、CDROM、ネットワークもサポートしており、特 徴として、OpenGL を使った高速なグラフィックと 4GB のメモリを扱えることがあります。 16.4.2 ホスト側の設定 まず、ARAnyM をインストールします。Debian パッケージになっているので apt で簡単にインストールできま す。また、後で必要になるパッケージもインストールしておきます。 $ sudo apt-get install aranym p7zip Debian m68k の開発に必要なカーネル、ユーザランドイメージのダウンロードします。 カーネルは linux-image-2.6.38-2-atari カーネルパッケージ*41 を展開した vmlinuz を使います。 $ wget http://debian.nctu.edu.tw/debian-ports/pool-m68k/main/l/linux-2.6/linux-image-2.6.38-2-atari_2.6.38-5_m68k.deb $ ar -x linux-image-2.6.38-2-atari_2.6.38-5_m68k.deb $ tar -xzf data.tar.gz $ ls boot/vmlinuz-2.6.38-2-atari -rw-r--r-- 1 iwamatsu iwamatsu 1767311 2011-05-12 00:48 boot/vmlinuz-2.6.38-2-atari 次のユーザランドイメージをダウンロードします。build-essentail がインストールされたイメージが既にあるので、 これを活用します。 $ wget http://people.debian.org/~smarenka/aranym/sid/disk.tar.7z $ 7zr x -so disk.tar.7z | tar xvf $ ls -l disk.img -rw-r--r-- 1 iwamatsu iwamatsu 10737377280 2011-05-18 00:37 disk.img 次にネットワークを設定します。以下で説明するネットワークは図 9 のようなネットワーク構成になるようにして います。 図9 ARAnyM のネットワーク構成図 今回の ARAnyM 環境では tun を使うので uml-utilities パッケージをインストールします。 *40 *41 http://aranym.org/ http://packages.debian.org/search?keywords=linux-image-2.6.38-2-atari 64 $ sudo apt-get install uml-utilities そして、tun および ARAnyM を使うユーザを uml-net に追加します。 $ sudo gpasswd -a iwamatsu uml-net ホスト側の ネットワークを以下のように設定します。 $ cat /etc/network/interfaces auto tap0 iface tap0 inet static address 192.168.2.1 pointopoint 192.168.2.2 netmask 255.255.255.255 tunctl_user iwamatsu up iptables -t nat -A POSTROUTING -s 192.168.2.2 -j MASQUERADE down iptables -t nat -D POSTROUTING -s 192.168.2.2 -j MASQUERADE フォワーディングを有効にして、tap0 ネットワークデバイスを上げます。 $ sudo sh -c ’echo 1 > /proc/sys/net/ipv4/ip_forward’ $ sudo ifup tap0 次に ARAnyM の設定を行います。ARAnyM は 特に指定しない場合には ˜/.aranym/config を読み込みます。 $ cat aranym.config [GLOBAL] FastRAM = 768 # メモリサイズ。単位は MB。 Floppy = TOS = EmuTOS = AutoGrabMouse = No GMTime = Yes [LILO] # Linux カーネルイメージ Kernel = vmlinuz-2.6.38-2-atari # these Args for normal X operation # カーネルコマンドライン Args = root=/dev/hda1 console=tty debug=par # these Args for headless #Args = root=/dev/hda1 console=nfcon # ネットワーク設定 [ETH0] Type = bridge Tunnel = tap0 # エミュレータで使う仮想ネットワークデバイスの Mac アドレス Mac = XX:XX:XX:XX:XX:XX [STARTUP] GrabMouse = No Debugger = No [IDE0] Present = Yes IsCDROM = No ByteSwap = No ReadOnly = No # ディスクイメージ Path = disk.img Cylinders = 20805 Heads = 16 SectorsPerTrack = 63 ModelName = Master [VIDEO] FullScreen = No BootColorDepth = 8 VidelRefresh = 1 以上で設定は終わりなので、ARAnyM を使って、Debian OS を立ち上げます。 $ aranym-mmu -l -c aranym.config $ uname -a Linux aranym 2.6.38-2-atari #1 Mon May 9 16:39:31 UTC 2011 m68k GNU/Linux $ cat /proc/cpuinfo CPU:68040 MMU:68040 FPU:68040 Clocking:73.5MHz BogoMips:49.04 Calibration:245248 loops 65 16.4.3 ターゲットでの設定 Debian OS が立ち上がったら、root ユーザでログイン(パスワードは無し)し、ネットワーク設定を行います。起 動時に ARAnyM の仮想ネットワークデバイス(nfeth:nat-feature) を eth0 として認識します。認識されている場合 には ARAnyM の設定した MAC アドレスで eth0 が認識されています。 # dmesg | grep eth0 eth0: nfeth addr:192.168.0.1 (192.168.0.2) HWaddr:XX:XX:XX:XX:XX:XX もしホスト側の設定が間違っている場合、eth0 が存在しない状態になります。このような場合には、ホスト側の設 定を見直してください。 eth0 が認識されているのなら、/etc/network/interfaces と /etc/resolv.conf を以下のように変更します。 # cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.2.2 netmask 255.255.255.0 gateway 192.168.2.1 # cat /etc/resolv.conf nameserver 192.168.3.1 設定が終わったら、各デバイスを上げネットワークがつながることを確認できれば、apt を使って最新の環境にアッ プデートし開発環境環境は完成です。 # # # # # # # # ifup lo ifup eth0 ping 192.168.2.1 # gateway へのチェック ping 192.168.3.1 # DNS へのチェック apt-get update # apt-get update apt-get install debian-ports-archive-keyring apt-get update apt-get dist-upgrade 16.4.4 その他開発環境 エミュレータを使って開発できるのはすごく良いことなのですが、エミュレータだけでは遅いのでクロスツール チェインが欲しくなります。Debian でのクロス toolchain は emdebian プロジェクトが提供していますが、m68k の ものは提供されていません。しかし、amd64 バイナリは Thorsten Glaser 氏が以下の apt-line で提供しています。 deb http://www.freewrt.org/~tg/debs68k/ cross main 16.5 ARAnyM 上での開発 動作しているのが エミュレータ上というだけで通常の開発と変わりません。cowbuilder も使えるので、遅いとい う以外には問題はないでしょう。開発速度を上げたい場合には、distcc/icecc/ccache などを駆使すれば快適な開発が できるようになります。このあたりの話はまた今度。 16.6 Ruby の FTBFS バグはどうなったのか? Debian/m68k の開発環境は構築できましたが、Ruby のバグはどうなったのかというと、http://redmine. ruby-lang.org/issues/4745 としてバグレポートし、r31646 でコミットしておきました。 参考文献 [1] wiki.debian.org の m68k の項目,https://wiki.debian.org/M68k 66 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 17 バグ報告はバグのためだけじゃな いよ のがた じゅん 17.1 はじめに Debian を使っている時、なにか不具合を見つけたとします。そんな時、あなたはどういう行動をとるでしょうか。 Sid を使っていてよくあるケースは、パッケージのアップデート直後に以前と違う動きをしてバグに気がつくとい うケースでしょう。 そんな時、/var/log/apt/term.log や/var/log/aptitude のログを見て、アップデートしたパッケージにアタ リをつけ、Debian バグ管理システム (BTS:Bug Tracking System)*42 にそのパッケージのバグ情報を見に行きます。 すると、あなたの遭遇したバグはすでに報告されていて、結局何もすることなかった。で終わる人も多いかと思い ます。 そんなあなたのために、今回は不具合報告以外に焦点を当てたバグ報告について書いてみたいと思います。 17.2 おさらいも兼ねてバグ報告の基本 バグ報告以外の BTS の使い方、といっても基本的なバグ報告について知らなければ応用もできないので、おさら いも兼ねてバグ報告の基本について述べます。 Debian の BTS は、debbugs と呼ばれる Debian に特化したバグ報告システムを使っています。debbugs はメール ベースの BTS で、[email protected] 宛にメールを送ることでバグを登録できます。 メールの送り方は、メールの Subject にバグの内容についての要約を書きます。メール本文には BTS として受け 付けてもらうための擬似ヘッダを書きます。書き方は本文 1 行目にパッケージ名、2 行目にパッケージのバージョン を書きます。必要に応じて重要度とタグを書き、その後にバグの内容を書いていきます。 Subject: バグについて ---Package: <パッケージ名> Version: <パッケージバージョン> Severity: <重要度 critical|grave|serious|important|normal|minor|wishlist> Tags: <タグ> 以下バグの内容を書く 17.2.1 reportbug/reportbug-ng/debian-el を使う Debian のバグ報告の基本は以上ですが、バグ報告のたびに毎回手で書くのは非常に面倒です。 reportbug や reportbu-ng を使うと定型化された部分は自動で埋めて、バグ修正に必要な情報も付記してくれるの で、バグ報告にはこれらを利用しましょう。 *42 http://bugs.debian.org/ 67 reportbug を初めて使う場合はターミナルからは reportbug、GUI からは [メニュー] → [システムツール] → [reportbug] を実行すると、reportbug の初期設定が始まります。 詳しい初期設定の方法については「あんどきゅめんてっどでびあん 2009 年冬号」の「GUI がついて格好良くなっ た reportbug を使ってみよう」[9] に書いてあるので参考にしてください。 reportbug-ng を使う場合は、普段使うメーラー (MUA) と連携して利用するので、reportbug-ng のメニューバー [Edit] の Mail Client で MUA を確認しておきます。 emacs の人は debian-el パッケージを入れておいて、M-x debian-bug でいいと思います。 17.2.2 reportbug を使ったバグ報告の仕方 reportbug を使ってバグを報告するには、reportbug をそのまま起動するとバグ報告をしたいパッケージ名を尋ね られるので入力するか、reportbug にパッケージ名をつけて起動します。 $ reportbug (パッケージ名) パッケージ名を入力すると、そのパッケージの既存のバグ一覧が表示されるので、目を通して、同じものがなけれ ばバグ報告に進みます。 reportbug の一連の流れも「あんどきゅめんてっどでびあん 2009 年冬号」の「GUI がついて格好良くなった reportbug を使ってみよう」[9] に書いてあるので参考にしてください。 17.3 Severity(バグの重要度) と Tags(タグ) バグ報告の基本で擬似ヘッダに書く Severity(バグの重要度) と Tags(タグ) について触れましたが、ここでは 「Debian – Debian BTS ― 開発者情報」*43 から引用して、簡単に説明します。 17.3.1 Severity(バグの重要度) バグの重要度は critical(致命的) から、wishlist(要望) までの 7 段階に分かれています。通常使うのは normal が多 いと思います。 critical (致命的) システム上の関係のないソフトウェア (またはシステム全体) を破壊する、重大なデータの欠落を 引き起こす、または、そのパッケージをインストールしたシステム上でセキュリティホールが生じる場合。 grave (重大) 問題のあるパッケージが使用できない、またはほとんど使用できない。またはデータの欠落を引き起 こす、そのパッケージを使用するユーザのアカウントにアクセスを許してしまうセキュリティホールが生じる 場合。 serious (深刻) Debian ポリシーに対して見すごせない違反がある (大まかに言うと、「must」や「required」の要件 に違反している)、またはパッケージメンテナあるいはリリースマネージャの意見としてそのパッケージがリ リースに適していないと判断された場合。 important (重要) バグがパッケージの有用性を大きく損なっている場合 (ただし、誰にとっても完全に使用できなく なっている場合を除く)。 normal (通常) デフォルト値。通常のバグ。 minor (軽度) 問題がパッケージの利用に影響しない、かつ修正はたいした事がないと思われる場合。 wishlist (要望) 将来的な要望、主に設計上の理由により修正が非常に困難なバグ。 17.3.2 Tags(バグのタグ) バグ報告には決められたタグをつけることができます。 とりあえず抜き書きをしてみましたが、個人的にはパッチをつけたときに patch を使ったことがあるような気がし *43 http://www.debian.org/Bugs/Developer 68 ますが、そんなに意識して使ったことがないです。 patch (パッチ) バグ報告に、バグを修正するためのパッチや簡単な手順が含まれています。パッチがあってもバグを 適切に解決できない場合や別の問題を生じる場合は、 このタグは使うべきではありません。 security (セキュリティ) このバグはパッケージのセキュリティ問題を説明します (例: アクセスされてはいけない データへのアクセスを許可する不正な許可属性がある、 やれるべきではない方法でシステムを制御できるバッ ファオーバーフローがある、 修正すべき DoS 攻撃の穴がある、等)。ほとんどのセキュリティバグは、critical (致命的) や grave (重大) の severity (重要度) も設定すべきです。 upstream (上流) このバグは、パッケージの上流の部分に影響します。 l10n このバグは、パッケージの地域化に関するものです。 sid/squeeze/lenny ディストリビューションに関するタグです。 17.4 不具合報告ではないバグ報告とは バグ報告についてひと通り書きましたが、タイトルにもあるように Debian はパッケージに由来する不具合のほか に、Debian に関連する問題があれば、すべて BTS に登録し管理します。 話だけではわかりにくいですが、reportbug を起動してパッケージ名の代わりに「other」と入力すると、このよう に登録するカテゴリ一覧が表示されます。 1 2 3 4 5 6 7 base bugs.debian.org buildd.debian.org buildd.emdebian.org cdimage.debian.org cdrom debian-i18n 8 debian-maintainers 9 debian-policy 10 ftp.debian.org 11 general 12 13 14 15 16 17 18 19 20 21 installation-reports listarchives lists.debian.org mirrors nm.debian.org press project qa.debian.org release-notes release.debian.org 22 23 24 25 security-tracker security.debian.org snapshot.debian.org spam 26 27 28 29 30 tech-ctte upgrade-reports wiki.debian.org wnpp www.debian.org General bugs in the base system The bug tracking system, @bugs.debian.org Problems and requests related to the Debian Buildds Problems related to building packages for Emdebian CD Image issues Problems with installation from CD-ROMs Requests regarding Internationalization (i18n) of the distribution Problems and requests related to Debian Maintainers Proposed changes in the Debian policy documentation Problems with the FTP site and Package removal requests General problems (e.g., that many manpages are mode 755) Problems with installing Debian Problems with the WWW mailing list archives The mailing lists, debian-*@lists.debian.org. Problems with Debian archive mirrors. New Maintainer process and nm.debian.org website Press release issues Problems related to project administration Problems related to the quality assurance group Problems with the release notes Requests regarding Debian releases and release team tools The Debian Security Bug Tracker Problems with the security updates server Issues with the snapshot.debian.org service Spam (reassign spam to here so we can complain about it) Issues to be referred to the technical committee Reports of successful and unsucessful upgrades Problems with the Debian wiki Work-Needing and Prospective Packages list Problems with the WWW site (including other *.debian.org sites) インストーラやプレスリリース、サイトについての問題といった多岐に渡る問題について扱っていることがわかる と思います。 17.5 wishlist を使う もうひとつ。不具合ではないバグ報告としては wishlist(要望) があります。 wishlist(要望) とは、パッケージに対しての要望がある場合に使用し、たとえばパッケージのソフトに対して何か機 能を追加してもらいたい場合や、アップストリームで新しいバージョンのソフトがリリースされたときに、バージョ ンアップをお願いする場合などに使われます。 wishlist の使い方は簡単で、バグの重要度 (severity) に wishlist を指定して通常のバグ報告をするだけです。 69 $ reportbug gpsbabel-gui (reportbug にパッケージ名をつけて起動します) Please briefly describe your problem (max. 100 characters allowed; you can elaborate in a moment). This will be the bug email subject, so write a concise summary of what is wrong with the package, for example, "fails to send email" or "does not start with -q option specified" (type Ctrl+c to exit). > Please include icon and desktop file. (要望の要約を書きます) reportbug にパッケージ名をつけて起動します。起動すると問題の要約を尋ねられるので要望の要約を書きます。 Rewriting subject to ’gpsbabel-gui: Please include icon and desktop file.’ Removing release critical severities, since running in ’novice’ mode. How would you rate the severity of this problem or report? 1 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. 2 normal a bug that does not undermine the usability of the whole package; for example, a problem with a particular option or menu item. 3 minor things like spelling mistakes and other minor cosmetic errors that do not affect the core functionality of the package. 4 wishlist suggestions and requests for new features. Please select a severity level: [normal] 4 (wishlist を指定します。) バグの重要度を尋ねられるので、4 番の wishlist を選びます。 Spawning sensible-editor... (エディタが起動します) Subject: gpsbabel-gui: Please include icon and desktop file. Package: gpsbabel-gui Version: 1.4.2-1 Severity: wishlist *** Please type your report below this line *** (ここに要望の内容を書きます) (以下略) 「*** Please type your report below this line ***」以下に要望を書き終えれば、通常のバグ報告と同じように [email protected] にメールを送るだけです。 17.6 パッケージ作成にまつわるバグ報告 パッケージ作成にまつわるバグ報告と書きましたが、「パッケージがないのにバグ報告とははなんぞや?」と思われ るかもしれません。 パッケージを作成するためには、 「こんなパッケージを作って欲しい」というパッケージ作成希望をバグ報告として 出すことからスタートします。 「不具合ではないバグ報告」の章を思い出すと、こういうセクションがあったと思います。 29 wnpp Work-Needing and Prospective Packages list この WNPP(Work-Needing and Prospective Packages) からパッケージ作成が始まります。 (と偉そうに書いていますが WNPP をしたことがないので、Debian – 作業が望まれるパッケージ: http: //www.debian.org/devel/wnpp/ に書いてあることをなぞっているだけです。何かあればツッコミをお願いし ます。) $ reportbug Please enter the name of the package in which you have found a problem, or type ’other’ to report a more general problem. > other reportbug を起動して「other」と入力します。 70 Please enter the name of the package in which you have found a problem, or choose one of these bug categories: 1 base General bugs in the base system (中略) 29 wnpp 30 www.debian.org Work-Needing and Prospective Packages list Problems with the WWW site (including other *.debian.org sites) Enter a package: 29 バグのカテゴリーを尋ねられるので 29 番の WNPP を選びます。 Are you sure you want to file a WNPP report? [y|N|q|?]? y 1 ITP 2 O 3 RFA 4 RFH 5 RFP This is an ‘Intent To Package’. Please submit a package description along with copyright and URL in such a report. The package has been ‘Orphaned’. It needs a new maintainer as soon as possible. This is a ‘Request for Adoption’. Due to lack of time, resources, interest or something similar, the current maintainer is asking for someone else to maintain this package. They will maintain it in the meantime, but perhaps not in the best possible way. In short: the package needs a new maintainer. This is a ‘Request For Help’. The current maintainer wants to continue to maintain this package, but they needs some help to do this, because their time is limited or the package is quite big and needs several maintainers. This is a ‘Request For Package’. You have found an interesting piece of software and would like someone else to maintain it for Debian. Please submit a package description along with copyright and URL in such a report. Choose the request type: 5 WNPP の中で何をするのか尋ねられます。 • ITP: パッケージを作成する (Intent To Package) • O: パッケージを手放す (Orphaned) • RFA: パッケージを引き取って欲しい (Request for Adoption) • RFH: パッケージの維持を手伝って欲しい (Request For Help) • RFP: パッケージをつくって欲しい (Request For Package) なので 5 の RFP を選びます。 Please enter the proposed package name: sahana-eden Checking status database... Please briefly describe this package; this should be an appropriate short description for the eventual package: > Disaster management system made from web2py パッケージの簡単な説明を書きます。書き終えるとエディタが起動します。 Spawning sensible-editor... Subject: RFP: sahana-eden -- Disaster Management System made by web2py Package: wnpp Severity: wishlist *** Please type your report below this line *** * Package name : Version : Upstream Author : * URL : * License : Programming Lang: Description : sahana-eden 0.5.3 Name <[email protected]> https://launchpad.net/sahana-eden MIT/X Python Disaster Management System made by web2py Sahana Eden is an Emergency Development Environment which allows the rapid deployment of customisable tools to support the 4 phases of the Emergency Management Cycle as well as Development & Environment projects. It is an example of an HFOSS project (Humanitarian FOSS) 書き終われば保存してエディタを終了します。 71 Report will be sent to "Debian Bug Tracking System" <[email protected]> Wrong line: Upstream Author : Name <[email protected]> ERROR: you have composed an ITP with fields unchanged from the template; this will NOT be submitted. You should edit all fields so they contain correct values for your ITP (e to edit) [E|q|?]? 適当に書いてると怒られてしまいました。ということで E で戻って書きなおして保存、[email protected] 宛に送れば RFP はおしまいです。 17.6.1 RFP を ITP にする この辺りになると自分でも未知の領域ですが、「作業が望まれるパッケージ」によると これをパッケージ化することにしたら、このプログラムが パッケージ化の作業中ことをほかの人に知らせ、さ らにあなたがそのバグの 所有者となるために、 バグレポートを「RFP」から「ITP」に改称します。それか ら ソフトウェアをパッケージ化し、アップロードして、そのパッケージが インストールされたらこのバグを 閉じます。 とのことなので、[email protected] 宛に「Debian BTS ― 制御サーバ」http://www.debian.org/ Bugs/server-control.ja.html を参照してコントロールメールを送ればよいのでしょうか。 owner (バグ番号) ! retitle (バグ番号) ITP: sahana-eden -- Disaster Management System made by web2py thanks 調べきれず終わってしまった…。 17.7 最後に 不具合報告だけではないバグ報告を書きましたが、いかがでしたでしょうか。あまり自分も使うことがない事をま とめたので大変でした。 参考文献 [1] Debian – Debian BTS - バグを報告する http://debian.org/Bugs/Reporting [2] Debian – 作業が望まれるパッケージ http://www.debian.org/devel/wnpp/ [3] Debian 開発者リファレンス「第 5 章 パッケージの取扱い方」http://www.jp.debian.org/doc/manuals/ developers-reference/pkgs.html#newpackage [4] 岩松伸洋「ITP の仕方からアップロードまでの流れ」(あんどきゅめんてっどでびあん 2005 年冬号) http: //tokyodebian.alioth.debian.org/pdf/debianmeetingresume2005-fuyu.pdf pp. 3 – 7 [5] や ま ね ひ で き「claim makes Debian better」(あ ん ど きゅめ ん てっど で び あ ん 2005 年 冬 号) http:// tokyodebian.alioth.debian.org/pdf/debianmeetingresume2005-fuyu.pdf pp. 26 – 29 [6] 上川純一「debbugs internal」(あんどきゅめんてっどでびあん 2005 年冬号) http://tokyodebian.alioth. debian.org/pdf/debianmeetingresume2005-fuyu.pdf pp. 31 – 38 [7] 木下達也「バグレポートから参加する Debian パッケージ開発」(あんどきゅめんてっどでびあん 2008 年夏号) http://tokyodebian.alioth.debian.org/pdf/debianmeetingresume2008-natsu.pdf pp. 76 – 78 [8] 藤 澤 徹「MC-MPI/GXP 公 式 パッケ ー ジ へ の 道 」(あ ん ど きゅめ ん てっど で び あ ん 2009 年 夏 号) http: //tokyodebian.alioth.debian.org/pdf/debianmeetingresume2009-natsu.pdf pp. 77 – 83 [9] のがたじゅん「GUI がついて格好良くなった reportbug を使ってみよう」(あんどきゅめんてっどでびあん 2009 年 冬号) http://tokyodebian.alioth.debian.org/pdf/debianmeetingresume2009-fuyu.pdf pp. 61 – 66 72 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 18 dpkg のおさらい 倉敷 悟 今となっては、APT やその他いろいろ綺麗で便利な GUI ツールのかげに隠れてすっかり存在感の薄れてしまった dpkg。ですが debian システムの根幹を支えてくれている屋台骨であることには何の変化もありません。 というわけで、今回は新年度特集として、誰でも知っている (べき) dpkg のおさらいをしてみようと思います。 18.1 普段使いの dpkg まずは文字通り、日常的に debian システムで作業をする上で dpkg コマンドを使う場面を振り返ってみましょう。 事前課題として皆さんそれぞれの利用シーンも整理してもらいましたが、やはりある程度パターンは定まってくるよ うです。 18.1.1 deb ファイルの操作 基本中の基本ですが、バイナリパッケージファイルそのものを操作するコマンドです。 「ダウンロードした *.deb ファイルをインストールしよう」という時は: dpkg -i <package filename> APT と違って依存関係をひっぱってくれたりはしないので、個人的には–ignore-depends= <package name >を 多用したりします。 「このパッケージファイルには何が入ってるんだろ?」という時は: dpkg --contents <package filename> 18.1.2 パッケージ DB の操作 インストールされてパッケージ DB に登録された情報を照会するコマンド達です。実際の使用頻度が一番高いのは このあたりでしょう。 「今どんなパッケージがインストールされてるんだっけ?」という時は: dpkg -l [<string>] 「このパッケージでインストールされるファイルは何だっけ?」という時は: dpkg -L <package name> 「このファイルはどのパッケージから来てるんだっけ?」という時は: dpkg -S <file path> 「新しい PC に今のと同じパッケージをまるっと引っ越そうかな」という時は: 73 dpkg --get-selections > tmpfile dpkg --clear-selections ; dpkg --set-selections < tmpfile –clear-selections は、set-selection ができる状態でのみ実行するようにしておいた方がいいでしょう。 18.1.3 設定ファイルなど そんなものの存在自体が初耳だ、という人がほとんどじゃないかという気もしますが、実は dpkg にも設定ファイ ルがあります。 /etc/dpkg/dpkg.cfg /etc/dpkg/dpkg.cfg.d ~/.dpkg.cfg 書式は簡単で、dpkg コマンドのコマンドラインオプションからダッシュを省いたものを書いておくだけです。毎回 こだわりの定番オプションを手打ちしている方は是非どうぞ。 ちなみに、手元の sid で自動登録されていた内容は次のような感じです。 no-debsig log /var/log/dpkg.log man dpkg して、どういう内容なのか見てみると、また新鮮な発見があるかもしれません。 18.2 パッケージの中身をのぞいてみる さて、dpkg のことをだいぶ思い出してきたところではないかと思います。引き続き、今度は操作対象となるバイ ナリパッケージの中身を少し眺めてみることにしましょう。 18.2.1 バイナリパッケージの中身 実は、deb パッケージは単なる ar 書庫ファイルだったりします。なので、 ar t <package filename> で書庫の中身を表示することができますし、同様に ar で中身を解凍して取り出すこともできます。出てくるファ イルはこんな感じです。 debian-binary data.tar.gz control.tar.gz この 3 つのファイル名はどんなパッケージでも同じです。それぞれ、次のような内容になっています。 debian-binary バイナリパッケージのバージョンが記載されている。現時点では 2.0 のはず data.tar.gz パッケージに含まれるファイルの実体をまとめたディレクトリツリー。これだけ取り出せば checkinstall あたりと同じかも control.tar.gz パッケージのメタ情報とパッケージ前後処理のスクリプトなど 18.2.2 メタ情報 data.tar.gz は明確なのでひとまず置いておくことにして、control.tar.gz の中身を見てみましょう。 debconf 関連 config templates post/pre 関連 preinst postinst prerm postrm パッケージ情報 control conffiles md5sum これらのファイルに記載されている情報は、下記の場所にそれぞれ適当に配置されます。 74 /var/lib/dpkg/info/ post/pre 関連、conffiles、debconf 関連などなど /var/lib/dpkg/status パッケージの導入ステータス 18.2.3 バイナリパッケージの分解と合成 先程 ar 書庫のことを書きましたが、実際にバイナリパッケージの中身をとりだしたい時は、別のコマンドで一度 に解凍した方がラクかもしれません。 dpkg-deb --control <package filename> [<target directory>] dpkg-deb --extract <package filename> [<target directory>] 指定した target directory (指定しなかった場合はカレントディレクトリ) に、それぞれパッケージ制御ファイルは DEBIAN/ ディレクトリ以下にまとめて、展開するツリーは直下をルートとしてそのまま、展開してくれます。 逆に、こういう状態で展開されているディレクトリを (DEBIAN/ と usr/ なりがある状態で) 指定して、 dpkg-deb --build <target directory> を実行すると、バイナリパッケージ形式の ar アーカイブに固めることもできます。 18.3 dpkg 3 分黒魔 ˆh ˆh 演習 ここから、バイナリパッケージと dpkg をネタに、ちょっと困った場面で dpkg を使う練習をしてみましょう。 18.3.1 演習:dropbox の deb ファイルをインストールする ※この回の勉強会の直後に、dropbox のパッケージはまともに作り直されて main に入りました。当時の記録とい うことでそのまま残していますが、今見ても邪悪さは楽しめないかも知れません http://www.dropbox.com/downloading?os=lnx から、ubuntu 専用の邪悪ˆh ˆh 手抜きな deb ファイルをダ ウンロードしてください。そのままでは debian にインストールしようとするとエラーになってしまうので、ここま での内容を使ってどうにかしてみてください。 アーキテクチャは各自の環境に合わせて適切な方を選んでください。これを間違えても dpkg コマンドでなんとか することはできません。 この資料は事前に配布してしまうので、解答はセッションの方で説明します。 一応、解答としては安易な方法を 3 種類ほど想定していますので、余裕でできてしまった人は何種類か方法を考え てみたり、一応ソースもあるので、自分で make してバイナリパッケージ作成にチャレンジしてもいいでしょう。 75 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 19 backports.debian.org 岩松 信洋 2010 の 9 月、正式に debian.org インフラの一部になった backports.debian.org(以下、bpo) ですが、実際にどの ように使えばいいのかわからないところがあります。今回はユーザと開発者側からの視点で情報をまとめました。 19.1 backports.debian.org とは backports.debian.org は testing や unstable で提供されているパッケージを既にリリースされた stable(執筆時 点では squeeze)および old-stable(執筆時点では lenny) にバックポートしたパッケージを提供するプロジェクト です。バックポートされることによって、stable で提供されているパッケージより新しいバージョンを使うことがで きるようになります。 アップロードされるパッケージには、元のバージョンに bpo{Debian リリース番号 }+{ ビルド番号 } という バージョンが付加されます。これによって、どのバージョンをどの Debian リリースにバックポートしたのかわかり ます。また、セキュリティアップデートにも対応しています。この場合、DSA(Debian Security Announce)ではな く BSA(Backports Security Announce)となります。また、DSA とは連動していない点に注意が必要です。 19.2 backports.debian.org で提供されているパッケージを使う まずは、backports.debian.org で提供されているパッケージの使い方について説明します。 19.2.1 どのようなパッケージが提供されているのか 現 在 backports.debian.org で 提 供 さ れ て い る パッケ ー ジ は http://backports.debian.org/changes/ squeeze-backports.html から参照できます。 76 19.2.2 /etc/apat/sources.list に apt-line を追加する /etc/apat/sources.list に backports.debian.org の apt-line を追加します。squeeze 向けには以下のように設定し ます。 deb http://backports.debian.org/debian-backports squeeze-backports main contrib や non-free も提供しているので、有効にしたい場合には apt-line に追加できます。 追加したらリポジトリ情報を更新します。 $ sudo apt-get update または $ sudo aptitude update 19.2.3 パッケージをインストールする backports.debian.org で提供されているパッケージをインストールするには、apt や aptitude の -t オプションを 使って ディストリビューションを指定します。例えば、postgresql-9.0 パッケージをインストールするには以下のよ うに実行します。 $ sudo apt-get -t squeeze-backports install postgresql-9.0 または $ sudo aptitude -t squeeze-backports install postgresql-9.0 19.2.4 パッケージを更新する backports.debian.org で提供されているパッケージに更新があった場合、apt-get update ; apt-get upgrade を実行しても、パッケージは更新されません。これは Pin-Priority の値が 100 (指定すればインストールできるが、 アップグレードの対象にはならない)に設定されているためで、更新するには、apt の preferences を使って、パッ ケージのプライオリティを設定する必要があります。 例えば、 /etc/apt/preferences に以下のような設定をしておくと、backports.debian.org で提供されているパッ ケージが更新された場合、apt-get update ; apt-get upgrade で更新されるようになります。これは、セキュリ ティアップデートをこのコマンドで行いたい場合に必要な設定でもあります。 Package: * Pin: release a=squeeze-backports Pin-Priority: 200 また、常に backports.debian.org で提供されているパッケージを利用するようには、Pin-Priority の値を 500 に設 定しておくとよいでしょう。(表 7*44 ) *44 http://debian.fam.cx/index.php?AptGet#y193a8b6 から抜粋した 77 表7 Pin-Priority の値と意味 Pin-Priority 意味 <0 インストールしない 1 NotAutomatic アーカイブ (experimental や backports 等) の優先値 1-100 指定すればインストールできるが、アップグレードの対象にはならない 100 現在インストールされているパッケージの 優先値 101-500 通常のアーカイブよりも優先度が低いが、指定してインストールしたも のはアップグレードの対象になる 500 ターゲットリリースに指定されていない通常のアーカイブの優先値 501-990 ターゲットリリース指定のアーカイブよりも優先度が低いが、アップグ レードの対象になる 990 ターゲットリリースに指定したアーカイブの優先値 991-1000 現在インストールされているパッケージよりも新しければターゲットリ リース指定に関係なくインストールされる >1000 ダウングレードしてでも、そのパッケージをインストールさせる 19.2.5 セキュリティアップデート backports.debian.org で提供されているパッケージのセキュリティアップデートは DSA では行われません。 BSA として行われ 誰かが 修正してアップロードします。(backports チームがチェック していると思われる) パッケージアップデートのアナウンスは backports-announce メーリングリスト(http://lists.debian.org/ debian-backports-announce)で行われます。backports.debian.org を使っている人はメーリングリストに登録し ましょう。 19.2.6 バグレポート 今のところ、backports.debian.org で提供されているパッケージは Debian BTS(http://bugs.debian.org) にバグレポートしてはいけないことになっています。なにか問題があった場合には、backports メーリングリスト (http://lists.debian.org/debian-backports)に投稿しましょう。backports.debian.org は Debian の正式な インフラなので、Debian BTS に統合される可能性もあります。その場合には、reportbug パッケージからもバグレ ポートできるようになるかもしれません。 19.2.7 欲しいパッケージがない場合 自分の欲しい機能がまだ stable で提供されているパッケージにはなく、unstable にあるパッケージで提供されてい るといったことはよくあります。このような場合、自分でビルドして使う方法もありますが、backports.debian.org で提供してもらうように依頼する方法もあります。まずはパッケージメンテナに直接依頼するのがよいのです が、パッケージメンテナが乗る気ではない場合、backpoorts メーリングリスト(http://lists.debian.org/ debian-backports/)で依頼するという方法もあります。 19.3 backports.debian.org を使ったパッケージの提供方法 backports.debian.org は誰でも利用可能です。といっても、パッケージをアップロードするには、Debian Developer (以下、DD)である必要があります。Debian Maintainer もパッケージをアップロードおよび更新はできません。よっ て DD 以外はスポンサーアップロードをしてもらう必要があります。また、自分がメンテナンスしているパッケージ 以外でもアップロードできます。ここでは、パッケージアップロードまでの流れと注意すべき点について説明します。 78 19.3.1 backports.debian.org キーリングへの登録 先では DD だとアップロードできると説明しましたが、すぐにアップロードできるわけではありません。Debian Developer キーリングと同じ鍵を backports.debian.org キーリングへの登録してもらうように申請する必要がありま す。この申請はリクエストトラッカー(https://rt.debian.org/Ticket/Create.html?Queue=20)を使います。 申請すると、数日後にキーリングに追加されます(リクエストトラッカーから連絡メールが来ます)。 19.3.2 アップロードするパッケージについて backports.debian.org にアップロードするパッケージは testing や unstable にあるパッケージをリビルドしてアッ プロードするのではなく、パッケージそのものに手を加える必要があります。また、いくつか注意する点もあります。 • ディストリビューションを コードネーム-backports に変更する。 debian/changelog では、ディストリビューションに stable や unstable を設定しますが、backports.debian.org にアップロードするパッケージのディストリビューションには コードネーム-backports を指定する必要があ ります。例えば、squeeze へバックポートしたい場合には、squeeze-backports とします。 • Debian バージョンに bpo{Debian リリース番号 }+{ ビルド番号 } を付加する。 最初に説明したように、backports.debian.org にアップロードされるパッケージには他のディストリビュー ションとの違いが分かるように Debian バージョンに bpo{Debian リリース番号 }+{ ビルド番号 } とい うバージョンを付加する必要があります。例えば、unstable にある パッケージ foo の 1.2.3-4 をアップロー ドし squeeze-backports にアップロードしたい場合には、1.2.3-4 bpo60+1 とします。60 は squeeze のリ リース番号(6.0)です。もし、アップロードしたパッケージ問題があり、再アップロードしたい場合には、 1.2.3-4 bpo60+2 とし、ビルド番号をインクリメントします。 • backports だけの修正を行わない。 特定のバージョンで発生するのはバグなので、unstable 等で修正して、それを backports.debian.org にバッ クポートするようにしましょう。 • squeeze および backports の環境でパッケージがビルドできるか確認する。 backports.debian.org では、buildd と同様に複数のアーキテクチャ向けにパッケージがビルドされます。もし、 stable および backports の環境でパッケージがビルドできない場合、FTBFS(Fail To Build From Source)に なるため、注意が必要です。また、ABI の問題があるため、動作確認は慎重に行う必要があります。pbuilder*45 や cowbuilder*46 を使って、クリーンルームからのビルドチェックを行いましょう。 • インストールとアップデートの確認をする。 パッケージができても、インストールとアップデートがうまく動作しない場合があります。これは、piuparts*47 を使って確認できます。 19.3.3 パッケージのアップロード先 通常、パッケージは ftp.upload.debian.org にアップロードされます。しかし、backports.debian.org の場合に は、backports-master.debian.org にアップロードする必要があります。通常、アップロードする時には dupload や dput というパッケージをアップロードするツールを使います。各アプリケーションの設定ファイルに以下のよう な設定を加えておきます。 • dupload の場合 *45 *46 *47 http://packages.qa.debian.org/p/pbuilder.html http://packages.qa.debian.org/c/cowdancer.html http://packages.qa.debian.org/p/piuparts.html 79 $cfg{’bpo’} = { fqdn => "backports-master.debian.org", incoming => "/pub/UploadQueue/", }; • dput の場合 [bpo] fqdn = backports-master.debian.org incoming = /pub/UploadQueue/ method = ftp login = anonymous allow_dcut = 1 19.3.4 セキュリティアップロードをする backports-master.debian.org にセキュリティアップロードを行う場合には BSA 番号を割り振ってもらう必要 があります。この番号は backports チームで管理しているので、[email protected] に問い合せま す。また、セキュリティアップロードの内容を PGP/GPG でサインして、backports-announce メーリングリスト (http://lists.debian.org/debian-backports-announce)にアナウンスします。 アナウンスする内容のテンプレートは以下のようになります。 Subject: [BSA-XXX] Security Update for <packagename> <Uploader> uploaded new packages for <packagename> which fixed the following security problems: CVE-XXXX or whatever ID if existant short description ... CVE-.... .... For the squeeze-backports distribution the problems have been fixed in version <packageversion>. <other distributions if any> 19.3.5 backports.debian.org の動作 backports.debian.org の動作は buildd network と同じです。アップロード先やパッケージリポジトリが異なるだ けで、buildd network を利用したパッケージのビルドを行っています。 80 19.4 まとめ ユーザが backports.debian.org を使う場合、新しいバージョンを使えるというメリットがあるので使ったほうが 良いと思います。先に書いたように BTS 等はうまく連動していないのと、パッケージメンテナではなくてもアッ プロードできてしまうので、問題があった場合には調整が必要になることがありそうです。このような場合には debian-backports メーリングリストをうまく活用していく必要があると思います。また、apt の pin の設定を正しく しておかないと、うまくアップデートしなかったりするので、注意が必要です。 開発者の場合には、メンテナンスコストが増えるだけであまりメリットがあるようには思えません。しかしユーザ からの依頼があった場合には考慮する必要があるので、仕組みだけは知っておくとよいと思います。もう少し使いや すくするには他の Debian インフラとの連携が密になる必要があるでしょう。 81 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 20 pbuilder を使ってみよう 水野 源 20.1 pbuilder とは? 20.1.1 pbuilder とはなにか? pbuilder とは、「Personal Debian Package Builder の略」で、Debian パッケージをクリーンな chroot 環境内で ビルドするためのツールです。シェルスクリプトで記述されており、内部では debootstrap という Debian の基本シ ステムをインストールするためのユーティリティを利用しています。pbuilder は debootstrap を用いて「最小限な Debian 環境」をあらかじめ作成しておき、これをパッケージのビルド時に展開して、その中で実際のパッケージビ ルドを実行します。 もちろん pbuilder を使わなくてもバイナリパッケージを構築することはできます。ですが pbuilder を使うことで、 パッケージビルドに伴ういくつかの問題を解決することができます。 20.1.2 Debian パッケージのビルド おさらい pbuilder のメリットを理解しやすくするため、ソースパッケージからパッケージをリビルドする手順を例に、 Debian パッケージのビルドをおさらいしておきましょう。 apt-get source コマンドでソースの取得と展開を行います。Debian のソースパッケージはオリジナルのソース tarball である*.orig.tar.gz、Debian パッケージにする際に必要な差分である*.debian.tar.gz、署名ファイルであ る*.dsc の三つのファイルで構成されており、apt-get source コマンドはこれらのファイルの取得と展開を行なうこと ができます。 展開後のディレクトリには、オリジナルのソースファイルとパッケージに必要な debian ディレクトリが存在し、こ こで dpkg-buildpackage コマンドを実行することでパッケージのビルドが行えます。しかしこの例では、ビルド時の 依存関係が満たせずビルドに失敗します。 $ apt-get source jd $ cd jd-2.7.0~beta100627 $ dpkg-buildpackage (...snip...) dpkg-checkbuilddeps: Unmet build dependencies: quilt (>= 0.46-7~) autoconf automake libtool libgnutls-dev libgtkmm-2.4-dev zlib1g-dev hardening-wrapper libasound2-dev dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. (...snip...) apt-get build-dep コマンドを実行すると、debian/control ファイルの Build-Depends に列挙されているパッケー ジがインストールされます。これでビルド時の依存関係が満たされましたので、再度ビルドを行ないます。今度は問 題なくビルドが完了するはずです。 82 $ apt-get build-dep jd (...snip...) The following NEW packages will be installed: autoconf automake autotools-dev bsdmainutils debhelper defoma diffstat file fontconfig fontconfig-config gettext gettext-base groff-base hardening-wrapper html2text intltool-debian libasound2 libasound2-dev (...snip...) $ dpkg-buildpackage 20.1.3 Debian パッケージのビルド まとめ • パッケージをビルドするには「ビルド時に」依存しているパッケージをインストールする必要がある • apt-get は Build-Depends をもとに、ビルド依存パッケージを一括導入できる • ビルド依存パッケージは debian/control に Build-Depends として記述してある 20.1.4 pbuilder を使うことによるメリット クリーンな環境でパッケージのビルドを行うことができる 前述の通りパッケージをビルドするためには、ビルド依存パッケージをあらかじめシステムにインストールしてお く必要があります。通常のマシンでさまざまなパッケージのビルドを行なっていると、こういったパッケージたちが システムに蓄積されていきます。pbuilder はビルド時に最小限な Debian 環境を一時ディレクトリに展開し、必要な パッケージを追加インストールします。そしてビルド終了後に一時ディレクトリごと破棄するため、ビルド環境が 「汚れていく」ことがありません。 依存関係のテストができる 上記のように pbuilder は、最小限な Debian 環境に、ビルドに必要なパッケージをその都度インストールします。こ の「必要なパッケージ」はパッケージの Build-Depends の記述をもとに行いますので、もしも Build-Depends の記 述に不足があった場合は、ビルドに失敗する = 記述の間違いに気付くことができます。また Build-Depends が不足 しているパッケージがリリースされてしまった場合、必要なパッケージが既に揃っているメンテナの環境では正常に ビルドできるが、第三者の環境では apt-get build-dep で必要なパッケージがすべてインストールされないため、リ ビルドに失敗するという事態が発生する可能性があります。 別リリース、別アーキテクチャ向けのビルドを行うことができる 通常であれば、ビルドマシンを対象となるリリースやアーキテクチャごとにそれぞれ用意しなくてはなりませ ん。しかし pbuilder であれば、amd64 マシンの上に i386 の chroot 環境を作ることもできるため、amd64 マシ ン一台で amd64/i386 両方のパッケージをビルドすることが可能です (もちろん arm なども)。それだけではな く、sid/squeeze/lenny といった別リリースや、Ubuntu の chroot 環境を作ることも可能です (つまり Debian 上で Ubuntu パッケージが作れます。またその逆も可能!)。 20.2 pbuilder の使い方 20.2.1 pbuilder のインストール それでは pbuilder をインストールして、実際に動かしてみましょう。pbuilder 本体をインストールしたら、pbuilder –create コマンドで chroot 環境を作成します。この例ではディストリビューションに sid、アーキテクチャは i386、ミ ラーサイトに理研を指定しています。mirror オプションで指定したミラーサイトは chroot 内の apt-line にも反映さ れます。 $ sudo apt-get install pbuilder $ sudo pbuilder --create --distribution sid --architecture i386 --mirror "http://ftp.riken.jp/Linux/debian/debian" 構築作業が完了すると、/var/cache/pbuilder/base.tgz というファイルが作成されています。これが i386 な sid の chroot 環境を固めた tarball です。 83 20.2.2 パッケージのビルド pbuilder でパッケージをビルドするには、pbuilder –build コマンドにソースパッケージの*.dsc ファイルを引数と して渡します。すると pbuilder は、/var/cache/pbuilder/build/(pbuilder-buildpackage の PID) というディレクト リに base.tar.gz を展開し、この中でビルド依存パッケージのインストールと、パッケージのビルドを行ないます。ビ ルドが終了すると build ディレクトリは削除され、ビルド済みのバイナリパッケージが/var/cache/pbuilder/result 以下に作成されているはずです。 $ sudo pbuilder --build jd_2.7.0~beta100627-1.dsc I: using fakeroot in build. I: Current time: Tue Feb 15 19:48:46 JST 2011 I: pbuilder-time-stamp: 1297766926 I: Building the build Environment I: extracting base tarball [/var/cache/pbuilder/base.tgz] (...snip...) I: Installing the build-deps -> Attempting to satisfy build-dependencies (...snip...) I: cleaning the build env I: removing directory /var/cache/pbuilder/build//8063 and its subdirectories 20.2.3 複数の pbuilder 環境 pbuilder はデフォルトで/var/cache/pbuilder/base.tgz を使用しますが、–basetgz オプションを使用することで 任意のパス/ファイルを指定することができます。これを利用して複数の pbuilder 環境を使いわけることが可能です。 $ $ $ $ sudo sudo sudo sudo pbuilder pbuilder pbuilder pbuilder --create --distribution sid --architecture i386 --basetgz /var/cache/pbuilder/sid-i386.tgz --create --distribution squeeze --architecture amd64 --basetgz /var/cache/pbuilder/squeeze-amd64.tgz --build jd_2.7.0~beta100627-1.dsc --basetgz /var/cache/pbuilder/sid-i386.tgz --build jd_2.7.0~beta100627-1.dsc --basetgz /var/cache/pbuilder/squeeze-amd64.tgz 20.2.4 pbuilder 環境へのログイン パッケージビルド時に自動的に使用される pbuilder の chroot 環境ですが、ここへ chroot してシェルを取ることも 可能です。そのためには pbuilder –login コマンドを使用します。この機能を利用すれば、squeeze 上で sid の環境を ちょっと試す、といったことも可能です。 $ sudo pbuilder --login --basetgz /var/cache/pbuilder/sid-i386.tgz 20.2.5 pbuilder 環境の更新 パッケージをビルドするためには、chroot 環境を常に最新に保っておく必要があります。既存の環境をアップデー トするには pbuilder –update コマンドを使用します。 $ sudo pbuilder --update --basetgz /var/cache/pbuilder/sid-i386.tgz また前述のように展開した pbuilder 環境は使い捨てで、環境に対して行なった変更はビルド終了後に破棄されま す。これによって常にクリーンな環境が保たれるわけですが、場合によっては恒久的な変更を加えたい場合があるか もしれません。そんな場合は、–login –save-after-login コマンドでカスタマイズが可能です。–save-after–login つき で chroot 環境にログインして何らかの変更を加えると、ログアウト時に base.tgz を更新してくれます。chroot 環境 に「パッケージを追加しておきたい」「設定を変更しておきたい」などという時に便利です。 $ sudo pbuilder --login --save-after-login --basetgz /var/cache/pbuilder/sid-i386.tgz I: Building the build Environment I: extracting base tarball [/var/cache/pbuilder/sid-i386.tgz] (...snip...) # exit (...snip...) I: creating base tarball [/var/cache/pbuilder/sid-i386.tgz] I: cleaning the build env I: removing directory /var/cache/pbuilder/build//679 and its subdirectories 84 20.3 pbuilder をさらに便利に使う/cowbuilder このように pbuilder は非常に便利ですが、毎回 tarball を展開し使い終ったら削除するというのは、展開や削除に 時間がかかります。さらに tarball の中に格納されているファイルとビルド時に使用されるファイルは同じものです し、ほとんどのファイルは変更されないまま破棄されるわけですので、わざわざコピーするのは無駄です。それなら ば原本そのものを見ておけばいいよね、という発想で無駄を省いたのが cowbuilder です。 20.3.1 tarball からハードリンクへ cowbuilder は pbuilder と同じように使用でき、同じように動作します。ただし、pbuilder が chroot 環境を tarball で保存するのに対し、cowbuilder は/var/cache/pbuilder/base.cow というディレクトリ以下に展開した状態で保存さ れる点が異なります。pbuilder では使用時に tarball を/var/cache/pbuilder/build 以下に展開しますが、cowbuilder は cp -la コマンドで base.cow へのハードリンクを/var/cache/pbuilder/build 以下に作成しています。ファイル実体 のコピーや展開は行なわれないため非常に高速で、余計なディスクスペースも消費しません。 ですが単にハードリンクしているだけでは、ビルド用の一時環境に変更が加わった時に原本が変更されてしまい ます。そこで使用されているのが cowbuilder の名前の由来でもある「Copy-On-Write」という技術です。Copy-On- Write とは「コピーしたふりをして原本を参照させておき、変更が加わった際に実際にコピーを行なって変更を書き こむ」技術で、cowbuilder の内部では、Copy-On-Write を実現するために cowdancer というプログラムが使用され ています。これにより cowbuilder は、大部分のファイルはハードリンクで原本 (base.cow) をそのまま使い、変更が 必要な部分のみコピーして書きかえるという効率的な動作が可能になっています。 $ sudo cowbuilder --create --distribution sid --architecture i386 --mirror "http://ftp.riken.jp/Linux/debian/debian" $ cd /var/cache/pbuilder/base.cow/ $ ls -li etc/debian-version 7020666 /etc/debian_version $ sudo cowbuilder --login # ls -li /etc/debian-version 7020666 /etc/debian_version # vi /etc/debian_version # ls -i /etc/debian_version 7070836 /etc/debian_version 20.4 Ubuntu 的な pbuilder/cowbuilder Ubuntu では pbuilder/cowbuilder を直接使わず、pbuilder-dist/cowbuilder-dist というラッパースクリプトを経 由して使うのが一般的です。これらのスクリプトは ubuntu-dev-tools パッケージに含まれており、Debian でも使用 することができます。これらのスクリプトは、pbuilder における pbuilder-distribution.sh をよりよい形で Python で再実装したものと言えます。 20.4.1 pbuilder-dist/cowbuilder-dist の特徴 一言で言ってしまえば、pbuilder/cowbuilder に、事前に設定したオプションを食わせるラッパーです。次のよう に実行します。 $ pbuilder-dist distribution [architecture] operation –debug-echo オプションを使用すると、実際に起動される pbuilder のコマンドとオプションを確認することがで きます。pbuilder は root か sudo つきで実行する必要がありましたが、pbuilder-dist は内部で pbuilder が sudo つ きで起動されるため、pbuilder-dist 自身はユーザ権限で実行できます。また base tarball やログファイル、ビルド したパッケージなどをユーザのホームディレクトリ以下に作成するため、さまざまな pbuilder のオプションが暗黙 的に設定されているのがわかります。また tarball のファイル名も dist-arch-base.tgz という形になっており、複数の pbuilder 環境を共存させやすくなっています。 85 $ pbuilder-dist sid i386 create --debug-echo sudo /usr/sbin/pbuilder --create --basetgz "/home/mizuno/pbuilder/sid-i386-base.tgz" --distribution "sid" --buildresult "/home/mizuno/pbuilder/sid-i386_result/" --aptcache "/var/cache/apt/archives/" --override-config --logfile /home/mizuno/pbuilder/sid-i386_result/last_operation.log --mirror "ftp://ftp.debian.org/debian" --components "main contrib non-free" --debootstrapopts --arch="i386" 20.4.2 pbuilder-dist の呼び出し方 pbuilder-dist コマンドをそのまま呼び出してもよいのですが、シンボリックリンクで別名をつけて使うのも便利で す。シンボリックリンクは pbuilder-[dist]-[arch] という形式で作成します。例えば pbuilder-sid-amd64 というリン クは、pbuilder-dist sid amd64 というコマンドと同等の働きをします。i386/amd64 の sid と squeeze の環境、計 4 つを使いわけたいなどという場合は、それぞれの名前でリンクを作成しておけばわかりやすいでしょう。 $ ln -s /usr/sbin/pbuilder-dist pbuilder-sid-amd64 $ ./pbuilder-sid-amd64 create --debug-echo sudo /usr/sbin/pbuilder --create --basetgz "/home/mizuno/pbuilder/sid-amd64-base.tgz" --distribution "sid" --buildresult "/home/mizuno/pbuilder/sid-amd64_result/" --aptcache "/var/cache/apt/archives/" --override-config --logfile /home/mizuno/pbuilder/sid-amd64_result/last_operation.log --mirror "ftp://ftp.debian.org/debian" --components "main contrib non-free" 20.4.3 pbuilder-dist のメリット pbuilder-dist では、簡単に複数の pbuilder 環境を使い分けることができます。特に Ubuntu は複数のリリースや、 上流である Debian でのテストが必要なため、release、release+1、sid を簡単に切り替えられることが大事です。 また、デフォルトでユーザのホーム以下に base tarball やビルドしたパッケージができるため、ユーザ権限での管 理がしやすいという特徴があります。 20.5 まとめ • pbuilder/cowbuilder を使うことで、普段使っている環境を開発用パッケージで汚すことなく、パッケージの ビルドを行うことができます。 • 基本的な Debian システムでビルドが可能なことを確認することができるので、パッケージをいじった後は必 ず確認しておくとよいでしょう。 • cowbuilder を使えば、より高速に pbuilder 環境を利用することができます。 • pbuilder-dist を使えば、リリース間、ディストリ間を渡り歩くのも簡単です。 86 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 21 Debian 勉強会予約システムにアン ケート追加 上川 純一 21.1 アンケートシステムの目的 Debian 勉強会は各自のブログに記述するということが当初事後課題として機能していました。勉強会を開催した あと、参加者は勉強会で得られた内容を整理することができて、開催者は内容がどのようにうけとられたのかをある 程度推し量ることができました。 しかし、近年勉強会の感想がブログに記述される率が低下してきています [1]。原因を想像するに、最近はコミュニ ケーションの道具としての twitter の流行などにともない、ブログに記述するという習慣が減ってきているからなの かもしれません。 時代の変遷によりブログエントリーがなくなるとその機能を代替するものは何でしょう。 ブログの機能としては、フィードバックのシステムと、あとその他のユーザに勉強会の記録を伝えるという面があ りました。記録の面は twitter のログをまとめる togetter をなどを使えばよいだろうということが 2010 年 12 月の勉 強会で提案され、それで問題は解決しそうです。残る課題はフィードバックシステムとしての機能です。 勉強会へのフィードバックシステムとしてアンケートシステムを提案します。 21.2 アンケートシステムの利用方法 21.2.1 管理者の事前準備 イベントの管理者はイベントの一覧画面からアンケート作成画面に遷移することができます。そこでは、ユーザに 表示するための全体的なメッセージと、各項目を改行区切りで記述する欄があります。 ユーザにメールを送信すると、ユーザにはリンクの書いてあるメールが届きます。そのリンクをクリックすると、 ユーザはアンケートに回答することができます。 21.2.2 ユーザ ユーザは各項目については 0 から 5 までの値で回答することができます。そして、全体について自由記述の項目が あります。*48 二つ目的があります。勉強会の企画の中で、どの部分が評価されているのかというのを出していきたいのと、任意 なメッセージを入力できるようにすることで会に対してやりたいことなどの要望が伝えられるようにすることです。 *48 勉強会の会場では 5 択だと中心に回答が偏りがちなので、4 択にしたほうがよいのではないかという意見が出ました。Debian 勉強会アン ケートシステムでは中心に偏り過ぎているとい傾向はまだ出ていないのでこのまま進めてみようと考えています。 87 図 10 アンケート編集画面 図 11 アンケート回答画面 表8 0. N/A アンケート回答結果の内部表現 *49 1. すごくよくない 2. よくない 3. どちらでもない 4. よかった 5. 素晴らしい、他人にも薦めたい 21.2.3 管理者が事後に確認 管理者は、アンケートの [アンケート集計 CSV] リンクをたどることにより、イベント単位のデータの CSV ダンプ を見ることができます。 特に集計処理はしていません。ここから先は CSV をとりだして処理することになります。 ここで、アンケートが匿名であるべきか記名であるべきかを最初考えていませんでした。どちらがどういう効果が あるのかよくわかっていないので今後の課題としたいと思います。ブログ代わりなのであれば記名でよいと思うので すが、アンケートが記名だとバイアスがかかるというのであれば匿名のほうがよいかもしれません。システム的には 今は匿名として扱っています。*50 *50 Debian 勉強会の会場での議論では、回答の匿名性については。参加者のアンケート回答は匿名扱いにしたほうが答えにバイアスがかかり にくいだろうという意見が出ました。 88 21.3 アンケートシステムの設計と実装 アンケートシステムの設計と実装について見てみましょう。アンケートは Debian 勉強会予約システム [2] の一機 能として実装しています。 21.3.1 データストア ここの設計で悩んだ点は、EventEnqueteResponse を Attendance と一緒にするべきかどうかです。Datastore が join をサポートしていないためです。今回は分離して必要なときに手動で join*51 するアプローチにしてみました。 class EventEnquete(db.Model): """Enquete questions for an event.""" eventid = db.StringProperty() overall_message = db.TextProperty() question_text = db.StringListProperty() timestamp = db.DateTimeProperty(auto_now_add=True) class EventEnqueteResponse(db.Model): """Enquete respnose for an event by one person.""" eventid = db.StringProperty() # responses for 1-5 questions. 0 is N/A question_response = db.ListProperty(long) overall_comment = db.TextProperty() # a general comment from user. timestamp = db.DateTimeProperty(auto_now_add=True) user = db.UserProperty() 21.3.2 ユーザインタフェース ユーザインタフェース部分は enquete.py に記述しています。メールや HTML ファイルの表示部分には、Django のテンプレートを利用しています。 • EnqueteAdminEdit.html 管理者用のアンケート編集画面 • EnqueteAdminSendMail.txt 管理者が参加者にアンケートを依頼するメール送信するときのメールのテンプ レート • EnqueteAdminShowEnqueteResult.txt アンケートの結果を CSV 形式で表示する。 • EnqueteRespond.html 参加者がアンケートを返答する際に表示される HTML。 • EnqueteRespondDone.txt 参加者がアンケートを回答したときに送信される確認メール。 21.3.3 バックグラウンドタスク ウェブインタフェースからアンケートの送信リクエストがあった場合、クリックした瞬間にメールの送信処理が発 生するわけではなく、メールの送信処理に taskqueue を利用しています。 送信元は [email protected] を使っています。多分ログインユーザの権限でメールを出す ということができないのだと想定してこうなっています*52 。 21.4 先月のアンケート集計結果 それでは、例として 2010 年 12 月のアンケート結果をみてみましょう。0 は欠損値なので、R に処理させる場合は 「NA」として処理します。これで R で処理した結果を見てみましょう。まだこの時点ではデータが少ないので、今回 のなかでどのセッションが比較的ポジティブな感想を集めたのかということが分かるだけです。 事前準備として、統計解析ツール R[3] をインストールします。ここでは基本パッケージの r-base とドキュメント の r-doc-info*53 をインストールしています。 *51 同じキーで二回別のテーブルを query することになるので必要なときには効率が悪いけど、あまり必要にならないと予想した設計 未確認 *53 R ではなにかわからないことがあればとりあえず info を見るか、help() コマンドをつかえばよいかんじです。 *52 89 # apt-get install r-base r-doc-info R を起動して CSV ファイルをロードして、まず基本的な統計量を調べます。 $ R [中略] > enquete <- read.csv(’201012enquete.csv’) > summary(enquete) 事前課題紹介 X2010 年の Debian を振り返って.2011 年を企画する Min. :3.00 Min. :3 1st Qu.:3.75 1st Qu.:3 Median :4.00 Median :4 Mean :3.75 Mean :4 3rd Qu.:4.00 3rd Qu.:5 Max. :4.00 Max. :5 NA’s :1.00 NA’s :1 CACert の準備に何が必要か 俺の libsane が火をふくぜ Debian.Miniconf. 企画 Min. :4.000 Min. :4.000 Min. :1.000 1st Qu.:4.000 1st Qu.:4.500 1st Qu.:2.000 Median :5.000 Median :5.000 Median :3.000 Mean :4.556 Mean :4.714 Mean :2.778 3rd Qu.:5.000 3rd Qu.:5.000 3rd Qu.:4.000 Max. :5.000 Max. :5.000 Max. :4.000 NA’s :2.000 > quantile(enquete$俺の, na.rm=TRUE) 0% 25% 50% 75% 100% 4.0 4.5 5.0 5.0 5.0 > quantile(enquete$Debian) 0% 25% 50% 75% 100% 1 2 3 4 4 ざっと数字を眺めただけですが、今回特に評価の高かったセッションは sane ネタと、CACert ネタで、評価の低 かったセッションは Debian Miniconf 企画ネタでした。今回のアンケートの結果を受けると、Debian miniconf につ いてはプレゼンテーションの方法を考え直した方がよいだろうと思います。事前課題資料が無かった、プレゼンテー ションしようとしたマシンがプロジェクタにうまくつながらなかった、そもそも話の内容もあまり練られていなかっ たということを考えるとそれがそのままアンケートの統計値にも反映したと考えられます。 一つ目線を変えて相関を調べてみました。しかし、まだこれをどう判断するべきか考えがまとまっていません。 > cor(enquete$CAC, enquete$俺の, use="complete.obs") [1] 0.7302967 > cor(enquete$俺の, enquete$事前, use="complete.obs") [1] -0.2581989 > cor(enquete$CAC, enquete$事前, use="complete.obs") [1] 0 また、勉強会で議論した結果出てきた懸念点としては、点数のフィードバックは毎回出てこられても講師のやる気 がそがれるなどの悪影響がある可能性がある点でした。講師には一年に一回程度まとめて返すのがよいだろうという 提案がありました。 参考文献 [1] 上川純一, 「2010 年の東京エリア Debian 勉強会をふりかえって」東京エリア Debian 勉強会 Deb 専 2010 年 12 月号 [2] 上川純一, 「東京エリア Debian 勉強会予約システムの構想」東京エリア Debian 勉強会 Deb 専 2010 年 2 月号 [3] R Development Core Team, “R: A Language and Environment for Statistical Computing”, R Foundation for Statistical Computing, Vienna, Austria, 2008 http://www.R-project.org 90 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 22 2010 年の東京エリア Debian 勉強会 をふりかえって 上川 純一 今月で 6 年目の Debian 勉強会が終了しました。Debian Developer の数も着々と増えていき、当初の目標が達成 されてきていますね。 今年東京エリア Debian 勉強会常連のやまねさんが Debian Developer になりました。苦節 6 年おめでとうござい ます。 Debian Maintainer 申請も複数通りました。 22.1 基本的な数値 Debian 勉強会は毎回事前課題事後課題を設定しており、予習復習を必要だとうたっている勉強会です。実際にど れくらいの人が出席しているのか、またその人たちがどれくらい事前課題・事後課題を提出しているのか、確認して みましょう。図 12 です。値は一年の移動平均です。 結果を見ると事前課題の提出率が 2009 年に低下傾向にあったのが、2010 年に反転上昇しています。これは Debian 勉強会予約システムの導入により事前課題の提出が簡単になったことと関係ありそうです。また、別の傾向として事 後課題 (ブログ) の率が低下傾向にあります。もうブログは流行らないのかもしれません。 図 12 東京エリア Debian 勉強会事前課題・事後課題提出実績 (12ヶ月移動平均) 毎回の参加者の人数と、その際のトピックを見てみます。今年はとくに目立った感じの回はないですが、参加者に ついての記録が散逸しているようです。 91 今年の会場ですが、東京大学、筑波大学、木更津高専とアカデミックな場所の利用が増えました。*54 。また、NIFTY さんの会場も使い、公営の会議室 (杉並区、オリンピックセンターなど) は数回しか利用していません。 表9 表 10 東京エリア Debian 勉強会参加人数 (2005-2006 年) 参加人数 内容 2005 年 1 月 21 秘密 2005 年 2 月 10 debhelper 1 2005 年 3 月 8 (早朝) debhelper 2、so- 東京エリア Debian 勉強会参加人数 (2007-2008 年) 参加人数 cial contract 2005 年 4 月 6 debhelper 3 2005 年 5 月 8 DFSG、dpkg-cross、 lintian/linda 2005 年 6 月 12 alternatives、d-i 2005 年 7 月 12 toolchain、dpatch 2005 年 8 月 7 Debconf 参加報告、ITP 14 debconf 2005 年 10 月 9 apt-listbugs、バ グ レ 2007 年 1 月 15 一年を企画する 2007 年 2 月 13 dbs, dpatch 2007 年 3 月 80 OSC 仮想化 2007 年 4 月 19 quilt, darcs, git 2007 年 5 月 23 etch, pbuilder, superh 2007 年 6 月 4 エジンバラ開催:Deb- conf7 実況中継 からアップロードまで 2005 年 9 月 2007 年 7 月 18 Debconf7 参加報告 2007 年 8 月 25 cdn.debian.or.jp 2007 年 9 月 14 exim 2007 年 10 月 30 OSC Tokyo/Fall(CUPS) 2007 年 11 月 ポート、debconf 翻訳、 19 8 2005 年 12 月 8 忘年会 2006 年 1 月 8 policy、Debian 勉 強 会 2006 年 2 月 7 policy、multimedia 2006 年 3 月 30 OSC: debian 勉 強 会 、 2006 年 4 月 15 policy、LATEX 2006 年 5 月 6 mexico 2006 年 6 月 16 debconf、cowdancer 2006 年 7 月 40 OSC-Do: 11 忘年会 2008 年 1 月 23 一年を企画する 2008 年 2/29,3/1 36 OSC 2008 年 3 月 37 デ ー タ だ け の パッケ ー 17 13 執念 2006 年 9 月 12 翻訳、Debian-specific、 17 バイナリパッケージ 2008 年 5 月 20 複数のバイナリパッケー 2008 年 6 月 10 debhelper 2008 年 7 月 17 Linux kernel patch / module パッケージ MacBook 2006 年 8 月 2008 年 4 月 ジ 2008 年 8 月 Debian 10 2008 年 9 月 17 network、i18n 会 議 、 2008 年 10 月 11? OSC Tokyo/Fall 2008 年 11 月 17 「その場で勉強会資料を 作成しちゃえ」 Debian 関 西 開 催: bug、sid、 を使った LATEX 原稿作 packaging *54 14 po4a, 「Debian メンテ ナのお仕事」 Flash、apt 2006 年 12 月 Debconf IRC 会 議 と Debian 温泉 oprofile 20 patch, ジ、ライセンス sid 2006 年 11 月 kernel 2007 年 12 月 でやりたいこと 23 tomoyo server DWN 翻訳フロー、statoverride 2006 年 10 月 live-helper, linux debbugs 2005 年 11 月 内容 成合宿 忘年会 2008 年 12 月 OSC も明星大学で開催されました 92 12 忘年会 表 11 東京エリア Debian 勉強会参加人数 (2009-2010 年) 参加人数 内容 2009 年 1 月 12 一年を企画する 2009 年 2 月 30 OSC パッケージハンズ オン 2009 年 3 月 23 Common Lisp, パッ ケージ作成 2009 年 4 月 15 Java Policy, ocaml, 開 発ワークフロー 2009 年 5 月 13 MC-MPI パッケージ化、 Erlang、Android ア プ リ、DDTP 2009 年 6 月 14 DDTP・DDTSS、 bsdstats パッケ ー ジ 、 Debian kFreeBSD 2009 年 7 月 4 スペインにて Debconf 9 2009 年 8 月 14 スペイン Debconf 9 参 加報告 2009 年 9 月 26 GPG キーサインパーテ ィー 2009 年 10 月 30 OSC Tokyo Fall 2009 年 11 月 12 Octave, R, gnuplot, auto-builder 2009 年 12 月 10 忘年会 2010 年 1 月 17 東京大学にて新年会 2010 年 2 月 11 Debian 温 泉,ocaml,haskell 2010 年 3 月 12 weka,fftw,dpkg v3 quilt 2010 年 4 月 15 upstart,piuparts,debtags 2010 年 5 月 22 筑波大学,kernel 2010 年 6 月 12 OSC-Do リハーサル 2010 年 7 月 0 キャンセル 2010 年 8 月 3 Debconf (NYC) 2010 年 9 月 30 OSC Tokyo/Fall 2010 年 10 月 13 俺の Debian な一日 2010 年 11 月 15 ext4,btrfs,nilfs,ceph 2010 年 12 月 14 cacert, libsane 93 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 23 関西 Debian 勉強会 2010 年度各種 イベント開催実績と総括 倉敷・佐々木・野方 23.1 運営状況 23.1.1 勉強会全体 毎月のセッションについてですが、 勉強会の常連さんやイベント等で交流のある方に講師を依頼したりすること で、 参加者が関心を持っている様々な分野のネタを勉強会で行なう事ができました。その反面 Debian との関連性に 薄いネタが増えている、という指摘も受けています*55 。これは我々運営側が講師に依頼する際にもっと明確にお願い すべき事柄の様な気もします。今後の反省材料としたい所です。また、今回の事前課題で複数の方が提出されている 通り、定番のネタ (Debian 入門的なお話やライセンス、パッケージ作成等) を雑誌のように毎年繰り返すことも考え てみたい所です。 講師については、継続して参加者して下さる常連さんへの講師依頼をする中で、その方が勉強会の運営側へ参加し て下さったり、という嬉しい事もありました。また、Ubuntu コミュニティとの交流があったり、という感じでした。 人の輪がこうして広がっていくのは嬉しいですね。 事前課題については、「Debian 勉強会登録システム」の実装と連動してシステム化されたこともあり、関西でも毎 回の流れにのってきました。来年からは東京のように統計をとってもいいかな、と考えています。 イベント参加については、今年は春先に OSC Kobe が開催されたため、年間通して 3 回分をイベントセッション という形で実施しました。また、勉強会から fork (?) する形で GPG キーサインパーティの実施も定例となりつつ あります。来年も今年通り 3 回の参加を予定しておりますが、takaya さんより「ユーザ向け」と「開発者 (含むワナ ビー) 向け」の 2 セッションに分けたらどうか、との提案もあったりしています。当面 4 月の OSC Kobe でのお話 になりますが、検討してみたい所です*56 。 debian.org については、今年度は佐々木、倉敷の 2 名がめでたく Debian Maintainer になりました。来年もこ の流れを維持できればと思います。 23.1.2 イベント関連 例年通り、夏のオープンソースカンファレンス Kansai@Kyoto(OSC 京都) と、秋の関西オープンフォーラム (KOF) の出展にくわえ、3 月に神戸で開催されたオープンソースカンファレンス Kansai@Kobe(OSC 神戸) にも参加しま した。 そして OSC 京都と KOF では、佐々木さんが中心となり GPG キーサインパーティを開催しました。 セッションの内容については、OSC 神戸や KOF では最近の Debian 関連情報を伝える軽めのセッション、OSC 京 *55 *56 ネタ自体は Debian に絡められるのに, あんまり関連性について触れられていない, 等 人的リソースやそもそも二枠取れるのか, 等と気になる課題はありますが 94 都ではパッケージのバックポート講座を開きましたが、情報系より手を動かすセッションのほうが反響があったので、 ハンズオン的なことを増やしていければと思います。 イベントについては FLOSS 関連のイベントが年 2 回から 3 回に増えたことと、GPG キーサインパーティの担当、 イベント側のスタッフとして参加など、リソースが若干厳しくなってきたのでなにかいいバランスを取ることを考え たほうがいいのかもしれません。 23.2 開催実績 関西 Debian 勉強会の出席状況を確認してみましょう。グラフで見ると図 13 になります。表で見ると表 15 です。 図 13 関西の参加人数推移 95 表 12 表 13 関西 Debian 勉強会参加人数 (2008 年) 関西 Debian 勉強会参加人数 (2007 年) 参加人数 参加人数 内容 2007 年 3 月 19 開催にあたり 2007 年 4 月 25 goodbye、youtube、プ 23 20 前後 2007 年 8 月 20 16 2008 年 5 月 OSC-Kansai 22 ラ イ ブ ラ リ、翻 訳 、 20 前後 2007 年 12 月 15 coLinux, Debian 25 ipv6, emacs, us- 2008 年 6 月 20 pbuilder, hotplug, ssl 2008 年 8 月 13 coLinux 2008 年 9 月 17 debian mentors, ubiquity, DFSG 日本語入力、SPAM フィ ルタ 2007 年 11 月 24 tream.tv Inkscape、patch、 debtorrent 2007 年 10 月 23 PC Cluster, GIS, TEX bug report, developer GNU/kFreeBSD, sid dpatch 2007 年 9 月 2008 年 3 月 2008 年 4 月 社会契約、テーマ、de- bian/rules、bugreport 2007 年 7 月 20 corner, GPG ロジェクトトラッカー 2007 年 6 月 2008 年 2 月 内容 KOF 忘年会、iPod touch 2008 年 10 月 11 cdbs,cdn.debian.or.jp 2008 年 11 月 35 KOF 2008 年 12 月 ? TeX 資料作成ハンズオ ン 表 15 関西 Debian 勉強会参加人数 (2010 年) 表 14 関西 Debian 勉強会参加人数 (2009 年) 参加人数 参加人数 内容 2009 年 1 月 18 DMCK, LT 2009 年 3 月 12 Git 2009 年 4 月 13 Installing sid, 内容 2010 年 1 月 16 Xen, 2010 年企画 2010 年 2 月 16 レンタルサーバでの利 用, GAE Man- coosi, keysign 2009 年 6 月 18 Debian Live, bash 2009 年 7 月 30? OSC2009Kansai 2009 年 8 月 14 DDTSS, lintian 2009 年 9 月 14 reportbug, gdb, packaging 2009 年 11 月 35 KOF2009 2009 年 12 月 16 GPS program, Open- OSC2010Kobe 2010 年 4 月 12 デスクトップ環境, 正規 2010 年 5 月 11 ubuntu, squeeze 2010 年 6 月 11 debhelper7, cdbs, puppet mentors 16 30? 表現 debian 2009 年 10 月 2010 年 3 月 StreetMap 2010 年 7 月 40? OSC2010Kyoto 2010 年 8 月 17 emdebian, kFreeBSD 2010 年 9 月 17 タイル WM 2010 年 10 月 12 initramfs, debian live 2010 年 11 月 33 KOF2010 2010 年 12 月 14 Proxmox, annual review 96 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 24 執筆者紹介 本号の執筆に参加したメンバを紹介します。 本庄 弘典 上川 純一 必 要 に 迫 ら れ 自 宅 の 本 を 自 炊 。焼 き 鳥 が oper)、 東京エリア Debian 勉強会創始者。印 好き。 山田 泰資 Debian JP Project Member。Debian JP 副 刷物の完成を眺めるのが結構すき。 森山 京平 会長。DD になって自分のソフトをパッケージ化 NAIST( 奈 良 の 森 の 中 の 大 学 院 )に い る Ubuntu User。 して世界征服するのが野望。これでまた野望に一 杉本 典充 歩近づいた・ ・ ・ ? 野島 貴英 Debian Project Member (Debian Devel- 北海道、関西、東京といろいろな土地で開催 昔 Debian を使って稼いだ経験から、Con- する Debian 勉強会に出没する道民。主に Debian tribution 生活に憧れる。しかしその実態は、典型 GNU/kFreeBSD を使い unstable の醍醐味に浸 IT 土方生活との折り合いをなんとか付けようと る日々を過ごしている。 のがた じゅん Debian Live をこよなく愛す、38 歳無 日々もがくチキン野郎。 まえだ こうへい Debian JP Project Member。Debian 職ニートヒッキーパンクロッカー。 水野 源 JP 会長。あまり人の使わないマイノリティな技 理想のビールを求めて西へ東へ。最近はサッポ 術を Debian で使って、愛猫こまめとヨメとの生 ロクラシックがフェイバリット。Ubuntu Japanese 活をいかに楽にできるかに腐心してる。 Team 所属。 岩松 信洋 倉敷 悟 Debian Project Member (Debian Devel- Debian Maintainer と翻訳で修行している、 oper)。東京エリア Debian 勉強会から輩出された Debian Developer ワナビー。puppet 楽しいよ Debian Developer 1号。子供の影響で鉄分(鉄 puppet。 かわだ てつたろう 道)を多く摂取するようになった。 山本 浩之 Debian JP Project Member。PPC64 を Debian のドキュメント周りに興味 がある関西在住の Debian User。 木下 達也 Debian にポーティングする日々を過ごす休日プ Debian Project Member (Debian Devel- oper)。Wanderlust, Mew, w3m のメンテナ。 ログラマ。 山下 康成 LinkStation /玄箱 を中心にいろいろいじっ ている人。 97 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 25 Debian Trivia Quiz 上川 純一 ところで、みなさん Debian 関連の話題においついていますか?Debian 関連の話題はメーリングリストをよんで いると追跡できます。ただよんでいるだけでははりあいがないので、理解度のテストをします。特に一人だけでは意 味がわからないところもあるかも知れません。みんなで一緒に読んでみましょう。 問題 1. DACA ってなんですか? 問題 6. RC バグの現状ははどこで確認できるか □ A Debian Admin Coaching Association □ A http://bugs.debian.org/release-critical/ □ B Debian を使うと (A) あの子と (C) クリスマスに □ B http://localhost/ (A) アレができるかもしれない □ C http://debianmeeting.appspot.com/ □ C Debian’s Automated Code Analysi project 問題 7. Debian 勉強会予約システムの URL はどれか 問題 2. DebConf11 はいつ開催されるでしょう □ A http://www.2ch.net/ □ A 2011/6/24 - 30 □ B http://atnd.org/events/ □ B 2011/7/24 - 30 □ C http://debianmeeting.appspot.com/ □ C 2011/8/24 - 30 問題 8. [email protected] はどこと統合されたか 問題 3. squeeze の Linux カーネルは一味違います。何 □ A [email protected] が違うでしょう。 □ B [email protected] □ A non-free firmware を排除した □ C [email protected] □ B Tux くんを排除した □ C 一つのカーネルイメージで kFreeBSD と Linux を 問題 9. [email protected] のうらにいないの 提供します は誰か □ A Amaya Rodrigo Sastre 問題 4. 2010/12/17 の時点で RC ハグはいくつあるで □ B Patty Langasek しょう。 □ C Kouhei Maeda □A3 □ B 83 問題 10. 現在いくつかの Sprint が開催され、企画され □ C 183 ている。現在企画すらされていない sprint はどれか □ A -www sprint 問題 5. New Maintianer フロントデスクに追加された □ B security sprint メンバーは? □ C tokyo sprint □ A Xavier Oswald □ B Enrico Zini □ C Kenshi Muto 98 問題 11. DACA はどこを見ればよいか 問題 19. Lars Wirzenius が提案した次のリリースゴー □ A http://qa.debian.org/daca/ ル目標は? □ B http://daca.debian.org/ □ A UTF-8 で動かないパッケージをなくす □ C file:/tmp □ B Debian で動いている人工衛星を打ち上げます □ C 全パッケージを LLVM でビルドします 問題 12. DEP は何の略か □ A Debian Enhancement Proposal 問題 20. 2011 年度 Debian JP 会長は誰でしょうか? □ B Device Enhancement Protocol □ A 前田 耕平 □ C でっぷ □ B 岩松 信洋 □ C 荒木 靖宏 問題 13. DEP5 で提案されている debian/copyright の 機械可読形式はどういうものか 問題 21. 2011 年度 DPL は誰でしょうか? □ A S式 □ A Kurt Roeckx □ B RFC822 風 □ B Kenshi Muto □ C XML □ C Stefano Zacchiroli 問題 14. Debian 6.0 がリリースされたのはいつか? 問題 22. Debian Policy 3.9.2 で追加されていない項目 □ A 2011/02/05 はどれか □ B 2011/02/06 □ A Debian アカウントをメンテナアドレスに追加する □ C 2011/02/07 必要があります。 □ B ア ー キ テ ク チャ依 存 の ラ イ ブ ラ リ 等 は 問題 15. 今回のリリースでサポートされなくなったアー DEB HOST MULTIARCH で取得した値を利用する キテクチャは? 必要があります。 □ A m68k, ppc64 □ C 全てのパッケージは VCS で管理する必要があり □ B alpha, arm, hppa ます。 □ C blackfin, microblaze 問題 23. DebConf chairs に指名されたのは誰? 問題 16. www.debian.org のデザインが変更されまし □ A Gunnar Wolf た。何年同じデザインを使っていたか? □ B Maeda Kouhei □ A 11 年 □ C Junichi Uekawa □ B 12 年 問題 24. ries.debian.org で取得できるようになったデー □ C 13 年 タは? 問題 17. 次のリリースコードネームは何か? □ A debian.org の稼働状況データ □ A rc □ B debian.org の ML データを gzip で固めた物 □ B spell □ C dak のデータ □ C wheezy 問題 25. /run が消された理由は? 問題 18. 今度行われる FTP-master 会議で議論されな □ A /go のほうがよくね?という人が現れた。 い予定は? □ B initscripts がまだサポートしてない! □ A パッケージ自動サイン機構 □ C /run を入れたのはパッケージングミスです。 □ B クロスコンパイルサポート 問題 26. HPPA と alpha の移転先はどこでしょうか? □ C md5sum と shaXsum をとっぱらう □ A buildd.debian.or.jp □ B buildd.debian-ports.org □ C www.buildd.net 99 問題 27. linux カーネル 2.6.39 が Debian に入ることに よって起きる変更は? 問題 29. Debian のサーバに追加された機能は? □ A i386-bigmem が i386-pae になった □ A ログインしているユーザを IRC に流す機能 □ B amd64 が i386 になった □ B RFC1149 の実装 □ C i386 は amd64 のマルチバイナリになった □ C DNSSEC 問題 28. Qt3 パッケージが削除されない理由は? □ A Qt3 ユーザによる哀願のため □ B LSB 4.1 が Qt3 を必要としているため □ C 削除の仕方がわからない 100 101 Deb 専(旧あんどきゅめんてっど でびあん)2011 年夏号 26 Debian Trivia Quiz 問題回答 上川 純一 Debian Trivia Quiz の問題回答です。あなたは何問わかりましたか? 1. C 2. B 3. A 4. C 5. A 6. A 7. C 8. A 9. C 10. C 11. A 12. A 13. B 14. A 15. B 16. C 17. C 18. B 19. A 20. A 21. C 22. C 23. A 24. C 25. B 26. B 27. A 28. B 29. C 102 『あんどきゅめんてっど でびあん』について 本書は、東京および関西周辺で毎月行なわれている『東京エリア Debian 勉強会』および『関 西エリア Debian 勉強会』で使用された資料・小ネタ・必殺技などを一冊にまとめたものです。 収録範囲は東京エリアは 2010 年 12 月勉強会 (第 71 回) から 2011 年 05 月勉強会 (第 77 回)、 関西エリアは第 42 回から第 47 回 まで。内容は無保証、つっこみなどがあれば勉強会にて。 あんどきゅめんてっど でびあん 2011 年夏号 2011 年 08 月 13 日 初版第 1 刷発行 東京エリア Debian 勉強会/関西エリア Debian 勉強会 (編集・印刷・発行)
© Copyright 2024 Paperzz