基本的なシステム設定の構成
Red Hat Enterprise Linux 8 で基本的なシステム設定を構成するためのガイド
概要
はじめに
第1章 システム管理の使用
以下のセクションでは、インストール済みシステムでの基本的な管理タスクの概要を説明します。
以下のような基本的な管理タスクには、システムの登録など、必須ではありませんが、通常はインストールプロセス中に実行済みとなる項目が含まれている場合があります。以下のセクションでは、このようなタスクを扱うことで、インストール時に同じ目的を達成する方法を概説します。
Red Hat Enterprise Linux のインストールの詳細は『標準的な RHEL インストールの実行』を参照してください。
インストール後のタスクはすべてコマンドラインから実行できますが、一部のコマンドは RHEL 8 Web コンソールから実行することもできます。
1.1. RHEL Web コンソールの使用
Red Hat Enterprise Linux 8 に Web コンソールをインストールし、RHEL 8 Web コンソールでの 「リモートホストの追加」および監視方法を確認します。
前提条件
- Red Hat Enterprise Linux 8 をインストールしている。
- 有効なネットワークがある。
適切なサブスクリプションが割り当てられた登録済みのシステムがある。
サブスクリプションを取得する場合は、「Web コンソールでサブスクリプションの管理」を参照してください。
1.1.1. RHEL Web コンソールの概要
RHEL Web コンソールは、ローカルシステムやネットワーク環境にある Linux サーバーを管理および監視するために設計された Red Hat Enterprise Linux 8 の Web ベースのインターフェースです。
RHEL Web コンソールは、以下を含むさまざまな管理タスクを可能にします。
- サービスの管理
- ユーザーアカウントの管理
- システムサービスの管理および監視
- ネットワークインターフェースおよびファイアウォールの設定
- システムログの確認
- 仮想マシンの管理
- 診断レポートの作成
- カーネルダンプ構成の設定
- SELinux の構成
- ソフトウェアの更新
- システムサブスクリプションの管理
RHEL Web コンソールは、ターミナルと同じシステム API を使用します。ターミナルで実行した操作は、即座に RHEL Web コンソールに反映されます。
ネットワーク環境のシステムのログや、パフォーマンスをグラフで監視できます。さらに、Web コンソールで設定を直接変更したり、ターミナルから設定を変更できます。
1.1.2. Web コンソールのインストールおよび有効化
RHEL 8 Web コンソールにアクセスするには、最初に cockpit.socket
サービスを有効にします。
Red Hat Enterprise Linux 8 では、多くのインストール方法で、RHEL 8 Web コンソールがデフォルトでインストールされます。ご使用のシステムがこれに該当しない場合は、cockpit
パッケージをインストールしてから .socket
サービスを有効にしてください。
手順
Web コンソールがインストールバリアントにデフォルトでインストールされていない場合は、
cockpit
パッケージを手動でインストールします。# yum install cockpit
必要に応じて、Web サーバーを実行する
cockpit.socket
サービスを有効にして起動します。# systemctl enable --now cockpit.socket
Web コンソールがインストールバリアントにデフォルトでインストールされておらず、カスタムのファイアウォールプロファイルを使用している場合は、
cockpit
サービスをfirewalld
に追加して、ファイアウォールの 9090 番ポートを開きます。# firewall-cmd --add-service=cockpit --permanent # firewall-cmd --reload
検証手順
- 以前のインストールと設定を確認するには、Web コンソールを開きます。
1.1.3. Web コンソールへのログイン
RHEL Web コンソールに、システムユーザー名とパスワードを使用して初めてログインするには、この手順に従ってください。
前提条件
以下のブラウザーのいずれかを使用して、Web コンソールを開いている。
- Mozilla Firefox 52 以上
- Google Chrome 57 以上
- Microsoft Edge 16 以上
システムユーザーアカウントの認証情報
RHEL Web コンソールは、
/etc/pam.d/cockpit
にある特定の PAM スタックを使用します。PAM を使用した認証では、システムのローカルアカウントのユーザー名およびパスワードを使用してログインできます。
手順
Web ブラウザーで Web コンソールを開きます。
-
ローカルの場合 -
https://localhost:9090
-
リモートでサーバーのホスト名を使用する場合 -
https://example.com:9090
リモートでサーバーの IP アドレスを使用する場合 -
https://192.0.2.2:9090
自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可してから、ログインを続行します。
コンソールは
/etc/cockpit/ws-certs.d
ディレクトリーから証明書をロードし、アルファベット順で最後となる.cert
拡張子のファイルを使用します。セキュリティーの例外を承認しなくてもすむように、認証局 (CA) が署名した証明書をインストールします。
-
ローカルの場合 -
ログイン画面で、システムユーザー名とパスワードを入力します。
必要に応じて、特権タスクにパスワードを再使用する オプションをクリックします。
ログインに使用するユーザーアカウントに sudo 権限がある場合は、ソフトウェアのインストールや SELinux の設定など、Web コンソールで権限が必要となるタスクを実行できます。
- ログイン をクリックします。
認証に成功すると、RHEL Web コンソールインターフェースが開きます。
1.1.4. リモートマシンから Web コンソールへの接続
任意のクライアントオペレーティングシステムから、または携帯電話やタブレットから、Web コンソールインターフェースに接続できます。
前提条件
対応しているインターネットブラウザーを備えたデバイス。以下に例を示します。
- Mozilla Firefox 52 以上
- Google Chrome 57 以上
- Microsoft Edge 16 以上
- インストールしてアクセス可能な Web コンソールでアクセスする RHEL 8 サーバー。Web コンソールのインストールの詳細は、「RHEL Web コンソールの使用」を参照してください。
手順
- Web ブラウザを開きます。
リモートサーバーのアドレスを次のいずれかの形式で入力します。
-
サーバーのホスト名 (
server.hostname.example.com:port_number
) -
サーバーの IP アドレス (
server.IP_address:port_number
)
-
サーバーのホスト名 (
- ログインインターフェースが開いたら、RHEL マシンの資格情報でログインします。
1.1.5. ワンタイムパスワードを使用した Web コンソールへのログイン
ワンタイムパスワード (OTP) 設定が有効になっている Identity Management (IdM) ドメインにシステムが含まれている場合には、OTP を使用して RHEL Web コンソールにログインできます。
ワンタイムパスワードを使用してログインできるのは、OTP 設定が有効な Identity Management (IdM) ドメインに、お使いのシステムが含まれる場合のみです。IdM の OTP の詳細は、「Identity Management のワンタイムパスワード」を参照してください。
前提条件
RHEL Web コンソールがインストールされている。
詳細は「Web コンソールのインストール」を参照してください。
Identity Management サーバーで OTP 設定を有効しておく。
詳細は「Identity Management のワンタイムパスワード」を参照してください。
- OTP トークンを生成する構成済みのハードウェアまたはソフトウェアのデバイス
手順
ブラウザーで RHEL Web コンソールを開きます。
-
ローカルの場合 -
https://localhost:PORT_NUMBER
-
リモートでサーバーのホスト名を使用する場合 -
https://example.com:PORT_NUMBER
リモートでサーバーの IP アドレスを使用する場合 -
https://EXAMPLE.SERVER.IP.ADDR:PORT_NUMBER
自己署名証明書を使用する場合は、ブラウザーに警告が表示されます。証明書を確認し、セキュリティー例外を許可してから、ログインを続行します。
コンソールは
/etc/cockpit/ws-certs.d
ディレクトリーから証明書をロードし、アルファベット順で最後となる.cert
拡張子のファイルを使用します。セキュリティーの例外を承認しなくてもすむように、認証局 (CA) が署名した証明書をインストールします。
-
ローカルの場合 -
- ログイン画面が表示されます。ログイン画面で、システムユーザーの名前とパスワードを入力します。
- デバイスでワンタイムパスワードを生成します。
- パスワードを確認してから、Web コンソールインターフェースに表示される新規フィールドにワンタイムパスワードを入力します。
- Log in をクリックします。
- ログインに成功すると、Web コンソールインターフェースの Overview ページに移動します。
1.1.6. Web コンソールでのシステムの再起動
Web コンソールを使用して、Web コンソールの接続先の RHEL システムを再起動します。
前提条件
RHEL 8 Web コンソールをインストールし、アクセスできる。
詳細は、「Web コンソールのインストール」を参照してください。
手順
RHEL 8 Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
- 概要 をクリックします。
再起動 ボタンをクリックします。
- ユーザーがシステムにログインする場合は、再起動 ダイアログボックスに、再起動する理由を記入します。
必要に応じて、遅延 ドロップダウンリストで、遅延させる時間を選択します。
- 再起動 をクリックします。
1.1.7. Web コンソールでのシステムのシャットダウン
Web コンソールを使用して、Web コンソールが接続している RHEL システムをシャットダウンします。
前提条件
RHEL 8 Web コンソールをインストールし、アクセスできる。
詳細は、「Web コンソールのインストール」を参照してください。
手順
RHEL 8 Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
- 概要 をクリックします。
再起動 ドロップダウンリストで、シャットダウン を選択します。
- システムにログインするユーザーがいる場合は、シャットダウン ダイアログボックスに、シャットダウンの理由を入力します。
- 必要に応じて、遅延 ドロップダウンリストで、遅延させる時間を選択します。
- シャットダウン をクリックします。
1.1.8. Web コンソールでの時間設定の構成
タイムゾーンを設定して、システム時間を Network Time Protocol (NTP) サーバーと同期できます。
前提条件
RHEL 8 Web コンソールをインストールし、アクセスできる。
詳細は「Web コンソールのインストール」を参照してください。
手順
RHEL 8 Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
概要 で現在のシステム時間をクリックします。
- 必要に応じて、システム時間の変更 ダイアログボックスで、タイムゾーンを変更します。
時間の設定 ドロップダウンメニューで、以下のいずれかを選択します。
- 手動
- NTP サーバーなしで手動で時間を設定する必要がある場合は、このオプションを使用します。
- NTP サーバーの自動使用
- これはデフォルトのオプションで、既存の NTP サーバーと時間を自動同期します。
- 特定の NTP サーバーの自動使用
- このオプションは、システムを特定の NTP サーバーと同期する必要がある場合に限り使用してください。サーバーの DNS 名または IP アドレスを指定します。
変更 をクリックします。
検証手順
- システム タブに表示されるシステム時間を確認します。
1.1.9. Web コンソールを使用した RHEL 8 システムの IdM ドメインへの参加
Web コンソールを使用して、Red Hat Enterprise Linux 8 システムを Identity Management (IdM) ドメインに参加させることができます。
前提条件
- IdM ドメインが実行中で参加するクライアントから到達可能
- IdM ドメインの管理者認証情報がある。
手順
RHEL Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
- システム タブを開きます。
- ドメイン参加 ダイアログボックスの ドメインアドレス フィールドに、IdM サーバーのホスト名を入力します。
認証 ドロップダウンメニューで、認証にパスワード、またはワンタイムパスワードを使用するかどうかを選択します。
- ドメイン管理者名 フィールドで、IdM 管理アカウントのユーザー名を入力します。
- 上記の 認証 ドロップダウンリストで選択した内容に応じて、パスワードフィールドにパスワードまたはワンタイムパスワードを追加します。
検証手順
- システムが IdM ドメインに参加していると、RHEL 8 Web コンソールにエラーが表示されず、システム 画面でドメイン名を確認できます。
ユーザーがドメインのメンバーであることを確認するには、Terminal ページをクリックし、
id
コマンドを実行します。$ id euid=548800004(example_user) gid=548800004(example_user) groups=548800004(example_user) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
1.1.10. Web コンソールを使用して CPU のセキュリティーの問題を防ぐために SMT を無効化する手順
CPU SMT (Simultaneous Multi Threading) を悪用する攻撃が発生した場合に SMT を無効にします。SMT を無効にすると、L1TF や MDS などのセキュリティー脆弱性を軽減できます。
SMT を無効にすると、システムパフォーマンスが低下する可能性があります。
前提条件
Web コンソールがインストールされており、アクセス可能である。
詳細は「Web コンソールのインストール」を参照してください。
手順
RHEL 8 Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
- システム をクリックします。
ハードウェア で、ハードウェア情報をクリックします。
CPU セキュリティー で、軽減策 をクリックします。
このリンクがない場合は、システムが SMT に対応していないため、攻撃を受けません。
CPU セキュリティートグル で、同時マルチスレッドの無効 (nosmt) オプションに切り替えます。
- 保存および再起動 ボタンをクリックします。
システムの再起動後、CPU は SMT を使用しなくなりました。
1.1.11. ログインページへのバナーの追加
企業および代理店は、コンピューターは正当な目的で使用すること、またユーザーは監視下にあり、不正アクセスは告訴の対象となるという警告を表示する必要がある場合があります。ログイン前に警告を表示する必要があります。SSH と同様に、Web コンソールのログイン画面にバナーファイルのコンテンツを表示することも可能です (オプション)。Web コンソールセッションでバナーを有効にするには、/etc/cockpit/cockpit.conf
ファイルを変更する必要があります。このファイルは必須ではないため、手動で作成する必要がある場合があります。
前提条件
- RHEL 8 Web コンソールをインストールし、アクセスできる。詳細は、「Web コンソールのインストール」を参照してください。
- sudo 権限があること。
手順
任意のテキストエディターで、
/etc/issue.cockpit
ファイルがまだ作成されていない場合には、作成します。バナーとして表示するコンテンツをファイルに追加します。ファイルのコンテンツと表示コンテンツの間で再フォーマットが行われないので、ファイルにマクロは追加しないでください。必要に応じて改行を使用します。ASCII アートを使用できます。
- ファイルを保存します。
任意のテキストエディターで、
/etc/cockpit/
ディレクトリーのcockpit.conf
ファイルを開くか、作成します。$ sudo vi cockpit.conf
以下のテキストをファイルに追加します。
[Session] Banner=/etc/issue.cockpit
- ファイルを保存します。
Web コンソールを再起動して、変更を有効にします。
# systemctl try-restart cockpit
検証手順
- Web コンソールのログイン画面を再度開き、バナーが表示されていることを確認します。
例1.1 ログインページへのバナー例の追加
テキストエディターを使用して、任意のテキストを含めて
/etc/issue.cockpit
ファイルを作成します。This is an example banner for the RHEL web console login page.
/etc/cockpit/cockpit.conf
ファイルを開くか、作成して、以下のテキストを追加します。[Session] Banner=/etc/issue.cockpit
- Web コンソールを再起動します。
Web コンソールのログイン画面を再度開きます。
1.1.12. Web コンソールでの自動アイドルロックの設定
デフォルトでは、Web コンソールインターフェースには、アイドル後のタイムアウトは設定されていません。システムでアイドルタイムアウトを有効にするには、/etc/cockpit/cockpit.conf
設定ファイルを変更してください。このファイルは必須ではないため、手動で作成する必要がある場合があります。
前提条件
Web コンソールがインストールされており、アクセス可能である。
詳細は、「Web コンソールのインストール」を参照してください。
- sudo 権限があること。
手順
任意のテキストエディターで、
/etc/cockpit/
ディレクトリーのcockpit.conf
ファイルを開くか、作成します。$ sudo vi cockpit.conf
以下のテキストをファイルに追加します。
[Session] IdleTimeout=X
X は、選択した期間の数値 (分単位) に置き換えます。
- ファイルを保存します。
Web コンソールを再起動して、変更を有効にします。
# systemctl try-restart cockpit
検証手順
- 設定の期間後にセッションがログアウトされているかどうかを確認します。
1.2. Web コンソールでのホスト名のを設定
以下では、RHEL 8 Web コンソールを使用して、Web コンソールの接続先のシステムで、異なる形式のホスト名を設定する方法を説明します。
1.2.1. ホスト名
ホスト名はシステムを識別します。デフォルトでは、ホスト名は localhost
に設定されていますが、変更できます。
ホスト名は、以下の 2 つの部分から構成されます。
- ホスト名
- システムを識別する一意の名前です。
- ドメイン
- ネットワーク内でシステムを使用する場合や、IP アドレスではなく名前を使用する場合に、ホスト名の後にドメインを接尾辞として追加します。
ドメイン名が割り当てられたホスト名は、完全修飾ドメイン名 (FQDN) と呼ばれます。たとえば、mymachine.example.com
です。
ホスト名は /etc/hostname
ファイルに保存されます。
1.2.2. Web コンソールでの Pretty ホスト名
RHEL Web コンソールで Pretty ホスト名を設定することもできます。Pretty ホスト名は、大文字、スペースなどを含むホスト名です。
Pretty ホスト名は Web コンソールに表示されますが、ホスト名に対応させる必要はありません。
例1.2 Web コンソールでのホスト名の形式
- Pretty ホスト名
-
My machine
- ホスト名
-
mymachine
- 実際のホスト名 - 完全修飾ドメイン名 (FQDN)
-
mymachine.idm.company.com
1.2.3. Web コンソールを使用したホスト名の設定
この手順では、Web コンソールで実際のホスト名または Pretty ホスト名を設定します。
前提条件
RHEL 8 Web コンソールをインストールし、アクセスできる。
詳細は、「Web コンソールのインストール」を参照してください。
手順
RHEL 8 Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
- をクリックします。
現在のホスト名の横にある
をクリックします。- ホスト名の変更 ダイアログボックスの Pretty ホスト名 フィールドに、ホスト名を入力します。
実際のホスト名フィールド は、ドメイン名を Pretty 名に割り当てます。
ホスト名が Pretty ホスト名と一致しない場合は、実際にホスト名を手動で変更できます。
検証手順
- Web コンソールからログアウトします。
ブラウザーのアドレスバーに新規ホスト名のアドレスを入力して、Web コンソールを再度開きます。
1.3. Red Hat Web コンソールアドオン
RHEL 8 Web コンソールでアドオンをインストールし、利用できるアドオンアプリケーションを確認します。
1.3.1. アドオンのインストール
cockpit
パッケージは、デフォルトで Red Hat Enterprise Linux 8 に含まれています。アドオンアプリケーションを使用できるようにするには、個別にインストールする必要があります。
前提条件
-
cockpit
パッケージがインストールされ、有効になっている。Web コンソールを先にインストールする必要がある場合は、「installation」のセクションを参照してください。
手順
アドオンをインストールします。
# yum install <add-on>
1.3.2. RHEL 8 Web コンソールのアドオン
以下の表は、RHEL 8 Web コンソールの利用可能なアドオンアプリケーションの一覧です。
機能名 | パッケージ名 | 用途 |
---|---|---|
Composer | cockpit-composer | カスタム OS イメージの構築 |
Dashboard | cockpit-dashboard | 単一の UI で複数のサーバーを管理する |
Machines | cockpit-machines | libvirt 仮想マシンの管理 |
PackageKit | cockpit-packagekit | ソフトウェア更新およびアプリケーションインストール (通常はデフォルトでインストールされている) |
PCP | cockpit-pcp | 永続的かつ、より詳細なパフォーマンスデータ (UI からオンデマンドでインストール) |
podman | cockpit-podman | podman コンテナーの管理 (RHEL 8.1 から利用可能) |
セッションの録画 | cockpit-session-recording | ユーザーセッションの記録および管理 |
1.4. Web コンソールを使用したシステムパフォーマンスの最適化
以下では、RHEL 8 Web コンソールでパフォーマンスプロファイルを設定し、選択したタスクに対してシステムのパフォーマンスを最適化する方法を説明します。
1.4.1. Web コンソールでのパフォーマンスチューニングオプション
Red Hat Enterprise Linux 8 には、以下のタスクに対してシステムを最適化する複数のパフォーマンスプロファイルが同梱されています。
- デスクトップを使用するシステム
- スループットパフォーマンス
- レイテンシーパフォーマンス
- ネットワークパフォーマンス
- 電力の低消費
- 仮想マシン
tuned
サービスは、選択したプロファイルに一致するようにシステムオプションを最適化します。
Web コンソールでは、システムが使用するパフォーマンスプロファイルを設定できます。
関連情報
-
tuned
サービスの詳細は、『システムの状態とパフォーマンスの監視と管理』を参照してください。
1.4.2. Web コンソールでのパフォーマンスプロファイルの設定
この手順では、Web コンソールを使用して、選択したタスクのシステムパフォーマンスを最適化します。
前提条件
RHEL 8 Web コンソールをインストールし、アクセスできる。
詳細は「Web コンソールのインストール」を参照してください。
手順
RHEL 8 Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
- 概要 をクリックします。
パフォーマンスプロファイル フィールドで、現在のパフォーマンスプロファイルをクリックします。
- 必要に応じて、パフォーマンスプロファイルの変更 ダイアログボックスで、プロファイルを変更します。
プロファイルの変更 をクリックします。
検証手順
- Overview タブには、選択したパフォーマンスプロファイルが表示されます。
1.5. RHEL システムロールの使用
本セクションでは、RHEL システムロールの概要を説明します。また、Ansible Playbook を使用して特定のロールを適用し、さまざまなシステム管理タスクを実行する方法を説明します。
1.5.1. RHEL システムロールの概要
RHEL システムロールは、Ansible ロールおよびモジュールのコレクションです。RHEL システムロールは、複数の RHEL システムをリモートで管理するための設定インターフェースを提供します。このインターフェースは、RHEL の複数のバージョンにわたるシステム設定の管理と、新しいメジャーリリースの導入を可能にします。
Red Hat Enterprise Linux 8 のインターフェースは、現在、以下のロールから構成されます。
- kdump
- network
- selinux
- storage
- certificate
- kernel_settings
- logging
- metrics
- nbde_client and nbde_server
- timesync
- tlog
これらのロールはすべて、AppStream
リポジトリーで利用可能な rhel-system-roles
パッケージで提供されます。
関連情報
- RHEL システムロールの概要は、Red Hat ナレッジベースアーティクル 「Red Hat Enterprise Linux (RHEL) System Roles」 を参照してください。
-
特定のロールの詳細は、
/usr/share/doc/rhel-system-roles
ディレクトリーのドキュメントを参照してください。本書はrhel-system-roles
パッケージで自動的にインストールされます。 - 「SELinux システムロールの概要」
- 「ストレージロールの概要」
1.5.2. RHEL システムロールの用語
このドキュメントでは、以下の用語を確認できます。
システムロールの用語
- Ansible Playbook
- Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語です。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。
- コントロールノード
- Ansible がインストールされているマシン。コマンドおよび Playbook を実行でき、すべてのコントロールノードから /usr/bin/ansible または /usr/bin/ansible-playbook を起動します。Python がインストールされているすべてのコンピューターをコントロールノードとして使用できます。ラップトップ、共有デスクトップ、およびサーバーですべての Ansible を実行できます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを使用できます。
- インベントリー
- 管理対象ノードの一覧。インベントリーファイルは「ホストファイル」とも呼ばれます。インベントリーでは、各管理対象ノードに対して IP アドレスなどの情報を指定できます。また、インベントリーは管理ノードを編成し、簡単にスケーリングできるようにグループの作成およびネスト化が可能です。インベントリーについての詳細は、「インベントリーの操作」セクションを参照してください。
- 管理ノード
- Ansible で管理するネットワークデバイス、サーバー、またはその両方。管理対象ノードは、「ホスト」と呼ばれることもあります。Ansible が管理ノードにはインストールされません。
1.5.3. ロールの適用
以下の手順では、特定のロールを適用する方法を説明します。
前提条件
rhel-system-roles
パッケージが、コントロールノードとして使用するシステムにインストールされている。# yum install rhel-system-roles
Ansible Engine リポジトリーが有効になり、コントロールノードとして使用するシステムに
ansible
パッケージがインストールされている。RHEL システムロールを使用する Playbook を実行するには、ansible
パッケージが必要です。Red Hat Ansible Engine サブスクリプションをお持ちでない場合は、Red Hat Enterprise Linux サブスクリプションで提供される Red Hat Ansible Engine の限定サポートバージョンを使用できます。この場合は、次の手順を実行します。
RHEL Ansible Engine リポジトリーを有効にします。
# subscription-manager refresh # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
Ansible Engine をインストールします。
# yum install ansible
- Red Hat Ansible Engine のサブスクリプションをお持ちの場合は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 に記載されている手順を行ってください。
Ansible Playbook を作成できる。
Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語を表します。Playbook を使用すると、リモートマシンの設定を宣言して管理したり、複数のリモートマシンをデプロイしたり、手動で順番を付けたプロセスの手順をまとめたりできます。
Playbook は、1 つ以上の
play
の一覧です。すべてのplay
には、Ansible の変数、タスク、またはロールが含まれます。Playbook は人が判読でき、
YAML
形式で表現されます。Playbook の詳細は、Ansible ドキュメント を参照してください。
手順
必要なロールを含む Ansible Playbook を作成します。
以下の例は、特定の
play
のroles:
オプションを使用してロールを使用する方法を示しています。--- - hosts: webservers roles: - rhel-system-roles.network - rhel-system-roles.timesync
Playbook でロールを使用する方法は、Ansible ドキュメント を参照してください。
Playbook の例は 「Ansible examples」を参照してください。
注記すべてのロールには README ファイルが含まれます。このファイルには、ロールや、サポートされるパラメーター値の使用方法が記載されています。ロールのドキュメントディレクトリーで、特定ロール用の Playbook のサンプルを見つけることもできます。このようなドキュメンテーションディレクトリーは、
rhel-system-roles
パッケージでデフォルトで提供され、以下の場所に置かれます。/usr/share/doc/rhel-system-roles/SUBSYSTEM/
SUBSYSTEM は、
selinux
、kdump
、network
、timesync
、またはstorage
などの必要なロールの名前に置き換えます。Playbook の構文を確認します。
#
ansible-playbook --syntax-check name.of.the.playbook
ansible-playbook
コマンドは、Playbook の構文の検証に使用できる--syntax-check
オプションを提供します。ansible-playbook
コマンドを実行して、ターゲットホストで Playbook を実行します。#
ansible-playbook -i name.of.the.inventory
name.of.the.playbookインベントリーは、Ansible が有効なシステムの一覧です。インベントリーの作成方法と使用方法は、Ansible ドキュメント を参照してください。
インベントリーがない場合は、
ansible-playbook
の実行時に作成できます。Playbook を実行するターゲットホストが 1 つしかない場合は、次のコマンドを実行します。
# ansible-playbook -i host1, name.of.the.playbook
Playbook を実行するターゲットホストが複数になる場合は、次のコマンドを実行します。
# ansible-playbook -i host1,host2,....,hostn name.of.the.playbook
関連情報
-
ansible-playbook
コマンドの使用方法は、man ページのansible-playbook
を参照してください。
1.5.4. 関連情報
- RHEL システムロールの概要は、Red Hat ナレッジベースアーティクル 「Red Hat Enterprise Linux (RHEL) System Roles」 を参照してください。
- 「RHEL システムロールを使用したローカルストレージの管理」
- 「複数のシステムへの同じ SELINUX 設定のデプロイメント」
1.6. 基本的な環境設定の変更
基本的な環境設定は、インストールプロセスの一部です。以下のセクションでは、後での変更する時に説明します。環境の基本設定には、以下が含まれます。
- 日付と時刻
- システムロケール
- キーボードのレイアウト
- 言語
1.6.1. 日付および時刻の設定
正確な時間を維持することは、さまざまな理由で重要です。Red Hat Enterprise Linux では、NTP
プロトコルにより、時刻が管理されます。これは、デーモンにより、ユーザー領域に実装されています。ユーザー領域のデーモンは、カーネルで実行しているシステムクロックを更新します。システムクロックは、さまざまなクロックソースを使用して時間を維持します。
Red Hat Enterprise Linux 8 では、chronyd
デーモンを使用して NTP
を実装します。chronyd
は、chrony パッケージから入手できます。詳細は「Chrony スイートを使用した NTP の設定」を参照してください。
1.6.1.1. システムの現在日時の表示
現在の日時を表示するには、以下のいずれかの手順を行います。
手順
date
コマンドを実行します。$ date Mon Mar 30 16:02:59 CEST 2020
詳細は、
timedatectl
コマンドを使用して確認します。$ timedatectl Local time: Mon 2020-03-30 16:04:42 CEST Universal time: Mon 2020-03-30 14:04:42 UTC RTC time: Mon 2020-03-30 14:04:41 Time zone: Europe/Prague (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no
関連情報
-
詳細は、
date(1)
およびtimedatectl(1)
の man ページを参照してください。
1.6.1.2. 関連情報
- Web コンソールの時間設定の詳細は、「Web コンソールを使用した時間設定の構成」を参照してください。
1.6.2. システムロケールの設定
システム全体にわたるロケール設定は /etc/locale.conf
ファイルに保存され、システム起動の初期段階で systemd
デーモンにより読み込まれます。/etc/locale.conf
に設定したロケール設定は、個別のプログラムやユーザーが上書きしない限り、すべてのサービスやユーザーに継承されます。
本セクションでは、システムロケールを管理する方法を説明します。
手順
利用可能なシステムロケール設定を一覧表示するには、次のコマンドを実行します。
$ localectl list-locales C.utf8 aa_DJ aa_DJ.iso88591 aa_DJ.utf8 ...
システムロケール設定の現在のステータスを表示するには、次のコマンドを実行します。
$ localectl status
デフォルトのシステムロケールオプションを設定または変更するには、
root
ユーザーでlocalectl set-locale
サブコマンドを使用します。以下に例を示します。# localectl set-locale LANG=en-US
関連情報
-
詳細は、
localectl(1)
、locale(7)
、およびlocale.conf(5)
の man ページを参照してください。
1.6.3. キーボードレイアウトの設定
キーボードレイアウト設定では、テキストコンソールとグラフィカルユーザーインターフェースで使用するレイアウトを管理します。
手順
利用可能なキーマップを一覧表示するには、以下を実行します。
$ localectl list-keymaps ANSI-dvorak al al-plisi amiga-de amiga-us ...
キーマップ設定の現在のステータスを表示するには、次のコマンドを実行します。
$ localectl status ... VC Keymap: us ...
デフォルトのシステムキーマップを設定または変更するには、
root
ユーザーでlocalectl set-keymap
サブコマンドを使用します。以下に例を示します。# localectl set-keymap us
関連情報
-
詳細は、
localectl(1)
、locale(7)
、およびlocale.conf(5)
の man ページを参照してください。
1.6.4. デスクトップ GUI を使用した言語の変更
本セクションでは、デスクトップ GUI を使用してシステム言語を変更する方法を説明します。
前提条件
- システムに必要な言語パッケージがインストールされている。
手順
システムメニュー
からアイコンをクリックしてGNOME コントロールセンター
を開きます。-
GNOME Control Center
で、左側の垂直バーから地域および言語
を選択します。 言語 メニューをクリックします。
メニューから必要な地域および言語を選択します。
該当する地域および言語が表示されない場合はスクロールダウンし、詳細 をクリックして、利用可能な地域および言語を選択します。
- 完了 をクリックします。
再起動 をクリックして変更を有効にします。
アプリケーションによっては、特定の言語に対応していないものもあります。選択した言語に翻訳できないアプリケーションのテキストは、アメリカ英語のままになります。
関連情報
-
GNOME Control Center
の起動方法に関する詳細は、「アプリケーションの起動」で説明されている方法を参照してください。
1.6.5. 関連情報
- 基本的な環境オプションの設定方法は『標準的な RHEL インストールの実行』を参照してください。
1.7. ネットワークアクセスの設定および管理
本セクションでは、Red Hat Enterprise Linux でイーサネット接続を追加するさまざまなオプションを説明します。
1.7.1. グラフィカルインストールモードでのネットワークおよびホスト名の設定
以下の手順に従って、ネットワークとホスト名を設定します。
手順
- インストール概要 画面から、 * をクリックします。
- 左側のペインのリストから、インターフェースを選択します。詳細が右側のペインに表示されます。
選択したインタフェースを有効または無効にするには、
スイッチを切り替えます。注記インストールプログラムは、ローカルでアクセス可能なインターフェースを自動的に検出し、手動で追加または削除できません。
- をクリックして、仮想ネットワークインターフェースを追加します。仮想ネットワークインターフェースは、チーム、ボンド、ブリッジ、または VLAN のいずれかです。
- を選択して、仮想インターフェースを削除します。
- をクリックして、既存のインターフェースの IP アドレス、DNS サーバー、またはルーティング設定 (仮想と物理の両方) などの設定を変更します。
ホスト名 フィールドに、システムのホスト名を入力します。
注記-
em1
やwl3sp0
といった一貫性のある名前をネットワークデバイスの特定に使用するネットワークデバイス命名の標準仕様には、いくつかのタイプがあります。このような標準仕様の詳細は『ネットワークの設定および管理』を参照してください。 -
ホスト名は、hostname.domainname という形式の完全修飾ドメイン名 (FQDN) か、ドメイン名のない短縮ホスト名のいずれかとなります。多くのネットワークには、自動的に接続したシステムにドメイン名を提供する DHCP (Dynamic Host Configuration Protocol) サービスがあります。DHCP サービスが、このマシンにドメイン名を割り当てるようにするには、短縮ホスト名のみを指定してください。
localhost.localdomain
の値は、ターゲットシステムの静的ホスト名が指定されておらず、(たとえば、DHCP または DNS を使用するNetworkManager
による) ネットワーク設定時に、インストールされるシステムの実際のホスト名が設定されることを示しています。
-
- をクリックして、ホスト名を環境に適用します。
その他のリソースおよび情報
- キックスタートファイルの使用時のネットワーク設定およびホスト名の設定の詳細は、『高度な RHEL インストールの実行』の該当する付録を参照してください。
-
Anaconda
インストールプログラムのテキストモードを使用して Red Hat Enterprise Linux をインストールする場合は、 オプションでネットワークを設定します。
1.7.2. nmcli を使用した静的イーサネット接続の設定
この手順では、nmcli
ユーティリティーを使用して、以下の設定でイーサネット接続を追加する方法を説明します。
-
静的 IPv4 アドレス:
/24
サブネットマスクを持つ192.0.2.1
-
静的 IPv6 アドレス:
2001:db8:1::1
(/64
サブネットマスクあり) -
IPv4 デフォルトゲートウェイ:
192.0.2.254
-
IPv6 デフォルトゲートウェイ:
2001:db8:1::fffe
-
IPv4 DNS サーバー:
192.0.2.200
-
IPv6 DNS サーバー:
2001:db8:1::ffbb
-
DNS 検索ドメイン:
example.com
手順
Ethernet 接続の NetworkManager 接続プロファイルを新たに追加します。
#
nmcli connection add con-name Example-Connection
ifname enp7s0 type ethernet以下の手順は、作成した
Example-Connection
接続プロファイルを変更します。IPv4 アドレスを設定します。
#
nmcli connection modify Example-Connection
ipv4.addresses 192.0.2.1/24IPv6 アドレスを設定します。
#
nmcli connection modify Example-Connection
ipv6.addresses 2001:db8:1::1/64IPv4 および IPv6 接続メソッドを
manual
に設定します。#
nmcli connection modify Example-Connection
ipv4.method manual #nmcli connection modify Example-Connection
ipv6.method manualIPv4 および IPv6 のデフォルトゲートウェイを設定します。
#
nmcli connection modify Example-Connection
ipv4.gateway 192.0.2.254 #nmcli connection modify Example-Connection
ipv6.gateway 2001:db8:1::fffeIPv4 および IPv6 DNS サーバーアドレスを設定します。
#
nmcli connection modify Example-Connection
ipv4.dns "192.0.2.200" #nmcli connection modify Example-Connection
ipv6.dns "2001:db8:1::ffbb"複数の DNS サーバーを設定するには、空白で区切って引用符で囲みます。
IPv4 および IPv6 接続の DNS 検索ドメインを設定します。
#
nmcli connection modify Example-Connection
ipv4.dns-search example.com #nmcli connection modify Example-Connection
ipv6.dns-search example.com接続プロファイルをアクティベートします。
#
nmcli connection up Example-Connection
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/13)
検証手順
デバイスおよび接続の状態を表示します。
#
nmcli device status
DEVICE TYPE STATE CONNECTION enp7s0 ethernet connected Example-Connection接続プロファイルのすべての設定を表示するには、次のコマンドを実行します。
#
nmcli connection show Example-Connection
connection.id: Example-Connection connection.uuid: b6cdfa1c-e4ad-46e5-af8b-a75f06b79f76 connection.stable-id: -- connection.type: 802-3-ethernet connection.interface-name: enp7s0 ...ping
ユーティリティーを使用して、このホストがパケットを他のホストに送信できることを確認します。同じサブネットの IP アドレスに ping します。
IPv4 の場合:
#
ping 192.0.2.3
IPv6 の場合:
#
ping 2001:db8:2::1
コマンドが失敗した場合は、IP およびサブネットの設定を確認します。
リモートサブネットの IP アドレスに ping します。
IPv4 の場合:
#
ping 198.162.3.1
IPv6 の場合:
#
ping 2001:db8:2::1
コマンドが失敗した場合は、デフォルトゲートウェイに ping して設定を確認します。
IPv4 の場合:
#
ping 192.0.2.254
IPv6 の場合:
#
ping 2001:db8:1::fffe
host
ユーティリティーを使用して名前解決が機能することを確認します。以下に例を示します。#
host client.example.com
connection timed out
やno servers could be reached
など、コマンドがエラーを返した場合は、DNS 設定を確認してください。
トラブルシューティングの手順
接続に失敗するか、ネットワークインターフェースが up と down の状態の間で切り替わる場合は、以下を行います。
- ネットワークケーブルがホストとスイッチにプラグインされていることを確認します。
- リンクの失敗がこのホストのみに存在するか、またはサーバーの接続先と同じスイッチに接続されている他のホストでも存在するかどうかを確認します。
- ネットワークケーブルとネットワークインターフェースが予想どおりに機能していることを確認します。ハードウェア診断手順を実施して、不具合ケーブルとネットワークインターフェースカードを置き換えます。
関連情報
-
接続プロファイルのプロパティーとその設定の詳細は、man ページの
nm-settings(5)
を参照してください。 -
nmcli
ユーティリティーの詳細は、nmcli(1)
の man ページを参照してください。 - ディスクの設定がデバイスの設定と一致しない場合は、NetworkManager を起動するか再起動して、インメモリー接続を作成することで、デバイスの設定を反映します。詳細と、この問題を回避する方法は、「NetworkManager duplicates a connection after restart of NetworkManager service」を参照してください。
- 接続にデフォルトゲートウェイがない場合は、『ネットワークガイド』の「ネットワークの設定および管理」のドキュメントで特定のプロファイルを使用してデフォルトのゲートウェイを提供しないようにするように NetworkManager の設定を参照してください。
1.7.3. nmtui を使用した接続プロファイルの追加
nmtui
アプリケーションで、NetworkManager へのテキストユーザーインターフェースが含まれます。この手順では、新しい接続プロファイルを追加する方法を説明します。
前提条件
-
NetworkManager-tui
パッケージがインストールされている。
手順
NetworkManager のテキストユーザーインターフェースユーティリティーを起動します。
#
nmtui
-
接続の編集
メニューエントリーを選択し、Enter を押します。 - Enter を押します。 ボタンを選択し、
-
Ethernet
を選択し、Enter を押します。 フィールドにコネクションの詳細を入力します。
- をクリックして変更を保存します。
-
Back
を選択してメインメニューに戻ります。 -
Activate a connection
を選択し、Enter を押します。 - 新しい接続エントリーを選択し、Enter を押して接続をアクティベートします。
- を選択してメインメニューに戻ります。
-
Quit
を選択します。
検証手順
デバイスおよび接続の状態を表示します。
#
nmcli device status
DEVICE TYPE STATE CONNECTION enp1s0 ethernet connected Example-Connection接続プロファイルのすべての設定を表示するには、次のコマンドを実行します。
#
nmcli connection show Example-Connection
connection.id: Example-Connection connection.uuid: b6cdfa1c-e4ad-46e5-af8b-a75f06b79f76 connection.stable-id: -- connection.type: 802-3-ethernet connection.interface-name: enp1s0 ...
関連情報
-
接続テストの詳細は、
『ネットワークの設定および管理』
の「基本的なネットワーク設定のテスト」を参照してください。 -
nmtui
アプリケーションの詳細は、nmtui(1)
のman ページを参照してください。 - ディスクの設定がデバイスの設定と一致しない場合は、NetworkManager を起動するか再起動して、インメモリー接続を作成することで、デバイスの設定を反映します。詳細と、この問題を回避する方法は、「NetworkManager duplicates a connection after restart of NetworkManager service」を参照してください。
1.7.4. RHEL 8 Web コンソールにおけるネットワークの管理
Web コンソールの
メニューでは、以下が可能です。- 最近送受信したパケットの表示
- 利用可能なネットワークインターフェースの最も重要な特徴の表示
- ネットワーキングログのコンテンツの表示
- ネットワークインターフェースのさまざまなタイプ (ボンディング、チーム、ブリッジ、VLAN) の追加
図1.1 RHEL 8 Web コンソールにおけるネットワークの管理

1.7.5. RHEL システムロールを使用したネットワークの管理
network
ロールを使用して、複数のターゲットマシンにネットワーク接続を構成できます。
network
ロールでは、以下のタイプのインターフェースを構成できます。
- イーサネット
- ブリッジ
- ボンディング
- VLAN
- MacVLAN
- Infiniband
各ホストに必要なネットワーク接続は、network_connections
変数内にリストとして提供されます。
network
ロールは、network_connections
変数で指定されているとおりに、ターゲットシステムにあるすべての接続プロファイルを更新または作成します。したがって、そのオプションがそのシステムにのみ存在し、network_connections
変数にはない場合、network
ロールは指定されたプロファイルからオプションを削除します。
以下の例は、必要なパラメーターを持つイーサネット接続が確実に設定されるように、network
ロールを適用する方法を示しています。
例1.3 必要なパラメーターでイーサネット接続を設定する network ロールを適用する Playbook の例
# SPDX-License-Identifier: BSD-3-Clause --- - hosts: network-test vars: network_connections: # Create one ethernet profile and activate it. # The profile uses automatic IP addressing # and is tied to the interface by MAC address. - name: prod1 state: up type: ethernet autoconnect: yes mac: "00:00:5e:00:53:00" mtu: 1450 roles: - rhel-system-roles.network
システムロールを適用する方法は、「RHEL システムロールの概要」を参照してください。
1.7.6. 関連情報
- ネットワークボンディングやチーミングの設定など、ネットワーク設定の詳細は『ネットワークの設定および管理』を参照してください。
1.8. システム登録およびサブスクリプション管理
Red Hat Enterprise Linux オペレーティングシステムと、そこにインストールされている製品は、サブスクリプションの対象となります。
Red Hat コンテンツ配信ネットワーク (CDN) サブスクリプションを使用して、以下を追跡します。
- 登録したシステム
- システムにインストールされている製品
- インストール済みの製品に割り当てられているサブスクリプション
1.8.1. インストール後のシステム登録
インストールプロセス中にシステムを登録していない場合は、以下の手順に従って登録します。
前提条件
- Red Hat カスタマーポータルに有効なユーザーアカウントがある。
- 「Red Hat アカウントの作成」ページを参照してください。
- RHEL システムに使用するアクティブなサブスクリプションがある。
- インストールプロセスの詳細は『標準的な RHEL インストールの実行』を参照してください。
手順
ワンステップでシステムを登録し、自動的にサブスクライブします。
# subscription-manager register --username <username> --password <password> --auto-attach Registering to: subscription.rhsm.redhat.com:443/subscription The system has been registered with ID: 37to907c-ece6-49ea-9174-20b87ajk9ee7 The registered system name is: client1.idm.example.com Installed Product Current Status: Product Name: Red Hat Enterprise Linux for x86_64 Status: Subscribed
コマンドを実行すると、Red Hat カスタマーポータルのユーザー名とパスワードの入力を求めるプロンプトが表示されます。
登録プロセスに失敗した場合は、システムを特定のプールに登録できます。これを実行する方法については、以下の手順に従います。
必要なサブスクリプションのプール ID を確認します。
# subscription-manager list --available
このコマンドは、使用している Red Hat アカウントで利用可能なサブスクリプションをすべて表示します。サブスクリプションごとに、プール ID を含むさまざまな情報が表示されます。
pool_id を、確認したプール ID に置き換えて、適切なサブスクリプションをシステムに割り当てます。
# subscription-manager attach --pool=pool_id
関連情報
-
--auto-attach
オプションを使用して RHEL システムを登録する方法は、「カスタマーポータルでサブスクリプションの自動アタッチについて」を参照してください。 - RHEL システムを手動で登録する方法は、「Understanding the manual registration and subscription on the Customer Portal」を参照してください。
1.8.2. Web コンソールで認証情報を使用してサブスクリプションを登録
RHEL 8 Web コンソールを使用して、新たにインストールした Red Hat Enterprise Linux を登録するには、以下の手順に従います。
前提条件
Red Hat カスタマーポータルに有効なユーザーアカウントがある。
「Red Hat アカウントの作成」ページを参照してください。
- RHEL システムに使用するアクティブなサブスクリプションがある。
手順
検索フィールドに「subscription」と入力して、Enter キーを押します。
RHEL 8 Web コンソールにログインすることもできます。詳細は「Web コンソールへのログイン」を参照してください。
特権タスク用の
polkit
認証ダイアログで、ダイアログに表示されているユーザー名のパスワードを入力します。- 認証 をクリックします。
サブスクリプション ダイアログボックスの 登録 をクリックします。
カスタマーポータルの認証情報を入力します。
組織の名前を入力してください。
Red Hat カスタマーポータルにアカウントが複数ある場合は、組織名または組織 ID を追加する必要があります。組織 ID は、Red Hat の連絡先に問い合わせてください。
- 登録 ボタンをクリックします。
この時点で、Red Hat Enterprise Linux 8 システムが正常に登録されました。
1.8.3. GNOME での Red Hat アカウントを使用したシステム登録
以下の手順に従って、システムを Red Hat アカウントに登録します。
前提条件
Red Hat カスタマーポータルで有効なアカウント
新規ユーザー登録は、「Red Hat アカウントの作成」ページを参照してください。
手順
- 画面右上からアクセスできる システムメニュー に移動し、設定 アイコンをクリックします。
- → セクションで、 をクリックします。
- Registration Server を選択します。
- Red Hat サーバーを使用しない場合は、URL フィールドにサーバーアドレスを入力します。
- Registration Type メニューで、Red Hat Account を選択します。
Registration Details で以下を行います。
- Login フィールドに Red Hat アカウントのユーザー名を入力します。
- Password フィールドに Red Hat アカウントのパスワードを入力します。
- Organizaiton フィールドに組織の名前を入力します。
- をクリックします。
1.8.4. GNOME でのアクティベーションキーを使用したシステム登録
以下の手順に従って、システムをアクティベーションキーに登録します。組織の管理者からアクティベーションキーを取得できます。
前提条件
アクティベーションキーまたはキー。
新しいアクティベーションキーを作成するには、アクティベーションキーページを参照してください。
手順
- 画面右上からアクセスできる システムメニュー に移動し、設定 アイコンをクリックします。
- → セクションで、 をクリックします。
- Registration Server を選択します。
- Red Hat サーバーを使用していない場合は、カスタマイズされたサーバーに URL を入力します。
- Registration Type メニューで、Activation keys を選択します。
Registration Details で以下を行います。
Activation keys を入力します。
複数の鍵をコンマ (,) で区切ります。
- 組織 フィールドに組織の名前または ID を入力します。
- をクリックします。
1.9. システム起動時に systemd サービスの開始
systemd は、Linux オペレーティングシステム用のシステムおよびサービスのマネージャーで、systemd ユニットの概念が使用されています。
本セクションでは、システムの起動時にサービスを有効または無効にする方法を説明します。また、Web コンソールを使用してサービスを管理する方法も説明します。
1.9.1. CLI を使用したサービスの有効化または無効化
インストールプロセス時に、システムの起動時に有効または無効にするサービスを確認できます。インストール後に、オペレーティングシステムのサービスを有効または無効にできます。
本セクションでは、インストール済みのオペレーティングシステムでこれらのサービスを有効または無効にする手順を説明します。
前提条件
- システムへの root アクセス権限がある。
手順
サービスを有効にするには、
enable
オプションを使用します。# systemctl enable service_name
service_name は、有効にするサービスに置き換えます。
1 つのコマンドでサービスを有効にして起動することもできます。
# systemctl enable --now service_name
サービスを無効にするには、
disable
オプションを使用します。# systemctl disable service_name
service_name は、無効にするサービスに置き換えます。
以前マスクされたサービスを有効化できません。最初にマスクを解除する必要があります。
# systemctl unmask service_name
1.9.2. RHEL 8 Web コンソールにおけるサービスの管理
本セクションでは、Web コンソールを使用してサービスを有効または無効にする方法を説明します。systemd ターゲット、サービス、ソケット、タイマー、およびパスを管理できます。また、サービスのステータス、開始または停止を確認し、サービスを有効または無効にすることもできます。
前提条件
- システムへの root アクセス権限がある。
手順
-
任意の Web ブラウザーで
https://localhost:9090/
を開きます。 - システム上の root 認証情報を使用して Web コンソールにログインします。
Web コンソールパネルを表示するには、ウィンドウの左上にある
ホスト
アイコンをクリックします。メニューで、
をクリックします。systemd ターゲット、サービス、ソケット、タイマー、およびパスを管理できます。
たとえば、サービスの NFS クライアントサービス を管理するには、以下を実行します。
- をクリックします。
- NFS Client Services のサービスを選択します。
- サービスを有効または無効にするには、 ボタンをクリックします。
サービスを停止するには、
ボタンをクリックし、オプション 'Stop' を選択します。
1.10. システムセキュリティーの設定
コンピューターセキュリティーとは、盗難、損傷、破壊、および誤りからコンピューターシステムやハードウェア、ソフトウェア、情報、およびサービスを保護することです。機密データを処理してビジネス取引を扱う企業では特に、コンピューターセキュリティーの確保は必須タスクです。
本セクションでは、オペレーティングシステムのインストール後に設定できる基本的なセキュリティー機能のみを説明します。Red Hat Enterprise Linux のセキュリティー保護に関する詳細は、『Product Documentation for Red Hat Enterprise Linux 8』の Security セクションのタイトルを参照してください。
1.10.1. ファイアウォールを使用したシステムセキュリティーの強化
ファイアウォールは、既定のセキュリティールールに基づいてネットワークトラフィックの送受信の監視および制御を行うネットワークセキュリティーシステムです。ファイアウォールは、通常、信頼できる安全な内部ネットワークと、その他の外部ネットワークとの間に壁を作ります。
Red Hat Enterprise Linux でファイアウォールを提供する firewalld
サービスは、インストール時に自動的に有効になります。
1.10.1.1. ファイアウォールサービスの有効化
firewalld
サービスを有効にするには、以下の手順に従います。
手順
firewalld
の現在の状況の表示$ systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) Active: inactive (dead) ...
firewalld
が有効になっていない場合は、root
ユーザーに切り替えて、firewalld
サービスを起動し、システムの再起動後に自動的に起動できるようにします。# systemctl enable --now firewalld
検証手順
firewalld
が実行中で、有効になっていることを確認します。$ systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) ...
関連情報
-
詳細は、
firewalld(1)
の man ページを参照してください。
1.10.1.2. RHEL 8 Web コンソールでファイアウォールの管理
Web コンソールで firewalld
サービスを設定するには、 → に移動します。
デフォルトでは、firewalld
サービスは有効になっています。
手順
Web コンソールで
firewalld
を有効または無効にするには、 のトグルボタンを切り替えます。
さらに、
ボタンを使用して、ファイアウォール経由でのサービスへのアクセスをより詳細にわたり定義できます。1.10.1.3. 関連情報
- ファイアウォールの設定および使用の詳細は、「firewalld の使用および設定」を参照してください。
1.10.2. 基本的な SELinux 設定の管理
Security Enhanced Linux (SELinux) は、どのプロセスがどのファイル、ディレクトリー、およびポートにアクセスできるのかを指定するシステムセキュリティーの追加レイヤーです。これらのパーミッションは、SELinux ポリシーで定義します。ポリシーは、SELinux セキュリティーエンジンをガイドする一連のルールです。
1.10.2.1. SELinux のステータスおよびモード
SELinux のステータスには、以下の 2 つがあります。
- 無効
- 有効
SELinux が有効な場合は、以下のいずれのモードで実行できます。
有効
- Enforcing
- Permissive
Enforcing モード では、SELinux は読み込まれたポリシーを強制的に実行します。SELinux は、SELinux ポリシールールに基づいてアクセスを拒否し、明示的に許可された対話だけを有効にします。Enforcing モードは最も安全な SELinux モードであり、インストール後のデフォルトモードです。
Permissive モード
では、SELinux は読み込まれたポリシーを強制に実行しません。SELinux はアクセスを拒否しませんが、ルールに違反するアクションを /var/log/audit/audit.log
ログで報告します。Permissive モードは、インストール時のデフォルトのモードです。Permissive モードは、問題のトラブルシューティングなど、特定のケースで役に立ちます。
関連情報
- SELinux の詳細は、『SELinux の使用』を参照してください。
1.10.2.2. SELinux で必要な状態を確認
デフォルトでは、SELinux は Enforcing モードで動作します。ただし、特定のシナリオでは、SELinux を Permissive モードに設定したり、無効にしたりすることもできます。
Red Hat は、Enforcing モードでシステムを使用することを推奨します。デバッグの目的で、SELinux を Permissive モードに設定します。
以下の手順に従って、システムの SELinux の状態とモードを変更します。
手順
現在有効な SELinux モードを表示します。
$ getenforce
SELinux を一時的に設定します。
Enforcing モードに設定する場合:
# setenforce Enforcing
Permissive モードに設定する場合:
# setenforce Permissive
注記再起動後に、SELinux モードは
/etc/selinux/config
設定ファイルで指定された値に設定されます。
再起動後も SELinux モードを保持するように設定するには、
/etc/selinux/config
設定ファイルのSELINUX
変数を変更します。たとえば、SELinux を Enforcing モードに切り替えるには、以下のように設定します。
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing ...
警告SELinux を無効にすると、システムセキュリティーが低下します。無効にすると、メモリーリークや競合状態によりカーネルパニックが発生する可能性があるため、
/etc/selinux/config
ファイルのSELINUX=disabled
オプションを使用して SELinux を無効にしないでください。代わりに、「システムの起動時に SELinux モードの変更」で説明されているように、selinux=0
パラメーターをカーネルコマンドラインに追加して SELinux を無効にします。
関連情報
- SELinux モードの永続的な変更の詳細は、「SELinux のステータスおよびモードの変更」を参照してください。
1.10.2.3. RHEL 8 Web コンソールで SELinux モードの切り替え
SELinux メニュー項目の RHEL 8 Web コンソールで SELinux モードを設定できます。
デフォルトでは、Web コンソールの SELinux の Enforcing ポリシーが有効になっており、SELinux が Enforcing モードで動作します。このモードを無効にして、SELinux を Permissive モードに切り替えます。モードの選択は、次回の起動時に /etc/sysconfig/selinux
ファイルで定義されている設定に自動的に元に戻されます。
手順
Web コンソールで、SELinux メニュー項目の
トグルボタンを使用して SELinux の Enforcing ポリシーをオンまたはオフにします。
1.10.2.4. 次のステップ
-
selinux
システムロールを使用すると、複数のターゲットシステムでさまざまな SELinux のローカルカスタマイズを管理できます。詳細は「複数のシステムに同じ SELinux 設定をデプロイ」セクションを参照してください。
1.10.3. 次のステップ
1.11. ユーザーアカウントの管理
Red Hat Enterprise Linux は、マルチユーザー向けのオペレーティングシステムです。つまり、1 台のマシンにインストールされた 1 つのシステムに、複数のユーザーが別々のコンピューターからアクセスできます。
各ユーザーは自身のアカウントで操作します。このような方法でユーザーアカウントを管理することは、Red Hat Enterprise Linux のシステム管理の中心的要素になります。
1.11.1. ユーザーアカウントとグループの概要
本セクションでは、ユーザーアカウントとグループを概説します。以下に各種ユーザーアカウントを紹介します。
通常のユーザーアカウント
通常のアカウントは特定システムのユーザー用に作成されます。このようなアカウントは、通常のシステム管理中に追加、削除、および修正できます。
システムユーザーアカウント
システムユーザーアカウントは、システムで特定のアプリケーション識別子を表します。このようなアカウントは通常、ソフトウェアのインストール時にのみ追加または操作され、後で変更することはありません。
警告システムアカウントは、システムでローカルに利用できると想定されています。アカウントがリモートで設定され、提供されている (LDAP の設定など) と、システムが破損したり、サービスが開始できない場合があります。
システムアカウント用に、1000 番未満のユーザー ID が予約されています。通常のアカウントには、1000 から始まる ID を使用できます。ただし、5000 以降の ID を割り当てることが推奨されます。
グループ
グループとは、複数のユーザーアカウントを共通目的 (特定のファイルにアクセス権を与えるなど) で統合するエンティティーです。
- 詳細は以下を参照してください。
-
ID の割り当ては、
/etc/login.defs
ファイルを参照してください。
1.11.2. コマンドラインツールを使用したアカウントとグループの管理
本セクションでは、ユーザーアカウントとグループを管理する基本的なコマンドラインツールを説明します。
ユーザーおよびグループ ID を表示します。
$ id uid=1000(example.user) gid=1000(example.user) groups=1000(example.user),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
新規ユーザーアカウントを作成します。
# useradd example.user
example.user に属するユーザーアカウントに新しいパスワードを割り当てます。
# passwd example.user
ユーザーをグループを追加します。
# usermod -a -G example.group example.user
関連情報
-
useradd(8)
、passwd(1)
、およびusermod(8)
の man ページ
1.11.3. Web コンソールで管理されるシステムユーザーアカウント
RHEL Web コンソールに表示されているユーザーアカウントでは、以下が可能になります。
- システムにアクセスする際にユーザーを認証する
- システムへのアクセス権を設定する
RHEL Web コンソールは、システムに存在するすべてのユーザーアカウントを表示します。そのため、最初に Web コンソールにログインした直後は、ユーザーアカウントが少なくとも 1 つ表示されます。
RHEL Web コンソールにログインしたら、以下の操作を実行できます。
- 新規ユーザーアカウントの作成
- パラメーターの変更
- アカウントのロック
- ユーザーセッションの終了
1.11.4. Web コンソールで新規アカウントの追加
RHEL Web コンソールを使用して、ユーザーアカウントをシステムに追加し、アカウントに管理者権限を設定する場合は、以下の手順に従います。
前提条件
- RHEL Web コンソールがインストールされており、アクセス可能である。詳細は「Web コンソールのインストール」を参照してください。
手順
- RHEL Web コンソールにログインします。
- をクリックします。
フルネーム フィールドにユーザーの氏名を入力します。
RHEL Web コンソールは、入力した氏名からユーザー名が自動的に作成され、ユーザー名 フィールドに入力されます。名前の頭文字と、苗字で構成される命名規則を使用しない場合は、入力されたユーザー名を変更します。
パスワード/確認 フィールドにパスワードを入力し、再度パスワードを入力します。フィールドの下にあるカラーバーは、入力したパスワードの強度を表し、弱いパスワードは使用できないようにします。
- をクリックして設定を保存し、ダイアログボックスを閉じます。
- 新規作成したアカウントを選択します。
- ロール で、サーバー管理者 を選択します。
これで アカウント 設定に新規アカウントが表示され、認証情報を使用してシステムに接続できるようになりました。
1.12. 後で分析するためにクラッシュしたカーネルのダンプ
kdump
サービスを使用して後で分析できるようにシステムのメモリー内容を保存することで、システムがクラッシュした理由を分析できます。
本セクションでは、kdump
の概要と、RHEL Web コンソールまたは対応する RHEL システムロールを使用して kdump
を設定する方法を説明します。
1.12.1. kdump とは
kdump
は、クラッシュダンプメカニズムを提供するサービスです。このサービスを使用すると、システムのメモリーの内容を後で分析するために保存できます。kdump
は kexec
システムコールを使用して再起動せずに別のカーネル (capture kernel) で起動し、クラッシュしたカーネルメモリーの内容 (crash dump または vmcore) をキャプチャーして保存します。この第 2 のカーネルは、システムメモリーの予約部分に収納されています。
カーネルクラッシュダンプは、システム障害 (重大なバグ) 時に利用できる唯一の情報になります。したがって、ミッションクリティカルな環境では、kdump
を確実に稼働させることが重要です。Red Hat は、システム管理者が通常のカーネル更新サイクルで kexec-tools
を定期的に更新してテストすることをお勧めします。これは、新しいカーネル機能が実装されている場合に特に重要です。
1.12.2. Web コンソールで kdump メモリーの使用量およびターゲットの場所を設定
以下の手順は、Red Hat Enterprise Linux Web コンソールインターフェースで Kernel Dump
タブを使用して、kdump カーネル用に予約されたメモリー容量を設定する方法を説明します。この手順では、vmcore ダンプファイルのターゲットの場所を指定する方法と、設定をテストする方法を説明します。
前提条件
- Web コンソール の操作概要
手順
-
Kernel Dump
タブを開き、kdump
サービスを開始します。 -
コマンドラインで
kdump
のメモリー使用量を設定します。 クラッシュダンプの場所
オプションの横にあるリンクをクリックします。ドロップダウンメニューから
ローカルファイルシステム
を選択し、ダンプを保存するディレクトリーを指定します。または、ドロップダウンから
SSH 経由のリモート
オプションを選択し、SSH プロトコルを使用して、vmcore をリモートマシンに送信します。Server
、ssh key
、Directory
の各フィールドに、リモートマシンのアドレス、ssh キーの場所、およびターゲットディレクトリーを入力します。または、ドロップダウンから
NFS 経由のリモート
オプションを選択し、マウント
フィールドに入力して、NFS プロトコルを使用して vmcore をリモートマシンに送信することもできます。注記圧縮
チェックボックスにチェックマークを入れ、vmcore ファイルのサイズを小さくします。
カーネルをクラッシュして、設定をテストします。
警告この手順では、カーネルの実行を中断し、システムクラッシュやデータの損失が発生します。
関連情報
-
現在対応している
kdump
のターゲットの完全リストは、「対応している kdump のダンプ出力先」を参照してください。 - SSH サーバーの設定および鍵ベースの認証の設定方法は、「OpenSSH を使用したシステム間でセキュアな通信の使用」を参照してください。
1.12.3. RHEL システムロールを使用した kdump の設定
RHEL システムロールは、複数の RHEL システムをリモートで管理する一貫した構成インターフェースを提供する Ansible ロールおよびモジュールの集合です。kdump
ロールを使用すると、複数のシステムに基本的なカーネルダンプパラメーターを設定できます。
kdump
ロールは、/etc/kdump.conf
ファイルを置き換えて、管理対象ホストの kdump
設定をすべて置き換えます。また、kdump
ロールが適用されると、 /etc/sysconfig/kdump
ファイルを置き換えて、ロール変数で指定されていない場合でも、以前の kdump
の設定もすべて置き換えられます。
以下の例は、kdump
システムロールを適用してクラッシュダンプファイルの場所を設定する方法を示しています。
--- - hosts: kdump-test vars: kdump_path: /var/crash roles: - rhel-system-roles.kdump
関連情報
-
kdump
ロール変数の詳細は、rhel-system-roles
パッケージをインストールし、/usr/share/doc/rhel-system-roles/kdump
ディレクトリーのREADME.md
またはREADME.html
ファイルを参照してください。 - RHEL システムロールの詳細は、「RHEL のシステムロールの概要」 を参照してください。
1.12.4. 関連情報
-
kdump
の詳細は「kdump のインストールと設定」を参照してください。
1.13. システムの復旧および復元
Red Hat Enterprise Linux では、既存のバックアップを使用してシステムを復旧および復元するために、ReaR (Relax-and-Recover) ユーティリティーが同梱されています。
このユーティリティーは、障害復旧ソリューションとして、またシステム移行にも使用できます。
このユーティリティーを使用すると、以下のタスクを実行できます。
- イメージを使用して、起動可能なイメージを作成し、既存のバックアップからシステムを復元する
- オリジナルのストレージレイアウトを複製する
- ユーザーおよびシステムファイルを復元する
- システムを別のハードウェアに復元する
また、障害復旧の場合は、特定のバックアップソフトウェアを ReaR に統合することもできます。
ReaR 設定の概要手順は以下のとおりです。
- ReaR をインストールします。
- レスキューシステムを作成します。
- ReaR 設定ファイルを変更して、バックアップ手法の詳細を追加します。
- バックアップファイルを生成します。
1.13.1. ReaR の設定
以下の手順を使用して、Relax-and-Recover (ReaR) ユーティリティーを使用するパッケージのインストール、レスキューシステムの作成、バックアップの設定および生成を行います。
前提条件
バックアップ復元計画をもとに、必要な設定の準備が整いました。
NETFS
バックアップメソッド (ReaR に完全に統合され、組み込まれたメソッド) を使用できることに注意してください。
手順
ReaR、
genisomage
のマスター前のプログラム、およびブートローダースイートが含まれるsyslinux
パッケージをインストールします。# yum install rear genisoimage syslinux
レスキューシステムを作成します。
# rear mkrescue
以下の例のように、任意のエディターで ReaR 設定ファイルを変更します。
# vi /etc/rear/local.conf
バックアップ設定の詳細を
/etc/rear/local.conf
に追加します。たとえば、NETFS
バックアップメソッドの場合は、以下の行を追加します。BACKUP=NETFS BACKUP_URL=backup.location
backup.location は、バックアップ先の URL に置き換えます。
新規バックアップの作成時に以前のバックアップアーカイブを維持するように RaaR 設定を行うには、以下の行を設定ファイルに追加します。
NETFS_KEEP_OLD_BACKUP_COPY=y
増分バックアップ (実行するたびに変更されたファイルのみがバックアップされる) を設定する場合は、以下の行を追加します。
BACKUP_TYPE=incremental
- 復元計画に従ってバックアップを作成します。
1.14. ログファイルを使用した問題のトラブルシューティング
ログファイルは、システム (カーネル、サービス、および実行中のアプリケーションなど) に関するメッセージが含まれるファイルです。ログファイルには、問題のトラブルシューティングやシステム機能の監視に役立つ情報が含まれています。Red Hat Enterprise Linux におけるロギングシステムは、組み込みの syslog
プロトコルに基づいています。特定のプログラムがこのシステムを使用してイベントを記録し、ログファイルに分類します。 これは、オペレーティングシステムの監査およびさまざまな問題のトラブルシューティングに役立ちます。
1.14.1. syslog メッセージを処理するサービス
以下の 2 つのサービスは、syslog
メッセージを処理します。
-
systemd-journald
デーモン -
Rsyslog
サービス
systemd-journald
デーモンは、さまざまなソースからメッセージを収集し、収集したメッセージを処理するために Rsyslog
に転送します。systemd-journald
デーモンは、以下のソースからメッセージを収集します。
- カーネル
- ブートプロセスの初期段階
- 起動時および実行時のデーモンの標準出力とエラー
-
Syslog
Rsyslog
サービスは、タイプおよび優先順で syslog
のメッセージを分類し、/var/log
ディレクトリー内のファイルに書き込みます。/var/log
ディレクトリーは、ログメッセージを永続的に保存します。
1.14.2. syslog メッセージを保存するサブディレクトリー
/var/log
ディレクトリー内の以下のサブディレクトリーでは、syslog
メッセージを保存します。
-
/var/log/messages
- 以下を除くすべてのsyslog
メッセージ -
/var/log/secure
- セキュリティーおよび認証に関連するメッセージおよびエラー -
/var/log/maillog
- メールサーバーに関連するメッセージおよびエラー -
/var/log/cron
- 定期的に実行されるタスクに関連するログファイル -
/var/log/boot.log
- システムの起動に関連するログファイル
1.14.3. Web コンソールでログファイルの検査
以下の手順に従って、Web コンソールを使用してログファイルを検証します。
手順
Red Hat Enterprise Linux 8 Web コンソールにログインします。
詳細は「Web コンソールへのログイン」を参照してください。
- ログ をクリックします。
図1.2 RHEL 8 Web コンソールでログファイルの検査

1.14.4. コマンドラインでのログの表示
Journal は、ログファイルの表示および管理に役立つ systemd のコンポーネントです。従来のロギングに関連する問題に対応し、残りのシステムと密接に統合され、ログファイルのさまざまなロギングテクノロジーおよびアクセス管理をサポートします。
journalctl
コマンドを使用すると、以下のようにコマンドラインを使用してシステムジャーナルのメッセージを表示できます。
$ journalctl -b | grep kvm
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: cpu 0, msr 76401001, primary cpu clock
...
表1.1 システム情報の表示
コマンド | 説明 |
---|---|
| 収集されたジャーナルエントリーをすべて表示します。 |
|
特定のファイルに関連するログを表示します。たとえば、 |
| 現在のブートのログを表示します。 |
| 現在のブートのカーネルログを表示します。 |
表1.2 特定のサービスの情報の表示
コマンド | 説明 |
---|---|
|
ログをフィルターして、「foo」の |
|
一致を組み合わせます。たとえば、このコマンドは、 |
|
区切り文字「+」は、論理 OR の 2 つの式を組み合わせます。たとえば、以下のコマンドは、 |
|
このコマンドは、同じフィールドを参照し、いずれかの式に一致するエントリーをすべて表示します。このコマンドは、systemd-unit |
表1.3 特定のブートに関連するログの表示
コマンド | 説明 |
---|---|
| ブート番号、その ID、およびブートに関する最初のメッセージと最後のメッセージのタイムスタンプの表形式一覧が表示されます。以下のコマンドの ID を使用して詳細情報を表示できます。 |
| 指定したブート ID に関する情報を表示します。 |
1.14.5. 関連情報
-
ログを記録するように
Rsyslog
を設定する方法は、「リモートロギングソリューションの設定」を参照してください。 -
journalctl(1)
の man ページ -
systemd
の詳細は、「systemdによるサービス管理」を参照してください。
1.15. Red Hat サポートへのアクセス
本セクションでは、Red Hat サポートおよび sosreport
を使用して問題を効果的にトラブルシューティングする方法を説明します。
Red Hat サポートを利用する場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルでは、サブスクリプションで利用可能なものをすべて提供します。
1.15.1. Red Hat カスタマーポータルで利用できる Red Hat サポート
以下のセクションでは、Red Hat カスタマーポータルを使用してサポートを受ける方法を説明します。
前提条件
- Red Hat カスタマーポータルに有効なユーザーアカウントがある。「Red Hat ログインの作成」を参照してください。
- RHEL システムに使用するアクティブなサブスクリプションがある。
手順
Red Hat サポート にアクセスします。
- サポートケースを作成する
- Red Hat 専門スタッフとのライブチャットを開始する
- 電話または電子メールで Red Hat 専門スタッフに問い合わせる
1.15.2. sosreport を使用した問題のトラブルシューティング
sosreport
コマンドは設定の詳細、システム情報、および診断情報を Red Hat Enterprise Linux システムから収集します。
次のセクションでは、sosreport
コマンドを使用して、サポートケースのレポートを作成する方法を説明します。
前提条件
- Red Hat カスタマーポータルに有効なユーザーアカウントがある。「Red Hat ログインの作成」を参照してください。
- RHEL システムに使用するアクティブなサブスクリプションがある。
- サポートケース番号。
手順
sos
パッケージをインストールするには、以下のコマンドを実行します。# yum install sos
注記Red Hat Enterprise Linux のデフォルトの最小インストールには、
sosreport
コマンドを提供するsos
パッケージは含まれません。レポートを生成します。
# sosreport
サポートケースにレポートを添付します。
「How can I attach a file to a Red Hat support case?」を参照してください。詳細は、Red Hat ナレッジベースの記事を参照してください。
レポートを添付すると、該当のサポートケース番号の入力が求められます。
関連情報
-
sosreport
の詳細は、「Red Hat Enterprise Linux 4.6 以降における sosreport の役割と取得方法」を参照してください。Red Hat ナレッジベースの記事
第2章 ソフトウェアパッケージの管理
2.1. Red Hat Enterprise Linux 8 のソフトウェア管理ツール
RHEL 8 では、DNF テクノロジーをベースにする新しいバージョンの YUM ツール (YUM v4) によりソフトウェアインストールが有効になります。
アップストリームのドキュメントでは、このテクノロジーを DNF と識別しているので、このツールはアップストリームの DNF と呼ばれます。これにより、RHEL 8 の新しい YUM ツールが返した出力の一部で、DNF と表示されます。
RHEL 8 で使用される YUM v4
は DNF に基づいていますが、RHEL 7 で使用される YUM v3 と互換性があります。ソフトウェアのインストールでは、yum
コマンドとそのオプションのほとんどが、RHEL 7 で実行したように RHEL 8 で機能します。
選択した yum プラグインおよびユーティリティーは、新しい DNF バックエンドに移植されており、RHEL 7 と同じ名前でインストールできます。パッケージは互換性を持ったシンボリックリンクを提供するため、バイナリー、設定ファイル、ディレクトリーは通常の場所で確認できます。
YUM v3 が提供する以前の Python API は利用できなくなりました。YUM v4 (DNF Python API) が提供する安定し、完全に対応する新しい API に、使用しているプラグインおよびスクリプトを移行できます。詳細は、「DNF API Reference」を参照してください。
2.2. アプリケーションストリーム
Red Hat Enterprise Linux 8 では、アプリケーションストリームの概念が導入されました。ユーザー空間コンポーネントのバージョンは複数配信され、コアオペレーティングシステムのパッケージよりも頻繁に更新されるようになりました。これによりプラットフォームや特定のデプロイメントの基本的な安定性に影響を及ぼすことなく、Red Hat Enterprise Linux をカスタマイズする柔軟性が向上します。
アプリケーションストリームとして使用できるコンポーネントは、モジュールまたは RPM パッケージとしてパッケージ化され、Red Hat Enterprise Linux 8 の AppStream リポジトリーを介して配信されます。各アプリケーションストリームには、特定のアプリケーションにより適した、RHEL 8 と同じか、より短いライフサイクルが指定されています。ライフサイクルが短いアプリケーションストリームは、「Red Hat Enterprise Linux 8 Application Streams ライフサイクル」ページに記載されています。
モジュールは、論理ユニット (アプリケーション、言語スタック、データベース、またはツールセット) を表すパッケージの集まりです。これらのパッケージはまとめてビルドされ、テストされ、そしてリリースされます。
モジュールストリームは、アプリケーションストリームコンポーネントのバージョンを表します。たとえば、postgresql モジュールでは 2 つのストリーム (バージョン) の PostgreSQL データベースサーバー、つまり PostgreSQL 10 (デフォルトストリーム) および PostgreSQL 9.6 が利用できます。システムにインストールできるモジュールストリームは 1 つだけです。複数のコンテナーで異なるバージョンを使用できます。
詳細なモジュールコマンドは『ユーザー空間コンポーネントのインストール、管理、および削除』を参照してください。AppStream で利用可能なモジュールの一覧は『パッケージマニフェスト』を参照してください。
2.3. ソフトウェアパッケージの検索
yum を使用すると、ソフトウェアパッケージをすべて操作できます。
以下のセクションでは、yum を使用して以下を行う方法を説明します。
- パッケージを検索する
- パッケージを一覧表示する
- リポジトリーを一覧表示する
- パッケージに関する情報を表示する
- パッケージグループを一覧表示する
- yum input での glob 表現を指定する
2.3.1. yum を使用したパッケージの検索
パッケージを検索するには、以下を使用します。
# yum search term
term は、パッケージ関連の用語に置き換えます。
yum search
コマンドでは、パッケージの名前と概要に含まれる用語で一致したものが返されることに注意してください。これにより、検索時間が短縮され、名前が分からないものの、関連用語が分かっているパッケージの検索が可能になります。パッケージの説明に一致する用語を含めるには、以下を使用します。
# yum search --all term
term は、パッケージ名、概要、または説明で検索する用語に置き換えます。
yum search --all
はより完全な検索を可能にしますが、速度が遅くなることに注意してください。
2.3.2. yum を使用したパッケージの一覧表示
インストール済みで利用可能なパッケージの情報をすべて表示するには、次のコマンドを実行します。
# yum list --all
システムにインストールされているパッケージの一覧を表示するには、以下のコマンドを使用します。
# yum list --installed
有効なすべてのリポジトリーで、インストール可能な全パッケージを表示するには、以下を使用します。
# yum list --available
glob 表現を引数として追加して結果をフィルターできることに注意してください。詳細は「yum input での glob 表現の指定」を参照してください。
2.3.3. yum を使用したリポジトリーの一覧表示
システムで有効なリポジトリーをすべて一覧表示するには、以下を使用します。
# yum repolist
システムで無効になっているリポジトリーをすべて一覧を表示するには、以下を使用します。
# yum repolist --disabled
有効および無効なリポジトリーの両方を一覧表示するには、以下を使用します。
# yum repolist --all
リポジトリーに関する追加情報を一覧表示するには、以下を使用します。
# yum repoinfo
リポジトリーの ID または名前を引数として渡すか、glob 表現を追加して結果をフィルタリングでききることに注意してください。詳細は「yum input での glob 表現の指定」を参照してください。
2.3.4. yum でパッケージ情報の表示
パッケージに関する情報を表示するには、以下を使用します。
# yum info package-name
package-name を、パッケージ名に置き換えます。
glob 表現を引数として追加して結果をフィルターできることに注意してください。詳細は「yum input での glob 表現の指定」を参照してください。
2.3.5. yum を使用したパッケージグループの一覧表示
インストール済みおよび利用可能なグループの数を表示するには、以下を使用します。
# yum group summary
インストール済みおよび利用可能なグループをすべて一覧表示するには、以下のコマンドを使用します。
# yum group list
yum group list
コマンドのコマンドラインオプション (--hidden
、--available)
を追加して結果をフィルタリングできます。利用可能なオプションの詳細は、man ページを参照してください。特定のグループに含まれている必須および任意のパッケージを一覧表示するには、次のコマンドを実行します。
# yum group info group-name
group-name は、グループ名に置き換えます。
glob 表現を引数として追加して結果をフィルターできることに注意してください。詳細は「yum input での glob 表現の指定」を参照してください。
2.3.6. yum input での glob 表現の指定
yum
コマンドでは、1 つ以上の glob 表現 を引数として追加することで、結果をフィルタリングできます。glob 表現は、yum
コマンドに引数として指定するとエスケープする必要があります。確実に glob 表現を yum
に渡すには、以下のいずれかの方法で行います。
glob 表現全体を二重引用符または単一引用符でくくる
# yum provides "*/file-name"
file-name は、ファイルの名前に置き換えます。
ワイルドカード文字の前にバックスラッシュ記号 (
\
) を入力して、ワイルドカード文字をエスケープする# yum provides \*/file-name
file-name は、ファイルの名前に置き換えます。
2.4. ソフトウェアパッケージのインストール
以下のセクションでは、yum を使用して以下を行う方法を説明します。
- パッケージをインストールする
- パッケージグループをインストールする
- yum input にパッケージ名を指定する
2.4.1. yum を使用したパッケージのインストール
パッケージとすべてのパッケージ依存関係をインストールするには、以下を使用します。
# yum install package-name
package-name を、パッケージ名に置き換えます。
複数のパッケージとその依存関係を同時にインストールするには、以下を使用します。
# yum install package-name-1 package-name-2
package-name-1 および package-name-2 は、パッケージ名に置き換えます。
multilib システムにパッケージをインストールする場合に (AMD64、Intel 64 マシン)、パッケージのアーキテクチャーをパッケージ名に追加して指定できます。
# yum install package-name.arch
package-name.arch は、パッケージの名前およびアーキテクチャーに置き換えます。
インストールするバイナリー名は分かっているが、パッケージ名が分からない場合は、引数としてバイナリーへのパスを使用できます。
# yum install /usr/sbin/binary-file
/usr/sbin/binary-file
は、バイナリーファイルへのパスに置き換えます。yum はパッケージ一覧で検索を行い、
/usr/sbin/binary-file
を提供するパッケージを探します。パッケージが見つかると、そのパッケージをインストールするかどうかを尋ねられます。ローカルディレクトリーからダウンロード済みのパッケージをインストールするには、以下を使用します。
# yum install /path/
/path/ は、パッケージへのパスに置き換えます。
引数の解析方法を明示的に定義することで、パッケージ検索を最適化できます。詳細は「yum input でのパッケージ名の指定」を参照してください。
2.4.2. yum を使用したパッケージグループのインストール
パッケージグループをグループ名でインストールするには、以下を使用します。
# yum group install group-name
または
# yum install @group-name
group-name は、グループまたは環境グループのフルネームに置き換えます。
groupID でパッケージグループをインストールするには、以下を使用します。
# yum group install groupID
groupID は、グループの ID に置き換えます。
2.4.3. yum input でのパッケージ名の指定
インストールと削除のプロセスを最適化するには、yum install
コマンド、および yum remove
コマンドに -n
、-na
、または -nerva
接尾辞を追加して、引数の分析方法を明示的に定義してください。
正確な名前を使用してパッケージをインストールするには、以下を使用します。
# yum install-n name
name は、パッケージの正確な名前に置き換えます。
正確な名前およびアーキテクチャーを使用してパッケージをインストールするには、以下を使用します。
# yum install-na name.architecture
name および architecture は、パッケージの正確な名前およびアーキテクチャーに置き換えます。
正確な名前、エポック、バージョン、リリース、およびアーキテクチャーを使用してパッケージをインストールするには、以下を使用します。
# yum install-nevra name-epoch:version-release.architecture
name、epoch、version、release、および architecture は、パッケージの正確な名前、エポック、バージョン、リリース、およびアーキテクチャーに置き換えます。
2.5. ソフトウェアパッケージの更新
yum を使用すると、システムに保留中の更新があるかどうかを確認できます。更新が必要なパッケージを一覧表示して、1 つのパッケージ、複数のパッケージ、またはすべてのパッケージを一度に更新できます。更新パッケージに依存関係がある場合は、合わせて更新されます。
以下のセクションでは、yum を使用して以下を行う方法を説明します。
- 更新の有無を確認する
- 1 つのパッケージを更新する
- パッケージグループを更新する
- すべてのパッケージとその依存関係を更新する
- セキュリティー更新を適用する
- ソフトウェアの更新を自動化する
2.5.1. yum を使用した更新の確認
システムにインストールされているパッケージで更新を利用できるのはどれかを確認するには、以下のコマンドを実行します。
# yum check-update
このコマンドは、更新が利用可能なパッケージおよびその依存関係の一覧を表示します。
2.5.2. yum を使用した単一パッケージの更新
パッケージを更新するには、以下を使用します。
# yum update package-name
package-name を、パッケージ名に置き換えます。
カーネルの更新を適用する場合、yum は、yum update
コマンドまたは yum install
コマンドを使用しているかどうかに関わらず、新しいカーネルを常に インストール します。
2.5.3. yum を使用したパッケージグループの更新
パッケージグループを更新するには、以下を使用します。
# yum group update group-name
group-name は、パッケージグループの名前に置き換えます。
2.5.4. yum ですべてのパッケージとその依存関係の更新
すべてのパッケージとその依存関係を更新するには、次のコマンドを実行します。
# yum update
2.5.6. ソフトウェア更新の自動化
パッケージの更新の確認とダウンロードを定期的に行うには、dnf-automatic
パッケージの DNF Automatic ツールを使用できます。
DNF Automatic は、systemd タイマー、cron ジョブ、その他のツールを使用した自動実行および定期実行に適した yum の代替コマンドラインインターフェースです。
DNF Automatic は、必要に応じてパッケージのメタデータを同期し、利用できる更新を確認します。その後、このツールは、設定方法に応じて以下のアクションのいずれかを実行できます。
- 終了
- 更新済みパッケージのダウンロード
- 更新のダウンロードおよび適用
その後、標準出力やメールなど、選択したメカニズムによって操作の結果が報告されます。
2.5.6.1. DNF Automatic のインストール
以下の手順では、DNF Automatic ツールをインストールする方法を説明します。
手順
dnf-automatic
パッケージをインストールするには、次のコマンドを実行します。# yum install dnf-automatic
検証手順
インストールの成功を確認するには、以下のコマンドを実行して
dnf-automatic
パッケージが存在することを確認します。# rpm -qi dnf-automatic
2.5.6.2. dnf Automatic 設定ファイル
デフォルトでは、DNF Automatic は、動作を定義するための設定ファイルとして /etc/dnf/automatic.conf
を使用します。
設定ファイルは、以下のトピックセクションに分かれています。
[commands]
セクションDNF Automatic の操作モードを設定します。
[emitters]
セクションDNF Automatic の結果が報告される方法を定義します。
[command_email]
セクション電子メールの送信に使用する外部コマンドのメールエミッター設定を提供します。
[email]
セクション電子メールエミッターの設定を提供します。
[base]
セクションyum の主な設定ファイルのオプションを上書きします。
/etc/dnf/automatic.conf
のデフォルト設定では、DNF Automatic は、利用可能な更新を自動的にチェックし、ダウンロードして、結果を標準出力として報告します。
[commands]
セクションの操作モードの設定は、dnf-automatic.timer
以外のすべてのタイマーユニットに対して、systemd タイマーユニットで使用される設定によって上書きされます。
関連情報
- 特定のセクションの詳細は、『DNF Automatic ドキュメント』を参照してください。
-
systemd タイマーユニットの詳細は、
man dnf-automatic
で man ページを参照してください。 -
dnf-automatic パッケージ
に含まれる systemd タイマーユニットの概要は、2.5.6.4.「dnf-automatic に含まれる systemd タイマーユニットの概要」 のセクションを参照してください。
2.5.6.3. DNF Automatic の有効化
DNF Automatic を実行するには、常に特定の systemd タイマーユニットを有効にして起動する必要があります。dnf-automatic
パッケージで提供されるタイマーユニットのいずれかを使用するか、必要に応じて独自のタイマーユニットを作成することができます。
以下のセクションでは、DNF Automatic を有効にする方法を説明します。
前提条件
-
/etc/dnf/automatic.conf
設定ファイルを変更して、DNF Automatic の動作を指定している。
DNF Automatic 設定ファイルの詳細は、セクション 2.5.6.2『DNF Automatic 設定ファイル』を参照してください。
手順
ニーズに合った systemd タイマーユニットを選択し、有効にして開始します。
# systemctl enable --now <unit>
ここで、
<unit>
は以下のタイマーのいずれかです。-
dnf-automatic-download.timer
-
dnf-automatic-install.timer
-
dnf-automatic-notifyonly.timer
-
dnf-automatic.timer
-
利用可能な更新の ダウンロード の場合は、次のコマンドを使用します。
# systemctl enable dnf-automatic-download.timer
# systemctl start dnf-automatic-download.timer
利用可能な更新の ダウンロードとインストール の場合は、次のコマンドを使用します。
# systemctl enable dnf-automatic-install.timer
# systemctl start dnf-automatic-install.timer
利用可能な更新の 報告 の場合は、次のコマンドを使用します。
# systemctl enable dnf-automatic-notifyonly.timer
# systemctl start dnf-automatic-notifyonly.timer
必要に応じて、以下を使用できます。
# systemctl enable dnf-automatic.timer
# systemctl start dnf-automatic.timer
更新のダウンロードおよび適用では、このタイマーユニットは /etc/dnf/automatic.conf
設定ファイルの設定に応じて動作します。デフォルトの動作は dnf-automatic-download.timer
に似ています。更新されたパッケージをダウンロードしますが、インストールはしません。
別の方法として、/usr/bin/dnf-automatic
ファイルをコマンドラインまたはカスタムスクリプトから直接実行して、DNF Automatic も実行できます。
検証手順
タイマーが有効になっていることを確認するには、次のコマンドを実行します。
# systemctl status <systemd timer unit>
関連情報
-
dnf-automatic タイマーの詳細は、
man dnf-automatic
の man ページを参照してください。 -
dnf-automatic
パッケージに含まれる systemd タイマーユニットの概要は、 2.5.6.4.「dnf-automatic
に含まれる systemd タイマーユニットの概要」のセクションを参照してください。
2.5.6.4. dnf-automatic パッケージに含まれる systemd タイマーユニットの概要
systemd タイマーユニットが優先され、更新のダウンロードと適用に関する /etc/dnf/automatic.conf
設定ファイルのオプションを上書きします。
たとえば、以下を設定します。
download_updates = yes
/etc/dnf/automatic.conf
設定ファイルでは、dnf-automatic-notifyonly.timer
ユニットをアクティベートしていても、パッケージはダウンロードされません。
dnf-automatic
パッケージには、次の systemd タイマーユニットが含まれます。
タイマーユニット | 機能 | /etc/dnf/automatic.conf ファイルの設定を上書きするか |
---|---|---|
| キャッシュにパッケージをダウンロードし、更新を利用できるようにします。
注記: このタイマーユニットでは更新パッケージはインストールされません。インストールを実行するには、 | はい |
| 更新したパッケージをダウンロードしてインストールします。 | はい |
| リポジトリーデータのみをダウンロードして、リポジトリーキャッシュを最新の状態に維持し、利用可能な更新について通知します。 注記: このタイマーユニットでは、更新されたパッケージはダウンロードまたはインストールされません。 | はい |
|
更新のダウンロードと適用に関するこのタイマーの動作は、
デフォルトの動作は、 | いいえ |
関連情報
-
dnf-automatic
タイマーの詳細は、man dnf-automatic
の man ページを参照してください。 -
/etc/dnf/automatic.conf
設定ファイルの詳細は、セクション 2.5.6.2.「DNF Automatic 設定ファイル」を参照してください。
2.6. ソフトウェアパッケージのアンインストール
以下のセクションでは、yum を使用して以下を行う方法を説明します。
- パッケージを削除する
- パッケージグループを削除する
- yum input にパッケージ名を指定する
2.6.1. yum を使用したパッケージの削除
特定のパッケージおよび依存パッケージをすべて削除するには、以下を使用します。
# yum remove package-name
package-name を、パッケージ名に置き換えます。
複数のパッケージとその依存関係を同時に削除するには、以下を使用します。
# yum remove package-name-1 package-name-2
package-name-1 および package-name-2 は、パッケージ名に置き換えます。
yum では、依存パッケージを削除しなければパッケージを削除できません。
引数の解析方法を明示的に定義することで、パッケージ検索を最適化できます。詳細は「yum input でのパッケージ名の指定」を参照してください。
2.6.2. yum を使用したパッケージグループの削除
グループ名を使用してパッケージグループを削除するには、以下を使用します。
# yum group remove group-name
または
# yum remove @group-name
group-name は、グループの完全な名前に置き換えます。
groupID でパッケージグループを削除するには、以下を使用します。
# yum group remove groupID
groupID は、グループの ID に置き換えます。
2.6.3. yum input でのパッケージ名の指定
インストールと削除のプロセスを最適化するには、yum install
コマンド、および yum remove
コマンドに -n
、-na
、または -nerva
接尾辞を追加して、引数の分析方法を明示的に定義してください。
正確な名前を使用してパッケージをインストールするには、以下を使用します。
# yum install-n name
name は、パッケージの正確な名前に置き換えます。
正確な名前およびアーキテクチャーを使用してパッケージをインストールするには、以下を使用します。
# yum install-na name.architecture
name および architecture は、パッケージの正確な名前およびアーキテクチャーに置き換えます。
正確な名前、エポック、バージョン、リリース、およびアーキテクチャーを使用してパッケージをインストールするには、以下を使用します。
# yum install-nevra name-epoch:version-release.architecture
name、epoch、version、release、および architecture は、パッケージの正確な名前、エポック、バージョン、リリース、およびアーキテクチャーに置き換えます。
2.7. ソフトウェアパッケージグループの管理
パッケージグループは、共通の目的 (システムツール、サウンドとビデオ) でサービスを行うパッケージの集合です。パッケージグループをインストールすると、依存パッケージも取得するため、時間が大幅に短縮できます。
以下のセクションでは、yum を使用して以下を行う方法を説明します。
- パッケージグループを一覧表示する
- パッケージグループをインストールする
- パッケージグループを削除する
- yum input での glob 表現を指定する
2.7.1. yum を使用したパッケージグループの一覧表示
インストール済みおよび利用可能なグループの数を表示するには、以下を使用します。
# yum group summary
インストール済みおよび利用可能なグループをすべて一覧表示するには、以下のコマンドを使用します。
# yum group list
yum group list
コマンドのコマンドラインオプション (--hidden
、--available)
を追加して結果をフィルタリングできます。利用可能なオプションの詳細は、man ページを参照してください。特定のグループに含まれている必須および任意のパッケージを一覧表示するには、次のコマンドを実行します。
# yum group info group-name
group-name は、グループ名に置き換えます。
glob 表現を引数として追加して結果をフィルターできることに注意してください。詳細は「yum input での glob 表現の指定」を参照してください。
2.7.2. yum を使用したパッケージグループのインストール
パッケージグループをグループ名でインストールするには、以下を使用します。
# yum group install group-name
または
# yum install @group-name
group-name は、グループまたは環境グループのフルネームに置き換えます。
groupID でパッケージグループをインストールするには、以下を使用します。
# yum group install groupID
groupID は、グループの ID に置き換えます。
2.7.3. yum を使用したパッケージグループの削除
グループ名を使用してパッケージグループを削除するには、以下を使用します。
# yum group remove group-name
または
# yum remove @group-name
group-name は、グループの完全な名前に置き換えます。
groupID でパッケージグループを削除するには、以下を使用します。
# yum group remove groupID
groupID は、グループの ID に置き換えます。
2.7.4. yum input での glob 表現の指定
yum
コマンドでは、1 つ以上の glob 表現 を引数として追加することで、結果をフィルタリングできます。glob 表現は、yum
コマンドに引数として指定するとエスケープする必要があります。確実に glob 表現を yum
に渡すには、以下のいずれかの方法で行います。
glob 表現全体を二重引用符または単一引用符でくくる
# yum provides "*/file-name"
file-name は、ファイルの名前に置き換えます。
ワイルドカード文字の前にバックスラッシュ記号 (
\
) を入力して、ワイルドカード文字をエスケープする# yum provides \*/file-name
file-name は、ファイルの名前に置き換えます。
2.8. パッケージ管理履歴の処理
yum history
コマンドを使用すると、yum トランザクションのタイムライン、トランザクションの発生日時、影響を受けたパッケージ数、トランザクション成功の有無、RPM データベースがトランザクション間で変更されたかどうかなどに関する情報を確認できます。また、yum history
コマンドを使用してトランザクションを元に戻すか、やり直すこともできます。
以下のセクションでは、yum を使用して以下を行う方法を説明します。
- トランザクションを一覧表示する
- トランザクションを元に戻す
- トランザクションを繰り返す
- yum input での glob 表現を指定する
2.8.1. yum を使用したトランザクションの一覧表示
最新の yum トランザクションの一覧を表示するには、以下を使用します。
# yum history
選択したパッケージの最新操作の一覧を表示するには、以下を使用します。
# yum history list package-name
package-name を、パッケージ名に置き換えます。glob 表現を追加して、コマンドの出力をフィルタリングできます。詳細は「yum input での glob 表現の指定」を参照してください。
特定のトランザクションを調べるには、以下を使用します。
# yum history info transactionID
transactionID は、トランザクションの ID に置き換えます。
2.8.2. yum を使用してトランザクションを元に戻す方法
特定のトランザクションを元に戻すには、以下を使用します。
# yum history undo transactionID
transactionID は、トランザクションの ID に置き換えます。
最後のトランザクションを元に戻すには、以下を使用します。
# yum history undo last
yum history undo
コマンドは、トランザクション中に実行されたステップのみを元に戻すことに注意してください。トランザクションで新しいパッケージをインストールした場合には、yum history undo
コマンドでこのパッケージをアンインストールします。トランザクションでパッケージをアンインストールした場合には、 yum history undo
コマンドによりこのパッケージが再インストールされます。また、yum history undo
では、以前のパッケージがまだ利用可能な場合に、更新されたパッケージをすべて以前のバージョンにダウングレードしようとします。
2.8.3. yum を使用したトランザクションの反復
特定のトランザクションを繰り返すには、以下を使用します。
# yum history redo transactionID
transactionID は、トランザクションの ID に置き換えます。
最後のトランザクションを繰り返すには、以下を使用します。
# yum history redo last
yum history redo
コマンドは、トランザクション中に実行されたステップのみを繰り返すことに注意してください。
2.8.4. yum input での glob 表現の指定
yum
コマンドでは、1 つ以上の glob 表現 を引数として追加することで、結果をフィルタリングできます。glob 表現は、yum
コマンドに引数として指定するとエスケープする必要があります。確実に glob 表現を yum
に渡すには、以下のいずれかの方法で行います。
glob 表現全体を二重引用符または単一引用符でくくる
# yum provides "*/file-name"
file-name は、ファイルの名前に置き換えます。
ワイルドカード文字の前にバックスラッシュ記号 (
\
) を入力して、ワイルドカード文字をエスケープする# yum provides \*/file-name
file-name は、ファイルの名前に置き換えます。
2.9. ソフトウェアリポジトリーの管理
yum および関連ユーティリティーの設定情報は /etc/yum.conf
ファイルに保存されます。このファイルには [repository]
セクションが含まれており、リポジトリー固有のオプションを設定できます。
/etc/yum.repos.d/
ディレクトリーにある、新規または既存の .repo
ファイルに個々のリポジトリーを定義することが推奨されます。
/etc/yum.conf
ファイルの各 [repository]
セクションで定義した値は、[main]
セクションに設定した値をオーバーライドします。
次のセクションでは、以下を行う方法を説明します。
-
[repository]
オプションを設定する - yum リポジトリーを追加する
- yum リポジトリーを有効にする
- yum リポジトリーを無効にする
2.9.1. Yum リポジトリーオプションの設定
/etc/yum.conf
設定ファイルには [repository]
のセクションが含まれ、repository は一意のリポジトリー ID に置き換えます。[repository]
セクションでは、各 yum リポジトリーを定義できます。
競合を回避するために、カスタムリポジトリーには Red Hat リポジトリーで使用される名前を指定しないでください。
利用可能な [repository]
オプションの完全なリストは、man ページの yum.conf(5) の [repository] OPTIONS
セクションを参照してください。
2.9.2. yum リポジトリーの追加
新規リポジトリーを定義するには、以下を行います。
-
[repository]
セクションを/etc/yum.conf
ファイルに追加します。 /etc/yum.repos.d/
ディレクトリーの.repo
ファイルに[repository]
セクションを追加します。yum リポジトリーは、一般的に
.repo
ファイルを提供します。
このディレクトリーにある、.repo
ファイル拡張子が付いたすべてのファイルを yum が読み取るため、リポジトリーは、/etc/yum.conf
ではなく、.repo
ファイルに定義することが推奨されます。
システムにリポジトリーを追加して有効にするには、以下を使用します。
# yum-config-manager --add-repo repository_URL
repository_url は、リポジトリーを参照する URL に置き換えます。
ソフトウェアパッケージを、Red Hat の認証ベース Content Delivery Network
(CDN) 以外の未検証または信頼できないソースから取得してインストールする場合には、セキュリティー上のリスクが伴います。セキュリティー、安定性、互換性、保全性に関する問題につながる恐れがあります。
2.9.3. yum リポジトリーの有効化
リポジトリーを有効にするには、以下を使用します。
# yum-config-manager --enable repositoryID
repositoryID は、一意のリポジトリー ID に置き換えます。
利用可能なリポジトリー ID を一覧表示するには、「yum を使用したパッケージの一覧表示」を参照してください。
2.9.4. yum リポジトリーの無効化
yum リポジトリーを無効にするには、以下のコマンドを使用します。
# yum-config-manager --disable repositoryID
repositoryID は、一意のリポジトリー ID に置き換えます。
利用可能なリポジトリー ID を一覧表示するには、「yum を使用したパッケージの一覧表示」を参照してください。
2.10. yum の設定
yum および関連ユーティリティーの設定情報は /etc/yum.conf
ファイルに保存されます。このファイルには、必須の [main]
セクションが含まれており、このセクションを使用することで yum オプションを設定してグローバルに設定を適用できます。
次のセクションでは、以下を行う方法を説明します。
- 現在の yum 設定を表示します。
- yum [main] オプションを設定します。
- yum プラグインを使用します。
2.10.1. 現在の yum 設定の表示
/etc/yum.conf
ファイルの[main]
セクションで指定されるグローバル yum オプションの現在の値を表示するには、以下を使用します。# yum config-manager --dump
2.10.2. yum メインオプションの設定
/etc/yum.conf
設定ファイルには [main]
セクションが 1 つ含まれています。本セクションの鍵と値のペアにより、yum の動作とリポジトリーの処理方法が変わります。
/etc/yum.conf
の [main]
セクションの下に、オプションを追加できます。
利用可能な [main]
オプションの詳細なリストは、man ページの yum.conf(5) の [main] OPTIONS
セクションを参照してください。
2.10.3. yum プラグインの使用
yum は、その操作を拡張し、強化するプラグインを提供します。特定のプラグインが、デフォルトでインストールされています。
以下のセクションでは、yum プラグインを有効、設定、および無効にする方法を説明します。
2.10.3.1. yum プラグインの管理
プラグイン設定ファイルには常に [main]
セクションが含まれます。このセクションでは、enabled=
オプションで、yum
コマンドを実行する際にプラグインを有効にするかどうかを制御します。このオプションがファイルに含まれていない場合は手動で追加できます。
/etc/dnf/plugins/
ディレクトリーには、インストールしているすべてのプラグインに対する設定ファイルがあります。これらのファイルでは、プラグイン固有のオプションを有効または無効にできます。
2.10.3.2. yum プラグインの有効化
すべての yum プラグインを有効にするには、以下を実行します。
-
plugins=
で始まる行が/etc/yum.conf
ファイルの[main]
セクションにあることを確認します。 plugins=
の値を1
に設定します。plugins=1
-
2.10.3.3. yum プラグインの無効化
yum プラグインをすべて無効にするには、以下を実行します。
-
plugins=
で始まる行が/etc/yum.conf
ファイルの[main]
セクションにあることを確認します。 plugins=
の値を0
に設定します。plugins=0
重要プラグインをすべて無効にすることは推奨 していません。プラグインによっては、重要な yum サービスを提供します。その中でも product-id プラグインおよび subscription-manager プラグインは、証明書ベースの
Content Delivery Network
(CDN) への対応に必要です。システム全体でプラグインを簡単に無効にできますが、通常は yum での潜在的な問題を診断する時に限り使用することを推奨します。
-
特定のコマンドで yum プラグインをすべて無効にするには、
--noplugins
オプションをコマンドに追加します。# yum --noplugins update
1 つのコマンドで特定の yum プラグインを無効にするには、
--disableplugin=plugin-name
オプションをコマンドに追加します。# yum update --disableplugin=plugin-name
plugin-name をプラグインの名前に置き換えます。
第3章 systemd によるサービス管理
3.1. systemd の概要
systemd は、Linux オペレーティングシステム用のシステムおよびサービスのマネージャーです。SysV init スクリプトと後方互換するように設計されており、システム起動時のシステムサービスの並行スタートアップや、デーモンのオンデマンドのアクティベーション、依存関係ベースのサービス制御論理などの多くの機能を提供します。Red Hat Enterprise Linux 7 以降、systemd は、Upstart に代わるデフォルトの init システムです。
systemd は、systemd unit の概念を導入します。このユニットは、次の表に挙げられているディレクトリーのいずれかにあるユニット設定ファイルで示されます。
表3.1 systemd のユニットファイルの場所
ディレクトリー | 説明 |
---|---|
| インストール済みの RPM パッケージで配布された systemd のユニットファイル。 |
| ランタイム時に作成された systemd ユニットファイル。このディレクトリーは、インストール済みのサービスのユニットファイルのディレクトリーよりも優先されます。 |
|
|
ユニットは、次の情報をカプセル化します。
- システムサービス
- ソケットのリッスン
- init システムに関連するその他のオブジェクト
利用可能な systemd のユニットタイプの完全なリストは、次の表を参照してください。
表3.2 利用可能な systemd のユニットタイプ
ユニットのタイプ | ファイルの拡張子 | 説明 |
---|---|---|
サービスユニット |
| システムサービス |
ターゲットユニット |
| systemd ユニットのグループ |
自動マウントユニット |
| ファイルシステムの自動マウントポイント |
デバイスユニット |
| カーネルが認識するデバイスファイル |
マウントユニット |
| ファイルシステムのマウントポイント |
パスユニット |
| ファイルシステム内のファイルまたはディレクトリー |
スコープユニット |
| 外部作成のプロセス |
スライスユニット |
| システムプロセスを管理する、階層的に構成されたユニットのグループ |
ソケットユニット |
| プロセス間の通信ソケット |
スワップユニット |
| スワップデバイスまたはスワップファイル |
タイマーユニット |
| systemd タイマー |
system.conf を使用してデフォルトの systemd 設定の上書き
systemd のデフォルト設定はコンパイル中に定義され、/etc/systemd/system.conf
にある systemd 設定ファイルで確認できます。ここに記載されるデフォルトではなく、systemd ユニットでグローバルに選択したデフォルト値を上書きする場合は、このファイルを使用します。
たとえば、タイムアウト制限のデフォルト値 (90 秒) を上書きする場合は、DefaultTimeoutStartSec
パラメータを使用して、上書きする値を秒単位で入力します。
DefaultTimeoutStartSec=required value
詳細は例3.11「タイムアウト制限の変更」を参照してください。
3.1.1. 主な特長
systemd システムおよびサービスマネージャーの主な機能は、以下のようになります。
ソケットベースのアクティベーション - システムの起動時に、systemd は、このタイプのアクティベーションに対応するすべてのシステムサービスに対してリスニングソケットを作成し、サービスが開始するとすぐにこのソケットをサービスに渡します。これで systemd がサービスを同時に開始できるだけでなく、サービスが利用できない時に送信されたメッセージを失うことなくサービスの再起動が可能になります。 これは、対応するソケットがアクセス可能なままで、すべてのメッセージがキューに登録されるためです。
systemd は、ソケットベースの有効化に ソケットユニット を使用します。
- バスベースのアクティベーション - プロセス間の通信に D-Bus を使用するシステムサービスは、クライアントアプリケーションがシステムサービスとの通信を初めて試みる時にオンデマンドで開始します。systemd は、バスベースのアクティベーションに D-Bus サービスファイル を使用します。
- デバイスベースのアクティベーション - デバイスベースのアクティベーションをサポートするシステムサービスは、特定のタイプのハードウェアがプラグインするか利用可能になると、オンデマンドで開始できます。Systemd は、デバイスベースのアクティベーションに、デバイスユニット を使用します。
- パスベースのアクティベーション - パスベースのアクティベーションをサポートするシステムサービスは、特定のファイルまたはディレクトリーのステータスが変更になると、オンデマンドで開始できます。Systemd は、パスベースのアクティベーションに パスユニット を使用します。
- マウントおよび自動マウントポイント管理 - systemd は、マウントポイントおよび自動マウントポイントを監視および管理します。systemd は、マウントポイントに マウントユニット を使用し、自動マウントポイントに 自動マウントユニット を使用します。
- アグレッシブな並列化 - ソケットベースのアクティベーションを使用するため、systemd はすべてのリスニングソケットが配置されるとすぐに、システムサービスを同時に開始できます。並列アクティベーションは、オンデマンドのアクティベーションをサポートするシステムサービスと組み合わせることで、システムの起動に必要な時間を大幅に短縮します。
- トランザクション性のあるユニットのアクティベーション論理 - ユニットをアクティブまたは非アクティブにする前に、systemd はその依存関係を計算して、一時的なトランザクションを作成し、このトランザクションの一貫性を検証します。トランザクションに一貫性がない場合、systemd は自動的にこれを正そうとし、エラーをレポートする前に必須ではないジョブを削除しようと試みます。
- SysV init との後方互換性 - Linux Standard Base Core Specification にあるように、systemd は SysV init スクリプトに対応しています。これにより、systemd サービスのユニットへのアップグレードが容易になります。
3.1.2. 互換性の変更点
systemd システムおよびサービスマネージャーは、その大部分が SysV init および Upstart と互換性があるように設計されています。以下では、SysV init を使用していた Red Hat Enterprise Linux 6 システムと比較して、互換性について最も重要な変更点を挙げています。
-
systemd のランレベルのサポートは限定的なものです。ランレベルに直接マッピング可能なターゲットユニットを数多く提供し、互換性のために以前の
runlevel
コマンドで配布されます。ただし、systemd ターゲットのすべてがランレベルに直接マッピングできるわけではないため、このコマンドが不明なランレベルを示すN
を返す場合もあります。可能な場合は、runlevel
コマンドの使用を避けることが推奨されます。
systemd ターゲットの詳細と、ランレベルとの比較は「systemd ターゲットでの作業」を参照してください。 systemctl
ユーティリティーは、カスタマイズされたコマンドをサポートしません。SysV init スクリプトでは、start
、stop
、status
といった標準のコマンドのほかに、任意のコマンドを実装して多くの機能を提供できます。たとえば、iptables
の init スクリプトは、panic
コマンドで実行できます。これにより、パニックモードが即座に有効になり、システムを再設定して受信パケットおよび送信パケットをすべて切断します。これは systemd ではサポートされておらず、systemctl
は文書化されたコマンドのみ受け付けます。systemctl
ユーティリティー、および以前のservice
ユーティリティーとの比較は、表3.3「service ユーティリティーと systemctl の比較」 を参照してください。-
systemctl
ユーティリティーは、systemd が開始していないサービスとは通信しません。systemd がシステムサービスを開始すると、メインプロセスの ID を保存して、メインプロセスを追跡します。すると、systemctl
ユーティリティーがこの PID を使用してクエリーを行い、サービスを管理します。このため、ユーザーがコマンドラインで特定のデーモンを直接開始すると、systemctl
がそのデーモンの最新の状態を判断したり、停止したりすることができません。 -
systemd が停止するのは、実行中のサービスのみです。Red Hat Enterprise Linux 6 以前のリリースでは、シャットダウンシーケンスが開始すると、
/etc/rc0.d/
ディレクトリーにあるシンボリックリンクを使用して、利用可能なシステムサービスをそのステータスに関係なくすべて停止していました。systemd では、実行中のサービスだけを、シャットダウン時に停止します。 -
システムサービスは、標準の入力ストリームからは読み取れません。systemd がサービスを開始すると、標準入力を
/dev/null
に接続し、ユーザーとの対話を行わないようにします。 -
システムサービスは、呼び出したユーザーやそのセッションから、(環境変数
HOME
、PATH
などの) コンテキストを継承しません。各サービスは、クリーンな実行コンテキストで実行します。 - SysV init スクリプトを読み込む際に、systemd は Linux Standard Base (LSB) ヘッダーにエンコードされている依存関係情報を読み取り、ランタイム時に解釈します。
- サービスユニット上のすべての操作は、デフォルトで 5 分でタイムアウトになるように設定されており、サービスの故障でシステムがフリーズすることを防ぎます。この値は initscript から生成されるサービス用にハードコーディングされ、変更することができません。ただし、個別の設定ファイルを使用して、サービスごとにタイムアウト値を長くすることができます。例3.11「タイムアウト制限の変更」を参照してください。
systemd で導入された互換性の変更点に関する詳細なリストは、Red Hat Enterprise Linux 7 の『移行計画ガイド』を参照してください。
3.2. システムサービスの管理
以前のバージョンの Red Hat Enterprise Linux は、SysV init または Upstart で配布されており、/etc/rc.d/init.d/
ディレクトリーにある init スクリプト を使用していました。この init スクリプトは通常の Bash で書かれており、システム管理者がシステム内で、サービスの状態とデーモンを管理できるようになっていました。Red Hat Enterprise Linux 7 では、この init スクリプトは、サービスユニット に代わっています。
サービスユニットは、ファイル拡張子 .service
で終わり、init スクリプトと同様の役割を担います。システムサービスの表示、開始、停止、再開、有効化、または無効化には、「service ユーティリティーと systemctl の比較」、「chkconfig ユーティリティーと systemctl の比較」、および本セクションで説明されているように、systemctl
コマンドを使用します。service
コマンドおよび chkconfig
コマンドは、引き続きシステムで利用可能になっており、期待通りに機能しますが、これらは互換性のために含まれており、使用は推奨されていません。
表3.3 service ユーティリティーと systemctl の比較
service | systemctl | 説明 |
---|---|---|
|
| サービスを起動します。 |
|
| サービスを停止します。 |
|
| サービスを再起動します。 |
|
| サービスが実行中の場合のみ、再起動します。 |
|
| 設定を再読み込みします。 |
|
| サービスが実行中かどうかをチェックします。 |
|
| すべてのサービスのステータスを表示します。 |
表3.4 chkconfig ユーティリティーと systemctl の比較
chkconfig | systemctl | 説明 |
---|---|---|
|
| サービスを有効にします。 |
|
| サービスを無効にします。 |
|
| サービスが有効かどうかを確認します。 |
|
| サービスを一覧表示し、各サービスが有効かどうかを確認します。 |
|
| 指定されたユニットの前に開始するように指定されているサービスを一覧表示します。 |
|
| 指定されたユニットの後に開始するように指定されているサービスを一覧表示します。 |
サービスユニットの指定
分かりやすくするため、本セクションの残りの部分のコマンド例では、.service
ファイル拡張子がついた完全なユニット名を使用します。以下に例を示します。
# systemctl stop nfs-server.service
ただし、ファイル拡張子は省略することができます。省略すると、systemctl
は、引数がサービスユニットであることを想定します。以下のコマンドは、上記のコマンドと同等のものになります。
# systemctl stop nfs-server
また、ユニットによってはエイリアス名を持つものもあります。この名前は、ユニット名よりも短くすることができ、ユニット名の代わりとして使用できます。特定のユニットに使用できるエイリアスを見つけるには、以下のコマンドを実行します。
# systemctl show nfs-server.service -p Names
chroot 環境における systemctl の挙動
chroot
コマンドを使用して root ディレクトリーを変更すると、ほとんどの systemctl
コマンドは、アクションの実行をすべて拒否します。なぜなら、systemd
プロセスと、chroot
コマンドを使用しているユーザーでは、ファイルシステムの見え方が異なるからです。このような状況は、systemctl
が キックスタート
ファイルから呼び出されたときなどに発生します。
例外が、systemctl enable
や systemctl disable
などのユニットファイルコマンドです。このコマンドは、実行中のシステムを必要とせず実行中のプロセスに影響を与えませんが、ユニットファイルには影響を及ぼします。したがってこのようなコマンドは、chroot
環境であっても実行することが可能です。たとえば、/srv/website1/
ディレクトリー配下で、システムの httpd
サービスを有効にするときは、以下のコマンドを実行します。
# chroot /srv/website1 # systemctl enable httpd.service Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service.
3.2.1. サービスの一覧表示
読み込み済みのサービスユニットの一覧を表示するには、シェルプロンプトで以下を実行します。
systemctl list-units --type service
各サービスのユニットファイルに対して、このコマンドは正式名 (UNIT
) の後に、そのユニットファイルが読み込まれているかどうか (LOAD
)、そのユニットファイルアクティベーションの状態の概要 (ACTIVE
) および詳細 (SUB
) な状態、そして簡単な説明 (DESCRIPTION
) を示します。
デフォルトでは、systemctl list-units
コマンドは、アクティブなユニットのみを表示します。状態に関係なく読み込み済みユニットをすべて表示する場合は、コマンドラインオプションの --all
または -a
を付けて、以下のコマンドを実行します。
systemctl list-units --type service --all
また、利用可能なサービスユニットを一覧表示して、各ユニットが有効かどうかを確認できます。これには、以下のコマンドを実行します。
systemctl list-unit-files --type service
このコマンドにより、各サービスユニットの完全な名前 (UNIT FILE
) と、サービスユニットが有効かどうか (STATE
) が表示されます。個別のサービスユニットの状態を判断する方法は「サービスステータスの表示」を参照してください。
例3.1 サービスの一覧表示
読み込み済みのサービスユニットの一覧を表示するには、以下のコマンドを実行します。
$ systemctl list-units --type service
UNIT LOAD ACTIVE SUB DESCRIPTION
abrt-ccpp.service loaded active exited Install ABRT coredump hook
abrt-oops.service loaded active running ABRT kernel log watcher
abrt-vmcore.service loaded active exited Harvest vmcores for ABRT
abrt-xorg.service loaded active running ABRT Xorg log watcher
abrtd.service loaded active running ABRT Automated Bug Reporting Tool
…
systemd-vconsole-setup.service loaded active exited Setup Virtual Console
tog-pegasus.service loaded active running OpenPegasus CIM Server
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'
インストール済みのサービスユニットファイルを一覧表示して、そのユニットが有効かどうかを判断するには、以下コマンドを実行します。
$ systemctl list-unit-files --type service UNIT FILE STATE abrt-ccpp.service enabled abrt-oops.service enabled abrt-vmcore.service enabled abrt-xorg.service enabled abrtd.service enabled … wpa_supplicant.service disabled ypbind.service disabled 208 unit files listed.
3.2.2. サービスステータスの表示
システムサービスに対応するサービスユニットに関する詳細情報を表示するには、シェルプロンプトで以下を実行します。
systemctl status name
.service
name を、確認するサービスユニット名 (gdm
など) に置き換えます。このコマンドでは、選択したサービスユニット名の後に、簡単な説明と、表3.5「利用可能なサービスユニットの情報」 にある 1 つ以上のフィールド、さらに root
ユーザーが実行している場合は最新のログエントリーが表示されます。
表3.5 利用可能なサービスユニットの情報
フィールド | 説明 |
---|---|
| サービスユニットが読み込まれているかどうか、ユニットファイルへの絶対パス、ユニットが有効かどうかについての説明 |
| サービスユニットが実行中かどうかの説明と、タイムスタンプ |
| 対応するシステムサービスの PID と、その名前 |
| 対応するシステムサービスに関する追加情報 |
| 関連プロセスに関する追加情報 |
| 関連するコントロールグループ (cgroup) に関する追加情報 |
特定のサービスユニットが実行中かどうかだけを確認する場合は、以下のコマンドを実行します。
systemctl is-active name
.service
同様に、特定のサービスユニットが有効かどうかを確認するには、以下のコマンドを実行します。
systemctl is-enabled name
.service
systemctl is-active
および systemctl is-enabled
は両方とも、指定したサービスユニットが実行中または有効な場合に、終了ステータス 0
を返すことに注意してください。現在読み込み済みのサービスユニットの一覧を表示する方法は、「サービスの一覧表示」を参照してください。
例3.2 サービスステータスの表示
GNOME Display Manager のサービスユニット名は gdm.service
になります。このサービスユニットの現在のステータスを確認するには、シェルプロンプトで次のコマンドを実行します。
# systemctl status gdm.service gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled) Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago Main PID: 1029 (gdm) CGroup: /system.slice/gdm.service ├─1029 /usr/sbin/gdm ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno… └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r… Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.
例3.3 サービスの前に開始するサービスの表示
特定のサービスの前に開始するサービスを確認するには、シェルプロンプトで次のコマンドを実行します。
# systemctl list-dependencies --after gdm.service gdm.service ├─dbus.socket ├─getty@tty1.service ├─livesys.service ├─plymouth-quit.service ├─system.slice ├─systemd-journald.socket ├─systemd-user-sessions.service └─basic.target [output truncated]
例3.4 サービスの後に開始するサービスの表示
特定のサービスの後に開始するサービスを確認するには、シェルプロンプトで次のコマンドを実行します。
# systemctl list-dependencies --before gdm.service gdm.service ├─dracut-shutdown.service ├─graphical.target │ ├─systemd-readahead-done.service │ ├─systemd-readahead-done.timer │ └─systemd-update-utmp-runlevel.service └─shutdown.target ├─systemd-reboot.service └─final.target └─systemd-reboot.service
3.2.3. サービスの起動
システムサービスに対応するサービスユニットを開始する場合は、root
で次のコマンドを実行します。
systemctl start name
.service
name を、開始するサービスユニット名 (たとえば、gdm
) に置き換えます。このコマンドは、選択したサービスを現行セッションで開始します。システムの起動時にサービスユニットを開始するように設定する方法は「サービスの有効化」を参照してください。特定のサービスユニットのステータスを確認する方法は「サービスステータスの表示」を参照してください。
例3.5 サービスの起動
Apache HTTP サーバー用のサービスユニットは httpd.service
です。サービスユニットをアクティブにし、現行セッションで httpd
デーモンを起動するには、root
で以下のコマンドを実行します。
# systemctl start httpd.service
3.2.4. サービスの停止
システムサービスに対応するサービスユニットを停止するには、root
で次のコマンドを実行します。
systemctl stop name
.service
name を、停止するサービスユニット名 (たとえば bluetooth
) に置き換えます。このコマンドは、選択したサービスユニットを現行セッションで停止します。システムの起動時にサービスユニットを無効にし、開始しないようにする方法は、「サービスの無効化」を参照してください。特定のサービスユニットのステータスを確認する方法は「サービスステータスの表示」を参照してください。
例3.6 サービスの停止
bluetoothd
デーモンのサービスユニットは bluetooth.service
です。サービスユニットを無効にし、現行セッションで bluetoothd
デーモンを停止する場合は、root
で以下のコマンドを実行します。
# systemctl stop bluetooth.service
3.2.5. サービスの再開
システムサービスに対応するサービスユニットを再開する場合は、root
で次のコマンドを実行します。
systemctl restart name
.service
name を、再開するサービスユニット名 (たとえば、httpd
) に置き換えます。このコマンドは、現行セッションで選択したサービスユニットを停止し、即座に再起動します。重要なのは、選択したサービスユニットが実行中でないと、このコマンドがそのサービスユニットを起動するということです。対応するサービスがすでに実行中の場合にのみ、サービスユニットを再起動するように systemd に設定するには、root
で以下のコマンドを実行します。
systemctl try-restart name
.service
システムサービスによっては、サービスの実行を中断することなく設定の再読み込みが可能です。これを実行するには、root
で次のコマンドを実行します。
systemctl reload name
.service
システムサービスがこの機能をサポートしない場合は、このコマンドが無視されることに注意してください。代わりに、systemctl
コマンドでは、この機能をサポートしないサービスを代わりに再起動する reload-or-restart
コマンドおよび reload-or-try-restart
コマンドもサポートします。特定のサービスユニットのステータスを確認する方法は「サービスステータスの表示」を参照してください。
例3.7 サービスの再開
ユーザーが不要なエラーメッセージや、部分的に表示される Web ページに遭遇しないようにするため、Apache HTTP Server では設定を再起動したり、処理されたリクエストをアクティブに妨害したりせずに、設定を編集したり再読み込みしたりできます。これを行うには、root
で次のコマンドを実行します。
# systemctl reload httpd.service
3.2.6. サービスの有効化
システムの起動時にシステムサービスに対応するサービスユニットを自動的に起動するように設定するには、root
で次のコマンドを実行します。
systemctl enable name
.service
name を、有効にするサービスユニット名 (httpd
など) に置き換えます。このコマンドは、選択したサービスユニットの [Install]
セクションを読み取り、/etc/systemd/system/
ディレクトリーおよびそのサブディレクトリーにある /usr/lib/systemd/system/name.service
ファイルへの適切なシンボリックリンクを作成します。ただし、このコマンドは既存のリンクを上書きしません。シンボリックリンクが確実に再作成されるようにするには、root
で以下のコマンドを実行します。
systemctl reenable name
.service
このコマンドは、選択したサービスユニットを無効にし、即座に再度有効にします。特定のサービスユニットが有効になっていて、システムの起動時に開始するようになっているかどうかを確認する方法は「サービスステータスの表示」を参照してください。現行セッションでサービスを開始する方法は「サービスの起動」を参照してください。
例3.8 サービスの有効化
システムの起動時に Apache HTTP Server が自動的に開始するように設定するには、root
で以下のコマンドを実行します。
# systemctl enable httpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
3.2.7. サービスの無効化
システムの起動時に、システムサービスに対応するサービスユニットを自動的に起動しないように設定するには、root
で次のコマンドを実行します。
systemctl disable name
.service
name を、無効にするサービスユニット名 (bluetooth
など) に置き換えます。このコマンドは、選択したサービスユニットの [Install]
セクションを読み取り、/etc/systemd/system/
ディレクトリーおよびそのサブディレクトリーから、/usr/lib/systemd/system/name.service
ファイルへの適切なシンボリックリンクを削除します。さらに、サービスユニットにマスクをして、手動で開始したり、別のサービスがこれを開始することを防いだりできます。これを行うには、root
で以下のコマンドを実行します。
systemctl mask name
.service
このコマンドにより、/etc/systemd/system/name.service
ファイルを、/dev/null
へのシンボリックリンクに置き換え、実際のユニットファイルが systemd ファイルにアクセスできないようにします。この動作を元に戻してサービスユニットのマスクを解除するには、root
で以下のコマンドを実行します。
systemctl unmask name
.service
特定のサービスユニットが有効になっていて、システムの起動時に開始するようになっているかどうかを確認する方法は「サービスステータスの表示」を参照してください。現行セッションでサービスを停止する方法は、「サービスの停止」を参照してください。
例3.9 サービスの無効化
例3.6「サービスの停止」 では、現行セッションで bluetooth.service
ユニットを停止する方法を説明しました。システムの起動時にこのサービスユニットが開始しないようにするには、root
で次のコマンドを実行します。
# systemctl disable bluetooth.service Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service. Removed symlink /etc/systemd/system/dbus-org.bluez.service.
3.2.8. 競合するサービスの起動
systemd では、サービスとサービスとの間に正と負の依存関係が存在します。特定のサービスを起動するとき、別のサービスを 1 つまたは複数開始 (正の依存関係)、あるいはサービスを 1 つまたは複数停止 (負の依存関係) することが必要となる場合があります。
ユーザーが新しいサービスを起動しようとすると、systemd がすべての依存関係を自動的に解決します。これは、ユーザーに明示的に通知されることなく実行されるため注意が必要です。サービスが実行されているときに、負の依存関係を持つ別のサービスを起動しようとすると、実行しているサービスが自動的に停止します。
たとえば、postfix
サービスを実行している時に sendmail
サービスを起動すると、systemd は、自動的に postfix
を停止します。 この 2 つのサービスは競合するため、同じポートでは実行できません。
3.3. systemd ターゲットでの作業
systemd ターゲットはターゲットユニットで表現されます。ターゲットユニットファイルは .target
ファイル拡張子で終わり、その唯一の目的は依存関係の連鎖で他の systemd ユニットをグループ化することです。たとえば、グラフィカルセッションの開始に使用する graphical.target unit
ユニットは、GNOME Display Manager ((gdm.service)
) または Accounts Service (accounts-daemon.service)
といったシステムサービスを開始するとともに、multi-user.target unit
ユニットもアクティブにします。同様に、multi-user.target ユニットは、NetworkManager (NetworkManager.service)
、D-Bus (dbus.service)
といった、その他の必須システムサービスを開始し、basic.target という別のターゲットユニットをアクティブにします。
本セクションでは、systemd
ターゲットでの作業中に実装する手順を説明します。
3.3.1. SysV ランレベルと systemd ターゲットの違い
以前のバージョンの Red Hat Enterprise Linux は、SysV init または Upstart で配布されており、特定モードのオペレーションを表す事前定義のランレベルを実装していました。このランレベルは 0 から 6 までの数字で表され、システム管理者が各ランレベルを有効にしたときに実行するシステムサービスが定義されていました。Red Hat Enterprise Linux 7 では、ランレベルの概念が systemd ターゲットに代わっています。
Red Hat Enterprise Linux 7 では、以前のシステムリリースの標準ランレベルと類似する定義済みターゲットが多数同梱されています。互換性の理由から、このようなターゲットのエイリアスも SysV ランレベルに直接マッピングします。
以下の表では、SysV ランレベルとそれに対応する systemd ターゲットの完全リストを提供します。
表3.6 SysV ランレベルと systemd ターゲットの比較
ランレベル | ターゲットユニット | 説明 |
---|---|---|
|
| システムをシャットダウンし、電源を切ります。 |
|
| レスキューシェルを設定します。 |
|
| 非グラフィカルなマルチユーザーシステムを設定します。 |
|
| 非グラフィカルなマルチユーザーシステムを設定します。 |
|
| 非グラフィカルなマルチユーザーシステムを設定します。 |
|
| グラフィカルなマルチユーザーシステムを設定します。 |
|
| システムをシャットダウンして再起動します。 |
以下の表は、SysV init コマンドを systemctl と比較しています。systemctl ユーティリティーを使用して、systemd ターゲットを表示、変更、または設定します。
runlevel
コマンドおよび telinit
コマンドは今も利用でき、期待どおりに機能しますが、このコマンドは互換性のために同梱されているため、なるべく使用しないでください。
表3.7 SysV init コマンドと systemctl の比較
古いコマンド | 新しいコマンド | 説明 |
---|---|---|
|
| 現在読み込まれているターゲットユニットを一覧表示します。 |
|
| 現在のターゲットを変更します。 |
関連情報
- man sysv init
- man upstart init
- man systemctl
3.3.2. デフォルトターゲットの表示
デフォルトのターゲットユニットは /etc/systemd/system/default.target
ファイルで表されます。
手順
デフォルトでどのターゲットユニットが使用されるかを判断するには、次のコマンドを実行します。
$ systemctl get-default graphical.target
シンボリックリンクを使用してデフォルトのターゲットを確認するには、次のコマンドを実行します。
$ ls -l /lib/systemd/system/default.target
3.3.3. ターゲットユニットの表示
デフォルトでは、systemctl list-units
コマンドは、アクティブなユニットのみを表示します。
手順
状態に関係なく読み込み済みユニットをすべて表示するには、以下のコマンドを実行します。
$ systemctl list-units --type target --all
現在読み込み済みのターゲットユニットの一覧を表示するには、以下のコマンドを実行します。
$ systemctl list-units --type target UNIT LOAD ACTIVE SUB DESCRIPTION basic.target loaded active active Basic System cryptsetup.target loaded active active Encrypted Volumes getty.target loaded active active Login Prompts graphical.target loaded active active Graphical Interface local-fs-pre.target loaded active active Local File Systems (Pre) local-fs.target loaded active active Local File Systems multi-user.target loaded active active Multi-User System network.target loaded active active Network paths.target loaded active active Paths remote-fs.target loaded active active Remote File Systems sockets.target loaded active active Sockets sound.target loaded active active Sound Card spice-vdagentd.target loaded active active Agent daemon for Spice guests swap.target loaded active active Swap sysinit.target loaded active active System Initialization time-sync.target loaded active active System Time Synchronized timers.target loaded active active Timers LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 17 loaded units listed.
3.3.4. デフォルトターゲットの変更
デフォルトのターゲットユニットは /etc/systemd/system/default.target
ファイルで表されます。以下の手順では、systemctl コマンドを使用して、デフォルトのターゲットを変更する方法を説明します。
手順
デフォルトのターゲットユニットを確認するには、次のコマンドを実行します。
# systemctl get-default
デフォルトで異なるターゲットユニットを使用するようにシステムを設定するには、次のコマンドを実行します。
# systemctl set-default multi-user.target rm /etc/systemd/system/default.target ln -s /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target
このコマンドにより、
/etc/systemd/system/default.target
ファイルが、/usr/lib/systemd/system/name.target
へのシンボリックリンクに置き換わります。name は、使用するターゲットユニットの名前になります。multi-user を、デフォルトで使用するターゲットユニット名に置き換えます。再起動します。
# reboot
3.3.5. シンボリックリンクを使用したデフォルトのターゲットの変更
以下の手順では、ターゲットへのシンボリックリンクを作成して、デフォルトのターゲットを変更する方法を説明します。
手順
デフォルトのターゲットユニットを確認するには、次のコマンドを実行します。
# ls /lib/systemd/system/default.target -l
シンボリックリンクを作成するには、以下を行います。
# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
システムを再起動します。
# reboot
検証手順
新規作成された default.target を確認します。
$ systemctl get-default multi-user.target
3.3.6. 現在のターゲットの変更
この手順では、systemctl コマンドを使用して、現行セッションでターゲットユニットを変更する方法を説明します。
手順
現行セッションで異なるターゲットユニットに変更するには、次のコマンドを実行します。
# systemctl isolate multi-user.target
このコマンドは、multi-user という名前のターゲットユニットと、その従属ユニットをすべて起動し、その他のユニットを直ちに停止します。
multi-user を、デフォルトで使用するターゲットユニット名に置き換えます。
検証手順
新規作成された default.target を確認します。
$ systemctl get-default multi-user.target
3.3.7. レスキューモードでの起動
レスキューモード は、便利なシングルユーザー環境を提供し、通常の起動プロセスを完了できない状況でのシステムの修復を可能にします。レスキューモードでは、システムはすべてのローカルファイルシステムのマウントと、いくつかの重要なシステムサービスの開始を試みますが、ネットワークインターフェースをアクティブにしたり、他のユーザーによるシステムへの同時ログインを許可したりすることはしません。
手順
現在のターゲットを変更し、現行セッションでレスキューモードに入るには、以下を実行します。
# systemctl rescue Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST): The system is going down to rescue mode NOW!
このコマンドは
systemctl isolate rescue.target
と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。systemd
がメッセージを送信しないようにするには、コマンドラインオプション--no-wall
を付けて# systemctl --no-wall rescue
を実行します。
3.3.8. 緊急モードでのブート
緊急モード は、可能な限り最小限の環境を提供し、レスキューモードに入れないシステム状態でのシステムの修復を可能にします。緊急モードでは、システムは root ファイルシステムを読み込み専用でマウントし、他のローカルファイルシステムのマウントは試みません。また、ネットワークインターフェースのアクティブ化も行わず、限定的な必須サービスのみを起動します。
手順
現在のターゲットを変更し、緊急モードに入るには、次のコマンドを実行します。
# systemctl emergency
このコマンドは systemctl isolate emergency.target
と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。
systemd がメッセージを送信しないようにするには、--no-wall
コマンドラインオプションを付けて # systemctl --no-wall emergency
を実行します。
3.4. システムのシャットダウン、サスペンド、および休止状態
Red Hat Enterprise Linux 7 では、systemctl
ユーティリティーが、これまでのバージョンの Red Hat Enterprise Linux システムで使用されていた多くの電源管理コマンドに置き換わっています。表3.8「電源管理コマンドと systemctl の比較」 に表示されているコマンドは、互換性の理由から現在も利用することができますが、可能な場合は systemctl
の使用が推奨されます。
表3.8 電源管理コマンドと systemctl の比較
古いコマンド | 新しいコマンド | 説明 |
---|---|---|
|
| システムを停止します。 |
|
| システムの電源を切ります。 |
|
| システムを再起動します。 |
|
| システムをサスペンドします。 |
|
| システムを休止状態にします。 |
|
| システムを休止状態にしてサスペンドします。 |
3.4.1. システムのシャットダウン
systemctl
ユーティリティーは、システムをシャットダウンするコマンドを提供します。ただし、従来の shutdown
コマンドもサポートされます。shutdown
コマンドは、systemctl
ユーティリティーを呼び出してシャットダウンを実行しますが、time 引数もサポートするという利点があります。これは、計画メンテナンスにとりわけ役立ち、システムシャットダウンの予定に関する警告にユーザーが対応する時間をより長く確保できます。シャットダウンをキャンセルするオプションがあることも利点です。
systemctl コマンドの使用
システムをシャットダウンし、マシンの電源を切るには、root
で次のコマンドを実行します。
systemctl poweroff
マシンの電源を切らずにシステムをシャットダウンして停止するには、root
で以下のコマンドを実行します。
systemctl halt
デフォルトでは、このコマンドのいずれかを実行すると、systemd が、システムに現在ログインしたすべてのユーザーに情報メッセージを送信します。systemd がメッセージを送信しないようにするには、たとえば、コマンドラインオプション --no-wall
を付けてコマンドを実行します。
systemctl --no-wall poweroff
shutdown コマンドの使用
指定した時間にシステムをシャットダウンしてマシンの電源を切るには、root
で、以下の形式でコマンドを実行します。
shutdown --poweroff hh:mm
hh:mm は 24 時間形式の時刻となります。新たなログインを防ぐために、システムをシャットダウンする 5 分前に /run/nologin
ファイルが作成されます。時間引数を使用する場合は、コマンドに任意のメッセージ wall message を付けることができます。
マシンの電源を切らずに、少し待ってシステムをシャットダウンして停止するには、root
で以下の形式のコマンドを実行します。
shutdown --halt +m
+m は遅らせる時間 (分) です。キーワード now
は、+0
のエイリアスとなります。
保留中のシャットダウンは、root
で以下のコマンドを実行するとキャンセルできます。
shutdown -c
詳細なコマンドオプションは、man ページの shutdown(8)
を参照してください。
3.4.2. システムの再起動
システムを再起動するには、root
で以下のコマンドを実行します。
systemctl reboot
デフォルトでは、このコマンドにより、systemd が、システムに現在ログインしたすべてのユーザーに情報メッセージを送信します。systemd がこのメッセージを送信しないようにするには、コマンドラインオプション --no-wall
を付けてこのコマンドを実行します。
systemctl --no-wall reboot
3.4.3. システムのサスペンド
システムをサスペンドするには、root
で次のコマンドを実行します。
systemctl suspend
このコマンドは、システムの状態を RAM に保存し、マシンにある、RAM モジュール以外のほとんどのデバイスの電源を切ります。マシンの電源を戻すと、システムは再起動せずに RAM からその状態を復元します。システムの状態がハードディスクではなく RAM に保存されるので、システムのサスペンドモードから復元する場合は、休止状態からの復元と比べて著しく速くなります。ただし、システムをサスペンドした状態は、停電に対して脆弱となります。
システムを休止状態にする方法は「システムの休止状態」を参照してください。
3.4.4. システムの休止状態
システムを休止状態にするには、root
で次のコマンドを実行します。
systemctl hibernate
このコマンドは、システムの状態をハードディスクドライブに保存し、マシンの電源を切ります。マシンの電源を戻すと、システムは再起動せずに、保存されたデータからその状態を復元します。システムの状態が RAM ではなくハードディスクに保存されるため、マシンが RAM モジュールに電力を維持する必要がありません。ただし、システムの休止状態から復元する場合は、サスペンドモードからの復元と比べて大幅に遅くなります。
システムを休止状態にしてサスペンドするには、root
で次のコマンドを実行します。
systemctl hybrid-sleep
システムをサスペンドする方法は「システムのサスペンド」を参照してください。
3.5. systemd ユニットファイルでの作業
本章では、systemd ユニットファイルに関する説明が含まれています。以下のセクションでは、次の方法を紹介します。
- カスタムユニットファイルの作成
- SysV Init スクリプトのユニットファイルへの変換
- 既存のユニットファイルの変更
- インスタンス化されたユニットの使用
3.5.1. ユニットファイルの概要
ユニットファイルには、ユニットを説明し、その動作を定義する設定ディレクティブが含まれます。複数の systemctl
コマンドがバックグラウンドでユニットファイルと連携します。細かい調整を行う場合は、システム管理者が手動でユニットファイルを編集するか、または作成する必要があります。表3.1「systemd のユニットファイルの場所」には、システムでユニットファイルが保存される 3 つのメインディレクトリーが挙げられていますが、/etc/systemd/system/
ディレクトリーは、システム管理者が作成するか、またはカスタマイズするユニットファイル用に予約されます。
ユニットファイル名は、以下のフォーマットを使用します。
unit_name.type_extension
unit_name はユニットの名前を表し、type_extension はユニットタイプを指定します。ユニットタイプの詳細な一覧は、表3.2「利用可能な systemd のユニットタイプ」を参照してください。たとえば、通常は、システムには sshd.service
ユニットおよび sshd.socket
ユニットがあります。
ユニットファイルには、追加の設定ファイルのディレクトリーを追加できます。たとえば、カスタム設定オプションを sshd.service
に追加するには、sshd.service.d/custom.conf
ファイルを作成し、追加のディレクティブを挿入します。設定ディレクトリーの詳細は、「既存のユニットファイルの変更」を参照してください。
さらに、sshd.service.wants/
ディレクトリーおよび sshd.service.requires/
ディレクトリーを作成することもできます。このディレクトリーには、sshd
サービスの依存関係であるユニットファイルへのシンボリックリンクが含まれます。シンボリックリンクは、[Install] ユニットファイルに基づいてインストール時に、または [Unit] オプションに基づいてランタイム時に自動的に作成されます。このディレクトリーとシンボリックリンクを手動で作成することもできます。[Install] オプションおよび [Unit] オプションの詳細は、以下の表を参照してください。
多くのユニットファイルオプションは、いわゆる ユニット指定子 を使用して設定できます。これは、ユニットファイルが読み込まれる際にユニットパラメーターに動的に置き換えられるワイルドカード文字列です。これにより、インスタンス化されたユニットを生成するテンプレートとしての役割を担う汎用ユニットファイルを作成できます。詳細は、「インスタンス化されたユニットの使用」を参照してください。
3.5.2. ユニットファイル構造
通常、ユニットファイルは 3 つのセクションで構成されています。
-
[Unit]
セクション- ユニットのタイプに依存しない一般的なオプションが含まれます。このセクションに含まれるオプションはユニットを説明し、ユニットの動作を指定し、他のユニットへの依存関係を設定します。最もよく使用される [Unit] オプションの一覧は、表3.9「[Unit] セクションの重要なオプション」を参照してください。 -
[Unit type]
セクション - ユニットにタイプ固有のディレクティブがある場合は、そのユニットタイプにちなんで命名されたセクションにまとめられます。たとえば、サービスユニットファイルには[Service]
セクションが含まれます。 -
[Install]
セクション -systemctl enable
コマンドおよびdisable
コマンドでユニットをインストールした際の情報が含まれます。[Install]
セクションのオプションの一覧は、表3.11「[Install] セクションの重要なオプション」を参照してください。
3.5.2.1. [Unit] セクションの重要なオプション
以下の表は、[Unit] セクションの重要なオプションを示しています。
表3.9 [Unit] セクションの重要なオプション
オプション[a]] セクションで設定可能なオプションの一覧は、systemd.unit(5) の man ページを参照してください。 | 説明 |
---|---|
|
ユニットの説明です。このテキストは、たとえば |
| ユニットのドキュメントを参照する URI の一覧を提供します。 |
|
ユニットが開始する順序を定義します。このユニットは、 |
|
その他のユニットに依存関係を設定します。 |
|
|
|
|
[a]
[Unit
[b]
ほとんどの場合、ユニットファイルオプションの After および Before で依存関係の並び順を設定するだけで十分です。Wants (推奨) または Requires で要件の依存関係も設定する場合は、依存関係の並び順を指定する必要があります。これは、並び順と要件の依存関係が相互に依存していないためです。
|
3.5.2.2. [Service] セクションの重要なオプション
以下の表では、[Service] セクションの重要なオプションを紹介しています。
表3.10 [Service] セクションの重要なオプション
オプション[a]] セクションで設定可能なオプションの一覧は、systemd.service (5) の man ページを参照してください。 | 説明 |
---|---|
|
*
*
*
*
*
* |
|
ユニットの開始時に実行するコマンドまたはスクリプトを指定します。 |
| ユニットの停止時に実行するコマンドまたはスクリプトを指定します。 |
| ユニットの再読み込み時に実行するコマンドまたはスクリプトを指定します。 |
|
このオプションを有効にすると、 |
|
True に設定すると、サービスは、そのプロセスがすべて終了していてもアクティブと見なされます。デフォルトの値は False です。このオプションは、特に |
[a]
[Service
|
3.5.2.3. [Install] セクションの重要なオプション
以下の表は、[Install] セクションの重要なオプションを紹介しています。
表3.11 [Install] セクションの重要なオプション
オプション[a]] セクションで設定可能なオプションの一覧は、systemd.unit (5) の man ページを参照してください。 | 説明 |
---|---|
|
ユニット名の追加一覧を、スペース区切りで提供します。 |
|
そのユニットに依存するユニットの一覧です。このユニットが有効な場合に、 |
|
このユニットへの依存が弱いユニットの一覧です。このユニットが有効になると、 |
| 対応するユニットと共にインストールまたはアンインストールされるユニットの一覧を指定します。 |
| インスタンス化されているユニットだけが対象となりますが、このオプションは、ユニットが有効になっているデフォルトのインスタンスを指定します。「インスタンス化されたユニットの使用」を参照してください。 |
[a]
[Install
|
3.5.3. カスタムユニットファイルの作成
ユニットファイルをゼロから作成するユースケースが複数あります。カスタムデーモンを実行したり、一部の既存のサービスの 2 つ目のインスタンスを作成したり (「sshd サービスの 2 つ目のインスタンスの作成」を参照)、SysV init スクリプトをインポートしたり (「SysV Init スクリプトのユニットファイルへの変換」を参照) できます。一方、既存ユニットの動作の変更または拡張のみを実行しようとする場合は、 「既存のユニットファイルの変更」を参照してください。以下の手順では、カスタムサービスを作成する一般的なプロセスを説明します。
手順
-
カスタムサービスで実行可能なファイルを用意します。カスタムで作成されたスクリプトや、ソフトウェアプロバイダーが提供する実行ファイルがこれにあたります。必要な場合は、カスタムサービスのメインプロセスの PID を保持するため、PID ファイルを用意します。また、サービスのシェル変数を保存するために環境ファイルを組み込むこともできます。(
chmod a+x
を実行して) ソーススクリプトが実行でき、インタラクティブではないことを確認してください。 /etc/systemd/system/
ディレクトリーにユニットファイルを作成し、ファイルに適切なパーミッションがあることを確認します。root
で以下のコマンドを実行します。touch /etc/systemd/system/name
.servicechmod 664 /etc/systemd/system/name
.servicename を、作成するサービスの名前に置き換えます。ファイルには実行権限が必要ありません。
上の手順で作成した
name.service
ファイルを開き、サービス設定オプションを追加します。作成するサービスのタイプに応じて、さまざまなオプションを使用できます。「ユニットファイル構造」を参照してください。以下は、ネットワーク関連サービスのユニットの設定例になります。[Unit] Description=service_description After=network.target [Service] ExecStart=path_to_executable Type=forking PIDFile=path_to_pidfile [Install] WantedBy=default.target
詳細は以下のようになります。
-
service_description は、ジャーナルログファイルおよび
systemctl status
コマンドの出力に表示される役立つ説明です。 -
After
設定により、このサービスは、ネットワークが実行してから起動します。関連するサービスまたはターゲットは、スペースで区切って追加します。 - path_to_executable は、サービス実行ファイルへのパスを表します。
-
Type=forking
は、fork システム呼び出しを行うデーモンに使用します。サービスのメインプロセスは、path_to_pidfile で指定した PID で作成されます。その他の起動タイプは、表3.10「[Service] セクションの重要なオプション」を参照してください。 -
WantedBy
では、サービスを起動するターゲットを指定します。ターゲットは、従来のランレベルの概念に代わるものとお考えください。
-
service_description は、ジャーナルログファイルおよび
root
で以下のコマンドを実行すると、新しいname.service
ファイルが存在することが、systemd に通知されます。systemctl daemon-reload
systemctl start name
.service警告新しいユニットファイルを作成したり、既存のユニットファイルを修正したら常に
systemctl daemon-reload
コマンドを実行します。このコマンドを実行しないと、systemd のステータスと、ディスクの実際のサービスユニットファイルが一致しなくなるため、systemctl start
コマンドやsystemctl enable
コマンドが失敗します。ユニット数が多いシステムでは、各ユニットのステータスをシリアライズし、その後再読み込み時にデシリアライズする必要があるため、これには時間がかかることがあります。
3.5.3.1. sshd サービスの 2 番目のインスタンスを使用したカスタムユニットファイルの作成
システム管理者は、サービスのインスタンスを複数設定し、実行しなければならないことが多々あります。これは、サービスの主なインスタンスとの競合を避けるために、元のサービス設定ファイルのコピーを作成し、特定のパラメーターを変更することで実行します。以下の手順は、sshd
サービスの 2 つ目のインスタンスを作成する方法を示しています。
手順
2 つ目のデーモンで使用する、
sshd_config
ファイルのコピーを作成します。# cp /etc/ssh/sshd{,-second}_config
作成した
sshd-second_config
ファイルを編集し、2 つ目のデーモンに別のポート番号と PID ファイルを割り当てます。Port 22220 PidFile /var/run/sshd-second.pid
Port
オプションおよびPidFile
オプションの詳細は、man ページのsshd_config
(5) を参照してください。他のサービスで使用されていないポートを選択してください。PID ファイルはサービスの実行時に存在していなければいけないものではありません。存在しない場合は、サービスの起動時に自動的に生成されます。sshd
サービスの systemd ユニットファイルのコピーを作成します。# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
作成した
sshd-second.service
を以下のように変更します。Description
オプションを変更します。Description=OpenSSH server second instance daemon
After
オプションを指定するサービスに sshd.service を追加し、最初のインスタンスが起動した場合に限り 2 つ目のインスタンスが起動するようにします。After=syslog.target network.target auditd.service sshd.service
- sshd の最初のインスタンスには鍵の生成が含まれるため、ExecStartPre=/usr/sbin/sshd-keygen 行を削除します。
sshd
コマンドに-f /etc/ssh/sshd-second_config
パラメーターを追加して、代替の設定ファイルが使用されるようにします。ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
上記のように変更すると、sshd-second.service は以下のようになります。
[Unit] Description=OpenSSH server second instance daemon After=syslog.target network.target auditd.service sshd.service [Service] EnvironmentFile=/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target
SELinux を使用している場合は、sshd の 2 番目のインスタンスのポートを SSH ポートに追加します。追加しないと、sshd の 2 番目のインスタンスがポートにバインドされません。
# semanage port -a -t ssh_port_t -p tcp 22220
システムの起動時にこのサービスが自動的に起動するように、sshd-second.service を有効にします。
# systemctl enable sshd-second.service
-
systemctl status
コマンドを使用して sshd-second.service が実行中かどうかを確認します。 さらに、サービスに接続して、ポートが正しく有効化されていることを確認します。
$
ssh -p 22220 user@server
ファイアウォールを使用している場合は、sshd の 2 番目のインスタンスへの接続を許可するように適切に設定されていることを確認してください。
3.5.3.2. カスタムユニットファイルの順番および依存関係のターゲットの選択
カスタムユニットファイルの順番および依存関係のターゲットを適切に選択する方法は、以下の Red Hat ナレッジベースの記事を参照してください。
ユニットファイルの並び順および依存関係に関する実例と追加情報は「Is there any useful information about writing unit files?」を参照してください。
systemd
が開始するサービスへの制限の設定は、Red Hat ナレッジベースの記事 「RHEL 7 および systemd でサービスに制限を設定する」を参照してください。この制限は、サービスのユニットファイルで設定する必要があります。systemd
は、/etc/security/limits.conf
設定ファイルおよび /etc/security/limits.d/*.conf
設定ファイルに設定した制限を無視する点に注意してください。このファイルに定義した制限は、ログインセッションの開始時に PAM により設定されますが、systemd
が開始するデーモンは、PAM ログインセッションを使用しません。
3.5.4. SysV Init スクリプトのユニットファイルへの変換
SysV init スクリプトをユニットファイルに変換する前に、すでに別の場所で変換が行われていないことを確認します。Red Hat Enterprise Linux にインストールされるすべてのコアサービスにデフォルトのユニットファイルが同梱されていますが、多くのサードパーティーソフトウェアパッケージにも同様のことが言えます。
init スクリプトをユニットファイルに変換するには、スクリプトを分析し、そこから必要な情報を抽出することが必要になります。このデータに基づいて、ユニットファイルを作成できます。init スクリプトはサービスのタイプによって大きく異なるため、この章で概略されているよりも多くの設定オプションの変換を使用しなければならない場合もあります。init スクリプトで利用できるカスタマイズのレベルの一部が systemd ユニットでサポートされなくなっていることに注意してください。
変換に必要とされるほとんどの情報はスクリプトのヘッダーに提供されます。以下の例は、Red Hat Enterprise Linux 6 で postfix
サービスを起動するために使用される init スクリプトの開始セクションになります。
!/bin/bash # postfix Postfix Mail Transfer Agent # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another.
# END INIT INFO
上記の例では、# chkconfig および # description で始まる行のみが必須になり、init ファイルによってはその他の記載はない可能性もあります。BEGIN INIT INFO 行と END INIT INFO 行に囲まれたテキストは Linux Standard Base (LSB) ヘッダー と呼ばれています。LSB ヘッダーを指定している場合は、サービスの説明、依存関係、およびデフォルトのランレベルを定義するディレクティブがこれに含まれます。次に、新規のユニットファイルに必要なデータを収集する分析タスクの概要が続きます。postfix init スクリプトは例として使用されます。
3.5.4.1. systemd サービスの説明の検索
#description で始まる行で、スクリプトに関する説明の情報を確認します。この説明は、サービス名と共に、ユニットファイルの [Unit] セクションの Description
オプションで使用します。LSB ヘッダーの #Short-Description 行および #Description 行に同様のデータが含まれる場合があります。
3.5.4.2. systemd サービス依存関係の検索
LSB ヘッダーには、サービス間の依存関係を形成する複数のディレクティブが含まれる場合があります。そのほとんどは systemd ユニットオプションに変換できます。表3.12「LSB ヘッダーの依存関係オプション」を参照してください。
表3.12 LSB ヘッダーの依存関係オプション
LSB オプション | 説明 | 同等のユニットファイル |
---|---|---|
| サービスの起動ファシリティー名を指定します。この名前は他の init スクリプトで参照できます ( "$" 接頭辞を使用)。ただし、ユニットファイルが他のユニットをファイル名で参照できるようになったため、これは不要になりました。 | – |
|
必要なサービスの起動ファシリティー名が含まれます。これは、並び順の依存関係として変換され、起動ファシリティー名は、対応するサービスまたはそのサービスが属するターゲットに置き換えられます。たとえば、 |
|
| Required-Start よりも弱い依存関係を構成します。Should-Start 依存関係が失敗しても、サービスの起動には影響を及ぼしません。 |
|
| 負の依存関係を構成します。 |
|
3.5.4.3. サービスのデフォルトターゲットの検索
#chkconfig で始まる行には 3 つの数値があります。最も重要な値は最初の数値で、サービスが起動するデフォルトのランレベルを示しています。ランレベルは、同等の systemd ターゲットに対応します。次に、そのターゲットを、ユニットファイルの [Install] セクションの WantedBy
オプションに記述します。たとえば、postfix
がランレベルの 2、3、4、および 5 で起動していた場合、これは multi-user.target および graphical.target に対応します。ただし、graphical.target は multiuser.target に依存するため、両方を記述する必要はありません。また、LSB ヘッダーの #Default-Start 行および #Default-Stop 行に、デフォルト、および動作するべきでないランレベルの情報がある場合は、そちらも参照してください。
#chkconfig 行で指定した他の 2 つの値は、init スクリプトの起動およびシャットダウンの優先順位を表します。この値は、init スクリプトが読み込まれる場合は systemd により解釈されますが、同等のユニットファイルはありません。
3.5.4.4. サービスで使用されるファイルの検索
init スクリプトでは、専用ディレクトリーから関数ライブラリーを読み込み、設定ファイル、環境ファイル、および PID ファイルのインポートを許可します。環境変数は init スクリプトヘッダーの #config で始まる行で指定し、EnvironmentFile
ユニットファイルオプションに変換されます。#pidfile init スクリプト行に指定した PID ファイルは、PIDFile
オプションでユニットファイルにインポートされます。
init スクリプトヘッダーに含まれない主要な情報は、サービス実行ファイルへのパス、またはサービスで必要になる可能性のあるその他のファイルへのパスです。以前のバージョンの Red Hat Enterprise Linux では、init スクリプトは、カスタム定義のアクションと共に 起動、停止、再起動 などのデフォルトアクションのサービスの動作を定義する Bash ケースステートメントを使用しました。postfix
init スクリプトからの以下の抜粋は、サービス起動時に実行するコードのブロックを示しています。
conf_check() { [ -x /usr/sbin/postfix ] || exit 5 [ -d /etc/postfix ] || exit 6 [ -d /var/spool/postfix ] || exit 5 } make_aliasesdb() { if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ] then # /etc/aliases.db might be used by other MTA, make sure nothing # has touched it since our last newaliases call [ /etc/aliases -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return /usr/bin/newaliases touch -r /etc/aliases.db "$ALIASESDB_STAMP" else /usr/bin/newaliases fi } start() { [ "$EUID" != "0" ] && exit 4 # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 1 conf_check # Start daemons. echo -n $"Starting postfix: " make_aliasesdb >/dev/null 2>&1 [ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start" RETVAL=$? [ $RETVAL -eq 0 ] && touch $lockfile echo return $RETVAL }
init スクリプトの拡張性により、start()
関数ブロックから呼び出される conf_check()
および make_aliasesdb()
の 2 つのカスタム関数を指定することができました。さらに詳しくみると、上記コードでは外部のファイルおよびディレクトリーが複数記述されています (主なサービス実行ファイル /usr/sbin/postfix
、設定ディレクトリー /etc/postfix/
、/var/spool/postfix/
、および /usr/sbin/postconf/
ディレクトリー) 。
systemd は、事前に定義されたアクションのみをサポートしますが、オプションの ExecStart
、ExecStartPre
、ExecStartPost
、ExecStop
、および ExecReload
でカスタムの実行ファイルを有効にできます。/usr/sbin/postfix
は、対応するスクリプトとともに、サービスの起動時に実行します。複雑な init スクリプトを変換する際には、スクリプトのすべてのステートメントの目的を理解している必要があります。一部のステートメントはオペレーティングシステムのバージョンに固有のものであるため、そのステートメントを変換する必要はありません。一方、新規の環境では、サービス実行ファイルおよびサポートファイルやユニットファイルで調整が一部必要となる場合があります。
3.5.5. 既存のユニットファイルの変更
システムにインストールされるサービスは、/usr/lib/systemd/system/
ディレクトリーに保存されるデフォルトのユニットファイルと共に提供されます。システム管理者はこのファイルを直接変更できないため、カスタマイズは /etc/systemd/system/
ディレクトリーの設定ファイルに制限される必要があります。
手順
必要とされる変更の程度に応じて、以下の方法のいずれかを実施してください。
-
補助設定ファイルのディレクトリーを
/etc/systemd/system/unit.d/
に作成します。この方法は、ほとんどのユースケースで推奨されます。これにより、元のユニットファイルを参照しつつも、デフォルト設定を追加の機能で拡張できます。この場合、パッケージのアップグレードで導入されるデフォルトユニットへの変更は自動的に適用されます。詳細は「デフォルトのユニット設定の拡張」 を参照してください。 -
元のユニットファイル
/usr/lib/systemd/system/
のコピーを/etc/systemd/system/
に作成し、そこで変更を行います。コピーは元のファイルを上書きするため、パッケージの更新で導入される変更は適用されません。この方法は、パッケージの更新とは無関係に永続する重要なユニット変更を行う際に役に立ちます。詳細は「デフォルトのユニット設定の上書き」 を参照してください。
-
補助設定ファイルのディレクトリーを
-
ユニットのデフォルト設定に戻るには、
/etc/systemd/system/
でカスタム作成した設定ファイルを削除します。 システムを再起動せずにユニットファイルへの変更を適用するには、以下を実行します。
systemctl daemon-reload
daemon-reload
オプションは、すべてのユニットファイルを再読み込みし、ユニットファイルへの変更をすぐに適用するのに必要な依存関係ツリー全体を再作成します。また、以下のコマンドを実行しても同じ結果になります。このコマンドの実行にはroot
権限が必要になります。init q
変更したユニットファイルが実行中のサービスに属する場合は、このサービスを再起動して新たな設定を反映させる必要があります。
systemctl restart name
.service
SysV init スクリプトが処理しているサービスのプロパティ (依存関係やタイムアウトなど) を変更するときは、init スクリプト自体は変更しないでください。代わりに、「デフォルトのユニット設定の拡張」と「デフォルトのユニット設定の上書き」にあるように、サービスの systemd
ドロップイン設定ファイルを作成します。その後、通常の systemd
サービスと同じ方法でサービスを管理します。
たとえば、network
サービスの設定を拡張するときは、init スクリプトファイル /etc/rc.d/init.d/network
を変更しないでください。代わりに、新しいディレクトリー /etc/systemd/system/network.service.d/
と、systemd
ドロップインファイル /etc/systemd/system/network.service.d/my_config.conf
を作成します。そして、ドロップインファイルの値を変更します。systemd
は、network
サービスを network.service
として認識することに注意してください。作成したディレクトリーが network.service.d
と命名されるのはそのためです。
3.5.5.1. デフォルトのユニット設定の拡張
本セクションでは、追加の設定オプションでデフォルトのユニットファイルを拡張する方法を説明します。
手順
追加の設定オプションでデフォルトのユニットファイルを拡張するには、最初に
/etc/systemd/system/
に設定ディレクトリーを作成します。サービスユニットを拡張する場合は、root
で以下のコマンドを実行します。mkdir /etc/systemd/system/name
.service.d/name を、拡張する必要のあるサービスの名前に置き換えます。上記の構文はすべてのユニットタイプに適用されます。
作成したディレクトリーに設定ファイルを作成します。ファイル名の接尾辞は .conf にする必要があることに注意してください。以下のコマンドを実行します。
touch /etc/systemd/system/name.service.d/config_name.conf
config_name を、設定ファイルの名前に置き換えます。このファイルは、通常のユニットファイル構造に基づくため、すべてのディレクティブは該当するセクションで指定する必要があります。「ユニットファイル構造」を参照してください。
たとえば、カスタムの依存性を追加するには、以下の内容で設定ファイルを作成します。
[Unit] Requires=new_dependency After=new_dependency
new_dependency は、依存性としてマークが付けられるユニットを表します。次の例は、30 秒の遅延後のメインプロセス終了後にサービスを再起動する設定ファイルです。
[Service] Restart=always RestartSec=30
1 つのタスクだけを扱う簡単な設定ファイルを作成することが推奨されます。これにより、他のサービスの設定ディレクトリーに簡単に移動したり、リンクできます。
そのユニットに行った変更を適用するには、
root
で以下のコマンドを実行します。systemctl daemon-reload
systemctl restart name
.service
例3.10 httpd.service 設定の拡張
Apache サービスの起動時にカスタムシェルスクリプトが自動的に実行されるように httpd.service ユニットを変更するには、以下の手順で行います。
ディレクトリーおよびカスタム設定ファイルを作成します。
# mkdir /etc/systemd/system/httpd.service.d/
# touch /etc/systemd/system/httpd.service.d/custom_script.conf
Apache で自動的に起動するスクリプトが
/usr/local/bin/custom.sh
にある場合は、以下のテキストをcustom_script.conf
ファイルに追加します。[Service] ExecStartPost=/usr/local/bin/custom.sh
ユニットの変更を適用するには、以下を実行します。
# systemctl daemon-reload
# systemctl restart httpd.service
/etc/systemd/system/
の設定ディレクトリーの設定ファイルは、/usr/lib/systemd/system/
のユニットファイルに優先します。そのため、設定ファイルに、一度だけ指定できるオプション (Description
、ExecStart
など) が含まれる場合は、このオプションのデフォルト値が上書きされます。「上書きされたユニットの監視」で説明されているように、 systemd-delta
コマンドの出力では、一部のオプションは実際に上書きされますが、該当するユニットは常に [EXTENDED] とマークされます。
3.5.5.2. デフォルトのユニット設定の上書き
本セクションでは、デフォルトのユニット設定を上書きする方法を説明します。
手順
ユニットファイルを提供するパッケージの更新後も変更を持続させるには、最初にファイルを
/etc/systemd/system/
ディレクトリーにファイルをコピーします。それを行うには、root
で以下のコマンドを実行します。cp /usr/lib/systemd/system/name
.service /etc/systemd/system/name.servicename は、変更するサービスユニットの名前を表します。上記の構文はすべてのユニットタイプに適用されます。
コピーされたファイルをテキストエディターで開き、必要な変更を行います。ユニットの変更を適用するには、
root
で以下のコマンドを実行します。systemctl daemon-reload
systemctl restart name
.service
例3.11 タイムアウト制限の変更
サービスごとにタイムアウト値を指定すると、正常に動作していないサービスによってシステムがフリーズすることを防ぐことができます。タイムアウト値を指定しないサービスには、通常のサービスの場合は 90 秒、そして SysV と互換性のあるサービスの場合は 300 秒と、それぞれデフォルトのタイムアウトが設定されています。
たとえば、httpd
サービスのタイムアウト制限を延長するときは、以下を行います。
httpd
ユニットファイルを、/etc/systemd/system/
ディレクトリーにコピーします。cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service
/etc/systemd/system/httpd.service
ファイルを開き、[Service]
セクションにTimeoutStartSec
値を指定します。… [Service] … PrivateTmp=true TimeoutStartSec=10 [Install] WantedBy=multi-user.target …
systemd
デーモンを再ロードします。systemctl daemon-reload
オプション:新しいタイムアウト値を確認します。
systemctl show httpd -p TimeoutStartUSec
グローバルでタイムアウト制限を変更するには、/etc/systemd/system.conf
ファイルの DefaultTimeoutStartSec
を変更します。
3.5.5.3. 上書きされたユニットの監視
本セクションでは、上書きされたユニットファイルまたは変更されたユニットファイルの概要を表示する方法を説明します。
手順
上書きされたユニット、または変更したユニットファイルの概要を表示するには、以下のコマンドを実行します。
systemd-delta
上記のコマンドを実行すると、以下のような出力になります。
[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target [OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service --- /usr/lib/systemd/system/autofs.service 2014-10-16 21:30:39.000000000 -0400 + /etc/systemd/system/autofs.service 2014-11-21 10:00:58.513568275 -0500 @@ -8,7 +8,8 @@ EnvironmentFile=-/etc/sysconfig/autofs ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid ExecReload=/usr/bin/kill -HUP $MAINPID -TimeoutSec=180 +TimeoutSec=240 +Restart=Always [Install] WantedBy=multi-user.target [MASKED] /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service [EXTENDED] /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf 4 overridden configuration files found.
3.5.6. インスタンス化されたユニットの使用
ランタイム時に、1 つのテンプレート設定ファイルから複数のユニットをインスタンス化できます。「@」文字は、テンプレートにマークを付け、ユニットをこれに関連付けるために使用されます。インスタンス化されたユニットは、(Requires
オプションまたは Wants
オプションを使用して) 別のユニットから開始することも、systemctl start
コマンドで開始することもできます。インスタンス化されたサービスユニットの名前は以下のような形式となります。
template_name@instance_name.service
ここで、template_name は、テンプレート設定ファイルの名前になります。instance_name を、ユニットインスタンスの名前に置き換えます。複数のインスタンスが同じテンプレートファイルを参照し、このテンプレートには、ユニットの全インスタンスに共通する設定オプションが含まれます。テンプレートユニットの名前には以下の形式が使用されます。
unit_name@.service
たとえば、ユニットファイルに次の Wants
設定を指定すると、
Wants=getty@ttyA.service getty@ttyB.service
この設定により、systemd が、最初に指定したサービスユニットを検索します。該当するユニットが見つからないと、「@」とタイプ接尾辞の間にある部分は無視され、systemd が getty@.service
ファイルを検索し、そこから設定を読み取り、サービスを起動します。
たとえば、getty@.service
テンプレートには以下のディレクティブが含まれます。
[Unit] Description=Getty on %I … [Service] ExecStart=-/sbin/agetty --noclear %I $TERM …
上記のテンプレートから getty@ttyA.service および getty@ttyB.service をインスタンス化する場合、Description
= は Getty on ttyA および Getty on ttyB として解決されます。
3.5.6.1. 重要なユニット指定子
ワイルドカード文字 (ユニット指定子 とも呼ばれる) を、すべてのユニット設定ファイルで使用できます。ユニット指定子は、ランタイム時に特定のユニットパラメーターに置き換えられて解釈されます。表3.13「重要なユニット指定子」 で、特にテンプレートユニットで役に立つユニット指定子の一覧を紹介します。
表3.13 重要なユニット指定子
ユニット指定子 | 意味 | 説明 |
---|---|---|
| 完全ユニット名 |
タイプ接尾辞を含む完全ユニット名を表します。 |
| 接頭辞名 | タイプ接尾辞が削除されたユニット名を表します。インスタンス化されたユニットの %p は、ユニット名の「@」文字の前の部分を表します。 |
| インスタンス名 |
インスタンス化されたユニット名の「@」文字およびタイプ接尾辞間の部分です。 |
| ホスト名 | ユニット設定を読み込んだ時に稼働しているシステムのホスト名を表します。 |
| ランタイムディレクトリー |
ランタイムディレクトリーを表します。これは、 |
ユニット指定子の詳細な一覧は、man ページの systemd.unit(5)
を参照してください。
3.6. 起動時間を短縮するための systemd の最適化
デフォルトで有効になっている systemd ユニットファイルの一覧があります。システムの起動時に、このようなユニットファイルで定義されているシステムサービスが自動的に実行し、システムの起動時間に影響を及ぼします。
本セクションでは、以下を説明します。
- システムの起動パフォーマンスを調べるツール
- systemd ユニットがデフォルトで無効になっている目的と、起動時間を短縮するために、このような systemd ユニットを無効にしても安全な状況
3.6.1. システムの起動パフォーマンスを調べる
システムの起動時のパフォーマンスを調べる場合は、systemd-analyze
コマンドを使用できます。このコマンドでは、多数のオプションが使用できます。ただし、本セクションでは、起動時間を短縮するために、systemd を調整する際に重要なものだけを説明します。
オプションの完全リストおよび詳細な説明は、man ページの systemd-analyze
を参照してください。
前提条件
システムの起動時に調整するために、systemd を調べる前に、有効なサービスの一覧を表示することもできます。
$ systemctl list-unit-files --state=enabled
システム全体の起動時間の分析
手順
- システムが最後に起動してからの時間に関する総合的な情報を表示する場合は、次のコマンドを実行します。
$ systemd-analyze
ユニットの初期化時間の分析
手順
- 各 systemd ユニットの初期化時間の詳細を確認する場合は、次のコマンドを実行します。
$ systemd-analyze blame
この出力では、システムが最後に起動した時に初期化にかかった時間に応じて、ユニットが降順で表示されます。
重要なユニットの識別
手順
- システムが最後に起動した時に、初期化に最も時間がかかったユニットを特定するには、次のコマンドを実行します。
$ systemd-analyze critical-chain
この出力では、起動に非常に時間がかかっているユニットが、赤字で強調表示されています。
図3.1 systemd-analyze critical-chain コマンドの出力

3.6.2. 無効にしても安全なサービスを選択するためのガイド
システムの起動時に時間がかかっている場合は、デフォルトで起動時に有効になるサービスの一部を無効にすることで、起動時間を短くできます。
このようなサービスを一覧表示するには、次のコマンドを実行します。
$ systemctl list-unit-files --state=enabled
サービスを無効にするには、次のコマンドを実行します。
# systemctl disable service_name
ただし、お使いのオペレーティングシステムが安全で、希望通りに機能できるように、特定のサービスは有効にしたままにしておく必要があります。
次の表は、無効にしても安全なサービスを選択するためのガイドとして使用できます。この表では、Red Hat Enterprise Linux 8 の最小インストールで、デフォルトで有効になっているすべてのサービスと、各サービスを無効にしても安全かどうかを説明します。
その他にも、サービスを無効にできる状況と、そのサービスを無効にすべきではない理由を示しています。
表3.14 RHEL 8 の最小インストールで、デフォルトで有効になっているサービス
サービス名 | 無効にすることは可能か? | 詳細情報 |
---|---|---|
auditd.service | はい |
|
autovt@.service | いいえ | このサービスは、本当に必要な場合に限り実行されるため、無効にする必要はありません。 |
crond.service | はい | crond.service を無効にすると crontab からアイテムが実行しないことに注意してください。 |
dbus-org.fedoraproject.FirewallD1.service | はい |
|
dbus-org.freedesktop.NetworkManager.service | はい |
|
dbus-org.freedesktop.nm-dispatcher.service | はい |
|
firewalld.service | はい |
ファイアウォールが必要ない場合に限り |
getty@.service | いいえ | このサービスは、本当に必要な場合に限り実行されるため、無効にする必要はありません。 |
import-state.service | はい |
|
irqbalance.service | はい |
|
kdump.service | はい |
|
loadmodules.service | はい |
このサービスは、 |
lvm2-monitor.service | はい |
|
microcode.service | いいえ | そのサービスは、CPU 内のマイクロコードソフトウェアの更新を提供するため、無効にしないでください。 |
NetworkManager-dispatcher.service | はい |
|
NetworkManager-wait-online.service | はい |
|
NetworkManager.service | はい |
|
nis-domainname.service | はい |
|
rhsmcertd.service | いいえ | |
rngd.service | はい |
|
rsyslog.service | はい |
|
selinux-autorelabel-mark.service | はい |
|
sshd.service | はい |
|
sssd.service | はい |
|
syslog.service | はい |
|
tuned.service | はい |
|
lvm2-lvmpolld.socket | はい |
|
dnf-makecache.timer | はい |
|
unbound-anchor.timer | はい |
|
サービスの詳細は、次のいずれかのコマンドを実行すると表示できます。
$ systemctl cat <service_name>
$ systemctl help <service_name>
systemctl cat
コマンドは、/usr/lib/systemd/system/<service>
の配下に置かれたサービスファイルの内容と、適用可能なすべてのオーバーライドを提供します。適用可能なオーバーライドには、/etc/systemd/system/<service>
ファイルからのユニットファイルオーバーライドと、対応する unit.type.d
ディレクトリーのドロップインファイルが含まれます。
ドロップインファイルの詳細は、man ページの systemd.unit
を参照してください。
systemctl help
コマンドは、特定サービスの man ページを表示します。
3.7. 関連情報
systemd と、Red Hat Enterprise Linux での使用方法は、以下に挙げる資料を参照してください。
3.7.1. インストールされているドキュメント
-
systemctl
(1) -systemctl
コマンドラインユーティリティーの man ページには、サポートされるオプションとコマンドの完全なリストが提供されます。 -
systemd
(1) -systemd
システムおよびサービスマネージャーの man ページでは、その概念に関する詳細情報が提供され、利用可能なコマンドラインオプションと環境変数、サポートされる設定ファイルとディレクトリー、認識されるシグナル、および利用可能なカーネルオプションが説明されています。 -
systemd-delta
(1) - 拡張され、上書きされた設定ファイルの検索を可能にするsystemd-delta
ユーティリティーの man ページです。 -
systemd.directives(7)
-systemd.directives
という名前の man ページでは、systemd ディレクティブの詳細を確認できます。 -
systemd.unit
(5) -systemd.unit
の man ページでは、systemd ユニットファイルの詳細情報と、利用可能なすべての設定オプションが説明されてます。 -
systemd.service
(5) -systemd.service
の man ページでは、サービスユニットファイルの形式が紹介されています。 -
systemd.target
(5) -systemd.target
の man ページには、ターゲットユニットファイルの形式が説明されています。 -
systemd.kill
(5) -systemd.kill
の man ページでは、プロセスの強制終了手順の設定が説明されています。
3.7.2. オンラインドキュメント
- systemd ホームページ - このプロジェクトのホームページでは、systemd に関する詳細情報が提供されています。
第4章 ユーザーアカウントおよびグループアカウントの管理の概要
ユーザーとグループの制御は、Red Hat Enterprise Linux (RHEL) システム管理の中核となる要素です。
4.1. ユーザーとグループの概要
各 RHEL ユーザーには各種ログイン認証情報があり、さまざまなグループに割り当ててシステム権限をカスタマイズすることができます。
ファイルを作成するユーザーは、そのファイルの所有者 および
グループ所有者です。ファイルには、所有者、グループ、およびそのグループ外のユーザーに対して読み取り、書き込み、実行のパーミッションが別々に割り当てられます。ファイルの所有者は、root
ユーザーのみが変更できます。ファイルへのアクセス権限を変更できるのは、root
ユーザー、ファイル所有者の両方です。通常ユーザーは、所有するファイルのグループ所有権を、所属するグループに変更できます。
各ユーザーは、ユーザー ID (UID) と呼ばれる一意の数値 ID に関連付けられています。各グループは グループ ID (GID) に関連付けられています。グループ内のユーザーは、そのグループが所有するファイルの読み取り、書き込み、実行を行う権限を共有します。
4.2. 予約ユーザーおよびグループ ID の設定
RHEL は、999 以下のユーザー ID とグループ ID をシステムユーザーとグループ用に予約しています。予約ユーザー ID とグループ ID は、setup
パッケージで確認できます。予約ユーザー ID とグループ ID を表示するには、以下を使用します。
cat /usr/share/doc/setup*/uidgid
予約範囲は今後増える可能性があるため、新規ユーザーおよびグループには、5000 以降の ID を割り当てることを推奨します。
デフォルトで新規ユーザーに割り当てる ID を 5000 以降に指定するには、/etc/login.defs
ファイルの UID_MIN
と GID_MIN
パラメーターを変更します。
手順
デフォルトで新規ユーザーに割り当てる ID を 5000 以降にするには、以下のコマンドを使用します。
-
任意のエディターで
/etc/login.defs
ファイルを開きます。 UID の自動選択の最小値を定義する行を見つけます。
# Min/max values for automatic uid selection in useradd # UID_MIN 1000
UID_MIN
の値を 5000 から開始するように変更します。# Min/max values for automatic uid selection in useradd # UID_MIN 5000
GID の自動選択の最小値を定義する行を見つけます。
# Min/max values for automatic gid selection in groupadd # GID_MIN 1000
UID_MIN
および GID_MIN
の値を変更する前に作成されたユーザーおよびグループに割り当てられる UID および GID は、デフォルトの 1000 から開始します。
上限が 1000 のシステムとの競合を回避するため、SYS_UID_MAX
を変更して、システムが予約している ID を 1000 以上にしないようにしてください。
4.3. ユーザープライベートグループ
RHEL は、ユーザープライベートグループ ( UPG) システム設定を使用するため、UNIX グループの管理が容易になります。ユーザープライベートグループは、新規ユーザーがシステムに追加されるたびに作成されます。ユーザープライベートグループは作成したユーザーと同じ名前となり、そのユーザーがそのユーザープライベートグループの唯一のメンバーになります。
UPG は、複数ユーザー間のプロジェクトの連携を簡素化します。さらに、UPG のシステム設定では、ユーザーおよびこのユーザーが所属するグループ両方がファイルまたはディレクトリーを変更できるので、新規作成されたファイルまたはディレクトリーのデフォルトの権限を安全に設定できます。
グループの一覧は、/etc/group
設定ファイルに保存されます。
第5章 Web コンソールでユーザーアカウントの管理
RHEL Web コンソールは、直接ターミナルにアクセスせずに、幅広い管理タスクを実行できるグラフィカルインターフェースを提供します。たとえば、システムユーザーアカウントの追加、編集、または削除が可能です。
本セクションの内容を読むと、以下を理解できます。
- 既存のアカウントが存在する場所
- 新規アカウントの追加方法
- パスワードの有効期限の設定方法
- ユーザーセッションを終了する方法および時期
前提条件
- RHEL Web コンソールを設定しておく。詳細は「RHEL Web コンソールの使用ガイド」 を参照してください。
- 管理者権限が割り当てられたアカウントで RHEL Web コンソールにログインしている。詳細は「RHEL 8 Web コンソールへのログイン」を参照してください。
5.1. Web コンソールで管理されるシステムユーザーアカウント
RHEL Web コンソールに表示されているユーザーアカウントでは、以下が可能になります。
- システムにアクセスする際にユーザーを認証する
- システムへのアクセス権を設定する
RHEL Web コンソールは、システムに存在するすべてのユーザーアカウントを表示します。そのため、最初に Web コンソールにログインした直後は、ユーザーアカウントが少なくとも 1 つ表示されます。
RHEL Web コンソールにログインしたら、以下の操作を実行できます。
- 新規ユーザーアカウントの作成
- パラメーターの変更
- アカウントのロック
- ユーザーセッションの終了
5.2. Web コンソールで新規アカウントの追加
RHEL Web コンソールを使用して、ユーザーアカウントをシステムに追加し、アカウントに管理者権限を設定する場合は、以下の手順に従います。
前提条件
- RHEL Web コンソールがインストールされており、アクセス可能である。詳細は「Web コンソールのインストール」を参照してください。
手順
- RHEL Web コンソールにログインします。
- をクリックします。
フルネーム フィールドにユーザーの氏名を入力します。
RHEL Web コンソールは、入力した氏名からユーザー名が自動的に作成され、ユーザー名 フィールドに入力されます。名前の頭文字と、苗字で構成される命名規則を使用しない場合は、入力されたユーザー名を変更します。
パスワード/確認 フィールドにパスワードを入力し、再度パスワードを入力します。フィールドの下にあるカラーバーは、入力したパスワードの強度を表し、弱いパスワードは使用できないようにします。
- をクリックして設定を保存し、ダイアログボックスを閉じます。
- 新規作成したアカウントを選択します。
- ロール で、サーバー管理者 を選択します。
これで アカウント 設定に新規アカウントが表示され、認証情報を使用してシステムに接続できるようになりました。
5.3. Web コンソールでパスワード有効期限の強制
デフォルトでは、ユーザーアカウントのパスワードに期限はありません。パスワードの有効期限を設定するには、管理者が、定義した日数後にシステムパスワードが期限切れになるように設定します。
パスワードが期限切れになると、次回のログイン時にパスワードの変更が要求されます。
手順
- RHEL 8 Web コンソールインターフェースへログインします。
- アカウント をクリックします。
- パスワードの有効期限を設定するユーザーアカウントを選択します。
- ユーザーアカウントの設定でパスワードを失効しないをクリックします。
パスワードの有効期限 ダイアログボックスで、... 日ごとのパスワードの変更が必要を選択し、パスワードの期限が切れるまでの日数 (正の整数) を入力します。
- 変更 をクリックします。
設定を確認するには、アカウント設定を開きます。RHEL 8 Webコンソールには、有効期限を表すリンクが表示されます。
5.4. Web コンソールでユーザーセッションの終了
ユーザーがシステムにログインすると、ユーザーセッションが作成されます。ユーザーセッションを終了すると、ユーザーはシステムからログアウトされます。
これは、システムのアップグレードなどの、設定変更の影響を受ける管理タスクを実行する必要がある場合に便利です。
RHEL 8 Web コンソールの各ユーザーアカウントで、現在使用している Web コンソールセッション以外のセッションすべてを終了できます。これにより、管理者がシステムからログアウトしないようにします。
手順
- RHEL 8 Web コンソールにログインします。
- アカウント をクリックします。
- セッションを終了するユーザーアカウントをクリックします。
セッションの終了 ボタンをクリックします。
Terminate Session ボタンが無効になっている場合は、ユーザーがシステムにログインしていません。
RHEL Web コンソールはセッションを終了します。
第6章 コマンドラインからのユーザーの管理
コマンドラインインターフェース (CLI) を使用してユーザーおよびグループを管理できます。
前提条件
-
root
アクセス
6.1. コマンドラインでの新規ユーザーの追加
本セクションでは、useradd
コマンドを使用して、新しいユーザーを追加する方法を説明します。
手順
新規ユーザーを追加するには、以下を使用します。
# useradd options username
options は
useradd
コマンドのコマンドラインオプションに、username はユーザー名に置き換えます。
例
ユーザー ID が
5000
のユーザーsarah
を追加するには、以下を使用します。# useradd -u 5000 sarah
検証手順
新規ユーザーが追加されたことを確認するには、
id
ユーティリティーを使用します。# id sarah
返される出力は以下のとおりです。
uid=5000(sarah) gid=5000(sarah) groups=5000(sarah)
関連情報
-
useradd
の詳細は、useradd
の man ページを参照してください。
6.2. コマンドラインでの新規グループの追加
本セクションでは、groupadd
コマンドを使用して、新しいユーザーを追加する方法を説明します。
手順
新規グループを追加するには、以下を使用します。
# groupadd options group-name
options は
groupadd
コマンドのコマンドラインオプションに、group-name はグループ名に置き換えます。
例
グループ ID が
5000
のグループsysadmins
を追加するには、以下を使用します。# groupadd -g 5000 sysadmins
検証手順
新規グループが追加されていることを確認するには、
tail
ユーティリティーを使用します。# tail /etc/group
返される出力は以下のとおりです。
sysadmins:x:5000:
関連情報
-
useradd
の詳細は、groupadd
の man ページを参照してください。
6.3. コマンドラインでのグループへのユーザーの追加
本セクションでは、usermod
コマンドを使用して、ユーザーの補助グループにグループを追加する方法を説明します。
手順
ユーザーの補助グループにグループを追加するには、以下を使用します。
# usermod --append -G group-name username
group-name はグループ名に、username はユーザー名に置き換えます。
例
ユーザーの
sysadmin
をグループsystem-administrators
に追加するには、以下を使用します。# usermod --append -G system-administrators sysadmin
検証手順
ユーザー
sysadmin
の補助グループに新規グループが追加されていることを確認するには、以下を使用します。# groups sysadmin
返される出力は以下のとおりです。
sysadmin: sysadmin system-administrators
6.4. グループディレクトリーの作成
UPG システム設定では、グループ ID 権限の設定 (setgid) をディレクトリーに適用できます。setgid
を使用して、ディレクトリーを共有するグループプロジェクトの管理が簡単になります。setgid
をディレクトリーに適用すると、ディレクトリー内に作成されたファイルは、そのディレクトリーを所有するグループに自動的に割り当てられます。このグループ内の書き込みおよび実行権限があるユーザーは、対象のディレクトリーにファイルを作成、変更、および削除できるようになりました。
次のセクションでは、グループディレクトリーを作成する方法を説明します。
手順
ディレクトリーを作成します。
# mkdir directory-name
directory-name は、ディレクトリー名に置き換えます。
グループを作成します。
# groupadd group-name
group-name は、グループ名に置き換えます。
ユーザーをグループに追加します。
# usermod --append -G group-name username
group-name はグループ名に、username はユーザー名に置き換えます。
ディレクトリーのユーザーとグループの所有権は、group-name グループに関連付けます。
# chown :group-name directory-name
group-name はグループ名に、directory-name はディレクトリー名に置き換えます。
ファイルおよびディレクトリーを作成および修正し、
setgid
を設定してこの権限を directory-name ディレクトリー内で適用できるようにします。# chmod g+rwxs directory-name
directory-name は、ディレクトリー名に置き換えます。
group-name
グループのすべてのメンバーが、directory-name
ディレクトリーにファイルを作成し、編集できるようになりました。新規に作成されたファイルは、group-name
グループの所有権を保持します。
検証手順
パーミッション設定の正確性を検証するには、以下を使用します。
# ls -ld directory-name
directory-name は、ディレクトリー名に置き換えます。
返される出力は以下のとおりです。
drwxrwsr-x. 2 root group-name 6 Nov 25 08:45 directory-name
第7章 コマンドラインからのユーザーの削除
ユーザーが所属するグループを、削除するユーザーが含まれない新しいグループセットに上書きして、プライマリーグループまたは補助グループからユーザーを削除できます。
7.1. ユーザーのプライマリーグループの上書き
本セクションでは、usermod
コマンドを使用して、ユーザーのプライマリーグループを上書きする方法を説明します。
手順
ユーザーのプライマリーグループを上書きするには、以下のコマンドを使用します。
# usermod -g group-name username
group-name はグループ名に、username はユーザー名に置き換えます。
例
ユーザー
sarah
がプライマリーグループsarah1
に所属しており、ユーザーのプライマリーグループをsarah2
に変更する場合は、以下を使用します。# usermod -g sarah2 sarah
検証手順
ユーザーのプライマリーグループが上書きされていることを確認するには、以下を使用します。
# groups sarah
返される出力は以下のとおりです。
sarah : sarah2
7.2. ユーザーの補助グループの上書き
本セクションでは、usermod
コマンドを使用して、ユーザーの補助グループを上書きする方法を説明します。
手順
ユーザーの補助グループを上書きするには、以下のコマンドを使用します。
# usermod -G group-name username
group-name はグループ名に、username はユーザー名に置き換えます。
例
ユーザー
sarah
がsystem-administrator
グループおよびdeveloper
グループに所属しており、system-administrator
グループからユーザーsarah
を削除する場合は、古いグループ一覧を新しいものに置き換えてください。これを行うには、以下を使用します。# usermod -G developer sarah
検証手順
ユーザーの補助グループが上書きされていることを確認するには、以下を使用します。
# groups sarah
返される出力は以下のとおりです。
sarah : sarah developer
第8章 sudo アクセスの管理
システム管理者は、root 以外のユーザーが管理コマンドを実行できるように sudo
アクセスを付与できます。sudo
コマンドは、root
ユーザーのパスワードを使用せずに、管理アクセスを持つユーザーを提供する方法です。
ユーザーが管理コマンドを実行する必要がある場合には、コマンドの前に sudo
を指定してください。すると、そのコマンドは、root
ユーザーのように実行されます。
以下の制限事項に注意してください。
-
/etc/sudoers
設定ファイルに一覧表示されているユーザーのみがsudo
コマンドを使用できます。 -
コマンドは、
root
シェルではなく、ユーザーのシェルで実行されます。
8.1. ユーザーへの sudo アクセス権限の付与
root 以外のユーザーが管理コマンドを実行するには sudo アクセスが必要です。次のセクションでは、ユーザーに sudo
アクセスを付与する方法を説明します。
前提条件
-
root
アクセス
手順
/etc/sudoers
ファイルを開きます。# visudo
/etc/sudoers
ファイルは、sudo
コマンドで適用されるポリシーを定義します。/etc/sudoers
ファイルで、wheel
管理グループのユーザーにsudo
アクセスを付与する行を見つけます。## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL
-
%wheel
で始まる行に#
コメント文字が含まれていないことを確認してください。 - 変更を保存し、エディターを終了します。
sudo
アクセスを付与するユーザーを、wheel
管理グループに追加します。# usermod --append -G wheel username
username は、ユーザー名に置き換えます。
例
wheel
管理 グループにユーザーsarah
を追加するには、以下を使用します。# usermod --append -G wheel sarah
検証手順
ユーザーが
wheel
管理グループに追加されていることを確認するには、id
ユーティリティーを使用します。# id sarah
返される出力は以下のとおりです。
uid=5000(sarah) gid=5000(sarah) groups=5000(sarah),10(wheel)
第9章 root パスワードの変更およびリセット
既存の root パスワードが要件を満たさないか、パスワードを忘れた場合には、root
ユーザーおよび root 以外のユーザーの両方として、パスワードを変更またはリセットできます。
9.1. root ユーザーとしての root パスワードの変更
本セクションでは、passwd
コマンドを使用して、root
ユーザーで root
パスワードを変更する方法を説明します。
前提条件
-
root
アクセス
手順
root
パスワードを変更する場合は、次のコマンドを実行します。# passwd
変更する前に、現在のパスワードを入力するように求められます。
9.2. root 以外のユーザーが root パスワードを変更またはリセット
本セクションでは、passwd
コマンドを使用して、root 以外のユーザーで root
パスワードを変更またはリセットする方法を説明します。
前提条件
- root 以外のユーザーとしてログインできる。
-
wheel
管理グループのメンバーである。
手順
wheel
グループに属する root ユーザー以外のユーザーとしてroot
パスワードを変更またはリセットするには、以下を使用します。$ sudo passwd root
root
パスワードを変更する前に、root 以外のユーザーのパスワードを入力するように求められます。
9.3. システム起動時の root パスワードのリセット
root 以外のユーザーとしてログインできない場合や、wheel
管理グループに所属しない場合は、特別な chroot jail
環境に切り替えることで起動時に root パスワードをリセットできます。
手順
システムを再起動して、GRUB 2 ブート画面で
キーを押して、起動プロセスを中断します。カーネルブートパラメーターが表示されます。
load_video set gfx_payload=keep insmod gzio linux ($root)/vmlinuz-4.18.0-80.e18.x86_64 root=/dev/mapper/rhel-root ro crash\ kernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv/swap rhgb quiet initrd ($root)/initramfs-4.18.0-80.e18.x86_64.img $tuned_initrd
linux で始まる行の最後に移動します。
linux ($root)/vmlinuz-4.18.0-80.e18.x86_64 root=/dev/mapper/rhel-root ro crash\ kernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv/swap rhgb quiet
rd.break
をlinux
で始まる行の最後に追加します。linux ($root)/vmlinuz-4.18.0-80.e18.x86_64 root=/dev/mapper/rhel-root ro crash\ kernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv/swap rhgb quiet rd.break
switch_root
プロンプトが表示されます。ファイルシステムを書き込み可能で再マウントします。
mount -o remount,rw /sysroot
ファイルシステムは、
/sysroot
ディレクトリーに読み取り専用としてマウントされます。書き込み可能なファイルシステムとして再マウントすると、パスワードを変更できます。chroot
環境に入ります。chroot /sysroot
sh-4.4#
プロンプトが表示されます。root
パスワードをリセットします。passwd
コマンドラインに表示される指示に従って、
root
パスワードの変更を完了します。次回のシステム起動時に SELinux の再ラベルプロセスを有効にします。
touch /.autorelabel
chroot
環境を終了します。exit
switch_root
プロンプトを終了します。exit
- SELinux の再ラベルプロセスが終了するまで待機します。大規模なディスクの再ラベルには時間がかかる可能性があることに注意してください。プロセスが完了すると、システムが自動的に再起動します。
第10章 ファイル権限の管理
10.1. ファイルパーミッションの概要
すべてのファイルまたはディレクトリーには、以下のレベルの所有権があります。
- ユーザー所有者 (u)。
- グループの所有者 (g)。
- その他 (o)。
各所有権レベルには、以下のパーミッションを割り当てることができます。
- 読み取り (r)。
- 書き込み (w)。
- 実行 (x)。
ファイルの execute 権限があると、そのファイルを実行するできることに注意してください。ディレクトリーの実行権限では、ディレクトリーのコンテンツにアクセスできますが、実行はできません。
新規ファイルまたはディレクトリーが作成されると、デフォルトのパーミッションセットが自動的に割り当てられます。ファイルまたはディレクトリーのデフォルトパーミッションは、以下の要素に基づいています。
- 基本パーミッション。
- ユーザーのファイル作成モードマスク (umask)
10.1.1. 基本パーミッション
新規ファイルまたはディレクトリーが作成されるたびに、基本パーミッションが自動的に割り当てられます。
ファイルまたはディレクトリーの基本パーミッションは、シンボリック または 8 進数 の値で表すことができます。
パーミッション | シンボリック値 | 8 進数値 |
パーミッションなし | --- | 0 |
実行 | --x | 1 |
書き込み | -w- | 2 |
書き込みおよび実行 | -wx | 3 |
読み取り | r-- | 4 |
読み取りおよび実行 | r-x | 5 |
読み取りおよび書き込み | rw- | 6 |
読み取り、書き込み、実行 | rwx | 7 |
ディレクトリーの基本パーミッションは 777
(drwxrwxrwx
) で、すべてのユーザーに読み取り、書き込み、実行権限を付与します。つまり,ディレクトリーの所有者、グループ、その他のユーザーはディレクトリーのコンテンツ表示、そのディレクトリーでの項目の作成、削除、編集、サブディレクトリーへの移動が可能です。
ディレクトリー内の個別ファイルには、ディレクトリーに無制限にアクセスできるにも拘らず、編集ができない独自のパーミッションが割り当てられている可能性があります。
ファイルの基本パーミッションは 666
(-rw-rw-rw-
) で、すべてのユーザーに読み取りおよび書き込み権限を付与します。ファイルの所有者、グループ、その他のユーザーは、ファイルの読み取りと編集が可能です。
例 1
ファイルに以下のパーミッションがある場合:
$ ls -l
-rwxrw----. 1 sysadmins sysadmins 2 Mar 2 08:43 file
-
-
ファイルであることを示します。 -
rwx
は、ファイルの所有者にファイルの読み取り、書き込み、実行のパーミッションがあることを示します。 -
rw-
は、グループに読み取りと書き込みのパーミッションがあるが、ファイルの実行はできません。 -
---
は、他のユーザーにファイルの読み取り、書き込み、実行のパーミッションがないことを示します。 -
.
は、SELinux セキュリティーコンテキストがファイルに設定されていることを示しています。
例 2
ディレクトリーに以下のパーミッションがある場合:
$ ls -dl
drwxr-----. 1 sysadmins sysadmins 2 Mar 2 08:43 directory
-
d
は、ディレクトリーであることを示します。 rwx
は、ディレクトリーの所有者にディレクトリーの内容を読み取り、書き込み、およびアクセスするパーミッションがあることを示します。ディレクトリーの所有者は、ディレクトリー内のアイテム (ファイル、サブディレクトリー) を表示して、アイテムのコンテンツへのアクセスや変更が可能です。
r--
は、グループに読み取りのパーミッションがあるが、ディレクトリーのコンテンツへの書き込みやアクセスはできないことを示します。ディレクトリーを所有するグループのメンバーは、ディレクトリー内の項目を表示できます。ディレクトリー内のアイテムに関する情報にアクセスしたり、変更したりすることはできません。
---
は、他のユーザーがディレクトリーの内容の読み取り、書き込み、またはアクセスパーミッションがないことを示します。ディレクトリーのユーザー所有者またはグループ所有者ではない場合に、そのディレクトリーのアイテムを表示したり、アイテムの情報にアクセスしたり、変更したりできません。
-
.
は、SELinux セキュリティーコンテキストがディレクトリーに設定されていることを示しています。
ファイルまたはディレクトリーに自動的に割り当てられる基本パーミッションは、最終的にファイルまたはディレクトリーに指定されるデフォルトのパーミッション ではありません。ファイルまたはディレクトリーを作成すると、umask により基本パーミッションが変更されます。基本パーミッションと umask の組み合わせにより、ファイルおよびディレクトリーのデフォルトパーミッションが作成されます。
10.1.2. ユーザーのファイル作成モードマスク
umask は、linux システムの全体のセキュリティーを強化するために、ファイルまたはディレクトリーが作成されると、基本パーミッション値からパーミッションを自動的に削除する変数です。
umask は、シンボリック または 8 進法 で表すことができます。
パーミッション | シンボリック値 | 8 進数値 |
読み取り、書き込み、実行 | rwx | 0 |
読み取りおよび書き込み | rw- | 1 |
読み取りおよび実行 | r-x | 2 |
読み取り | r-- | 3 |
書き込みおよび実行 | -wx | 4 |
書き込み | -w- | 5 |
実行 | --x | 6 |
権限なし | --- | 7 |
標準ユーザーのデフォルトの umask は 0002
です。root
ユーザーのデフォルトの umask は 0022
です。
umask の最初の数字は、特別なパーミッション (スティッキービット) を表します。umask の最後の 3 桁はユーザーの所有者 (u)、グループの所有者 (g) およびその他 (o) からそれぞれ削除したパーミッションを表します。
例
以下の例では、umask の 8 進数値 0137
が基本パーミッション 777
に適用され、デフォルトパーミッション 640
のファイルが作成されます。
図10.1 ファイルの作成時に umask を適用

10.1.3. デフォルトの権限
新しいファイルまたはディレクトリーのデフォルトパーミッションは、umask を基本パーミッションに適用して決定されます。
例 1
標準ユーザー が新しい ディレクトリー を作成すると、umask は 002
(rwxrwxr-x
) に、ディレクトリーの基本パーミッションは 777
(rwxrwxrwx
) に設定されます。これでデフォルトのパーミッションが 775
(drwxrwxr-x
) になります。
シンボリック値 | 8 進数値 | |
基本パーミッション | rwxrwxrwx | 777 |
Umask | rwxrwxr-x | 002 |
デフォルトパーミッション | rwxrwxr-x | 775 |
このパーミッションでは、ディレクトリーの所有者とグループはディレクトリーのコンテンツの表示、ディレクトリーでのアイテムの作成、削除、編集、サブディレクトリーへの移動が可能です。他のユーザーはディレクトリーの内容を表示して、サブディレクトリーに移動することしかできません。
例 2
標準ユーザー が新しい ファイル を作成すると、umask は 002
(rwxrwxr-x
) に、ファイルの基本パーミッションは 666
(rw-rw-rw-
) に設定されます。これにより、デフォルトのパーミッション 664
(-rw-rw-r--
) になります。
シンボリック値 | 8 進数値 | |
基本パーミッション | rw-rw-rw- | 666 |
Umask | rwxrwxr-x | 002 |
デフォルトパーミッション | rw-rw-r-- | 664 |
このパーミッションでは、ファイルの所有者とグループはファイルの読み取りと編集が可能ですが、他のユーザーはこのファイルの読み取りしかできません。
例 3
root ユーザー が新規 ディレクトリー を作成すると、umask は 022
(rwxr-xr-x
) に、ディレクトリーの基本パーミッションは 777
(rwxrwxrwx
) に設定されます。これにより、デフォルトのパーミッションが 755
(rwxr-xr-x
) になります。
シンボリック値 | 8 進数値 | |
基本パーミッション | rwxrwxrwx | 777 |
Umask | rwxr-xr-x | 022 |
デフォルトパーミッション | rwxr-xr-x | 755 |
このパーミッションでは、ディレクトリーの所有者はディレクトリーの内容の表示、ディレクトリー内のアイテムの作成、削除、編集、サブディレクトリーへの移動が可能です。グループとその他のユーザーは、ディレクトリーの内容の表示とサブディレクトリーの移動のみが可能です。
例 4
root ユーザー が新しい ファイル を作成すると、umask は 022
(rwxr-xr-x
) に、ファイルの基本パーミッションは 666
(rw-rw-rw-
) に設定されます。これにより、デフォルトのパーミッションが 644
(-rw-r—r--
) になります。
シンボリック値 | 8 進数値 | |
基本パーミッション | rw-rw-rw- | 666 |
Umask | rwxr-xr-x | 022 |
デフォルトパーミッション | rw-r—r-- | 644 |
このパーミッションでは、ファイルの所有者はファイルを読み取りと編集が可能ですが、グループや他のユーザーはこのファイルの読み取りのみが可能です。
セキュリティー上の理由から、通常のファイルに umask が 000
(rwxrwxrwx
) に設定されていても、デフォルトで実行権限がありません。ただし、ディレクトリーは実行権限を持つ状態で作成できます。
10.2. ファイル権限の表示
次のセクションでは、ls
コマンドを使用して、ディレクトリー内のディレクトリー、ファイル、ファイルのパーミッションを表示する方法を説明します。
手順
特定のディレクトリーのパーミッションを表示するには、以下を使用します。
$ ls -dl directory-name
directory-name は、ディレクトリー名に置き換えます。
特定のディレクトリーおよびそのディレクトリー内のすべてのファイルのパーミッションを表示するには、以下を使用します。
$ ls -l directory-name
directory-name は、ディレクトリー名に置き換えます。
特定のファイルのパーミッションを表示するには、以下を使用します。
$ ls -l file-name
file-name は、ファイルの名前に置き換えます。
関連情報
-
詳細は、
ls
の man ページを参照してください。
10.3. ファイル権限の変更
次のセクションでは、以下を行う方法を説明します。
- シンボリック値を使用してファイルのパーミッションを変更します。
- 8 進数値を使用してファイル権限を変更します。
10.3.1. シンボリック値を使用したファイル権限の変更
以下のパーミッションを割り当てることができます。
- 読み取り (r)。
- 書き込み (w)。
- 実行 (x)。
パーミッションは以下に割り当てることができます。
- ユーザー所有者 (u)。
- グループの所有者 (g)。
- その他 (o)。
- すべて (a)。
パーミッションを追加または取り除くには、以下の記号を使用できます。
-
+
: 既存のパーミッションの上にパーミッションを追加します。 -
-
: 既存のパーミッションからパーミッションを取り除きます。 -
=
: 既存のパーミッションを省略し、新規パーミッションを明示的に定義します。
次のセクションでは、シンボリック値を使用してファイルのパーミッションの設定および削除の方法を説明します。
手順
既存のファイルまたはディレクトリーのファイル権限を変更するには、以下を使用します。
$ chmod u=symbolic_value,g+symbolic_value,o-symbolic_value file-name
file-name は、ファイルまたはディレクトリーの名前に、ユーザー、グループ、およびその他の symbolic_value は、対応するシンボリック値に置き換えます。詳細は「基本パーミッション」を参照してください。
例
my-file.txt
のファイルパーミッションを664
(-rw-rw-r--
) から740
(-rwx-r---
) に変更するには、以下を使用します。$ chmod u+x,g-w,o= my-file.txt
パーミッションを等号 (
=
) の後ろに指定していない場合には自動的に無視される点に注意してください。ユーザー、グループなどに同じパーミッションを設定するには、以下を使用します。
$ chmod a=symbolic_value file-name
file-name は、ファイルまたはディレクトリーの名前に、symbolic_value はシンボリック値に置き換えます。詳細は「基本パーミッション」を参照してください。
例
my-file.txt
のパーミッションを777
(-rwxrwxrwx
またはdrwxrwxrwx
) に設定するには、以下を使用します。$ chmod a=rwx my-file
ディレクトリーとそのサブディレクトリーのパーミッションをすべて変更するには、
-R
オプションを追加します。$ chmod -R symbolic_value directory-name
directory-name はディレクトリーの名前に、symbolic_value はシンボリック値に置き換えます。詳細は「基本パーミッション」を参照してください。
例
/my-directory/
とそのすべてのサブディレクトリーのパーミッションを775
(drwxrwxr-x
) から740
(drwx-r---
) に変更するには、以下を使用します。$ chmod -R g-wx,o= /my-directory
10.3.2. 8 進数値を使用したファイル権限の変更
次のセクションでは、chmod
コマンドを使用して、ファイルまたはディレクトリーのパーミッションを変更する方法を説明します。
手順
既存のファイルまたはディレクトリーのファイル権限を変更するには、以下を使用します。
$ chmod octal_value file-name
file-name はファイルまたはディレクトリーの名前に、octal_value は 8 進数値に置き換えます。詳細は「基本パーミッション」を参照してください。
10.4. umask の表示
次のセクションでは、以下を行う方法を説明します。
- umask の現在の 8 進数値を表示します。
- umask の現在のシンボリック値を表示します。
- デフォルトの bash の umask を表示します。
10.4.1. umask の現在の 8 進数値の表示
次のセクションでは、umask
コマンドを使用して、現在の umask を表示する方法を説明します。
手順
標準ユーザーの umask の現在の 8 進値を表示するには、以下のコマンドを使用します。
$ umask
root
ユーザーの umask の現在の 8 進値を表示するには、以下のコマンドを使用します。$ sudo umask
または
# umask
umask
の表示時に、4 桁の数字 (0002
または 0022
) で表示される場合があります。umask の最初の数字は、特殊ビット (スティッキービット、SGID ビット、または SUID ビット) を表します。最初の数字を 0
に設定すると、特別なビットは設定されません。
10.4.2. umask の現在のシンボリック値の表示
次のセクションでは、umask
コマンドを使用して、現在の umask を表示する方法を説明します。
手順
umask の現在のシンボリック値を表示するには、以下のコマンドを使用します。
$ umask -S
root
ユーザーの umask の現在のシンボリック値を表示するには、以下のコマンドを使用します。$ sudo umask -S
または
# umask -S
10.4.3. デフォルトの bash umask の表示
bash
、ksh
、zsh
、tcsh
などの多くのシェルを使用できます。
これらのシェルはログインまたは nologin シェルとして動作します。ログインシェルは通常、ネイティブまたは GUI ターミナルを開いて起動します。
ログインシェルまたは nologin シェルのどちらでコマンドを実行しているかを確認するには、echo $0
コマンドを使用します。
bash
シェルの出力で bash
が返されると、nologin シェルでコマンドを実行しています。
$ echo $0 bash
nologin シェルのデフォルトの umask は、/etc/bashrc
設定ファイルで設定します。
出力で -bash
が返されると、ログインシェルでコマンドを実行していることになります。
# echo $0 -bash
ログインシェルのデフォルトの umask は /etc/profile
設定ファイルで設定します。
手順
nologin シェルのデフォルトの
bash
umask を表示するには、以下のコマンドを使用します。$ grep umask /etc/bashrc
返される出力は以下のとおりです。
# By default, we want umask to get set. This sets it for non-login shell. umask 002 umask 022
ログインシェルのデフォルトの
bash
umask を表示するには、以下のコマンドを使用します。$ grep umask /etc/profile
返される出力は以下のとおりです。
# By default, we want umask to get set. This sets it for login shell umask 002 umask 022
10.5. 現在のシェルセッションの umask 設定
次のセクションでは、現在のシェルセッションに umask を設定する方法を説明します。
- シンボリック値の使用。
- 8 進数値の使用。
umask は、現行シェルセッションでのみ有効で、セッションの完了後にデフォルトの umask に戻ります。
10.5.1. シンボリック値を使用した umask の設定
次のセクションでは、umask をシンボリック値で設定する方法を説明します。
手順
現在のシェルセッションのパーミッションを設定または削除するには、マイナス (
-
)、プラス (+
)、および等号 (=
)をシンボリック値と組み合わせて使用できます。$ umask -S u=symbolic_value,g+symbolic_value,o-symbolic_value
ユーザー、グループ、およびその他の symbolic_value は、シンボリック値に置き換えます。詳細は「ユーザーのファイル作成モードマスク」を参照してください。
例
現在の umask が
113
(u=rw-,g=rw-,o=r--
) に設定されていて、037
(u=rwx,g=-r-,o=---
) に設定する場合は、以下を使用します。$ umask -S u+x,g-w,o=
パーミッションを等号 (
=
) の後ろに指定していない場合には自動的に無視される点に注意してください。ユーザー、グループなどに同じパーミッションを設定するには、以下を使用します。
$ umask a=symbolic_value
symbolic_value は、シンボリック値に置き換えます。詳細は「ユーザーのファイル作成モードマスク」を参照してください。
例
umask を
000
(u=rwx,g=rwx,o=rwx
) に設定するには、以下を使用します。$ umask a=rwx
umask は、現在のシェルセッションにのみ有効であることに注意してください。
10.5.2. 8 進数値を使用した umask の設定
次のセクションでは、8 進数値で umask を設定する方法を説明します。
手順
8 進数値を使用して、現在のシェルセッションの umask を設定するには、以下のコマンドを使用します。
$ umask octal_value
octal_value は 8 進数値に置き換えます。詳細は「ユーザーのファイル作成モードマスク」を参照してください。
umask は、現在のシェルセッションにのみ有効であることに注意してください。
10.6. デフォルトの umask の変更
次のセクションでは、以下を行う方法を説明します。
- nologin シェルのデフォルトの bash umask を変更します。
- ログインシェルのデフォルトの bash umask を変更します。
- 特定ユーザーのデフォルトの bash umask を変更します。
- 新規作成されたホームディレクトリーのデフォルト権限を設定します。
前提条件
-
root
アクセス
10.6.1. nologin シェルのデフォルト umask の変更
次のセクションでは、標準ユーザーのデフォルトの bash
umask を変更する方法を説明します。
手順
-
root
として、任意のエディターで/etc/bashrc
ファイルを開きます。 以下のセクションを変更して、新しいデフォルトの bash umask を設定します。
if [ $UID -gt 199 ] && [ “id -gn” = “id -un” ]; then umask 002 else umask 022 fi
umask (
002
) のデフォルト値を別の進数値に置き換えます。詳細は「ユーザーのファイル作成モードマスク」を参照してください。- 変更を保存します。
10.6.2. ログインシェルのデフォルト umask の変更
次のセクションでは、root
ユーザーのデフォルトの bash
umask を変更する方法を説明します。
手順
-
root
として、任意のエディターで/etc/profile
ファイルを開きます。 以下のセクションを変更して、新しいデフォルトの bash umask を設定します。
if [ $UID -gt 199 ] && [ “/usr/bin/id -gn” = “/usr/bin/id -un” ]; then umask 002 else umask 022 fi
umask (
022
) のデフォルト値を別の 8 進数値に置き換えます。詳細は「ユーザーのファイル作成モードマスク」を参照してください。- 変更を保存します。
10.6.3. 特定ユーザーのデフォルトの umask の変更
次のセクションでは、特定ユーザーのデフォルトの umask を変更する方法を説明します。
手順
umask の 8 進値を指定する行は、特定のユーザーの
.bashrc
ファイルに組み込みます。$ echo 'umask octal_value' >> /home/username/.bashrc
octal_value は 8 進数値に、username はユーザー名に置き換えます。詳細は「ユーザーのファイル作成モードマスク」を参照してください。
10.6.4. 新規作成したホームディレクトリーのデフォルト UMASK の設定
次のセクションでは、新規作成したユーザーのホームディレクトリーでの UMASK を指定するパーミッションを変更する方法を説明します。
手順
-
root
として、任意のエディターで/etc/login.defs
ファイルを開きます。 以下のセクションを変更して、UMASK のデフォルトを新規設定します。
# The permission mask is initialized to this value. If not specified, # the permission mask will be initialized to 022. UMASK 077
デフォルトの 8 進数値 (
077
) を別の 8 進数値に置き換えます。詳細は「ユーザーのファイル作成モードマスク」を参照してください。- 変更を保存します。
10.7. アクセス制御リスト
従来は、各ファイルおよびディレクトリーには、ユーザー所有者とグループ所有者を一度に指定できます。ファイルやディレクトリーの所有権とパーミッションを変更せずに、より具体的なパーミッションをファイルやディレクトリーに適用する場合には (グループ外の特定のユーザーがディレクトリー内の特定のファイルにアクセスでき、それ以外のファイルにはアクセスできないようにする)、アクセス制御リスト (ACL) を使用できます。
次のセクションでは、以下を行う方法を説明します。
- 現在の ACL を表示します。
- ACL を設定します。
10.7.1. 現在の ACL の表示
次のセクションでは、現在の ACL を表示する方法を説明します。
手順
特定のファイルまたはディレクトリーの現在の ACL を表示するには、以下を使用します。
$ getfacl file-name
file-name は、ファイルまたはディレクトリーの名前に置き換えます。
10.7.2. ACL の設定
次のセクションでは、ACL を設定する方法を説明します。
前提条件
-
root
アクセス
手順
- ファイルまたはディレクトリーに ACL を設定するには、以下を使用します。
# setfacl -m u:username:symbolic_value file-name
username
はユーザー名に、symbolic_value はシンボリック値に、file-name はファイルまたはディレクトリーの名前に置き換えます。詳細は、 setfacl
の man ページを参照してください。
例
以下の例では、root
グループに所属する root
ユーザーが所有する group-project
ファイルのパーミッションを修正する方法を説明します。このファイルは以下のようになります。
- 誰にも実行権限はありません。
-
ユーザー
andrew
にはrw-
のパーミッションがあります。 -
susan
ユーザーには---
のパーミッションがあります。 -
他のユーザーには
r--
のパーミッションがあります。
手順
# setfacl -m u:andrew:rw- group-project # setfacl -m u:susan:--- group-project
検証手順
ユーザー
andrew
にrw-
パーミッションがあり、ユーザーsusan
には---
パーミッションがあり、その他のユーザーにr--
パーミッションがあることを確認するには、以下を実行します。$ getfacl group-project
返される出力は以下のとおりです。
# file: group-project # owner: root # group: root user:andrew:rw- user:susan:--- group::r-- mask::rw- other::r--
第11章 Chrony スイートを使用した NTP の設定
11.1. chrony を使用した NTP の設定の概要
IT では、さまざまな理由で正確な時間の維持が重要です。たとえばネットワーキングでは、パケットとログのタイムスタンプが正確であることが必要になります。Linux システムでは、NTP
プロトコルがユーザー領域で実行しているデーモンにより実装されます。
ユーザー領域のデーモンは、カーネルで実行しているシステムクロックを更新します。システムクロックは、さまざまなクロックソースを使用して時間を維持します。一般的に使用されるのは Time Stamp Counter (TSC) です。TSC は、最後にリセットされた時点からのサイクル数を計測する CPU レジスターです。非常に高速でハイレゾリューションであり、中断も発生しません。
Red Hat Enterprise Linux 8 では、NTP
プロトコルは chronyd
デーモンにより実装されます。このデーモンは、chrony
パッケージのリポジトリーから利用できます。
本セクションは、chrony スイートの使用を説明します。
11.2. chrony スイートの概要
chrony は Network Time Protocol (NTP)
の実装です。chrony を使用すると、以下のことができます。
-
システムクロックを、
NTP
サーバーと同期する - システムクロックを、GPS レシーバーなどの基準クロックと同期する
- システムクロックを、手動で入力した時間と同期する
-
ネットワーク内の他のコンピューターにタイムサービスを提供する
NTPv4(RFC 5905)
サーバーまたはピアとして
chrony は、ネットワーク接続が頻繁に切断される、ネットワークの混雑が長時間続く、温度が変わる (一般的なコンピューターのクロックは温度に敏感) といったさまざまな状況や、継続して実行されない、または仮想マシンで実行されているといったシステムにおいても、良好に動作します。
インターネット上で同期している 2 つのマシン間の一般的精度は数ミリ秒以内、LAN 上のマシン間では数十マイクロ秒以内です。ハードウェアのタイムスタンプまたはハードウェア基準クロックは、同期している 2 つのマシン間の精度をサブマイクロ秒レベルにまで高めることができます。
chrony は、ユーザー領域で実行する chronyd
と、chronyd
のパフォーマンスを監視し、実行時にさまざまなオペレーティングパラメーターを変更するのに使用できるコマンドラインプログラムである chronyc で構成されます。
chrony デーモンである chronyd
は、コマンドラインユーティリティーの chronyc を使用して監視と管理を行います。このユーティリティーは、chronyd
の現在の状態に対してクエリーを実行し、その設定を変更する多数のコマンド入力を可能にするコマンドプロンプトを提供します。デフォルトでは、chronyd
は chronyc のローカルインスタンスのコマンドのみを受け付けますが、リモートホストから監視コマンドを受け付けるように設定することも可能です。リモートアクセスは制限する必要があります。
11.2.1. chronyc を使用した chronyd の制御
対話モードでコマンドラインユーティリティー chronyc を使用して、chronyd
のローカルインスタンスを変更するには、root
で以下のコマンドを実行します。
# chronyc
制限されているコマンドを使用する場合は、root
で chronyc を実行する必要があります。
以下のように、chronyc コマンドプロンプトが表示されます。
chronyc>
このコマンドの一覧を表示するには、help
と入力します。
このユーティリティーは、以下のようなコマンドで呼び出すと、非対話型コマンドモードで呼び出すこともできます。
chronyc command
chronyc を使用して変更した内容は永続的ではなく、chronyd
を再起動すると元に戻ります。永続的に変更する場合は、/etc/chrony.conf
を変更してください。
11.3. chrony と ntp の相違点
Network Time Protocol (NTP)
には、基本的な機能が似ている 2 つの実装 (ntp と chrony) があります。
ntp と chrony のいずれも、NTP
サーバーにシステムクロックを同期させる NTP
クライアントとして動作したり、ネットワーク上の別のコンピューターに対する NTP
サーバーとして動作できます。各実装には、固有の機能があります。ntp および chrony の比較は「Comparison of NTP implementations」を参照してください。
NTP
クライアントに固有の設定は、ほとんどの場合同じです。NTP
サーバーは、server
ディレクティブで指定します。サーバーのプールは、pool
ディレクティブで指定します。
NTP
サーバーに固有の設定は、クライアントアクセスの制御方法により異なります。デフォルトでは、ntpd
は任意のアドレスからクライアントリクエストに応答します。このアクセスは restrict
ディレクティブで制御できますが、ntpd
が任意のサーバーをクライアントとして使用している場合は、アクセスを完全に無効にできません。chronyd
は、デフォルトではいずれのアクセスも許可せず、NTP
クライアントとして動作します。chrony を NTP
サーバーとして動作させるようにするには、allow
ディレクティブでいくつかのアドレスを指定する必要があります。
ntpd
と chronyd
は、システムクロックの修正に対するデフォルト動作も異なります。ntpd
は、オフセットが 128 ミリ秒より大きい場合に、step でクロックを修正します。オフセットが 1000 秒よりも大きい場合は、これがクロックの最初の修正でない場合は ntpd
が終了し、-g
オプションで ntpd
が起動します。chronyd
は、デフォルトでクロックを一気に修正する (step) ことはしませんが、chrony
パッケージで提供されているデフォルトの chrony.conf
ファイルでは、クロックの最初の 3 つの更新で step を許可します。その後の修正はすべて、クロックの速度を速めるか遅らせて徐々に修正します。chronyc makestep
コマンドを実行すれば、chronyd
によりクロックを強制的に step できます。
11.4. chrony への移行
Red Hat Enterprise Linux 7 では、正確な時間管理を行う方法として、ntp または chrony を選択できます。ntp と chrony の相違点、ntpd
と chronyd
の相違点は、「ntpd と chronyd の違い」を参照してください。
Red Hat Enterprise Linux 8 では ntp がサポートされなくなりました。デフォルトで chrony が有効になります。このため、ntp から chrony への移行が必要になる場合があります。
ntp から chrony への移行は、ほとんどの場合簡単です。プログラムの、設定ファイル、およびサービスに対応する名前は、次のとおりです。
表11.1 ntp から chrony へ移行する際に、プログラム、設定ファイル、サービスに対応する名前
ntp の名前 | chrony の名前 |
---|---|
/etc/ntp.conf | /etc/chrony.conf |
/etc/ntp/keys | /etc/chrony.keys |
ntpd | chronyd |
ntpq | chronyc |
ntpd.service | chronyd.service |
ntp-wait.service | chrony-wait.service |
ntpdate ユーティリティーおよび sntp ユーティリティーは ntp
ディストリビューションに含まれていますが、-q
オプションまたは -t
オプションを使用して chronyd
に置き換えることができます。この設定は、/etc/chrony.conf
を読み込まないようにコマンドラインで指定できます。たとえば、ntpdate ntp.example.com
を実行する代わりに、以下のように chronyd
を起動できます。
# chronyd -q 'server ntp.example.com iburst' 2018-05-18T12:37:43Z chronyd version 3.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 +DEBUG) 2018-05-18T12:37:43Z Initial frequency -2.630 ppm 2018-05-18T12:37:48Z System clock wrong by 0.003159 seconds (step) 2018-05-18T12:37:48Z chronyd exiting
ntpstat ユーティリティーは、ntp
パッケージに含まれていましたが、ntpd
だけをサポートしていました。現在は、ntpd
と chronyd
の両方をサポートします。これは、ntpstat
パッケージで入手できます。
11.4.1. 移行スクリプト
chrony
パッケージのドキュメント (/usr/share/doc/chrony
) には、ntp2chrony.py
という名前の Python スクリプトがあります。このスクリプトは、既存の ntp
設定を chrony
に自動的に変換します。ntp.conf
ファイルで最も一般的なディレクティブおよびオプションがサポートされます。変換で無視されている行はすべて、確認のために、生成された chrony.conf
ファイルにコメントとして追加されます。ntp
鍵ファイルに指定し、ntp.conf
で信頼される鍵としてマークされていない鍵は、生成された chrony.keys
ファイルにコメントとして追加されます。
デフォルトでは、スクリプトはいずれのファイルも上書きしません。/etc/chrony.conf
または /etc/chrony.keys
が存在する場合は、-b
オプションを使用してファイルの名前を変更すれば、バックアップとして使用できます。このスクリプトはその他のオプションもサポートします。--help
オプションを使用すると、サポートされるすべてのオプションが表示されます。
ntp
パッケージで提供されるデフォルトの ntp.conf
を使用したスクリプトの呼び出し例は以下のようになります。
# python3 /usr/share/doc/chrony/ntp2chrony.py -b -v Reading /etc/ntp.conf Reading /etc/ntp/crypto/pw Reading /etc/ntp/keys Writing /etc/chrony.conf Writing /etc/chrony.keys
この場合に無視される唯一のディレクティブは disable monitor
です。これは、noclientlog
ディレクティブで chrony に相当するものがありますが、アンプ攻撃を軽減するためだけに、デフォルトの ntp.conf
に含まれていました。
生成した chrony.conf
ファイルには、通常、ntp.conf
の制御行に対応する allow
ディレクティブが多数含まれています。chronyd
を NTP
サーバーとして実行しない場合は、allow
ディレクティブをすべて chrony.conf
から削除します。
11.4.2. Timesync ロール
Red Hat Enterprise Linux 7 システムで timesync ロール を使用すると、システムが ntp または chrony を使用して NTP プロトコルを実装するかどうかにかかわらず、RHEL 6 以降のすべてのバージョンの RHEL で同じ Playbook を使用できるため、chrony への移行が容易になります。
関連情報
-
timesync
ロール変数の詳細は、rhel-system-roles
パッケージをインストールし、/usr/share/doc/rhel-system-roles/timesync
ディレクトリーのREADME.md
またはREADME.html
ファイルを参照してください。 - RHEL システムロールの詳細は、「RHEL のシステムロールの概要」 を参照してください。
11.5. chrony の設定
chronyd
のデフォルト設定ファイルは /etc/chrony.conf
です。-f
オプションは、代替の設定ファイルパスを指定するのに使用できます。詳細は man ページの chrony.conf(5)
を参照してください。使用できるディレクティブの一覧は「The chronyd configuration file」を参照してください。
以下は、chronyd
設定オプションの一部です。
- コメント
- コメントの前には、#、%、;、または ! を付けます。
- allow
必要に応じて、
NTP
サーバーとして動作しているマシンへのNTP
接続が許可されるホスト、サブネット、またはネットワークを指定します。デフォルトでは、接続は許可されません。以下に例を示します。
allow 192.0.2.0/24
特定のネットワークへのアクセスを許可するときにこのコマンドを使用します。
allow 2001:0db8:85a3::8a2e:0370:7334
このコマンドを使用して、IPv6
へのアクセスを付与します。
クライアントアクセスを可能にするため、ファイアウォールで UDP ポート番号 123 を開いておく必要があります。
# firewall-cmd --zone=public --add-port=123/udp
ポート 123 を永続的に開くには、--permanent
オプションを使用します。
# firewall-cmd --permanent --zone=public --add-port=123/udp
- cmdallow
-
allow
ディレクティブ (allow
セクションを参照) と似ていますが、特定のサブセットまたはホストへの制御アクセスを許可します (これはNTP
クライアントアクセスとは異なります)。「制御アクセス」とは、chronyc がこのようなホストで実行可能であり、このコンピューターでchronyd
に正常に接続できることを意味します。 構文は同じになります。また、cmdallow all
ディレクティブと動作が似ているcmddeny all
もあります。 - dumpdir
-
chronyd
を再起動しても測定履歴を保存するディレクトリーへのパスです (これが実行していない時にシステムクロックの動作が変更されていないことを想定しています)。(設定ファイルのdumponexit
コマンド、chronyc のdump
コマンドから) この機能を使用する場合は、dumpdir
コマンドを使用して測定履歴を保存するディレクトリーを定義してください。 - dumponexit
-
このコマンドが存在する場合は、プログラムの終了時に、
chronyd
が、常に記録された各時間ソースの測定履歴を保存することを示しています。上記のdumpdir
コマンドを参照してください。 - hwtimestamp
-
hwtimestamp
ディレクティブは、ハードウェアのタイムスタンプで非常に精度の高い同期を可能にします。詳細は man ページのchrony.conf(5)
を参照してください。 - local
local
キーワードは、現在の同期ソースがない場合でも、(それをポーリングしているクライアントから見ると)chronyd
がリアルタイムに同期しているように見えるようにします。このオプションは、通常、孤立したネットワークで「master」となるコンピューターで使用されます。ここでは、いくつかのコンピューターが相互に同期するようになり、「master」は、手動入力でリアルタイムと一致させます。以下はコマンド例を示します。
local stratum 10
10 という大きな値が示しているのは「基準クロックからのホップ数が非常に多いため、時間の信頼性が低い」ということです。基準クロックに最終的に同期している別のコンピューターにアクセスするコンピューターは、確実に 10 よりも下の階層に存在することになります。このため、
local
コマンドで 10 のように高い値を設定すると、リアルサーバーの視認性があるクライアントにリークしたとしても、マシン自体の時間がリアルタイムと混同することを防ぎます。- log
log
コマンドは、特定情報がログに記録されることを意味します。以下のオプションを取ります。- measurements
-
このオプションは、生の
NTP
測定値とその関連情報を、measurements.log
という名前のログファイルに記録します。 - statistics
-
このオプションは、回帰処理の情報を
statistics.log
ファイルにログ記録します。 - tracking
-
このオプションは、システムの時間が進んだり遅れたりする予測に対する変更や、発生した slew 調整を、
tracking.log
と呼ばれるファイルにログ記録します。 - rtc
- このオプションは、システムのリアルタイムクロックに関する情報をログ記録します。
- refclocks
-
このオプションは、生およびフィルター処理された基準クロックの測定を、
refclocks.log
ファイルにログ記録します。 - tempcomp
このオプションは、温度測定とシステムレートの補正を、
tempcomp.log
と呼ばれるファイルにログ記録します。ログファイルは、
logdir
コマンドが指定するディレクトリーに書き込まれます。以下はコマンド例を示します。
log measurements statistics tracking
- logdir
このディレクティブは、ログファイルが書き込まれるディレクトリーを指定します。
このディレクティブの使用例は、以下のようになります。
logdir /var/log/chrony
- makestep
通常、
chronyd
は、必要に応じてクロックの速度を下げるかまたは上げることで、システムに対して時間オフセットの段階的修正を実施します。特定の状況では、このスルーイング (slewing) プロセスでシステムクロックを修正するのに非常に時間がかかり、システムクロックが不安定な状態になることがあります。このディレクティブは、調整がしきい値を上回ったときに、chronyd
でシステムクロックを一度に修正 (step) します。ただし、chronyd
が開始してからのクロックの更新が、指定した制限を上回らなかった場合に限ります (負の値は、制限を無効にします)。initstepslew
ディレクティブはNTP
のソースのみに対応しているため、この方法は基準クロックを使用しているときに特に有用です。このディレクティブの使用例は、以下のようになります。
makestep 1000 10
この場合は、調整幅が 1000 秒よりも大きければシステムクロックが更新されますが、最初の 10 回の更新しか行われません。
- maxchange
このディレクティブは、クロック更新で修正される許容オフセットの最大値を設定します。更新が指定された回数行われた後にのみチェックが実行されるため、システムクロックの初回の調整が大きくなります。指定された最大値よりも大きなオフセットが発生すると、そのオフセットは指定した回数の間無視され、その後に
chronyd
が終了します (負の値を使用すると、終了しないようになります)。いずれの場合も、メッセージは syslog に送信されます。このディレクティブの使用例は、以下のようになります。
maxchange 1000 1 2
最初のクロック更新後に、
chronyd
がすべてのクロック更新でオフセットをチェックし、1000 秒よりも大きい調整を 2 回無視して、3 回目に終了します。- maxupdateskew
chronyd
のタスクの 1 つは、コンピュータのクロックがその基準源に対してどれくらい速くまたは遅く動くかを調べることです。また、推定値の誤差範囲の概算を計算します。エラーの範囲が広すぎる場合は、測定が落ち着いていないこと、そして推定増加または損失率に信頼性があまりないことを示しています。
maxupdateskew
パラメーターは、推定値を使用できるほど信頼できるかどうかを判定するためのしきい値です。デフォルトでは、しきい値は 1000 ppm です。構文は以下のようになります。
maxupdateskew skew-in-ppm
skew-in-ppm の一般的な値は、電話回線を介してサーバーにダイアルアップ接続を行う場合は 100、LAN 上のコンピューターの場合は 5 または 10 になります。
信頼性のない推定値の使用に対する保護の方法は、これだけではないことに注意してください。
chronyd
は常に、予想される進みまたは遅れのレートと、予測のエラー範囲を追跡しています。ソースの 1 つで測定が作成された後に別の予測が新たに生成されると、加重組み合わせのアルゴリズムを使用してマスター予測が更新されます。このため、chronyd
に信頼性の高い既存のマスター予測があり、エラー範囲の広い新たな予測が生成されると、既存のマスター予測が新規のマスター予測を特徴づけることになります。- minsources
minsources
ディレクティブは、ローカルクロックを更新する前にソース選択アルゴリズムで選択可能なものとして考慮されるべきソースの最小数を設定します。構文は以下のようになります。
minsources number-of-sources
number-of-sources は、デフォルトでは 1 です。minsource を 1 よりも大きくすると、信頼性が向上します。複数のソースが互いに対応することが必要となるためです。
- noclientlog
-
引数を取らないこのディレクティブは、クライアントアクセスをログに記録しないことを指定します。通常はログに記録されますが、chronyc でクライアントコマンドを使用して統計を報告し、クライアントが
server
ディレクティブのxleave
オプションでインターリーブモードを使用するようにできます。 - reselectdist
chronyd
が、利用可能なソースから同期ソースを選択する際に、同期距離が最短のものを優先します。ただし、同様の距離のソースが複数存在して、再選択が繰り返されるのを回避するため、現在選択されていないソースからの距離に、固定距離が追加されます。これは、reselectdist
オプションで設定できます。デフォルトでは、この距離は 100 ミリ秒となります。構文は以下のようになります。
reselectdist dist-in-seconds
- stratumweight
stratumweight
ディレクティブは、chronyd
が利用可能なソースから同期ソースを選択する際に、階層ごとに追加される同期距離を設定します。構文は以下のようになります。
stratumweight dist-in-seconds
デフォルトでは、dist-in-seconds は 1 ミリ秒です。つまり、通常は、距離の値が非常に悪い場合でも、stratum が高いソースよりも、stratum が低いソースが優先されることを意味します。
stratumweight
を 0 に設定すると、chronyd
は、ソースを選択するときに stratum を無視します。- rtcfile
rtcfile
ディレクティブは、システムのリアルタイムクロック (RTC) の正確性の追跡に関連するパラメーターをchronyd
が保存できるファイル名を定義します。構文は以下のようになります。
rtcfile /var/lib/chrony/rtc
chronyd
は、このファイルが存在し、chronyc でwritertc
コマンドを実行すると、情報をこのファイルに保存します。保存される情報は、あるエポックでの RTC のエラー、そのエポック (1970 年 1 月 1 日以降の秒数)、および RTC の時間が早まるもしくは遅れる変化量です。リアルタイムクロックのコードはシステム固有のものなので、すべてのリアルタイムクロックがサポートされるわけではありません。このディレクティブを使用する場合は、リアルタイムクロックを手動で調整しないでください。リアルタイムクロックがランダムな間隔で調整されると、その変化量を測定する chrony の必要性が干渉されるためです。- rtcsync
-
rtcsync
ディレクティブは、デフォルトで/etc/chrony.conf
ファイルにあります。これにより、システムクロックが同期されていることがカーネルに知らされ、カーネルによりリアルタイムクロックが 11 分ごとに更新されます。
11.5.1. chrony でセキュリティーの設定
chronyc は、以下の 2 つの方法で chronyd
にアクセスします。
- インターネットプロトコル (IPv4 または IPv6)
-
Unix ドメインソケット (ユーザー
root
またはchrony
がローカルにアクセス可能)
デフォルトでは、chronyc は、Unix ドメインソケットに接続します。デフォルトのパスは /var/run/chrony/chronyd.sock
です。この接続に失敗すると (たとえば非特権ユーザーで chronyc を実行していると失敗する可能性があります)、chronyc は 127.0.0.1 への接続を試み、その後 ::1 への接続を試みます。
chronyd
の動作に影響しない次の監視コマンドのみが、ネットワークに許可されています。
- activity
- manual list
- rtcdata
- smoothing
- sources
- sourcestats
- tracking
- waitsync
chronyd
がこのコマンドを受け取るホスト郡は、chronyd
の設定ファイルにある cmdallow
ディレクティブ、または chronyc の cmdallow
コマンドで設定できます。デフォルトでは、このコマンドが許可されるのは、ローカルホスト (127.0.0.1 or ::1) のものだけになります。
その他のコマンドはすべて、Unix ドメインソケットのみを介して許可されます。ネットワーク上で送信されると、たとえローカルホストであっても、chronyd
は Not authorised
エラーを返します。
chronyc を使用して chronyd にリモートでアクセス
以下を
/etc/chrony.conf
ファイルに追加すると、IPv4 と IPv6 の両方のアドレスからアクセスが可能になります。bindcmdaddress 0.0.0.0
または
bindcmdaddress ::
cmdallow
ディレクティブを使用すると、リモート IP アドレス、ネットワーク、またはサブネットからのコマンドが許可されます。/etc/chrony.conf
ファイルに以下の内容を追加します。cmdallow 192.168.1.0/24
ファイアウォールでポート 323 を開き、リモートシステムから接続します。
# firewall-cmd --zone=public --add-port=323/udp
ポート 323 を永続的に開く場合は、
--permanent
を使用します。# firewall-cmd --permanent --zone=public --add-port=323/udp
allow
ディレクティブは NTP
のアクセス用で、cmdallow
ディレクティブは、リモートコマンドの受け取りを可能にします。ローカルで実行している chronyc を使用すると、この変更を一時的なものにできます。永続的に変更するときは設定ファイルを変更します。
11.6. chrony の使用
11.6.1. chrony のインストール
Red Hat Enterprise Linux では、chrony スイートがデフォルトでインストールされます。インストールされていることを確認するには、root
で以下のコマンドを実行します。
# yum install chrony
chrony デーモンのデフォルトの場所は、/usr/sbin/chronyd
です。このコマンドラインユーティリティーは /usr/bin/chronyc
にインストールされます。
11.6.2. chronyd ステータスの確認
chronyd
のステータスを確認するには、以下のコマンドを実行します。
$ systemctl status chronyd
chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)
Active: active (running) since Wed 2013-06-12 22:23:16 CEST; 11h ago
11.6.3. chronyd の起動
chronyd
を開始するには、root
で以下のコマンドを実行します。
# systemctl start chronyd
システムの起動時に chronyd
を自動的に起動するように設定するには、root
で以下のコマンドを実行します。
# systemctl enable chronyd
11.6.4. chronyd の停止
chronyd
を停止するには、root
で以下のコマンドを実行します。
# systemctl stop chronyd
システムの起動時に chronyd
を自動的に起動しないように設定するには、root
で以下のコマンドを実行します。
# systemctl disable chronyd
11.6.5. chrony の同期確認
chrony が同期されているかどうかを確認するには、tracking
コマンド、sources
コマンド、および sourcestats
コマンドを使用します。
11.6.5.1. chrony 追跡の確認
chrony の追跡を確認するには、以下のコマンドを実行します。
$ chronyc tracking
Reference ID : CB00710F (foo.example.net)
Stratum : 3
Ref time (UTC) : Fri Jan 27 09:49:17 2017
System time : 0.000006523 seconds slow of NTP time
Last offset : -0.000006747 seconds
RMS offset : 0.000035822 seconds
Frequency : 3.225 ppm slow
Residual freq : 0.000 ppm
Skew : 0.129 ppm
Root delay : 0.013639022 seconds
Root dispersion : 0.001100737 seconds
Update interval : 64.2 seconds
Leap status : Normal
各フィールドは、以下のとおりです。
- Reference ID
-
(利用可能な場合) コンピューターが現在同期しているサーバーの参照 ID および参照名 (または
IP
アドレス) です。参照 ID は IPv4 アドレスとの混同を避けるため 16 進数の数値になっています。 - Stratum
- 基準クロックのあるコンピューターから何ホップ離れているかを示します。上記の例のコンピューターは stratum-1 コンピューターであるため、2 ホップ離れていることになります (つまり、a.b.c が stratum-2 で、stratum-1 から同期しています)。
- Ref time
- 参照ソースからの最後の測定が処理された時間 (UTC) です。
- System time
-
chronyd
は、通常の操作ではシステムクロックを更新しません。タイムスケールにおけるジャンプは、いかなるものでも特定のアプリケーションプログラムに有害な結果をもたらすためです。代わりに、システムクロックのエラーをわずかに早めたり遅くしたりして、エラーがなくなるまで修正し、修正が完了したら、システムクロックを通常のスピードに戻します。その結果、(gettimeofday()
システムコールを使用した他のプログラム、またはシェルの date コマンドが読み取る) システムクロックが、chronyd
が予測する現在の実際の時間 (サーバーモードで稼働している場合はこれをNTP
クライアントに報告) と異なる期間が発生します。この行で報告される値は、これによる差異です。 - Last offset
- 最後のクロック更新におけるローカルオフセットの予測です。
- RMS offset
- 長期的な、オフセット値の平均です。
- Frequency
-
chronyd
が修正しない場合にシステムクロックが間違う変化量です。これは、ppm (100 万分の 1) で表されます。たとえば、1 ppm という値は、システムクロックにおける 1 秒が、実際の時間と比較すると 1.000001 秒進んでいることを意味します。 - Residual freq
現在選択されている基準源の「残留周波数」を示しています。基準源からの測定値が、示すべき周波数と、実際に使用されている周波数との違いを反映しています。
これが常にゼロにならない理由は、補正する手順が周波数に適用されているためです。基準源から測定を取得し、新たな剰余周波数が計算されるたびに、この剰余の推定精度が、既存の周波数の推定精度 (
skew
を参照) と比較されます。新たな周波数の加重平均は、その精度によって異なる加重で計算されます。基準源からの測定に一貫した傾向がある場合、剰余は時間をかけてゼロになります。- Skew
- 周波数の予測されるエラー範囲です。
- Root delay
- コンピューターが最終的に同期する stratum-1 コンピューターの、ネットワークパスの遅延の合計数です。Root delay の値はナノ秒の分解能で出力されます。値は、極端な状況では負数になります。(コンピューター同士が互いの周波数を追跡せず、各コンピューターのターンアラウンド時間に比較してネットワークの遅延が非常に短い、対称的なピア配置で、これが発生する場合があります。)
- Root dispersion
- コンピューターが最後に同期する stratum-1 コンピューターに戻るすべてのコンピューターを介して累積された合計分散です。分散は、システムクロックの分解能や統計的測定の変動等に起因します。Root の分散値は、ナノ秒の分解能で出力されます。
- Leap status
- Leap のステータスで、Normal、Insert second、Delete second、または Not synchronized のいずれかになります。
11.6.5.2. chrony ソースの確認
sources コマンドは、chronyd
がアクセスしている現在の時間ソースの情報を表示します。
任意の引数 -v (verbose (詳細) の意) を指定できます。この例では、余分なキャプション行は、コラムの意味を説明するものとして表示されます。
$ chronyc sources 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* GPS0 0 4 377 11 -479ns[ -621ns] /- 134ns ^? a.b.c 2 6 377 23 -923us[ -924us] +/- 43ms ^ d.e.f 1 6 377 21 -2629us[-2619us] +/- 86ms
各コラムの表示内容は、以下のとおりです。
- M
-
ソースのモードを示します。
^
はサーバーを、=
はピアを、#
はローカルに接続している基準クロックを意味します。 - S
-
この列は、ソースの状態を示します。「*」は、
chronyd
が現在同期しているソースを表します。「+」は、選択したソースと結合する、受け入れ可能なソースを表します。「-」は、受け入れ可能なソースで、結合アルゴリズムにより除外されたものを表します。「?」は、接続が切断されたソース、またはパケットがすべてのテストをパスしないソースを表します。「x」は、chronyd
が falseticker と考える (つまり、その時間が他の大半のソースと一致しない) クロックを表します。「~」は、時間の変動性が大きすぎるように見えるソースを表します。「?」条件は、少なくとも 3 つのサンプルが収集されるまで開始時にも表示されます。 - Name/IP address
-
ソースの名前または
IP
アドレス、もしくは基準クロックの参照 ID を表示します。 - Stratum
- 直近で受け取ったサンプルでレポートされているソースの stratum を表示します。Stratum 1 は、ローカルで基準クロックに接続しているコンピューターを示します。Stratum 1 コンピューターに同期しているコンピューターは、stratum 2 に存在することになります。同じく、Stratum 2 コンピューターに同期しているコンピューターは stratum 3 に存在することになり、以後も同様に続きます。
- Poll
ソースがポーリングされるレートで、間隔のベース-2 対数を秒数で示します。つまり、値が 6 の場合は、64 秒ごとに測定が行われます。
chronyd
は、一般的な条件に応じて、ポーリングレートを自動的に変更します。- Reach
- ソースの到達可能性のレジスターで、8 進法で表示されます。レジスターは 8 ビットで、ソースからパケットを受信するたびに、またはミスするたびに更新されます。値が 377 の場合は、最近の 8 回の通信全体で、有効な返信を受け取ったことを表します。
- LastRx
-
このコラムは、ソースから最後のサンプルがいつ受信されたかを表示します。通常は、秒数で表示されます。
m
、h
、d
、およびy
の各文字は、それぞれ分、時間、日、年を表します。値が 10 年の場合は、このソースからまだサンプルを受信していないことを示します。 - Last sample
-
この列は、ローカルクロックと、最後に測定されたソースの間のオフセットを表示します。角括弧内の数字は、実際に測定されたオフセットを表示します。これには
ns
(ナノ秒)、us
(マイクロ秒)、ms
(ミリ秒)、またはs
(秒) の各接尾辞が付く場合があります。角括弧の左側は元の測定を示し、slew がそれ以降にローカルクロックに適用可能になるように調整されています。+/-
に続く数字は、測定におけるエラーのマージンを示します。オフセットの値がプラスの場合は、ローカルクロックがソースよりも進んでいることを意味します。
11.6.5.3. chrony ソースの統計情報の確認
sourcestats
コマンドは、chronyd
が現在調べている各ソースに関するドリフト量とオフセット推定プロセスの情報を表示します。
任意の引数 -v
(verbose (詳細) の意) を指定できます。この例では、余分なキャプション行は、コラムの意味を説明するものとして表示されます。
$ chronyc sourcestats
210 Number of sources = 1
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
===============================================================================
abc.def.ghi 11 5 46m -0.001 0.045 1us 25us
各コラムの表示内容は、以下のとおりです。
- Name/IP address
-
これは、
NTP
サーバー (またはピア) の名前またはIP
アドレス、またはその行の残りの部分が関連する基準クロックの参照 ID です。 - NP
- 現在サーバーで保持されているサンプルポイントの数です。誤差レートと現在のオフセットは、このポイントを使って線形回帰を実行することで予測されます。
- NR
-
最新の回帰を追跡している同一サインを持つ剰余の実行数です。この数字がサンプル数に対して少なくなりすぎる場合は、直線がデータに適合しなくなったことを意味します。実行数が少なすぎる場合、
chronyd
は古いサンプルを破棄し、実行数が受け入れ可能な値になるまで回帰を再実行します。 - Span
- 一番古いサンプルと最新のサンプルの間隔です。単位が表示されない場合は、秒数を表しています。この例の間隔は 46 分です。
- Frequency
- これは予測されるサーバーの剰余周波数で、ppm (100 万分の 1) で表されます。この場合、このコンピューターのクロックは、このサーバーに対比して 109 分の 1 遅く稼働していると見積もられています。
- Freq Skew
- Freq の予測されるエラー範囲です (ppm (100 万分の 1) で表されます) 。
- Offset
- ソースの予測されるオフセットです。
- Std Dev
- サンプルの予測される標準偏差です。
11.6.6. システムクロックの手動調整
システムクロックを徐々に調整していく (slew) のを止め、一度に修正 (step) するには、root
で以下のコマンドを実行します。
# chronyc makestep
rtcfile
ディレクティブを使用している場合は、リアルタイムクロックを手動で調整しないでください。ランダムな調整を行うと、リアルタイムクロックがずれる変化量を測定する必要がある chrony に影響を与えます。
11.7. 異なる環境での chrony の設定
11.7.1. 孤立したネットワークでのシステムにおける chrony の設定
インターネットに接続していないネットワークに関しては、1 台のコンピューターをマスタータイムサーバーとします。もう 1 台のコンピューターをマスターの直接クライアント、またはクライアントのクライアントとします。マスターでは、ドリフトファイルは、システムクロックのドリフトの平均率を使用して手動で設定します。マスターを再起動すると、周囲のシステムから時間を取得し、システムクロックを設定するために平均値を計算します。その後、drift ファイルに基づいて調整の適用を再開します。drift ファイルは、settime
コマンドが使用されたときに自動的に更新されます。
マスターにしたシステムで、root
でテキストエディターを実行し、以下のように /etc/chrony.conf
を実行します。
driftfile /var/lib/chrony/drift commandkey 1 keyfile /etc/chrony.keys initstepslew 10 client1 client3 client6 local stratum 8 manual allow 192.0.2.0
192.0.2.0
は、クライアントが接続できるネットワークアドレスまたはサブネットアドレスです。
マスターのダイレクトクライアントにしたシステムで、root
でテキストエディターを実行し、以下のように /etc/chrony.conf
を実行します。
server master driftfile /var/lib/chrony/drift logdir /var/log/chrony log measurements statistics tracking keyfile /etc/chrony.keys commandkey 24 local stratum 10 initstepslew 20 master allow 192.0.2.123
ここでの 192.0.2.123
はマスターのアドレスで、master
はマスターのホスト名になります。この設定になっているクライアントは、システムが再起動するとマスターと再同期を行います。
マスターの直接のクライアントにはならないクライアントシステムの /etc/chrony.conf
ファイルでは、local
ディレクティブおよび allow
ディレクティブが省略される以外は、同じになるべきです。
孤立したネットワークでは、ローカルの参照モードを有効にする local
ディレクティブも使用できます。これにより、NTP
サーバーとして動作している chronyd
は、サーバーが一度も同期されていなかったり、クロックの最終更新から長い時間が経過している場合でも、リアルタイムに同期してるように見えます。
複数のサーバーをポーリングしているクライアントを混同することなく、ネットワーク上の複数のサーバーに同じローカル設定を使用し、互いを同期させるには、Orphan モードを有効にする local
ディレクティブの orphan
オプションを使用します。各サーバーは、他のすべてのサーバーを local
でポーリングするように設定する必要があります。これにより、最小の参照 ID を持つサーバーでのみローカル参照が有効になり、他のサーバーはそれに同期します。サーバーが失敗すると別のサーバーが引き継ぎます。
11.8. ハードウェアのタイムスタンプを使用した Chrony
11.8.1. ハードウェアのタイムスタンプの概要
ハードウェアのタイムスタンプは、一部の Network Interface Controller (NIC) でサポートされている機能です。着信パケットおよび送信パケットのタイムスタンプを正確に提供します。NTP
タイムスタンプは通常、カーネルにより作成され、システムクロックを使用して chronyd が作成されます。ただし、ハードウェアのタイムスタンプが有効な場合、NIC は独自のクロックを使用して、パケットがリンク層または物理層に出入りするときにタイムスタンプを生成します。ハードウェアスタンプで NTP
を使用すると、同期の精度を大幅に向上できます。最高精度を実現するには、NTP
サーバーおよび NTP
クライアントの両方が、ハードウェアのタイムスタンプを使用している必要があります。理想的な条件下では、サブマイクロ秒単位の精度を実現できるかもしれません。
ハードウェアのタイムスタンプを使用する時間同期の別のプロトコルには、PTP
があります。
NTP
とは異なり、PTP
は、ネットワークスイッチおよびルーターの補助に依存しています。同期の精度を最高の状態にしたい場合は、PTP
をサポートしているスイッチやルーターがあるネットワークで PTP
を使用し、そのようなスイッチおよびルーターがないネットワークでは、NTP
を使用することが推奨されます。
11.8.2. ハードウェアタイムスタンプのサポートの確認
NTP
を使用したハードウェアのタイムスタンプがインターフェースでサポートされていることを確認するには、ethtool -T
コマンドを実行します。ethtool
が、SOF_TIMESTAMPING_TX_HARDWARE
機能、SOF_TIMESTAMPING_TX_SOFTWARE
機能、および HWTSTAMP_FILTER_ALL
フィルターモードを一覧表示する場合は、NTP
を使用して、ハードウェアのタイムスタンプにインターフェースを使用できます。
例11.1 特定のインターフェースにおけるハードウェアのタイムスタンプのサポートの確認
# ethtool -T eth0
出力:
Timestamping parameters for eth0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
11.8.3. ハードウェアのタイムスタンプの有効化
ハードウェアのタイムスタンプを有効にするには、/etc/chrony.conf
ファイルの hwtimestamp
ディレクティブを使用します。ディレクティブは、個別のインターフェースを指定できますが、ワイルドカード文字を使用して、ハードウェアのタイムスタンプをサポートするすべてのインターフェースでハードウェアのタイムスタンプを有効にすることもできます。linuxptp
パッケージの ptp4l などのアプリケーションが、ハードウェアのタイムスタンプを使用していない場合は、ワイルドカード仕様を使用してください。chrony 設定ファイルで、複数の hwtimestamp
ディレクティブが使用されます。
例11.2 hwtimestamp のディレクティブを使用したハードウェアのタイムスタンプの有効化
hwtimestamp eth0 hwtimestamp eth1 hwtimestamp *
11.8.4. クライアントポーリング間隔の設定
インターネット上のサーバーのポーリング間隔は、デフォルトの範囲である 64 秒から 1024 秒が推奨されています。ローカルサーバーおよびハードウェアのタイムスタンプでは、システムクロックのオフセットを最小限にとどめるため、ポーリング間隔は短く設定する必要があります。
/etc/chrony.conf
における以下のディレクティブは、1 秒のポーリング間隔を使用してローカルの NTP
サーバーを指定します。
server ntp.local minpoll 0 maxpoll 0
11.8.5. インターリーブモードの有効化
ハードウェアの NTP
アプライアンスではなく、chrony など、ソフトウェアの NTP
実装を実行する汎用コンピューターの NTP
サーバーは、パケット送信後にのみハードウェア送信タイムスタンプを取得します。この動作により、サーバーは、対応するパケットのタイムスタンプを保存できません。NTP
クライアントが、送信後に生成された送信タイムスタンプを受け取るようにするには、/etc/chrony.conf
のサーバーディレクティブに xleave
オプションを追加し、クライアントが NTP
インターリーブモードを使用するように設定します。
server ntp.local minpoll 0 maxpoll 0 xleave
11.8.6. 多数のクライアント向けのサーバーの設定
デフォルトのサーバー設定では、最多で数千のクライアントが同時にインターリーブモードを使用できます。さらに多くのクライアント向けにサーバーを設定するには、/etc/chrony.conf
の clientloglimit
ディレクティブを増やします。このディレクティブは、サーバーでクライアントのアクセスログに割り当てられるメモリーの最大サイズを指定します。
clientloglimit 100000000
11.8.7. ハードウェアのタイムスタンプの確認
インターフェースがハードウェアのタイムスタンプを有効にできたことを確認するには、システムログを確認してください。ログには、chronyd
からの各インターフェース向けメッセージに、有効にしたハードウェアのタイムスタンプが追記されているはずです。
例11.3 ハードウェアのタイムスタンプが有効になったインターフェースのログメッセージ
chronyd[4081]: Enabled HW timestamping on eth0 chronyd[4081]: Enabled HW timestamping on eth1
chronyd
が、NTP
クライアントまたはピアとして設定されている場合は、chronyc ntpdata
コマンドにより、送信先と受信先のタイムスタンプおよびインターリーブモードを、各 NTP
ソースに報告できます。
例11.4 各 NTP ソースの送信先および受信先のタイムスタンプおよびインターリーブモードの報告
# chronyc ntpdata
出力:
Remote address : 203.0.113.15 (CB00710F) Remote port : 123 Local address : 203.0.113.74 (CB00714A) Leap status : Normal Version : 4 Mode : Server Stratum : 1 Poll interval : 0 (1 seconds) Precision : -24 (0.000000060 seconds) Root delay : 0.000015 seconds Root dispersion : 0.000015 seconds Reference ID : 47505300 (GPS) Reference time : Wed May 03 13:47:45 2017 Offset : -0.000000134 seconds Peer delay : 0.000005396 seconds Peer dispersion : 0.000002329 seconds Response time : 0.000152073 seconds Jitter asymmetry: +0.00 NTP tests : 111 111 1111 Interleaved : Yes Authenticated : No TX timestamping : Hardware RX timestamping : Hardware Total TX : 27 Total RX : 27 Total valid RX : 27
例11.5 NTP 測定の安定性の報告
# chronyc sourcestats
ハードウェアのタイムスタンプを有効にすると、NTP
測定の安定性は、通常のロードにおいて数十ナノ秒または数百ナノ秒となります。この安定性は、chronyc sourcestats
コマンドの出力の Std Dev
列に報告されます。
出力:
210 Number of sources = 1 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ntp.local 12 7 11 +0.000 0.019 +0ns 49ns
11.8.8. PTP-NTP ブリッジの設定
非常に精度が高い PTP
(Precision Time Protocol) のグランドマスターが、PTP
サポートのあるスイッチまたはルーターを持たないネットワークで利用可能な場合、コンピューターは、PTP
スレーブおよび stratum-1 の NTP
サーバーとしての操作に専念する可能性があります。このようなコンピューターには、2 つ以上のネットワークインターフェースが必要なほか、グランドマスターに近いか、またはグランドマスターに直接接続されている必要があります。これにより、ネットワークで非常に精度の高い同期が確実に実行されます。
1 つのインターフェースを使用して、PTP
でシステムクロックを同期するように、linuxptp
パッケージの ptp4l プログラムおよび phc2sys プログラムを設定します。
chronyd
を設定して、その他のインターフェースを使用してシステム時間を提供するには、以下を行います。
例11.6 その他のインターフェースを使用してシステム時間を提供するように chronyd を設定
bindaddress 203.0.113.74 hwtimestamp eth1 local stratum 1
11.9. 以前サポートされていた設定を chrony で実現
ntp がサポートする Red Hat Enterprise Linux の前のメジャーバージョンにあった一部の設定が、chrony ではサポートされません。このセクションはそのような設定の一覧と、chrony を使用して、システムでそれを実現する方法を説明します。
11.9.1. ntpq および ntpdc による監視
chrony は、NTP
モードの 6 および 7 に対応していないため、chronyd
は、ntp ディストリビューションの ntpq ユーティリティーおよび ntpdc ユーティリティーからは監視できません。これにより異なるプロトコルに対応します。chronyc はクライアントの実装になります。詳細は man ページの chronyc(1)
を参照してください。
chronyd
で同期しているシステムクロックの状態を監視するには、次のことができます。
- 追跡コマンドの使用
-
ntpstat ユーティリティーを使用します。 これは、chrony をサポートし、
ntpd
で使用したときと同様の出力を提供します。
例11.7 追跡コマンドの使用
$ chronyc -n tracking Reference ID : 0A051B0A (10.5.27.10) Stratum : 2 Ref time (UTC) : Thu Mar 08 15:46:20 2018 System time : 0.000000338 seconds slow of NTP time Last offset : +0.000339408 seconds RMS offset : 0.000339408 seconds Frequency : 2.968 ppm slow Residual freq : +0.001 ppm Skew : 3.336 ppm Root delay : 0.157559142 seconds Root dispersion : 0.001339232 seconds Update interval : 64.5 seconds Leap status : Normal
例11.8 ntpstat ユーティリティーの使用
$ ntpstat synchronised to NTP server (10.5.27.10) at stratum 2 time correct to within 80 ms polling server every 64 s
11.9.2. 公開鍵暗号に基づく認証メカニズムの使用
Red Hat Enterprise Linux 7 では、ntp がサポートする Autokey は、公開鍵暗号に基づく認証メカニズムです。Autokey は、chronyd
ではサポートされていません。
Red Hat Enterprise Linux 8 システムでは、代わりに対称鍵を使用することが推奨されます。鍵の生成には chronyc keygen
コマンドを使用します。クライアントおよびサーバーは、/etc/chrony.keys
で指定した鍵を共有する必要があります。クライアントは、server
、pool
、または peer
の各ディレクティブで、key
オプションを使用して認証を有効にできます。
11.9.3. 一時的な対称関係の使用
Red Hat Enterprise Linux 7 では、ntpd
が、ntp.conf
設定ファイルで指定しないピアからのパケットにより収集できる一時的な対称関係をサポートしていました。Red Hat Enterprise Linux 8 では、chronyd
は、chrony.conf
ですべてのピアを指定する必要があります。一時的な対称関係はサポートされません。
peer
ディレクティブで有効にした対象モードと比べると、server
ディレクティブまたは pool
ディレクティブで有効になっているクライアント/サーバーモードを使用したほうが安全です。
11.9.4. マルチキャストまたはブロードキャストのクライアント
Red Hat Enterprise Linux 7 では、クライアントの設定を簡素化するブロードキャストまたはマルチキャストの NTP
モードに対応していました。このモードでは、個々のユーザーの特定名またはアドレスに対してリッスンする代わりに、マルチキャストまたはブロードキャストのアドレスに送信されたパケットのみをリッスンするようにクライアントを設定できます。 これは、時間の経過とともに変化する場合があります。
Red Hat Enterprise Linux 8 では、chronyd
は、ブロードキャストモードまたはマルチキャストモードをサポートしていません。主な理由は、通常のクライアント/サーバーおよび対象モードに比べると正確性に欠け、セキュリティーも保護されていないからです。
NTP
のブロードキャストまたはマルチキャストの設定からの移行には、オプションがいくつかあります。
1 つの名前 (ntp.example.com など) を、異なるサーバーの複数のアドレスに変換するように DNS を設定します。
クライアントには、複数サーバーと同期するために、プールディレクティブを 1 つだけ使用した静的な設定を指定できます。サーバーがプールから到達できない場合、または同期に適切ではない場合は、クライアントが自動的にそのサーバーを、プールの別サーバーに置き換えます。
DHCP における
NTP
サーバーリストを配布します。NetworkManager が、DHCP サーバーから
NTP
サーバーの一覧を取得すると、それを使用するようにchronyd
が自動的に設定されます。この機能は、PEERNTP=no
を/etc/sysconfig/network
ファイルに追加すると無効にできます。Precision Time Protocol (PTP)
を使用します。このオプションは、サーバーが頻繁に変更する環境、または、大規模なクライアントグループが、宛先サーバーを持たずに、相互に同期できるようにする必要がある場合に主に適しています。
PTP
は、マルチキャストメッセージング用に設計されており、NTP
ブロードキャストモードと同じように動作します。PTP
実装は、linuxptp
パッケージから入手できます。通常、
PTP
が適切に動作するには、ハードウェアのタイムスタンプとネットワークスイッチのサポートが必要になります。ただし、ブロードキャストモードでは、ソフトウェアタイムスタンプを使用し、ネットワークスイッチのサポートがない場合でも、PTP
の方がNTP
よりも適しています。1 つの通信経路に非常に多くの
PTP
スレーブがあるネットワークでは、そのスレーブが生成したネットワークトラフィックの量を減らすために、hybrid_e2e
オプションでPTP
スレーブを設定することが推奨されます。NTP
クライアント (場合によりNTP
サーバー) としてchronyd
を実行するコンピューターを設定し、マルチキャストメッセージングを使用して、同期した時間を多数のコンピューターに配信するPTP
グランドマスターとして動作させることができます。
11.10. 関連情報
以下の資料は、chrony に関するその他の情報を提供します。
11.10.1. インストールされているドキュメント
-
chronyc(1)
の man ページ - chronyc コマンドラインインターフェースと、そのコマンドおよびコマンドオプションを説明します。 -
chronyd(8)
の man ページ -chronyd
デーモンと、そのコマンドおよびコマンドオプションが説明されています。 -
chrony.conf(5)
の man ページ - chrony 設定ファイルが説明されています。
11.10.2. オンラインドキュメント
FAQ への回答は https://chrony.tuxfamily.org/faq.html を参照してください。
11.11. RHEL システムロールを使用した時刻同期の管理
timesync
ロールを使用して、複数のターゲットマシンで時刻同期を管理できます。
システムクロックが、NTP サーバーまたは PTP ドメインのグランドマスターに同期するように、timesync
ロールが、NTP 実装または PTP 実装をインストールして NTP クライアントまたは PTP スレーブとして動作するように設定します。
timesync
ロールを使用すると、システムが ntp または chrony を使用して NTP プロトコルを実装するかどうかにかかわらず、RHEL 6 以降のすべてのバージョンの Red Hat Enterprise Linux で同じ Playbook を使用できるため、chrony への移行 が容易になります。
timesync
ロールは、管理対象ホストで指定または検出されたプロバイダーサービスの設定を置き換えます。以前の設定は、ロール変数で指定されていなくても失われます。timesync_ntp_provider
変数が定義されていない場合は、プロバイダーの唯一の設定が適用されます。
以下の例は、サーバーにプールが 1 つしかない場合に、timesync
ロールを適用する方法を示しています。
例11.9 サーバーの 1 つのプールに、timesync ロールを適用する Playbook の例
--- - hosts: timesync-test vars: timesync_ntp_servers: - hostname: 2.rhel.pool.ntp.org pool: yes iburst: yes roles: - rhel-system-roles.timesync
関連情報
-
timesync
ロール変数の詳細は、rhel-system-roles
パッケージをインストールし、/usr/share/doc/rhel-system-roles/timesync
ディレクトリーのREADME.md
またはREADME.html
ファイルを参照してください。 - RHEL システムロールの詳細は、「RHEL のシステムロールの概要」 を参照してください。
第12章 2 台のシステム間で OpenSSH を使用した安全な通信の使用
SSH (Secure Shell) は、クライアント/サーバーアーキテクチャーを使用する 2 つのシステム間で安全な通信を提供し、ユーザーがリモートでサーバーホストシステムにログインできるようにするプロトコルです。FTP、Telnet などの他のリモート通信プロトコルとは異なり、SSH はログインセッションを暗号化するため、侵入者が接続して暗号化されていないパスワードを入手するのが困難になります。
Red Hat Enterprise Linux には、基本的な OpenSSH
パッケージ (一般的な openssh
パッケージ、openssh-server
パッケージ、および openssh-clients
パッケージ) が含まれます。OpenSSH
パッケージには、OpenSSL
パッケージ (openssl-libs
) が必要です。このパッケージは、重要な暗号化ライブラリーをいくつかインストールして、暗号化通信を提供する OpenSSH
を有効にします。
12.1. SSH と OpenSSH
SSH (Secure Shell) は、リモートマシンにログインしてそのマシンでコマンドを実行するプログラムです。SSH プロトコルは、安全でないネットワーク上で、信頼されていないホスト間で安全な通信を提供します。また、X11 接続と任意の TCP/IP ポートを安全なチャンネルで転送することもできます。
SSH プロトコルは、リモートシェルのログインやファイルコピー用に使用する場合に、システム間の通信の傍受や特定ホストの偽装など、セキュリティーの脅威を軽減します。これは、SSH クライアントとサーバーがデジタル署名を使用してそれぞれの ID を確認するためです。さらに、クライアントシステムとサーバーシステムとの間の通信はすべて暗号化されます。
OpenSSH
は、多数の Linux、UNIX、および同様のオペレーティングシステムでサポートされている SSH プロトコルの実装です。OpenSSH クライアントとサーバー両方に必要なコアファイルが含まれます。OpenSSH スイートは、以下のユーザー空間ツールで構成されます。
-
SSH
は、リモートログインプログラム (SSH クライアント) です。 -
sshd
は、OpenSSH
SSH デーモンです。 -
scp
は、安全なリモートファイルコピープログラムです。 -
sftp
は、安全なファイル転送プログラムです。 -
ssh-agent
は、秘密鍵をキャッシュする認証エージェントです。 -
ssh-add
は、秘密鍵の ID をssh-agent
に追加します。 -
ssh-keygen
が、ssh
の認証キーを生成、管理、および変換します。 -
ssh-copy-id
は、ローカルの公開鍵をリモート SSH サーバーのauthorized_keys
ファイルに追加するスクリプトです。 -
ssh-keyscan
- SSH パブリックホストキーを収集します。
現在、SSH のバージョンには、バージョン 1 と新しいバージョン 2 の 2 つがあります。Red Hat Enterprise Linux 8 の OpenSSH
スイートは、SSH バージョン 2 のみを使用します。バージョン 1 で既知の不正使用の影響を受けない、強化された鍵交換アルゴリズムを備えています。
OpenSSH
は、RHEL コア暗号化サブシステムのいずれかで、システム全体の暗号化ポリシーを使用します。これにより、弱い暗号スイートおよび暗号化アルゴリズムがデフォルト設定で無効になります。ポリシーを調整するには、管理者が update-crypto-policies
コマンドを使用して設定を厳格または緩くするか、システム全体の暗号化ポリシーを手動でオプトアウトする必要があります。
OpenSSH
スイートは、設定ファイルのセットを 2 つ使用します。クライアントプログラム (つまり ssh
、scp
、および sftp
) の設定ファイルと、サーバー (sshd
デーモン) の設定ファイルです。システム全体の SSH 設定情報が /etc/ssh/
ディレクトリーに保存されます。ユーザー固有の SSH 設定情報は、ユーザーのホームディレクトリーの ~/.ssh/
に保存されます。OpenSSH 設定ファイルの詳細な一覧は、man ページの sshd (8)
の FILES
セクションを参照してください。
関連情報
-
man -k ssh
コマンドで一覧表示されるssh
トピックの man ページ - システム全体の暗号化ポリシーの使用
12.2. OpenSSH サーバーの設定および起動
お使いの環境と OpenSSH
サーバーを起動するのに必要な基本設定には、以下の手順を使用します。デフォルトの RHEL インストールを行うと、sshd
デーモンがすでに起動し、サーバーのホスト鍵が自動的に作成されることに注意してください。
前提条件
-
openssh-server
パッケージがインストールされている。
手順
現行セッションで
sshd
デーモンを開始し、ブート時に自動的に起動するように設定します。# systemctl start sshd # systemctl enable sshd
/etc/ssh/sshd_config
設定ファイルのListenAddress
ディレクティブに、デフォルトの0.0.0.0
(IPv4) または::
(IPv6) とは異なるアドレスを指定し、より低速な動的ネットワーク設定を使用するには、network-online.target
ターゲットユニットの依存関係をsshd.service
ユニットファイルに追加します。これを行うには、以下の内容で/etc/systemd/system/sshd.service.d/local.conf
ファイルを作成します。[Unit] Wants=network-online.target After=network-online.target
-
/etc/ssh/sshd_config
設定ファイルのOpenSSH
サーバーの設定がシナリオの要件を満たしているかどうかを確認します。 必要に応じて、
/etc/issue
ファイルを編集して、クライアント認証を行う前にOpenSSH
サーバーに表示される welcome メッセージを変更します。以下に例を示します。Welcome to ssh-server.example.com Warning: By accessing this server, you agree to the referenced terms and conditions.
Banner
オプションが/etc/ssh/sshd_config
でコメントアウトされず、その値に/etc/issue
が含まれていることを確認します。# less /etc/ssh/sshd_config | grep Banner Banner /etc/issue
ログインに成功すると表示されるメッセージを変更するには、サーバーの
/etc/motd
ファイルを編集する必要があります。詳細は、man ページのpam_motd
を参照してください。systemd
設定を再読み込みし、sshd
を再起動して変更を適用します。# systemctl daemon-reload # systemctl restart sshd
検証手順
sshd
デーモンが実行していることを確認します。# systemctl status sshd ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-11-18 14:59:58 CET; 6min ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 1149 (sshd) Tasks: 1 (limit: 11491) Memory: 1.9M CGroup: /system.slice/sshd.service └─1149 /usr/sbin/sshd -D -oCiphers=aes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc -oMACs=hmac-sha2-256,> Nov 18 14:59:58 ssh-server-example.com systemd[1]: Starting OpenSSH server daemon... Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on 0.0.0.0 port 22. Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on :: port 22. Nov 18 14:59:58 ssh-server-example.com systemd[1]: Started OpenSSH server daemon.
SSH クライアントを使用して SSH サーバーに接続します。
# ssh user@ssh-server-example.com ECDSA key fingerprint is SHA256:dXbaS0RG/UzlTTku8GtXSz0S1++lPegSy31v3L/FAEc. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'ssh-server-example.com' (ECDSA) to the list of known hosts. user@ssh-server-example.com's password:
関連情報
-
man ページの
sshd(8)
およびsshd_config(5)
12.3. SSH 認証にパスワードではなく鍵ペアを使用
システムのセキュリティーをさらに強化するには、SSH 鍵のペアを生成し、パスワード認証を無効にすることで鍵ベース認証を強制します。
12.3.1. 鍵ベースの認証用の OpenSSH サーバーの設定
以下の手順に従って、鍵ベースの認証を強制するように OpenSSH サーバーを設定します。
前提条件
-
openssh-server
パッケージがインストールされている。 -
サーバーで
sshd
デーモンが実行している。
手順
テキストエディターで
/etc/ssh/sshd_config
設定を開きます。以下に例を示します。# vi /etc/ssh/sshd_config
PasswordAuthentication
オプションをno
に変更します。PasswordAuthentication no
新しいデフォルトインストール以外のシステムで
PubkeyAuthentication no
が設定されていないことと、ChallengeResponseAuthentication
ディレクティブがno
に設定されていることを確認します。リモートで接続している場合は、コンソールもしくは帯域外アクセスを使用せず、パスワード認証を無効にする前に、鍵ベースのログインプロセスをテストします。NFS がマウントされたホームディレクトリーで鍵ベースの認証を使用するには、SELinux ブール値
use_nfs_home_dirs
を有効にします。# setsebool -P use_nfs_home_dirs 1
sshd
デーモンを再読み込みし、変更を適用します。# systemctl reload sshd
関連情報
-
man ページの
sshd(8)
、sshd_config(5)
、およびsetsebool(8)
12.3.2. SSH 鍵ペアの生成
以下の手順を使用して、ローカルシステムに SSH 鍵ペアを生成し、生成された公開鍵を OpenSSH
サーバーにコピーします。サーバーが正しく設定されている場合は、パスワードなしで OpenSSH
サーバーにログインできます。
root
で次の手順を完了すると、鍵を使用できるのは root
だけとなります。
手順
SSH プロトコルのバージョン 2 用の ECDSA 鍵ペアを生成するには、次のコマンドを実行します。
$ ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/joesec/.ssh/id_ecdsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/joesec/.ssh/id_ecdsa. Your public key has been saved in /home/joesec/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI joesec@localhost.example.com The key's randomart image is: +---[ECDSA 256]---+ |.oo..o=++ | |.. o .oo . | |. .. o. o | |....o.+... | |o.oo.o +S . | |.=.+. .o | |E.*+. . . . | |.=..+ +.. o | | . oo*+o. | +----[SHA256]-----+
ssh-keygen
コマンドまたは Ed25519 鍵ペアに-t rsa
オプションを指定して RSA 鍵ペアを生成するには、ssh-keygen -t ed25519
コマンドを実行します。公開鍵をリモートマシンにコピーするには、次のコマンドを実行します。
$ ssh-copy-id joesec@ssh-server-example.com /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed joesec@ssh-server-example.com's password: ... Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'joesec@ssh-server-example.com'" and check to make sure that only the key(s) you wanted were added.
セッションで
ssh-agent
プログラムを使用しない場合は、上記のコマンドで、最後に変更した~/.ssh/id*.pub
公開鍵をコピーします (インストールされていない場合)。別の公開キーファイルを指定したり、ssh-agent
により、メモリーにキャッシュされた鍵よりもファイル内の鍵の方が優先順位を高くするには、-i
オプションを指定してssh-copy-id
コマンドを使用します。
システムを再インストールする際に、生成しておいた鍵ペアを引き続き使用する場合は、~/.ssh/
ディレクトリーのバックアップを作成します。再インストール後に、このディレクトリーをホームディレクトリーにコピーします。これは、(root
を含む) システムの全ユーザーで実行できます。
検証手順
パスワードなしで OpenSSH サーバーにログインします。
$ ssh joesec@ssh-server-example.com Welcome message. ... Last login: Mon Nov 18 18:28:42 2019 from ::1
関連情報
-
man ページの
ssh-keygen (1)
およびssh-copy-id (1)
12.4. スマートカードに保存された SSH 鍵の使用
Red Hat Enterprise Linux 8 では、OpenSSH クライアントでスマートカードに保存されている RSA 鍵および ECDSA 鍵を使用できるようになりました。この手順に従って、パスワードの代わりにスマートカードを使用した認証を有効にします。
前提条件
-
クライアントで、
opensc
パッケージをインストールして、pcscd
サービスを実行している。
手順
PKCS #11 の URI を含む OpenSC PKCS #11 モジュールが提供する鍵の一覧を表示し、その出力を keys.pub ファイルに保存します。
$ ssh-keygen -D pkcs11: > keys.pub $ ssh-keygen -D pkcs11: ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
リモートサーバー (example.com) でスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。前の手順で作成された keys.pub で
ssh-copy-id
コマンドを使用します。$ ssh-copy-id -f -i keys.pub username@example.com
手順 1 の
ssh-keygen -D
コマンドの出力にある ECDSA 鍵を使用して example.com に接続するには、鍵を一意に参照する URI のサブセットのみを使用できます。以下に例を示します。$ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com Enter PIN for 'SSH key': [example.com] $
~/.ssh/config
ファイルで同じ URI 文字列を使用して、設定を永続化できます。$ cat ~/.ssh/config IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" $ ssh example.com Enter PIN for 'SSH key': [example.com] $
OpenSSH は
p11-kit-proxy
ラッパーを使用し、OpenSC PKCS #11 モジュールが PKCS#11 キットに登録されているため、以前のコマンドを簡素化できます。$ ssh -i "pkcs11:id=%01" example.com Enter PIN for 'SSH key': [example.com] $
PKCS #11 の URI の id=
の部分を飛ばすと、OpenSSH が、プロキシーモジュールで利用可能な鍵をすべて読み込みます。これにより、必要な入力の量を減らすことができます。
$ ssh -i pkcs11: example.com
Enter PIN for 'SSH key':
[example.com] $
関連情報
- Fedora 28: Better smart card support in OpenSSH
-
man ページの
p11-kit(8)
-
man ページの
ssh(1)
-
man ページの
ssh-keygen(1)
-
man ページの
opensc.conf(5)
-
man ページの
pcscd(8)
12.5. OpenSSH のセキュリティーの強化
以下のヒントは、OpenSSH を使用する際にセキュリティーを高めるのに役に立ちます。OpenSSH 設定ファイル /etc/ssh/sshd_config
を変更するには、sshd
デーモンを再読み込みして有効にする必要があることに注意してください。
# systemctl reload sshd
ほとんどのセキュリティー強化の設定変更により、最新のアルゴリズムまたは暗号スイートに対応していないクライアントとの互換性が低下します。
安全ではない接続プロトコルの無効化
-
SSH を本当の意味で有効なものにするため、
OpenSSH
スイートに置き換えられる安全ではない接続プロトコルを使用しないようにします。このような接続プロトコルを使用すると、ユーザーのパスワード自体は SSH を使用した 1 回のセッションで保護されても、その後に Telnet を使用してログインした時に傍受されてしまうためです。このため、telnet、rsh、rlogin、ftp などの安全ではないプロトコルを無効にすることを検討してください。
鍵ベースの認証の有効化およびパスワードベースの認証の無効化
認証用パスワードを無効にして鍵のペアのみを許可すると、攻撃対象領域が減ってユーザーの時間を節約できる可能性があります。クライアントにおいて、
ssh-keygen
ツールを使用して鍵のペアを生成し、ssh-copy-id
ユーティリティーを使用してOpenSSH
サーバーのクライアントから公開鍵をコピーします。OpenSSH サーバーでパスワードベースの認証を無効にするには、/etc/ssh/sshd_config
のPasswordAuthentication
オプションをno
に変更します。PasswordAuthentication no
鍵のタイプ
ssh-keygen
コマンドは、デフォルトで RSA 鍵のペアを生成しますが、-t
オプションを使用して ECDSA 鍵または Ed25519 鍵を生成するように指定できます。ECDSA (Elliptic Curve Digital Signature Algorithm) は、同等の対称鍵強度で RSA よりも優れたパフォーマンスを提供します。また、短いキーも生成します。Ed25519 公開鍵アルゴリズムは、RSA、DSA、および ECDSA より安全で高速な歪曲エドワーズ曲線の実装です。サーバーホストの鍵の RSA、ECDSA、および Ed25519 がない場合は、OpenSSH が自動的に作成します。RHEL 8 でホストの鍵の作成を設定するには、インスタンス化したサービス
sshd-keygen@.service
を使用します。たとえば、RSA 鍵タイプの自動作成を無効にするには、次のコマンドを実行します。# systemctl mask sshd-keygen@rsa.service
-
SSH 接続の特定の鍵タイプを除外するには、
/etc/ssh/sshd_config
で該当行をコメントアウトしてsshd
サービスを再読み込みします。たとえば、Ed25519 ホストキーだけを許可するには、次のコマンドを実行します。
# HostKey /etc/ssh/ssh_host_rsa_key # HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key
デフォルト以外のポート
デフォルトでは、
sshd
デーモンは TCP ポート 22 をリッスンします。ポートを変更すると、自動化したネットワークスキャンに基づく攻撃にシステムがさらされる可能性が減るため、あいまいさによりセキュリティーが向上します。ポートは、/etc/ssh/sshd_config
設定ファイルのPort
ディレクティブを使用して指定できます。また、デフォルト以外のポートを使用できるように、デフォルトの SELinux ポリシーも更新する必要があります。そのためには、
policycoreutils-python-utils
パッケージのsemanage
ツールを使用します。# semanage port -a -t ssh_port_t -p tcp port_number
さらに、
firewalld
設定を更新します。# firewall-cmd --add-port port_number/tcp # firewall-cmd --runtime-to-permanent
このコマンドで、port_number を、
Port
ディレクティブで指定された新しいポート番号に置き換えます。
root ログインなし
特定のユースケースで root ユーザーとしてログインする必要がない場合は、
/etc/ssh/sshd_config
ファイルでPermitRootLogin
設定ディレクティブをno
に設定することを検討してください。root ユーザーとしてログインする可能性を無効にすることにより、管理者は、通常のユーザーとしてログインし、root 権限を取得した後に、どのユーザーがどの特権コマンドを実行するかを監査できます。または、
PermitRootLogin
をprohibit-password
に設定します。PermitRootLogin prohibit-password
これにより、root としてログインしてパスワードを使用する代わりに鍵ベースの認証が使用され、ブルートフォース攻撃を防ぐことでリスクが軽減します。
X セキュリティー拡張機能の使用
Red Hat Enterprise Linux クライアントの X サーバーは、X セキュリティー拡張を提供しません。そのため、クライアントは X11 転送を使用して信頼できない SSH サーバーに接続するときに別のセキュリティー層を要求できません。ほとんどのアプリケーションは、この拡張機能を有効にしても実行できません。
デフォルトでは、
/etc/ssh/ssh_config.d/05-redhat.conf
ファイルのForwardX11Trusted
オプションがyes
に設定され、ssh -X remote_machine
コマンド (信頼できないホスト) とssh -Y remote_machine
コマンド (信頼できるホスト) には違いがありません。シナリオで X11 転送機能を必要としない場合は、
/etc/ssh/sshd_config
設定ファイルのX11Forwarding
ディレクティブをno
に設定します。
特定のユーザー、グループ、またはドメインへのアクセス制限
/etc/ssh/sshd_config
設定ファイルのAllowUsers
ディレクティブおよびAllowGroups
ディレクティブを使用すると、特定のユーザー、ドメイン、またはグループのみが OpenSSH サーバーに接続することを許可できます。AllowUsers
およびAllowGroups
を組み合わせて、アクセスをより正確に制限できます。以下に例を示します。AllowUsers *@192.168.1.*,*@10.0.0.*,!*@192.168.1.2 AllowGroups example-group
この設定行は、192.168.1.* サブネットおよび 10.0.0.* のサブネットのシステムの全ユーザーからの接続を許可します (192.168.1.2 アドレスのシステムを除く)。すべてのユーザーは、
example-group
グループに属している必要があります。OpenSSH サーバーは、その他のすべての接続を拒否します。ホワイトリストは、許可されていない新しいユーザーまたはグループもブロックするため、ホワイトリスト (Allow で始まるディレクティブ) の使用は、ブラックリスト (Deny で始まるオプション) を使用するよりも安全です。
システム全体の暗号化ポリシーの変更
OpenSSH
は、RHEL のシステム全体の暗号化ポリシーを使用し、デフォルトのシステム全体の暗号化ポリシーレベルは、現在の脅威モデルに安全な設定を提供します。暗号化の設定をより厳格にするには、現在のポリシーレベルを変更します。# update-crypto-policies --set FUTURE Setting system policy to FUTURE
-
OpenSSH
サーバーに対するシステム全体の暗号化ポリシーを除外するには、/etc/sysconfig/sshd
ファイルのCRYPTO_POLICY=
変数行のコメントを除外します。この変更後、/etc/ssh/sshd_config
ファイルのCiphers
セクション、MACs
セクション、KexAlgoritms
セクション、およびGSSAPIKexAlgorithms
セクションで指定した値は上書きされません。このタスクには、暗号化オプションの設定に関する深い専門知識が必要になることに注意してください。 - 詳細は、『RHEL 8 セキュリティーの強化』の「システム全体の暗号化ポリシーの使用」を参照してください
関連情報
-
man ページの
sshd_config(5)
、ssh-keygen(1)
、crypto-policies(7)
、およびupdate-crypto-policies(8)
12.6. SSH ジャンプホストを使用してリモートサーバーに接続
この手順に従って、ジャンプホストとも呼ばれる中間サーバーを介してリモートサーバーに接続します。
前提条件
- ジャンプホストが、システムからの SSH 接続を受け入れる。
- リモートサーバーが、ジャンプホストからのみ SSH 接続を受け入れる。
手順
~/.ssh/config
ファイルを編集して、ジャンプホストを定義します。以下に例を示します。Host jump-server1 HostName jump1.example.com
ProxyJump
ディレクティブを使用して、リモートサーバーのジャンプ設定を~/.ssh/config
に追加します。以下に例を示します。Host remote-server HostName remote1.example.com ProxyJump jump-server1
ジャンプサーバーを使用してリモートサーバーに接続します。
$ ssh remote-server
このコマンドは、設定手順 1 および 2 を省略したときの
ssh -J jump-server1 remote-server
コマンドと同じです。
ジャンプサーバーをさらに指定することもできます。また、完全なホスト名を指定する場合は、設定ファイルへのホスト定義の追加を飛ばすこともできます。以下に例を示します。
$ ssh -J jump1.example.com,jump2.example.com,jump3.example.com remote1.example.com
ジャンプサーバーのユーザー名または SSH ポートが、リモートサーバーの名前およびポートと異なる場合は、上記のコマンドのホスト名のみの表記を変更します。以下に例を示します。
$ ssh -J johndoe@jump1.example.com:75,johndoe@jump2.example.com:75,johndoe@jump3.example.com:75 joesec@remote1.example.com:220
関連情報
-
ssh_config(5)
およびssh(1)
の man ページ
12.7. ssh-agent を使用して SSH キーでリモートマシンに接続する手順
パスフレーズを SSH 接続を開始するたびに入力しなくて済むようにするには、ssh-agent
ユーティリティーを使用して SSH 秘密鍵をキャッシュします。秘密鍵とパスフレーズのセキュリティーが確保されます。
前提条件
- SSH デーモンが実行中で、ネットワーク経由で到達可能なリモートホストがある。
- リモートホストにログインするための IP アドレスまたはホスト名および認証情報を把握している。
- パスフレーズで SSH キーペアを生成し、公開鍵をリモートマシンに転送している。詳細は「SSH 鍵ペアの生成」を参照してください。
手順
必要に応じて、キーを使用してリモートホストに対して認証できることを確認します。
SSH を使用してリモートホストに接続します。
$ ssh example.user1@198.51.100.1 hostname
秘密鍵へのアクセス権を付与する鍵の作成時に指定したパスフレーズを入力します。
$ ssh example.user1@198.51.100.1 hostname host.example.com
ssh-agent
を起動します。$ eval $(ssh-agent) Agent pid 20062
ssh-agent
にキーを追加します。$ ssh-add ~/.ssh/id_rsa Enter passphrase for ~/.ssh/id_rsa: Identity added: ~/.ssh/id_rsa (example.user0@198.51.100.12)
検証手順
オプション: SSH を使用してホストマシンにログインします。
$ ssh example.user1@198.51.100.1 Last login: Mon Sep 14 12:56:37 2020
パスフレーズを入力する必要がないことに注意してください。
12.8. 関連情報
Red Hat Enterprise Linux で OpenSSH
サーバーおよびクライアントを設定し、接続する方法は、以下の資料を参照してください。
インストールされているドキュメント
-
man ページの
sshd(8)
では、利用可能なコマンドラインオプションと、対応している設定ファイルおよびディレクトリーがすべて説明されています。 -
man ページの
ssh(1)
には、利用可能なコマンドラインオプションと対応している設定ファイルおよびディレクトリーの一覧が記載されています。 -
man ページの
scp (1)
には、scp
ユーティリティーとその使用方法に関する詳細が記載されています。 -
man ページの
sftp(1)
には、sftp
ユーティリティーとその使用法に関する詳細が記載されています。 -
man ページの
ssh-keygen(1)
には、ssh-keygen
ユーティリティーを使用して ssh が使用する認証鍵を生成、管理、変換する方法を説明します。 -
man ページの
ssh-copy-id(1)
では、ssh-copy-id
スクリプトの使用方法が説明されています。 -
man ページの
ssh_config(5)
では、利用可能な SSH クライアント設定オプションが説明されています。 -
man ページの
sshd_config(5)
は、利用可能な SSH デーモン設定オプションの詳細な説明があります。 -
man ページの
update-crypto-policies(8)
は、システム全体の暗号化ポリシーの管理に関するガイドを提供します。 -
man ページの
crypto-policies(7)
は、システム全体の暗号化ポリシーレベルの概要を提供します。
オンラインドキュメント
- OpenSSH Home Page - その他のドキュメントや FAQ、メーリングリストへのリンク、バグレポートなどの役立つリソースが掲載されています。
- 「非標準設定でアプリケーションとサービスの SELinux の設定」 - Enforcing モードの SELinux を使用した非標準設定の OpenSSH に類似の手順を適用できます。
-
「firewalld を使用したネットワークトラフィックの制御」 - SSH ポートの変更後に
firewalld
設定の更新に関するガイダンスを提供します。
第13章 リモートロギングソリューションの設定
環境内の各種マシンからのログをロギングサーバーに集中的に記録するために、クライアントシステムからサーバーに特定の基準に合致するログを記録するように Rsyslog アプリケーションを設定できます。
13.1. Rsyslog ロギングサービス
Rsyslog アプリケーションは、systemd-journald
サービスと組み合わせて、Red Hat Enterprise Linux でローカルおよびリモートのロギングサポートを提供します。rsyslogd
デーモンは、ジャーナルから systemd-journald
サービスが受信した syslog
メッセージを継続的に読み取り、rsyslogd
がこのような syslog
イベントにフィルターを設定して処理し、rsyslog
ログファイルに記録するか、その設定に応じて他のサービスに転送します。
rsyslogd
デーモンは、拡張されたフィルタリング、暗号化で保護されたメッセージのリレー、入出力モジュール、TCP プロトコルおよび UDP プロトコルを使用した転送のサポートも提供します。
rsyslog
の主な設定ファイルである /etc/rsyslog.conf
では、どの rsyslogd
がメッセージを処理するかに応じてルールを指定できます。通常は、ソースおよびトピック (ファシリティー) 別および緊急度 (優先度) 別にメッセージを分類し、メッセージがその基準に合致したときに実行するアクションを割り当てることができます。
/etc/rsyslog.conf
では、rsyslogd
が維持するログファイルの一覧も確認できます。ほとんどのログファイルは /var/log/
ディレクトリーにあります。httpd
、samba
などの一部のアプリケーションは、ログファイルを /var/log/
内のサブディレクトリーに保存します。
関連情報
-
man ページの
rsyslogd(8)
およびrsyslog.conf(5)
-
file:///usr/share/doc/rsyslog/html/index.html で
rsyslog-doc
パッケージでインストールされるドキュメント
13.2. Rsyslog ドキュメントのインストール
Rsyslog アプリケーションには https://www.rsyslog.com/doc/ で利用可能な幅広いドキュメントがありますが、以下の手順に従って rsyslog-doc
ドキュメントパッケージをローカルにインストールすることもできます。
前提条件
-
システムで
AppStream
リポジトリーをアクティベートしている。 -
sudo
を使用した新規パッケージのインストールが認可されている。
手順
rsyslog-doc
パッケージをインストールします。$ sudo yum install rsyslog-doc
検証
選択したブラウザーで file:///usr/share/doc/rsyslog/html/index.html ファイルを開きます。以下に例を示します。
$ firefox file:///usr/share/doc/rsyslog/html/index.html
13.3. TCP でのリモートロギングの設定
Rsyslog アプリケーションを使用すると、ロギングサーバーを実行し、個別のシステムがログファイルをロギングサーバーに送信するように設定できます。TCP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。
Rsyslog アプリケーションを使用すると、ログメッセージがネットワークを介してサーバーに転送される中央ロギングシステムを維持できます。サーバーが利用できない場合にメッセージが失われないようにするには、転送アクションのアクションキューを設定します。これにより、送信に失敗したメッセージは、サーバーが再度到達可能になるまでローカルに保存されます。このようなキューは、UDP プロトコルを使用する接続用に設定できないことに注意してください。
omfwd
プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。このプラグインは組み込まれているため、読み込む必要はありません。
13.3.1. TCP でのリモートロギング用のサーバーの設定
以下の手順に従って、クライアントシステムが送信したログの収集および分析を行うサーバーを設定します。
デフォルトでは、rsyslog
はポート 514
で TCP を使用します。
前提条件
-
rsyslog
がサーバーシステムにインストールされている。 - サーバーに root としてログインしている。
手順
必要に応じて、
rsyslog
トラフィックに別のポートを使用するには、SELinux タイプsyslogd_port_t
をポートに追加します。たとえば、ポート30514
を有効にします。# semanage port -a -t syslogd_port_t -p tcp 30514
必要に応じて、
rsyslog
トラフィックに別のポートを使用するには、firewalld
がそのポートでの着信rsyslog
トラフィックを許可するように設定します。たとえば、ゾーンzone
でポート30514
に TCP トラフィックを許可します。# firewall-cmd --zone=zone --permanent --add-port=30514/tcp success
/etc/rsyslog.d/
ディレクトリーに新規ファイル (例:remotelog.conf
) を作成し、以下のコンテンツを挿入します。# Define templates before the rules that use them ### Per-Host Templates for Remote Systems ### template(name="TmplAuthpriv" type="list") { constant(value="/var/log/remote/auth/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") } template(name="TmplMsg" type="list") { constant(value="/var/log/remote/msg/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") } # Provides TCP syslog reception module(load="imtcp") # Adding this ruleset to process remote messages ruleset(name="remote1"){ authpriv.* action(type="omfile" DynaFile="TmplAuthpriv") *.info;mail.none;authpriv.none;cron.none action(type="omfile" DynaFile="TmplMsg") } input(type="imtcp" port="30514" ruleset="remote1")
-
/etc/rsyslog.d/remotelog.conf
ファイルへの変更を保存します。 Rsyslog
サービスがロギングサーバーで実行中で、有効になっていることを確認します。# systemctl status rsyslog
rsyslog
サービスを再起動します。# systemctl restart rsyslog
必要に応じて、
rsyslog
が有効になっていない場合は、再起動後にrsyslog
サービスが自動的に起動するようにします。# systemctl enable rsyslog
環境内の他のシステムからログファイルを受け取り、保存するように、ログサーバーが設定されています。
検証
/etc/rsyslog.conf
ファイルの構文をテストします。# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
関連情報
-
man ページの
rsyslogd(8)
、rsyslog.conf(5)
、semanage(8)
、およびfirewall-cmd(1)
-
file:///usr/share/doc/rsyslog/html/index.html で
rsyslog-doc
パッケージでインストールされるドキュメント
13.3.2. TCP 経由のサーバーへのリモートロギングの設定
以下の手順に従って、TCP プロトコルを介してサーバーにログメッセージを転送するようにシステムを設定します。omfwd
プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。
前提条件
-
rsyslog
パッケージが、サーバーに報告する必要のあるクライアントシステムにインストールされている。 - リモートロギング用にサーバーを設定している。
- 指定したポートが SELinux で許可され、ファイアウォールで開いている。
手順
/etc/rsyslog.d/
ディレクトリーに新規ファイル (例:remotelog.conf
) を作成し、以下のコンテンツを挿入します。*.* action(type="omfwd" queue.type="linkedlist" queue.filename="example_fwd" action.resumeRetryCount="-1" queue.saveOnShutdown="on" target="example.com" port="30514" protocol="tcp" )
詳細は以下のようになります。
-
queue.type="linkedlist"
は、LinkedList インメモリーキューを有効にします。 -
queue.filename
はディスクストレージを定義します。バックアップファイルは、前のグローバルのworkDirectory
ディレクティブで指定された作業ディレクトリーにexample_fwd
接頭辞を付けて作成されます。 -
action.resumeRetryCount -1
設定は、サーバーが応答しない場合に接続を再試行するときにrsyslog
がメッセージを破棄しないようにします。 -
rsyslog
がシャットダウンすると、有効になっているqueue.saveOnShutdown="on"
はインメモリーデータを保存します。 - 最後の行は受信メッセージをすべてロギングサーバーに転送します。ポートの指定は任意です。
この設定では、
rsyslog
はメッセージをサーバーに送信しますが、リモートサーバーに到達できない場合には、メッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域がrsyslog
で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。-
rsyslog
サービスを再起動します。# systemctl restart rsyslog
検証
クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。
クライアントシステムで、テストメッセージを送信します。
# logger test
サーバーシステムで、
/var/log/messages
ログを表示します。以下に例を示します。# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
hostname はクライアントシステムのホスト名です。ログには、
logger
コマンドを入力したユーザーのユーザー名 (この場合はroot
) が含まれていることに注意してください。
関連情報
-
man ページの
rsyslogd(8)
およびrsyslog.conf(5)
-
file:///usr/share/doc/rsyslog/html/index.html で
rsyslog-doc
パッケージでインストールされるドキュメント
13.4. UDP でのリモートロギングの設定
Rsyslog
アプリケーションを使用すると、リモートシステムからロギング情報を受信するようにシステムを設定できます。UDP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。受信サーバーは、クライアントシステムが送信したログの収集および分析を行います。デフォルトでは、rsyslog
はポート 514
で UDP を使用して、リモートシステムからログ情報を受信します。
13.4.1. UDP でリモートロギング情報を受信するためのサーバー設定
以下の手順に従って、UDP プロトコルでクライアントシステムが送信したログの収集および分析を行うサーバーを設定します。
前提条件
-
rsyslog
ユーティリティーがインストールされている。
手順
必要に応じて、デフォルトのポート
514
以外のrsyslog
トラフィックに別のポートを使用するには、次のコマンドを実行します。SELinux ポリシー設定に
syslogd_port_t
SELinux タイプを追加し、portno
はrsyslog
で使用するポート番号に置き換えます。# semanage port -a -t syslogd_port_t -p udp portno
rsyslog
の受信トラフィックを許可するようにfirewalld
を設定します。portno
はポート番号に、zone
はrsyslog
が使用するゾーンに置き換えます。# firewall-cmd --zone=zone --permanent --add-port=portno/udp success
ファイアウォールルールを再読み込みします。
# firewall-cmd --reload
/etc/rsyslog.d/
ディレクトリーに.conf
の新規ファイル (例:remotelogserv.conf
) を作成し、以下のコンテンツを挿入します。# Define templates before the rules that use them ### Per-Host Templates for Remote Systems ### template(name="TmplAuthpriv" type="list") { constant(value="/var/log/remote/auth/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") } template(name="TmplMsg" type="list") { constant(value="/var/log/remote/msg/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") } # Provides UDP syslog reception module(load="imudp") # This ruleset processes remote messages ruleset(name="remote1"){ authpriv.* action(type="omfile" DynaFile="TmplAuthpriv") *.info;mail.none;authpriv.none;cron.none action(type="omfile" DynaFile="TmplMsg") } input(type="imudp" port="514" ruleset="remote1")
514
は、rsyslog
がデフォルトで使用するポート番号です。代わりに別のポートを指定できます。rsyslog
サービスを再起動します。# systemctl restart rsyslog
必要に応じて、
rsyslog
が有効になっていない場合は、再起動後にrsyslog
サービスが自動的に起動するようにします。# systemctl enable rsyslog
検証
/etc/rsyslog.conf
ファイルの構文と/etc/rsyslog.d/
ディレクトリー内の全.conf
ファイルを確認します。# rsyslogd -N 1 rsyslogd: version 8.1911.0-2.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
関連情報
-
rsyslogd(8)
、rsyslog.conf(5)
、semanage(8)
、およびfirewall-cmd(1)
の man ページ -
file:///usr/share/doc/rsyslog/html/index.html
のrsyslog-doc
パッケージからインストールできるブラウザーベースのドキュメント
13.4.2. TCP 経由のサーバーへのリモートロギングの設定
以下の手順に従って、UDP プロトコルを介してサーバーにログメッセージを転送するようにシステムを設定します。omfwd
プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。
前提条件
-
rsyslog
パッケージが、サーバーに報告する必要のあるクライアントシステムにインストールされている。 - 「UDP でリモートロギング情報を受信するためのサーバー設定」で説明されているように、リモートロギング用にサーバーを設定している。
手順
/etc/rsyslog.d/
ディレクトリーに.conf
の新規ファイル (例:remotelogcli.conf
) を作成し、以下のコンテンツを挿入します。*.* action(type="omfwd" queue.type="linkedlist" queue.filename="example_fwd" action.resumeRetryCount="-1" queue.saveOnShutdown="on" target="example.com" port="portno" protocol="udp" )
詳細は以下のようになります。
-
queue.type="linkedlist"
は、LinkedList インメモリーキューを有効にします。 -
queue.filename
はディスクストレージを定義します。バックアップファイルは、前のグローバルのworkDirectory
ディレクティブで指定された作業ディレクトリーにexample_fwd
接頭辞を付けて作成されます。 -
action.resumeRetryCount -1
設定は、サーバーが応答しない場合に接続を再試行するときにrsyslog
がメッセージを破棄しないようにします。 -
rsyslog
がシャットダウンすると、有効になっている queue.saveOnShutdown="on"
はインメモリーデータを保存します。 -
portno
は、rsyslog
で使用するポート番号です。デフォルト値は514
です。 最後の行は受信メッセージをすべてロギングサーバーに転送します。ポートの指定は任意です。
この設定では、
rsyslog
はメッセージをサーバーに送信しますが、リモートサーバーに到達できない場合には、メッセージをメモリーに保持します。ディスク上にあるファイルは、設定されたメモリーキュー領域がrsyslog
で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。
-
rsyslog
サービスを再起動します。# systemctl restart rsyslog
必要に応じて、
rsyslog
が有効になっていない場合は、再起動後にrsyslog
サービスが自動的に起動するようにします。# systemctl enable rsyslog
検証
クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。
クライアントシステムで、テストメッセージを送信します。
# logger test
サーバーシステムで、
/var/log/remote/msg/hostname/root.log
ログを表示します。以下に例を示します。# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
hostname
はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合はroot
) が含まれていることに注意してください。
関連情報
-
man ページの
rsyslogd(8)
およびrsyslog.conf(5)
-
file:///usr/share/doc/rsyslog/html/index.html
のrsyslog-doc
パッケージからインストールできるブラウザーベースのドキュメント
13.5. 信頼できるリモートロギングの設定
Reliable Event Logging Protocol (RELP) を使用すると、メッセージ損失のリスクを大幅に軽減して TCP で syslog
メッセージを送受信できます。RELP は、信頼できるイベントメッセージを配信するので、メッセージ損失が許されない環境で有用です。RELP を使用するには、imrelp
の入力モジュール (サーバー上での実行とログの受信) と omrelp
出力モジュール (クライアント上での実行とロギングサーバーへのログの送信) を設定します。
前提条件
-
rsyslog
パッケージ、librelp
パッケージ、およびrsyslog-relp
パッケージをサーバーおよびクライアントシステムにインストールしている。 - 指定したポートが SELinux で許可され、ファイアウォール設定で開放されている。
手順
信頼できるリモートロギング用にクライアントシステムを設定します。
クライアントシステムの
/etc/rsyslog.d/
ディレクトリーに、relpcli.conf
などと名前を指定して新しい.conf
ファイルを作成し、以下のコンテンツを挿入します。module(load="omrelp") *.* action(type="omrelp" target="target_IP" port="target_port")
詳細は以下のようになります。
-
target_IP
は、ロギングサーバーの IP アドレスに置き換えます。 -
target_port
はロギングサーバーのポートに置き換えます。
-
-
/etc/rsyslog.d/relpserv.conf
ファイルへの変更を保存します。 rsyslog
サービスを再起動します。# systemctl restart rsyslog
必要に応じて、
rsyslog
が有効になっていない場合は、再起動後にrsyslog
サービスが自動的に起動するようにします。# systemctl enable rsyslog
信頼できるリモートロギング用にサーバーシステムを設定します。
サーバーシステムの
/etc/rsyslog.d/
ディレクトリーに、relpserv.conf
などと名前を指定して新しい.conf
ファイルを作成し、以下のコンテンツを挿入します。ruleset(name="relp"){ *.* action(type="omfile" file="log_path") } module(load="imrelp") input(type="imrelp" port="target_port" ruleset="relp")
詳細は以下のようになります。
-
log_path
は、メッセージを保存するパスを指定します。 -
target_port
はロギングサーバーのポートに置き換えます。クライアント設定ファイルと同じ値を使用します。
-
-
/etc/rsyslog.d/relpserv.conf
ファイルへの変更を保存します。 rsyslog
サービスを再起動します。# systemctl restart rsyslog
必要に応じて、
rsyslog
が有効になっていない場合は、再起動後にrsyslog
サービスが自動的に起動するようにします。# systemctl enable rsyslog
検証
クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。
クライアントシステムで、テストメッセージを送信します。
# logger test
サーバーシステムで、指定された
log_path
でログを表示します。以下に例を示します。# cat /var/log/remote/msg/hostname/root.log Feb 25 03:53:17 hostname root[6064]: test
hostname
はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合はroot
) が含まれていることに注意してください。
関連情報
-
man ページの
rsyslogd(8)
およびrsyslog.conf(5)
-
file:///usr/share/doc/rsyslog/html/index.html
のrsyslog-doc
パッケージからインストールできるブラウザーベースのドキュメント
13.6. サポート対象の Rsyslog モジュール
特定の追加モジュールを使用して Rsyslog ユーティリティーの機能を拡張できます。モジュールには、追加の入力 (入力モジュール)、出力 (出力モジュール)、およびその他の特定の機能が含まれます。モジュールは、モジュールの読み込み後に利用可能な設定ディレクティブを追加で提供することも可能です。
以下のコマンドを使用して、システムにインストールされている入出力モジュールを一覧表示します。
# ls /usr/lib64/rsyslog/{i,o}m*
利用可能な rsyslog
モジュールの一覧を表示するには、rsyslog-doc
パッケージからインストールしたドキュメントで以下のページを開きます。
$ firefox file:///usr/share/doc/rsyslog/html/configuration/modules/idx_output.html
13.7. 関連情報
-
file:///usr/share/doc/rsyslog/html/index.html で
rsyslog-doc
パッケージでインストールされるドキュメント -
man ページの
rsyslog.conf(5)
およびrsyslogd(8)
- ナレッジベースの記事「Configuring system logging without journald」
- 「Negative effects of the RHEL default logging setup on performance and their mitigations」
第14章 Logging システムロールの使用
システム管理者は、Logging システムロールを使用して、RHEL ホストをロギングサーバーとして設定し、多くのクライアントシステムからログを収集できます。
14.1. Logging システムロール
Logging システムロールを使用すると、ローカルおよびリモートホストにロギング設定をデプロイできます。
Logging システムロールを 1 つ以上のシステムに適用するには、Playbook でロギング設定を定義します。Playbook は、1 つ以上の play の一覧です。Playbook は YAML 形式で表現され、人が判読できるようになっています。Playbook の詳細は、Ansible ドキュメントの 「Working with playbooks」 を参照してください。
Ansible が Playbook に従って設定するシステムのセットは、インベントリーファイル で定義されます。インベントリーの作成および使用に関する詳細は、Ansible ドキュメントの 「How to build your inventory」 を参照してください。
ロギングソリューションは、ログと複数のログ出力を読み取る複数の方法を提供します。
たとえば、ロギングシステムは以下の入力を受け取ることができます。
- ローカルファイル
-
systemd/journal
- ネットワーク上で別のロギングシステム
さらに、ロギングシステムでは以下を出力できます。
-
/var/log
ディレクトリーのローカルファイルに保存されるログ - Elasticsearch に送信されるログ
- 別のロギングシステムに転送されるログ
logging システムロールを使用すると、必要に応じて入力と出力を組み合わせることができます。たとえば、journal
からの入力をローカルのファイルに保存しつつも、複数のファイルから読み込んだ入力を別のロギングシステムに転送してそのローカルのログファイルに保存するようにロギングソリューションを設定できます。
14.2. Logging システムロールのパラメーター
Logging システムロール Playbook では、logging_inputs
パラメーターで入力を、logging_outputs
パラメーターで出力を、そして logging_flows
パラメーターで入力と出力の関係を定義します。Logging システムロールは、ロギングシステムの追加設定オプションで、上記の変数を処理します。暗号化を有効にすることもできます。
現在、Logging システムロールで利用可能な唯一のロギングシステムは Rsyslog です。
logging_inputs
: ロギングソリューションの入力リスト。-
name
: 入力の一意の名前。logging_flows
入力一覧および生成されたconfig
ファイル名の一部で使用されます。 type
: 入力要素のタイプ。type は、roles/rsyslog/{tasks,vars}/inputs/
のディレクトリー名に対応するタスクタイプを指定します。basics
:systemd
ジャーナルまたはunix
ソケットからの入力を設定する入力。-
kernel_message
:true
に設定された場合はimklog
を読み込みます。デフォルトはfalse
です。 -
use_imuxsock
:imjournal
の代わりにimuxsock
を使用します。デフォルトはfalse
です。 -
ratelimit_burst
:ratelimit_interval
内に出力できるメッセージの最大数。use_imuxsock
が false の場合、デフォルトで20000
に設定されます。use_imuxsock
が true の場合、デフォルトで200
に設定されます。 -
ratelimit_interval
:ratelimit_burst
を評価する間隔。use_imuxsock
が false の場合、デフォルトで 600 秒に設定されます。use_imuxsock
が true の場合、デフォルトで 0 に設定されます。0 はレート制限がオフであることを示します。 -
persist_state_interval
: ジャーナルの状態は、value
メッセージごとに永続化されます。デフォルトは10
です。use_imuxsock
が false の場合のみ、有効です。
-
-
files
: ローカルファイルからの入力を設定する入力。 -
remote
: ネットワークを介して、他のロギングシステムからの入力を設定する入力。
-
state
: 設定ファイルの状態。present
またはabsent
。デフォルトはpresent
です。
-
logging_outputs
: ロギングソリューションの出力一覧。-
files
: ローカルファイルへの出力を設定する出力。 -
forwards
: 別のロギングシステムへの出力を設定する出力。 -
remote_files
: 別のロギングシステムからの出力をローカルファイルに設定する出力。
-
logging_flows
:logging_inputs
とlogging_outputs
の関係を定義するフローの一覧。logging_flows
変数には以下が含まれます。-
name
: フローの一意の名前。 -
inputs
:logging_inputs
名の値の一覧。 -
outputs
:logging_outputs
名の値の一覧。
-
関連情報
-
rhel-system-roles
パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html
)
14.3. ローカルの Logging システムロールの適用
以下の手順に従って、Red Hat Ansible Engine Playbook を準備および適用し、別個のマシンにロギングソリューションを設定します。各マシンはログをローカルに記録します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記ロギングソリューションをデプロイするシステムに Red Hat Ansible Engine をインストールする必要はありません。
Playbook を実行するシステムに
rhel-system-roles
パッケージがある。注記デプロイ時に
rsyslog
がシステムロールによりインストールされるので、rsyslog
はインストールする必要はありません。- ロギングソリューションを設定するシステムを一覧表示するインベントリーファイルがある。
手順
必要なロールを定義する Playbook を作成します。
新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi logging-playbook.yml
以下の内容を挿入します。
--- - name: Deploying basics input and implicit files output hosts: all roles: - linux-system-roles.logging vars: logging_inputs: - name: system_input type: basics logging_outputs: - name: files_output type: files logging_flows: - name: flow1 inputs: [system_input] outputs: [files_output]
特定のインベントリーで Playbook を実行します。
# ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml
ここでは、
-
inventory-file
はインベントリーファイルに置き換えます。 -
logging-playbook.yml
は、使用する Playbook に置き換えます。
-
検証
/etc/rsyslog.conf
ファイルの構文をテストします。# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
システムがログにメッセージを送信していることを確認します。
テストメッセージを送信します。
# logger test
/var/log/messages ログ
を表示します。以下に例を示します。# cat /var/log/messages Aug 5 13:48:31 hostname root[6778]: test
`hostname` はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は
root
) が含まれていることに注意してください。
14.4. Logging システムロールを使用したリモートロギングソリューションの適用
以下の手順に従って、Red Hat Ansible Engine Playbook を準備および適用し、リモートロギングソリューションを設定します。この Playbook では、1 つ以上のクライアントが systemd-journal
からログを取得し、リモートサーバーに転送します。サーバーは、remote_rsyslog
および remote_files
からリモート入力を受信し、リモートホスト名によって名付けられたディレクトリーのローカルファイルにログを出力します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記ロギングソリューションをデプロイするシステムに Red Hat Ansible Engine をインストールする必要はありません。
Playbook を実行するシステムに
rhel-system-roles
パッケージがある。注記デプロイ時に
rsyslog
がシステムロールによりインストールされるので、rsyslog
はインストールする必要はありません。2 つ以上のシステムがある。
- 少なくとも 1 つはロギングサーバー
- 少なくとも 1 つはロギングクライアント
手順
必要なロールを定義する Playbook を作成します。
新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi logging-playbook.yml
以下の内容をファイルに挿入します。
--- - name: Deploying remote input and remote_files output hosts: server roles: - linux-system-roles.logging vars: logging_inputs: - name: remote_udp_input type: remote udp_ports: [ 601 ] - name: remote_tcp_input type: remote tcp_ports: [ 601 ] logging_outputs: - name: remote_files_output type: remote_files logging_flows: - name: flow_0 inputs: [remote_udp_input, remote_tcp_input] outputs: [remote_files_output] - name: Deploying basics input and forwards output hosts: clients roles: - linux-system-roles.logging vars: logging_inputs: - name: basic_input type: basics logging_outputs: - name: forward_output0 type: forwards severity: info target: host1.example.com udp_port: 601 - name: forward_output1 type: forwards facility: mail target: host1.example.com tcp_port: 601 logging_flows: - name: flows0 inputs: [basic_input] outputs: [forward_output0, forward_output1] [basic_input] [forward_output0, forward_output1]
host1.example.com
はロギングサーバーに置き換えます。注記必要に応じて、Playbook のパラメーターを変更することができます。
警告ロギングソリューションは、サーバーまたはクライアントシステムの SELinux ポリシーで定義され、ファイアウォールで開放されたポートでしか機能しません。デフォルトの SELinux ポリシーには、ポート 601、514、6514、10514、および 20514 が含まれます。別のポートを使用するには、「クライアントシステムとサーバーシステムで SELinux ポリシーを変更」します。システムロールを使用したファイアウォールの設定は、まだサポートされていません。
サーバーおよびクライアントを一覧表示するインベントリーファイルを作成します。
新しいファイルを作成してテキストエディターで開きます。以下に例を示します。
# vi inventory.ini
以下のコンテンツをインベントリーファイルに挿入します。
[servers] server ansible_host=host1.example.com [clients] client ansible_host=host2.example.com
*
host1.example.com
はロギングサーバー、*host2.example.com
はロギングクライアントになります。
インベントリーで Playbook を実行します。
# ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml
ここでは、
-
inventory.ini
はインベントリーファイルに置き換えます。 -
logging-playbook.yml
は作成した Playbook に置き換えます。
-
検証手順
クライアントとサーバーシステムの両方で、
/etc/rsyslog.conf
ファイルの構文をテストします。# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
クライアントシステムがサーバーにメッセージを送信することを確認します。
クライアントシステムで、テストメッセージを送信します。
# logger test
サーバーシステムで、
/var/log/messages
ログを表示します。以下に例を示します。# cat /var/log/messages Aug 5 13:48:31 host2.example.com root[6778]: test
host2.example.com
は、クライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合はroot
) が含まれていることに注意してください。
関連情報
- RHEL システムロールの使用
-
rhel-system-roles
パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html
) - ナレッジベースの記事 「Red Hat Enterprise Linux (RHEL) System Roles」
14.5. 関連情報
- RHEL システムロールの使用
-
rhel-system-roles
パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html
) - ナレッジベースの記事 「Red Hat Enterprise Linux (RHEL) System Roles」
第15章 Python の使用
15.1. Python の概要
Python は、オブジェクト指向、命令、機能、手順などの複数のプログラミングパラダイムをサポートする、高レベルのプログラミング言語です。Python は動的なセマンティクスを持ち、汎用プログラミングに使用できます。
Red Hat Enterprise Linux では、システムツールを提供するパッケージ、データ分析または Web アプリケーションのツールなど、システムにインストールされている多くのパッケージが Python で記述されています。このパッケージを使用できるようにするには、python
パッケージがインストールされている必要があります。
15.1.1. Python のバージョン
Python で互換性のない 2 つのバージョン (Python 2.x および Python 3.x) が広く使用されています。
RHEL 8 は、以下のバージョンの Python を提供します。
バージョン | インストールするパッケージ | コマンドの例 | どのバージョン以降で利用可能か | ライフサイクル |
---|---|---|---|---|
Python 3.6 |
|
| RHEL 8.0 | 完全な RHEL 8 |
Python 2.7 |
|
| RHEL 8.0 | より短い |
Python 3.8 |
|
| RHEL 8.2 | より短い |
サポート期間の詳細は、「Red Hat Enterprise Linux のライフサイクル」および「Red Hat Enterprise Linux 8 アプリケーションストリームライフサイクル」を参照してください。
Python の各バージョンは個別のモジュールで配布され、設計上、同じシステムに複数のモジュールを同時にインストールできます。
python38
モジュールには、システムツール (RPM、DNF、SELinux など) にバインドされる、python36
モジュール向けに提供されているのと同じバインディングは含まれないことに留意してください。
Python のインストール時、起動時、対話時にはバージョンを常に指定します。たとえば、パッケージ名またはコマンド名で、python
の代わりに python3
を使用します。Python 関連のすべてのコマンドにもバージョンを含む必要があります (pip3
、pip2
、pip3.8
など)。
RHEL 8 では、バージョンを指定しない python
コマンド (/usr/bin/python
) は、デフォルトで利用できません。alternatives
コマンドを使用して設定できます。手順については、「Configuring the unversioned Python」を参照してください。alternatives
コマンドを使用して加えられた変更を除き、/usr/bin/python
への手動の変更は、更新時に上書きされる可能性があります。
以下の理由により、システム管理者は Python 3 を使用することが推奨されます。
- Python 3 は、Python プロジェクトの主な開発方向を表します。
- アップストリームコミュニティーの Python 2 のサポートは 2020 年に終了します。
- アップストリームで人気のある Python ライブラリーでは、Python 2 サポートが減っています。
-
Python 3
への移行を容易にするために、Red Hat Enterprise Linux 8 の Python 2 のライフサイクルが短くなっています。
開発者には、Python 2 と比較して Python 3 には以下の利点があります。
- Python 3 の方が、より簡単に、表現が豊かで、メンテナンスが可能な、正しいコードを書くことができます。
- Python 3 で書かれたコード寿命は長くなります。
- Python 3 には、asyncio、f-strings、高度なアンパッキング、キーワードのみの引数、例外チェーンなどの新機能があります。
ただし、既存のソフトウェアは、/usr/bin/python
が Python 2 であることが求められる傾向があります。この理由により、デフォルトでは、python
パッケージが配信されている Red Hat Enterprise Linux 8 で配信されず、「バージョンを指定しない Python の設定」に記載されるように、/usr/bin/python
で、使用する Python のバージョンを 2 または 3 から選択できます。
15.1.2. 内部 の platform-python パッケージ
Red Hat Enterprise Linux 8 のシステムツールは、内部の platform-python
パッケージで提供される Python バージョン 3.6 を使用します。Red Hat は、代わりに python36
パッケージを使用することを推奨します。
15.2. Python のインストールおよび使用
バージョンを指定しない python
コマンドを使用して Python をインストールまたは実行すると、曖昧なためデフォルトでは動作しません。Python のバージョンを常に指定するか、alternatives
コマンドを使用してシステムのデフォルトバージョンを設定します。
15.2.1. Python 3 のインストール
Red Hat Enterprise Linux 8 では、Python 3 は、AppStream リポジトリーの python36
および python38
モジュールにより提供されるバージョン 3.6 および 3.8 で配布されます。
手順
python36
モジュールから Python 3.6 をインストールするには、以下のコマンドを実行します。# yum install python3
python36:3.6 モジュールストリームは、自動的に有効になります。
python38
モジュールから Python 3.8 をインストールするには、以下を使用します。# yum install python38
python38:3.8 モジュールストリームは、自動的に有効になります。
RHEL 8 のモジュールの詳細は『ユーザー空間コンポーネントのインストール、管理、および削除』を参照してください。
設計上、python27
、python36
、python38
モジュールなど、RHEL 8 モジュールを同時にインストールできます。1 つのモジュール内の複数のストリームでの並列インストールは、サポート対象外です。
Python 3.8 および Python 3.8 向けにビルドされたパッケージは、mod_wsgi
モジュールを除き、同じシステムの Python 3.6 と並行してインストールできます。Apache HTTP Server の制限により、システムに python3-mod_wsgi
パッケージおよび python38-mod_wsgi
パッケージのいずれかしかインストールできません。
Python 3.6 用のアドオンモジュールのパッケージは、通常 python3-
の接頭辞を使用します。Python 3.8 のパッケージには python38-
の接頭辞が含まれます。以下の例にあるように、追加の Python パッケージのインストール時には常に接頭辞を含めます。
手順
Python 3.6 の
Requests
モジュールをインストールするには、以下のコマンドを実行します。# yum install python3-requests
Cython
拡張を Python 3.8 にインストールするには、以下を使用します。# yum install python38-Cython
15.2.1.1. 開発者用の Python 3 追加パッケージのインストール
開発者向けの Python 3.8 追加パッケージは、python38-devel
モジュールの CodeReady Linux Builder リポジトリーで配布されます。このモジュールには、python38-pytest
パッケージとその依存関係 (pyparsing
、atomicwrites
、attrs
、packaging
、py
、more-itertools
、pluggy
および wcwidth
パッケージ) が含まれます。
CodeReady Linux Builder リポジトリーおよびそのコンテンツは、Red Hat ではサポートされていません。
python38-devel
モジュールからパッケージをインストールするには、以下の手順を行います。
手順
サポート対象外の CodeReady Linux Builder リポジトリーを有効にします。
# subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms
python38-devel
モジュールを有効にします。# yum module enable python38-devel
python38-pytest
パッケージをインストールします。# yum install python38-pytest
CodeReady Linux Builder リポジトリーの詳細は、「How to enable and make use of content within CodeReady Linux Builder」を参照してください。
15.2.2. Python 2 のインストール
一部のソフトウェアは Python 3 に完全には移植されておらず、動作するのに Python 2 が必要となります。Red Hat Enterprise Linux 8 では、Python 3 と Python 2 を同時にインストールできます。Python 2 機能が必要な場合は python27
モジュールをインストールしてください。これは AppStream リポジトリーから入手できます。
Python 3 は、Python プロジェクトの主な開発方針です。Python 2 のサポートは終了しつつあります。python27
モジュールは、Red Hat Enterprise Linux 8 でのサポート期間が短くなります。
手順
python27
モジュールから Python 2.7 をインストールするには、以下のコマンドを実行します。# yum install python2
python27:2.7 モジュールストリームは、自動的に有効になります。
設計上、python27
、python36
、python38
モジュールなど、RHEL 8 モジュールを同時にインストールできます。
モジュールの詳細は『ユーザー空間コンポーネントのインストール、管理、および削除』を参照してください。
Python 2 用のアドオンモジュールのパッケージは、通常、接頭辞 python2-
を使用します。以下の例にあるように、追加の Python パッケージのインストール時には常に接頭辞を含めます。
手順
Python 2 の
Requests
モジュールをインストールするには、以下のコマンドを実行します。# yum install python2-requests
Python 2 に
Cython
拡張をインストールするには、以下を使用します。# yum install python2-Cython
15.2.3. Python 3 の使用
Python インタープリターまたは Python 関連のコマンドを実行する場合は、常にバージョンを指定します。
手順
Python 3.6 インタープリターまたは関連コマンドを実行するには、以下を使用します。
$ python3 $ python3 -m cython --help $ pip3 install <package>
Python 3.8 インタープリターまたは関連コマンドを実行するには、以下を使用します。
$ python3.8 $ python3.8 -m cython --help $ pip3.8 install <package>
15.2.4. Python 2 の使用
Python 2 インタープリターまたは Python2 関連のコマンドを実行する場合は、常にバージョンを指定します。
手順
Python 2 インタープリターまたは関連コマンドを実行するには、以下を使用します。
$ python2 $ python2 -m cython --help $ pip2 install <package>
15.2.5. バージョンを指定しない Python の設定
システム管理者は、alternatives
コマンドを使用して、/usr/bin/python
に、バージョンを管理しない python
コマンドを設定できます。必要なパッケージ (python3
、python38
、または python2
) は、バージョンを指定しないコマンドを各バージョンに設定する前にインストールする必要があります。
/usr/bin/python
実行ファイルは 代替
システムによって制御されます。更新時に手動の変更が上書きされる可能性があります。
その他の Python 関連のコマンド (pip3
など) には、バージョンを指定しないで設定できるバリアントがあります。
15.2.5.1. バージョンを指定しない python コマンドを直接設定
バージョンを指定しない python
コマンドを、選択した Python バージョンに直接設定するには、以下の手順に従います。
手順
バージョンを指定しない
python
コマンドを Python 3.6 に設定するには、以下のコマンドを実行します。# alternatives --set python /usr/bin/python3
バージョンを指定しない
python
コマンドを Python 3.8 に設定するには、以下のコマンドを使用します。# alternatives --set python /usr/bin/python3.8
バージョンを指定しない
python
コマンドを Python 2 に設定するには、以下のコマンドを実行します。# alternatives --set python /usr/bin/python2
15.2.5.2. バージョンを指定しない python コマンドを、必要な Python バージョンに対話的に設定する
バージョンを指定しない python
コマンドを、必要な Python バージョンに対話的に設定することもできます。
バージョンを指定しない python
コマンドを対話的に設定するには、この手順を使用します。
手順
以下のコマンドを実行します。
# alternatives --config python
- 表示された一覧から必要なバージョンを選択します。
この設定をリセットし、バージョンを指定しない
python
をコマンドを削除するには、以下のコマンドを実行します。# alternatives --auto python
15.3. Python 2 から Python 3 への移行
開発者は、Python 2 で記述したコードを Python 3 に移行できます。大規模なコードベースを Python 3 に移行する方法は「The Conservative Python 3 Porting Guide」を参照してください。
この移行が終了すると、元の Python 2 コードは Python 3 インタープリターにより解釈できるようになり、同様に Python 2 インタープリターは解釈できるままとなることに注意してください。
15.4. Python 3 RPM のパッケージング
ほとんどの Python プロジェクトは、パッケージ化に Setuptools を使用して、setup.py
ファイルにパッケージ情報を定義します。Setuptools パッケージ化の詳細は Setuptools ドキュメントを参照してください。
Python プロジェクトを RPM パッケージにパッケージ化することもできます。これには、Setuptools パッケージ化と比較して以下の利点があります。
- その他の RPM のパッケージの依存関係の指定 (Python 以外も含む)
電子署名
電子署名を使用すると、RPM パッケージの内容は、オペレーティングシステムのその他の部分とともに検証、統合、およびテストできます。
15.4.1. Python パッケージ用の SPEC ファイルの説明
SPEC ファイルには、RPM の構築に rpmbuild
ユーティリティーを使用する命令が含まれています。命令は、一連のセクションに含まれています。SPEC ファイルには、セクションが定義されている 2 つの主要部分があります。
- プリアンブル (ボディーに使用されている一連のメタデータ項目が含まれています)
- ボディー (命令の主要部分が含まれています)
SPEC ファイルの詳細は、『ソフトウェアのパッケージ化と配布』 を参照してください。
Python プロジェクトの RPM SPEC ファイルには、非 Python RPM SPEC ファイルと比較していくつかの詳細があります。特に注目すべきは、Python ライブラリーの RPM パッケージ名に、Python 3.6 の場合は python3
、Python 3.8 の場合は python38
など、バージョンを判断できる接頭辞を常に含める必要があります。
その他の詳細は、次の SPEC ファイルの python3-detox
パッケージの例 に記載されています。その詳細の説明は、例の下に記載されている注意事項を参照してください。
%global modname detox 1 Name: python3-detox 2 Version: 0.12 Release: 4%{?dist} Summary: Distributing activities of the tox tool License: MIT URL: https://pypi.io/project/detox Source0: https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz BuildArch: noarch BuildRequires: python36-devel 3 BuildRequires: python3-setuptools BuildRequires: python36-rpm-macros BuildRequires: python3-six BuildRequires: python3-tox BuildRequires: python3-py BuildRequires: python3-eventlet %?python_enable_dependency_generator 4 %description Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel. Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox. $ detox %prep %autosetup -n %{modname}-%{version} %build %py3_build 5 %install %py3_install %check %{__python3} setup.py test 6 %files -n python3-%{modname} %doc CHANGELOG %license LICENSE %{_bindir}/detox %{python3_sitelib}/%{modname}/ %{python3_sitelib}/%{modname}-%{version}* %changelog ...
- 1
- modname マクロには、Python プロジェクトの名前が含まれます。この例では
detox
となります。 - 2
- Python プロジェクトを RPM にパッケージ化する場合は、常にプロジェクトの元の名前に接頭辞
python3
を追加する必要があります。ここでの元の名前はdetox
で、RPM の名前 はpython3-detox
です。 - 3
- BuildRequires は、このパッケージのビルドおよびテストに必要なパッケージを指定します。BuildRequires では、Python パッケージをビルドするのに必要なツールを提供する項目 (
python36-devel
およびpython3-setuptools
) が常に含まれます。/usr/bin/python3
shebangs があるファイルが自動的に/usr/bin/python3.6
に変更するようにするには、python36-rpm-macros
パッケージが必要です。詳細は「Python スクリプトにおける hashbang の処理」を参照してください。 - 4
- すべての Python パッケージが正しく動作するためには、その他のパッケージがいくつか必要です。このようなパッケージも、SPEC ファイルで指定する必要があります。依存関係を指定するには、%python_enable_dependency_generator マクロを使用して、
setup.py
ファイルに定義した依存関係を自動的に使用できます。パッケージに、Setuptools で指定していない依存関係がある場合は、追加のRequires
ディレクティブ内に指定します。 - 5
- %py3_build マクロおよび %py3_install マクロは、
setup.py build
コマンドおよびsetup.py install
コマンドを実行します。それぞれには、インストール場所、使用するインタープリター、その他の詳細を指定する引数を用います。 - 6
- check セクションは、Python の正しいバージョンを実行するマクロを提供します。%{__python3} マクロには、Python 3 インタープリターのパス (
/usr/bin/python3
など) が含まれます。リテラルパスではなく、マクロを使用することが常に推奨されます。
15.4.2. Python 3 RPM の一般的なマクロ
SPEC ファイルでは、常にその値をハードコーディングするのではなく、以下のマクロを使用します。
マクロ名では、バージョンを指定しない python
ではなく、python3
または python2
を使用してください。SPEC ファイルの BuildRequires
で、特定の Python 3 バージョンを python36-rpm-macros
または python38-rpm-macros
のいずれかに設定します。
マクロ | 一般的な定義 | 説明 |
---|---|---|
%{__python3} | /usr/bin/python3 | Python 3 のインタープリター |
%{python3_version} | 3.6 | Python 3 インタープリターのフルバージョン |
%{python3_sitelib} | /usr/lib/python3.6/site-packages | pure-Python モジュールのインストール先 |
%{python3_sitearch} | /usr/lib64/python3.6/site-packages | アーキテクチャー固有の拡張を含むモジュールがインストールされている場合 |
%py3_build |
システムパッケージに適した引数で | |
%py3_install |
システムパッケージに適した引数で |