カスタムRPMや独自yumリポジトリではじめるソフトウェア管理術

　Red Hat系のLinuxディストリビューションでは、RPMパッケージという形式でソフトウェアが配布されており、yumコマンドを利用してパッケージをインストールしたり、アップデートを行うことができる。今回は既存のRPMパッケージをカスタマイズして独自のパッケージを作成したり、独自のyumリポジトリを作成してパッケージ管理を行う方法を紹介しよう。

プライベートyumリポジトリを活用してサーバーをデプロイする
独自のRPMパッケージを作成する
独自のyumリポジトリを作成する
設定ファイルのインストールなどにも積極的に利用したいRPM

プライベートyumリポジトリを活用してサーバーをデプロイする

　Ret Hat Enterprise LinuxやCentOSといったRed Hat系のLinuxディストリビューションでは、RPMパッケージ（ファイルの拡張子は.rpm）を使ってソフトウェアをインストールするのが一般的だ。

　RPMは「RPM Package Manager」の略で、Red Hatが開発したことから当初は「Red Hat Package Manager」と呼ばれていた。現在ではRed Hat以外のLinuxディストリビューションでも採用されており、独自のコミュニティでの開発が行われている（図1）。

　RPMを採用するディストリビューションではソフトウェアがRPMパッケージで提供され、yumコマンドやrpmコマンドを利用して簡単にソフトウェアをインストールできる。

　しかし、ディストリビューションが提供している以外のソフトウェアを利用したい場合や、提供されているものよりも新しいバージョンのソフトウェアを利用したい場合、また独自にカスタマイズしたソフトウェアを利用したい場合もあるだろう。このような場合、そのソフトウェアのRPMパッケージを独自に作成してインストールすることが推奨されている。

　RPMパッケージを利用するメリットとしては、まずソフトウェアの依存関係を自動的に管理してくれる点がある。これにより、依存するソフトウェアやライブラリを自動的にインストールしたり、ファイルのアンインストールやアップデート時にインストールされていたファイルを安全に削除する、といったことが可能になる。また、必要なパッケージをうっかり削除してしまうというようなミスを防ぐこともできる。

　さらに、作成したパッケージは容易にほかのサーバーへとインストールできる。yumコマンドでRPMパッケージをインストールする場合、通常はディストリビューションの開発元が提供するサーバーやそのミラーサーバーからRPMファイルがダウンロードされるが、yumコマンドの設定を変更することで、サーバー管理者が独自に作成したリポジトリからパッケージをダウンロードしてインストールすることもできる。複数台のサーバーを管理している場合、作成したパッケージを独自のリポジトリで公開し、各サーバーはそのリポジトリを参照するように設定しておけば、容易に複数のサーバーにソフトウェアをインストールしたり、アップデートを行うことが可能になる。

　以下ではこのようなRPMパッケージを用いたサーバーのデプロイを行うために必要となる独自のRPMパッケージおよびyumリポジトリの作成方法について解説する。

独自のRPMパッケージを作成する

　RPMパッケージの作成には、パッケージを作成するための「rpmbuild」と呼ばれるツールと、パッケージを作成するソフトウェアのソースコード、そしてspecファイルと呼ばれる設定ファイルが必要となる。これらを利用して独自のRPMパッケージを作成する流れは以下のようになる。

作成するパッケージのソースアーカイブやパッチファイル、設定ファイルなどを用意する
パッケージ作成手順やパッケージ情報を記載したspecファイルを作成する
rpmbuildコマンドを実行してパッケージを作成する

　以下では、これらの流れを簡単に紹介していこう。

RPMパッケージの作成環境を整える

　rpmbuildは「rpm-build」という名称のパッケージで提供されている。まずはこれをインストールしておく。

# yum install rpm-build

　rpmbuildコマンドのデフォルト設定では、RPMファイルの作成にホームディレクトリ以下の「rpmbuild」というディレクトリや表1のサブディレクトリを使用する。これらのディレクトリは後述するソースパッケージのインストール時やrpmbuildコマンドの実行時に必要に応じて自動的に作成される。

