Red Hat Training

A Red Hat training course is available for RHEL 8

基本的なシステム設定の構成

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8 で基本的なシステム設定を構成するためのガイド

概要

本書は、Red Hat Enterprise Linux 8 におけるシステム管理の基本を説明します。ここでは、システム管理者が、オペレーティングシステムをインストールした直後に行う必要がある基本的なタスク (yum を使用したソフトウェアのインストール、systemd を使用したサービスの管理、ユーザー、グループ、およびファイルのパーミッションの管理、そして chrony を使用した NTP の構成、Python 3 の使用など) を説明します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージをご覧ください。

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。

  • 特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトに移動します。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 RHEL システムロールの使用

本セクションでは、RHEL システムロールの概要を説明します。また、Ansible Playbook を使用して特定のロールを適用し、さまざまなシステム管理タスクを実行する方法を説明します。

1.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 パッケージで提供されます。

1.2. RHEL システムロールの用語

このドキュメントでは、以下の用語を確認できます。

システムロールの用語

Ansible Playbook
Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語です。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。
コントロールノード
Ansible がインストールされているマシン。コマンドおよび Playbook を実行でき、すべてのコントロールノードから /usr/bin/ansible または /usr/bin/ansible-playbook を起動します。Python がインストールされているすべてのコンピューターをコントロールノードとして使用できます。ラップトップ、共有デスクトップ、およびサーバーですべての Ansible を実行できます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを使用できます。
インベントリー
管理対象ノードの一覧。インベントリーファイルは「ホストファイル」とも呼ばれます。インベントリーでは、各管理対象ノードに対して IP アドレスなどの情報を指定できます。また、インベントリーは管理ノードを編成し、簡単にスケーリングできるようにグループの作成およびネスト化が可能です。インベントリーについての詳細は、「インベントリーの操作」セクションを参照してください。
管理ノード
Ansible で管理するネットワークデバイス、サーバー、またはその両方。管理対象ノードは、「ホスト」と呼ばれることもあります。Ansible が管理ノードにはインストールされません。

1.3. ロールの適用

以下の手順では、特定のロールを適用する方法を説明します。

前提条件

  • rhel-system-roles パッケージが、コントロールノードとして使用するシステムにインストールされていることを確認します。

    # yum install rhel-system-roles
  • RHEL システムロールを使用する Playbook を実行するには、ansible パッケージが必要です。Ansible Engine リポジトリーが有効になり、コントロールノードとして使用するシステムに ansible パッケージがインストールされていることを確認します。

    • Red Hat Ansible Engine サブスクリプションをお持ちでない場合は、Red Hat Enterprise Linux サブスクリプションで提供される Red Hat Ansible Engine の限定サポートバージョンをご利用できます。この場合は、次の手順を実行します。

      1. RHEL Ansible Engine リポジトリーを有効にします。

        # subscription-manager refresh
        # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
      2. Ansible Engine をインストールします。

        # yum install ansible
    • Red Hat Ansible Engine サブスクリプションをお持ちの場合は、「Red Hat Ansible Engine のダウンロードおよびインストール方法 」に記載されている手順を行ってください。
  • Ansible インベントリーを作成できることを確認します。

    インベントリーは、ホスト、ホストグループ、および Ansible Playbook で使用されるいくつかの設定パラメーターを表します。

    Playbook は通常人が判読でき、iniyamljson、およびその他のファイル形式で定義されます。

  • Ansible Playbook を作成できることを確認します。

    Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語を表します。Playbook を使用すると、リモートマシンの設定を宣言して管理したり、複数のリモートマシンをデプロイしたり、手動で順番を付けたプロセスの手順をまとめたりできます。

    Playbook は、1 つ以上の play の一覧です。すべての play には、Ansible の変数、タスク、またはロールが含まれます。

    Playbook は人が判読でき、yaml 形式で定義されます。

手順

  1. 管理するホストおよびグループを含む必要な Ansible インベントリーを作成します。以下の例は、webservers と呼ばれるホストのグループの inventory.ini というファイルを使用します。

    [webservers]
    host1
    host2
    host3
  2. 必要なロールを含む Ansible Playbook を作成します。以下の例では、Playbook の roles: オプションを使用してロールを使用する方法を示しています。

    以下の例は、特定の playroles: オプションを使用してロールを使用する方法を示しています。

    ---
    - hosts: webservers
      roles:
         - rhel-system-roles.network
         - rhel-system-roles.timesync
    注記

    すべてのロールには README ファイルが含まれます。このファイルには、ロールや、サポートされるパラメーター値の使用方法が記載されています。ロールのドキュメントディレクトリーで、特定ロール用の Playbook のサンプルを見つけることもできます。このようなドキュメンテーションディレクトリーは、rhel-system-roles パッケージでデフォルトで提供され、以下の場所に置かれます。

    /usr/share/doc/rhel-system-roles/SUBSYSTEM/

    SUBSYSTEM は、selinuxkdumpnetworktimesync、または storage などの必要なロールの名前に置き換えます。

  3. 特定のホストで Playbook を実行するには、以下のいずれかを実行する必要があります。

    • Playbook でホスト(host1[,host2,…​]、または hosts: all )を使用するように編集し、以下のコマンドを実行します。

      # ansible-playbook name.of.the.playbook
    • インベントリーを編集して、使用するホストがグループで定義されていることを確認し、以下のコマンドを実行します。

      # ansible-playbook -i name.of.the.inventory name.of.the.playbook
    • ansible-playbook コマンドの実行時にすべてのホストを指定します。

      # ansible-playbook -i host1,host2,... name.of.the.playbook
      重要

      -i フラグは、利用可能なすべてのホストのインベントリーを指定することに注意してください。ターゲットホストが複数あるが、Playbook を実行するホストを選択する場合は、Playbook に変数を追加して、ホストを選択できるようにすることができます。以下に例を示します。

      Ansible Playbook | example-playbook.yml:
      
      - hosts: "{{ target_host }}"
        roles:
           - rhel-system-roles.network
           - rhel-system-roles.timesync

      Playbook 実行コマンド:

      # ansible-playbook -i host1,..hostn -e target_host=host5 example-playbook.yml

1.4. 関連情報



[1] 本書は rhel-system-roles パッケージで自動的にインストールされます。

第2章 基本的な環境設定の変更

基本的な環境設定は、インストールプロセスの一部です。以下のセクションでは、後での変更する時に説明します。環境の基本設定には、以下が含まれます。

  • 日付と時刻
  • システムロケール
  • キーボードのレイアウト
  • 言語

2.1. 日付および時刻の設定

正確な時間を維持することは、さまざまな理由で重要です。Red Hat Enterprise Linux では、NTP プロトコルにより、時間管理が保証されます。これは、デーモンにより、ユーザー領域に実装されます。ユーザー領域のデーモンは、カーネルで実行しているシステムクロックを更新します。システムクロックは、さまざまなクロックソースを使用して時間を維持します。

Red Hat Enterprise Linux 8 は、chronyd デーモンを使用して NTP を実装します。chronyd は、 chrony パッケージ化できます。詳細は「chrony スイートを使用した NTP の設定 」を参照してください。

2.1.1. システムの現在日時の表示

現在の日時を表示するには、以下のいずれかの手順を行います。

手順

  1. date コマンドを実行します。

    $ date
    Mon Mar 30 16:02:59 CEST 2020
  2. 詳細は、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

関連情報

2.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

関連情報

  • man localectl(1)man locale(7)、および man locale.conf(5)

2.3. キーボードレイアウトの設定

キーボードレイアウト設定では、テキストコンソールとグラフィカルユーザーインターフェースで使用するレイアウトを管理します。

手順

  • 利用可能なキーマップを一覧表示するには、以下を実行します。

    $ localectl list-keymaps
    ANSI-dvorak
    al
    al-plisi
    amiga-de
    amiga-us
    ...
  • キーマップ設定の現在のステータスを表示するには、次のコマンドを実行します。

    $ localectl status
    ...
    VC Keymap: us
    ...
  • デフォルトのシステムキーマップを設定または変更します。以下に例を示します。

    # localectl set-keymap us

関連情報

  • man localectl(1)man locale(7)、および man locale.conf(5)

2.4. デスクトップ GUI を使用した言語の変更

本セクションでは、デスクトップ GUI を使用してシステム言語を変更する方法を説明します。

前提条件

  • システムに必要な言語パッケージがインストールされている。

手順

  1. システムメニュー からアイコンをクリックして GNOME コントロールセンター を開きます。

    cs system menu

  2. GNOME Control Center で、左側の垂直バーから 地域および言語 を選択します。
  3. 言語 メニューをクリックします。

    cs language menu

  4. メニューから必要な地域および言語を選択します。

    cs select region language

    該当する地域および言語が表示されない場合はスクロールダウンし、詳細 をクリックして、利用可能な地域および言語を選択します。

    cs available region language

  5. 完了 をクリックします。
  6. 再起動 をクリックして変更を有効にします。

    cs restart region language

注記

アプリケーションによっては、特定の言語に対応していないものもあります。選択した言語に翻訳できないアプリケーションのテキストは、アメリカ英語のままになります。

2.5. 関連情報

第3章 ネットワークアクセスの設定および管理

本セクションでは、Red Hat Enterprise Linux でイーサネット接続を追加するさまざまなオプションを説明します。

3.1. グラフィカルインストールモードでのネットワークおよびホスト名の設定

以下の手順に従って、ネットワークとホスト名を設定します。

手順

  1. インストール概要 画面から、ネットワークとホスト名 をクリックします。
  2. 左側のペインのリストから、インターフェースを選択します。詳細が右側のペインに表示されます。
  3. 選択したインタフェースを有効または無効にするには、ON/OFF スイッチを切り替えます。

    注記

    インストールプログラムは、ローカルでアクセス可能なインターフェースを自動的に検出し、手動で追加または削除できません。

  4. + をクリックして、仮想ネットワークインターフェースを追加します。仮想ネットワークインターフェースは、チーム、ボンド、ブリッジ、または VLAN のいずれかです。
  5. - を選択して、仮想インターフェースを削除します。
  6. 設定 をクリックして、既存のインターフェースの IP アドレス、DNS サーバー、またはルーティング設定 (仮想と物理の両方) などの設定を変更します。
  7. ホスト名 フィールドに、システムのホスト名を入力します。

    注記
    • em1wl3sp0 といった一貫性のある名前をネットワークデバイスの特定に使用するネットワークデバイス命名の標準仕様には、いくつかのタイプがあります。これらの標準仕様の詳細は『ネットワークの設定および管理』を参照してください
    • ホスト名は、hostname.domainname という形式の完全修飾ドメイン名 (FQDN) か、ドメイン名のない短縮ホスト名のいずれかとなります。多くのネットワークには、自動的に接続したシステムにドメイン名を提供する DHCP (Dynamic Host Configuration Protocol) サービスがあります。DHCP サービスが、このマシンにドメイン名を割り当てるようにするには、短縮ホスト名のみを指定してください。localhost.localdomain の値は、ターゲットシステムの静的ホスト名が指定されておらず、(たとえば、DHCP または DNS を使用する NetworkManager による) ネットワーク設定時に、インストールされるシステムの実際のホスト名が設定されることを示しています。
    • ホスト名には、英数字および - または のみを使用できます。ホスト名は、- および で起動または終了することはできません
  8. 適用 をクリックして、ホスト名を環境に適用します。
  9. また、ネットワークおよびホスト名 画面では、ワイヤレスオプションを選択できます。右側のペインで ネットワークの選択 をクリックして Wifi 接続を選択します。必要に応じてパスワードを入力し、完了 をクリックします。

3.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

手順

  1. Ethernet 接続の NetworkManager 接続プロファイルを新たに追加します。

    # nmcli connection add con-name Example-Connection ifname enp7s0 type ethernet

    以下の手順は、作成した Example-Connection 接続プロファイルを変更します。

  2. IPv4 アドレスを設定します。

    # nmcli connection modify Example-Connection ipv4.addresses 192.0.2.1/24
  3. IPv6 アドレスを設定します。

    # nmcli connection modify Example-Connection ipv6.addresses 2001:db8:1::1/64
  4. IPv4 および IPv6 接続メソッドを manual に設定します。

    # nmcli connection modify Example-Connection ipv4.method manual
    # nmcli connection modify Example-Connection ipv6.method manual
  5. IPv4 および IPv6 のデフォルトゲートウェイを設定します。

    # nmcli connection modify Example-Connection ipv4.gateway 192.0.2.254
    # nmcli connection modify Example-Connection ipv6.gateway 2001:db8:1::fffe
  6. IPv4 および 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 サーバーを設定するには、空白で区切って引用符で囲みます。

  7. IPv4 および IPv6 接続の DNS 検索ドメインを設定します。

    # nmcli connection modify Example-Connection ipv4.dns-search example.com
    # nmcli connection modify Example-Connection ipv6.dns-search example.com
  8. 接続プロファイルをアクティベートします。

    # nmcli connection up Example-Connection
    Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/13)

検証手順

  1. デバイスおよび接続の状態を表示します。

    # nmcli device status
    DEVICE      TYPE      STATE      CONNECTION
    enp7s0      ethernet  connected  Example-Connection
  2. 接続プロファイルのすべての設定を表示するには、次のコマンドを実行します。

    # 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
    ...
  3. 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
  4. host ユーティリティーを使用して名前解決が機能することを確認します。以下に例を示します。

    # host client.example.com

    connection timed outno servers could be reached など、コマンドがエラーを返した場合は、DNS 設定を確認してください。

トラブルシューティングの手順

  1. 接続に失敗するか、ネットワークインターフェースが up と down の状態の間で切り替わる場合は、以下を行います。

    • ネットワークケーブルがホストとスイッチにプラグインされていることを確認します。
    • リンクの失敗がこのホストのみに存在するか、またはサーバーの接続先と同じスイッチに接続されている他のホストでも存在するかどうかを確認します。
    • ネットワークケーブルとネットワークインターフェースが予想どおりに機能していることを確認します。ハードウェア診断手順を実施して、不具合ケーブルとネットワークインターフェースカードを置き換えます。
    • ディスクの設定がデバイスの設定と一致しない場合は、NetworkManager を起動するか再起動して、インメモリー接続を作成することで、デバイスの設定を反映します。この問題を回避する方法および詳細は、「NetworkManager duplicates a connection after restart of NetworkManager service」を参照してください。

3.3. nmtui を使用した接続プロファイルの追加

nmtui アプリケーションで、NetworkManager へのテキストユーザーインターフェースが含まれます。この手順では、新しい接続プロファイルを追加する方法を説明します。

前提条件

  • NetworkManager-tui パッケージがインストールされている。

手順

  1. NetworkManager のテキストユーザーインターフェースユーティリティーを起動します。

    # nmtui
  2. 接続の編集 メニューエントリーを選択し、Enter を押します。
  3. Add ボタンを選択し、Enter を押します。
  4. Ethernet を選択し、Enter を押します。
  5. フィールドにコネクションの詳細を入力します。

    add connection in nmtui
  6. OK をクリックして変更を保存します。
  7. Back を選択してメインメニューに戻ります。
  8. Activate a connection を選択し、Enter を押します。
  9. 新しい接続エントリーを選択し、Enter を押して接続をアクティベートします。
  10. Back を選択してメインメニューに戻ります。
  11. Quit を選択します。

検証手順

  1. デバイスおよび接続の状態を表示します。

    # nmcli device status
    DEVICE      TYPE      STATE      CONNECTION
    enp1s0      ethernet  connected  Example-Connection
  2. 接続プロファイルのすべての設定を表示するには、次のコマンドを実行します。

    # 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
    ...

    ディスクの設定がデバイスの設定と一致しない場合は、NetworkManager を起動するか再起動して、インメモリー接続を作成することで、デバイスの設定を反映します。この問題を回避する方法および詳細は、「NetworkManager duplicates a connection after restart of NetworkManager service 」を参照してください。

    関連情報

3.4. RHEL 8 Web コンソールにおけるネットワークの管理

Web コンソールの Networking メニューでは、以下が可能です。

  • 最近送受信したパケットの表示
  • 利用可能なネットワークインターフェースの最も重要な特徴の表示
  • ネットワーキングログのコンテンツの表示
  • ネットワークインターフェースのさまざまなタイプ (ボンディング、チーム、ブリッジ、VLAN) の追加

図3.1 RHEL 8 Web コンソールにおけるネットワークの管理

cs getting started networking new

3.5. RHEL システムロールを使用したネットワークの管理

network ロールを使用して、複数のターゲットマシンにネットワーク接続を構成できます。

network ロールでは、以下のタイプのインターフェースを構成できます。

  • イーサネット
  • ブリッジ
  • ボンディング
  • VLAN
  • MacVLAN
  • Infiniband

各ホストに必要なネットワーク接続は、network_connections 変数内にリストとして提供されます。

警告

network ロールは、network_connections 変数で指定されているとおりに、ターゲットシステムにあるすべての接続プロファイルを更新または作成します。したがって、そのオプションがそのシステムにのみ存在し、network_connections 変数にはない場合、network ロールは指定されたプロファイルからオプションを削除します。

以下の例は、必要なパラメーターを持つイーサネット接続が確実に設定されるように、network ロールを適用する方法を示しています。

必要なパラメーターでイーサネット接続を設定する 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

3.6. 関連情報

第4章 システム登録およびサブスクリプション管理

Red Hat Enterprise Linux オペレーティングシステムと、そこにインストールされている製品は、サブスクリプションの対象となります。

Red Hat コンテンツ配信ネットワーク (CDN) サブスクリプションを使用して、以下を追跡します。

  • 登録したシステム
  • システムにインストールされている製品
  • インストール済みの製品に割り当てられているサブスクリプション

4.1. インストール後のシステムの登録

インストールプロセス中にシステムを登録していない場合は、以下の手順に従って登録します。

前提条件

手順

  1. ワンステップでシステムを登録し、自動的にサブスクライブします。

    # 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 カスタマーポータルのユーザー名とパスワードの入力を求めるプロンプトが表示されます。

    登録プロセスに失敗した場合は、システムを特定のプールに登録できます。これを実行する方法については、以下の手順に従います。

    1. 必要なサブスクリプションのプール ID を確認します。

      # subscription-manager list --available

      このコマンドは、使用している Red Hat アカウントで利用可能なサブスクリプションをすべて表示します。サブスクリプションごとに、プール ID を含むさまざまな情報が表示されます。

    2. pool_id を、確認したプール ID に置き換えて、適切なサブスクリプションをシステムに割り当てます。

      # subscription-manager attach --pool=pool_id

4.2. Web コンソールで認証情報を使用してサブスクリプションを登録

RHEL 8 Web コンソールを使用して、新たにインストールした Red Hat Enterprise Linux を登録するには、以下の手順に従います。

前提条件

手順

  1. 検索フィールドに「subscription」と入力して、Enter キーを押します。

    cockpit subscription icon

    RHEL 8 Web コンソールにログインすることもできます。詳細は「Web コンソールへのログイン 」を参照してください。

  2. 特権タスク用の polkit 認証ダイアログで、ダイアログに表示されているユーザー名のパスワードを入力します。

    cockpit subscription password

  3. 認証 をクリックします。
  4. サブスクリプション ダイアログボックスの 登録 をクリックします。

    cockpit subscription notregistered

  5. カスタマーポータルの認証情報を入力します。

    cockpit subscription register cred

  6. 組織の名前を入力してください。

    Red Hat カスタマーポータルにアカウントが複数ある場合は、組織名または組織 ID を追加する必要があります。組織 ID は、Red Hat の連絡先に問い合わせてください。

  7. 登録 ボタンをクリックします。

この時点で、Red Hat Enterprise Linux 8 システムが正常に登録されました。

cockpit subscription registered

4.3. GNOME での Red Hat アカウントを使用したシステム登録

以下の手順に従って、システムを Red Hat アカウントに登録します。

前提条件

手順

  1. 画面右上からアクセスできる システムメニュー に移動し、設定 アイコンをクリックします。
  2. DetailsAbout セクションで、Register をクリックします。
  3. Registration Server を選択します。
  4. Red Hat サーバーを使用しない場合は、URL フィールドにサーバーアドレスを入力します。
  5. Registration Type メニューで、Red Hat Account を選択します。
  6. Registration Details で以下を行います。

    • Login フィールドに Red Hat アカウントのユーザー名を入力します。
    • Password フィールドに Red Hat アカウントのパスワードを入力します。
    • Organizaiton フィールドに組織の名前を入力します。
  7. Register をクリックします。

4.4. GNOME でのアクティベーションキーを使用したシステム登録

以下の手順に従って、システムをアクティベーションキーに登録します。組織の管理者からアクティベーションキーを取得できます。

前提条件

手順

  1. 画面右上からアクセスできる システムメニュー に移動し、設定 アイコンをクリックします。
  2. DetailsAbout セクションで、Register をクリックします。
  3. Registration Server を選択します。
  4. Red Hat サーバーを使用していない場合は、カスタマイズされたサーバーに URL を入力します。
  5. Registration Type メニューで、Activation keys を選択します。
  6. Registration Details で以下を行います。

    • Activation keys を入力します。

      複数の鍵をコンマ (,) で区切ります。

    • 組織 フィールドに組織の名前または ID を入力します。
  7. Register をクリックします。

4.5. インストーラー GUI を使用した RHEL 8.4 の登録

RHEL インストーラー GUI を使用して新たにインストールした Red Hat Enterprise Linux 8.4 を登録するには、以下の手順に従います。

前提条件

  • Red Hat カスタマーポータルに有効なユーザーアカウントがある。「Red Hat アカウントの作成」ページを参照してください

    ユーザーアカウントに適切なエンタイトルメントがある場合(またはアカウントが Simple Content Access モードで動作)、それらはアクティベーションキーを表示せずにユーザー名とパスワードを使用して登録できます。

  • 有効なアクティベーションキーおよび組織 ID

Procedure

  1. Account または Activation Key オプションを使用して、Red Hat アカウントを認証します。

    RHEL 8.4 registration

  2. Set System Purpose フィールドを選択し、ドロップダウンメニューから RHEL 8.4 インストールの ロール、SLA、使用方法 を選択します。

    rhel 8.4 system subscription step 4

    この時点で、Red Hat Enterprise Linux 8.4 システムが正常に登録されました。

第5章 システム起動時に systemd サービスの開始

systemd は、Linux オペレーティングシステム用のシステムおよびサービスのマネージャーで、systemd ユニットの概念が使用されています。

本セクションでは、システムの起動時にサービスを有効または無効にする方法を説明します。また、Web コンソールを使用してサービスを管理する方法も説明します。

5.1. サービスの有効化または無効化

インストールプロセスの際、システムの起動時にすでに有効化または無効化されているサービスを確認できます。インストール後に、オペレーティングシステムのサービスを有効または無効にできます。

本セクションでは、インストール済みのオペレーティングシステムでこれらのサービスを有効または無効にする手順を説明します。

前提条件

  • システムへの root アクセス権限がある。

手順

  1. サービスを有効にするには、enable オプションを使用します。

    # systemctl enable service_name

    service_name は、有効にするサービスに置き換えます。

    1 つのコマンドでサービスを有効にして起動することもできます。

    # systemctl enable --now service_name
  2. サービスを無効にするには、disable オプションを使用します。

    # systemctl disable service_name

    service_name は、無効にするサービスに置き換えます。

警告

以前マスクされたサービスを有効化できません。最初にマスクを解除する必要があります。

# systemctl unmask service_name

5.2. RHEL 8 Web コンソールにおけるサービスの管理

本セクションでは、Web コンソールを使用してサービスを有効または無効にする方法を説明します。systemd ターゲット、サービス、ソケット、タイマー、およびパスを管理できます。また、サービスのステータス、開始または停止を確認し、サービスを有効または無効にすることもできます。

前提条件

  • システムへの root アクセス権限がある。

手順

  1. 任意の Web ブラウザーでhttps://localhost:9090/ を開きます。
  2. システム上の root 認証情報を使用して Web コンソールにログインします。
  3. Web コンソールパネルを表示するには、ウィンドウの左上にある ホスト アイコンをクリックします。

    managing services web console
  4. メニューで、Services をクリックします。

    systemd ターゲット、サービス、ソケット、タイマー、およびパスを管理できます。

  5. たとえば、サービスの NFS クライアントサービス を管理するには、以下を実行します。

    1. Targets をクリックします。
    2. NFS Client Services のサービスを選択します。
    3. サービスを有効または無効にするには、Toogle ボタンをクリックします。
    4. サービスを停止するには、⫶ ボタンをクリックし、option Stop を選択します。

      stopping service web console

第6章 システムセキュリティーの設定

コンピューターセキュリティーとは、盗難、損傷、破壊、および誤りからコンピューターシステムやハードウェア、ソフトウェア、情報、およびサービスを保護することです。機密データを処理してビジネス取引を扱う企業では特に、コンピューターセキュリティーの確保は必須タスクです。

本セクションでは、オペレーティングシステムのインストール後に設定できる基本的なセキュリティー機能のみを説明します。

6.1. ファイアウォールサービスの有効化

ファイアウォールは、既定のセキュリティールールに基づいてネットワークトラフィックの送受信の監視および制御を行うネットワークセキュリティーシステムです。ファイアウォールは、通常、信頼できる安全な内部ネットワークと、その他の外部ネットワークとの間に壁を作ります。

Red Hat Enterprise Linux でファイアウォールを提供する firewalld サービスは、インストール時に自動的に有効になります。

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)
    ...

関連情報

6.2. RHEL 8 Web コンソールでファイアウォールの管理

Web コンソールで firewalld サービスを設定するには、ネットワークファイアウォール に移動します。

デフォルトでは、firewalld サービスは有効になっています。

手順

  1. Web コンソールで firewalld を有効または無効にするには、ファイアウォール のトグルボタンを切り替えます。

    cs getting started firewall new
注記

さらに、Add services…​ ボタンを使用して、ファイアウォール経由でのサービスへのアクセスをより詳細にわたり定義できます。

6.3. 基本的な selinux 設定の管理

Security Enhanced Linux (SELinux) は、どのプロセスがどのファイル、ディレクトリー、およびポートにアクセスできるのかを指定するシステムセキュリティーの追加レイヤーです。これらのパーミッションは、SELinux ポリシーで定義します。ポリシーは、SELinux セキュリティーエンジンをガイドする一連のルールです。

SELinux のステータスには、以下の 2 つがあります。

  • 無効
  • 有効

SELinux が有効な場合は、以下のいずれのモードで実行できます。

  • 有効

    • Enforcing
    • Permissive

Enforcing モード では、SELinux は読み込まれたポリシーを強制的に実行します。SELinux は、SELinux ポリシールールに基づいてアクセスを拒否し、明示的に許可された対話だけを有効にします。Enforcing モードは最も安全な SELinux モードであり、インストール後のデフォルトモードです。

Permissive モード では、SELinux は読み込まれたポリシーを強制に実行しません。SELinux はアクセスを拒否しませんが、ルールに違反するアクションを /var/log/audit/audit.log ログで報告します。Permissive モードは、インストール時のデフォルトのモードです。Permissive モードは、問題のトラブルシューティングなど、特定のケースで役に立ちます。

関連情報

6.4. SELinux の必要な状態の確認

デフォルトでは、SELinux は Enforcing モードで動作します。ただし、特定のシナリオでは、SELinux を Permissive モードに設定したり、無効にしたりすることもできます。

重要

Red Hat は、Enforcing モードでシステムを使用することを推奨します。デバッグの目的で、SELinux を Permissive モードに設定します。

以下の手順に従って、システムの SELinux の状態とモードを変更します。

手順

  1. 現在有効な SELinux モードを表示します。

    $ getenforce
  2. SELinux を一時的に設定します。

    1. Enforcing モードに設定する場合:

      # setenforce Enforcing
    2. Permissive モードに設定する場合:

      # setenforce Permissive
      注記

      再起動後に、SELinux モードは /etc/selinux/config 設定ファイルで指定された値に設定されます。

  3. 再起動後も 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=0 パラメーターをカーネルコマンドラインに追加すると、システムの起動時に SELinux モードの変更が、SELinux を無効にします。

6.5. RHEL 8 Web コンソールで SELinux モードの切り替え

SELinux メニュー項目の RHEL 8 Web コンソールで SELinux モードを設定できます。

デフォルトでは、Web コンソールの SELinux の Enforcing ポリシーが有効になっており、SELinux が Enforcing モードで動作します。このモードを無効にして、SELinux を Permissive モードに切り替えます。モードの選択は、次回の起動時に /etc/sysconfig/selinux ファイルで定義されている設定に自動的に元に戻されます。

手順

  1. Web コンソールで、SELinux メニュー項目の Enforce policy トグルボタンを使用して SELinux の Enforcing ポリシーをオンまたはオフにします。

    cs getting started selinux on

6.6. 関連情報

第7章 ユーザーアカウントの管理

Red Hat Enterprise Linux は、マルチユーザー向けのオペレーティングシステムです。つまり、1 台のマシンにインストールされた 1 つのシステムに、複数のユーザーが別々のコンピューターからアクセスできます。各ユーザーは自身のアカウントで操作します。このような方法でユーザーアカウントを管理することは、Red Hat Enterprise Linux のシステム管理の中心的要素になります。

以下に各種ユーザーアカウントを紹介します。

  • 通常のユーザーアカウント

    通常のアカウントは特定システムのユーザー用に作成されます。このようなアカウントは、通常のシステム管理中に追加、削除、および修正できます。

  • システムユーザーアカウント:

    システムユーザーアカウントは、システムで特定のアプリケーション識別子を表します。このようなアカウントは通常、ソフトウェアのインストール時にのみ追加または操作され、後で変更することはありません。

    警告

    システムアカウントは、システムでローカルに利用できると想定されています。アカウントがリモートで設定され、提供されている (LDAP の設定など) と、システムが破損したり、サービスが開始できない場合があります。

    システムアカウント用に、1000 番未満のユーザー ID が予約されています。通常のアカウントには、1000 から始まる ID を使用できます。ただし、5000 以降の ID を割り当てることが推奨されます。ID の割り当ては、/etc/login.defs ファイルを参照してください。

  • グループ:

    グループとは、複数のユーザーアカウントを共通目的 (特定のファイルにアクセス権を与えるなど) で統合するエンティティーです。

7.1. コマンドラインツールを使用したアカウントとグループの管理

本セクションでは、ユーザーアカウントとグループを管理する基本的なコマンドラインツールを説明します。

  • ユーザーおよびグループ 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

関連情報

  • man useradd(8)man passwd(1)、および man usermod(8)

7.2. Web コンソールで管理されるシステムユーザーアカウント

