Tweet

今回は、ディストリビューションに含まれているプログラムのソースコードを確認するための手順について紹介します。

この連載は主に RHEL ユーザーを想定していますが、今回は業務利用している RHEL サーバー上で作業するのではなく、自分のデスクトップ PC　上に仮想化環境で動作する CentOS サーバーをインストールして自分で作業するというケースを想定しているため、 CentOS ユーザー向けの手順で紹介します。

まず、 yum コマンドを使って yum-utils パッケージと rpm-build パッケージをインストールしてください。（既にインストールされているようであれば、無視して次へ進んでください。）

# yum -y install yum-utils rpm-build

次に、ソースコードパッケージをダウンロードするためのレポジトリとして、/etc/yum.repos.d/CentOS-Source.repo を作成します。 CentOS 6 の場合は、以下のような内容になります。

---------- /etc/yum.repos.d/CentOS-Source.repo の内容例　ここから ----------
[base-source]
name=base-source
baseurl=http://vault.centos.org/6.6/os/Source/
gpgcheck=1

[updates-source]
name=updates-source
baseurl=http://vault.centos.org/6.6/updates/Source/
gpgcheck=1
---------- /etc/yum.repos.d/CentOS-Source.repo の内容例　ここまで ----------

次に、ソースコードを見たいプログラムのソースパッケージをダウンロードします。
対象となるプログラムがどのパッケージに含まれているのかを rpm コマンドを使って確認します。ここでは、 /bin/cat のソースコードを見たいと仮定します。

$ rpm -qf /bin/cat
coreutils-8.4-37.el6.x86_64

確認したら、 yumdownloader コマンドを使って、当該パッケージのソースパッケージをダウンロードします

$  yumdownloader --source coreutils-8.4-37.el6

ダウンロードしたソースパッケージが破損して（あるいは改ざんされて）いないかどうかを rpm コマンドを使って確認します。出力される内容はパッケージにより異なる場合がありますが、英語のメッセージの場合には以下の2つを確認してください。

1. 出力の中に pgp が含まれていること
2. 出力の中に NOT または MISSING が含まれていないこと

（良い結果の例）

$ rpm --checksig coreutils-8.4-37.el6.src.rpm
coreutils-8.4-37.el6.src.rpm: rsa sha1 (md5) pgp md5 OK

（悪い結果の例）