表1 rpmbuildディレクトリの内容
ディレクトリ名	説明
BUILD	パッケージの作成時に使われるディレクトリ。ソースコードなどはこのディレクトリ以下に展開される
BUILDROOT	パッケージの作成時に使われるディレクトリ。ビルドされたバイナリなどがこのディレクトリ以下に格納される
RPMS	作成されたバイナリパッケージが格納されるディレクトリ
SOURCES	パッケージ作成に必要なTarballやパッチなどを格納するディレクトリ
SPECS	specファイルを格納するディレクトリ
SRPMS	作成されたソースパッケージが格納されるディレクトリ

　パッケージを作成するソフトウェアのソースコードについては、配布されているtar.gz形式などのアーカイブ形式（Tarballなどと呼ばれる）のままで良い。アーカイブの展開などはrpmbuildコマンドが自動的に実行してくれるからだ。そのほかパッチなどが必要な場合はそれぞれ用意しておく。これらのファイルは、rpmbuildディレクトリ内のSOURCESディレクトリ内に格納しておく。

　また、specファイルはパッケージの作成に必要な情報が記述されたテキストファイルで、テキストエディタで作成・編集できる。specファイル中にはパッケージの名称やバージョン番号、依存するパッケージといったパッケージ自体の情報だけでなく、ソースファイルをどのようにビルドするか、またビルド時にどのように設定を行うかといった情報、そしてパッケージに含めるファイル一覧といった情報も記述されている。作成したspecファイルは、rpmbuildディレクトリ中のSPECSディレクトリ内に格納しておく。

ソースパッケージからspecファイルを取り出す

　RPMパッケージを作成する際の「設計図」とも言えるspecファイルだが、これを一から作成しようとするとそれなりに手間がかかる。そのため、既存のパッケージをカスタマイズする場合はまずはそのspecファイルを入手し、それを元にカスタマイズしていくことをおすすめする。

　既存のパッケージをカスタマイズする場合は、そのソースパッケージ（「SRPM」とも呼ばれる。拡張子は.src.rpm）を利用する。RPMファイルからTarballやspecファイルを取り出すことはできないので注意してほしい。SRPMファイルはディストリビューションのリポジトリからダウンロードできる。たとえばCentOS 5.8の場合、「http://vault.centos.org/6.4/os/Source/」や「http://vault.centos.org/6.4/updates/Source/」といった公開ディレクトリから入手可能だ。また、yum-utilsというパッケージに含まれるyumdownloaderというコマンドでもSRPMファイルを入手できる。

# yum install yum-utils

　yumdownloaderを利用する場合、このyum-utilsパッケージをインストールしたうえで、SRPMファイルの入手先リポジトリを設定しておく必要がある。たとえばCentOS 6.4の場合、/etc/yum.repos.d/CentOS-Source.repoというファイルを作成し、以下のような内容を記述しておけばよい。

[base-Source]
name=CentOS-6.4 - Base - Source
baseurl=http://vault.centos.org/6.4/os/Source/
gpgcheck=0

[updates-Source]
name=CentOS-6.4 - Updates - Source
baseurl=http://vault.centos.org/6.4/updates/Source/
gpgcheck=0

　たとえばtarパッケージのSRPMファイルをダウンロードするには、以上の設定を行った状態でyumdownloaderコマンドを次のように実行すれば良い。

$ yumdownloader --source tar

　これで、対応するSRPMファイルがダウンロードされ、コマンドを実行したディレクトリ内に保存される。

　ダウンロードしたSRPMファイルは、次のようにrpmコマンドでインストールすることで、specファイルやソースファイルを取り出すことができる。

$ rpm -ivh ＜SRPMファイル＞

　このとき、rpmコマンドはroot権限ではなく一般ユーザー権限で実行する点に注意したい。RPMパッケージの作成は一般ユーザー権限で実行するのが慣例となっているからだ。

　ソースパッケージをインストールすると、rpmbuildディレクトリ以下にspecファイルやソースコードのTarballなどが格納される。あとは必要に応じてspecファイルを修正したり、パッチなどを追加すれば良い。

specファイルの作成/編集

　続いて、RPMパッケージ作成のキモとなるspecファイルについて説明していこう。具体的にspecファイルへ記述する内容は以下のようなものだ。