RHEL Web コンソールに表示されているユーザーアカウントでは、以下が可能になります。

  • システムにアクセスする際にユーザーを認証する
  • システムへのアクセス権を設定する

RHEL Web コンソールは、システムに存在するすべてのユーザーアカウントを表示します。そのため、最初に Web コンソールにログインした直後は、ユーザーアカウントが少なくとも 1 つ表示されます。

RHEL Web コンソールにログインしたら、以下の操作を実行できます。

  • 新規ユーザーアカウントの作成
  • パラメーターの変更
  • アカウントのロック
  • ユーザーセッションの終了

7.3. Web コンソールで新規アカウントの追加

RHEL Web コンソールを使用して、ユーザーアカウントをシステムに追加し、アカウントに管理者権限を設定する場合は、以下の手順に従います。

前提条件

手順

  1. RHEL Web コンソールにログインします。
  2. アカウント をクリックします。
  3. 新規アカウントの作成 をクリックします。
  1. フルネーム フィールドにユーザーの氏名を入力します。

    RHEL Web コンソールは、入力した氏名からユーザー名が自動的に作成され、ユーザー名 フィールドに入力されます。名前の頭文字と、苗字で構成される命名規則を使用しない場合は、入力されたユーザー名を変更します。

  2. パスワード/確認 フィールドにパスワードを入力し、再度パスワードを入力します。

    フィールドの下にあるカラーバーは、入力したパスワードの強度を表し、弱いパスワードは使用できないようにします。

  1. 作成 をクリックして設定を保存し、ダイアログボックスを閉じます。
  2. 新規作成したアカウントを選択します。
  3. ロール で、サーバー管理者 を選択します。

    cockpit terminate session pf4

    これで アカウント 設定に新規アカウントが表示され、認証情報を使用してシステムに接続できるようになりました。

第8章 後で分析するためにクラッシュしたカーネルのダンプ

kdump サービスを使用して後で分析できるようにシステムのメモリー内容を保存することで、システムがクラッシュした理由を分析できます。本セクションでは、kdump の概要と、RHEL Web コンソールまたは対応する RHEL システムロールを使用して kdump を設定する方法を説明します。

8.1. kdump とは

kdump は、クラッシュダンプメカニズムを提供するサービスです。サービスを使用すると、システムのメモリー内容を保存し、後で分析することができます。kdumpkexec システムコールを使用して再起動せずに 2 番目のカーネル (キャプチャーカーネル)で起動し、2 番目のカーネルメモリーの内容 (crash dump または vmcore) をキャプチャーして保存します。この第 2 のカーネルは、システムメモリーの予約部分に収納されています。

重要

カーネルクラッシュダンプは、システム障害 (重大なバグ) 時に利用できる唯一の情報になります。したがって、ミッションクリティカルな環境では、kdump を確実に稼働させることが重要です。Red Hat は、システム管理者が通常のカーネル更新サイクルで kexec-tools を定期的に更新してテストすることをお勧めします。これは、新しいカーネル機能が実装されている場合に特に重要です。

8.2. Web コンソールでの kdump メモリーの使用量およびターゲットの場所設定

以下の手順は、Red Hat Enterprise Linux Web コンソールインターフェースで Kernel Dump タブを使用して、kdump カーネル用に予約されたメモリー容量を設定する方法を説明します。この手順では、vmcore ダンプファイルのターゲットの場所を指定する方法と、設定をテストする方法を説明します。

手順

  1. Kernel Dump タブを開き、kdump サービスを開始します。
  2. コマンドラインで kdump のメモリー使用量を設定します。
  3. クラッシュダンプの場所 オプションの横にあるリンクをクリックします。

    web console initial screen
  4. ドロップダウンメニューから ローカルファイルシステム を選択し、ダンプを保存するディレクトリーを指定します。

    web console crashdump target
    • または、ドロップダウンから SSH 経由のリモート オプションを選択し、SSH プロトコルを使用して、vmcore をリモートマシンに送信します。

      Serverssh keyDirectory の各フィールドに、リモートマシンのアドレス、ssh キーの場所、およびターゲットディレクトリーを入力します。

    • または、ドロップダウンから NFS 経由のリモート オプションを選択し、マウント フィールドに入力して、NFS プロトコルを使用して vmcore をリモートマシンに送信することもできます。

      注記

      圧縮 チェックボックスにチェックマークを入れ、vmcore ファイルのサイズを小さくします。

  5. カーネルをクラッシュして、設定をテストします。

    web console test kdump config
    警告

    この手順では、カーネルの実行を中断し、システムクラッシュやデータの損失が発生します。

8.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 ファイルを参照してください。

8.4. 関連情報

第9章 システムの復旧および復元

Red Hat Enterprise Linux では、既存のバックアップを使用してシステムを復旧および復元するために、ReaR (Relax-and-Recover) ユーティリティーが同梱されています。

このユーティリティーは、障害復旧ソリューションとして、またシステム移行にも使用できます。

このユーティリティーを使用すると、以下のタスクを実行できます。

  • イメージを使用して、起動可能なイメージを作成し、既存のバックアップからシステムを復元する
  • オリジナルのストレージレイアウトを複製する
  • ユーザーおよびシステムファイルを復元する
  • システムを別のハードウェアに復元する

また、障害復旧の場合は、特定のバックアップソフトウェアを ReaR に統合することもできます。

ReaR 設定の概要手順は以下のとおりです。

  1. ReaR をインストールします。
  2. レスキューシステムを作成します。
  3. ReaR 設定ファイルを変更して、バックアップ手法の詳細を追加します。
  4. バックアップファイルを生成します。

9.1. ReaR の設定

以下の手順を使用して、Relax-and-Recover (ReaR) ユーティリティーを使用するパッケージのインストール、レスキューシステムの作成、バックアップの設定および生成を行います。

前提条件

  • バックアップ復元計画をもとに、必要な設定の準備が整いました。

    NETFS バックアップメソッド (ReaR に完全に統合され、組み込まれたメソッド) を使用できることに注意してください。

手順

  1. ReaR、genisomage のマスター前のプログラム、およびブートローダースイートが含まれる syslinux パッケージをインストールします。

    # yum install rear genisoimage syslinux
  2. レスキューシステムを作成します。

    # rear mkrescue
  3. 以下の例のように、任意のエディターで ReaR 設定ファイルを変更します。

    # vi /etc/rear/local.conf
  4. バックアップ設定の詳細を /etc/rear/local.conf に追加します。たとえば、NETFS バックアップメソッドの場合は、以下の行を追加します。

    BACKUP=NETFS
    BACKUP_URL=backup.location

    backup.location は、バックアップ先の URL に置き換えます。

  5. 新規バックアップの作成時に以前のバックアップアーカイブを維持するように RaaR 設定を行うには、以下の行を設定ファイルに追加します。

    NETFS_KEEP_OLD_BACKUP_COPY=y
  6. 増分バックアップ (実行するたびに変更されたファイルのみがバックアップされる) を設定する場合は、以下の行を追加します。

    BACKUP_TYPE=incremental
  7. 復元計画に従ってバックアップを作成します。

第10章 ログファイルを使用した問題のトラブルシューティング

ログファイルは、システム (カーネル、サービス、および実行中のアプリケーションなど) に関するメッセージが含まれるファイルです。ログファイルには、問題のトラブルシューティングやシステム機能の監視に役立つ情報が含まれています。Red Hat Enterprise Linux におけるロギングシステムは、組み込みの syslog プロトコルに基づいています。特定のプログラムがこのシステムを使用してイベントを記録し、ログファイルに分類します。これは、オペレーティングシステムの監査およびさまざまな問題のトラブルシューティングに役立ちます。

10.1. syslog メッセージを処理するサービス

以下の 2 つのサービスは、syslog メッセージを処理します。

  • systemd-journald デーモン
  • Rsyslog サービス

systemd-journald デーモンは、さまざまなソースからメッセージを収集し、収集したメッセージを処理するために Rsyslog に転送します。systemd-journald デーモンは、以下のソースからメッセージを収集します。

  • カーネル
  • ブートプロセスの初期段階
  • 起動時および実行時のデーモンの標準出力とエラー
  • Syslog

Rsyslog サービスは、タイプおよび優先順で syslog のメッセージを分類し、/var/log ディレクトリー内のファイルに書き込みます。/var/log ディレクトリーは、ログメッセージを永続的に保存します。

10.2. syslog メッセージを保存するサブディレクトリー

/var/log ディレクトリー内の以下のサブディレクトリーでは、syslog メッセージを保存します。

  • /var/log/messages - 以下を除くすべての syslog メッセージ
  • /var/log/secure - セキュリティーおよび認証に関連するメッセージおよびエラー
  • /var/log/maillog - メールサーバーに関連するメッセージおよびエラー
  • /var/log/cron - 定期的に実行されるタスクに関連するログファイル
  • /var/log/boot.log - システムの起動に関連するログファイル

10.3. Web コンソールでログファイルの検査

以下の手順に従って、Web コンソールを使用してログファイルを検証します。

手順

  1. Red Hat Enterprise Linux 8 Web コンソールにログインします。
  2. ログ をクリックします。

図10.1 RHEL 8 Web コンソールでログファイルの検査

cs viewing logs web console

10.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
...

表10.1 システム情報の表示

コマンド説明

journalctl

収集されたジャーナルエントリーをすべて表示します。

journalctl FILEPATH

特定のファイルに関連するログを表示します。たとえば、journalctl /dev/sda コマンドは、/dev/sda ファイルシステムに関連するログを表示します。

journalctl -b

現在のブートのログを表示します。

journalctl -k -b -1

現在のブートのカーネルログを表示します。

表10.2 特定のサービスの情報の表示

コマンド説明

journalctl -b _SYSTEMD_UNIT=foo

ログをフィルターして、「foo」のsystemd サービスに一致するものを表示します。

journalctl -b _SYSTEMD_UNIT=foo _PID=number

一致を組み合わせます。たとえば、このコマンドは、foo と PID 番号 に一致する systemd-units のログを表示します。

journalctl -b _SYSTEMD_UNIT=foo _PID=number + _SYSTEMD_UNIT=foo1

区切り文字「+」は、論理 OR の 2 つの式を組み合わせます。たとえば、以下のコマンドは、foo サービスプロセスからのメッセージをすべて PID で表示し、(プロセスのいずれかの) foo1 サービスからのメッセージをすべて表示します。

journalctl -b _SYSTEMD_UNIT=foo _SYSTEMD_UNIT=foo1

このコマンドは、同じフィールドを参照し、いずれかの式に一致するエントリーをすべて表示します。このコマンドは、systemd-unit foo または systemd-unit foo1 に一致するログを表示します。

表10.3 特定のブートに関連するログの表示

コマンド説明

journalctl --list-boots

ブート番号、その ID、およびブートに関する最初のメッセージと最後のメッセージのタイムスタンプの表形式一覧が表示されます。以下のコマンドの ID を使用して詳細情報を表示できます。

journalctl --boot=ID _SYSTEMD_UNIT=foo

指定したブート ID に関する情報を表示します。

10.5. 関連情報

第11章 Red Hat サポートへのアクセス

本セクションでは、Red Hat サポートおよび sosreport を使用して問題を効果的にトラブルシューティングする方法を説明します。

Red Hat のサポートを利用するには、Red Hat カスタマーポータルを使用します。カスタマーポータルは、サブスクリプションで利用可能なものをすべて提供します。

11.1. Red Hat カスタマーポータルで利用できる Red Hat サポート

以下のセクションでは、Red Hat カスタマーポータルを使用してサポートを受ける方法を説明します。

前提条件

手順

  1. Red Hat サポート:

    1. サポートケースを作成する
    2. Red Hat 専門スタッフとのライブチャットを開始する
    3. 電話または電子メールで Red Hat 専門スタッフに問い合わせる

11.2. sosreport を使用した問題のトラブルシューティング

sosreport コマンドは設定の詳細、システム情報、および診断情報を Red Hat Enterprise Linux システムから収集します。

次のセクションでは、sosreport コマンドを使用して、サポートケースのレポートを作成する方法を説明します。

前提条件

手順

  1. sos パッケージをインストールするには、以下のコマンドを実行します。

    # yum install sos
    注記

    Red Hat Enterprise Linux のデフォルトの最小インストールには、sosreport コマンドを提供する sos パッケージは含まれません。

  2. レポートを生成します。

    # sosreport
  3. サポートケースにレポートを添付します。

    「How can I attach a file to a Red Hat support case?」を参照してください。詳細は、Red Hat ナレッジベースの記事を参照してください。

    レポートを添付すると、該当のサポートケース番号の入力が求められます。

第12章 ソフトウェアパッケージの管理

12.1. Red Hat Enterprise Linux 8 におけるソフトウェア管理ツール

RHEL 8 では、 YUM ツール(YUM v4)は、 DNF Technology.

注記

アップストリームのドキュメントでは、テクノロジーが次のように識別されます。 DNF このツールは、 DNF アップストリームで参照してください。その結果、新しい出力の一部が返ります。 YUM RHEL 8 のツールが言及されている DNF.

ただし、 YUM v4 RHEL 8 では、 DNFYUM v3 RHEL 7 で使用ソフトウェアのインストールでは、yum コマンドとそのオプションのほとんどが、RHEL 7 で実行したように RHEL 8 で機能します。

選択済み yum プラグインおよびユーティリティーは、新しい DNF バックエンドに移植されており、RHEL 7 と同じ名前でインストールできます。パッケージは互換性を持ったシンボリックリンクを提供するため、バイナリー、設定ファイル、ディレクトリーは通常の場所で確認できます。

YUM v3 が提供する以前の Python API は利用できなくなりました。YUM v4 (DNF Python API) が提供する安定し、完全に対応する新しい API に、使用しているプラグインおよびスクリプトを移行できます。詳細は、「DNF API Reference 」を参照してください。

12.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 で利用可能なモジュールの一覧は『パッケージマニフェスト 』を参照してください。

12.3. ソフトウェアパッケージの検索

yum ソフトウェアパッケージをすべて操作できる。

以下のセクションでは、yum を使用して以下を行う方法を説明します。

  • パッケージを検索する
  • パッケージを一覧表示する
  • リポジトリーを一覧表示する
  • パッケージに関する情報を表示する
  • パッケージグループを一覧表示する
  • yum input での glob 表現を指定する

12.3.1. yum を使用したパッケージの検索

  • パッケージを検索するには、以下を使用します。

    # yum search term

    term は、パッケージ関連の用語に置き換えます。

    yum search コマンドでは、パッケージの名前と概要に含まれる用語で一致したものが返されることに注意してください。これにより、検索時間が短縮され、名前が分からないものの、関連用語が分かっているパッケージの検索が可能になります。

  • パッケージの説明に一致する用語を含めるには、以下を使用します。

    # yum search --all term

    term は、パッケージ名、概要、または説明で検索する用語に置き換えます。

    yum search --all はより完全な検索を可能にしますが、速度が遅くなることに注意してください。

12.3.2. yum を使用したパッケージの一覧表示

  • インストール済みで利用可能なパッケージの情報をすべて表示するには、次のコマンドを実行します。

    # yum list --all
  • システムにインストールされているパッケージの一覧を表示するには、以下のコマンドを使用します。

    # yum list --installed
  • 有効なすべてのリポジトリーで、インストール可能な全パッケージを表示するには、以下を使用します。

    # yum list --available

glob 表現を引数として追加して結果をフィルターできることに注意してください。詳細は、「yum input での glob 表現の指定」 を参照してください。

12.3.3. yum を使用したリポジトリーの一覧表示

  • システムで有効なリポジトリーをすべて一覧表示するには、以下を使用します。

    # yum repolist
  • システムで無効になっているリポジトリーをすべて一覧を表示するには、以下を使用します。

    # yum repolist --disabled
  • 有効および無効なリポジトリーの両方を一覧表示するには、以下を使用します。

    # yum repolist --all
  • リポジトリーに関する追加情報を一覧表示するには、以下を使用します。

    # yum repoinfo

リポジトリーの ID または名前を引数として渡すか、glob 表現を追加して結果をフィルタリングでききることに注意してください。詳細は、「yum input での glob 表現の指定」 を参照してください。

12.3.4. yum でパッケージ情報の表示

  • パッケージに関する情報を表示するには、以下を使用します。

    # yum info package-name

    package-name を、パッケージ名に置き換えます。

glob 表現を引数として追加して結果をフィルターできることに注意してください。詳細は、「yum input での glob 表現の指定」 を参照してください。

12.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 表現の指定」 を参照してください。

12.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 は、ファイルの名前に置き換えます。

12.4. ソフトウェアパッケージのインストール

以下のセクションでは、yum を使用して以下を行う方法を説明します。

  • パッケージをインストールする
  • パッケージグループをインストールする
  • yum input にパッケージ名を指定する

12.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 でのパッケージ名の指定」 を参照してください。

12.4.2. yum を使用したパッケージグループのインストール

  • パッケージグループをグループ名でインストールするには、以下を使用します。

    # yum group install group-name

    または

    # yum install @group-name

    group-name は、グループまたは環境グループのフルネームに置き換えます。

  • groupID でパッケージグループをインストールするには、以下を使用します。

    # yum group install groupID

    groupID は、グループの ID に置き換えます。

12.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

    nameepochversionrelease、および architecture は、パッケージの正確な名前、エポック、バージョン、リリース、およびアーキテクチャーに置き換えます。

12.5. ソフトウェアパッケージの更新

yum システムに保留中の更新があるかどうかを確認できます。更新が必要なパッケージを一覧表示して、1 つのパッケージ、複数のパッケージ、またはすべてのパッケージを一度に更新できます。更新パッケージに依存関係がある場合は、合わせて更新されます。

以下のセクションでは、yum を使用して以下を行う方法を説明します。

  • 更新の有無を確認する
  • 1 つのパッケージを更新する
  • パッケージグループを更新する
  • すべてのパッケージとその依存関係を更新する
  • セキュリティー更新を適用する
  • ソフトウェアの更新を自動化する

12.5.1. yum を使用した更新の確認

  • システムにインストールされているパッケージで更新を利用できるのはどれかを確認するには、以下のコマンドを実行します。

    # yum check-update

    このコマンドは、更新が利用可能なパッケージおよびその依存関係の一覧を表示します。

12.5.2. yum を使用した単一パッケージの更新

  • パッケージを更新するには、以下を使用します。

    # yum update package-name

    package-name を、パッケージ名に置き換えます。

重要

カーネルへの更新を適用する場合は、以下を行います。 yum yum update コマンドまたは yum install コマンドを使用しているかどうかに関係なく、新しいカーネルを常にインストールします

12.5.3. yum を使用したパッケージグループの更新

  • パッケージグループを更新するには、以下を使用します。

    # yum group update group-name

    group-name は、パッケージグループの名前に置き換えます。

12.5.4. yum ですべてのパッケージとその依存関係の更新

  • すべてのパッケージとその依存関係を更新するには、次のコマンドを実行します。

    # yum update

12.5.6. ソフトウェア更新の自動化

パッケージの更新の確認とダウンロードを定期的に行うには、dnf-automatic パッケージの DNF Automatic ツールを使用できます。

DNF Automatic は、systemd タイマー、cron ジョブ、その他のツールを使用した自動実行および定期実行に適した yum の代替コマンドラインインターフェースです。

DNF Automatic は、必要に応じてパッケージのメタデータを同期し、利用できる更新を確認します。その後、このツールは、設定方法に応じて以下のアクションのいずれかを実行できます。

  • 終了
  • 更新済みパッケージのダウンロード
  • 更新のダウンロードおよび適用

その後、標準出力やメールなど、選択したメカニズムによって操作の結果が報告されます。

12.5.6.1. DNF Automatic のインストール

以下の手順では、DNF Automatic ツールをインストールする方法を説明します。

手順

  • dnf-automatic パッケージをインストールするには、次のコマンドを実行します。

    # yum install dnf-automatic

検証手順

  • インストールの成功を確認するには、以下のコマンドを実行して dnf-automatic パッケージが存在することを確認します。

    # rpm -qi dnf-automatic

12.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 タイマーユニットで使用される設定によって上書きされます。

関連情報

12.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>

関連情報

12.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-download.timer

キャッシュにパッケージをダウンロードし、更新を利用できるようにします。

注記: このタイマーユニットでは更新パッケージはインストールされません。インストールを実行するには、dnf update コマンドを実行する必要があります。

はい

dnf-automatic-install.timer

更新したパッケージをダウンロードしてインストールします。

はい

dnf-automatic-notifyonly.timer

リポジトリーデータのみをダウンロードして、リポジトリーキャッシュを最新の状態に維持し、利用可能な更新について通知します。

注記: このタイマーユニットでは、更新されたパッケージはダウンロードまたはインストールされません。

はい

dnf-automatic.timer

更新のダウンロードと適用に関するこのタイマーの動作は、/etc/dnf/automatic.conf 設定ファイルの設定で指定されます。

デフォルトの動作は、dnf-automatic-download.timer ユニットと同じで、パッケージのみをダウンロードし、インストールは行いません。

いいえ

関連情報

  • dnf-automatic タイマーの詳細は、man dnf-automatic の man ページを参照してください。
  • /etc/dnf/automatic.conf 設定ファイルの詳細は、セクション 2.5.6.2.「DNF Automatic 設定ファイル」を参照してください。

12.6. ソフトウェアパッケージのアンインストール

以下のセクションでは、yum を使用して以下を行う方法を説明します。

  • パッケージを削除する
  • パッケージグループを削除する
  • yum input にパッケージ名を指定する

12.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 でのパッケージ名の指定」 を参照してください。

12.6.2. yum を使用したパッケージグループの削除

  • グループ名を使用してパッケージグループを削除するには、以下を使用します。

    # yum group remove group-name

    または

    # yum remove @group-name

    group-name は、グループの完全な名前に置き換えます。

  • groupID でパッケージグループを削除するには、以下を使用します。

    # yum group remove groupID

    groupID は、グループの ID に置き換えます。

12.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

    nameepochversionrelease、および architecture は、パッケージの正確な名前、エポック、バージョン、リリース、およびアーキテクチャーに置き換えます。

12.7. ソフトウェアパッケージグループの管理

パッケージグループは、共通の目的に対応するパッケージの集合です(System Tools, Sound and Video).パッケージグループをインストールすると、依存パッケージも取得するため、時間が大幅に短縮できます。

以下のセクションでは、yum を使用して以下を行う方法を説明します。

  • パッケージグループを一覧表示する
  • パッケージグループをインストールする
  • パッケージグループを削除する
  • yum input での glob 表現を指定する

12.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 表現の指定」 を参照してください。

12.7.2. yum を使用したパッケージグループのインストール

  • パッケージグループをグループ名でインストールするには、以下を使用します。

    # yum group install group-name

    または

    # yum install @group-name

    group-name は、グループまたは環境グループのフルネームに置き換えます。

  • groupID でパッケージグループをインストールするには、以下を使用します。

    # yum group install groupID

    groupID は、グループの ID に置き換えます。

12.7.3. yum を使用したパッケージグループの削除

  • グループ名を使用してパッケージグループを削除するには、以下を使用します。

    # yum group remove group-name

    または

    # yum remove @group-name

    group-name は、グループの完全な名前に置き換えます。

  • groupID でパッケージグループを削除するには、以下を使用します。

    # yum group remove groupID

    groupID は、グループの ID に置き換えます。

12.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 は、ファイルの名前に置き換えます。

12.8. パッケージ管理履歴の処理

yum history コマンドを使用すると、 yum トランザクション、日付と時刻、影響を受けたパッケージ数、これらのトランザクションが成功したか、RPM データベースがトランザクション間で変更されたかどうか。yum history コマンドを使用して、トランザクションを元に戻すまたはやり直すこともできます。

以下のセクションでは、yum を使用して以下を行う方法を説明します。

  • トランザクションを一覧表示する
  • トランザクションを元に戻す
  • トランザクションを繰り返す
  • yum input での glob 表現を指定する

12.8.1. yum を使用したトランザクションの一覧表示

  • 最新のものをすべて表示するには、 yum transactions。以下を使用します。

    # yum history
  • 選択したパッケージの最新操作の一覧を表示するには、以下を使用します。

    # yum history list package-name

    package-name を、パッケージ名に置き換えます。glob 表現を追加して、コマンドの出力をフィルタリングできます。詳細は、「yum input での glob 表現の指定」 を参照してください。

  • 特定のトランザクションを調べるには、以下を使用します。

    # yum history info transactionID

    transactionID は、トランザクションの ID に置き換えます。

12.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 は、(古いパッケージが引き続き利用可能な場合に) 更新済みパッケージをすべて以前のバージョンにダウングレードする試みも行います。

12.8.3. yum を使用したトランザクションの繰り返し

  • 特定のトランザクションを繰り返すには、以下を使用します。

    # yum history redo transactionID

    transactionID は、トランザクションの ID に置き換えます。

  • 最後のトランザクションを繰り返すには、以下を使用します。

    # yum history redo last

yum history redo コマンドは、トランザクション中に実行されたステップのみを繰り返すことに注意してください。

12.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 は、ファイルの名前に置き換えます。

12.9. ソフトウェアリポジトリーの管理

設定情報 yum その他のユーティリティーは、/etc/yum.conf ファイルに保存されます。このファイルには [repository] セクションが含まれており、リポジトリー固有のオプションを設定できます。

/etc/yum.repos.d/ ディレクトリーにある、新規または既存の .repo ファイルに個々のリポジトリーを定義することが推奨されます。

/etc/yum.conf ファイルの各 [repository] セクションで定義した値は、[main] セクションに設定した値をオーバーライドします。

次のセクションでは、以下を行う方法を説明します。

  • [repository] オプションを設定する
  • 追加: yum リポジトリー。
  • enable a yum リポジトリー。
  • 無効化: yum リポジトリー。

12.9.1. Yum リポジトリーオプションの設定

/etc/yum.conf 設定ファイルには [repository] のセクションが含まれ、repository は一意のリポジトリー ID に置き換えます。[repository] セクションでは、 yum リポジトリー。

注記

競合を回避するために、カスタムリポジトリーには Red Hat リポジトリーで使用される名前を指定しないでください。

利用可能な [repository] オプションの完全なリストは、yum.conf(5) man ページの [repository] OPTIONS セクションを参照してください。

12.9.2. yum リポジトリーの追加

新規リポジトリーを定義するには、以下を行います。

  • [repository] セクションを /etc/yum.conf ファイルに追加します。
  • /etc/yum.repos.d/ ディレクトリーの .repo ファイルに [repository] セクションを追加します。

    yum リポジトリーは、一般的に own.repo ファイルを提供します。

注記

このディレクトリーにある、.repo ファイル拡張子が付いたすべてのファイルを yum が読み取るため、リポジトリーは、/etc/yum.conf ではなく、.repo ファイルに定義することが推奨されます。

  • システムにリポジトリーを追加して有効にするには、以下を使用します。

    # yum-config-manager --add-repo repository_URL

    repository_url は、リポジトリーを参照する URL に置き換えます。

警告

ソフトウェアパッケージを、Red Hat の認証ベース Content Delivery Network (CDN) 以外の未検証または信頼できないソースから取得してインストールする場合には、セキュリティー上のリスクが伴います。セキュリティー、安定性、互換性、保全性に関する問題につながる恐れがあります。

12.9.3. yum リポジトリーの有効化

  • リポジトリーを有効にするには、以下を使用します。

    # yum-config-manager --enable repositoryID

    repositoryID は、一意のリポジトリー ID に置き換えます。

    利用可能なリポジトリー ID を一覧表示するには、「yum を使用したパッケージの一覧表示」 を参照してください。

12.9.4. yum リポジトリーの無効化

  • yum リポジトリーを無効にするには、以下のコマンドを使用します。

    # yum-config-manager --disable repositoryID

    repositoryID は、一意のリポジトリー ID に置き換えます。

    利用可能なリポジトリー ID を一覧表示するには、「yum を使用したパッケージの一覧表示」 を参照してください。

12.10. yum の設定

設定情報 yum その他のユーティリティーは、/etc/yum.conf ファイルに保存されます。このファイルには、必須の [main] セクションが含まれており、このセクションを使用することで yum オプションを設定してグローバルに設定を適用できます。

次のセクションでは、以下を行う方法を説明します。

  • 現在の yum 設定を表示します。
  • yum [main] オプションを設定します。
  • yum プラグインを使用します。

12.10.1. 現在の yum 設定の表示

  • /etc/yum.conf ファイルの [main] セクションで指定されるグローバル yum オプションの現在の値を表示するには、以下を使用します。

    # yum config-manager --dump

12.10.2. yum メインオプションの設定

/etc/yum.conf 設定ファイルには [main] セクションが 1 つ含まれています。本セクションの鍵と値のペアは、 yum リポジトリーを操作し、処理します。

/etc/yum.conf[main] セクションの下に、オプションを追加できます。

利用可能な [main] オプションの詳細なリストは、yum.conf(5) man ページの [main] OPTIONS セクションを参照してください。

12.10.3. yum プラグインの使用

yum その操作を拡張し、強化するプラグインを提供します。特定のプラグインが、デフォルトでインストールされています。

次のセクションでは、 yum プラグイン。

12.10.3.1. yum プラグインの管理

プラグイン設定ファイルには常に [main] セクションが含まれます。このセクションでは、enabled= オプションで、yum コマンドを実行する際にプラグインを有効にするかどうかを制御します。このオプションがファイルに含まれていない場合は手動で追加できます。

/etc/dnf/plugins/ ディレクトリーには、インストールしているすべてのプラグインに対する設定ファイルがあります。これらのファイルでは、プラグイン固有のオプションを有効または無効にできます。

12.10.3.2. yum プラグインの有効化

  • すべての yum プラグインを有効にするには、以下を実行します。

    1. plugins= で始まる行が /etc/yum.conf ファイルの [main] セクションにあることを確認します。
    2. plugins= の値を 1 に設定します。

      plugins=1

12.10.3.3. yum プラグインの無効化

  • yum プラグインをすべて無効にするには、以下を実行します。

    1. plugins= で始まる行が /etc/yum.conf ファイルの [main] セクションにあることを確認します。
    2. 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 をプラグインの名前に置き換えます。

第13章 systemd の概要

Systemd Linux オペレーティングシステム用のシステムおよびサービスマネージャーです。SysV init スクリプトと後方互換するように設計されており、システム起動時のシステムサービスの並行スタートアップや、デーモンのオンデマンドのアクティベーション、依存関係ベースのサービス制御論理などの多くの機能を提供します。Red Hat Enterprise Linux 7 以降 systemd Upstart をデフォルトの init システムとして置き換えます。

Systemd systemd ユニットの概念を導入します。このユニットは、次の表に挙げられているディレクトリーのいずれかにあるユニット設定ファイルで示されます。