$ rpm --checksig coreutils-8.4-37.el6.src.rpm
coreutils-8.4-37.el6.src.rpm: RSA sha1 ((MD5) PGP) md5 NOT OK (MISSING KEYS: (MD5) PGP#c105b9de)

良い結果の例のようになっていることを確認後、当該パッケージをビルドするのに必要なパッケージを yum-builddep コマンドを使ってインストールします。

# yum-builddep -y coreutils-8.4-37.el6.src.rpm

次に、当該パッケージをインストールします。

$ rpm -ivh coreutils-8.4-37.el6.src.rpm

rpm コマンドが終了すると、 ~/rpmbuild/SPECS/ の配下に rpmbuild コマンドに指定するためのファイルがインストールされていますので、 rpmbuild コマンドを使って展開します。

$ rpmbuild -bp ~/rpmbuild/SPECS/coreutils.spec

rpmbuild コマンドが終了すると、 ~/rpmbuild/BUILD/ の配下にソースコードが展開されていますので、 grep やテキストエディタなどを用いて確認できます。
/bin/cat のソースコードは ~/rpmbuild/BUILD/coreutils-8.4/src/cat.c です。
（例外として、ビルド中にソースコードを展開するパッケージも存在しており、そのようなパッケージの場合には -bp の代わりに -bb を指定する必要があります。）

なお、 CentOS 5 の場合、 ~/rpmbuild/ ディレクトリの代わりに /usr/src/redhat/ディレクトリが使われること、および、 /usr/src/redhat/ ディレクトリ配下には一般ユーザーは書き込みを行えないことから root ユーザーでインストールおよび展開する必要があること以外は、ほとんど同様の手順で行うことができます。

---------- /etc/yum.repos.d/CentOS-Source.repo の内容例　ここから ----------
[base-source]
name=base-source
baseurl=http://vault.centos.org/5.11/os/SRPMS/
gpgcheck=1

[updates-source]
name=updates-source
baseurl=http://vault.centos.org/5.11/updates/SRPMS/
gpgcheck=1
---------- /etc/yum.repos.d/CentOS-Source.repo の内容例　ここまで ----------

$ rpm -qf /bin/cat
coreutils-5.97-34.el5_8.1
$ yumdownloader --source coreutils-5.97-34.el5_8.1
$ rpm --checksig coreutils-5.97-34.el5_8.1.src.rpm
coreutils-5.97-34.el5_8.1.src.rpm: (sha1) dsa sha1 md5 gpg OK
# yum-builddep -y coreutils-5.97-34.el5_8.1.src.rpm
# rpm -ivh coreutils-5.97-34.el5_8.1.src.rpm
# rpmbuild -bp /usr/src/redhat/SPECS/coreutils.spec

ソースコードを確認する手順を知っていると、表示されたメッセージから問題の発生箇所を自力で探すことができるようになります。せっかくのオープンソースソフトウェアなのですから、何でもかんでもサポート担当者に丸投げするのではなく、自分でできそうなところは自分で頑張ってみませんか？

（半田哲夫）

コーヒーブレーク「肝を冷やすことノススメ」

先日、肝を冷やす出来事がありました。それについてご紹介したいと思います。
私は Amazon の電子書籍リーダー、 Kindle を使っています。週末、自宅で本を読もうと思ったときに端末がないことに気がつきました。その日の行動を振り返り、デパートに買い物に行って支払いをしたときに置き忘れたに違いないという結論に達しました。そして、ほとんど無意識で考えたのは、起こり得る被害のことです。

「被害」リストの筆頭は端末が見つからず失ってしまうことですが、それだけではすみません。私の端末は 3G 回線に対応したモデルです。過去、Kindleストアで書籍を購入しているため、支払い情報がクラウドに保存されています。かつ、端末にはパスワードを設定していません。つまり、他の人の手にわたれば誰でも書籍を購入できて、支払い請求がきてしまうことになります。その他、購入済みの本や自分で端末に保存した PDF ファイルも読まれてしまいます。起こり得る被害についてリアルにシミュレーションすることにより、身体がざわっとなり、一瞬周囲の音が聞こえなくなりました（読者の方も同様のご経験があるかと思います）。

落とし物として届いていないか確認しようと思い、レシートに印刷されていた電話番号に電話すると、それらしいものがあるという返事でした。取るものも取りあえず、デパートにとんぼ返りして、電話で聞いた窓口に行きました。すると、色々聞かれます。「色は？」「カバーは？」「大きさは？」それらには答えられるのですが、所有者であることを示す決めてがありません。緊張感にみちたやりとりが続くなか、ついに「ケースのポケットにレシートが入っているが、何のレシートですか？」というカルトな質問になり、見事それに正解して自分のKindleを取り戻すことができました。（拍手こそありませんでしたが、なかなか感動的な状況でした）

長々と自分のことを書いたのは、この件を通じて得られた教訓をご紹介したいからです。私は端末にパスワードをかけられることを知らなかったわけではありません。端末が他の人の手に渡れば書籍を購入できることも同様です。ただ、単に毎回パスワードを入力するのがめんどうくさいと考えていたわけであり、どこかに「自分は端末を置き忘れたりはしない」という根拠のない自信がありました。今回、「実際に」端末を失うという経験をしたことにより初めて、あまり意識していなかった影響や被害に直面したわけです。

起こっていないトラブルを想像するのは、一種のシミュレーションです。
それを漠然とではなく、「実際に起こったら」として考えてみるのは、容易なことではありません（私が端末を失うことを真剣に考えられなかったように）。しかし、あなたが重要な何かを守る立場にあるのであれば、それを行う必要があります。想像力を駆使して、リアルに、真剣にシミュレーションを重ねることにより、「将来起こるかもしれない」トラブルを未然に防ぎ、被害を軽減することができます。

本コラムもおかげさまで、今回で 10 回を数えました。最初の記事は「 kdump ノススメ」で、カーネルパニックが発生した場合のことを扱っています。この記事はたまたま初回になっているわけではありません。また、 kdump が実行できない場合も現実に起こった事象をもとにしています。すべての記事の裏には、実際に起こったトラブルが存在しています。私が担当しているコーヒーブレークも同様で、日々のサポート業務を通じて、大切と思うことをテーマとして取り上げています。是非、今一度第一回から「これは本当に起こったことであり、起こるかもしれないこと」と思って、記事を読み直していただければと思います。そうすると新しい発見があるかもしれません。どうか肝を冷やしてみてください。

「そう書いている自分はどうなんだ？」ですって？
大丈夫です。私も毎回次の記事に書くことがなかったらどうしようとか、締め切りに間に合わなかったらどうしようと肝を冷やしています。
と、書いていたら胃がきりきりしてきました。では、また次回お会いしましょう（それまであなたのシステムが平和でありますように！）。

P.S.　私の Kindle には現在パスワードが設定され、カバーのポケットには名刺が入っています

（原田季栄）

Tweet

---

• Hinemos関連サービス
• Hinemos