20年以上前にLinuxを使い始めて以来、rpmベースのパッケージマネージャーを使用してRedHatとFedoraLinuxにソフトウェアをインストールしてきました。 rpmを使用しました プログラム自体、 yum 、および DNF 、yumの子孫であり、Linuxホストにパッケージをインストールおよび更新します。 yumツールとDNFツールは、パッケージの依存関係を見つけてインストールする機能など、追加機能を提供するrpmユーティリティのラッパーです。
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース：RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか？
- 最新のLinux記事
何年にもわたって、私はいくつかのBashスクリプトを作成しましたが、そのうちのいくつかには個別の構成ファイルがあり、ほとんどの新しいコンピューターと仮想マシンにインストールするのが好きです。これらすべてのパッケージをインストールするのにかなりの時間がかかるようになったので、ターゲットホストにコピーしてこれらすべてのファイルを適切な場所にインストールできるrpmパッケージを作成することにより、そのプロセスを自動化することにしました。 rpm ツールは以前はrpmパッケージのビルドに使用されていましたが、その機能は削除され、新しいツール rpmbuild 新しいrpmを構築するために作成されました。
このプロジェクトを開始したとき、rpmパッケージの作成に関する情報はほとんど見つかりませんでしたが、 Maximum RPMという本を見つけることができました。 、それは私がそれを理解するのに役立ちました。私が見つけた情報の大部分がそうであるように、その本は今やや時代遅れです。また絶版であり、使用済みのコピーは数百ドルになります。 Maximum RPMのオンラインバージョンは無料で利用でき、最新の状態に保たれています。 RPM Webサイトには、rpmに関する多くのドキュメントがある他のWebサイトへのリンクもあります。他にどのような情報があるかは簡潔である傾向があり、プロセスについてすでに十分な知識があることを前提としているようです。
さらに、私が見つけたすべてのドキュメントは、開発環境の場合と同様に、コードをソースからコンパイルする必要があることを前提としています。私は開発者ではありません。私はシステム管理者ですが、管理タスクに使用するコードをコンパイルしない、またはコンパイルすべきではないため、システム管理者にはさまざまなニーズがあります。シェルスクリプトを使用する必要があります。したがって、バイナリ実行可能ファイルにコンパイルする必要があるという意味で、ソースコードはありません。私たちが持っているのは、実行可能ファイルでもあるソースです。
ほとんどの場合、このプロジェクトは非rootユーザーの学生として実行する必要があります。 Rpmはrootによってビルドされるべきではなく、非特権ユーザーによってのみビルドされるべきです。ルートとして実行する必要のある部分と、ルート以外の非特権ユーザーが実行する必要のある部分を示します。
準備
まず、1つのターミナルセッションを開き、su ルートに。必ず-を使用してください 完全なルート環境が有効になっていることを確認するオプション。システム管理者がsudoを使用する必要があるとは思わない 管理タスク用。私の個人的なブログ投稿で理由を確認してください：実際のシステム管理者はsudoを実行しません 。
[student@testvm1 ~]$ su -
Password:
[root@testvm1 ~]#
このプロジェクトに使用できる学生ユーザーを作成し、そのユーザーのパスワードを設定します。
[root@testvm1 ~]# useradd -c "Student User" student
[root@testvm1 ~]# passwd student
Changing password for user student.
New password: <Enter the password>
Retype new password: <Enter the password>
passwd: all authentication tokens updated successfully.
[root@testvm1 ~]#
rpmパッケージをビルドするには、rpm-buildが必要です パッケージ。まだインストールされていない可能性があります。今すぐrootとしてインストールします。このコマンドは、いくつかの依存関係もインストールすることに注意してください。数は、ホストにすでにインストールされているパッケージによって異なる場合があります。テストVMに合計17個のパッケージがインストールされましたが、これはごくわずかです。
dnf install -y rpm-build
このプロジェクトの残りの部分は、特に明示的に指示されていない限り、ユーザー学生として実行する必要があります。別のターミナルセッションを開き、suを使用します そのユーザーに切り替えて、これらの残りの手順を実行します。次のコマンドを使用して、GitHubから開発ディレクトリ構造utils.tarで作成したtarballをダウンロードします。
wget https://github.com/opensourceway/how-to-rpm/raw/master/utils.tarこのtarballには、最終回転数でインストールされるすべてのファイルとBashスクリプトが含まれています。 rpmを構築するために使用できる完全なスペックファイルもあります。スペックファイルの各セクションについて詳しく説明します。
ユーザー学生として、ホームディレクトリを現在の作業ディレクトリ（pwd）として使用して、tarballをuntarします。
[student@testvm1 ~]$ cd ; tar -xvf utils.tar
treeを使用する 〜/ developmentのディレクトリ構造と含まれているファイルが次の出力のようになっていることを確認するコマンド：
[student@testvm1 ~]$ tree development/
development/
├── license
│ ├── Copyright.and.GPL.Notice.txt
│ └── GPL_LICENSE.txt
├── scripts
│ ├── create_motd
│ ├── die
│ ├── mymotd
│ └── sysdata
└── spec
└── utils.spec
3 directories, 7 files
[student@testvm1 ~]$
mymotd スクリプトは、stdoutに送信される「MessageOfTheDay」データストリームを作成します。 create_motd スクリプトはmymotdを実行します スクリプトを作成し、出力を/ etc/motdファイルにリダイレクトします。このファイルは、SSHを使用してリモートでログインするユーザーに毎日のメッセージを表示するために使用されます。
die scriptは、killをラップする独自のスクリプトです。 指定された文字列に一致する実行中のプログラムを見つけてそれらを強制終了できるコード内のコマンド。 kill -9を使用します 強制終了メッセージを無視できないようにするためです。
sysdata スクリプトは、コンピューターハードウェア、インストールされているバージョンのLinux、インストールされているすべてのパッケージ、およびハードドライブのメタデータに関する数万行のデータを吐き出す可能性があります。ある時点でのホストの状態を文書化するために使用します。後で参照用に使用できます。以前は、顧客のためにインストールしたホストの記録を維持するためにこれを行っていました。
これらのファイルとディレクトリの所有権をstudent.studentに変更する必要がある場合があります。必要に応じて、次のコマンドを使用してこれを実行します。
chown -R student.student developmentこのツリー内のほとんどのファイルとディレクトリは、このプロジェクト中に作成したrpmによってFedoraシステムにインストールされます。
ビルドディレクトリ構造の作成
rpmbuild コマンドには、非常に特殊なディレクトリ構造が必要です。自動化された方法が提供されていないため、このディレクトリ構造を自分で作成する必要があります。ホームディレクトリに次のディレクトリ構造を作成します。
~ ─ rpmbuild>
├── RPMS
│ └── noarch
├── SOURCES
├── SPECS
└── SRPMS
rpmbuild / RPMS / X86_64ディレクトリは、64ビットでコンパイルされたバイナリのアーキテクチャ固有であるため、作成しません。アーキテクチャ固有ではないシェルスクリプトがあります。実際には、コンパイラのソースファイルを含むSRPMSディレクトリも使用しません。
スペックファイルの確認
各スペックファイルにはいくつかのセクションがあり、rpmビルドの特定の状況に応じて、一部は無視または省略される場合があります。この特定のスペックファイルは、動作に必要な最小限のファイルの例ではありませんが、コンパイルする必要のないファイルをパッケージ化した適度に複雑なスペックファイルの良い例です。コンパイルが必要な場合は、%buildで実行されます。 セクション。必須ではないため、このスペックファイルからは省略されています。
前文
これは、ラベルがないスペックファイルの唯一のセクションです。これは、コマンドrpm -qi [Package Name]のときに表示される情報の多くで構成されています。 実行されます。各データは、タグとタグの値のテキストデータを識別するタグで構成される1行です。
###############################################################################
# Spec file for utils
################################################################################
# Configured to be built by user student or other non-root user
################################################################################
#
Summary: Utility scripts for testing RPM creation
Name: utils
Version: 1.0.0
Release: 1
License: GPL
URL: http://www.both.org
Group: System
Packager: David Both
Requires: bash
Requires: screen
Requires: mc
Requires: dmidecode
BuildRoot: ~/rpmbuild/
# Build with the following syntax:
# rpmbuild --target noarch -bb utils.spec
コメント行はrpmbuildによって無視されます プログラム。このセクションには、rpmbuildの正確な構文を含むコメントを常に追加したいと思います。 パッケージの作成に必要なコマンド。 Summaryタグは、パッケージの簡単な説明です。 Name、Version、およびReleaseタグは、utils-1.00-1.rpmのように、rpmファイルの名前を作成するために使用されます。リリース番号とバージョン番号を増やすと、古いものを更新するために使用できるrpmを作成できます。
Licenseタグは、パッケージがリリースされるライセンスを定義します。私は常にGPLのバリエーションを使用しています。パッケージに含まれているソフトウェアがオープンソースであるという事実を明確にするために、ライセンスを指定することが重要です。これが、インストールされるファイルにライセンスとGPLステートメントを含めた理由でもあります。
URLは通常、プロジェクトまたはプロジェクト所有者のWebページです。この場合、それは私の個人的なWebページです。
Groupタグは興味深いものであり、通常はGUIアプリケーションに使用されます。 Groupタグの値は、アプリケーションメニューのアイコンのどのグループにこのパッケージの実行可能ファイルのアイコンが含まれるかを決定します。 Iconタグ（ここでは使用していません）と組み合わせて使用すると、Groupタグを使用して、アプリケーションのメニュー構造にプログラムを起動するためのアイコンと必要な情報を追加できます。
Packagerタグは、パッケージの保守と作成を担当する個人または組織を指定するために使用されます。
Requiredステートメントは、このrpmの依存関係を定義します。それぞれがパッケージ名です。指定されたパッケージの1つが存在しない場合、DNFインストール・ユーティリティーは、/ etc / yum.repos.dで定義された定義済みリポジトリーの1つでそれを見つけ、存在する場合はそれをインストールしようとします。 DNFが必要なパッケージを1つ以上見つけることができない場合、不足しているパッケージを示すエラーをスローして終了します。
BuildRoot行は、rpmbuildが配置されている最上位ディレクトリを指定します。 ツールはスペックファイルを見つけ、パッケージのビルド中に一時ディレクトリを作成します。完成したパッケージは、前に指定したnoarchサブディレクトリに保存されます。このパッケージのビルドに使用されるコマンド構文を示すコメントには、オプション–target noarchが含まれています。 、ターゲットアーキテクチャを定義します。これらはBashスクリプトであるため、特定のCPUアーキテクチャに関連付けられていません。このオプションを省略した場合、ビルドは、ビルドが実行されているCPUのアーキテクチャを対象とします。
rpmbuild プログラムは多くの異なるアーキテクチャをターゲットにでき、--targetを使用します オプションを使用すると、ビルドが実行されるアーキテクチャとは異なるアーキテクチャのホストでアーキテクチャ固有のパッケージをビルドできます。そのため、x86_64ホスト上のi686アーキテクチャで使用することを目的としたパッケージを構築できます。その逆も可能です。
パッケージャ名を自分のものに変更し、URLを自分のWebサイトに変更します（ある場合）。
％description
%description スペックファイルのセクションには、rpmパッケージの説明が含まれています。非常に短い場合もあれば、多くの情報行を含める場合もあります。 %description セクションはかなり簡潔です。
%description
A collection of utility scripts for testing RPM creation.
％prep
%prep セクションは、ビルドプロセス中に実行される最初のスクリプトです。このスクリプトは、パッケージのインストール中には実行されません。
このスクリプトは単なるBashシェルスクリプトです。ビルドディレクトリを準備し、必要に応じてビルドに使用するディレクトリを作成し、適切なファイルをそれぞれのディレクトリにコピーします。これには、ビルドの一部として完全なコンパイルに必要なソースが含まれます。
$ RPM_BUILD_ROOTディレクトリは、インストールされているシステムのルートディレクトリを表します。 $ RPM_BUILD_ROOTディレクトリに作成されたディレクトリは、ライブファイルシステム内の/ user / local / share / utils、/ usr / local/binなどの完全修飾パスです。
パッケージの場合、すべてのプログラムがBashスクリプトであるため、プリコンパイルソースはありません。したがって、これらのスクリプトやその他のファイルを、インストールされているシステムに属するディレクトリにコピーするだけです。
%prep
################################################################################
# Create the build tree and copy the files from the development directories #
# into the build tree. #
################################################################################
echo "BUILDROOT = $RPM_BUILD_ROOT"
mkdir -p $RPM_BUILD_ROOT/usr/local/bin/
mkdir -p $RPM_BUILD_ROOT/usr/local/share/utils
cp /home/student/development/utils/scripts/* $RPM_BUILD_ROOT/usr/local/bin
cp /home/student/development/utils/license/* $RPM_BUILD_ROOT/usr/local/share/utils
cp /home/student/development/utils/spec/* $RPM_BUILD_ROOT/usr/local/share/utils
exit
このセクションの最後にあるexitステートメントが必要であることに注意してください。
％files
スペックファイルのこのセクションでは、インストールするファイルとディレクトリツリー内のそれらの場所を定義します。また、インストールする各ファイルのファイル属性と所有者およびグループ所有者を指定します。ファイルのアクセス許可と所有権はオプションですが、インストール時にこれらの属性が正しくないかあいまいになる可能性を排除するために、明示的に設定することをお勧めします。ディレクトリがまだ存在しない場合は、インストール中に必要に応じて作成されます。
%files
%attr(0744, root, root) /usr/local/bin/*
%attr(0644, root, root) /usr/local/share/utils/*
％pre
このセクションは、ラボプロジェクトのスペックファイルでは空です。これは、rpmのインストール中、ファイルのインストール前に実行する必要のあるスクリプトを配置する場所になります。
％post
スペックファイルのこのセクションは、別のBashスクリプトです。これは、ファイルのインストール後に実行されます。このセクションは、ファイルの作成、システムコマンドの実行、構成の変更後にサービスを再初期化するためのサービスの再起動など、必要なものや必要なものをほぼすべて含めることができます。 %post rpmパッケージのスクリプトは、これらのタスクの一部を実行します。
%post
################################################################################
# Set up MOTD scripts #
################################################################################
cd /etc
# Save the old MOTD if it exists
if [ -e motd ]
then
cp motd motd.orig
fi
# If not there already, Add link to create_motd to cron.daily
cd /etc/cron.daily
if [ ! -e create_motd ]
then
ln -s /usr/local/bin/create_motd
fi
# create the MOTD for the first time
/usr/local/bin/mymotd > /etc/motd
このスクリプトに含まれるコメントは、その目的を明確にする必要があります。
％postun
このセクションには、rpmパッケージがアンインストールされた後に実行されるスクリプトが含まれています。 rpmまたはDNFを使用してパッケージを削除すると、%filesにリストされているすべてのファイルが削除されます。 セクションですが、%postによって作成されたファイルやリンクは削除されません セクションなので、このセクションで処理する必要があります。
このスクリプトは通常、rpmによって以前にインストールされたファイルを単に消去するだけでは実行できないクリーンアップタスクで構成されています。パッケージの場合、%postによって作成されたリンクの削除が含まれます スクリプトを作成し、保存されたmotdファイルのオリジナルを復元します。
%postun
# remove installed files and links
rm /etc/cron.daily/create_motd
# Restore the original MOTD if it was backed up
if [ -e /etc/motd.orig ]
then
mv -f /etc/motd.orig /etc/motd
fi
％clean
このBashスクリプトは、rpmビルドプロセスの後にクリーンアップを実行します。 %cleanの2行 以下のセクションでは、rpm-buildによって作成されたビルドディレクトリを削除します 指図。多くの場合、追加のクリーンアップも必要になる場合があります。
%clean
rm -rf $RPM_BUILD_ROOT/usr/local/bin
rm -rf $RPM_BUILD_ROOT/usr/local/share/utils
％changelog
このオプションのテキストセクションには、rpmとそれに含まれるファイルへの変更のリストが含まれています。最新の変更は、このセクションの上部に記録されています。
%changelog
* Wed Aug 29 2018 Your Name <[email protected]>
- The original package includes several useful scripts. it is
primarily intended to be used to illustrate the process of
building an RPM.
ヘッダー行のデータを自分の名前とメールアドレスに置き換えます。
rpmの構築
スペックファイルは、rpmbuildツリーのSPECSディレクトリにある必要があります。そのディレクトリに実際のスペックファイルへのリンクを作成して、開発ディレクトリで編集できるようにし、SPECSディレクトリにコピーする必要がないようにするのが最も簡単だと思います。 SPECSディレクトリをpwdにしてから、リンクを作成します。
cd ~/rpmbuild/SPECS/
ln -s ~/development/spec/utils.spec
次のコマンドを実行して、rpmを構築します。エラーが発生しなければ、rpmを作成するのに少し時間がかかるはずです。
rpmbuild --target noarch -bb utils.spec〜/ rpmbuild / RPMS / noarchディレクトリをチェックして、新しいrpmがそこに存在することを確認します。
[student@testvm1 ~]$ cd rpmbuild/RPMS/noarch/
[student@testvm1 noarch]$ ll
total 24
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
[student@testvm1 noarch]$
rpmのテスト
rootとして、rpmをインストールして、rpmが正しくインストールされ、ファイルが正しいディレクトリにインストールされていることを確認します。 rpmの正確な名前は、プリアンブルセクションでタグに使用した値によって異なりますが、サンプルで使用した場合、rpm名は以下のサンプルコマンドに示すようになります。
[root@testvm1 ~]# cd /home/student/rpmbuild/RPMS/noarch/
[root@testvm1 noarch]# ll
total 24
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
[root@testvm1 noarch]# rpm -ivh utils-1.0.0-1.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:utils-1.0.0-1 ################################# [100%]
/ usr / local / binをチェックして、新しいファイルがそこにあることを確認します。また、/ etc/cron.dailyのcreate_motdリンクが作成されていることを確認する必要があります。
rpm -q --changelog utilsを使用します 変更ログを表示するコマンド。 rpm -ql utilsを使用してパッケージによってインストールされたファイルを表示します コマンド（つまり、qlの小文字のL 。）
[root@testvm1 noarch]# rpm -q --changelog utils
* Wed Aug 29 2018 Your Name <[email protected]>
- The original package includes several useful scripts. it is
primarily intended to be used to illustrate the process of
building an RPM.
[root@testvm1 noarch]# rpm -ql utils
/usr/local/bin/create_motd
/usr/local/bin/die
/usr/local/bin/mymotd
/usr/local/bin/sysdata
/usr/local/share/utils/Copyright.and.GPL.Notice.txt
/usr/local/share/utils/GPL_LICENSE.txt
/usr/local/share/utils/utils.spec
[root@testvm1 noarch]#
パッケージを削除します。
rpm -e utils実験
次に、スペックファイルを変更して、存在しないパッケージを要求します。これにより、満たすことができない依存関係がシミュレートされます。既存のRequires行のすぐ下に次の行を追加します：
Requires: badrequireパッケージをビルドしてインストールしてみてください。どのようなメッセージが表示されますか？
rpmを使用しました utilsをインストールおよび削除するコマンド パッケージ。 yumまたはDNFを使用してパッケージをインストールしてみてください。これを機能させるには、パッケージと同じディレクトリにいるか、パッケージへのフルパスを指定する必要があります。
結論
rpmパッケージの作成の基本については、ここでは取り上げなかった多くのタグといくつかのセクションがあります。以下にリストされているリソースは、より多くの情報を提供することができます。 rpmパッケージの構築は難しくありません。正しい情報が必要です。これがお役に立てば幸いです。自分で物事を理解するのに数か月かかりました。
ソースコードからの構築については説明しませんでしたが、開発者であれば、この時点からの簡単なステップになるはずです。
rpmパッケージを作成することは、怠惰なシステム管理者になり、時間と労力を節約するためのもう1つの良い方法です。これは、システム管理者として多くのホストにインストールする必要のあるスクリプトやその他のファイルを配布およびインストールするための簡単な方法を提供します。
リソース
-
エドワードC.ベイリー、最大RPM 、Sams Publishing、2000、ISBN 0-672-31105-4
-
エドワードC.ベイリー、最大RPM 、更新されたオンラインバージョン
-
RPMドキュメント ：このWebページには、rpmで利用可能なオンラインドキュメントのほとんどがリストされています。他のウェブサイトへの多くのリンクとrpmに関する情報が含まれています。