表13.1 systemd のユニットファイルの場所

ディレクトリー詳細

/usr/lib/systemd/system/

インストール済みの RPM パッケージで配布された systemd のユニットファイル。

/run/systemd/system/

ランタイム時に作成された systemd ユニットファイル。このディレクトリーは、インストール済みのサービスのユニットファイルのディレクトリーよりも優先されます。

/etc/systemd/system/

systemctl enable で作成された systemd ユニットファイル、およびサービス拡張向けに追加されたユニットファイル。このディレクトリーは、runtime のユニットファイルのディレクトリーよりも優先されます。

ユニットは、次の情報をカプセル化します。

  • システムサービス
  • ソケットのリッスン
  • init システムに関連するその他のオブジェクト

利用可能な systemd のユニットタイプの完全なリストは、次の表を参照してください。

表13.2 利用可能な systemd のユニットタイプ

ユニットのタイプファイルの拡張子詳細

サービスユニット

.service

システムサービス

ターゲットユニット

.target

systemd ユニットのグループ

自動マウントユニット

.automount

ファイルシステムの自動マウントポイント

デバイスユニット

.device

カーネルが認識するデバイスファイル

マウントユニット

.mount

ファイルシステムのマウントポイント

パスユニット

.path

ファイルシステム内のファイルまたはディレクトリー

スコープユニット

.scope

外部作成のプロセス

スライスユニット

.slice

システムプロセスを管理する、階層的に構成されたユニットのグループ

ソケットユニット

.socket

プロセス間の通信ソケット

スワップユニット

.swap

スワップデバイスまたはスワップファイル

タイマーユニット

.timer

systemd タイマー

system.conf を使用してデフォルトの systemd 設定の上書き

デフォルト設定: systemd コンパイル中に定義され、/etc/systemd/system.conf にある systemd 設定ファイルで確認できます。ここに記載されるデフォルトではなく、systemd ユニットでグローバルに選択したデフォルト値を上書きする場合は、このファイルを使用します。

たとえば、タイムアウト制限のデフォルト値 (90 秒) を上書きする場合は、DefaultTimeoutStartSec パラメータを使用して、上書きする値を秒単位で入力します。

DefaultTimeoutStartSec=required value

詳細は、例17.2「タイムアウト制限の変更」 を参照してください。

13.1. 主な特長

systemd システムおよびサービスマネージャーの主な機能は、以下のようになります。

  • ソケットベースのアクティベーション: ブート時 systemd このタイプのアクティベーションをサポートするすべてのシステムサービスに対するリスニングソケットを作成し、サービスが起動するとソケットをサービスに渡します。これは、 systemd 並行してサービスを開始するために、サービスが利用できないときに送信されたメッセージを失うことなくサービスの再起動が可能になります。対応するソケットはアクセス可能なままで、すべてのメッセージがキューに格納されています。

    Systemd ソケットベースのアクティベーションにソケットユニットを使用します

  • バスベースのアクティベーション - プロセス間の通信に D-Bus を使用するシステムサービスは、クライアントアプリケーションがシステムサービスとの通信を初めて試みる時にオンデマンドで開始します。Systemd バスベースのアクティベーションに D-Bus サービスファイルを使用します
  • デバイスベースのアクティベーション - デバイスベースのアクティベーションをサポートするシステムサービスは、特定のタイプのハードウェアがプラグインするか利用可能になると、オンデマンドで開始できます。Systemd デバイスベースのアクティベーションに、デバイスユニットを使用します
  • パスベースのアクティベーション - パスベースのアクティベーションをサポートするシステムサービスは、特定のファイルまたはディレクトリーのステータスが変更になると、オンデマンドで開始できます。Systemd パスベースのアクティベーションにパスユニットを使用します
  • マウントおよび自動マウントポイント管理 - Systemd マウントおよび自動マウントポイントを監視および管理します。Systemd マウントポイントにマウントユニットを使用し 、自動マウントポイントに自動マウントユニットを使用します
  • アグレッシブな並列化 - ソケットベースのアクティベーションを使用するため、 systemd リスニングソケットがすべて有効になり次第、システムサービスを並行して開始できます。並列アクティベーションは、オンデマンドのアクティベーションをサポートするシステムサービスと組み合わせることで、システムの起動に必要な時間を大幅に短縮します。
  • トランザクションユニットのアクティベーション論理: ユニットをアクティブ化または非アクティブ化する前に、 systemd 依存関係を計算し、一時的なトランザクションを作成し、このトランザクションの一貫性を検証します。トランザクションに一貫性がない場合は、 systemd 自動的にこれを修正しようとし、エラーを報告する前に必須ではないジョブを削除しようと試みます。
  • SysV init との後方互換性 - Systemd の説明に従って、SysV init スクリプトをサポートします。 Linux Standard Base Core Specificationsystemd サービスユニットへのアップグレードパスを容易にします。

13.2. 互換性の変更点

systemd システムおよびサービスマネージャーは、その大部分が SysV init および Upstart と互換性があるように設計されています。以下では、SysV init を使用していた Red Hat Enterprise Linux 6 システムと比較して、互換性について最も重要な変更点を挙げています。

  • Systemd ランレベルのサポートは限定されています。ランレベルに直接マッピング可能なターゲットユニットを数多く提供し、互換性のために以前の runlevel コマンドで配布されます。ただし、systemd ターゲットのすべてがランレベルに直接マッピングできるわけではないため、このコマンドが不明なランレベルを示す N を返す場合もあります。可能な場合は、runlevel コマンドの使用を避けることが推奨されます。
    systemd ターゲットの詳細と、ランレベルとの比較は、15章systemd ターゲットでの作業 を参照してください。
  • systemctl ユーティリティーは、カスタマイズされたコマンドをサポートしません。SysV init スクリプトでは、startstopstatus といった標準のコマンドのほかに、任意のコマンドを実装して多くの機能を提供できます。たとえば、iptables の init スクリプトは、panic コマンドで実行できます。これにより、パニックモードが即座に有効になり、システムを再設定して受信パケットおよび送信パケットをすべて切断します。これは、 systemd また、systemctl は、文書化されたコマンドのみを受け入れます。
  • systemctl ユーティリティーは、 systemd.when systemd システムサービスを開始すると、メインプロセスの ID を保存して、メインプロセスを追跡します。すると、systemctl ユーティリティーがこの PID を使用してクエリーを行い、サービスを管理します。このため、ユーザーがコマンドラインで特定のデーモンを直接開始すると、systemctl がそのデーモンの最新の状態を判断したり、停止したりすることができません。
  • Systemd 実行中のサービスだけを停止します。Red Hat Enterprise Linux 6 以前のリリースでは、シャットダウンシーケンスが開始すると、/etc/rc0.d/ ディレクトリーにあるシンボリックリンクを使用して、利用可能なシステムサービスをそのステータスに関係なくすべて停止していました。上記の行を、以下のように置き換えます。 systemd 、実行中のサービスのみがシャットダウン時に停止します。
  • システムサービスは、標準の入力ストリームからは読み取れません。when systemd サービスを開始すると、標準入力を /dev/null に接続し、ユーザーとの対話を行わないようにします。
  • システムサービスは、呼び出したユーザーやそのセッションから、(環境変数 HOMEPATH などの) コンテキストを継承しません。各サービスは、クリーンな実行コンテキストで実行します。
  • SysV init スクリプトを読み込む場合は、 systemd Linux Standard Base(LSB)ヘッダーにエンコードされている依存関係情報を読み取り、ランタイム時に解釈します。
  • サービスユニット上のすべての操作は、デフォルトで 5 分でタイムアウトになるように設定されており、サービスの故障でシステムがフリーズすることを防ぎます。この値は initscript から生成されるサービス用にハードコーディングされ、変更することができません。ただし、個別の設定ファイルを使用して、サービスごとにタイムアウト値を長くすることができます。例17.2「タイムアウト制限の変更」 を参照してください。

以下で導入された互換性の変更点の詳細一覧については、 systemdRed Hat Enterprise Linux 7 の移行計画ガイド を参照してください

第14章 systemctl によるシステムサービス管理

systemctl ユーティリティーは、システムサービスの管理に役立ちます。systemctl ユーティリティーを使用して、サービスの起動、停止、再起動、有効化、およびシステムサービスステータスの表示などの各種サービスに関連するさまざまなタスクを実行できます。

本セクションでは、systemctl ユーティリティーを使用してシステムサービスを管理する方法を説明します。

14.1. systemctl によるサービスユニット管理

サービスユニット は、システム内のサービスおよびデーモンの状態を制御するのに役立ちます。

サービスユニットは、.service ファイル拡張子で終わります (例: nfs-server.service)。ただし、コマンドでサービスファイル名を使用する場合は、ファイル拡張子を省略できます。systemctl ユーティリティーは、引数がサービスユニットであることを想定します。たとえば、nfs-server.service を停止するには、以下のコマンドを入力します。

# systemctl stop nfs-server

また、サービスユニットによっては エイリアス名 があります。エイリアスはユニットよりも短く省略でき、ユニット名の代わりに使用できます。

特定のユニットに使用できるエイリアスを見つけるには、以下のコマンドを実行します。

# systemctl show nfs-server.service -p Names

14.2. サービスユーティリティーと systemctl の比較

本セクションでは、サービスユーティリティーと systemctl コマンドの使用方法の比較を説明します。

表14.1 service ユーティリティーと systemctl の比較

servicesystemctl説明

service <name> start

systemctl start <name>.service

サービスを起動します。

service <name> stop

systemctl stop <name>.service

サービスを停止します。

service <name> restart

systemctl restart <name>.service

サービスを再起動します。

service <name> condrestart

systemctl try-restart <name>.service

サービスが実行中の場合のみ、再起動します。

service <name> reload

systemctl reload <name>.service

設定を再読み込みします。

service <name> status

systemctl status <name>.service

systemctl is-active <name>.service

サービスが実行中かどうかをチェックします。

service --status-all

systemctl list-units --type service --all

すべてのサービスのステータスを表示します。

14.3. システムサービスの一覧表示

現在読み込み済みのサービスユニットと、利用可能なサービスユニットのステータスをすべて一覧表示できます。

手順

  • 現在読み込み済みのサービスユニットの一覧をすべて表示するには、次のコマンドを実行します。

    $ 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
    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-units コマンドは、アクティブなユニットのみを表示します。このコマンドは、サービスのユニットファイルごとに以下を表示します。

    • UNIT: フルネーム
    • LOAD: ユニットファイルが読み込まれているかどうかに関する情報
    • ACTIVE\ SUB: 高レベルかつ低レベルのユニットファイルアクティベーションの状態
    • DESCRIPTION: 簡単な説明
  • 状態に関係なく読み込み済みユニット の一覧を表示するには、コマンドラインオプション --all または -a を指定して以下のコマンドを実行します。

    $ systemctl list-units --type service --all
  • 利用可能なサービスユニットのステータス (enabled/ disabled) を一覧表示するには、次のコマンドを実行します。

    $ systemctl list-unit-files --type service
    UNIT FILE                               STATE
    abrt-ccpp.service                       enabled
    abrt-oops.service                       enabled
    abrtd.service                           enabled
    ...
    wpa_supplicant.service                  disabled
    ypbind.service                          disabled
    
    208 unit files listed.

    このコマンドでは、サービスユニットごとに以下を表示します。

    • UNIT FILE: フルネーム
    • STATE: サービスユニットが有効または無効であるかどうかに関する情報

14.4. システムサービスステータスの表示

サービスユニットを検査して、詳細情報を取得し、サービスの状態を確認できます。特定のサービスユニットの前または後に起動するように指定されたサービスを表示することもできます。

手順

  • システムサービスに対応するサービスユニットに関する詳細情報を表示するには、次のコマンドを実行します。

    $ systemctl status <name>.service

    <name> は、確認するサービスユニットの名前 (例: gdm) に置き換えます。

    このコマンドでは、選択したサービスユニット名の後に、簡単な説明と、利用可能なサービスユニット情報で説明されている 1 つ以上のフィールド、root ユーザーが実行している場合は最新のログエントリーが表示されます。

    表14.2 利用可能なサービスユニットの情報

    フィールド詳細

    Loaded

    サービスユニットが読み込まれているかどうか、ユニットファイルへの絶対パス、ユニットが有効かどうかについての説明

    Active

    サービスユニットが実行中かどうかの説明と、タイムスタンプ

    Main PID

    対応するシステムサービスの PID と、その名前

    状態

    対応するシステムサービスに関する追加情報

    Process

    関連プロセスに関する追加情報

    CGroup

    関連するコントロールグループ (cgroup) に関する追加情報

    例14.1 サービスステータスの表示

    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.
  • 特定のサービスユニットが実行中かどうかだけを確認するには、次のコマンドを実行します。

    $ systemctl is-active <name>.service
  • 特定のサービスユニットが有効になっているかどうかを確認するには、次のコマンドを実行します。

    $ systemctl is-enabled <name>.service
    注記

    systemctl is-active および systemctl is-enabled は、指定したサービスユニットが実行中または有効な場合に、終了ステータス 0 を返します。

  • 特定のサービスユニットの前に開始するサービスを確認するには、次のコマンドを実行します。

    # systemctl list-dependencies --after <name>.service

    <name> は、コマンド内のサービス名に置き換えます。たとえば、gdm の前に開始するサービスの一覧を表示する場合は、次のコマンドを実行します。

    # 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]
  • 指定したサービスユニットの後に開始するサービスを確認するには、次のコマンドを実行します。

    # systemctl list-dependencies --before <name>.service

    <name> は、コマンド内のサービス名に置き換えます。たとえば、gdm の後に開始するサービスの一覧を表示するには、次のコマンドを実行します。

    # 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

14.5. 正および負のサービスの依存関係

systemd には、サービス間で正と負の依存関係が存在します。特定のサービスを起動するとき、別のサービスを 1 つまたは複数開始 (正の依存関係)、あるいはサービスを 1 つまたは複数停止 (負の依存関係) することが必要となる場合があります。

新しいサービスの起動を試みると、ユーザーに明示的な通知なしに、systemd がすべての依存関係を自動的に解決します。つまり、サービスを実行していて、負の依存関係にある別のサービスを起動しようとすると、最初のサービスが自動的に停止します。

たとえば、postfix サービスを実行している時に sendmail サービスを起動すると、systemd は、自動的に postfix を停止します。この 2 つのサービスは競合するため、同じポートでは実行できません。

14.6. システムサービスの起動

start コマンドを使用すると、現行セッションでシステムサービスを開始できます。サービスの起動はオペレーティングシステムの状態を左右する可能性があるため、root アクセスが必要です。

手順

  • システムサービスに対応するサービスユニットを選択して開始するには、root で次のコマンドを実行します。

    # systemctl start <name>.service

    <name> は、開始するサービスユニットの名前 (httpd.serviceなど) に置き換えます。

    例14.2 httpd.service の起動

    Apache HTTP Server のサービスユニットは指定の httpd.service に置き換えます。サービスユニットをアクティブにし、現行セッションで httpd デーモンを起動するには、root で次のコマンドを実行します。

    # systemctl start httpd.service

14.7. システムサービスの停止

stop コマンドを使用すると、現行セッションでシステムサービスを停止できます。サービスの停止はオペレーティングシステムの状態を左右する可能性があるため、root アクセスが必要です。

手順

  • システムサービスに対応するサービスユニットを停止するには、root で次のコマンドを実行します。

    # systemctl stop <name>.service

    <name> は、停止するサービスユニットの名前 (例 : bluetooth) に置き換えます。

    例14.3 bluetoothd.service の停止

    bluetoothd デーモンのサービスユニットは bluetooth.service です。サービスユニットを無効にし、現行セッションで bluetoothd デーモンを停止するには、root で次のコマンドを実行します。

    # systemctl stop bluetooth.service

14.8. システムサービスの再起動

restart コマンドを使用すると、現行セッションでシステムサービスを再起動できます。サービスの再起動は、オペレーティングシステムの状態を左右する可能性があるため、root アクセスが必要です。

この手順では、以下の方法を説明します。

  • 現行セッションで選択したサービスユニットを停止して直ちに再起動する
  • 対応するサービスがすでに実行中の場合にのみ、サービスユニットを再起動する
  • 実行を中断せずにシステムサービスの設定を再読み込みする

手順

  • システムサービスに対応するサービスユニットを再起動するには、root で次のコマンドを実行します。

    # systemctl restart <name>.service

    <name> は、再起動するサービスユニット名 (例: httpd) に置き換えます。

    注記

    選択したサービスユニットが実行中でない場合には、このコマンドでこのサービスユニットが起動します。

    • または、対応するサービスがすでに実行中の場合に限り、サービスユニットを再起動するには、root で以下のコマンドを実行します。

      # systemctl try-restart <name>.service
    • サービス実行を中断せずに設定を再読み込みするには、root で次のコマンドを実行します。

      # systemctl reload <name>.service
      注記

      システムサービスがこの機能をサポートしない場合は、このコマンドは無視されることに注意してください。このようなサービスを再起動するには、代わりに reload-or-restart コマンドおよび reload-or-try-restart コマンドを使用します。

    例14.4 httpd.service のリロード

    ユーザーが不要なエラーメッセージや、部分的に表示される Web ページに遭遇しないようにするため、Apache HTTP Server では設定を再起動したり、処理されたリクエストをアクティブに妨害したりせずに、設定を編集したり再読み込みしたりできます。これを行うには、root で次のコマンドを実行します。

    # systemctl reload httpd.service

14.9. システムサービスの有効化

システムの起動時にサービスが自動起動するように設定できます。enable コマンドは、選択したサービスユニットの [Install] セクションを読み取り、/etc/systemd/system/ ディレクトリーおよびそのサブディレクトリーにある /usr/lib/systemd/system/name.service ファイルへの適切なシンボリックリンクを作成します。ただし、すでに存在するリンクは上書きされません。

手順

  • システムの起動時にシステムサービスに対応するサービスユニットを自動的に起動するように設定するには、root で次のコマンドを実行します。

    # systemctl enable <name>.service

    <name> は、有効にするサービスユニット名 (httpdなど) に置き換えます。

    • シンボリックリンクが確実に再作成されるようにするには、root で次のコマンドを実行します。

      # systemctl reenable <name>.service

      このコマンドは、選択したサービスユニットを無効にし、即座に再度有効にします。

      例14.5 httpd.service の有効化

      システムの起動時に 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.

14.10. システムサービスの無効化

システムの起動時にサービスユニットが自動的に起動しないようにすることができます。disable コマンドは、選択したサービスユニットの [Install] セクションを読み取り、 /etc/systemd/system/ ディレクトリーおよびそのサブディレクトリーから、/usr/lib/systemd/system/name.service ファイルへの適切なシンボリックリンクを削除します。

手順

  • システムの起動時に自動的に起動しないシステムサービスに対応するサービスユニットを設定するには、root で次のコマンドを実行します。

    # systemctl disable <name>.service

    <name> は、無効にするサービスユニット名 (bluetooth など) に置き換えます。

    例14.6 bluetoothd.service の無効化

    bluetoothd デーモンのサービスユニットは 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.
    • サービスユニットをマスクし、手動または別のサービスで起動できないようにするには、root で次のコマンドを実行します。

      # systemctl mask <name>.service

      このコマンドにより、/etc/systemd/system/name.service ファイルを、/dev/null へのシンボリックリンクに置き換え、実際のユニットファイルが systemd ファイルにアクセスできないようにします。

    • この動作を元に戻してサービスユニットのマスクを解除するには、以下のコマンドを実行します。

      # systemctl unmask <name>.service

第15章 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 ターゲットでの作業中に実装する手順を説明します。

15.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 ターゲットの完全リストを提供します。

表15.1 SysV ランレベルと systemd ターゲットの比較

ランレベルターゲットユニット詳細

0

runlevel0.target, poweroff.target

システムをシャットダウンし、電源を切ります。

1

runlevel1.target, rescue.target

レスキューシェルを設定します。

2

runlevel2.target, multi-user.target

非グラフィカルなマルチユーザーシステムを設定します。

3

runlevel3.target, multi-user.target

非グラフィカルなマルチユーザーシステムを設定します。

4

runlevel4.target, multi-user.target

非グラフィカルなマルチユーザーシステムを設定します。

5

runlevel5.target, graphical.target

グラフィカルなマルチユーザーシステムを設定します。

6

runlevel6.target, reboot.target

システムをシャットダウンして再起動します。

以下の表は、SysV init コマンドを systemctl と比較しています。systemctl ユーティリティーを使用して、systemd ターゲットを表示、変更、または設定します。

重要

runlevel コマンドおよび telinit コマンドは今も利用でき、期待どおりに機能しますが、このコマンドは互換性のために同梱されているため、なるべく使用しないでください。

表15.2 SysV init コマンドと systemctl の比較

古いコマンド新しいコマンド詳細

runlevel

systemctl list-units --type target

現在読み込まれているターゲットユニットを一覧表示します。

telinit runlevel

systemctl isolate name.target

現在のターゲットを変更します。

関連情報

  • man sysv init
  • man upstart init
  • man systemctl

15.2. デフォルトターゲットの表示

デフォルトのターゲットユニットは /etc/systemd/system/default.target ファイルで表されます。

手順

  • デフォルトでどのターゲットユニットが使用されるかを判断するには、次のコマンドを実行します。

    $ systemctl get-default
    graphical.target
  • シンボリックリンクを使用してデフォルトのターゲットを確認するには、次のコマンドを実行します。

    $  ls -l /lib/systemd/system/default.target

15.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.

15.4. デフォルトターゲットの変更

デフォルトのターゲットユニットは /etc/systemd/system/default.target ファイルで表されます。以下の手順では、systemctl コマンドを使用して、デフォルトのターゲットを変更する方法を説明します。

手順

  1. デフォルトのターゲットユニットを確認するには、次のコマンドを実行します。

    # systemctl get-default
  2. デフォルトで異なるターゲットユニットを使用するようにシステムを設定するには、次のコマンドを実行します。

    # 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 を、デフォルトで使用するターゲットユニット名に置き換えます。

  3. 再起動します。

    # reboot

15.6. 現在のターゲットの変更

この手順では、systemctl コマンドを使用して、現行セッションでターゲットユニットを変更する方法を説明します。

手順

  • 現行セッションで異なるターゲットユニットに変更するには、次のコマンドを実行します。

    # systemctl isolate multi-user.target

    このコマンドは、multi-user という名前のターゲットユニットと、その従属ユニットをすべて起動し、その他のユニットを直ちに停止します。

multi-user を、デフォルトで使用するターゲットユニット名に置き換えます。

検証手順

  • 新規作成された default.target を確認します。

    $ systemctl get-default
    multi-user.target

15.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 を実行します。

15.8. 緊急モードでのブート

緊急モード は、可能な限り最小限の環境を提供し、レスキューモードに入れないシステム状態でのシステムの修復を可能にします。緊急モードでは、システムは root ファイルシステムを読み込み専用でマウントし、他のローカルファイルシステムのマウントは試みません。また、ネットワークインターフェースのアクティブ化も行わず、限定的な必須サービスのみを起動します。

手順

  • 現在のターゲットを変更し、緊急モードに入るには、次のコマンドを実行します。

    # systemctl emergency
    注記

    このコマンドは systemctl isolate emergency.target と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。

    systemd がメッセージを送信しないようにするには、--no-wall コマンドラインオプションを付けて # systemctl --no-wall emergency を実行します。

第16章 システムのシャットダウン、サスペンド、および休止状態

本セクションでは、オペレーティングシステムのシャットダウン、サスペンド、または休止状態を説明します。

16.1. システムのシャットダウン

システムをシャットダウンする場合は、systemctl ユーティリティーを使用するか、shutdown コマンドを使用してこのユーティリティーを呼び出します。

shutdown コマンドを使用する利点は、以下のとおりです。

  • 時間引数のサポート

    この引数は特に、計画的なメンテナンスに役立ちます。また、システムのシャットダウンがスケジュールされていることを示す警告への対応時間を増やすことができます。

  • シャットダウンの取り消しオプション

16.2. shutdown コマンドを使用したシステムのシャットダウン

以下の手順に従って、shutdown コマンドを使用してさまざまな操作を実行できます。特定のタイミングでシステムをシャットダウンしてマシンの電源を切るか、マシンの電源を切らずにシステムをシャットダウンして停止するか、保留中のシャットダウンを中止できます。

前提条件

  • root ユーザーに切り替える

手順

  • システムをシャットダウンし、特定の時間にマシンの電源を切るには、以下の形式でコマンドを実行します。

    shutdown --poweroff hh:mm

    hh:mm は 24 時間形式の時刻となります。新たなログインを防ぐために、システムをシャットダウンする 5 分前に /run/nologin ファイルが作成されます。

    時間引数を使用する場合は、コマンドにオプションの wall message を追加できます。

    マシンの電源を切らず、少し待ってシステムをシャットダウンして停止するには、次のコマンドを実行します。

    shutdown --halt +m

    +m は遅らせる時間 (分) です。キーワード now は、+0 のエイリアスとなります。

    保留中のシャットダウンをキャンセルするには、以下を使用します。

    shutdown -c

16.3. systemctl コマンドを使用したシステムのシャットダウン

以下の手順に従って、systemctl コマンドを使用して、さまざまな操作を実行できます。システムをシャットダウンしてマシンの電源を切るか、マシンの電源を切らずにシステムをシャットダウンして停止できます。

前提条件

  • root ユーザーに切り替える

手順

  • システムをシャットダウンしてマシンの電源を切るには、以下の形式でコマンドを実行します。

    systemctl poweroff

    マシンの電源を切らずにシステムをシャットダウンして停止するには、以下を使用します。

    systemctl halt
注記

デフォルトでは、このコマンドのいずれかを実行すると、systemd が、システムに現在ログインしたすべてのユーザーに情報メッセージを送信します。systemd がメッセージを送信しないようにするには、コマンドラインオプション --no-wall を付けてコマンドを実行します。

16.4. システムの再起動

この手順に従ってシステムを再起動できます。

前提条件

  • root ユーザーに切り替える

手順

  • システムを再起動するには、以下のコマンドを実行します。

    systemctl reboot
注記

デフォルトでは、このコマンドにより、systemd が、システムに現在ログインしたすべてのユーザーに情報メッセージを送信します。systemd がこのメッセージを送信しないようにするには、コマンドラインオプション --no-wall を付けてこのコマンドを実行します。

16.5. システムのサスペンド

以下の手順に従って、システムを一時停止できます。

前提条件

  • root ユーザーに切り替える。

手順

  • システムを一時停止するには、以下のコマンドを実行します。

    systemctl suspend

    このコマンドは、システムの状態を RAM に保存し、マシンにある、RAM モジュール以外のほとんどのデバイスの電源を切ります。マシンの電源を戻すと、システムは再起動せずに RAM からその状態を復元します。

    システムの状態がハードディスクではなくメモリーに保存されるため、システムは、ハイバネートよりも、サスペンドモードからのほうがはるかに早く復元できます。ただし、一時停止したシステムの状態は、停電に対しても脆弱であることに注意してください。

16.6. システムの休止状態

以下の手順に従うと、システムを休止状態にするか、休止状態にして一時停止することができます。

前提条件

  • root ユーザーに切り替える。

手順

  • システムを休止状態にするには、以下のコマンドを実行します。

    systemctl hibernate

    このコマンドは、システムの状態をハードディスクドライブに保存し、マシンの電源を切ります。マシンの電源を戻すと、システムは再起動せずに、保存されたデータからその状態を復元します。

    システムの状態がメモリーではなくハードディスクに保存されるため、マシンでメモリーモジュールへの電源供給を維持する必要はありません。ただし、システムは、一時停止モードより、休止状態から復元する方がはるかに遅くなります。

    システムを休止状態にして一時呈すするには、以下のコマンドを実行します。

    systemctl hybrid-sleep

16.7. systemctl を使用した電源管理コマンドの概要

以下の systemctl コマンドを使用して、システムの電源管理を制御できます。

表16.1 systemctl 電源管理コマンドの概要

systemctl コマンド説明

systemctl halt

システムを停止します。

systemctl poweroff

システムの電源を切ります。

systemctl reboot

システムを再起動します。

systemctl suspend

システムをサスペンドします。

systemctl hibernate

システムを休止状態にします。

systemctl hybrid-sleep

システムを休止状態にしてサスペンドします。

第17章 systemd ユニットファイルでの作業

本章では、systemd ユニットファイルに関する説明が含まれています。以下のセクションでは、次の方法を紹介します。

  • カスタムユニットファイルの作成
  • SysV Init スクリプトのユニットファイルへの変換
  • 既存のユニットファイルの変更
  • インスタンス化されたユニットの使用

17.1. ユニットファイルの概要

ユニットファイルには、ユニットを説明し、その動作を定義する設定ディレクティブが含まれます。複数の systemctl コマンドがバックグラウンドでユニットファイルと連携します。詳細な調整を行うには、システム管理者がユニットファイルを手動で編集または作成する必要があります。表13.1「systemd のユニットファイルの場所」 には、システムにユニットファイルが保存される 3 つのメインディレクトリーが記載されています。/etc/systemd/system/ ディレクトリーは、システム管理者が作成またはカスタマイズするユニットファイル用に予約されます。

ユニットファイル名は、以下のフォーマットを使用します。

unit_name.type_extension

unit_name はユニットの名前を表し、type_extension はユニットタイプを識別します。ユニットタイプの完全なリストは、表13.2「利用可能な systemd のユニットタイプ」 を参照してください。たとえば、通常は、システムには sshd.service ユニットおよび sshd.socket ユニットがあります。

ユニットファイルには、追加の設定ファイルのディレクトリーを追加できます。たとえば、カスタム設定オプションを sshd.service に追加するには、sshd.service.d/custom.conf ファイルを作成し、追加のディレクティブを挿入します。設定ディレクトリーの詳細は、「既存のユニットファイルの変更」を参照してください。

さらに、sshd.service.wants/ ディレクトリーおよび sshd.service.requires/ ディレクトリーを作成することもできます。このディレクトリーには、sshd サービスの依存関係であるユニットファイルへのシンボリックリンクが含まれます。シンボリックリンクは、[Install] ユニットファイルに基づいてインストール時に、または [Unit] オプションに基づいてランタイム時に自動的に作成されます。このディレクトリーとシンボリックリンクを手動で作成することもできます。[Install] オプションおよび [Unit] オプションの詳細は、以下の表を参照してください。

多くのユニットファイルオプションは、いわゆる ユニット指定子 を使用して設定できます。これは、ユニットファイルが読み込まれる際にユニットパラメーターに動的に置き換えられるワイルドカード文字列です。これにより、インスタンス化されたユニットを生成するテンプレートとしての役割を担う汎用ユニットファイルを作成できます。詳細は、「インスタンス化されたユニットの使用」を参照してください。