パッケージの説明やバージョンなどの情報
RPMパッケージのビルドに必要なソースファイル
パッケージが依存するパッケージ
ビルド手順
パッケージに含めるファイル一覧
パッケージのチェンジログ

　rpmbuildコマンドはこのspecファイルに記述された情報を元に、ソースコードのコンパイルや、コンパイル時の設定、パッケージに含めるファイルの決定といった処理を実行する。specファイルではさまざまなマクロやコマンドを利用して、これらの情報を記述していくことになる。

　なお、specファイルに記述できるマクロやコマンドは非常に多く、今回そのすべてを解説することはできないので、以下ではその一部を述べるだけにとどめておく。より詳しい詳細についてはFedoraプロジェクト内にあるドキュメント（Packagers Guide）を参照すると良いだろう。

パッケージ情報の記述

　パッケージの説明やバージョンといった情報は、ファイル先頭に記述する。たとえばUNIX系OSではおなじみtarコマンドのspecファイル（tar.spec）の場合、以下のようにパッケージの要約（サマリ）や名称、バージョンといった情報が定義されている。

Summary: A GNU file archiving program
Name: tar
Epoch: 2
Version: 1.23
Release: 11%{?dist}
License: GPLv3+
Group: Applications/Archiving
URL: http://www.gnu.org/software/tar/

バージョン番号とリリース番号、エポック番号

　specファイル内では、パッケージのバージョンを示すものとして「Version」と「Release」、「Epoch」がある。「Version」はパッケージの元となるソースファイルに付けられたバージョン番号（アップストリームのバージョン番号）を示すものだ。また、「Release」はパッケージのバージョンを示すものとなる。元にしたソースファイルのバージョンはそのままで、パッケージのみを更新した場合はReleaseの番号を更新する形になる。

　「Epoch」はパッケージの新旧を比較するために使われる数値で、指定されていない場合は「0」と見なされる。rpmコマンドやyumコマンドでパッケージをアップデートする場合、通常はVersionやReleaseの値の大小を比較してバージョンの新旧をチェックするのだが、Epochの値が指定されていた場合は、この値の大小でバージョンの新旧がチェックされる。つまり、VersionやReleaseの値が古い（数値が小さい）場合でも、Epochの値が大きければそちらのパッケージがより新しいものと認識される。

　Epochは通常パッケージ名には表示されないため、利用するとバージョンの新旧が判別しにくくなる。そのため、明示的に古いバージョンのものをインストールさせたい場合などを除き、利用は基本的には推奨されていない。

必要なソースファイルや依存パッケージの記述

　RPMパッケージのビルドに必要なソースファイルは次のように「Source」や「Patch」といった行で指定する。

Source0: ftp://ftp.gnu.org/pub/gnu/tar/tar-%{version}.tar.bz2
Source1: ftp://ftp.gnu.org/pub/gnu/tar/tar-%{version}.tar.bz2.sig
#Manpage for tar and gtar, a bit modified help2man generated manpage
Source2: tar.1
#Stop issuing lone zero block warnings
Patch1: tar-1.14-loneZeroWarning.patch
#Fix extracting sparse files to a filesystem like vfat,
#when ftruncate may fail to grow the size of a file.(#179507)
Patch2: tar-1.15.1-vfatTruncate.patch
　　：
　　：

　依存パッケージは「Requires:」や「BuildRequires:」といった行で指定する。「Require:」にはパッケージのインストール時に必要となるパッケージを、「BuildRequires」にはパッケージのビルド時に必要となるパッケージを列挙する。

Requires: info
BuildRequires: autoconf automake gzip texinfo gettext libacl-devel gawk rsh

ビルド手順の記述

　RPMパッケージの作成は、「prep」および「build」、「install」、「check」、「clean」という段階を踏んで行われる（表2）。

表2 RPMパッケージの作成における段階
段階名	説明
prep	ソースアーカイブの展開やパッチの適用を行う
build	configureやmakeを実行してソースコードをコンパイルする
install	make installコマンドなどを実行してビルドしたバイナリを作業用ディレクトリにインストールする
check	必要なファイルが用意されているかどうかをチェックする
clean	ビルド時に生成された中間ファイルなどを削除する