17.2. ユニットファイル構造

通常、ユニットファイルは 3 つのセクションで構成されています。

  • [Unit] セクション- ユニットのタイプに依存しない一般的なオプションが含まれます。このセクションに含まれるオプションはユニットを説明し、ユニットの動作を指定し、他のユニットへの依存関係を設定します。最も頻繁に使用される [Unit] オプションの一覧は、表17.1「[Unit] セクションの重要なオプション」 を参照してください。
  • [Unit type] セクション - ユニットにタイプ固有のディレクティブがある場合は、そのユニットタイプにちなんで命名されたセクションにまとめられます。たとえば、サービスユニットファイルには [Service] セクションが含まれます。
  • [Install] セクション - systemctl enable コマンドおよび disable コマンドでユニットをインストールした際の情報が含まれます。[Install] セクションのオプションの一覧は、表17.3「[Install] セクションの重要なオプション」 を参照してください。

17.2.1. [Unit] セクションの重要なオプション

以下の表は、[Unit] セクションの重要なオプションを示しています。

表17.1 [Unit] セクションの重要なオプション

オプション [a]説明

詳細

ユニットの説明です。このテキストは、たとえば systemctl status コマンドの出力に表示されます。

Documentation

ユニットのドキュメントを参照する URI の一覧を提供します。

After[b]

ユニットが開始する順序を定義します。このユニットは、After で指定されたユニットがアクティブになると開始します。Requires とは異なり、After は、指定したユニットを明示的にアクティブにしません。Before オプションには、After と機能が反対になります。

Requires

その他のユニットに依存関係を設定します。Requires に一覧表示されるユニットは、対応するユニットと共にアクティブになります。必要なユニットのいずれかが開始しないと、このユニットはアクティブになりません。

Wants

Requires よりも強度の弱い依存関係を設定します。一覧に示されるユニットのいずれかが正常に開始しなくても、このユニットのアクティべーションには影響を与えません。これは、カスタムのユニット依存関係を設定する際に推奨される方法です。

Conflicts

Requires と反対の依存関係 (負の依存関係) を設定します。

[a] [Unit] セクションで設定可能なオプションの一覧は、man ページの systemd.unit(5) を参照してください。
[b] ほとんどの場合、ユニットファイルオプションの After および Before で依存関係の並び順を設定するだけで十分です。Wants (推奨) または Requires で要件の依存関係も設定する場合は、依存関係の並び順を指定する必要があります。これは、並び順と要件の依存関係が相互に依存していないためです。

17.2.2. [Service] セクションの重要なオプション

以下の表では、[Service] セクションの重要なオプションを紹介しています。

表17.2 [Service] セクションの重要なオプション

オプション [a]説明

Type

ExecStart および関連オプションの機能に影響を与えるユニットプロセスの起動タイプを設定します。以下のいずれかになります。

* simple - デフォルト値です。ExecStart で起動するプロセスは、サービスのメインプロセスです。

* forking - ExecStart で起動するプロセスは、サービスのメインプロセスになる子プロセスを起動します。親プロセスは、このプロセスが完了すると終了します。

* oneshot - このタイプは simple と似ていますが、結果として生じるユニットを起動する前に終了します。

* dbus - このタイプは simple と似ていますが、メインプロセスが D-Bus 名を取得する前に、結果として生じるユニットが起動します。

* notify - このタイプは simple と似ていますが、結果として生じるユニットは、通知メッセージが sd_notify() 関数で送信されないと起動しません。

* idle - simple と似ていますが、サービスバイナリーの実行は、すべてのジョブが終了するまで行いません (遅らせます)。 これにより、ステータスの出力とサービスのシェル出力を分けることができます。

ExecStart

ユニットの開始時に実行するコマンドまたはスクリプトを指定します。ExecStartPre および ExecStartPost は、ExecStart の前後に実行するカスタムコマンドを指定します。Type=oneshot を使用すれば、連続して実行する複数のカスタムコマンドを指定できます。

ExecStop

ユニットの停止時に実行するコマンドまたはスクリプトを指定します。

ExecReload

ユニットの再読み込み時に実行するコマンドまたはスクリプトを指定します。

Restart

このオプションを有効にすると、systemctl コマンドによる完全な停止の例外により、そのプロセスの終了後にサービスが再起動します。

RemainAfterExit

True に設定すると、サービスは、そのプロセスがすべて終了していてもアクティブと見なされます。デフォルトの値は False です。このオプションは、特に Type=oneshot が設定されている場合に役に立ちます。

[a] [Service] セクションで設定可能なオプションの一覧は、systemd.service(5) の man ページを参照してください。

17.2.3. [Install] セクションの重要なオプション

以下の表は、[Install] セクションの重要なオプションを紹介しています。

表17.3 [Install] セクションの重要なオプション

オプション [a]説明

Alias

ユニット名の追加一覧を、スペース区切りで提供します。systemctl enable を除くほとんどの systemctl コマンドでは、ユニット名ではなくエイリアスを使用できます。

RequiredBy

そのユニットに依存するユニットの一覧です。このユニットが有効な場合に、RequiredBy に一覧表示されるユニットは、このユニットに関する Require 依存関係を取得します。

WantedBy

このユニットへの依存が弱いユニットの一覧です。このユニットが有効になると、WantedBy に一覧表示されるユニットが、このユニットに関する Want 依存関係を取得します。

Also

対応するユニットと共にインストールまたはアンインストールされるユニットの一覧を指定します。

DefaultInstance

インスタンス化されているユニットだけが対象となりますが、このオプションは、ユニットが有効になっているデフォルトのインスタンスを指定します。「インスタンス化されたユニットの使用」を参照してください。

[a] [Install] セクションで設定可能なオプションの一覧は、man ページの systemd.unit(5) を参照してください。

17.3. カスタムユニットファイルの作成

ユニットファイルをゼロから作成するユースケースが複数あります。カスタムデーモンを実行したり、一部の既存のサービスの 2 つ目のインスタンスを作成したり (「sshd サービスの 2 つ目のインスタンスの作成」を参照)、SysV init スクリプトをインポートしたり (「SysV Init スクリプトのユニットファイルへの変換」を参照) できます。一方、既存ユニットの動作の変更または拡張のみを実行しようとする場合は、 「既存のユニットファイルの変更」を参照してください。以下の手順では、カスタムサービスを作成する一般的なプロセスを説明します。

手順

  1. カスタムサービスで実行可能なファイルを用意します。カスタムで作成されたスクリプトや、ソフトウェアプロバイダーが提供する実行ファイルがこれにあたります。必要な場合は、カスタムサービスのメインプロセスの PID を保持するため、PID ファイルを用意します。また、サービスのシェル変数を保存するために環境ファイルを組み込むこともできます。(chmod a+x を実行して) ソーススクリプトが実行でき、インタラクティブではないことを確認してください。
  2. /etc/systemd/system/ ディレクトリーにユニットファイルを作成し、ファイルに適切なパーミッションがあることを確認します。root で以下のコマンドを実行します。

    touch /etc/systemd/system/name.service
    
    chmod 664 /etc/systemd/system/name.service

    name を、作成するサービスの名前に置き換えます。ファイルには実行権限が必要ありません。

  3. 上の手順で作成した 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 で作成されます。その他の起動タイプは 表17.2「[Service] セクションの重要なオプション」 を参照してください。
    • WantedBy では、サービスを起動するターゲットを指定します。ターゲットは、従来のランレベルの概念に代わるものとお考えください。
  4. notify systemd root で以下のコマンドを実行すると、新しいname.service ファイルが存在する。

    systemctl daemon-reload
    
    systemctl start name.service
    警告

    新しいユニットファイルを作成したり、既存のユニットファイルを修正したら常に systemctl daemon-reload コマンドを実行します。そうしないと、ステータスが一致しないため、systemctl start コマンドや systemctl enable コマンドが失敗することがあります。 systemd また、ディスク上で実際のサービスユニットファイル。ユニット数が多いシステムでは、各ユニットのステータスをシリアライズし、その後再読み込み時にデシリアライズする必要があるため、これには時間がかかることがあります。

17.3.1. sshd サービスの 2 番目のインスタンスを使用したカスタムユニットファイルの作成

システム管理者は、サービスのインスタンスを複数設定し、実行しなければならないことが多々あります。これは、サービスの主なインスタンスとの競合を避けるために、元のサービス設定ファイルのコピーを作成し、特定のパラメーターを変更することで実行します。以下の手順は、sshd サービスの 2 つ目のインスタンスを作成する方法を示しています。

手順

  1. 2 つ目のデーモンで使用する、sshd_config ファイルのコピーを作成します。

    # cp /etc/ssh/sshd{,-second}_config
  2. 作成した sshd-second_config ファイルを編集し、2 つ目のデーモンに別のポート番号と PID ファイルを割り当てます。

    Port 22220
    PidFile /var/run/sshd-second.pid

    Port オプションおよび PidFile オプションの詳細は、man ページの sshd_config(5) を参照してください。他のサービスで使用されていないポートを選択してください。PID ファイルはサービスの実行時に存在していなければいけないものではありません。存在しない場合は、サービスの起動時に自動的に生成されます。

  3. sshd サービスの systemd ユニットファイルのコピーを作成します。

    # cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
  4. 作成した sshd-second.service を以下のように変更します。

    1. Description オプションを変更します。

      Description=OpenSSH server second instance daemon
    2. After オプションを指定するサービスに sshd.service を追加し、最初のインスタンスが起動した場合に限り 2 つ目のインスタンスが起動するようにします。

      After=syslog.target network.target auditd.service sshd.service
    3. sshd の最初のインスタンスには鍵の生成が含まれるため、ExecStartPre=/usr/sbin/sshd-keygen 行を削除します。
    4. sshd コマンドに -f /etc/ssh/sshd-second_config パラメーターを追加して、代替の設定ファイルが使用されるようにします。

      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
    5. 上記のように変更すると、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
  5. SELinux を使用している場合は、sshd の 2 番目のインスタンスのポートを SSH ポートに追加します。追加しないと、sshd の 2 番目のインスタンスがポートにバインドされません。

    # semanage port -a -t ssh_port_t -p tcp 22220
  6. システムの起動時にこのサービスが自動的に起動するように、sshd-second.service を有効にします。

    # systemctl enable sshd-second.service
  7. systemctl status コマンドを使用して sshd-second.service が実行中かどうかを確認します。
  8. さらに、サービスに接続して、ポートが正しく有効化されていることを確認します。

    ssh -p 22220 user@server

    ファイアウォールを使用している場合は、sshd の 2 番目のインスタンスへの接続を許可するように適切に設定されていることを確認してください。

17.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 ログインセッションを使用しません。

17.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 スクリプトは例として使用されます。

17.4.1. systemd サービスの説明の検索

#description で始まる行で、スクリプトに関する説明の情報を確認します。この説明は、サービス名と共に、ユニットファイルの [Unit] セクションの Description オプションで使用します。LSB ヘッダーの #Short-Description 行および #Description 行に同様のデータが含まれる場合があります。

17.4.2. systemd サービス依存関係の検索

LSB ヘッダーには、サービス間の依存関係を形成する複数のディレクティブが含まれる場合があります。そのほとんどは systemd ユニットオプションに変換できます。表17.4「LSB ヘッダーの依存関係オプション」 を参照してください。

表17.4 LSB ヘッダーの依存関係オプション

LSB オプション詳細同等のユニットファイル

Provides

サービスの起動ファシリティー名を指定します。この名前は他の init スクリプトで参照できます ( "$" 接頭辞を使用)。ただし、ユニットファイルが他のユニットをファイル名で参照できるようになったため、これは不要になりました。

Required-Start

必要なサービスの起動ファシリティー名が含まれます。これは、並び順の依存関係として変換され、起動ファシリティー名は、対応するサービスまたはそのサービスが属するターゲットに置き換えられます。たとえば、postfix の場合、$network の Required-Start 依存関係は、network.target の After 依存関係に変換されました。

AfterBefore

Should-Start

Required-Start よりも弱い依存関係を構成します。Should-Start 依存関係が失敗しても、サービスの起動には影響を及ぼしません。

AfterBefore

Required-StopShould-Stop

負の依存関係を構成します。

Conflicts

17.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 スクリプトの起動およびシャットダウンの優先順位を表します。この値は、 systemd init スクリプトが読み込まれていても、同等のユニットファイルはありません。

17.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 スクリプトを変換する際には、スクリプトのすべてのステートメントの目的を理解している必要があります。一部のステートメントはオペレーティングシステムのバージョンに固有のものであるため、そのステートメントを変換する必要はありません。一方、新規の環境では、サービス実行ファイルおよびサポートファイルやユニットファイルで調整が一部必要となる場合があります。

17.5. 既存のユニットファイルの変更

システムにインストールされるサービスは、/usr/lib/systemd/system/ ディレクトリーに保存されるデフォルトのユニットファイルと共に提供されます。システム管理者はこのファイルを直接変更できないため、カスタマイズは /etc/systemd/system/ ディレクトリーの設定ファイルに制限される必要があります。

手順

  1. 必要とされる変更の程度に応じて、以下の方法のいずれかを実施してください。

    • 補助設定ファイルのディレクトリーを /etc/systemd/system/unit.d/ に作成します。この方法は、ほとんどのユースケースで推奨されます。これにより、元のユニットファイルを参照しつつも、デフォルト設定を追加の機能で拡張できます。この場合、パッケージのアップグレードで導入されるデフォルトユニットへの変更は自動的に適用されます。詳細は「デフォルトのユニット設定の拡張」 を参照してください。
    • 元のユニットファイル /usr/lib/systemd/system/ のコピーを /etc/systemd/system/ に作成し、そこで変更を行います。コピーは元のファイルを上書きするため、パッケージの更新で導入される変更は適用されません。この方法は、パッケージの更新とは無関係に永続する重要なユニット変更を行う際に役に立ちます。詳細は「デフォルトのユニット設定の上書き」 を参照してください。
  2. ユニットのデフォルト設定に戻るには、/etc/systemd/system/ でカスタム作成した設定ファイルを削除します。
  3. システムを再起動せずにユニットファイルへの変更を適用するには、以下を実行します。

    systemctl daemon-reload

    daemon-reload オプションは、すべてのユニットファイルを再読み込みし、ユニットファイルへの変更をすぐに適用するのに必要な依存関係ツリー全体を再作成します。また、以下のコマンドを実行しても同じ結果になります。このコマンドの実行には root 権限が必要になります。

    init q
  4. 変更したユニットファイルが実行中のサービスに属する場合は、このサービスを再起動して新たな設定を反映させる必要があります。

    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 と命名されるのはそのためです。

17.5.1. デフォルトのユニット設定の拡張

本セクションでは、追加の設定オプションでデフォルトのユニットファイルを拡張する方法を説明します。

手順

  1. 追加の設定オプションでデフォルトのユニットファイルを拡張するには、最初に /etc/systemd/system/ に設定ディレクトリーを作成します。サービスユニットを拡張する場合は、root で以下のコマンドを実行します。

    mkdir /etc/systemd/system/name.service.d/

    name を、拡張する必要のあるサービスの名前に置き換えます。上記の構文はすべてのユニットタイプに適用されます。

  2. 作成したディレクトリーに設定ファイルを作成します。ファイル名の接尾辞は .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 つのタスクだけを扱う簡単な設定ファイルを作成することが推奨されます。これにより、他のサービスの設定ディレクトリーに簡単に移動したり、リンクできます。

  3. そのユニットに行った変更を適用するには、root で以下のコマンドを実行します。

    systemctl daemon-reload
    systemctl restart name.service

例17.1 httpd.service 設定の拡張

Apache サービスの起動時にカスタムシェルスクリプトが自動的に実行されるように httpd.service ユニットを変更するには、以下の手順で行います。

  1. ディレクトリーおよびカスタム設定ファイルを作成します。

    # mkdir /etc/systemd/system/httpd.service.d/
    # touch /etc/systemd/system/httpd.service.d/custom_script.conf
  2. Apache で自動的に起動するスクリプトが /usr/local/bin/custom.sh にある場合は、以下のテキストを custom_script.conf ファイルに追加します。

    [Service]
    ExecStartPost=/usr/local/bin/custom.sh
  3. ユニットの変更を適用するには、以下を実行します。

    # systemctl daemon-reload
    # systemctl restart httpd.service
注記

/etc/systemd/system/ の設定ディレクトリーの設定ファイルは、/usr/lib/systemd/system/ のユニットファイルに優先します。そのため、設定ファイルに、一度だけ指定できるオプション (DescriptionExecStart など) が含まれる場合は、このオプションのデフォルト値が上書きされます。「上書きされたユニットの監視」で説明されているように、 systemd-delta コマンドの出力では、一部のオプションは実際に上書きされますが、該当するユニットは常に [EXTENDED] とマークされます。

17.5.2. デフォルトのユニット設定の上書き

本セクションでは、デフォルトのユニット設定を上書きする方法を説明します。

手順

  1. ユニットファイルを提供するパッケージの更新後も変更を持続させるには、最初にファイルを /etc/systemd/system/ ディレクトリーにファイルをコピーします。それを行うには、root で以下のコマンドを実行します。

    cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

    name は、変更するサービスユニットの名前を表します。上記の構文はすべてのユニットタイプに適用されます。

  2. コピーされたファイルをテキストエディターで開き、必要な変更を行います。ユニットの変更を適用するには、root で以下のコマンドを実行します。

    systemctl daemon-reload
    systemctl restart name.service

例17.2 タイムアウト制限の変更

サービスごとにタイムアウト値を指定すると、正常に動作していないサービスによってシステムがフリーズすることを防ぐことができます。タイムアウト値を指定しないサービスには、通常のサービスの場合は 90 秒、そして SysV と互換性のあるサービスの場合は 300 秒と、それぞれデフォルトのタイムアウトが設定されています。

たとえば、httpd サービスのタイムアウト制限を延長するときは、以下を行います。

  1. httpd ユニットファイルを、/etc/systemd/system/ ディレクトリーにコピーします。

    cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service
  2. /etc/systemd/system/httpd.service ファイルを開き、[Service] セクションに TimeoutStartSec 値を指定します。

    …​
    [Service]
    …​
    PrivateTmp=true
    TimeoutStartSec=10
    
    [Install]
    WantedBy=multi-user.target
    …​
  3. systemd デーモンを再ロードします。

    systemctl daemon-reload
  4. オプション:新しいタイムアウト値を確認します。

    systemctl show httpd -p TimeoutStartUSec
注記

グローバルでタイムアウト制限を変更するには、/etc/systemd/system.conf ファイルの DefaultTimeoutStartSec を変更します。

17.5.3. 上書きされたユニットの監視

本セクションでは、上書きされたユニットファイルまたは変更されたユニットファイルの概要を表示する方法を説明します。

手順

  1. 上書きされたユニット、または変更したユニットファイルの概要を表示するには、以下のコマンドを実行します。

    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.

17.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 として解決されます。

17.6.1. 重要なユニット指定子

ワイルドカード文字 (ユニット指定子 とも呼ばれる) を、すべてのユニット設定ファイルで使用できます。ユニット指定子は、特定のユニットパラメーターを置き換え、ランタイム時に解釈されます。表17.5「重要なユニット指定子」 は、特にテンプレートユニットで便利なユニット指定子を一覧表示します。

表17.5 重要なユニット指定子

ユニット指定子意味詳細

%n

完全ユニット名

タイプ接尾辞を含む完全ユニット名を表します。%N には同じ意味がありますが、禁止文字を ASCII コードに置き換えます。

%p

接頭辞名

タイプ接尾辞が削除されたユニット名を表します。インスタンス化されたユニットの %p は、ユニット名の「@」文字の前の部分を表します。

%i

インスタンス名

インスタンス化されたユニット名の「@」文字およびタイプ接尾辞間の部分です。%I には同じ意味がありますが、禁止文字を ASCII コードにも置き換えます。

%H

ホスト名

ユニット設定を読み込んだ時に稼働しているシステムのホスト名を表します。

%t

ランタイムディレクトリー

ランタイムディレクトリーを表します。これは、root ユーザーの /run、または非特権ユーザーの XDG_RUNTIME_DIR 変数の値になります。

ユニット指定子の詳細な一覧は、systemd.unit(5) の man ページを参照してください。

第18章 起動時間を短縮するための systemd の最適化

デフォルトで有効になっている systemd ユニットファイルの一覧があります。システムの起動時に、このようなユニットファイルで定義されているシステムサービスが自動的に実行し、システムの起動時間に影響を及ぼします。

本セクションでは、以下を説明します。

  • システムの起動パフォーマンスを調べるツール
  • systemd ユニットがデフォルトで無効になっている目的と、起動時間を短縮するために、このような systemd ユニットを無効にしても安全な状況

18.1. システムの起動パフォーマンスを調べる

システムの起動時のパフォーマンスを調べる場合は、systemd-analyze コマンドを使用できます。このコマンドでは、多数のオプションが使用できます。ただし、本セクションでは、起動時間を短縮するために、systemd を調整する際に重要なものだけを説明します。

オプションの完全リストおよび詳細な説明は、systemd-analyze の man ページを参照してください。

前提条件

システムの起動時に調整するために、systemd を調べる前に、有効なサービスの一覧を表示することもできます。

$ systemctl list-unit-files --state=enabled

システム全体の起動時間の分析

手順

  • システムが最後に起動してからの時間に関する総合的な情報を表示する場合は、次のコマンドを実行します。
$ systemd-analyze

ユニットの初期化時間の分析

手順

  • 各 systemd ユニットの初期化時間の詳細を確認する場合は、次のコマンドを実行します。
$ systemd-analyze blame

この出力では、システムが最後に起動した時に初期化にかかった時間に応じて、ユニットが降順で表示されます。

重要なユニットの識別

手順

  • システムが最後に起動した時に、初期化に最も時間がかかったユニットを特定するには、次のコマンドを実行します。
$ systemd-analyze critical-chain

この出力では、起動に非常に時間がかかっているユニットが、赤字で強調表示されています。

図18.1 systemd-analyze critical-chain コマンドの出力

systemd analyze critical

18.2. 無効にしても安全なサービスを選択するためのガイド

システムの起動時に時間がかかっている場合は、デフォルトで起動時に有効になるサービスの一部を無効にすることで、起動時間を短くできます。

このようなサービスを一覧表示するには、次のコマンドを実行します。

$ systemctl list-unit-files --state=enabled

サービスを無効にするには、次のコマンドを実行します。

# systemctl disable service_name

ただし、お使いのオペレーティングシステムが安全で、希望通りに機能できるように、特定のサービスは有効にしたままにしておく必要があります。

次の表は、無効にしても安全なサービスを選択するためのガイドとして使用できます。この表では、Red Hat Enterprise Linux 8 の最小インストールでデフォルトで有効になっているすべてのサービスと、各サービスを無効にしても安全かどうかを記載しています。

その他にも、サービスを無効にできる状況と、そのサービスを無効にすべきではない理由を示しています。

表18.1 RHEL 8 の最小インストールで、デフォルトで有効になっているサービス

サービス名無効にすることは可能か?詳細情報

auditd.service

はい

auditd.service は、カーネルからの監査メッセージが必要ない場合に限り無効にします。auditd.service を無効にすると、/var/log/audit/audit.log ファイルが生成されないことに注意してください。無効にすると、ユーザーログイン、サービスの起動、パスワードの変更などの、一般的に確認されるアクションまたはレビューをさかのぼって確認することはできません。auditd には、カーネルの部分と、サービスそのものが含まれることに注意してください。systemctl disable auditd コマンドを実行すると、サービスを無効にするだけで、カーネル部分は無効にしません。システムの監査を完全に無効にするには、カーネルコマンドラインに audit=0 と設定します。

autovt@.service

いいえ

このサービスは、本当に必要な場合に限り実行されるため、無効にする必要はありません。

crond.service

はい

crond.service を無効にすると crontab からアイテムが実行しないことに注意してください。

dbus-org.fedoraproject.FirewallD1.service

はい

firewalld.service へのシンボリックリンク

dbus-org.freedesktop.NetworkManager.service

はい

NetworkManager.service へのシンボリックリンク

dbus-org.freedesktop.nm-dispatcher.service

はい

NetworkManager-dispatcher.service へのシンボリックリンク

firewalld.service

はい

ファイアウォールが必要ない場合に限り firewalld.service を無効にします。

getty@.service

いいえ

このサービスは、本当に必要な場合に限り実行されるため、無効にする必要はありません。

import-state.service

はい

import-state.service は、ネットワークストレージからの起動が必要ない場合に限り無効にします。

irqbalance.service

はい

irqbalance.service は、CPU が 1 つしかない場合に限り無効にします。システムに CPU が複数ある場合は irqbalance.service を無効にしないでください。

kdump.service

はい

kdump.service は、カーネルクラッシュからのレポートが必要ない場合に限り無効にします。

loadmodules.service

はい

このサービスは、/etc/rc.modules ディレクトリーまたは /etc/sysconfig/modules ディレクトリーがなければ起動しません。つまり、RHEL 8 の最小インストールでは起動しません。

lvm2-monitor.service

はい

lvm2-monitor.service は、論理ボリュームマネージャー (LVM) を使用しない場合に限り無効にします。

microcode.service

いいえ

そのサービスは、CPU 内のマイクロコードソフトウェアの更新を提供するため、無効にしないでください。

NetworkManager-dispatcher.service

はい

NetworkManager-dispatcher.service は、ネットワーク設定変更の通知が必要ない場合 (静的ネットワークなど) に限り無効にします。

NetworkManager-wait-online.service

はい

NetworkManager-wait-online.service は、システムの起動直後にネットワーク接続が利用できるようになっている必要がない場合に限り無効にします。このサービスを有効にすると、ネットワーク接続が有効になるまで、システムの起動が完了しません。これにより、起動時間が大幅に長くなることがあります。

NetworkManager.service

はい

NetworkManager.service は、ネットワークへの接続が必要ない場合に限り無効にします。

nis-domainname.service

はい

nis-domainname.service は、ネットワークインフォメーションサービス (NIS) を使用しない場合に限り無効にします。

rhsmcertd.service

いいえ

 

rngd.service

はい

rngd.service は、システムでエントロピーがそれほど必要ない場合、またはハードウェアジェネレーターがない場合に限り無効にします。このサービスは、X.509 証明書の生成に使用されるシステム (たとえば FreeIPA サーバー) など、良好なエントロピーを多数必要とする環境で必要になります。

rsyslog.service

はい

rsyslog.service は、永続的なログが必要ない場合に限り、または systemd-journald を永続モードに設定した場合に限り無効にします。

selinux-autorelabel-mark.service

はい

selinux-autorelabel-mark.service は、SELinux を使用しない場合に限り無効にします。

sshd.service

はい

sshd.service は、OpenSSH サーバーへのリモートログインが必要ない場合に限り無効にします。

sssd.service

はい

sssd.service は、ネットワークを介して (たとえば LDAP や Kerberos を使用して) システムにログインするユーザーがいない場合に限り無効にします。sssd.service を無効にした場合は、sssd-* ユニットをすべて無効にすることを Red Hat は推奨します。

syslog.service

はい

rsyslog.service のエイリアス

tuned.service

はい

tuned.service は、パフォーマンスチューニングを使用する必要がない場合に限り無効にします。

lvm2-lvmpolld.socket

はい

lvm2-lvmpolld.socket は、論理ボリュームマネージャー (LVM) を使用しない場合に限り無効にします。

dnf-makecache.timer

はい

dnf-makecache.timerは、パッケージメターデータを自動的に更新する必要がない場合に限り無効にします。

unbound-anchor.timer

はい

unbound-anchor.timer は、DNSSEC (DNS Security Extensions) のルートトラストアンカーを毎日更新する必要がない場合に限り無効にします。このルートトラストアンカーは、DNSSEC 検証の Unbound リゾルバー、およびリゾルバーライブラリーにより使用されます。

サービスの詳細は、次のいずれかのコマンドを実行すると表示できます。

$ systemctl cat <service_name>
$ systemctl help <service_name>

systemctl cat コマンドは、/usr/lib/systemd/system/<service> の配下に置かれたサービスファイルの内容と、適用可能なすべてのオーバーライドを提供します。適用可能なオーバーライドには、/etc/systemd/system/<service> ファイルからのユニットファイルオーバーライドと、対応する unit.type.d ディレクトリーのドロップインファイルが含まれます。

ドロップインファイルの詳細は、systemd.unit の man ページを参照してください。

systemctl help コマンドは、特定サービスの man ページを表示します。

第19章 関連情報

systemd と、Red Hat Enterprise Linux での使用方法は、以下に挙げる資料を参照してください。

19.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 ページでは、プロセスの強制終了手順の設定が説明されています。

19.2. オンラインドキュメント

  • systemd ホームページ - プロジェクトのホームページでは、systemd に関する詳細情報が提供されています。

第20章 ユーザーアカウントおよびグループアカウントの管理の概要

ユーザーとグループの制御は、Red Hat Enterprise Linux (RHEL) システム管理の中核となる要素です。各 RHEL ユーザーには各種ログイン認証情報があり、さまざまなグループに割り当ててシステム権限をカスタマイズすることができます。

ファイルを作成するユーザーは、そのファイルの所有者 および グループ所有者です。ファイルには、所有者、グループ、およびそのグループ外のユーザーに対して読み取り、書き込み、実行のパーミッションが別々に割り当てられます。ファイルの所有者は、root ユーザーのみが変更できます。ファイルへのアクセス権限を変更できるのは、root ユーザー、ファイル所有者の両方です。通常ユーザーは、所有するファイルのグループ所有権を、所属するグループに変更できます。

各ユーザーは、ユーザー ID (UID) と呼ばれる一意の数値 ID に関連付けられています。各グループは グループ ID (GID) に関連付けられています。グループ内のユーザーは、そのグループが所有するファイルの読み取り、書き込み、実行を行う権限を共有します。

20.1. ユーザーとグループの概要

ファイルを作成するユーザーは、そのファイルの所有者 および グループ所有者です。ファイルには、所有者、グループ、およびそのグループ外のユーザーに対して読み取り、書き込み、実行のパーミッションが別々に割り当てられます。ファイルの所有者は、root ユーザーのみが変更できます。ファイルへのアクセス権限を変更できるのは、root ユーザー、ファイル所有者の両方です。通常ユーザーは、所有するファイルのグループ所有権を、所属するグループに変更できます。

各ユーザーは、ユーザー ID (UID) と呼ばれる一意の数値 ID に関連付けられています。各グループは グループ ID (GID) に関連付けられています。グループ内のユーザーは、そのグループが所有するファイルの読み取り、書き込み、実行を行う権限を共有します。

20.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_MINGID_MIN パラメーターを変更します。

手順

デフォルトで新規ユーザーに割り当てる ID を 5000 以降にするには、以下のコマンドを使用します。

  1. 任意のエディターで /etc/login.defs ファイルを開きます。
  2. UID の自動選択の最小値を定義する行を見つけます。

    # Min/max values for automatic uid selection in useradd
    #
    UID_MIN                  1000
  3. UID_MIN の値を 5000 から開始するように変更します。

    # Min/max values for automatic uid selection in useradd
    #
    UID_MIN                  5000
  4. 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 以上にしないようにしてください。

20.3. ユーザープライベートグループ

RHEL は、ユーザープライベートグループ (UPG) システム設定を使用するため、UNIX グループの管理が容易になります。ユーザープライベートグループは、新規ユーザーがシステムに追加されるたびに作成されます。ユーザープライベートグループは作成したユーザーと同じ名前となり、そのユーザーがそのユーザープライベートグループの唯一のメンバーになります。

UPG は、複数ユーザー間のプロジェクトの連携を簡素化します。さらに、UPG のシステム設定では、ユーザーおよびこのユーザーが所属するグループ両方がファイルまたはディレクトリーを変更できるので、新規作成されたファイルまたはディレクトリーのデフォルトの権限を安全に設定できます。

グループの一覧は、/etc/group 設定ファイルに保存されます。

第21章 Web コンソールでユーザーアカウントの管理

RHEL Web コンソールは、直接ターミナルにアクセスせずに、幅広い管理タスクを実行できるグラフィカルインターフェースを提供します。たとえば、システムユーザーアカウントの追加、編集、または削除が可能です。

本セクションの内容を読むと、以下を理解できます。

  • 既存のアカウントが存在する場所
  • 新規アカウントの追加方法
  • パスワードの有効期限の設定方法
  • ユーザーセッションを終了する方法および時期

前提条件

21.1. Web コンソールで管理されるシステムユーザーアカウント

RHEL Web コンソールに表示されているユーザーアカウントでは、以下が可能になります。

  • システムにアクセスする際にユーザーを認証する
  • システムへのアクセス権を設定する

RHEL Web コンソールは、システムに存在するすべてのユーザーアカウントを表示します。そのため、最初に Web コンソールにログインした直後は、ユーザーアカウントが少なくとも 1 つ表示されます。

RHEL Web コンソールにログインしたら、以下の操作を実行できます。

  • 新規ユーザーアカウントの作成
  • パラメーターの変更
  • アカウントのロック
  • ユーザーセッションの終了

21.2. Web コンソールで新規アカウントの追加

RHEL Web コンソールを使用して、ユーザーアカウントをシステムに追加し、アカウントに管理者権限を設定する場合は、以下の手順に従います。

前提条件

手順

  1. RHEL Web コンソールにログインします。
  2. アカウント をクリックします。
  3. 新規アカウントの作成 をクリックします。
  1. フルネーム フィールドにユーザーの氏名を入力します。

    RHEL Web コンソールは、入力した氏名からユーザー名が自動的に作成され、ユーザー名 フィールドに入力されます。名前の頭文字と、苗字で構成される命名規則を使用しない場合は、入力されたユーザー名を変更します。

  2. パスワード/確認 フィールドにパスワードを入力し、再度パスワードを入力します。

    フィールドの下にあるカラーバーは、入力したパスワードの強度を表し、弱いパスワードは使用できないようにします。

  1. 作成 をクリックして設定を保存し、ダイアログボックスを閉じます。
  2. 新規作成したアカウントを選択します。
  3. ロール で、サーバー管理者 を選択します。

    cockpit terminate session pf4

    これで アカウント 設定に新規アカウントが表示され、認証情報を使用してシステムに接続できるようになりました。

21.3. Web コンソールでパスワード有効期限の強制

デフォルトでは、ユーザーアカウントのパスワードに期限はありません。定義した日数が経過したら、システムパスワードが期限切れになるように設定できます。パスワードが期限切れになると、次回のログイン時にパスワードの変更が要求されます。

手順

  1. RHEL 8 Web コンソールにログインします。
  2. アカウント をクリックします。
  3. パスワードの有効期限を設定するユーザーアカウントを選択します。
  4. ユーザーアカウントの設定で パスワードを失効しない をクリックします。
  5. パスワードの有効期限 ダイアログボックスで、... 日ごとのパスワードの変更が必要を選択し、パスワードの期限が切れるまでの日数 (正の整数) を入力します。
  1. 変更 をクリックします。

検証手順

  • パスワードの有効期限が設定されていることを確認するには、アカウント設定を開きます。

    RHEL 8 Webコンソールには、有効期限を表すリンクが表示されます。

    cockpit password expiration date

21.4. Web コンソールでユーザーセッションの終了

ユーザーがシステムにログインすると、ユーザーセッションが作成されます。ユーザーセッションを終了すると、ユーザーはシステムからログアウトされます。これは、システムのアップグレードなどの、設定変更の影響を受ける管理タスクを実行する必要がある場合に便利です。

RHEL 8 Web コンソールの各ユーザーアカウントで、現在使用している Web コンソールセッション以外のセッションすべてを終了できます。これにより、システムへの不正アクセスを阻止できます。

手順

  1. RHEL 8 Web コンソールにログインします。
  2. アカウント をクリックします。
  3. セッションを終了するユーザーアカウントをクリックします。
  4. セッションの 終了 をクリックします。

    Terminate Session ボタンが無効になっている場合は、ユーザーがシステムにログインしていません。

    RHEL Web コンソールはセッションを終了します。

第22章 コマンドラインからのユーザーの管理

コマンドラインインターフェース (CLI) を使用してユーザーおよびグループを管理できます。これにより、Red Hat Enterprise Linux 環境でユーザーおよびユーザーグループを追加、削除、および変更できます。

22.1. コマンドラインでの新規ユーザーの追加

本セクションでは、useradd ユーティリティーを使用して、新しいユーザーを追加する方法を説明します。

前提条件

  • root アクセス

手順

  • 新規ユーザーを追加するには、以下を使用します。

    # useradd options username

    optionsuseradd コマンドのコマンドラインオプションに、username はユーザー名に置き換えます。

    例22.1 新規ユーザーの追加

    ユーザー ID が 5000 のユーザー sarah を追加するには、以下を使用します。

    +

    # useradd -u 5000 sarah

検証手順

  • 新規ユーザーが追加されたことを確認するには、id ユーティリティーを使用します。

    # id sarah

    返される出力は以下のとおりです。

    uid=5000(sarah) gid=5000(sarah) groups=5000(sarah)

関連情報

  • useradd の man ページ

22.2. コマンドラインでの新規グループの追加

本セクションでは、groupadd ユーティリティーを使用して、新しいユーザーを追加する方法を説明します。

前提条件

  • root アクセス

手順

  • 新規グループを追加するには、以下を使用します。

    # groupadd options group-name

    optionsgroupadd コマンドのコマンドラインオプションに、group-name はグループ名に置き換えます。

    例22.2 新規グループの追加

    グループ ID が 5000 のグループ sysadmins を追加するには、以下を使用します。

    +

    # groupadd -g 5000 sysadmins

検証手順

  • 新規グループが追加されていることを確認するには、tail ユーティリティーを使用します。

    # tail /etc/group

    返される出力は以下のとおりです。

    sysadmins:x:5000:

関連情報

  • groupadd の man ページ

22.3. コマンドラインでのグループへのユーザーの追加

本セクションでは、usermod ユーティリティーを使用して、ユーザーの補助グループにグループを追加する方法を説明します。

前提条件

  • root アクセス

手順

  • ユーザーの補助グループにグループを追加するには、以下を使用します。

    # usermod --append -G group-name username

    group-name はグループ名に、username はユーザー名に置き換えます。

    例22.3 グループへのユーザーの追加

    ユーザーの sysadmin をグループ system-administrators に追加するには、以下を使用します。

    +

    # usermod --append -G system-administrators sysadmin

検証手順

  • ユーザー sysadmin の補助グループに新規グループが追加されていることを確認するには、以下を使用します。

    # groups sysadmin

    返される出力は以下のとおりです。

    sysadmin: sysadmin system-administrators

22.4. グループディレクトリーの作成

UPG システム設定では、グループ ID 権限の設定 (setgid) をディレクトリーに適用できます。setgid を使用して、ディレクトリーを共有するグループプロジェクトの管理が簡単になります。setgid をディレクトリーに適用すると、ディレクトリー内に作成されたファイルは、そのディレクトリーを所有するグループに自動的に割り当てられます。このグループ内の書き込みおよび実行権限があるユーザーは、対象のディレクトリーにファイルを作成、変更、および削除できるようになりました。

次のセクションでは、グループディレクトリーを作成する方法を説明します。

前提条件

  • root アクセス

手順

  1. ディレクトリーを作成します。

    # mkdir directory-name

    directory-name は、ディレクトリー名に置き換えます。

  2. グループを作成します。

    # groupadd group-name

    group-name は、グループ名に置き換えます。

  3. ユーザーをグループに追加します。

    # usermod --append -G group-name username

    group-name はグループ名に、[role="abstract"]e _username はユーザー名に置き換えます。

  4. ディレクトリーのユーザーとグループの所有権は、group-name グループに関連付けます。

    # chown :group-name directory-name

    group-name はグループ名に、directory-name はディレクトリー名に置き換えます。

  5. ファイルおよびディレクトリーを作成および修正し、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

第23章 コマンドラインを使用したグループからのユーザーの削除

ユーザーが所属するグループを、削除するユーザーが含まれない新しいグループセットに上書きして、プライマリーグループまたは補助グループからユーザーを削除できます。

23.1. ユーザーのプライマリーグループの上書き

本セクションでは、usermod ユーティリティーを使用して、ユーザーのプライマリーグループを上書きする方法を説明します。

前提条件

  • root アクセス

手順

  • ユーザーのプライマリーグループを上書きするには、以下のコマンドを使用します。

    # usermod -g group-name username

    group-name はグループ名に、username はユーザー名に置き換えます。

    例23.1 ユーザーのプライマリーグループの変更

    ユーザー sarah がプライマリーグループ sarah1 に所属しており、ユーザーのプライマリーグループを sarah2 に変更する場合は、以下を使用します。

    # usermod -g sarah2 sarah

検証手順

  • ユーザーのプライマリーグループが上書きされていることを確認するには、以下を使用します。

    # groups sarah

    返される出力は以下のとおりです。

    sarah : sarah2

23.2. ユーザーの補助グループの上書き

本セクションでは、usermod ユーティリティーを使用して、ユーザーの補助グループを上書きする方法を説明します。

前提条件

  • root アクセス

手順

  • ユーザーの補助グループを上書きするには、以下のコマンドを使用します。

    # usermod -G group-name username

    group-name はグループ名に、username はユーザー名に置き換えます。

    例23.2 ユーザーの補助グループの変更

    ユーザー sarahsystem-administrator グループおよび developer グループに所属しており、system-administrator グループからユーザー sarah を削除する場合は、古いグループ一覧を新しいものに置き換えてください。これを行うには、以下を使用します。

    # usermod -G developer sarah

検証手順

  • ユーザーの補助グループが上書きされていることを確認するには、以下を使用します。

    # groups sarah

    返される出力は以下のとおりです。

    sarah : sarah developer

第24章 sudo アクセスの管理

システム管理者は、root 以外のユーザーに、通常 root ユーザー用に予約されている管理コマンドを実行できるようにする sudo アクセスを付与できます。これにより、root 以外のユーザーは、root ユーザーアカウントにログインせずに、このようなコマンドを実行できます。

24.1. sudoers のユーザー認可

/etc/sudoers ファイルは、sudo コマンドを使用して、どのユーザーがどのコマンドを実行できるかを指定します。ルールは、個別のユーザーおよびユーザーグループに適用できます。エイリアスを使用して、ホスト、コマンド、ユーザーのグループに対するルールの定義を簡素化することもできます。デフォルトのエイリアスは、/etc/sudoers ファイルの最初の部分で定義されます。

ユーザーが sudo 権限を使用して /etc/sudoers ファイルで許可されていないコマンドを実行しようとすると、システムは username: user NOT in sudoers が含まれるメッセージをジャーナルログに記録します。

デフォルトの /etc/sudoers ファイルは、認可の情報と例を提供します。行頭から # コメント文字を削除して、特定のサンプルルールをアクティベートできます。ユーザー認可に関連するセクションには、以下の概要が示されています。

## Next comes the main part: which users can run what software on
## which machines  (the sudoers file can be shared between multiple
## systems).

次の形式を使用して、新しい sudoers 認可を作成し、既存の認可を変更できます。

username hostname=path/to/command

詳細は以下のようになります。

  • username は、ユーザーまたはグループの名前です (例: user1 または %group1)。
  • hostname は、ルールが適用されるホストの名前です。
  • path/to/command は、コマンドへの完全パスです。また、コマンドパスの後にオプションを追加することにより、特定のオプションおよび引数を指定したコマンドのみを実行するようにユーザーを制限することもできます。オプションを指定しないと、すべてのオプションが有効な状態でコマンドを使用できます。

この変数のいずれかを ALL に置き換え、ルールをすべてのユーザー、ホスト、またはコマンドに適用できます。

警告

ALL ALL=(ALL) ALL などの過度に寛容なルールを使用すると、どのユーザーも、ホスト、ユーザー、コマンドはどれでも使用できます。このような設定をすると、セキュリティーリスクにつながる可能性があります。

! 演算子を使用して引数を負の値で指定できます。たとえば、!root を使用して、root ユーザー以外の全ユーザーを指定できます。許可リストを使用して特定のユーザー、グループ、およびコマンドを許可する方法は、拒否リストを使用して特定のユーザー、グループ、およびコマンドを拒否するよりも安全です。許可リストを使用すると、権限のない新規ユーザーまたはグループもブロックできす。

警告

alias コマンドでコマンドの名前を変更すると、このような規則が上書きされるため、コマンドに否定的な規則を使用しないでください。

システムは、/etc/sudoers ファイルを最初から最後まで読み取ります。したがって、ファイルにユーザーの複数のエントリーが含まれている場合、エントリーは順番に適用されます。値が競合する場合は、最も具体的な一致ではない場合でも、システムは最後の一致を使用します。

sudoers に新しいルールを追加する方法として、ルールを /etc/sudoers ファイルに直接入力する代わりに、/etc/sudoers.d/ ディレクトリーに新しいファイルを作成することが推奨されます。これは、このディレクトリーの内容は、システム更新時に保持されるためです。さらに、/etc/sudoers ファイル以外のファイルでエラーを修正することが簡単になります。システムは、/etc/sudoers ファイル内で以下の行に到達する際に、/etc/sudoers.d ディレクトリー内のファイルを読み取ります。

#includedir /etc/sudoers.d

この行の頭にある番号記号 # は構文の一部であり、行がコメントであることを意味するものではありません。そのディレクトリー内のファイル名にはピリオド . を使用することができません。チルダ ~ で終了しないでください。

24.2. ユーザーへの sudo アクセス権限の付与

システム管理者は、root 以外のユーザーが管理コマンドを実行できるように sudo アクセスを付与できます。sudo コマンドは、root ユーザーのパスワードを使用せずに、管理アクセスを持つユーザーを提供する方法です。

ユーザーが管理コマンドを実行する必要がある場合には、コマンドの前に sudo を指定してください。すると、そのコマンドは、root ユーザーのように実行されます。

以下の制限事項に注意してください。

  • /etc/sudoers 設定ファイルに一覧表示されているユーザーのみが sudo コマンドを使用できます。
  • コマンドは、root シェルではなく、ユーザーのシェルで実行されます。

前提条件

  • root アクセス

手順

  1. root で /etc/sudoers ファイルを開きます。

    # visudo

    /etc/sudoers ファイルは、sudo コマンドで適用されるポリシーを定義します。

  2. /etc/sudoers ファイルで、wheel 管理グループのユーザーに sudo アクセスを付与する行を見つけます。

    ## Allows people in group wheel to run all commands
    %wheel        ALL=(ALL)       ALL
  3. %wheel で始まる行に # コメント文字が含まれていないことを確認します。
  4. 変更を保存し、エディターを終了します。
  5. sudo アクセスを付与するユーザーを、wheel 管理グループに追加します。

     # usermod --append -G wheel username

    username は、ユーザー名に置き換えます。

    検証手順

    • ユーザーが wheel 管理グループに追加されていることを確認します。

      # id username
      uid=5000(username) gid=5000(_username) groups=5000(username),10(wheel)

24.3. 非特権ユーザーが特定のコマンドを実行できるようにする

権限のないユーザーが特定のワークステーションで特定のコマンドを実行することを許可するポリシーを設定できます。このポリシーを設定するには、sudoers.d ファイルを編集する必要があります。

前提条件

  • root アクセス

手順

  1. root で、/etc/ の下に新しい sudoers.d ディレクトリーを作成します。

    # mkdir -p /etc/sudoers.d/
  2. /etc/sudoers.d ディレクトリーに新規ファイルを作成します。

    # visudo -f /etc/sudoers.d/file-name

    file-name は、作成するファイルの名前に置き換えます。ファイルは自動的に開きます。

  3. 新たに作成されたファイルに次の行を追加します。

    username hostname = /path/to/the/command

    username は、ユーザー名に置き換えます。hostname は、ホスト名に置き換えます。/path/to/the/command は、コマンドへの絶対パス (例: /usr/bin/yum) に置き換えます。

  4. 変更を保存し、エディターを終了します。

    例24.1 特権のないユーザーが yum および dnf でプログラムをインストールできるようにする手順

    sudo 特権で yum ユーティリティーおよび dnf ユーティリティーを使用して、ユーザー sarahlocalhost.localdomain ワークステーションにプログラムをインストールするには、以下を使用します。

    1. root で、/etc/ の下に新しい sudoers.d ディレクトリーを作成します。

      # mkdir -p /etc/sudoers.d/
    2. /etc/sudoers.d ディレクトリーに新規ファイルを作成します。

      # visudo -f /etc/sudoers.d/sarah

      ファイルは自動的に開きます。

    3. 以下の行を /etc/sudoers.d/sarah ファイルに追加します。

      sarah localhost.localdomain = /usr/bin/yum, /usr/bin/dnf

      2 つのコマンドパスがコンマ (,) とスペースで区切られていることを確認します。

    4. オプション: ユーザー sarahsudo 特権の使用を試みるたびにメール通知を受け取るには、以下の行をファイルに追加します。

      Defaults    mail_always
      Defaults    mailto="email@domain.com"
    5. ユーザー sarahsudo 権限で yum コマンドを実行できるかどうかを確認するには、アカウントを切り替えます。

      # su sarah -
    6. sudo yum コマンドを入力します。

      $ sudo yum
      [sudo] password for sarah:

      ユーザー sarahsudo パスワードを入力します。

    7. システムは、yum コマンドおよびオプションの一覧を表示します。

      ...
      usage: yum [options] COMMAND
      ...

      sarah is not in the sudoers file.This incident will be reported. のメッセージを受信する場合は、設定が正しく完了しませんでした。この手順を root で実行し、手順が確実に実行されたことを確認します。

24.4. 関連情報

  • sudo(8) の man ページ
  • visudo(8) の man ページ

第25章 root パスワードの変更およびリセット

既存の root パスワードが要件を満たさないか、パスワードを忘れた場合には、root ユーザーおよび root 以外のユーザーの両方として、パスワードを変更またはリセットできます。

25.1. root ユーザーとしての root パスワードの変更

本セクションでは、passwd コマンドを使用して、root ユーザーで root パスワードを変更する方法を説明します。

前提条件

  • root アクセス

手順

  • root パスワードを変更する場合は、次のコマンドを実行します。

    # passwd

    変更する前に、現在のパスワードを入力するように求められます。

25.2. root 以外のユーザーが root パスワードを変更またはリセット

本セクションでは、passwd コマンドを使用して、root 以外のユーザーで root パスワードを変更またはリセットする方法を説明します。

前提条件

  • root 以外のユーザーとしてログインできる。
  • wheel 管理グループのメンバーである。

手順

  • wheel グループに属する root ユーザー以外のユーザーとして root パスワードを変更またはリセットするには、以下を使用します。

    $ sudo passwd root

    root パスワードを変更する前に、root 以外のユーザーのパスワードを入力するように求められます。

25.3. 起動時の root パスワードのリセット

root 以外のユーザーとしてログインできない場合や、wheel 管理グループに所属しない場合は、特別な chroot jail 環境に切り替えることで起動時に root パスワードをリセットできます。

手順

  1. システムを再起動して、GRUB 2 ブート画面で e キーを押して、起動プロセスを中断します。

    カーネルブートパラメーターが表示されます。

    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
  2. 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

    Ctrl+e を押して、行の最後に移動します。

  3. rd.breaklinux で始まる行の最後に追加します。

    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
  4. Ctrl+x を押して、変更したパラメーターでシステムを起動します。

    switch_root プロンプトが表示されます。

  5. ファイルシステムを書き込み可能で再マウントします。

    mount -o remount,rw /sysroot

    ファイルシステムは、/sysroot ディレクトリーに読み取り専用としてマウントされます。書き込み可能なファイルシステムとして再マウントすると、パスワードを変更できます。

  6. chroot 環境に入ります。

    chroot /sysroot

    sh-4.4# プロンプトが表示されます。

  7. root パスワードをリセットします。

    passwd

    コマンドラインに表示される指示に従って、root パスワードの変更を完了します。

  8. 次回のシステム起動時に SELinux の再ラベルプロセスを有効にします。

    touch /.autorelabel
  9. chroot 環境を終了します。

    exit
  10. switch_root プロンプトを終了します。

    exit
  11. SELinux の再ラベルプロセスが終了するまで待機します。大規模なディスクの再ラベルには時間がかかる可能性があることに注意してください。プロセスが完了すると、システムが自動的に再起動します。

検証手順

  1. root パスワードが正常に変更されたことを確認するには、通常のユーザーとしてログインし、ターミナルを開きます。
  2. root としてインタラクティブシェルを実行します。

    $ su
  3. 新しい root パスワードを入力します。
  4. 現在の実効ユーザー ID に関連付けられたユーザー名を出力します。

    whoami

    返される出力は以下のとおりです。

    root

第26章 ファイル権限の管理

ファイルのパーミッションは、ユーザーおよびグループのアカウントで、ファイルとディレクトリーのコンテンツを表示、変更、アクセス、および実行する機能を制御します。

すべてのファイルまたはディレクトリーには、以下のレベルの所有権があります。

  • ユーザー所有者 (u)。
  • グループの所有者 (g)。
  • その他 (o)。

各所有権レベルには、以下のパーミッションを割り当てることができます。

  • 読み取り (r)。
  • 書き込み (w)。
  • 実行 (x)。

ファイルの execute 権限があると、そのファイルを実行するできることに注意してください。ディレクトリーの実行権限では、ディレクトリーのコンテンツにアクセスできますが、実行はできません。

新規ファイルまたはディレクトリーが作成されると、デフォルトのパーミッションセットが自動的に割り当てられます。ファイルまたはディレクトリーのデフォルトパーミッションは、以下の 2 つの要素に基づいています。

  • 基本パーミッション。
  • ユーザーのファイル作成モードマスク (umask)

26.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-) で、すべてのユーザーに読み取りおよび書き込み権限を付与します。ファイルの所有者、グループ、その他のユーザーは、ファイルの読み取りと編集が可能です。

例26.1 ファイルのパーミッション

ファイルに以下のパーミッションがある場合:

$ ls -l
-rwxrw----. 1 sysadmins sysadmins 2 Mar 2 08:43 file
  • - ファイルであることを示します。
  • rwx は、ファイルの所有者にファイルの読み取り、書き込み、実行のパーミッションがあることを示します。
  • rw- は、グループに読み取りと書き込みのパーミッションがあるが、ファイルの実行はできません。
  • --- は、他のユーザーにファイルの読み取り、書き込み、実行のパーミッションがないことを示します。
  • . は、SELinux セキュリティーコンテキストがファイルに設定されていることを示しています。

例26.2 ディレクトリーのパーミッション

ディレクトリーに以下のパーミッションがある場合:

$ ls -dl directory
drwxr-----. 1 sysadmins sysadmins 2 Mar 2 08:43 directory
  • d は、ディレクトリーであることを示します。
  • rwx は、ディレクトリーの所有者にディレクトリーの内容を読み取り、書き込み、およびアクセスするパーミッションがあることを示します。

    ディレクトリーの所有者は、ディレクトリー内のアイテム (ファイル、サブディレクトリー) を表示して、アイテムのコンテンツへのアクセスや変更が可能です。

  • r-- は、グループに読み取りのパーミッションがあるが、ディレクトリーのコンテンツへの書き込みやアクセスはできないことを示します。

    ディレクトリーを所有するグループのメンバーは、ディレクトリー内の項目を表示できます。ディレクトリー内のアイテムに関する情報にアクセスしたり、変更したりすることはできません。

  • --- は、他のユーザーがディレクトリーの内容の読み取り、書き込み、またはアクセスパーミッションがないことを示します。

    ディレクトリーのユーザー所有者またはグループ所有者ではない場合に、そのディレクトリーのアイテムを表示したり、アイテムの情報にアクセスしたり、変更したりできません。

  • . は、SELinux セキュリティーコンテキストがディレクトリーに設定されていることを示しています。
注記

ファイルまたはディレクトリーに自動的に割り当てられる基本パーミッションは、最終的にファイルまたはディレクトリーに指定されるデフォルトのパーミッション ではありません。ファイルまたはディレクトリーを作成すると、umask により基本パーミッションが変更されます。基本パーミッションと umask の組み合わせにより、ファイルおよびディレクトリーのデフォルトパーミッションが作成されます。

26.2. ユーザーのファイル作成モードマスク

ユーザーファイル作成モードマスク (umask) は、新規作成ファイルおよびディレクトリーにファイル権限を設定する方法を制御する変数です。umask は、基本パーミッション値からパーミッションを自動的に削除し、linux システム全体のセキュリティーを強化します。umask は、シンボリック 値または 8 進数 の値で表すことができます。

パーミッション

シンボリック値

8 進数値

読み取り、書き込み、実行

rwx

0

読み取りおよび書き込み

rw-

1

読み取りおよび実行

r-x

2

読み取り

r--

3

書き込みおよび実行

-wx

4

書き込み

-w-

5

実行

--x

6

権限なし

---

7

標準ユーザーのデフォルトの umask0002 です。root ユーザーのデフォルトの umask0022 です。

umask の最初の数字は、特別なパーミッション (スティッキービット) を表します。umask の最後の 3 桁はユーザーの所有者 (u)、グループの所有者 (g) およびその他 (o) からそれぞれ削除したパーミッションを表します。

例26.3 ファイルの作成時に umask を適用

以下の例では、umask の 8 進数値 0137 が基本パーミッション 777 に適用され、デフォルトパーミッション 640 のファイルが作成されます。

Users Groups Umask Example

26.3. デフォルトのファイル権限

デフォルトのパーミッションは、新規作成ファイルおよびディレクトリーに対して自動的に設定されます。デフォルトのパーミッションの値は、umask を基本パーミッションに適用して決定します。

例26.4 標準ユーザーが作成したディレクトリーのデフォルト権限

標準ユーザー が新しい ディレクトリー を作成すると、umask002 (rwxrwxr-x) に、ディレクトリーの基本パーミッションは 777 (rwxrwxrwx) に設定されます。これにより、デフォルトのパーミッションが 775 (drwxrwxr-x) になります。

 

シンボリック値

8 進数値

基本パーミッション

rwxrwxrwx

777

Umask

rwxrwxr-x

002

デフォルトパーミッション

rwxrwxr-x

775

このパーミッションでは、ディレクトリーの所有者とグループはディレクトリーのコンテンツの表示、ディレクトリーでのアイテムの作成、削除、編集、サブディレクトリーへの移動が可能です。他のユーザーはディレクトリーの内容を表示して、サブディレクトリーに移動することしかできません。

例26.5 標準ユーザーが作成したファイルのデフォルト権限

標準ユーザー が新しい ファイル を作成すると、umask002 (rwxrwxr-x) に、ファイルの基本パーミッションは 666 (rw-rw-rw-) に設定されます。これにより、デフォルトのパーミッション 664 (-rw-rw-r--) になります。

 

シンボリック値

8 進数値

基本パーミッション

rw-rw-rw-

666

Umask

rwxrwxr-x

002

デフォルトパーミッション

rw-rw-r--

664

このパーミッションでは、ファイルの所有者とグループはファイルの読み取りと編集が可能ですが、他のユーザーはこのファイルの読み取りしかできません。

例26.6 root ユーザーが作成したディレクトリーのデフォルト権限

root ユーザー が新規 ディレクトリー を作成すると、umask022 (rwxr-xr-x) に、ディレクトリーの基本パーミッションは 777 (rwxrwxrwx) に設定されます。これにより、デフォルトのパーミッションが 755 (rwxr-xr-x) になります。

 

シンボリック値

8 進数値

基本パーミッション

rwxrwxrwx

777

Umask

rwxr-xr-x

022

デフォルトパーミッション

rwxr-xr-x

755

このパーミッションでは、ディレクトリーの所有者はディレクトリーの内容の表示、ディレクトリー内のアイテムの作成、削除、編集、サブディレクトリーへの移動が可能です。グループとその他のユーザーは、ディレクトリーの内容の表示とサブディレクトリーの移動のみが可能です。

例26.7 root ユーザーが作成したファイルのデフォルト権限