　これらの段階で実行する処理は、それぞれ「%prep」や「%build」、「%install」、「%check」、「%clean」といったセクションで定義する。たとえば先のtarパッケージの場合、「%prep」セクションは以下のようになっている。ここでは、「%setup」マクロを使用してSource:行で指定したソースコードを展開し、「%patch」コマンドでPatch:行で指定したパッチをソースコードに展開後、autoreconfコマンドを実行している。

%prep
%setup -q
%patch1 -p1 -b .loneZeroWarning%
%patch2 -p1 -b .vfatTruncate
　：
　：
%patch23 -p1 -b .coredump-hash
autoreconf

　また、「%build」セクションは次のようになっている。ここでは「%configure」マクロでconfigureを実行し、続けてmakeコマンドを実行している。

%build
%configure --bindir=/bin --libexecdir=/sbin \
%if %{WITH_SELINUX}
  --enable-selinux
%endif
make

　これ以外のセクションも%prepや%buildセクションと同様、マクロやコマンドを記述して実際に行う処理を記述していくことになる。

それ以外のセクション

　specファイル中では先に示した%prepや%buildといったセクションに加えて、「%pre」や「%post」、「%preun」、「%postun」などのセクションを定義できる。これらにはパッケージのインストール前やインストール後、アンインストール前およびアンインストール後に実行する処理を記述する。詳しくはドキュメントなどを参照してほしい。

パッケージに含めるファイルの指定

　「%files」セクションでは、パッケージに含めるファイルのリストをそのフルパスで記述する。ここでは%{_bindir}や%{_mandir}といったマクロ変数やワイルドカードも利用可能だ。たとえばtarパッケージの場合、以下のようになっている。

%files -f %{name}.lang
%defattr(-,root,root)
%doc AUTHORS ChangeLog ChangeLog.1 NEWS README THANKS TODO
%ifos linux
/bin/tar
/bin/gtar
%{_mandir}/man1/tar.1*
%{_mandir}/man1/gtar.1*
%else
%{_bindir}/*
%{_libexecdir}/*
%{_mandir}/man*/*
%endif

%{_infodir}/tar.info*

チェンジログの記述

　specファイルの最後には、パッケージのチェンジログを記載する「%changelog」セクションを記述する。ここでは以下のように、一般的なchangelog形式で日時や著者名、変更点などを記載していく。