root ユーザー が新規 ファイル を作成すると、umask022 (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

このパーミッションでは、ファイルの所有者はファイルを読み取りと編集が可能ですが、グループや他のユーザーはこのファイルの読み取りのみが可能です。

注記

セキュリティー上の理由から、通常のファイルに umask000 (rwxrwxrwx) に設定されていても、デフォルトで実行権限がありません。ただし、ディレクトリーは実行権限を持つ状態で作成できます。

26.4. シンボリック値を使用したファイル権限の変更

chmod ユーティリティーにシンボリック値 (組み合わせ文字および記号) を付けて、ファイルまたはディレクトリーのファイルのパーミッションを変更できます。

以下の パーミッション を割り当てることができます。

  • 読み取り (r)
  • 書き込み (w)
  • 実行 (x)

パーミッションは、以下の レベルの所有権 に割り当てることができます。

  • ユーザー所有者 (u)
  • グループ所有者 (g)
  • その他 (o)
  • すべて (a)

パーミッションを追加または削除するには、以下の 記号 を使用できます。

  • +: 既存のパーミッションの上にパーミッションを追加します。
  • -: 既存のパーミッションからパーミッションを削除します。
  • =: 既存のパーミッションを削除し、新しいパーミッションを明示的に定義します。

手順

  • ファイルまたはディレクトリーのパーミッションを変更するには、以下を使用します。

    $ chmod <level><operation><permission> file-name

    <level> は、パーミッションを設定する 所有権のレベル に置き換えます。<operation> は、署名 の 1 つに置き換えます。<permission> は、割り当てる パーミション に置き換えます。file-name は、ファイルまたはディレクトリーの名前に置き換えます。たとえば、すべてのユーザーに読み取り、書き込み、実行 (rwx) my-script.sh のパーミッションを付与するには、chmod a=rwx my-script.sh コマンドを使用します。

    詳細は、「ベースパーミッション」を参照してください。

検証手順

  • 特定のファイルのパーミッションを表示するには、以下を使用します。

    $ ls -l file-name

    file-name は、ファイルの名前に置き換えます。

  • 特定のディレクトリーのパーミッションを表示するには、以下を使用します。

    $ ls -dl directory-name

    directory-name は、ディレクトリー名に置き換えます。

  • 特定のディレクトリー内の全ファイルのパーミッションを表示するには、以下を使用します。

    $ ls -l directory-name

    directory-name は、ディレクトリー名に置き換えます。

例26.8 ファイルおよびディレクトリーの権限の変更

  • my-file.txt のパーミッションを -rw-rw-r-- から -rw------ に変更するには以下を使用します。

    1. my-file.txt の現在のパーミッションを表示します。

      $ ls -l my-file.txt
      -rw-rw-r--. 1 username username 0 Feb 24 17:56 my-file.txt
    2. グループ所有者 (g) およびその他のファイル (o) からファイルを読み取り、書き込み、実行 (rwx) するパーミッションを削除します。

      $ chmod go= my-file.txt

      パーミッションを等号 (=) の後ろに指定していない場合には自動的に無視される点に注意してください。

    3. my-file.txt のパーミッションが正しく設定されていることを確認します。

      $ ls -l my-file.txt
      -rw-------. 1 username username 0 Feb 24 17:56 my-file.txt
  • my-directory のパーミッションを drwxrwx--- から drwxrwxr-x に変更するには、以下を使用します。

    1. my-directory の現在のパーミッションを表示します。

      $ ls -dl my-directory
      drwxrwx---. 2 username username 4096 Feb 24 18:12 my-directory
    2. 全ユーザー (a) の読み取り、書き込み、実行 (rwx) アクセスを追加します。

      $ chmod o+rx my-directory
    3. my-directory とそのコンテンツが正しく設定されていることを確認します。

      $ ls -dl my-directory
      drwxrwxr-x. 2 username username 4096 Feb 24 18:12 my-directory

26.5. 8 進数値を使用したファイル権限の変更

chmod ユーティリティーに 8 進数値(数値)を指定して chmod ユーティリティーを使用し、ファイルまたはディレクトリーのファイルパーミッションを変更できます。

手順

  • 既存のファイルまたはディレクトリーのファイル権限を変更するには、以下を使用します。

    $ chmod octal_value file-name

    file-name は、ファイルまたはディレクトリーの名前に置き換えます。octal_value は 8 進数値に置き換えます。詳細は、「ベースパーミッション」を参照してください。

第27章 umask の管理

umask ユーティリティーを使用して、umask の現在の値またはデフォルト値を表示、設定、または変更できます。

27.1. umask の現在の値の表示

umask ユーティリティーを使用して、umask の現在の値をシンボリックモードまたは 8 進数モードで表示できます。

手順

  • umask の現在の値をシンボリックモードで表示するには、以下のコマンドを使用します。

    $ umask -S
  • umask の現在の値を 8 進法で表示するには、以下のコマンドを使用します。

    $ umask
    注記

    umask を 8 進法で表示するには、4 桁の数字(0002 または 0022)で表示される場合があります。umask の最初の数字は、特殊ビット (スティッキービット、SGID ビット、または SUID ビット) を表します。最初の数字を 0 に設定すると、特別なビットは設定されません。

27.2. デフォルトの bash umask の表示

bashkshzshtcsh などの多くのシェルを使用できます。これらのシェルはログインまたは nologin シェルとして動作します。ログインシェルは通常、ネイティブまたは GUI ターミナルを開いて起動します。

ログインシェルまたは nologin シェルのどちらでコマンドを実行しているかを確認するには、echo $0 コマンドを使用します。

例27.1 ログインまたは nologin bash シェルで作業しているかどうかの確認

  • echo $0 コマンドの出力が bash を返す場合、nologin シェルでコマンドを実行します。

    $ echo $0
    bash

    nologin シェルのデフォルトの umask は、/etc/bashrc 設定ファイルで設定します。

  • echo $0 コマンドの出力が -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

27.3. シンボリック値を使用した umask の設定

シンボリック値 (組み合わせ文字および記号) を指定して umask ユーティリティーを使用し、現在のシェルセッションの umask を設定できます。

以下の パーミッション を割り当てることができます。

  • 読み取り (r)
  • 書き込み (w)
  • 実行 (x)

パーミッションは、以下の レベルの所有権 に割り当てることができます。

  • ユーザー所有者 (u)
  • グループ所有者 (g)
  • その他 (o)
  • すべて (a)

パーミッションを追加または削除するには、以下の 記号 を使用できます。

  • +: 既存のパーミッションの上にパーミッションを追加します。
  • -: 既存のパーミッションからパーミッションを削除します。
  • =: 既存のパーミッションを削除し、新しいパーミッションを明示的に定義します。

    注記

    パーミッションを等号 (=) の後ろに指定していない場合には自動的に無視されます。

手順

  • 現在のシェルセッションの umask を設定するには、以下のコマンドを使用します。

    $ umask -S <level><operation><permission>

    <level> は、umask を設定する 所有権のレベル に置き換えます。<operation> は、署名 の 1 つに置き換えます。<permission> は、割り当てる パーミッション に置き換えます。たとえば、umasku=rwx,g=rwx,o=rwx に設定するには umask -S a=rwx を使用します。

    詳細は、「ユーザーファイル作成モード」を参照してください。

    注記

    umask は、現在のシェルセッション限定で有効になります。

27.4. 8 進数値を使用した umask の設定

8 進数値 (数字) を指定して umask ユーティリティーを使用し、現在のシェルセッションの umask を設定できます。

手順

  • 現在のシェルセッションの umask を設定するには、以下のコマンドを使用します。

    $ umask octal_value

    octal_value は 8 進数値に置き換えます。詳細は、「ユーザーファイル作成モードマスク」を参照してください。

    注記

    umask は、現在のシェルセッション限定で有効になります。

27.5. nologin シェルのデフォルト umask の変更

/etc/bashrc ファイルを変更して、標準ユーザーのデフォルトの bash umask を変更できます。

前提条件

  • root アクセス

手順

  1. root として、任意のエディターで /etc/bashrc ファイルを開きます。
  2. 以下のセクションを変更して、新しいデフォルトの bash umask を設定します。

        if [ $UID -gt 199 ] && [ id -gn = id -un ]; then
           umask 002
        else
           umask 022
        fi

    umask (002) のデフォルト値を別の進数値に置き換えます。詳細は、「ユーザーファイル作成モードマスク」を参照してください。

  3. 変更を保存し、エディターを終了します。

27.6. ログインシェルのデフォルト umask の変更

/etc/profile ファイルを変更して、root ユーザーのデフォルトの bash umask を変更できます。

前提条件

  • root アクセス

手順

  1. root として、任意のエディターで /etc/profile ファイルを開きます。
  2. 以下のセクションを変更して、新しいデフォルトの bash umask を設定します。

    if [ $UID -gt 199 ] && [ /usr/bin/id -gn = /usr/bin/id -un ]; then
        umask 002
    else
        umask 022
    fi

    umask (022) のデフォルト値を別の 8 進数値に置き換えます。詳細は、「ユーザーファイル作成モードマスク」を参照してください。

  3. 変更を保存し、エディターを終了します。

27.7. 特定ユーザーのデフォルトの umask の変更

特定ユーザーのデフォルトの umask を変更するには、そのユーザーの .bashrc を変更します。

手順

  • umask の 8 進数値を指定する行を、特定ユーザーの .bashrc ファイルに追加します。

    $ echo 'umask octal_value' >> /home/username/.bashrc

    octal_value は 8 進数値に、username はユーザー名に置き換えます。詳細は、「ユーザーファイル作成モードマスク」を参照してください。

27.8. 新規作成したホームディレクトリーのデフォルト UMASK の設定

新規作成したユーザーのホームディレクトリーの UMASK を指定するパーミッションは、/etc/login.defs ファイルを修正して変更できます。

手順

  1. root として、任意のエディターで /etc/login.defs ファイルを開きます。
  2. 以下のセクションを変更して、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 進数値に置き換えます。詳細は、「ユーザーファイル作成モードマスク」を参照してください。

  3. 変更を保存し、エディターを終了します。

第28章 RHEL 8 での dnstap の使用

dnstap ユーティリティーは、着信名クエリーの詳細を監視およびログに記録する高度な方法を提供します。named サービスから送信されたメッセージを記録します。本セクションでは、dnstap を使用して DNS クエリーを記録する方法を説明します。

28.1. RHEL 8 で dnstap を使用した DNS クエリーの記録

ネットワーク管理者は、DNS クエリーを記録し、ドメインの正常性と共に Web サイトまたは IP アドレス情報を収集できます。

前提条件

  • BIND パッケージをバージョン bind-9.11.26-2 以降にアップグレードします。
警告

BIND バージョンがすでにインストールされ、実行されている場合、新しいバージョンの BIND を追加すると、既存のバージョンが上書きされます。

手順

DNS クエリーを記録する手順は次のとおりです。

  1. options ブロックの /etc/named.conf ファイルを編集し、dnstap と target ファイルを有効にします。

    options
    {
    # …
    
    dnstap { all; }; # Configure filter
    dnstap-output file “/var/named/data/dnstap.bin”;
    
    # …
    };
    # end of options

    ( all | auth | client | forwarder | resolver | update ) [ ( query | response ) ];

    dnstap フィルターには、dnstap {} ブロック内に、; で区切られた複数の定義が含まれています。

    ルールごとの構文を以下に示します。

    • auth: 権威ゾーンの応答または回答。
    • client: 内部クライアントクエリーまたは回答。
    • forwarder: 転送クエリーまたは応答。
    • resolver: 反復的解決クエリーまたは応答。
    • update: 動的ゾーン更新要求。
    • all: 上記のオプションのいずれか。
    • query | response: クエリーまたは応答キーワードが指定されていない場合、両方を記録。

      以下の例では、auth 応答のみ、client queries および動的 updates のクエリーと応答の両方を要求します。

    Example:
    
    dnstap {auth response; client query; update;};
  2. アクティブなログの定期的なロールアウトを設定します。

    以下の例では、ユーザー編集のスクリプトの内容は、cron で 1 日 1 回実行されます。数値 3 はその番号に制限されたバックアップログファイルを示します。ファイルが削除されるため、.2 接尾辞に到達しません。

    Example:
    
    sudoedit /etc/cron.daily/dnstap
    
    #!/bin/sh
    rndc dnstap -roll 3
    mv /var/named/data/dnstap.bin.1 \ /var/log/named/dnstap/dnstap-$(date -I).bin
    
    # use dnstap-read to analyze saved logs
    sudo chmod a+x /etc/cron.daily/dnstap
  3. dnstap-read ユーティリティーを使用して、人間が判読できる形式でログを処理および分析します。

    以下の例では、詳細な dnstap 出力が YAML ファイル形式で出力されます。

    Example:
    
    dnstap-read -y [file-name]

第29章 アクセス制御一覧の管理

各ファイルおよびディレクトリーには、ユーザー所有者とグループ所有者を一度に指定できます。他のファイルやディレクトリーを非公開のままにし、別のユーザーまたはグループが所有する特定のファイルまたはディレクトリーにアクセスできるようなユーザーのパーミッションを付与する場合には、Linux アクセス制御リスト (ACL) を使用できます。

29.1. 現在のアクセス制御リストの表示

getfacl ユーティリティーを使用して、現在の ACL を表示できます。

手順

  • 特定のファイルまたはディレクトリーの現在の ACL を表示するには、以下を使用します。

    $ getfacl file-name

    file-name は、ファイルまたはディレクトリーの名前に置き換えます。

29.2. アクセス制御一覧の設定

setfacl ユーティリティーを使用して、ファイルまたはディレクトリーに ACL を設定できます。

前提条件

  • root アクセス

手順

  • ファイルまたはディレクトリーに ACL を設定するには、以下を使用します。
# setfacl -m u:username:symbolic_value file-name

username はユーザー名に、symbolic_value はシンボリック値に、file-name はファイルまたはディレクトリーの名前に置き換えます。詳細は、 setfacl の man ページを参照してください。

例29.1 グループプロジェクトのパーミッションの変更

以下の例では、root グループに所属する root ユーザーが所有する group-project ファイルのパーミッションを修正する方法を説明します。このファイルは以下のように設定します。

  • 誰にも実行権限がない。
  • ユーザー andrew のパーミッションは rw- である。
  • susan ユーザーのパーミッションは --- である。
  • 他のユーザーのパーミッションは r-- である。

手順

# setfacl -m u:andrew:rw- group-project
# setfacl -m u:susan:--- group-project

検証手順

  • ユーザー andrewrw- パーミッションがあり、ユーザー susan には --- パーミッションがあり、その他のユーザーに r-- パーミッションがあることを確認するには、以下を実行します。

    $ getfacl group-project

    返される出力は以下のとおりです。

    # file: group-project
    # owner: root
    # group: root
    user:andrew:rw-
    user:susan:---
    group::r--
    mask::rw-
    other::r--

第30章 Chrony スイートを使用した NTP の設定

IT では、さまざまな理由で正確な時間の維持が重要です。たとえばネットワーキングでは、パケットとログのタイムスタンプが正確であることが必要になります。Linux システムでは、NTP プロトコルがユーザー領域で実行しているデーモンにより実装されます。

ユーザー領域のデーモンは、カーネルで実行しているシステムクロックを更新します。システムクロックは、さまざまなクロックソースを使用して時間を維持します。一般的に使用されるのは Time Stamp Counter (TSC) です。TSC は、最後にリセットされた時点からのサイクル数を計測する CPU レジスターです。非常に高速でハイレゾリューションであり、中断も発生しません。

Red Hat Enterprise Linux 8 では、NTP プロトコルは chronyd デーモンにより実装されます。このデーモンは、chrony パッケージのリポジトリーから利用できます。

以下のセクションでは、 chrony NTP を設定するスイート。

30.1. chrony スイートの概要

chrony Network Time Protocol(NTP) の実装です。become を使用して、 chrony:

  • システムクロックを、NTP サーバーと同期する
  • システムクロックを、GPS レシーバーなどの基準クロックと同期する
  • システムクロックを、手動で入力した時間と同期する
  • ネットワーク内の他のコンピューターにタイムサービスを提供する NTPv4(RFC 5905) サーバーまたはピアとして使用

chrony ネットワーク接続が頻繁に切断される、ネットワークの混雑が長時間続く、温度が変わる(一般的なコンピューターのクロックは温度に敏感)といったさまざまな状況や、継続的に実行されない、または仮想マシンで実行しているシステムなど、幅広い状態でも良好に動作します。

インターネット上で同期している 2 つのマシン間の一般的精度は数ミリ秒以内、LAN 上のマシン間では数十マイクロ秒以内です。ハードウェアのタイムスタンプまたはハードウェア基準クロックは、同期している 2 つのマシン間の精度をサブマイクロ秒レベルにまで高めることができます。

chrony chronyd、ユーザースペースで実行するデーモン、 chronycchronyd のパフォーマンスを監視し、実行時にさまざまなオペレーティングパラメーターを変更するのに使用できるコマンドラインプログラム

module_version は、 chrony chronyd デーモンは、コマンドラインユーティリティーで監視および制御できます。 chronyc.このユーティリティーは、chronyd の現在の状態に対してクエリーを実行し、その設定を変更する多数のコマンド入力を可能にするコマンドプロンプトを提供します。デフォルトでは、chronyd は、 chronycただし、リモートホストから監視コマンドを受け付けるように設定することも可能です。リモートアクセスは制限する必要があります。

30.2. chronyc を使用した chronyd の制御

本セクションでは、以下を使用して chronyd を制御する方法を説明します。 chronyc コマンドラインユーティリティー。

Procedure

  1. コマンドラインユーティリティーを使用して chronyd のローカルインスタンスを変更するには、以下を行います。 chronyc インタラクティブモードで、root で次のコマンドを実行します。

    # chronyc

    chronyc 制限されたコマンドを使用する場合は、root で実行する必要があります。

    module_version は、 chronyc コマンドプロンプトは以下のようになります。

    chronyc>
  2. コマンドの一覧を表示するには、help と入力します。
  3. 以下のように、コマンドと合わせて呼び出した場合には、非対話的なコマンドモードでユーティリティーを呼び出すこともできます。

    chronyc command
注記

変更内容は、 chronyc 永続的ではないので、chronyd を再起動すると元に戻ります。永続的に変更する場合は、/etc/chrony.conf を変更してください。

30.3. chrony への移行

Red Hat Enterprise Linux 7 では、 ntp および chrony 正確な時間を維持するには、以下を実行します。相違点 ntp および chronyntpdchronyd に関する詳細は、ntpd と chronyd の相違点 を参照してください。

Red Hat Enterprise Linux 8 では、以下のようになります。 ntp 今後サポートされなくなったため。chrony デフォルトでは有効です。このため、 ntp 次のように変更してください。 chrony.

Migrating from ntp 次のように変更してください。 chrony ほとんどの場合は、シンプルです。プログラムの、設定ファイル、およびサービスに対応する名前は、次のとおりです。

表30.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

module_version は、 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

module_version は、 ntpstat 以前は ntp パッケージに含まれ、ntpd のみをサポートしていましたが、ntpd chronyd の両方に対応するようになりました。これは、ntpstat パッケージで入手できます。

30.3.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 ディレクティブが多数含まれています。chronydNTP サーバーとして実行しない場合は、allow ディレクティブをすべて chrony.conf から削除します。

第31章 chrony でセキュリティーの設定

chronyd のデフォルト設定ファイルは /etc/chrony.conf です。-f オプションは、代替の設定ファイルパスを指定するのに使用できます。詳細は chrony.conf(5) の man ページを参照してください。使用できるディレクティブの一覧は「The chronyd configuration file 」を参照してください。

chronyc chronyd には、以下の 2 つの方法で chronyd にアクセスできます。

  • インターネットプロトコル (IPv4 または IPv6)
  • Unix ドメインソケット (ユーザー root または chrony がローカルにアクセス可能)

デフォルトでは、 chronyc Unix ドメインソケットに接続します。デフォルトのパスは /var/run/chrony/chronyd.sock です。失敗すると、たとえば、 chronyc root 以外のユーザー下で実行されています。 chronyc 127.0.0.1 への接続を試み、次に ::1 への接続を試みます。

chronyd の動作に影響しない次の監視コマンドのみが、ネットワークに許可されています。

  • activity
  • manual list
  • rtcdata
  • smoothing
  • sources
  • sourcestats
  • tracking
  • waitsync

chronyd がこのコマンドを受け付けるホストセットは、chronyd の設定ファイルにある cmdallow ディレクティブ、 chronyc.デフォルトでは、このコマンドが許可されるのは、ローカルホスト (127.0.0.1 または ::1) のものだけになります。

その他のコマンドはすべて、Unix ドメインソケットのみを介して許可されます。ネットワーク上で送信されると、たとえローカルホストであっても、chronydNot authorised エラーを返します。

以下の手順では、chronyd にリモートでアクセスする方法を説明します。 chronyc.

Procedure

  1. 以下を /etc/chrony.conf ファイルに追加すると、IPv4 と IPv6 の両方のアドレスからアクセスが可能になります。

    bindcmdaddress 0.0.0.0

    または

    bindcmdaddress ::
  2. cmdallow ディレクティブを使用すると、リモート IP アドレス、ネットワーク、またはサブネットからのコマンドが許可されます。

    /etc/chrony.conf ファイルに以下の内容を追加します。

    cmdallow 192.168.1.0/24
  3. ファイアウォールでポート 323 を開き、リモートシステムから接続します。

    #  firewall-cmd --zone=public --add-port=323/udp

    ポート 323 を永続的に開く場合は、--permanent を使用します。

    #  firewall-cmd --permanent --zone=public --add-port=323/udp

関連情報

  • chrony.conf(5) の man ページ

第32章 chrony の使用

次のセクションでは、chronyd のインストール、起動、停止の方法や、chrony が同期しているかどうかを確認する方法を説明します。また、システムクロックを手動で調整する方法も説明されています。

32.1. chrony の管理

以下の手順では、chronyd のインストール、起動、停止、およびステータスの確認方法を説明します。

Procedure

  1. module_version は、 chrony Suite は、Red Hat Enterprise Linux にデフォルトでインストールされます。インストールされていることを確認するには、root で以下のコマンドを実行します。

    # yum install chrony

    デフォルトのロケーション chrony デーモンは /usr/sbin/chronyd です。このコマンドラインユーティリティーは /usr/bin/chronyc にインストールされます。

  2. 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
  3. chronyd を開始するには、root で以下のコマンドを実行します。

    # systemctl start chronyd

    システムの起動時に chronyd を自動的に起動するように設定するには、root で以下のコマンドを実行します。

    # systemctl enable chronyd
  4. chronyd を停止するには、root で以下のコマンドを実行します。

    # systemctl stop chronyd

    システムの起動時に chronyd を自動的に起動しないように設定するには、root で以下のコマンドを実行します。

    # systemctl disable chronyd

32.2. chrony の同期確認

以下の手順では、 chrony tracking、sources、およびsource stats コマンドを使用して同期されます。

Procedure

  1. 確認するには、 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
  2. sources コマンドは、chronyd がアクセスしている現在の時間ソースの情報を表示します。確認するには、 chrony ソース - 以下のコマンドを実行します。

    $ 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

    任意の引数 -v (verbose (詳細) の意) を指定できます。この例では、余分なキャプション行は、コラムの意味を説明するものとして表示されます。

  3. sourcestats コマンドは、chronyd が現在調べている各ソースに関するドリフト量とオフセット推定プロセスの情報を表示します。確認するには、 chrony ソース統計。以下のコマンドを発行します。

    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

    任意の引数 -v (verbose (詳細) の意) を指定できます。この例では、余分なキャプション行は、コラムの意味を説明するものとして表示されます。

関連情報

  • chronyc(1) の man ページ

32.3. システムクロックの手動調整

以下の手順では、システムクロックを手動で調整する方法を説明します。

手順

  1. システムクロックを徐々に調整していく (slew) のを止め、一度に修正 (step) するには、root で以下のコマンドを実行します。

    # chronyc makestep

rtcfile ディレクティブを使用している場合は、リアルタイムクロックを手動で調整しないでください。ランダムな調整を行うと、 chrony's need to measure the rate that the real-time clock drifts.

32.4. 孤立したネットワークでのシステムにおける chrony の設定

インターネットに接続していないネットワークに関しては、1 台のコンピューターをマスタータイムサーバーとします。もう 1 台のコンピューターをマスターの直接クライアント、またはクライアントのクライアントとします。マスターでは、ドリフトファイルは、システムクロックのドリフトの平均率を使用して手動で設定します。マスターを再起動すると、周囲のシステムから時間を取得し、システムクロックを設定するために平均値を計算します。その後、drift ファイルに基づいて調整の適用を再開します。drift ファイルは、settime コマンドが使用されたときに自動的に更新されます。

以下の手順では、 chrony 分離されたネットワークにあるシステムの場合。

Procedure

  1. マスターにしたシステムで、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 は、クライアントが接続できるネットワークアドレスまたはサブネットアドレスです。

  2. マスターのダイレクトクライアントにしたシステムで、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 を持つサーバーでのみローカル参照が有効になり、他のサーバーはそれに同期します。サーバーが失敗すると別のサーバーが引き継ぎます。

32.5. 関連情報

第33章 ハードウェアのタイムスタンプを使用した Chrony

ハードウェアのタイムスタンプは、一部の Network Interface Controller (NIC) でサポートされている機能です。着信パケットおよび送信パケットのタイムスタンプを正確に提供します。NTP タイムスタンプは通常、カーネルにより作成され、 chronyd システムクロックが使用中です。ただし、ハードウェアのタイムスタンプが有効な場合、NIC は独自のクロックを使用して、パケットがリンク層または物理層に出入りするときにタイムスタンプを生成します。ハードウェアスタンプで NTP を使用すると、同期の精度を大幅に向上できます。最高精度を実現するには、NTP サーバーおよび NTP クライアントの両方が、ハードウェアのタイムスタンプを使用している必要があります。理想的な条件下では、サブマイクロ秒単位の精度を実現できるかもしれません。

ハードウェアのタイムスタンプを使用する時間同期の別のプロトコルには、PTP があります。

NTP とは異なり、PTP は、ネットワークスイッチおよびルーターの補助に依存しています。同期の精度を最高の状態にしたい場合は、PTP をサポートしているスイッチやルーターがあるネットワークで PTP を使用し、そのようなスイッチおよびルーターがないネットワークでは、NTP を使用することが推奨されます。

以下のセクションでは、次の方法を説明します。

  • ハードウェアタイムスタンプのサポートの確認
  • ハードウェアのタイムスタンプの有効化
  • クライアントポーリング間隔の設定
  • インターリーブモードの有効化
  • 多数のクライアント向けのサーバー設定
  • ハードウェアのタイムスタンプの確認
  • PTP-NTP ブリッジの設定

33.1. ハードウェアタイムスタンプのサポートの確認

NTP を使用したハードウェアのタイムスタンプがインターフェースでサポートされていることを確認するには、ethtool -T コマンドを実行します。ethtool が、SOF_TIMESTAMPING_TX_HARDWARE 機能、SOF_TIMESTAMPING_TX_SOFTWARE 機能、および HWTSTAMP_FILTER_ALL フィルターモードを一覧表示する場合は、NTP を使用して、ハードウェアのタイムスタンプにインターフェースを使用できます。

例33.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)

33.2. ハードウェアのタイムスタンプの有効化

ハードウェアのタイムスタンプを有効にするには、/etc/chrony.conf ファイルの hwtimestamp ディレクティブを使用します。ディレクティブは、個別のインターフェースを指定できますが、ワイルドカード文字を使用して、ハードウェアのタイムスタンプをサポートするすべてのインターフェースでハードウェアのタイムスタンプを有効にすることもできます。他のアプリケーションではない場合に、ワイルドカード仕様を使用してください。 ptp4l linuxptp パッケージでは、ハードウェアのタイムスタンプを使用している。chrony 設定ファイルで、複数の hwtimestamp ディレクティブが使用されます。

例33.2 hwtimestamp のディレクティブを使用したハードウェアのタイムスタンプの有効化

hwtimestamp eth0
hwtimestamp eth1
hwtimestamp *

33.3. クライアントポーリング間隔の設定

インターネット上のサーバーのポーリング間隔は、デフォルトの範囲である 64 秒から 1024 秒が推奨されています。ローカルサーバーおよびハードウェアのタイムスタンプでは、システムクロックのオフセットを最小限にとどめるため、ポーリング間隔は短く設定する必要があります。

/etc/chrony.conf における以下のディレクティブは、1 秒のポーリング間隔を使用してローカルの NTP サーバーを指定します。

server ntp.local minpoll 0 maxpoll 0

33.4. インターリーブモードの有効化

ハードウェアの NTP アプライアンスではなく、ソフトウェア NTP 実装を実行する汎用コンピューターの NTP サーバー chronyパケットの送信後にのみハードウェア送信タイムスタンプを取得します。この動作により、サーバーは、対応するパケットのタイムスタンプを保存できません。NTP クライアントが、送信後に生成された送信タイムスタンプを受け取るようにするには、/etc/chrony.conf のサーバーディレクティブに xleave オプションを追加し、クライアントが NTP インターリーブモードを使用するように設定します。

server ntp.local minpoll 0 maxpoll 0 xleave

33.5. 多数のクライアント向けのサーバーの設定

デフォルトのサーバー設定では、最多で数千のクライアントが同時にインターリーブモードを使用できます。さらに多くのクライアント向けにサーバーを設定するには、/etc/chrony.confclientloglimit ディレクティブを増やします。このディレクティブは、サーバーでクライアントのアクセスログに割り当てられるメモリーの最大サイズを指定します。

clientloglimit 100000000

33.6. ハードウェアのタイムスタンプの確認

インターフェースがハードウェアのタイムスタンプを有効にできたことを確認するには、システムログを確認してください。ログには、chronyd からの各インターフェース向けメッセージに、有効にしたハードウェアのタイムスタンプが追記されているはずです。

例33.3 ハードウェアのタイムスタンプが有効になったインターフェースのログメッセージ

chronyd[4081]: Enabled HW timestamping on eth0
chronyd[4081]: Enabled HW timestamping on eth1

chronyd が、NTP クライアントまたはピアとして設定されている場合は、chronyc ntpdata コマンドにより、送信先と受信先のタイムスタンプおよびインターリーブモードを、各 NTP ソースに報告できます。

例33.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

例33.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

33.7. PTP-NTP ブリッジの設定

非常に精度が高い PTP (Precision Time Protocol) のグランドマスターが、PTP サポートのあるスイッチまたはルーターを持たないネットワークで利用可能な場合、コンピューターは、PTP スレーブおよび stratum-1 の NTP サーバーとしての操作に専念する可能性があります。このようなコンピューターには、2 つ以上のネットワークインターフェースが必要なほか、グランドマスターに近いか、またはグランドマスターに直接接続されている必要があります。これにより、ネットワークで非常に精度の高い同期が確実に実行されます。

設定: ptp4l および phc2sys linuxptp パッケージのプログラムが 1 つのインターフェースを使用して、PTP でシステムクロックを同期します。

chronyd を設定して、その他のインターフェースを使用してシステム時間を提供するには、以下を行います。

例33.6 その他のインターフェースを使用してシステム時間を提供するように chronyd を設定

bindaddress 203.0.113.74
hwtimestamp eth1
local stratum 1

第34章 以前サポートされていた設定を chrony で実現する手順

Red Hat Enterprise Linux の以前のメジャーバージョンでサポートされていた設定によっては、 ntp, は、 chrony.以下のセクションでは、このような設定の一覧と、 chrony.

34.1. ntpq および ntpdc による監視

chronyd は、 ntpq および ntpdc ユーティリティー ntp ディストリビューション。 chrony NTP モード 6 および 7 には対応していません。これは、別のプロトコルをサポートします。 chronyc クライアントの実装です。詳細は chronyc(1) の man ページを参照してください。

chronyd で同期しているシステムクロックの状態を監視するには、次のことができます。

  • 追跡コマンドの使用
  • 使用するには、 ntpstat 対応するユーティリティー。 chrony ntpdを使用すると使用する場合と同様の出力が得られます。

例34.1 追跡コマンドの使用

$ 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

例34.2 ntpstat ユーティリティーの使用

$ ntpstat
synchronised to NTP server (10.5.27.10) at stratum 2
   time correct to within 80 ms
   polling server every 64 s

34.2. 公開鍵暗号に基づく認証メカニズムの使用

Red Hat Enterprise Linux 7 では、 ntp サポート対象 Autokey: 公開鍵暗号に基づく認証メカニズムです。Autokey chronyd ではサポートされていません。

Red Hat Enterprise Linux 8 システムでは、代わりに対称鍵を使用することが推奨されます。鍵の生成には chronyc keygen コマンドを使用します。クライアントおよびサーバーは、/etc/chrony.keys で指定した鍵を共有する必要があります。クライアントは、serverpool、または peer の各ディレクティブで、key オプションを使用して認証を有効にできます。

34.3. 一時的な対称関係の使用

Red Hat Enterprise Linux 7 では、ntpd が、ntp.conf 設定ファイルで指定しないピアからのパケットにより収集できる一時的な対称関係をサポートしていました。Red Hat Enterprise Linux 8 では、chronyd は、chrony.conf ですべてのピアを指定する必要があります。一時的な対称関係はサポートされません。

peer ディレクティブで有効にした対象モードと比べると、server ディレクティブまたは pool ディレクティブで有効になっているクライアント/サーバーモードを使用したほうが安全です。

34.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 グランドマスターとして動作させることができます。

第35章 RHEL システムロールを使用した時刻同期の管理

timesync ロールを使用して、複数のターゲットマシンで時刻同期を管理できます。システムクロックが、NTP サーバーまたは PTP ドメインのグランドマスターに同期するように、timesync ロールが、NTP 実装または PTP 実装をインストールして NTP クライアントまたは PTP スレーブとして動作するように設定します。

timesync ロールを使用すると、システムが使用しているかどうかにかかわらず、RHEL 6 以降のすべてのバージョンの Red Hat Enterprise Linux で同じ Playbook を使用できるため、chrony への移行が容易になりますntp または chrony NTP プロトコルを実装する。

警告

timesync ロールは、管理対象ホストで指定または検出されたプロバイダーサービスの設定を置き換えます。以前の設定は、ロール変数で指定されていなくても失われます。timesync_ntp_provider 変数が定義されていない場合は、プロバイダーの唯一の設定が適用されます。

以下の例は、サーバーにプールが 1 つしかない場合に、timesync ロールを適用する方法を示しています。

例35.1 サーバーの 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 ファイルを参照してください。

第36章 2 台のシステム間で OpenSSH を使用した安全な通信の使用

SSH (Secure Shell) は、クライアント/サーバーアーキテクチャーを使用する 2 つのシステム間で安全な通信を提供し、ユーザーがリモートでサーバーホストシステムにログインできるようにするプロトコルです。FTP、Telnet などの他のリモート通信プロトコルとは異なり、SSH はログインセッションを暗号化するため、侵入者が接続して暗号化されていないパスワードを入手するのが困難になります。

Red Hat Enterprise Linux 8 には、基本的な OpenSSH パッケージ (一般的な openssh パッケージ、openssh-server パッケージ、および openssh-clients パッケージ) が含まれます。OpenSSH パッケージには、OpenSSL パッケージ (openssl-libs) が必要です。このパッケージは、重要な暗号化ライブラリーをいくつかインストールして、暗号化通信を提供する OpenSSH を有効にします。

36.1. SSH と OpenSSH

SSH (Secure Shell) は、リモートマシンにログインしてそのマシンでコマンドを実行するプログラムです。SSH プロトコルは、安全でないネットワーク上で、信頼されていないホスト間で安全な通信を提供します。また、X11 接続と任意の TCP/IP ポートを安全なチャンネルで転送することもできます。

SSH プロトコルは、リモートシェルのログインやファイルコピー用に使用する場合に、システム間の通信の傍受や特定ホストの偽装など、セキュリティーの脅威を軽減します。これは、SSH クライアントとサーバーがデジタル署名を使用してそれぞれの ID を確認するためです。さらに、クライアントシステムとサーバーシステムとの間の通信はすべて暗号化されます。

ホストキーは、SSH プロトコルのホストを認証します。ホスト鍵は、OpenSSH の初回インストール時、またはホストの初回起動時に自動的に生成される暗号鍵です。

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 つ使用します。クライアントプログラム (つまり sshscp、および sftp) の設定ファイルと、サーバー (sshd デーモン) の設定ファイルです。システム全体の SSH 設定情報が /etc/ssh/ ディレクトリーに保存されます。ユーザー固有の SSH 設定情報は、ユーザーのホームディレクトリーの ~/.ssh/ に保存されます。OpenSSH 設定ファイルの詳細な一覧は、sshd (8) の man ページの FILES セクションを参照してください。

関連情報

36.2. OpenSSH サーバーの設定および起動

お使いの環境と OpenSSH サーバーを起動するのに必要な基本設定には、以下の手順を使用します。デフォルトの RHEL インストールを行うと、sshd デーモンがすでに起動し、サーバーのホスト鍵が自動的に作成されることに注意してください。

前提条件

  • openssh-server パッケージがインストールされている。

手順

  1. 現行セッションで sshd デーモンを開始し、ブート時に自動的に起動するように設定します。

    # systemctl start sshd
    # systemctl enable sshd
  2. /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
  3. /etc/ssh/sshd_config 設定ファイルの OpenSSH サーバーの設定がシナリオの要件を満たしているかどうかを確認します。
  4. 必要に応じて、/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 を参照してください。

  5. systemd 設定を再読み込みし、sshd を再起動して変更を適用します。

    # systemctl daemon-reload
    # systemctl restart sshd

検証

  1. 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.
  2. 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:

関連情報

  • sshd(8) および sshd_config(5) の man ページ。

36.3. 鍵ベースの認証用の OpenSSH サーバーの設定

システムのセキュリティーを強化するには、OpenSSH サーバーでパスワード認証を無効にして鍵ベースの認証を有効にします。

前提条件

  • openssh-server パッケージがインストールされている。
  • サーバーで sshd デーモンが実行している。

手順

  1. テキストエディターで /etc/ssh/sshd_config 設定を開きます。以下に例を示します。

    # vi /etc/ssh/sshd_config
  2. PasswordAuthentication オプションを no に変更します。

    PasswordAuthentication no

    新しいデフォルトインストール以外のシステムで PubkeyAuthentication no が設定されていないことと、ChallengeResponseAuthentication ディレクティブが no に設定されていることを確認します。リモートで接続している場合は、コンソールもしくは帯域外アクセスを使用せず、パスワード認証を無効にする前に、鍵ベースのログインプロセスをテストします。

  3. NFS がマウントされたホームディレクトリーで鍵ベースの認証を使用するには、SELinux ブール値 use_nfs_home_dirs を有効にします。

    # setsebool -P use_nfs_home_dirs 1
  4. sshd デーモンを再読み込みし、変更を適用します。

    # systemctl reload sshd

関連情報

  • sshd(8)sshd_config(5)、および setsebool(8) の man ページ。

36.4. SSH 鍵ペアの生成

以下の手順を使用して、ローカルシステムに SSH 鍵ペアを生成し、生成された公開鍵を OpenSSH サーバーにコピーします。サーバーが正しく設定されている場合は、パスワードなしで OpenSSH サーバーにログインできます。

重要

root で次の手順を完了すると、鍵を使用できるのは root だけとなります。

手順

  1. 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 コマンドを実行します。

  2. 公開鍵をリモートマシンにコピーするには、次のコマンドを実行します。

    $ 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 を含む) システムの全ユーザーで実行できます。

検証

  1. パスワードなしで 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)

36.5. スマートカードに保存された SSH 鍵の使用

Red Hat Enterprise Linux では、OpenSSH クライアントでスマートカードに保存されている RSA 鍵および ECDSA 鍵を使用できるようになりました。この手順に従って、パスワードの代わりにスマートカードを使用した認証を有効にします。

前提条件

  • クライアントで、opensc パッケージをインストールして、pcscd サービスを実行している。

手順

  1. 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
  2. リモートサーバー (example.com) でスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。前の手順で作成された keys.pubssh-copy-id コマンドを使用します。

    $ ssh-copy-id -f -i keys.pub username@example.com
  3. 手順 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] $
  4. ~/.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] $

関連情報

36.6. 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_configPasswordAuthentication オプションを 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 権限を取得した後に、どのユーザーがどの特権コマンドを実行するかを監査できます。

    または、PermitRootLoginprohibit-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)

36.7. SSH ジャンプホストを使用してリモートサーバーに接続

この手順に従って、ジャンプホストとも呼ばれる中間サーバーを介してローカルシステムをリモートサーバーに接続します。

前提条件

  • ジャンプホストでローカルシステムからの SSH 接続に対応している。
  • リモートサーバーが、ジャンプホストからのみ SSH 接続を受け入れる。

手順

  1. ローカルシステムの ~/.ssh/config ファイルを編集してジャンプホストを定義します。以下に例を示します。

    Host jump-server1
      HostName jump1.example.com
    • Host パラメーターは、ssh コマンドで使用できるホストの名前またはエイリアスを定義します。値は実際のホスト名と一致可能ですが、任意の文字列にすることもできます。
    • HostName パラメーターは、ジャンプホストの実際のホスト名または IP アドレスを設定します。
  2. ProxyJump ディレクティブを使用してリモートサーバーのジャンプ設定を、ローカルシステムの ~/.ssh/config ファイルに追加します。以下に例を示します。

    Host remote-server
      HostName remote1.example.com
      ProxyJump jump-server1
  3. ローカルシステムを使用して、ジャンプサーバー経由でリモートサーバーに接続します。

    $ 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 ページ

36.8. ssh-agent を使用して SSH キーでリモートマシンに接続する手順

パスフレーズを SSH 接続を開始するたびに入力しなくて済むようにするには、ssh-agent ユーティリティーを使用して SSH 秘密鍵をキャッシュします。秘密鍵とパスフレーズのセキュリティーが確保されます。

前提条件

  • SSH デーモンが実行中で、ネットワーク経由で到達可能なリモートホストがある。
  • リモートホストにログインするための IP アドレスまたはホスト名および認証情報を把握している。
  • パスフレーズで SSH キーペアを生成し、公開鍵をリモートマシンに転送している。詳細は「SSH 鍵ペアの生成」を参照してください。

手順

  1. 必要に応じて、キーを使用してリモートホストに対して認証できることを確認します。

    1. SSH を使用してリモートホストに接続します。

      $ ssh example.user1@198.51.100.1 hostname
    2. 秘密鍵へのアクセス権を付与する鍵の作成時に指定したパスフレーズを入力します。

      $ ssh example.user1@198.51.100.1 hostname
       host.example.com
  2. ssh-agent を起動します。

    $ eval $(ssh-agent)
    Agent pid 20062
  3. 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

    パスフレーズを入力する必要がないことに注意してください。

36.9. 関連情報

第37章 リモートロギングソリューションの設定

環境内の各種マシンからのログをロギングサーバーに集中的に記録するために、クライアントシステムからサーバーに特定の基準に合致するログを記録するように Rsyslog アプリケーションを設定できます。

37.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/ ディレクトリーにあります。httpdsamba などの一部のアプリケーションは、ログファイルを /var/log/ 内のサブディレクトリーに保存します。

関連情報

37.2. Rsyslog ドキュメントのインストール

Rsyslog アプリケーションには https://www.rsyslog.com/doc/ で利用可能な幅広いドキュメントがありますが、以下の手順に従って rsyslog-doc ドキュメントパッケージをローカルにインストールすることもできます。

前提条件

  • システムで AppStream リポジトリーをアクティベートしている。
  • sudo を使用して新規パッケージをインストールする権限がある。

手順

  • rsyslog-doc パッケージをインストールします。

    $ sudo yum install rsyslog-doc

検証

37.3. TCP でのリモートロギング用のサーバーの設定

Rsyslog アプリケーションを使用すると、ロギングサーバーを実行し、個別のシステムがログファイルをロギングサーバーに送信するように設定できます。TCP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。サーバーは、クライアントシステムにより送信されたログを収集し、分析します。

Rsyslog アプリケーションを使用すると、ログメッセージがネットワークを介してサーバーに転送される中央ロギングシステムを維持できます。サーバーが利用できない場合にメッセージが失われないようにするには、転送アクションのアクションキューを設定します。これにより、送信に失敗したメッセージは、サーバーが再度到達可能になるまでローカルに保存されます。このようなキューは、UDP プロトコルを使用する接続用に設定できないことに注意してください。

omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。このプラグインは組み込まれているため、読み込む必要はありません。

デフォルトでは、rsyslog はポート 514 で TCP を使用します。

前提条件

  • rsyslog がサーバーシステムにインストールされている。
  • サーバーに root としてログインしている。

手順

  1. 必要に応じて、rsyslog トラフィックに別のポートを使用するには、SELinux タイプ syslogd_port_t をポートに追加します。たとえば、ポート 30514 を有効にします。

    # semanage port -a -t syslogd_port_t -p tcp 30514
  2. 必要に応じて、rsyslog トラフィックに別のポートを使用するには、firewalld がそのポートでの着信 rsyslog トラフィックを許可するように設定します。たとえば、ゾーン zone でポート 30514 に TCP トラフィックを許可します。

    # firewall-cmd --zone=zone --permanent --add-port=30514/tcp
    success
  3. /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")
  4. /etc/rsyslog.d/remotelog.conf ファイルへの変更を保存します。
  5. Rsyslog サービスがロギングサーバーで実行中で、有効になっていることを確認します。

    # systemctl status rsyslog
  6. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
  7. 必要に応じて、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.

関連情報

37.4. TCP 経由のサーバーへのリモートロギングの設定

以下の手順に従って、TCP プロトコルを介してサーバーにログメッセージを転送するようにシステムを設定します。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。

前提条件

  • rsyslog パッケージが、サーバーに報告する必要のあるクライアントシステムにインストールされている。
  • リモートロギング用にサーバーを設定している。
  • 指定したポートが SELinux で許可され、ファイアウォールで開いている。

手順

  1. /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 で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。

  2. rsyslog サービスを再起動します。

    # systemctl restart rsyslog

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
  2. サーバーシステムで、/var/log/messages ログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

37.5. UDP でリモートロギング情報を受信するためのサーバー設定

Rsyslog アプリケーションを使用すると、リモートシステムからロギング情報を受信するようにシステムを設定できます。UDP 経由でリモートロギングを使用するには、サーバーとクライアントの両方を設定します。受信サーバーは、クライアントシステムが送信したログの収集および分析を行います。デフォルトでは、rsyslog はポート 514 で UDP を使用して、リモートシステムからログ情報を受信します。

以下の手順に従って、UDP プロトコルでクライアントシステムが送信したログの収集および分析を行うサーバーを設定します。

前提条件

  • rsyslog ユーティリティーがインストールされている。

手順

  1. 必要に応じて、デフォルトのポート 514 以外の rsyslog トラフィックに別のポートを使用するには、次のコマンドを実行します。

    1. SELinux ポリシー設定に syslogd_port_t SELinux タイプを追加し、portnorsyslog で使用するポート番号に置き換えます。

      # semanage port -a -t syslogd_port_t -p udp portno
    2. rsyslog の受信トラフィックを許可するように firewalld を設定します。portno はポート番号に、zonersyslog が使用するゾーンに置き換えます。

      # firewall-cmd --zone=zone --permanent --add-port=portno/udp
      success
    3. ファイアウォールルールを再読み込みします。

      # firewall-cmd --reload
  2. /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 がデフォルトで使用するポート番号です。代わりに別のポートを指定できます。

  3. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
  4. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog

検証

  1. /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.

関連情報

37.6. UDP 経由のサーバーへのリモートロギングの設定

以下の手順に従って、UDP プロトコルを介してサーバーにログメッセージを転送するようにシステムを設定します。omfwd プラグインは、UDP または TCP による転送を提供します。デフォルトのプロトコルは UDP です。プラグインは組み込まれているのでロードする必要はありません。

前提条件

手順

  1. /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 で不足するか、シャットダウンする必要がある場合にのみ作成されます。これにより、システムパフォーマンスが向上します。

  2. rsyslog サービスを再起動します。

    # systemctl restart rsyslog
  3. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

    # systemctl enable rsyslog

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
  2. サーバーシステムで、/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) が含まれていることに注意してください。

関連情報

37.7. 信頼できるリモートロギングの設定

Reliable Event Logging Protocol (RELP) を使用すると、メッセージ損失のリスクを大幅に軽減して TCP で syslog メッセージを送受信できます。RELP は、信頼できるイベントメッセージを配信するので、メッセージ損失が許されない環境で有用です。RELP を使用するには、imrelp の入力モジュール (サーバー上での実行とログの受信) と omrelp 出力モジュール (クライアント上での実行とロギングサーバーへのログの送信) を設定します。

前提条件

  • rsyslog パッケージ、librelp パッケージ、および rsyslog-relp パッケージをサーバーおよびクライアントシステムにインストールしている。
  • 指定したポートが SELinux で許可され、ファイアウォール設定で開放されている。

手順

  1. 信頼できるリモートロギング用にクライアントシステムを設定します。

    1. クライアントシステムの /etc/rsyslog.d/ ディレクトリーに、relpcli.conf などと名前を指定して新しい .conf ファイルを作成し、以下のコンテンツを挿入します。

      module(load="omrelp")
      *.* action(type="omrelp" target="target_IP" port="target_port")

      詳細は以下のようになります。

      • target_IP は、ロギングサーバーの IP アドレスに置き換えます。
      • target_port はロギングサーバーのポートに置き換えます。
    2. /etc/rsyslog.d/relpserv.conf ファイルへの変更を保存します。
    3. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
    4. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog
  2. 信頼できるリモートロギング用にサーバーシステムを設定します。

    1. サーバーシステムの /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 はロギングサーバーのポートに置き換えます。クライアント設定ファイルと同じ値を使用します。
    2. /etc/rsyslog.d/relpserv.conf ファイルへの変更を保存します。
    3. rsyslog サービスを再起動します。

      # systemctl restart rsyslog
    4. 必要に応じて、rsyslog が有効になっていない場合は、再起動後に rsyslog サービスが自動的に起動するようにします。

      # systemctl enable rsyslog

検証

クライアントシステムがサーバーにメッセージを送信することを確認するには、以下の手順に従います。

  1. クライアントシステムで、テストメッセージを送信します。

    # logger test
  2. サーバーシステムで、指定された log_path でログを表示します。以下に例を示します。

    # cat /var/log/remote/msg/hostname/root.log
    Feb 25 03:53:17 hostname root[6064]: test

    hostname はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

37.8. サポート対象の Rsyslog モジュール

特定の追加モジュールを使用して Rsyslog ユーティリティーの機能を拡張できます。モジュールには、追加の入力 (入力モジュール)、出力 (出力モジュール)、およびその他の特定の機能が含まれます。モジュールは、モジュールの読み込み後に利用可能な設定ディレクティブを追加で提供することも可能です。

以下のコマンドを使用して、システムにインストールされている入出力モジュールを一覧表示できます。

# ls /usr/lib64/rsyslog/{i,o}m*

rsyslog-doc パッケージからインストールしたドキュメントから、利用可能な rsyslog モジュールの全一覧は、file:///usr/share/doc /rsyslog/html/configuration/modules/idx_output.html から確認できます。

37.9. 関連情報

第38章 Logging システムロールの使用

システム管理者は、Logging システムロールを使用して、RHEL ホストをロギングサーバーとして設定し、多くのクライアントシステムからログを収集できます。

38.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 からの入力をローカルのファイルに保存しつつも、複数のファイルから読み込んだ入力を別のロギングシステムに転送してそのローカルのログファイルに保存するようにロギングソリューションを設定できます。

38.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_inputslogging_outputs の関係を定義するフローの一覧。logging_flows 変数には以下が含まれます。

    • name: フローの一意の名前。
    • inputs: logging_inputs 名の値の一覧。
    • outputs: logging_outputs 名の値の一覧。

関連情報

  • rhel-system-roles パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html)

38.3. ローカルの Logging システムロールの適用

以下の手順に従って、Red Hat Ansible Engine Playbook を準備および適用し、別個のマシンにロギングソリューションを設定します。各マシンはログをローカルに記録します。

前提条件

  • Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。

    注記

    ロギングソリューションをデプロイするシステムに Red Hat Ansible Engine をインストールする必要はありません。

  • Playbook を実行するシステムに rhel-system-roles パッケージがある。

    注記

    デプロイ時に rsyslog がシステムロールによりインストールされるので、rsyslog はインストールする必要はありません。

  • ロギングソリューションを設定するシステムを一覧表示するインベントリーファイルがある。

手順

  1. 必要なロールを定義する Playbook を作成します。

    1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      # vi logging-playbook.yml
    2. 以下の内容を挿入します。

      ---
      - 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]
  2. 特定のインベントリーで Playbook を実行します。

    # ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml

    詳細は以下のようになります。

    • inventory-file はインベントリーファイルに置き換えます。
    • logging-playbook.yml は、使用する Playbook に置き換えます。

検証

  1. /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.
  2. システムがログにメッセージを送信していることを確認します。

    1. テストメッセージを送信します。

      # logger test
    2. /var/log/messages ログ を表示します。以下に例を示します。

      # cat /var/log/messages
      Aug  5 13:48:31 hostname root[6778]: test

      `hostname` はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

38.4. ローカルの Logging システムロールでのログのフィルタリング

rsyslog プロパティーベースのフィルターをもとにログをフィルターするロギングソリューションをデプロイできます。

前提条件

  • Logging システムロールを設定する 管理対象ノード 1 つ以上へのアクセスおよびパーミッション。
  • Red Hat Ansible Engine が他のシステムを設定する コントロールノード へのアクセスおよびパーミッション。

    コントロールノードでは、

    • Red Hat Ansible Engine がインストールされている。
    • rhel-system-roles パッケージがインストールされている。
    • 管理対象ノードが記載されているインベントリーファイルがある。