%changelog
* Mon Nov 19 2012 Pavel Raiskup <praiskup@redhat.com> - 2:1.23-11
- avoid crash by backporting upstream patch for internal construction of
  file-name hash table (#877769).

specファイルを元にパッケージをビルドする

　specファイルからパッケージをビルドするには、specファイルを引数にしてrpmbuildコマンドを実行する。

$ rpmbuild -ba ＜specファイル＞

　なお、ここで指定している「-ba」オプションは、バイナリパッケージとソースコーパッケージの両方を生成させるためのオプションだ。もしバイナリパッケージのみが必要な場合は代わりに「-bb」を、ソースパッケージだけが必要な場合は「-bs」を指定する。

　また、これらの代わりに「-bp」や「-bc」、「-bi」、「-bl」オプションを指定すると、specファイル中で定義された「prep」や「build」、「install」、「check」の処理までがそれぞれ実行される。これらはパッケージ作成作業のデバッグなどに有用だ。

　rpmbuildコマンドを実行すると、指定したオプションに応じてファイルの展開やビルド、バイナリパッケージやソースパッケージの生成などが行われる。成果物はrpmbuildディレクトリ中のRPMSやSRPCS、BUILDROOTディレクトリなどに生成される。

RPMパッケージに署名を行う

　RPMには作成者やパッケージの改変を検証するため、RPMパッケージに署名を行う機能が用意されている。署名が行われていないRPMパッケージでもインストールは可能だが、yumコマンドでRPMパッケージをインストールする場合、デフォルトでは署名されていないパッケージはインストールできない。そのため、パッケージに署名を行う方法についても解説しておこう。

　RPMパッケージに署名を行うには、GnuPG（gpg）が必要だ。gpgはyumコマンドでインストールできる。

# yum install gpg

　gpgをインストールしたら、続いて「gpg --gen-key」コマンドを実行して署名に必要な鍵を生成する。

$ gpg --gen-key

　鍵の生成時、いくつかの質問に答える必要があるが、基本的にはデフォルトの設定（何も入力せずにEnterキーを入力）で構わない。生成した鍵の情報は、「gpg --list-keys」オプションで確認できる。

$ gpg --list-keys
/home/hylom/.gnupg/pubring.gpg
------------------------------
pub   2048R/4924CD0B 2013-06-28
uid                  Hiromichi Matsushima <hylom@hylom.net>
sub   2048R/0516826B 2013-06-28

　作成した鍵の公開鍵は、「gpg --export -a '＜鍵の所有者名＞'」コマンドで適当なファイルにエクスポートできる。たとえば「Hiromichi Matsushima」の公開鍵をエクスポートして「RPM-GPG-KEY-hylom」というファイルに保存する場合、以下のようになる。

$ gpg --export -a 'Hiromichi Matsushima' > RPM-GPG-KEY-hylom

　続いて、エクスポートした公開鍵を「rpm --import ＜公開鍵ファイル＞」コマンドでRPMが使用するデータベースに登録する。たとえば先の例で「RPM-GPG-KEY-hylom」というファイルにエクスポートした鍵が保存されている場合、以下のようにする。

# rpm --import RPM-GPG-KEY-hylom

　以上で鍵の準備は完了だ。なお、RPMのデータベースに登録されている公開鍵一覧は下記のようにして確認できる。

$ rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
gpg-pubkey-c105b9de-4e0fd3a3 --> gpg(CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>)
gpg-pubkey-4924cd0b-51cd58e4 --> gpg(Hiromichi Matsushima <hylom@hylom.net>)

　最後に、RPMのマクロ設定ファイルである~/.rpmmacrosに下記の内容を追加しておく。

%_signature gpg
%_gpg_name ＜鍵の所有者名＞

　~/.rpmmacrosファイルが存在しない場合は、適宜作成してこの内容を記述すればよい。また、鍵の所有者名には鍵の作成時に入力した名前を指定する。

　以上の設定が完了したら、「rpm --addsign ＜署名するRPMパッケージファイル＞」コマンドでRPMパッケージに署名を行えるようになる。たとえばnodejs-0.10.12-private1.x86_64.rpmというRPMファイルに署名をする場合、以下のようになる。

$ rpm --addsign nodejs-0.10.12-private1.x86_64.rpm
パスフレーズの入力: ←パスフレーズを入力
パスフレーズは正常です。
nodejs-0.10.12-private1.x86_64.rpm:

　署名を検証するには、以下のように「rpm --checksig ＜パッケージファイル＞」コマンドを実行する。

$ rpm --checksig nodejs-0.10.12-private1.x86_64.rpm
nodejs-0.10.12-private1.x86_64.rpm: rsa sha1 (md5) pgp md5 OK

独自のyumリポジトリを作成する

　さて、前述の手順で作成した独自のRPMパッケージは、ディストリビューション公式のパッケージと同様に、rpmコマンドでのインストールやアンインストールが可能だ。しかし、作成したパッケージを複数のサーバーで利用したい場合、いちいちそれぞれのサーバーにパッケージファイルをコピーしてからインストール作業を実行するのは手間である。rpmコマンドにはHTTPやFTPを使ってリモートサーバー上にあるファイルを取得し、直接インストールする機能も備えられているものの、いちいちフルパスを含むURLを指定する必要がある。このような場合に有用なのが、独自のyumリポジトリを作成してRPMパッケージを配置し、パッケージを利用するサーバーからはyumコマンドを使ってパッケージのインストールを行う、というやり方だ。

　独自のyumリポジトリを利用するメリットとしては、次のものが挙げられる。

バージョン番号までを含めたパッケージファイル名をいちいち指定する必要がない
パッケージグループや依存性の設定により、複数のパッケージを一括してインストールできる
パッケージを更新した際のアップデートが容易

　yumコマンドには、利用できるパッケージのなかで最も新しいものを自動的に探索してインストールする機能を備えている。そのため、パッケージのインストール時にはパッケージ名のみを指定すれば良い。また、yum updateコマンドを実行することで、インストールされているパッケージでより新しいものが利用できる場合は自動的にパッケージの更新を行える。特に管理対象とするサーバーの台数が多い場合などに有用だ。

yumリポジトリの構造とyumコマンドの仕組み

　独自yumリポジトリについて説明する前に、まずはyumリポジトリの構造やyumコマンドの動作について解説しておこう。

　yumリポジトリは通常、HTTPもしくはFTPでファイルを公開する。特殊なHTTPサーバーやFTPサーバーは不要で、Apacheなどの一般的なWebサーバーがファイルの公開に利用される。

　yumリポジトリで公開されている必要があるのは、公開するRPMパッケージファイルと、リポジトリの情報が格納されている「repomd.xml」ファイル、そして提供するパッケージの情報が格納されたデータベースファイルだ。repomd.xmlファイルやデータベースファイルはまとめて「メタデータファイル」などとも呼ばれる。メタデータファイルはRPMパッケージファイルが納められているディレクトリ内に「repodata」というサブディレクトリが作成されて納められるのが一般的だ。

　yumコマンドは、そのファイルを参照して有効化されているリポジトリのURLを取得し、リポジトリサーバーにアクセスしてrepomd.xmlファイルを取得する。続いてrepomd.xmlファイル内で指定されているデータベースファイルを取得して読み込み、利用可能なパッケージを確認する。有効化されているリポジトリすべてに対してこの処理を実行したのち、yumコマンドはコマンドラインで指定された処理に応じてデータベースを確認し、最新のパッケージを探索してダウンロードおよびインストールを実行する。

　なお、yumコマンドでは通常/etc/yum.repos.dディレクトリ内に格納されているリポジトリ設定ファイルを参照して利用するリポジトリを決定する。そのため、独自のリポジトリを利用したい場合、このディレクトリ以下に設定ファイルを配置しておく必要がある。

独自のyumリポジトリを作成する

　yumリポジトリを作成するには、repomd.xmlファイルや各種データベースファイルを作成する「creatrepo」コマンドが必要となる。これは同名のパッケージで提供されているので、これをあらかじめインストールしておこう。

# yum install createrepo

　yumリポジトリを作成するには、公開するRPMファイルが格納されているディレクトリを引数に指定してcreaterepoコマンドを実行する。たとえば/var/www/rpmrepo/x86_64/PackagesというディレクトリにRPMファイルが格納されている場合、以下のように実行する。

# createrepo /var/www/rpmrepo/x86_64/Packages

　すると、引数で指定したディレクトリ内にrepodataディレクトリが作成され、そこにrepomd.xmlなどのメタデータファイルが作成される。

　そのほかrpmbuildコマンドにはリポジトリで公開するファイルを指定する「-i」オプションやリポジトリの更新時に利用できる「--update」オプションなども用意されているので、詳しくはmanページなどを参照してほしい。

　createrepoコマンドでメタデータを作成したら、最後にこれらのディレクトリがHTTPもしくはFTPで公開されるようにすれは設定作業は完了だ。

独自yumリポジトリを利用するよう設定を行う

　作成した独自yumリポジトリにアクセスするには、リポジトリを利用する側（クライアント側）でyumの設定を行う必要がある。yumが利用するリポジトリの情報は、/etc/yum.repos.dディレクトリに格納されている。このファイルはいわゆる「ini形式」で記述されており、最小限下記のものを指定すれば良い。

[＜リポジトリ名＞]
name=＜リポジトリの説明文＞
baseurl=＜リポジトリのURL＞

　「リポジトリ名」には、リポジトリの名前を、「name」にはそのリポジトリを説明する文字列を、「baseurl」にはrepodataディレクトリが存在するディレクトリをURLで指定する。

　たとえば「hylompkgs」という名称で独自のリポジトリを登録する場合、以下のような内容となる。これを適当な名前（たとえば「hylmpkgs.repo」など）で/etc/yum.repos.dディレクトリ内に配置すれば良い。

# hylom's original yum repository
[hylompkgs]
name=hylom's original RPM packages
baseurl=http://hylom.net/rpmrepo/x86_64/

　これで指定したリポジトリがyumコマンドでの探索対象となり、ここからパッケージをインストールできるようになる。

　なお、前述のとおりyumのデフォルト設定では署名の検証ができないRPMパッケージはインストールできない。また、署名がされているRPMパッケージでも、それに対応する公開鍵がローカルにインストールされていない場合はインストールができない。署名がされているRPMパッケージをインストールしたい場合、署名に使用した鍵の公開鍵を以下のようにしてインポートしておく必要がある。

# rpm --import RPM-GPG-KEY-hylom

　また、リポジトリの設定ファイルに下記のように「gpgcheck=0」という設定を追加しておくことで、署名の検証を省略することも可能だ。ただしこの場合、署名されていないRPMパッケージを無制限にインストールできてしまうことになるのでその点には注意したい。

# hylom's original yum repository
[hylompkgs]
name=hylom's original RPM packages
baseurl=http://hylom.net/rpmrepo/x86_64/
gpgcheck=0

公開鍵およびリポジトリ設定ファイルをRPMパッケージとして配布する

　独自に作成したリポジトリを利用する場合、先に述べたとおり/etc/yum.repos.dディレクトリ内の設定ファイルと、公開鍵の設定が必要となる。これらをいちいち手動で実行するのは手間がかかるため、これらのファイルおよび設定を自動で行えるRPMパッケージを作成しておくと便利だ。たとえば、独自のリポジトリ名を「hylompkgs」とした場合、以下のようなspecファイルおよび設定を記載したリポジトリ設定ファイルや公開鍵を用意してRPMパッケージを作成しておけば、このRPMパッケージをインストールするだけでリポジトリが利用可能になる。

Name:           hylompkgs
Version:        6
Release:        0
Summary:        hylom's Original Packages for CentOS

Group:          System Environment/Base
License:        GPLv2

URL:            http://hylom.net/rpmrepo/
Source0:        http://hylom.net/rpmrepo/RPM-GPG-KEY-hylom
Source1:        hylompkgs.repo

BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildArch:     noarch
Requires:      redhat-release >=  %{version}

%description
This package contains hylompkgs repository GPG key and configuration files.

%prep

%build

%install
rm -rf $RPM_BUILD_ROOT

#GPG Key
install -dm 755 $RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg
install -pm 644 %{SOURCE0} $RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg

# yum
install -dm 755 $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
install -pm 644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%config(noreplace) /etc/yum.repos.d/*
/etc/pki/rpm-gpg/*

%changelog
* Fri Jun 28 2013 hylom <hylom@hylom.net> - 6.0
- Create Package

　また、ここで用意するリポジトリ設定ファイルの例は以下のようになる。

# hylom's original yum repository

[hylompkgs]
name=hylom's original RPM packages
baseurl=http://hylom.net/rpmrepo/x86_64/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-hylom
enabled=1
gpgcheck=1

　ちなみにこのリポジトリ設定ファイル中の「gpgkey=」項目は、使用する公開鍵ファイルを指定するものだ。この設定を行っておくと、リポジトリからのパッケージインストール時に自動的に指定された公開鍵ファイルがインポートされるようになる。

設定ファイルのインストールなどにも積極的に利用したいRPM

　RPMファイルを作成するのに必要となるspecファイルの編集にはやや知識が必要であるが、既存のspecファイルを編集するだけならそんなに難しいことはない。

　また、RPMはソフトウェアをインストールするための仕組みだと思われていることが多いが、実際にはソフトウェアだけでなく、任意のスクリプトや設定ファイルなど、さまざまなファイルのインストールが可能だ。また、インストール/アンインストール時に任意のコマンドやスクリプトを実行してシステムの設定などを実行することも可能だ。これをうまく利用することで、厳格にサーバーのソフトウェア/ファイル管理を行うことが可能になる。

　ソフトウェアをRPMファイル化してからインストールすることで、圧倒的にファイルの管理が楽になる。たとえばWebサーバーなどをカスタマイズした設定でビルドする場合や複数台に同じ設定ファイルをインストールするといった場合には、ぜひRPMを活用してみてほしい。