手順

  1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

    ---
    - name: Deploying files input and configured files output
      hosts: all
      roles:
        - linux-system-roles.logging
      vars:
        logging_inputs:
          - name: files_input0
            type: files
            input_log_path: /var/log/containerA/*.log
          - name: files_input1
            type: files
            input_log_path: /var/log/containerB/*.log
        logging_outputs:
          - name: files_output0
            type: files
            property: msg
            property_op: contains
            property_value: error
            path: /var/log/errors.log
          - name: files_output1
            type: files
            property: msg
            property_op: "!contains"
            property_value: error
            path: /var/log/others.log
        logging_flows:
          - name: flow0
            inputs: [files_input0, files_input1]
            outputs: [files_output0, files_output1]

    この設定を使用すると、error 文字列を含むメッセージはすべて /var/log/errors.log に記録され、その他のメッセージはすべて /var/log/others.log に記録されます。

    error プロパティーの値はフィルタリングする文字列に置き換えることができます。

    設定に合わせて変数を変更できます。

  2. オプション: Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file /path/to/file/playbook.yml

検証

  1. /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.
  2. システムが error 文字列を含むメッセージをログに送信していることを確認します。

    1. テストメッセージを送信します。

      # logger error
    2. 以下のように /var/log/errors.log ログを表示します。

      # cat /var/log/errors.log
      Aug  5 13:48:31 hostname root[6778]: error

      hostname はクライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

関連情報

  • rhel-system-roles パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html)

38.5. 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 つはロギングクライアント

手順

  1. 必要なロールを定義する Playbook を作成します。

    1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      # vi logging-playbook.yml
    2. 以下の内容をファイルに挿入します。

      ---
      - 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 ポリシーを変更します。システムロールを使用したファイアウォールの設定は、まだサポートされていません。

  2. サーバーおよびクライアントを一覧表示するインベントリーファイルを作成します。

    1. 新しいファイルを作成してテキストエディターで開きます。以下に例を示します。

      # vi inventory.ini
    2. 以下のコンテンツをインベントリーファイルに挿入します。

      [servers]
      server ansible_host=host1.example.com
      [clients]
      client ansible_host=host2.example.com

      * host1.example.com はロギングサーバーに置き換えます。* host2.example.com はロギングクライアントに置き換えます。

  3. インベントリーで Playbook を実行します。

    # ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml

    詳細は以下のようになります。

    • inventory.ini はインベントリーファイルに置き換えます。
    • logging-playbook.yml は作成した Playbook に置き換えます。

検証

  1. クライアントとサーバーシステムの両方で、/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.
  2. クライアントシステムがサーバーにメッセージを送信することを確認します。

    1. クライアントシステムで、テストメッセージを送信します。

      # logger test
    2. サーバーシステムで、/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

38.6. RELP でのロギングシステムロールの使用

Reliable Event Logging Protocol (RELP) とは、TCP ネットワークを使用する、データとメッセージロギング用のネットワーキングプロトコルのことです。イベントメッセージを確実に配信するので、メッセージの損失が許されない環境で使用できます。

RELP の送信側はコマンド形式でログエントリーを転送し、受信側は処理後に確認応答します。RELP は、一貫性を保つために、転送されたコマンドごとにトランザクション番号を保存し、各種メッセージの復旧します。

RELP Client と RELP Server の間にリモートロギングシステムを検討してください。RELP クライアントはログをリモートロギングシステムに転送し、RELP Server はリモートロギングシステムから送信されたすべてのログを受け取ります。

管理者は Logging システムロールを使用して、ログエントリーが確実に送受信されるようにロギングシステムを設定することができます。

38.6.1. RELP を使用したクライアントロギングの設定

Logging システムロールを使用して、ローカルマシンにログインしている RHEL システムでロギングを設定し、Ansible Playbook を実行して、ログを RELP でリモートロギングシステムに転送できます。

この手順では、Ansible インベントリーの client グループ内の全ホストに RELP を設定します。RELP 設定は Transport Layer Security (TLS) を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

  • RELP を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying basic input and relp output
      hosts: clients
      roles:
        - rhel-system-roles.logging
      vars:
        logging_inputs:
          - name: basic_input
            type: basics
        logging_outputs:
          - name: relp_client
            type: relp
            target: logging.server.com
            port: 20514
            tls: true
            ca_cert: /etc/pki/tls/certs/ca.pem
            cert: /etc/pki/tls/certs/client-cert.pem
            private_key: /etc/pki/tls/private/client-key.pem
            pki_authmode: name
            permitted_servers:
              - '*.server.example.com'
        logging_flows:
          - name: example_flow
            inputs: [basic_input]
            outputs: [relp_client]

    Playbook は、以下の設定を使用します。

    • target: リモートロギングシステムが稼働しているホスト名を指定する必須パラメーターです。
    • port: リモートロギングシステムがリッスンしているポート番号です。
    • TLS: ネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、tls 変数を false に設定します。デフォルトでは tls パラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_certcertprivate_key} や {ca_cert_srccert_srcprivate_key_src} が必要です。

      • {ca_cert_srccert_srcprivate_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certs/etc/pki/tls/private) を、コントロールノードから転送する管理対象ノードの宛先として使用します。この場合、ファイル名はトリプレットの元の名前と同じです。
      • {ca_certcertprivate_key} トリプレットが設定されている場合には、ファイルはロギング設定の前にデフォルトのパスを配置する必要があります。
      • トリプレットの両方が設定されている場合には、ファイルはコントロールノードのローカルのパスから管理対象ノードの特定のパスへ転送されます。
    • ca_cert: CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    • cert: 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    • private_key: 秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    • CA_cert_src: ローカル CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert が指定している場合は、その場所にコピーされます。
    • cert_src: ローカル証明書ファイルのパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    • private_key_src: ローカルキーファイルパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合には、その場所にコピーされます。
    • pki_authmode: name または fingerprint の認証モードを使用できます。
    • permitted_servers: ロギングクライアントが、TLS 経由での接続およびログ送信を許可するサーバーの一覧。
    • inputs: ロギング入力ディクショナリーの一覧。
    • outputs: ロギング出力ディクショナリーの一覧。
  2. オプション: Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

38.6.2. RELP を使用したサーバーログの設定

Logging システムロールを使用して、RHEL システムのログインをサーバーとして設定し、Ansible Playbook を実行して RELP でリモートロギングシステムからログを受信できます。

以下の手順では、Ansible インベントリーの server グループ内の全ホストに RELP を設定します。RELP 設定は TLS を使用して、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

  • RELP を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying remote input and remote_files output
      hosts: server
      roles:
        - rhel-system-roles.logging
      vars:
        logging_inputs:
          - name: relp_server
            type: relp
            port: 20514
            tls: true
            ca_cert: /etc/pki/tls/certs/ca.pem
            cert: /etc/pki/tls/certs/server-cert.pem
            private_key: /etc/pki/tls/private/server-key.pem
            pki_authmode: name
            permitted_clients:
              - '*example.client.com'
        logging_outputs:
          - name: remote_files_output
            type: remote_files
        logging_flows:
          - name: example_flow
            inputs: relp_server
            outputs: remote_files_output

    Playbook は、以下の設定を使用します。

    • port: リモートロギングシステムがリッスンしているポート番号です。
    • TLS: ネットワーク上でログをセキュアに転送します。セキュアなラッパーが必要ない場合は、tls 変数を false に設定します。デフォルトでは tls パラメーターは true に設定されますが、RELP を使用する場合には鍵/証明書およびトリプレット {ca_certcertprivate_key} や {ca_cert_srccert_srcprivate_key_src} が必要です。

      • {ca_cert_srccert_srcprivate_key_src} のトリプレットを設定すると、デフォルトの場所 (/etc/pki/tls/certs/etc/pki/tls/private) を、コントロールノードから転送する管理対象ノードの宛先として使用します。この場合、ファイル名はトリプレットの元の名前と同じです。
      • {ca_certcertprivate_key} トリプレットが設定されている場合には、ファイルはロギング設定の前にデフォルトのパスを配置する必要があります。
      • トリプレットの両方が設定されている場合には、ファイルはコントロールノードのローカルのパスから管理対象ノードの特定のパスへ転送されます。
    • ca_cert: CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    • cert: 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    • private_key: 秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    • CA_cert_src: ローカル CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert が指定している場合は、その場所にコピーされます。
    • cert_src: ローカル証明書ファイルのパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    • private_key_src: ローカルキーファイルパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合には、その場所にコピーされます。
    • pki_authmode: name または fingerprint の認証モードを使用できます。
    • permitted_clients: ロギングサーバーが TLS 経由での接続およびログ送信を許可するクライアントの一覧。
    • inputs: ロギング入力ディクショナリーの一覧。
    • outputs: ロギング出力ディクショナリーの一覧。
  2. オプション: Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

38.7. TLS でのロギングシステムロールの使用

Transport Layer Security (TLS) は、コンピューターネットワーク上で安全に通信するために設計された暗号プロトコルです。

管理者は、RHEL で Logging システムロールを使用し、Red Hat Ansible Automation Platform を使用したセキュアなログ転送を設定できます。

38.7.1. TLS を使用したクライアントロギングの設定

Logging システムロールを使用して、ローカルマシンにログインしている RHEL システムでロギングを設定し、Ansible Playbook を実行して、ログを TLS でリモートロギングシステムに転送できます。

この手順では、Ansible インベントリーの client グループ内の全ホストに TLS を設定します。TLS プロトコルは、メッセージ送信を暗号化し、ネットワーク経由でログを安全に転送します。

前提条件

  • TLS を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying files input and forwards output with certs
      hosts: clients
      roles:
        - rhel-system-roles.logging
      vars:
        logging_pki_files:
          - ca_cert_src: /local/path/to/ca_cert.pem
            cert_src: /local/path/to/cert.pem
            private_key_src: /local/path/to/key.pem
        logging_inputs:
          - name: input_name
            type: files
            input_log_path: /var/log/containers/*.log
        logging_outputs:
          - name: output_name
            type: forwards
            target: your_target_host
            tcp_port: 514
            tls: true
            pki_authmode: x509/name
            permitted_server: 'server.example.com'
        logging_flows:
          - name: flow_name
            inputs: [input_name]
            outputs: [output_name]

    Playbook は以下のパラメーターを使用します。

    logging_pki_files
    このパラメーターを使用して、TLS を設定し、ca_cert_srccert_src および private_key_src パラメーターを指定する必要があります。
    ca_cert
    CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ローカルの CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert を指定している場合は、その場所にコピーされます。
    cert_src
    ローカルの証明書ファイルパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    private_key_src
    ローカルキーファイルのパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合は、その場所にコピーされます。
    tls
    このパラメーターを使用すると、ネットワーク経由でログを安全に転送できるようになります。セキュアなラッパーが必要ない場合は、tls: true と設定できます。
  2. Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

38.7.2. TLS を使用したサーバーロギングの設定

Logging システムロールを使用して、RHEL システムのログインをサーバーとして設定し、Ansible Playbook を実行して TLS でリモートロギングシステムからログを受信できます。

以下の手順では、Ansible インベントリーの server グループ内の全ホストに TLS を設定します。

前提条件

  • TLS を設定する管理ノードで Playbook の実行権限がある。
  • 管理対象ノードがコントロールノードのインベントリーファイルに記載されている。
  • ansible パッケージおよび rhel-system-roles パッケージがコントロールノードにインストールされている。

手順

  1. 以下の内容を含む playbook.yml ファイルを作成します。

    ---
    - name: Deploying remote input and remote_files output with certs
      hosts: server
      roles:
        - rhel-system-roles.logging
      vars:
        logging_pki_files:
          - ca_cert_src: /local/path/to/ca_cert.pem
            cert_src: /local/path/to/cert.pem
            private_key_src: /local/path/to/key.pem
        logging_inputs:
          - name: input_name
            type: remote
            tcp_ports: 514
            tls: true
            permitted_clients: ['clients.example.com']
        logging_outputs:
          - name: output_name
            type: remote_files
            remote_log_path: /var/log/remote/%FROMHOST%/%PROGRAMNAME:::secpath-replace%.log
            async_writing: true
            client_count: 20
            io_buffer_size: 8192
        logging_flows:
          - name: flow_name
            inputs: [input_name]
            outputs: [output_name]

    Playbook は以下のパラメーターを使用します。

    logging_pki_files
    このパラメーターを使用して、TLS を設定し、ca_cert_srccert_src および private_key_src パラメーターを指定する必要があります。
    ca_cert
    CA 証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/ca.pem で、ファイル名はユーザーが設定します。
    cert
    証明書へのパスを表します。デフォルトのパスは /etc/pki/tls/certs/server-cert.pem で、ファイル名はユーザーが設定します。
    private_key
    秘密鍵へのパスを表します。デフォルトのパスは /etc/pki/tls/private/server-key.pem で、ファイル名はユーザーが設定します。
    ca_cert_src
    ローカルの CA 証明書ファイルパスを表します。これはターゲットホストにコピーされます。ca_cert を指定している場合は、その場所にコピーされます。
    cert_src
    ローカルの証明書ファイルパスを表します。これはターゲットホストにコピーされます。cert を指定している場合には、その証明書が場所にコピーされます。
    private_key_src
    ローカルキーファイルのパスを表します。これはターゲットホストにコピーされます。private_key を指定している場合は、その場所にコピーされます。
    tls
    このパラメーターを使用すると、ネットワーク経由でログを安全に転送できるようになります。セキュアなラッパーが必要ない場合は、tls: true と設定できます。
  2. Playbook の構文を確認します。

    # ansible-playbook --syntax-check playbook.yml
  3. インベントリーファイルで Playbook を実行します。

    # ansible-playbook -i inventory_file playbook.yml

38.8. 関連情報

  • RHEL システムロールの使用
  • rhel-system-roles パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html)
  • ナレッジベースの記事「Red Hat Enterprise Linux (RHEL)System Roles
  • ansible-playbook コマンドの詳細は、ansible-playbook(1) の man ページを参照してください。

第39章 Python の概要

Python は、オブジェクト指向、命令、機能、手順などの複数のプログラミングパラダイムをサポートする、高レベルのプログラミング言語です。Python は動的なセマンティクスを持ち、汎用プログラミングに使用できます。

Red Hat Enterprise Linux では、システムツール、データ分析用のツール、Web アプリケーションを提供するパッケージなど、システムにインストールされている多くのパッケージが Python で記述されています。このパッケージを使用するには、python* パッケージがインストールされている必要があります。

39.1. Python のバージョン

Python で互換性のない 2 つのバージョン (Python 2.x および Python 3.x) が広く使用されています。RHEL 8 は、以下のバージョンの Python を提供します。

表39.1 RHEL 8 の Python バージョン

バージョンインストールするパッケージコマンドの例どのバージョン以降で利用可能かライフサイクル

Python 3.6

python3

python3pip3

RHEL 8.0

完全な RHEL 8

Python 2.7

python2

python2pip2

RHEL 8.0

より短い

Python 3.8

python38

python3.8, pip3.8

RHEL 8.2

より短い

Python 3.9

python39

python3.9, pip3.9

RHEL 8.4

より短い

サポート期間は、「Red Hat Enterprise Linux のライフサイクル 」および「Red Hat Enterprise Linux 8 Application Streams ライフサイクル」を参照してください

Python の各バージョンは個別のモジュールで配布され、設計上、同じシステムに複数のモジュールを同時にインストールできます。

python38 モジュールおよび python39 モジュールには、python36 モジュールに提供されているシステムツール (RPM、DNF、SELinux など) へのバインディングと同じものを含めないでください。

重要

Python のインストール時、起動時、対話時にはバージョンを常に指定します。たとえば、パッケージ名またはコマンド名で、python の代わりに python3 を使用します。Python 関連のすべてのコマンドにもバージョンを含む必要があります (例: pip3pip2pip3.8、または pip3.9など)。

RHEL 8 では、バージョンを指定しない python コマンド (/usr/bin/python) は、デフォルトで利用できません。alternatives コマンドを使用して設定できます。手順については、「バージョンを指定しない 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 から選択できます。

重要

Red Hat Enterprise Linux 8 のシステムツールは、内部の platform-python パッケージで提供される Python バージョン 3.6 を使用します。Red Hat は、代わりに python36 パッケージを使用することを推奨します。

第40章 Python のインストールおよび使用

Red Hat Enterprise Linux 8 では、Python 3 は、AppStream リポジトリーの python36python38、および python39 モジュールにより提供されるバージョン 3.6、3.8、および 3.9 で配布されます。

警告

バージョンを指定しない python コマンドを使用して Python をインストールまたは実行すると、曖昧なためデフォルトでは動作しません。Python のバージョンを常に指定するか、alternatives コマンドを使用してシステムのデフォルトバージョンを設定します。

40.1. Python 3 のインストール

設計上、python27python36python38、および python39 モジュールを含む RHEL 8 モジュールを同時にインストールできます。1 つのモジュール内の複数のストリームでの並列インストールは、サポート対象外です。

mod_wsgi モジュールを除き、同じシステムに Python3.6 と同時に、いずれかのバージョン用にビルドされたパッケージを含む Python3.8 と Python3.9 をインストールできます。Apache HTTP Server の制限により、システムに python3-mod_wsgipython38-mod_wsgi、または python39-mod_wsgi パッケージのいずれかしかインストールできません。

手順

  • python36 モジュールから Python 3.6 をインストールするには、以下を使用します。

    # yum install python3

    python36:3.6 モジュールストリームは、自動的に有効になります。

  • python38 モジュールから Python 3.8 をインストールするには、以下を使用します。

    # yum install python38

    python38:3.8 モジュールストリームは、自動的に有効になります。

  • python39 モジュールから Python 3.9 をインストールするには、以下を使用します。

    # yum install python39

    python39:3.9 モジュールストリームは、自動的に有効になります。

検証手順

  • お使いのシステムにインストールされている Python のバージョンを確認するには、必要なバージョンの Python 固有の python コマンドで --version オプションを使用します。

    • Python 3.6 の場合

      $ python3 --version
    • Python 3.8 の場合

      $ python3.8 --version
    • Python 3.9 の場合

      $ python3.9 --version

40.2. Python 3 追加パッケージのインストール

Python 3.6 用のアドオンモジュールのパッケージは、通常 python3- 接頭辞を使用し、Python 3.8 のパッケージには python38- の接頭辞が含まれ、Python 3.9 のパッケージには python39- 接頭辞が含まれます。以下の例にあるように、追加の Python パッケージのインストール時には常に接頭辞を含めます。

手順

  • Python 3.6 の Requests モジュールをインストールするには、以下を使用します。

    # yum install python3-requests
  • Cython 拡張を Python 3.8 にインストールするには、以下を使用します。

    # yum install python38-Cython
  • Python 3.9 から pip パッケージインストーラーをインストールするには、以下を使用します。

    # yum install python39-pip

40.3. 開発者用の Python 3 追加ツールのインストール

開発者向けの追加の Python ツールは、該当する python3x-devel モジュールの CodeReady Linux Builder リポジトリーを介して配布されます。

python38-devel モジュールには python38-pytest パッケージとその依存関係 (pyparsingatomicwritesattrspackagingpymore-itertoolspluggy、および wcwidth パッケージ) が含まれます。

python39-devel モジュールには python39-pytest パッケージとその依存関係 (pyparsingattrspackagingpymore-itertoolspluggywcwidthiniconfig、および pybind11 パッケージ) が含まれます。python39-devel モジュールには、python39-debug パッケージおよび python39-Cython パッケージも含まれています。

重要

CodeReady Linux Builder リポジトリーおよびそのコンテンツは、Red Hat ではサポートされていません。

python39-devel モジュールからパッケージをインストールするには、以下の手順を使用します。

手順

  1. CodeReady Linux Builder リポジトリーを有効にします。

    # subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms
  2. python39-devel モジュールを有効にします。

    # yum module enable python39-devel
  3. python39-pytest パッケージをインストールします。

    # yum install python39-pytest

python38-devel モジュールからパッケージをインストールするには、上記のコマンドで python39-python38 に置き換えます。

40.4. 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 モジュールストリームは、自動的に有効になります。

Python 2 用のアドオンモジュールのパッケージは、通常、接頭辞 python2- を使用します。以下の例にあるように、追加の Python パッケージのインストール時には常に接頭辞を含めます。

  • Python 2 の Requests モジュールをインストールするには、以下を使用します。

    # yum install python2-requests
  • Python 2 に Cython 拡張をインストールするには、以下を使用します。

    # yum install python2-Cython

検証手順

  • システムに Python バージョンがインストールされていることを確認するには、以下を使用します。

    $ python2 --version
注記

設計上、python27python36python38、および python39 モジュールを含む RHEL 8 モジュールを同時にインストールできます。

40.5. Python 2 から Python 3 への移行

開発者は、Python 2 で記述したコードを Python 3 に移行できます。

大規模なコードベースを Python 3 に移行する方法は「The Conservative Python 3 Porting Guide」を参照してください

この移行が終了すると、元の Python 2 コードは Python 3 インタープリターにより解釈できるようになり、同様に Python 2 インタープリターは解釈できるままとなることに注意してください。

40.6. Python の使用

Python インタープリターまたは 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
  • Python 3.9 インタープリターまたは関連コマンドを実行するには、以下を使用します。

    $ python3.9
    $ python3.9 -m pip --help
    $ pip3.9 install package
  • Python 2 インタープリターまたは関連コマンドを実行するには、以下を使用します。

    $ python2
    $ python2 -m cython --help
    $ pip2 install package

第41章 バージョンを指定しない Python の設定

システム管理者は、alternatives コマンドを使用して、/usr/bin/python に、バージョンを管理しない python コマンドを設定できます。必要なパッケージ (python3python38python39、または python2) は、バージョンを指定しないコマンドをそれぞれのバージョンに設定する前にインストールする必要があります。

重要

/usr/bin/python 実行ファイルは 代替 システムによって制御されます。更新時に手動の変更が上書きされる可能性があります。

その他の Python 関連のコマンド (pip3 など) には、バージョンを指定しないで設定できるバリアントがあります。

41.1. バージョンを指定しない python コマンドを直接設定

バージョンを指定しない 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 3.9 に設定するには、以下を使用します。

    # alternatives --set python /usr/bin/python3.9
  • バージョンを指定しない python コマンドを Python 2 に設定するには、以下のコマンドを実行します。

    # alternatives --set python /usr/bin/python2

41.2. バージョンを指定しない python コマンドを、必要な Python バージョンに対話的に設定する

バージョンを指定しない python コマンドを、必要な Python バージョンに対話的に設定できます。

前提条件

  • 必要なバージョンの Python がインストールされていることを確認する。

手順

  1. バージョンを指定しない python コマンドを対話的に設定するには、次のコマンドを実行します。

    # alternatives --config python
  2. 表示された一覧から必要なバージョンを選択します。
  3. この設定をリセットし、バージョンを指定しない python コマンドを削除するには、次のコマンドを実行します。

    # alternatives --auto python

41.3. 関連情報

  • man ページのalternatives(8) および unversioned-python(1)

第42章 Python 3 RPM のパッケージ化

ほとんどの Python プロジェクトは、パッケージ化に Setuptools を使用して、setup.py ファイルにパッケージ情報を定義します。Setuptools パッケージ化の詳細は Setuptools ドキュメントを参照してください

Python プロジェクトを RPM パッケージにパッケージ化することもできます。これには、Setuptools パッケージ化と比較して以下の利点があります。

  • その他の RPM のパッケージの依存関係の指定 (Python 以外も含む)
  • 電子署名

    電子署名を使用すると、RPM パッケージの内容は、オペレーティングシステムのその他の部分とともに検証、統合、およびテストできます。

42.1. Python パッケージ用の SPEC ファイルの説明

SPEC ファイルには、RPM の構築に rpmbuild ユーティリティーを使用する命令が含まれています。命令は、一連のセクションに含まれています。SPEC ファイルには、セクションが定義されている 2 つの主要部分があります。

  • プリアンブル (ボディーに使用されている一連のメタデータ項目が含まれています)
  • ボディー (命令の主要部分が含まれています)

Python プロジェクトの RPM SPEC ファイルには、非 Python RPM SPEC ファイルと比較していくつかの詳細があります。特に注目すべきは、Python ライブラリーの RPM パッケージ名に、Python 3.6 の場合は python3、Python 3.8 の場合は python38、Python 3.9 の場合は python39 など、バージョンを判別する接頭辞を常に含める必要があります。

その他の詳細は、次の 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 インタープリターディレクティブを持つファイルが自動的に /usr/bin/python3.6に変更されるように、python36-rpm-macros パッケージが必要です。
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 など) が含まれます。リテラルパスではなく、マクロを使用することが常に推奨されます。

42.2. Python 3 RPM の一般的なマクロ

SPEC ファイルでは、値をハードコーディングするのではなく、以下の Python 3 RPM のマクロのテーブルで説明されているマクロを常に使用します。

マクロ名では、バージョンを指定しない python ではなく、python3 または python2 を使用してください。SPEC ファイルの BuildRequires で、特定の Python 3 バージョンを python36-rpm-macrospython38-rpm-macros、または python39-rpm-macros に設定します。

表42.1 Python 3 RPM 用のマクロ

マクロ一般的な定義説明

%{__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

 

システムパッケージに適した引数で setup.py build コマンドを実行します。

%py3_install

 

システムパッケージに適した引数で setup.py install コマンドを実行します。

42.3. Python RPM の自動 Provides

Python プロジェクトをパッケージ化する際、以下のディレクトリーが存在する場合は、作成される RPM に以下のディレクトリーが含まれていることを確認してください。

  • .dist-info
  • .egg-info
  • .egg-link

このディレクトリーから、RPM ビルドプロセスは自動的に仮想 pythonX.Ydist Provides (python3.6dist(detox) など) を生成します。この仮想 Provides は、%python_enable_dependency_generator マクロにより指定されるパッケージにより提供されます。

第43章 Python スクリプトでインタープリターディレクティブの処理

Red Hat Enterprise Linux 8 では、実行可能な Python スクリプトは、少なくとも主要な Python バージョンを明示的に指定するインタープリターディレクティブ (別名 hashbangs または shebangs) を使用することが想定されます。以下に例を示します。

#!/usr/bin/python3
#!/usr/bin/python3.6
#!/usr/bin/python2

/usr/lib/rpm/redhat/brp-mangle-shebangs BRP (buildroot policy) スクリプト は、RPM パッケージを構築する際に自動的に実行し、実行可能なすべてのファイルでインタープリターディレクティブを修正しようとします。

BRP スクリプトは、以下のようにあいまいなインタープリターディレクティブを含む Python スクリプトが発生すると、エラーを作成します。

#!/usr/bin/python

または

#!/usr/bin/env python

43.1. Python スクリプトでインタープリターディレクティブの変更

RPM ビルド時にビルドエラーが発生する Python スクリプト内のインタープリターディレクティブを変更します。

前提条件

  • Python スクリプトのインタープリターディレクティブの一部でビルドエラーが発生します。

手順

インタープリターディレクティブを変更するには、以下のタスクのいずれかを実行します。

  • platform-python-devel パッケージから pathfix.py スクリプトを適用します。

    # pathfix.py -pn -i %{__python3} PATH …​

    複数の PATH を指定できます。PATH がディレクトリーの場合、pathfix.py はあいまいなインタープリターディレクティブを持つスクリプトだけでなく、^[a-zA-Z0-9_]+\.py$ のパターンに一致する Python スクリプトを再帰的にスキャンします。このコマンドを %prep セクション、または %install セクションに追加します。

  • パッケージ化した Python スクリプトを、想定される形式に準拠するように変更します。この目的のために、pathfix.py は、RPM ビルドプロセス以外でも使用できます。pathfix.py を RPM ビルド以外で実行する場合は、上記の例の %{__python3} を、/usr/bin/python3 などのインタープリターディレクティブのパスに置き換えます。

パッケージ化された Python スクリプトに Python 3.6 以外のバージョンが必要な場合は、上記のコマンドを調整して必要なバージョンを含めます。

43.2. カスタムパッケージの /usr/bin/python3 インタープリターディレクティブの変更

デフォルトでは、/usr/bin/python3 の形式でのインタープリターディレクティブは、Red Hat Enterprise Linux のシステムツールに使用されるplatform-python パッケージから Python を参照するインタープリターディレクティブに置き換えられます。カスタムパッケージの /usr/bin/python3 インタープリターディレクティブを変更して、AppStream リポジトリーからインストールした特定バージョンの Python を参照できます。

手順

  • Python の特定バージョンのパッケージを構築するには、対応する python パッケージの python*-rpm-macros サブパッケージを SPEC ファイルの BuildRequires セクションに追加します。たとえば、Python 3.6 の場合は、以下の行を追加します。

    BuildRequires:  python36-rpm-macros

    これにより、カスタムパッケージの /usr/bin/python3 インタープリターディレクティブは、自動的に /usr/bin/python3.6 に変換されます。

注記

BRP スクリプトがインタープリターディレクティブを確認したり、変更したりしないようにするには、以下の RPM ディレクティブを使用します。

%undefine %brp_mangle_shebangs

第44章 PHP スクリプト言語の使用

Hypertext Preprocessor (PHP) はサーバー側のスクリプトに主に使用する汎用スクリプト言語で、Web サーバーを使用して PHP コードを実行できるようにします。

RHEL 8 では、PHP スクリプト言語は php モジュールにより提供されます。これは、複数のストリーム (バージョン) で利用できます。

ユースケースによっては、選択したモジュールストリームの特定のプロファイルをインストールできます。

  • common: Web サーバーを使用したサーバー側のスクリプトのデフォルトプロファイル。これには、広範に使用される拡張機能が複数含まれています。
  • minimal: このプロファイルは、Web サーバーを使用せずに PHP でのスクリプト用のコマンドラインインターフェースのみをインストールします。
  • devel: このプロファイルには、共通 プロファイルのパッケージと開発用の追加パッケージが含まれます。

44.1. PHP スクリプト言語のインストール

本セクションでは、選択したバージョンの php モジュールをインストールする方法を説明します。

手順

  • デフォルトのプロファイルで php モジュールストリームをインストールするには、以下を使用します。

    # yum module install php:stream

    stream は、インストールする PHP のバージョンに置き換えます。

    たとえば、PHP 7.4 をインストールするには、以下を実行します。

    # yum module install php:7.4

    デフォルトの 共通 プロファイルは php-fpm パッケージもインストールし、Apache HTTP Server または nginx で使用する PHP を事前設定します。

  • php モジュールストリームの特定のプロファイルをインストールするには、以下を使用します。

    # yum module install php:stream/profile

    stream は、インストールする プロファイル の名前に置き換えます。

    たとえば、Web サーバーを使用しない PHP 7.4 をインストールするには、以下を実行します。

    # yum module install php:7.4/minimal

44.2. Web サーバーでの PHP スクリプト言語の使用

44.2.1. Apache HTTP Server での PHP の使用

RHEL 8 では、Apache HTTP Server を使用することで PHP を FastCGI プロセスサーバーとして実行できます。FastCGI Process Manager (FPM) は、Web サイトで高負荷の管理可能にする代替の PHP FastCGI デーモンです。RHEL 8 では、PHP はデフォルトで FastCGI Process Manager を使用します。

本セクションでは、FastCGI プロセスサーバーを使用して PHP コードを実行する方法を説明します。

前提条件

手順

  1. httpd モジュールをインストールします。

    # yum module install httpd:2.4
  2. Apache HTTP Server を起動します。

    # systemctl start httpd

    または、Apache HTTP Server をシステムで実行している場合は、PHP のインストール後に httpd サービスを再起動します。

    # systemctl restart httpd
  3. php-fpm サービスを起動します。

    # systemctl start php-fpm
  4. 必要に応じて、両方のサービスが起動時に開始できるようにします。

    # systemctl enable php-fpm httpd
  5. PHP の設定に関する情報を取得するには、以下の内容を含む index.php ファイルを /var/www/html/ ディレクトリーに作成します。

    echo '<?php phpinfo(); ?>' > /var/www/html/index.php
  6. index.php ファイルを実行するには、ブラウザーで以下を指定します。

    http://<hostname>/
  7. オプション: 特定の要件がある場合は、設定を調整します。

    • /etc/httpd/conf/httpd.conf - 一般的な httpd 設定
    • /etc/httpd/conf.d/php.conf - httpd の PHP 固有の設定
    • /usr/lib/systemd/system/httpd.service.d/php-fpm.conf - デフォルトでは、php-fpm サービスは httpd と一緒に起動します。
    • /etc/php-fpm.conf - FPM の主要設定
    • /etc/php-fpm.d/www.conf - デフォルトの www プール設定

例44.1 「Hello, World」の実行 Apache HTTP Server を使用した PHP スクリプト

  1. /var/www/html/ ディレクトリーにプロジェクト用の hello ディレクトリーを作成します。

    # mkdir hello
  2. 以下の内容を含む /var/www/html/hello/ ディレクトリーに hello.php ファイルを作成します。

    # <!DOCTYPE html>
    <html>
    <head>
    <title>Hello, World! Page</title>
    </head>
    <body>
    <?php
        echo 'Hello, World!';
    ?>
    </body>
    </html>
  3. Apache HTTP Server を起動します。

    # systemctl start httpd
  4. hello.php ファイルを実行するには、ブラウザーに以下を指定します。

    http://<hostname>/hello/hello.php

    これにより、「Hello, World!」テキストの Web ページが表示されます。

44.2.2. nginx Web サーバーでの PHP の使用

本セクションでは、nginx Web サーバーで PHP コードを実行する方法を説明します。

前提条件

手順

  1. nginx モジュールストリームをインストールします。

    # yum module install nginx:stream

    stream は、インストールする nginx のバージョンに置き換えます。

    たとえば、nginx バージョン 1.18 をインストールするには、以下を実行します。

    # yum module install nginx:1.18
  2. nginx サーバーを起動します。

    # systemctl start nginx

    または、使用中のシステムで nginx サーバーを実行している場合は、PHP のインストール後に nginx サービスを再起動します。

    # systemctl restart nginx
  3. php-fpm サービスを起動します。

    # systemctl start php-fpm
  4. 必要に応じて、両方のサービスが起動時に開始できるようにします。

    # systemctl enable php-fpm nginx
  5. PHP の設定に関する情報を取得するには、以下の内容を含む index.php ファイルを /usr/share/nginx/html/ ディレクトリーに作成します。

    echo '<?php phpinfo(); ?>' > /usr/share/nginx/html/index.php
  6. index.php ファイルを実行するには、ブラウザーで以下を指定します。

    http://<hostname>/
  7. オプション: 特定の要件がある場合は、設定を調整します。

    • /etc/nginx/nginx.conf - nginx main configuration
    • /etc/nginx/conf.d/php-fpm.conf - nginxの FPM 設定
    • /etc/php-fpm.conf - FPM の主要設定
    • /etc/php-fpm.d/www.conf - デフォルトの www プール設定

例44.2 「Hello, World」の実行 nginx サーバーを使用した PHP スクリプト

  1. プロジェクトの hello ディレクトリーを /usr/share/nginx/html/ ディレクトリーに作成します。

    # mkdir hello
  2. 以下の内容で /usr/share/nginx/html/hello/ ディレクトリーに hello.php ファイルを作成します。

    # <!DOCTYPE html>
    <html>
    <head>
    <title>Hello, World! Page</title>
    </head>
    <body>
    <?php
        echo 'Hello, World!';
    ?>
    </body>
    </html>
  3. nginx サーバーを起動します。

    # systemctl start nginx
  4. hello.php ファイルを実行するには、ブラウザーに以下を指定します。

    http://<hostname>/hello/hello.php

    これにより、「Hello, World!」テキストの Web ページが表示されます。

44.3. コマンドラインインターフェースを使用した PHP スクリプトの実行

通常、PHP スクリプトは Web サーバーを使用して実行されますが、コマンドラインインターフェースを使用して実行することも可能です。

コマンドラインのみを使用して php スクリプトを実行する場合は、php モジュールストリームの 最低限 のプロファイルをインストールします。

詳しくは、「PHP スクリプト言語のインストール」 を参照してください。

前提条件

手順

  1. テキストエディターで filename.php ファイルを作成します。

    filename は、使用するファイル名に置き換えます。

  2. コマンドラインから、作成した filename.php ファイルを実行します。

    # php filename.php

例44.3 「Hello, World」の実行 コマンドラインインターフェースを使用した PHP スクリプト

  1. テキストエディターを使用して、以下の内容で hello.php ファイルを作成します。

    <?php
        echo 'Hello, World!';
    ?>
  2. コマンドラインで hello.php ファイルを実行します。

    # php hello.php

    その結果、「Hello, World!」が出力されます。

44.4. 関連情報

  • httpd(8) - httpd サービスの man ページで、コマンドラインオプションの一覧が記載されます。
  • httpd.conf (5) - httpd 設定ファイルの構造と場所を説明する httpd 設定用の man ページです。
  • nginx(8) - nginx Web サーバーの man ページです。コマンドラインオプションの完全一覧とシグナルの一覧が含まれます。
  • php-fpm(8) - PHP FPM の man ページでは、コマンドラインオプションおよび設定ファイルの全リストが説明されています。

第45章 言語パックの使用

Langpacks システムにインストールされているすべてのパッケージに対する翻訳、ディクショナリー、およびロケールを含む追加のアドオンパッケージをインストールするメタパッケージです。

Red Hat Enterprise Linux 8 システム側 langpacks インストールは、langpack-<langcode> 言語メタパッケージおよび RPM の弱い依存関係(補完タグ)に基づいています。

使用できる前提条件は 2 つあります。 langpacks 選択した言語向けです。この前提条件が満たされている場合は、言語のメタパッケージが選択した言語の言語パックをトランザクションセットに自動的に取得します。

前提条件

  • 選択した言語の langpacks-<langcode> 言語メタパッケージがインストールされている。

    Red Hat Enterprise Linux 8 では、言語パックのメタパッケージが Application Stream リポジトリーで利用できるため、Anaconda インストーラーを使用して、オペレーティングシステムの初期インストールで自動的にインストールされます。

    詳細は 「言語パックを提供する言語の確認」 を参照してください。

  • ベースパッケージ (locale パッケージを検索) は、システムにすでにインストールされています。

45.1. 言語パックを提供する言語の確認

この手順では、言語パックを提供する言語を確認します。

手順

  • 以下のコマンドを実行します。

    # yum list langpacks-*

45.2. RPM の弱い依存関係ベースの言語パックでの作業

本セクションでは、RPM の弱い依存関係ベースの言語パックのクエリー、言語サポートのインストールまたは削除の時に実行できる複数アクションを説明します。

45.2.1. インストールされている言語サポートの一覧表示

インストールされている言語サポートの一覧を表示するには、この手順を使用します。

手順

  • 以下のコマンドを実行します。

    # yum list instal