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

Red Hat Enterprise Linux 8

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

Red Hat Customer Content Services

概要

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

第1章 Red Hat Enterprise Linux におけるシステム管理の概要

以下のセクションでは、Red Hat Enterprise Linux をインストールした直後にシステム管理者が行う必要がある可能性がある基本的なタスクの概要を説明します。

注記

これらのタスクには、必須ではありませんが、通常はインストールプロセス中に実行済みとなる項目が含まれている場合があります。以下のセクションではこのようなタスクを扱い、インストール中に必要な方法と、関連ドキュメントへのリンクを紹介します。

Red Hat Enterprise Linux のインストールの詳細は『Red Hat Enterprise Linux 8 のインストール』を参照してください。

注記

本章では、実行すべきコマンドを紹介します。root 権限が必要なコマンドには # がついており、一般ユーザーが実行できるコマンドには $ がついています。

インストール後のタスクはすべてコマンドラインから実行できますが、一部のコマンドは RHEL 8 Web コンソールから実行することもできます。

1.1. RHEL 8 Web コンソールと使用可能なタスク

RHEL 8 Web コンソールは、対話型サーバー管理インターフェースです。このコンソールは、ブラウザーの実際の Linux セッションからオペレーティングシステムと直接対話します。

Web コンソールは、以下のタスクを実行できます。

  • システムの基本機能 (ハードウェア情報、時間設定、パフォーマンスプロファイル、レルムドメインへの接続など) の監視
  • システムログファイルの検査
  • ネットワークインターフェースの管理およびファイアウォールの設定
  • Docker イメージの操作
  • 仮想マシンの管理
  • ユーザーアカウントの管理
  • システムサービスの監視および設定
  • 診断レポートの作成
  • カーネルダンプ設定のセットアップ
  • パッケージの管理
  • SELinux の設定
  • ソフトウェアの更新
  • システムサブスクリプションの管理
  • ターミナルへのアクセス

RHEL 8 Web コンソールのインストールおよび使用の詳細は『RHEL 8 web コンソールを使用したシステムの管理』を参照してください。

1.1.1. システム管理の基本タスクに RHEL 8 Web コンソールの使用

システム メニューでは、最も基本的な操作を行います。

たとえば、以下のような操作が含まれます。

  • システムのシャットダウンまたは再起動
  • ハードウェア情報の検査
  • パフォーマンスプロファイルの設定
  • ホスト名の設定
  • realmd ドメインへの接続

図1.1 RHEL 8 Web コンソールでシステムのシャットダウンまたは再起動

cockpit shutdown restart new

図1.2 RHEL 8 Web コンソールでハードウェア情報の確認

cs getting started HW info new

図1.3 RHEL 8 Web コンソールでパフォーマンスプロファイルの設定

cockpit performance profiles new

図1.4 RHEL 8 Web コンソールでホスト名の設定

cockpit hostname new

図1.5 RHEL 8 Web コンソールで realmd ドメインへの接続

cockpit join a domain new

1.2. 環境の基本設定

環境の基本設定には、以下が含まれます。

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

この項目は、通常、インストールプロセス時に設定されます。詳細は『Red Hat Enterprise Linux 8 のインストール』を参照してください。

1.2.1. 日付と時刻の設定の概要

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

Red Hat Enterprise Linux 8 は、chronyd デーモンを使用して NTP を実装します。chronyd は、chrony パッケージから利用できます。chronydNTP を設定および使用する方法は 5章Chrony スイートを使用した NTP の設定 を参照してください。

システムの現在日時の表示
  • システムの現在日時を表示するには、以下のいずれかのコマンドを使用します。

    ~]$ date
    ~]$ timedatectl

    timedatectl コマンドを使用すると、より詳細な出力が得られます。出力には、ユニバーサル時間、現在使用しているタイムゾーン、Network Time Protocol (NTP) 設定ステータスなどの情報が含まれます。

インストール中の日時の設定方法は『Red Hat Enterprise Linux 8 のインストール』を参照してください。

1.2.1.1. RHEL 8 Web コンソールで時間設定の管理

RHEL 8 Web コンソールでは時間設定も行えます。System オプションでは、NTP プロトコルの設定や、タイムゾーンの手動変更が可能です。

図1.6 RHEL 8 Web コンソールで時間設定の管理

cockpit time configuration

1.2.2. システムロケールの設定の概要

システム全体にわたるロケール設定は /etc/locale.conf ファイルに保存され、システム起動の初期段階で systemd デーモンが読み取ります。/etc/locale.conf に設定したロケール設定は、個別のプログラムやユーザーが上書きしない限り、すべてのサービスやユーザーに継承されます。

システムロケールを処理する基本的なタスク

  • 利用可能なシステムロケール設定の一覧表示

    ~]$ localectl list-locales
  • システムロケール設定の現行ステータスの表示

    ~]$ localectl status
  • デフォルトのシステムロケール設定または変更

    ~]# localectl set-locale LANG=locale

1.2.3. キーボードレイアウト設定の概要

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

キーボードレイアウトを扱う基本的なタスクには、以下が含まれます。

  • 利用可能なキーマップの一覧表示

    ~]$ localectl list-keymaps
  • キーマップ設定の現行ステータスの表示

    ~]$ localectl status
  • デフォルトのシステムキーマップの設定または変更

    ~]# localectl set-keymap

1.3. ネットワークアクセスの設定および管理

1.3.1. インストールプロセス時のネットワークアクセスの設定

インストールプロセス時のネットワークアクセスの設定方法

  • Anaconda インストールプログラムにおけるグラフィカルユーザーインターフェースの「インストールの概要」画面に表示される ネットワークとホスト名 メニュー
  • Anaconda インストールプログラムのテキストモードの Network settings オプション
  • キックスタートファイル

インストールが完了して初めてシステムを起動すると、インストール中に設定したネットワークインターフェースが自動的に有効になります。

インストール中のネットワークアクセスの設定方法は『Red Hat Enterprise Linux 8 のインストール』を参照してください。

1.3.2. nmcli を使用したインストールプロセス後のネットワーク接続管理

以下のコマンドを実行し、nmcli ユーティリティーを使用してネットワーク接続を管理します。

注記

nmcli ユーティリティーでは、Tab キーを 2 回押すと有効になる強力な構文補完機能があります。この機能を使用するには、bash-completion パッケージをインストールする必要があります。

接続を新規作成するには、以下を実行します。

~]# nmcli con add type type of the connection con-name connection name ifname ifname ipv4.addresses ipv4 address ipv4.gateway gateway address

以下を置き換えます。

  • type of the connection - 必要なデバイスのタイプ
  • connection name - 必要な接続名
  • ifname - 必要なデバイス名
  • ipv4 address - 必要な IPv4 アドレス/ネットマスク
  • gateway address - 必要なゲートウェイアドレス

ipv4 address および gateway address の設定は任意ですが、残りのすべての設定は必須です。

補助モードで新しい接続を作成することもできます。以下のコマンドを実行すると、この接続に関する設定を入力することが求められるため、その指示に従います。

~]# nmcli -a con add

既存の接続を修正するには、以下を実行します。

~]# nmcli con mod connection name setting.property newvalue

以下を置き換えます。

  • connection name - 修正する接続の名前
  • setting.property - 修正する設定
  • newvalue - この設定に必要な値

たとえば、enp0 という名前の接続に対して、IPv4 アドレスの設定方法 (ipv4.method) を auto に設定するには、以下のコマンドを実行します。

~]# nmcli con mod enp0 ipv4.method auto

接続を変更するには、以下のコマンドを実行します。

~]# nmcli connection edit connection name

ここでは、connection name を、変更する接続の名前に置き換えます。

すべての接続を表示するには、以下を実行します。

~]# nmcli con show

アクティブな接続を表示するには、以下を実行します。

~]# nmcli con show --active

特定の接続の設定をすべて表示するには、以下を実行します。

~]# nmcli con show con-name connection name

ここで、connection name を、必要な接続の名前に置き換えます。

次に、特定の設定の入力を求める指示に従います。設定可能なすべてのオプションを表示するには、エディターで print コマンドを実行します。

1.3.3. nmtui を使用したインストールプロセス後のネットワーク接続管理

NetworkManager テキストユーザーインターフェース (TUI) のユーティリティー (nmtui) は、NetworkManager を制御してネットワークを設定するテキストインターフェースを提供します。

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

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

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

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

cs getting started networking new

1.4. システム登録およびサブスクリプション管理の基本

1.4.1. Red Hat サブスクリプションと使用可能なタスク

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

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

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

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

サブスクリプションは、インストールプロセスで登録できます。詳細は『Red Hat Enterprise Linux 8 のインストール』を参照してください。

インストールプロセス中にシステムの登録を行わなかった場合は、インストール後に、以下の手順に従って登録できます。この手順で紹介するコマンドはすべて root で実行する必要がある点に注意してください。

システムの登録およびサブスクリプション

  1. システムを登録します。

    ~]# subscription-manager register

    コマンドを実行すると、Red Hat カスタマーポータルのユーザー名とパスワードの入力を求めるプロンプトが表示されます。

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

    ~]# subscription-manager list --available

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

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

    ~]# subscription-manager attach --pool=pool_id

1.5. ソフトウェアのインストール

本セクションでは、ソフトウェアをインストールする際の基本的な内容を紹介します。ソフトウェアをインストールできるようにするための前提条件、ソフトウェアパッケージングとソフトウェアリポジトリーに関する基本情報、およびソフトウェアのインストールに関連する基本的なタスクの実行方法を説明します。

1.5.1. ソフトウェアインストールの前提条件

Red Hat コンテンツ配信ネットワークのサブスクリプションサービスは、Red Hat のソフトウェアインベントリーを処理するメカニズムを提供し、ソフトウェアを追加でインストールしたり、インストール済みのパッケージを更新したりできるようにします。「システム登録およびサブスクリプション管理の基本」 に従って、システムの登録とサブスクリプションの割り当てを完了したら、ソフトウェアのインストールを開始できます。

1.5.2. ソフトウェアパッケージングとソフトウェアリポジトリーのシステムの概要

Red Hat Enterprise Linux システム上のすべてのソフトウェアは、RPM パッケージに分類されます。RPM パッケージは、特定のリポジトリーに置かれています。Red Hat コンテンツ配信ネットワークにシステムをサブスクライブすると、/etc/yum.repos.d/ ディレクトリーにリポジトリーファイルが作成されます。

パッケージ操作を管理するには、yum ユーティリティーを使用します。

  • パッケージに関する情報の検索
  • パッケージのインストール
  • パッケージの更新
  • パッケージの削除
  • 現在利用可能なリポジトリー一覧の確認
  • リポジトリーの追加または削除
  • リポジトリーの有効化または無効化

ソフトウェアのインストールに関連する基本的なタスクの詳細は 「サブスクリプションマネージャーと yum を使用したソフトウェアインストールの基本タスクの管理」 を参照してください。

1.5.3. サブスクリプションマネージャーと yum を使用したソフトウェアインストールの基本タスクの管理

以下は、オペレーティングシステムのインストール後に必要になる可能性がある最も基本的なソフトウェアインストールタスクです。

  • 利用可能なリポジトリーをすべて表示します。

    ~]# subscription-manager repos --list
  • 現在有効になっているリポジトリーをすべて表示します。

    ~]$ yum repolist
  • リポジトリーを有効または無効にします。

    ~]# subscription-manager repos --enable repository
    ~]# subscription-manager repos --disable repository
  • 特定の文字列に一致するパッケージを検索します。

    ~]$ yum search string
  • パッケージをインストールします。

    ~]# yum install package_name
  • パッケージおよびその依存関係をすべて更新します。

    ~]# yum update
  • パッケージを更新します。

    ~]# yum update package_name
  • パッケージおよびそれに依存しているパッケージをすべてアンインストールします。

    ~]# yum remove package_name
  • インストール済みで利用可能なパッケージの情報をすべて表示します。

    ~]$ yum list all
  • インストール済みパッケージの情報をすべて表示します。

    ~]$ yum list installed

1.6. システム起動時に systemd サービスの開始

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

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

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

インストールプロセス時に、システムの起動時に有効または無効にするサービスを設定できます。インストール後に、オペレーティングシステムでサービスを有効または無効にすることもできます。

インストールプロセス時に、システムの起動時に有効または無効にするサービスの一覧を作成するには、キックスタートファイルの services オプションを使用します。

services [--disabled=list] [--enabled=list]
注記

無効にするサービスの一覧は、有効にするサービスの一覧の前に処理されます。したがって、サービスが両方の一覧に記載されていると、そのサービスは有効になります。サービスの一覧はコンマ区切りのフォーマットで指定する必要があります。サービスの一覧には空白を使用しないでください。

インストール後に、オペレーティングシステムのサービスを有効または無効にするには、以下を実行します。

~]# systemctl enable service_name
~]# systemctl disable service_name

サービスの有効および無効の詳細は「systemd によるサービス管理」を参照してください。

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

systemd のターゲット、サービス、ソケット、タイマー、およびパスを管理するには、Web コンソール で Services を選択します。ここで状態の確認、開始または停止、有効化または無効化を設定できます。

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

cs getting started systemd new2

1.7. ファイアーウォール、SELinux、および SSH ログインを使用したシステムセキュリティーの強化

コンピューターセキュリティーとは、盗難やダメージからハードウェア、ソフトウェア、または情報を保護し、提供するサービスの混乱や誤りからコンピューターシステムを保護することです。したがって、コンピューターセキュリティーの保護は、機密データやビジネストランザクションを扱う企業だけではなく、すべてのお客様に欠かせないタスクになります。

コンピューターのセキュリティーには、多種多様の機能およびツールがあります。本セクションでは、オペレーティングシステムのインストール後に設定が必要な基本的なセキュリティー機能のみを説明します。Red Hat Enterprise Linux のセキュリティー保護に関する詳細は『セキュリティーの設定および管理』を参照してください。

1.7.1. ファイアウォールが有効で実行しているのを確認

1.7.1.1. ファイアウォールとシステムセキュリティーの強化方法

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

ファイアウォールは、firewalld サービスにより提供され、インストール時に自動的に有効になります。ただし、サービスを明示的に無効にした場合は、「ファイアウォールサービスの再有効化」 の説明に従って再度有効にできます。

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

インストール後に firewalld サービスが無効になっている場合は、再度有効にすることを Red Hat は推奨します。

一般ユーザーとして、firewalld の現在のステータスを表示します。

~]$ systemctl status firewalld

firewalld が有効ではなく実行していない場合は、root ユーザーに切り替えて、そのステータスを変更します。

~]# systemctl start firewalld
~]# systemctl enable firewalld

ファイアウォールの設定および使用の詳細は『Using and configuring firewalls』を参照してください。

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

Web コンソールでは、Networking の下にある Firewall オプションを使用して、firewalld サービスを有効または無効にします。

デフォルトでは、Web コンソールの firewalld サービスは有効です。これを無効にするには、以下のように off に設定します。また、ファイアウォールを通して許可するサービスを選択します。

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

cs getting started firewall new

1.7.2. SELinux の適切な状態の確認

1.7.2.1. SELinux とシステムセキュリティーの強化方法

Security Enhanced Linux (SELinux) は、どのプロセスがどのファイル、ディレクトリー、ポートにアクセスできるのかを決定するシステムセキュリティーの追加レイヤーです。

SELinux のスタータス

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

  • 有効
  • 無効

SELinux が無効の場合は、Discretionary Access Control (DAC) ルールだけが使用されます。

SELinux モード

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

  • Enforcing
  • Permissive

Enforcing モードは、SELinux ポリシーが強制されることを意味します。SELinux は、SELinux ポリシールールに基づいてアクセスを拒否し、特別に許可されている対話のみを有効にします。Enforcing モードは、インストール後のデフォルトモードで、最も安全な SELinux モードです。

Permissive モードは、SELinux のポリシーが強制されていないことを意味します。SELinux はアクセスを拒否しませんが、Enforcing モードでは拒否されるアクションの拒否がログに記録されます。Permissive モードは、インストール時のデフォルトのモードです。Permissive モードは、問題のトラブルシューティング時に AVC (アクセスベクターキャッシュ) へのアクセスを拒否する必要がある場合など、特定のケースで役立ちます。

SELinux の詳細は『セキュリティーの設定および管理』を参照してください。

1.7.3. SELinux のステータスの確認

デフォルトでは、SELinux は、インストール時には Permissive モードで動作し、インストールが完了すると Enforcing モードで動作します。

ただし、シナリオによっては、明示的に SELinux を Permissive モードに設定したり、インストール後にオペレーティングシステムで無効にすることもできます (たとえば、キックスタート設定で設定できます)。

重要

Red Hat は、Enforcing モードでシステムを使用することを推奨します。

現在の SELinux モードを表示し、必要に応じてモードを設定するには、以下を実行します。

SELinux ステータスの設定

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

    ~]$ getenforce
  2. 必要に応じて SELinux モードを切り替えます。

    切り替えは、一時的または永続的を選択できます。一時的な切り替えでは、システムを再起動すると設定が元に戻りますが、永続的に切り替えると、再起動後もその設定が持続します。

    • 一時的に Enforcing モードまたは Permissive モードのいずれかに切り替えるには、以下を実行します。

      ~]# setenforce Enforcing
      ~]# setenforce Permissive
    • 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

1.7.3.1. RHEL 8 Web コンソールで SELinux の管理

Web コンソールで、SELinux オプションを使用して SELinux の Enforcing ポリシーをオンまたはオフにします。

デフォルトでは、Web コンソールの SELinux Enforcing モードが有効になっており、SELinux が Enforcing モードで動作します。このモードを無効にして、SELinux を Permissive モードに切り替えることができます。/etc/sysconfig/selinux ファイルのデフォルト設定を変更した場合は、次回システムを起動する時に自動的に元に戻ります。

図1.10 RHEL 8 Web コンソールで SELinux の管理

cs getting started selinux on

1.7.4. SSH を経由したシステムへのアクセス

1.7.4.1. SSH ベースのアクセス、およびシステムセキュリティーの強化方法

別のコンピューターとの通信の安全性を確保したい場合は、SSH ベースの認証を使用できます。

SSH (Secure Shell) は、クライアントとサーバーとの間の通信を容易にし、SSH を実行するホストシステムにユーザーがリモートでログインできるようにするプロトコルです。SSH は接続を保護します。クライアントは、暗号化した認証情報をサーバーへ送信します。セッション中に送受信したすべてのデータは暗号化されて転送されます。

SSH は、パスワードなしでユーザーが認証できるようにします。これを行うために、SSH は公開鍵/秘密鍵のスキームを使用します。

SSH の詳細は『セキュリティーの設定および管理』を参照してください。

1.7.4.2. キーベースの SSH アクセスの設定

SSH 接続を使用できるようにするには、公開鍵と秘密鍵からなる鍵ペアを作成します。

鍵ファイルを作成してサーバーへコピー

  1. 公開鍵と秘密鍵を生成するには、以下を実行します。

    ~]$ ssh-keygen

    この鍵は共に ~/.ssh/ ディレクトリーに保存されます。

    • ~/.ssh/id_rsa.pub - 公開鍵
    • ~/.ssh/id_rsa - 秘密鍵

      公開鍵は秘密である必要はありません。秘密鍵の確認に使用されます。秘密鍵は秘密となります。秘密鍵は、鍵の生成プロセスで指定するパスフレーズで保護するように選択できます。パスフレーズにより認証はさらに安全となりますが、これを設定するとパスワードが毎回必要になります。これを回避するには、ssh-agent コマンドを利用します。この場合、パスフレーズを入力するのはセッション開始時の 1 回のみとなります。

  2. 最近変更した公開鍵を、ログインするリモートマシンにコピーします。

    ~]# ssh-copy-id USER@hostname

    これにより、パスワードを入力することなく、安全な方法でシステムにログインできるようになります。

1.7.4.3. SSH root ログインの無効化

デフォルトで有効になっている root ユーザーの SSH アクセスを無効にすることで、システムセキュリティーを高めることができます。

SSH root ログインの無効化

  1. /etc/ssh/sshd_config ファイルにアクセスします。

    ~]# vi /etc/ssh/sshd_config
  2. #PermitRootLogin yes と書かれた行を以下のように変更します。

    PermitRootLogin no
  3. sshd サービスを再起動します。

    ~]# systemctl restart sshd
注記

PermitRootLogin no を使用すると、root ユーザーはシステムに直接ログインできません。もしくは、「キーベースの SSH アクセスの設定」 で説明されているように、root ユーザーはログインできますが、パスワードを使用しない認証方法 (通常は鍵を使用した認証) を使用します。これを有効にするには、/etc/ssh/sshd_config ファイルで PermitRootLogin prohibit-password を指定します。

1.8. ユーザーアカウント管理の基本

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

通常のアカウントおよびシステムアカウント

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

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

警告

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

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

# Min/max values for automatic uid selection in useradd
#
UID_MIN                  1000
UID_MAX                 60000
# System accounts
SYS_UID_MIN               201
SYS_UID_MAX               999

グループとその使用可能な目的

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

1.8.1. ユーザーアカウントとグループを管理する基本的なコマンドラインツール

ユーザーアカウントとグループを管理する最も基本的なタスク、および適切なコマンドラインツールは、以下のとおりです。

  • ユーザーおよびグループの ID を表示します。

    ~]$ id
  • 新規のユーザーアカウントを作成します。

    ~]# useradd [options] user_name
  • username に属するユーザーアカウントに新しいパスワードを割り当てます。

    ~]# passwd user_name
  • グループにユーザーを追加します。

    ~]# usermod -a -G group_name user_name

ユーザーおよびグループの管理方法は 4章ユーザーアカウントおよびグループアカウントの管理、およびファイルのアクセス権の設定 を参照してください。

1.8.2. RHEL 8 Web コンソールでユーザーアカウントの管理

Web コンソールでアカウントを管理するには、Accounts メニューを選択します。

図1.11 RHEL 8 Web コンソールにおけるユーザーアカウントの管理

cs getting started accounts new

1.9. kdump メカニズムを使用したクラッシュカーネルのダンプ

本セクションは、kdump とも呼ばれるカーネルクラッシュダンプメカニズムの概要を説明します。「kdump と使用可能なタスク」 では、kdump で使用されるものを簡単に説明します。

『Red Hat Enterprise Linux 8 のインストール』 で説明されているように、kdump サービスのアクティベーションは、インストールプロセスで行います。本セクションは、「インストールプロセス後に kdump のインストールと有効化」 の説明に従ってインストールした後に、kdump サービスが無効な場合に手動で有効にする方法を説明します。

Web コンソールを使用して kdump を設定できます。詳細は 「RHEL 8 Web コンソールで kdump の設定」 を参照してください。

1.9.1. kdump と使用可能なタスク

システムがクラッシュした場合は、kdump と呼ばれるカーネルクラッシュダンプのメカニズムを利用できます。これにより、システムのメモリー内容を保存し、後で分析することが可能となります。kdump では、kexec システムコールにより、別のカーネルのコンテキストから Linux カーネルを起動し、BIOS を迂回して通常は失われてしまう 1 番目のカーネルメモリーの内容を維持するメカニズムを採用しています。

カーネルクラッシュが発生すると、kdump は kexec を使用して 2 番目のカーネル (キャプチャーカーネル) で起動します。この 2 番目のカーネルはシステムメモリーの予約部分にあり、1 番目のカーネルからはアクセスできません。2 番目のカーネルが起動すると、クラッシュしたカーネルメモリーの内容 (クラッシュダンプ) をキャプチャーして保存します。

kdump の詳細は『Managing, monitoring and updating the kernel』を参照してください。

1.9.2. インストールプロセス後に kdump のインストールと有効化

kdump がインストールされているのを確認し、設定するには、以下を行います。

kdump がインストールされたかどうかの確認、および kdump の設定

  1. システムに kdump がインストールされているかどうかを確認するには、以下のコマンドを実行します。

    ~]$ rpm -q kexec-tools
  2. kdump がインストールされていない場合は、root で以下のコマンドを実行すればインストールできます。

    ~]# yum install kexec-tools
  3. kdump を設定するには、以下を行います。

    『Managing, monitoring and updating the kernel』に従って、コマンドラインまたはグラフィカルユーザーインターフェースを使用します。

    グラフィカル設定ツールをインストールする必要がある場合は、以下を実行します。

    ~]# yum install system-config-kdump

1.9.3. RHEL 8 Web コンソールで kdump の設定

Web コンソールで、カーネルダンプ設定 を選択し、以下を確認します。

  • kdump ステータス
  • kdump に予約されているメモリー量
  • クラッシュダンプファイルの場所

図1.12 RHEL 8 Web コンソールで kdump の設定

cs getting started kdump new

1.10. ReaR を使用したシステムレスキューの実行およびシステムバックアップの作成

ソフトウェアやハードウェアの不具合でオペレーティングシステムが破損した場合は、システムをレスキューするためのメカニズムが必要です。システムの復旧にも、バックアップが役に立ちます。Red Hat は、これら両方のニーズを満たすために、ReaR (Relax-and-Recover) ツールの使用を推奨します。

1.10.1. ReaR と使用可能なタスク

ReaR は、完全なレスキューシステムの作成を実現する障害復旧およびシステム移行ユーティリティーです。デフォルトでは、このレスキューシステムは、ストレージレイアウトとブートローダーのみを復元し、実際のユーザーおよびシステムファイルは復元しません。

さらに、バックアップソフトウェアにより、障害復旧向けに ReaR を統合できます。

ReaR を使用すると、以下のタスクを実行できます。

  • 新規ハードウェア上でレスキューシステムを起動する
  • オリジナルのストレージレイアウトを複製する
  • ユーザーおよびシステムファイルを復元する

1.10.2. ReaR のインストールおよび設定のクイックスタート

ReaR をインストールするには、root ユーザーになり、以下のコマンドを実行します。

~]# yum install rear genisoimage syslinux

/etc/rear/local.conf ファイルの設定を使用して、ReaR を設定します。

1.10.3. ReaR を使用したレスキューシステム作成のクイックスタート

レスキューシステムを作成するには、root ユーザーになり、以下のコマンドを実行します。

~]# rear mkrescue

1.10.4. バックアップソフトウェアを使用して ReaR を設定するクイックスタート

ReaR には、NETFS と呼ばれる、完全に統合された組み込みまたは内部のバックアップメソッドが含まれます。

ReaR が内部のバックアップメソッドを使用するように設定するには、/etc/rear/local.conf ファイルに以下の行を追加します。

BACKUP=NETFS
BACKUP_URL=backup location

/etc/rear/local.conf に以下の行を追加すると、新規バックアップの作成時にこれまでのバックアップアーカイブを維持しておくように ReaR を設定できます。

NETFS_KEEP_OLD_BACKUP_COPY=y

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

BACKUP_TYPE=incremental

1.11. 問題のトラブルシューティング時にログファイルの使用

問題をトラブルシューティングする際、オペレーティングシステムに関する様々な情報とメッセージが含まれるログファイルを利用できます。Red Hat Enterprise Linux におけるロギングシステムは、組み込みの syslog プロトコルに基づいています。特定のプログラムがこのシステムを使用してイベントを記録し、ログファイルに分類します。これは、オペレーティングシステムの監査および様々な問題のトラブルシューティングに役立ちます。

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

syslog メッセージは、2 つのサービスで処理されます。

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

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

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

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

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

syslog メッセージは、含まれるメッセージやログの種類に応じて、/var/log ディレクトリー配下の様々なサブディレクトリーに保存されます。

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

1.11.2.1. RHEL 8 Web コンソールでログファイルの管理

Web コンソールでログファイルを調べる場合は Logs オプションを使用します。

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

cs getting started logs new

1.12. Red Hat サポートの利用

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

このセクションでは、以下について説明します。

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

Red Hat カスタマーポータル を使用すると、以下のことができます。

  • サポートケースの作成
  • Red Hat 専門スタッフとのライブチャット
  • 電話または電子メールによる Red Hat 専門スタッフへの問い合わせ

Red Hat カスタマーポータルには、https://access.redhat.com からアクセスしてください。

1.12.2. SOS レポートを使用した問題のトラブルシューティング

SOS レポート は設定の詳細、システム情報、診断情報を Red Hat Enterprise Linux システムから収集します。サポートケースを作成する際にその SOS レポートを添付してください。

SOS レポート は、sos パッケージで提供されています。これは、Red Hat Enterprise Linux のデフォルトの最小インストールでは提供されません。

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

~]# yum install sos

SOS レポート を生成するには、以下のコマンドを実行します。

~]# sosreport

サポートケースに sos レポート を添付する方法は、Red Hat ナレッジベースの記事「How can I attach a file to a Red Hat support case?」を参照してください。sos レポート を添付すると、サポートケース番号の入力を促すプロンプトが表示される点に注意してください。

SOS レポート の詳細は、Red Hat ナレッジベースの記事「Red Hat Enterprise Linux 4.6 以降における sosreport の役割と取得方法」を参照してください。

第2章 yum を使用したソフトウェアのインストール

2.1. Red Hat Enterprise Linux 8 におけるソフトウェアのインストールの概要

Red Hat Enterprise Linux 8 では、ソフトウェアのインストールは、新しいバージョンの YUM ツールで行います。これは、DNF テクノロジーに基づいています。

YUM ベースの DNF には、Red Hat Enterprise Linux 7 で使用されている以前の YUM v3 に比べて、以下の点が優れています。

  • パフォーマンスの向上
  • 利用できる新機能。モジュール式のコンテンツを管理するために最も重要なサポート
  • ツーリングと統合するために適切に設計され、安定した API

新しい YUM ツールと、以前のバージョンである Red Hat Enterprise Linux 7 の YUM v3 の詳細な相違点は、『Changes in DNF CLI compared to YUM』 を参照してください。

注記

このツールは、アップストリームでは、DNF と呼ばれています。そのため、Red Hat Enterprise Linux 8 の新しい YUM ツールが返す出力結果には DNF と書かれており、アップストリームのドキュメントでは、これが DNF とみなされます。

ソフトウェアをインストールするには、Red Hat Enterprise Linux 7 と同じ yum コマンドとオプションを使用できます。

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

YUM v3 が提供するレガシーの Python API は利用できなくなりました。代わりに、使用しているプラグインおよびスクリプトを、安定し、完全に対応している、新しい DNF Python API に移行することが推奨されます。DNF Python APIhttps://dnf.readthedocs.io/en/latest/api.html から利用できます。

また、Red Hat Enterprise Linux 8 では、新しい Libdnf API である Libdnf C API および Libdnf Python API が利用できます。新しい Libdnf API は現在安定していないため、おそらく Red Hat Enterprise Linux 8 ライフサイクル中に変更します。

2.2. yum 機能の概要

yum は、Red Hat のパッケージマネージャーです。yum を使用すれば、利用可能なパッケージ情報に関するクエリー、リポジトリーからのパッケージのフェッチ、パッケージのインストールおよびアンインストール、さらには利用可能な最新バージョンへのシステム全体の更新が可能です。yum は、パッケージの更新、インストール、削除を実行しているパッケージで依存関係の自動解決を行います。そのため、利用可能なすべての依存パッケージを自動的に決定、フェッチ、インストールできます。

yum は、新たに追加されたリポジトリー、または パッケージソース で設定でき、その機能を強化または拡張するプラグインを多数提供します。yum を使用すれば、パッケージ管理が簡単に行えます。

重要

yum は、すべてのパッケージリポジトリー (パッケージソース)、または個々のリポジトリーに対して有効になっている GPG 署名のパッケージにおける署名検証である Gnu Privacy Guard (GPG) (GnuPG とも呼ばれる) を有効にすることで、安全なパッケージ管理を提供します。

yum を使用すると、他のマシンへダウンロードし、インストールを行う RPM パッケージでリポジトリーを設定できます。可能な場合、yum は複数のパッケージおよびメタデータの 並行ダウンロード を使用して、ダウンロードのスピードを高めます。

注記

yum を使用して、システムへのパッケージのインストール、アップデート、または削除を行うにはスーパーユーザー権限が必要になります。ここに示す例では、su コマンドまたは sudo コマンドのいずれかを使用して、すでにスーパーユーザー権限を取得していることが前提となります。

2.3. 特定のタスクに yum の使用

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

2.3.1. パッケージの確認と更新

yum を使用すると、お使いのシステムに適用される更新があるかどうかをチェックできます。更新が必要なパッケージを一覧表示してこれらを一度に更新したり、パッケージを個別に選択して更新したりできます。

2.3.1.1. 更新の確認

使用しているシステムに利用可能な更新があるインストール済みのパッケージを確認するには、以下のコマンドを実行します。

yum check-update

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

  • パッケージの名前
  • パッケージがどの CPU アーキテクチャーを対象としてビルドされたか
  • インストールする更新パッケージのバージョン
  • 更新パッケージのリリース
  • ビルドバージョン (z-stream 更新として追加)
  • 更新パッケージが置かれているリポジトリー
2.3.1.1.1. パッケージの更新

1 回に更新するパッケージ数を 1 つ、複数、または全てのパッケージから選択できます。更新するパッケージの依存関係またはパッケージに利用可能な更新がある場合は、併せて更新されます。

2.3.1.1.1.1. 単一パッケージの更新

1 つのパッケージを更新するには、root で以下のコマンドを実行します。

yum update package_name
重要

yum は、 yum update コマンドまたは yum install コマンドを使用してカーネルの更新を適用しているかどうかに関わらず、新しいカーネルを常に インストール します。

一方、RPM を使用する場合は、現在のカーネルを 置き換える rpm -u kernel ではなく、新しいカーネルをインストールする rpm -i kernel コマンドを使用することが重要です。

2.3.1.1.1.2. パッケージグループの更新

パッケージグループを更新するには、root で以下のコマンドを実行します。

yum group update group_name

ここでは、group_name を、更新するパッケージグループに置き換えます。パッケージグループの詳細は 「パッケージグループでの作業」 を参照してください。

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

パッケージとその依存関係をすべて更新するには、引数なしで yum update コマンドを実行します。

yum update

2.3.2. パッケージでの作業

yum では、パッケージの検索、パッケージ情報の表示、パッケージのインストールおよび削除など、ソフトウェアパッケージの完全な操作が可能です。

2.3.2.1. パッケージの検索

以下のコマンドを使用すると、全パッケージの名前、詳細、サマリーを検索できます。

yum search term...

term を、検索するパッケージ名に置き換えます。

yum search コマンドは、パッケージ名は分からないものの、関連用語を知っている場合にパッケージを検索する際に役立ちます。デフォルトでは、yum search はパッケージ名とサマリーを返すため、検索には時間がかかりません。詳細情報を検索する場合は yum search all を使用しますが、この場合は時間がかかります。

2.3.2.1.1. 結果のフィルタリング

yum の全 list コマンドでは、1 つ以上の glob 表現 を引数として追加することで、結果をフィルタリングできます。glob 表現は、1 つ以上のワイルドカード文字 * (任意の文字サブセットに拡張) および ? (任意の 1 文字に拡張) を含む通常の文字列です。

yum コマンドに glob 表現を引数として渡す場合には、glob 表現をエスケープする点に注意してください。これを行わないと、bash シェルはこの表現を パス名の展開 と解釈してしまい、glob と適合する現在のディレクトリーの全ファイルを yum に渡す可能性があります。確実に glob 表現を yum に渡すには、以下のいずれかの方法で行います。

  • ワイルドカード文字の前にバックスラッシュ記号を入力して、ワイルドカード文字をエスケープする
  • glob 表現全体を二重引用符または単一引用符でくくる

2.3.2.2. パッケージの一覧表示

インストール済み および 利用可能なパッケージに関する情報を一覧表示するには、シェルプロンプトで次のコマンドを実行します。

yum list all

glob 表現に一致するインストール済み および 利用可能なパッケージを一覧表示するには、以下のコマンドを使用します。

yum list glob_expression...

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

yum list installed glob_expression...

有効なすべてのリポジトリーでインストール可能なパッケージを一覧表示するには、以下の形式のコマンドを使用します。

yum list available glob_expression...
2.3.2.2.1. リポジトリーの一覧表示

リポジトリーの ID、名前、お使いのシステムで 有効な 各リポジトリーのパッケージ数を一覧表示するには、以下のコマンドを実行します。

yum repolist

このようなリポジトリーの詳細情報を一覧表示するには、repoinfo コマンドを使用します。このコマンドを使用すると、一覧表示した各リポジトリーのファイル名、全体のサイズ、最終更新日、URL などの情報が表示されます。

yum repoinfo

有効および無効なリポジトリーの両方を表示するには、以下のコマンドを使用します。ステータスのコラムが出力リストに追加され、どのリポジトリーが有効になっているかが分かります。

yum repolist all

最初の引数を disabled にすることで、コマンドの出力を無効なリポジトリーに制限できます。また、リポジトリーの ID、名前、関連する glob 表現を引数として指定することもできます。引数と完全に一致するリポジトリー ID または名前がある場合は、enabled フィルターまたは disabled フィルターを通過しないリポジトリーであっても表示されることに注意してください。

2.3.2.2.2. パッケージ情報の表示

1 つ以上のパッケージに関する情報を表示するには、以下のコマンドを実行します (ここでは glob 表現も有効)。

yum info package_name...

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

2.3.2.2.3. パッケージのインストール

1 つのパッケージと、そのパッケージでインストールされていない依存関係をすべてインストールするには、root で、以下の形式のコマンドを入力します。

yum install package_name

複数パッケージを同時にインストールするには、その名前を引数として追加します。root で以下を実行します。

yum install package_name package_name...

AMD64 マシンや Intel 64 マシンなどの multilib システムにパッケージをインストールする場合は、パッケージ名に .arch を追加して、パッケージのアーキテクチャーを指定できます (ただし、有効なリポジトリーで利用可能な場合のみ)。

yum install package_name.arch

glob 表現を使用すると、名前が似ている複数のパッケージを迅速にインストールできます。root で以下のコマンドを実行します。

yum install glob_expression...

パッケージ名と glob 表現に加えて、yum install にはファイル名も追加できます。インストールするバイナリー名が分かっていて、パッケージ名が分からない場合は、yum install にパス名を付けて実行します。root で以下を実行します。

yum install /usr/sbin/named

yum はパッケージ一覧で検索を行い、/usr/sbin/named を提供するパッケージを探します。パッケージが存在すると、そのパッケージをインストールするかどうかを yum が確認します。

上記の例で分かるように、yum install コマンドは厳密に定義された引数を必要としません。さまざまな形式のパッケージ名や glob 表現を処理できるため、ユーザーによるインストールを容易にします。一方で、yum が入力を正確に分析するにはしばらく時間がかかります。指定するパッケージの数が多くなれば、それだけ時間がかかります。したがって、パッケージ検索を最適化するために、以下のコマンドを使用して引数の分析方法を明示的に定義できます。

yum install-n name
yum install-na name.architecture
yum install-nevra name-epoch:version-release.architecture

yum は、install-n コマンドでは name をパッケージの正確な名前として解釈します。また、install-na コマンドでは、後続の引数で、ピリオドを使用してパッケージ名とアーキテクチャーを指定し、install-nevra では、name-epoch:version-release.architecture の形で引数を指定していると yum は解釈します。同様に、削除するパッケージを検索する際に、yum remove-nyum remove-na、および yum remove-nevra を使用できます。

注記

named バイナリーを含むパッケージをインストールしたい場合に、このファイルがインストールされているディレクトリーが bin/sbin/ か分からない場合は、glob 表現で yum provides コマンドを実行します。

yum provides "*/file_name" は、file_name が含まれるパッケージを検索するのに便利です。

ダウンロード済みのパッケージを、システム上のローカルディレクトリーからインストールするには、以下のコマンドを使用します。

yum install path

path を、インストールするパッケージのパスに置き換えます。

または、yum localinstall コマンドを使用して、前に -nload を指定したパッケージを、ローカルディレクトリーからインストールできます。

2.3.2.2.4. パッケージの削除

特定のパッケージと、そのパッケージの依存関係パッケージをアンインストールをするには、root で以下のコマンドを実行します。

yum remove package_name...

コマンドに複数のパッケージ名を追加して、一度に複数のパッケージを削除するには、以下を行います。

install と同じように、remove では、以下の引数を使用できます。

  • パッケージ名
  • glob 表現
  • ファイル一覧
  • パッケージが提供する機能
警告

yum では、依存するパッケージを削除しなければパッケージを削除することはできません。

2.3.3. パッケージグループでの作業

パッケージグループは、たとえば システムツールサウンドとビデオ などの共通の目的でサービスを行うパッケージの集合です。パッケージグループをインストールすると、依存パッケージもプルされるので、時間が大幅に短縮できます。yum groups コマンドは、yum のパッケージグループに作用するすべての操作をカバーするトップレベルのコマンドです。

2.3.3.1. パッケージグループの一覧表示

summary オプションは、以下の数を表示するのに使用できます。

  • インストールされているグループ
  • 利用可能なグループ
  • 利用可能な環境変数
  • インストールされ、利用可能な言語グループ
yum groups summary

yum リポジトリーのパッケージグループを一覧表示するには、list オプションを追加します。コマンドの出力は、グループ名でフィルターを設定できます。

yum group list glob_expression...

このコマンドで使用できる任意の引数には、たとえば次のようなものがあります。hidden はユーザー表示可能とマークされていないグループも一覧表示し、ids はグループ ID を表示します。また、languageenvironmentinstalledavailable などのオプションを追加して、出力を特定のグループタイプに制限することもできます。

特定のグループに含まれている必須およびオプションのパッケージを一覧表示するには、以下のコマンドを使用します。

yum group info glob_expression...
注記

パッケージグループには、@ というマークを付けることができます。yum group listinfoinstall、または remove を使用する場合は、@group_name で、パッケージグループまたは環境グループを指定してください。

2.3.3.2. パッケージグループのインストール

パッケージグループにはそれぞれ、名前とグループ ID (groupid) があります。パッケージグループの名前とグループ ID (括弧内に表示される) を一覧表示するには、以下のコマンドを入力します。

yum group list ids

パッケージグループをインストールするには、group install コマンドに正式なグループ名 (groupid は含めない) を渡します。root で以下のコマンドを入力します。

yum group install group_name

groupid を使用してインストールすることもできます。root で、以下のコマンドを実行します。

yum group install groupid

groupid または引用付きグループ名の先頭に @ 記号を追加して、install コマンドに渡すことで、group install と同じように yum を実行できます。root で以下のコマンドを実行します。

yum install @group

group を、groupid または引用符で囲んだグループ名に置き換えます。同様に、環境グループに置き換えることもできます。

yum install @group

2.3.3.3. パッケージグループの削除

install 構文に類似した構文で、パッケージグループ名またはその ID を使用してパッケージグループを削除できます。root で以下のコマンドを入力します。

yum group remove group_name
yum group remove groupid

また、groupid または引用付き名前の先頭に @ 記号を追加して、remove コマンドに渡すことで、group remove と同じように yum を実行できます。root で以下のコマンドを実行します。

yum remove @group

group を、groupid または引用符で囲んだグループ名に置き換えます。同様に、環境グループに置き換えることもできます。

yum remove @group

2.4. トランザクション履歴の活用

yum history コマンドを使用すると、yum のトランザクションのタイムライン、トランザクションの発生日時、影響を受けたパッケージ数、トランザクション成功の有無、RPM データベースがトランザクション間で変更されたかどうかといった情報を確認できます。さらに、このコマンドを使用すると、特定のトランザクションを元に戻す、またはやり直すことが可能です。履歴データはすべて、/var/lib/yum/history/ ディレクトリーの history DB に保存されます。

2.4.1. トランザクションの一覧表示

最近発生した 20 件のトランザクションを一覧表示するには、root で引数なしで yum history を実行するか、シェルプロンプトで以下を実行します。

yum history list

特定のトランザクションを詳しく調べる場合は、root で以下のコマンドを実行します。

yum history info id...

ここでの id 引数は、トランザクションの ID を表します。この引数は任意ですが、引数を指定しないと、yum が最後のトランザクションを使用します。

2.4.2. トランザクションを元に戻す/繰り返す

トランザクション履歴の確認以外に、yum history コマンドは選択したトランザクションを元に戻す、または繰り返す方法を提供します。トランザクションを元に戻すには、root で次のコマンドを実行します。

yum history undo id

特定のトランザクションを繰り返すには、root で次のコマンドを実行します。

yum history redo id

どちらのコマンドでも last キーワードを使用して、最新のトランザクションを元に戻す、または繰り返すことができます。

yum history undo コマンドおよび yum history redo コマンドのどちらも、トランザクション中に実行されたステップを元に戻す、または繰り返すだけである点に注意してください。このトランザクションにより新しいパッケージがインストールされた場合に、yum history undo コマンドを実行すると、今回インストールしたパッケージがアンインストールされます。逆に、このトランザクションでパッケージがアンインストールされた場合は、このコマンドにより再度インストールされます。またこのコマンドは、(古いパッケージが引き続き利用可能な場合に)、更新済みパッケージをすべて以前のバージョンにダウングレードする試みも行います。

2.5. yum と yum リポジトリーの設定

yum および関連ユーティリティーの設定情報は /etc/yum.conf ファイルにあります。このファイルには、必須の [main] セクションが 1 つあり、ここで全体に影響を与える yum オプションを設定できます。また、[repository] セクションを 1 つ以上追加して、リポジトリー固有のオプションを設定することもできます。ただし、/etc/yum.repos.d/ ディレクトリーにある、新規または既存の .repo ファイルで個々のリポジトリーを定義することが推奨されます。/etc/yum.conf ファイルの各 [repository] セクションで定義した値は、[main] セクションに設定した値をオーバーライドします。

本セクションでは、以下の方法を紹介します。

  • /etc/yum.conf 設定ファイルの [main] セクションを編集して、yum のグローバルオプションを設定する方法
  • /etc/yum.repos.d/ ディレクトリーの /etc/yum.conf ファイルおよび .repo ファイルの [repository] セクションを編集して、個々のレポジトリーにオプションを設定する方法
  • コマンドラインで yum リポジトリーを追加、有効、無効にする方法

2.5.1. [main] オプションの設定

/etc/yum.conf 設定ファイルには、[main] セクションが 1 つだけ含まれます。本セクションにあるキー値ペアの中には、yum の動作に影響を与えるものもあれば、yum がリポジトリーを処理する方法に影響を与えるものもあります。

/etc/yum.conf[main] セクションの下に多くの情報を追加できます。

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

2.5.2. [repository] オプションの設定

[repository] セクションでは、個別の yum リポジトリーを定義できます。ここで repository は、 my_personal_repo (スペースは使用不可) などの一意のリポジトリー ID になります。競合を回避するために、カスタムリポジトリーには、Red Hat リポジトリーで使用されている名前を使用しないでください。

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

2.5.3. 現行設定の表示

yum グローバルオプションの現在の値 (つまり /etc/yum.conf ファイルの [main] セクションで指定しているオプション) を表示するには、コマンドラインでオプションを付けずに yum-config-manager コマンドを実行します。

yum-config-manager

2.5.4. yum リポジトリーの追加、有効化、および無効化

「[repository] オプションの設定」 では、yum リポジトリーの定義に使用可能なさまざまなオプションを説明しました。本セクションでは、yum-config-manager コマンドを使用してリポジトリーを追加、もしくは有効または無効にする方法を説明します。

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

新しいリポジトリーを定義するには、[repository] セクションを、/etc/yum.conf ファイルか、/etc/yum.repos.d/ ディレクトリーの .repo ファイルに追加します。このディレクトリーで .repo ファイル拡張子が付いたすべてのファイルを、yum が読み取ります。リポジトリーは、/etc/yum.conf ではなく、ここに定義することが推奨されます。

警告

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

Yum リポジトリーは、一般的に .repo ファイルを提供します。システムにこのようなリポジトリーを追加して有効にするには、root で以下のコマンドを実行します。

yum-config-manager --add-repo repository_url

ここでの repository_url は、.repo ファイルへのリンクになります。

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

特定のリポジトリーを有効にするには、root で以下のコマンドを入力します。

yum-config-manager --enable repository...

ここでの repository は、個々のリポジトリー ID です (yum repolist all を実行すると、利用可能なリポジトリー ID の一覧を確認できます)。

yum リポジトリーの無効化

yum リポジトリーを無効にするには、root で以下のコマンドを実行します。

yum-config-manager --disable repository...

ここでの repository は、個々のリポジトリー ID です (yum repolist all を実行すると、利用可能なリポジトリー ID の一覧を確認できます)。

2.6. yum プラグインの使用

Yum は、その操作を拡張し、強化するプラグインを提供します。特定のプラグインはデフォルトでインストールされています。yum コマンドを呼び出すたびに、読み込まれ、アクティブになっているプラグインがあれば Yum がそれを通知します。

2.6.1. yum プラグインを有効、設定、および無効にする方法

yum プラグインを有効にする場合は、/etc/yum.conf[main] セクションに plugins= で始まる行を追加し、その値を 1 にします。

plugins=1

すべてのプラグインを無効にするには、この行を plugins=0 に変更します。

重要

一部のプラグインは重要な yum サービスを提供するため、すべてのプラグインを無効にすることは推奨されません。その中でも product-id プラグインおよび subscription-manager プラグインは、証明書ベースの Content Delivery Network (CDN) への対応に必要です。プラグイン全体を無効にすることは簡単にできますが、通常は yum に潜在的な問題があると判断された場合に限り使用することが推奨されます。

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

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

/etc/yum.confenabled=0 を設定してすべてのプラグインを無効にすると、すべてのプラグインは、個々の設定ファイルで有効かどうかに関わらず無効になります。

1 つの yum コマンドで yum プラグインをすべて無効にする場合は、--noplugins オプションを使用します。

1 つの yum コマンドに、1 つ以上の yum プラグインを無効にする場合は、そのコマンドに --disableplugin=plugin_name オプションを追加します。

2.7. 関連資料

以下の資料は、YUM に関するその他の情報を提供します。

2.7.1. インストールされているドキュメント

  • yum(8) - yum コマンドラインユーティリティーの man ページでは、サポートされるオプションとコマンドの完全なリストを提供します。
  • yum.conf(5) - man ページの yum.conf では、利用できる yum 設定オプションを説明します。

2.7.2. オンラインのドキュメント

第3章 systemd によるサービス管理

3.1. systemd の概要

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

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

表3.1 systemd unit ファイルの場所

ディレクトリー説明

/usr/lib/systemd/system/

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

/run/systemd/system/

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

/etc/systemd/system/

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

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

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

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

表3.2 利用可能な systemd unit タイプ

Unit タイプファイル拡張子説明

Service unit

.service

システムサービス

Target unit

.target

systemd unit のグループ

Automount unit

.automount

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

Device unit

.device

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

Mount unit

.mount

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

Path unit

.path

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

Scope unit

.scope

外部作成のプロセス

Slice unit

.slice

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

Socket unit

.socket

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

Swap unit

.swap

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

Timer unit

.timer

systemd タイマー

system.conf で、デフォルトの systemd 設定の上書き

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

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

DefaultTimeoutStartSec=required value

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

3.1.1. 主な特長

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

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

    systemd は、ソケットベースの有効化に ソケットユニット を使用します。

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

3.1.2. 互換性の変更点

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

  • Systemd のランレベルのサポートは限定的なものです。ランレベルに直接マッピング可能なターゲットユニットを数多く提供し、互換性のために以前の runlevel コマンドで配布されます。ただし、systemd ターゲットのすべてがランレベルに直接マッピング可能な訳ではないため、このコマンドが不明なランレベルを示す N を返す場合もあります。可能な場合は、runlevel コマンドの使用を避けることが推奨されます。
    systemd ターゲットの詳細と、ランレベルとの比較は 「systemd ターゲットでの作業」 を参照してください。
  • systemctl ユーティリティーは、カスタマイズされたコマンドをサポートしません。SysV init スクリプトでは、startstopstatus といった標準のコマンドのほかに、任意のコマンドを実装して多くの機能を提供できます。たとえば、iptables の init スクリプトは、panic コマンドで実行できます。これにより、パニックモードが即座に有効になり、システムを再設定して受信パケットおよび送信パケットをすべて切断します。これは systemd ではサポートされておらず、systemctl は文書化されたコマンドのみ受け付けます。

    systemctl ユーティリティー、および以前の service ユーティリティーとの比較は 表3.3「service ユーティリティーと systemctl の比較」 を参照してください。

  • systemctl ユーティリティーは、systemd が開始していないとサービスとは通信しません。systemd がシステムサービスを開始すると、メインプロセスの ID を保存して、メインプロセスを追跡します。すると、systemctl ユーティリティーはこの PID を使用してクエリーを行い、サービスを管理します。このため、ユーザーがコマンドラインで特定のデーモンを直接開始すると、systemctl が最新の状態を判断したり、これを停止したりできません。
  • Systemd が停止するのは、実行中のサービスのみです。Red Hat Enterprise Linux 6 以前のリリースでは、シャットダウンシーケンスが開始すると、/etc/rc0.d/ ディレクトリーにあるシンボリックリンクを使用して、利用可能なシステムサービスをそのステータスに関係なくすべて停止していました。systemd では、シャットダウン時に停止するのは、実行中のサービスのみになります。
  • システムサービスは、標準の入力ストリームからは読み取れません。systemd がサービスを開始すると、標準入力を /dev/null に接続し、ユーザーとのインタラクションを防ぎます。
  • システムサービスは、開始したユーザーやそのセッションから、(環境変数 HOMEPATH などの) コンテキストを継承しません。各サービスは、クリーンな実行コンテキストで実行します。
  • SysV init スクリプトを読み込む際に、systemd は Linux Standard Base (LSB) ヘッダーにエンコードされている依存関係情報を読み取り、ランタイム時に解釈します。
  • サービスユニット上のすべての操作は 5 分間でタイムアウトするようにデフォルト設定になっており、サービスの故障でシステムがフリーズすることを防ぎます。この値は initscript から生成されるサービス用にハードコーディングされ、変更することができません。ただし、個別の設定ファイルを使用してサービス別にタイムアウト値を長くできます。例3.20「タイムアウト制限の変更」 を参照してください。

systemd で導入された互換性の変更点に関する詳細なリストは、Red Hat Enterprise Linux 7 の『Migration Planning Guide』を参照してください。

3.2. システムサービスの管理

以前のバージョンの Red Hat Enterprise Linux は、SysV init または Upstart で配布されており、/etc/rc.d/init.d/ ディレクトリーにある init スクリプト を使用していました。この init スクリプトは通常の Bash で書かれており、システム管理者がシステムの状態とシステム内のデーモンを管理できるようになっていました。Red Hat Enterprise Linux 7 では、この init スクリプトは、サービスユニット に代わっています。

サービスユニットは、ファイル拡張子 .service で終わり、init スクリプトと同様の役割を担います。システムサービスの表示、開始、停止、再開、有効化、無効化には、「service ユーティリティーと systemctl の比較」「chkconfig ユーティリティーと systemctl の比較」、および本セクションで説明されているように、systemctl コマンドを使用します。service コマンドおよび chkconfig コマンドは、引き続きシステムで利用可能になっており、期待通りに機能しますが、これらは互換性のために含まれており、使用は推奨されていません。

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

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

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

表3.4 chkconfig ユーティリティーと systemctl の比較

chkconfigsystemctl説明

chkconfig name on

systemctl enable name.service

サービスを有効にします。

chkconfig name off

systemctl disable name.service

サービスを無効にします。

chkconfig --list name

systemctl status name.service

systemctl is-enabled name.service

サービスが有効かどうかを確認します。

chkconfig --list

systemctl list-unit-files --type service

サービスを一覧表示し、各サービスが有効かどうかを確認します。

chkconfig --list

systemctl list-dependencies --after

指定されたユニットの前に開始するよう命令されるサービスを一覧表示します。

chkconfig --list

systemctl list-dependencies --before

指定されたユニットの後に開始するように命令されるサービスを一覧表示します。

サービスユニットの指定

明確化を図るため、本セクションの残りの部分のコマンド例では、.service ファイル拡張子がついた完全なユニット名を使用します。例を示します。

~]# systemctl stop nfs-server.service

ただし、ファイル拡張子は省略することが可能で、その場合、systemctl は、引数がサービスユニットであることを想定します。以下のコマンドは、上記のコマンドと同等のものになります。

~]# systemctl stop nfs-server

また、ユニットによってはエイリアス名を持つものもあります。この名前はユニット名よりも短いことがあり、ユニット名の代わりとして使用できます。特定のユニットに使用可能なエイリアスを見つけるには、以下のコマンドを実行します。

~]# systemctl show nfs-server.service -p Names

chroot 環境における systemctl の挙動

chroot コマンドを使用して root ディレクトリーを変更すると、ほとんどの systemctl コマンドは、アクションの実行をすべて拒否します。なぜなら、systemd プロセスと、chroot コマンドを使用しているユーザーでは、ファイルシステムの見え方が異なるからです。このような状況は、systemctlキックスタート ファイルから呼び出されたときなどに発生します。

例外が、systemctl enablesystemctl disable などのユニットファイルコマンドです。このコマンドは、実行中のシステムを必要とせず実行中のプロセスに影響を与えませんが、ユニットファイルには影響を及ぼします。したがってこのようなコマンドは、chroot 環境であっても実行することが可能です。たとえば、/srv/website1/ ディレクトリー配下で、システムの httpd サービスを有効にするときは、以下のコマンドを使用します。

~]# chroot /srv/website1
~]# systemctl enable httpd.service
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service.

3.2.1. サービスの一覧表示

読み込み済みの最新サービスユニットの一覧を表示するには、シェルプロンプトで以下を実行します。

systemctl list-units --type service

各サービスのユニットファイルに対して、このコマンドは正式名 (UNIT) の後に、そのユニットファイルがロードされているかどうか (LOAD)、そのユニットファイルアクティベーションの状態の概要 (ACTIVE) および詳細 (SUB) な状態、簡単な説明 (DESCRIPTION) と示します。

デフォルトでは、systemctl list-units コマンドは、アクティブなユニットのみを表示します。状態に関係なく読み込み済みユニットをすべて表示する場合は、--all または -a コマンドラインオプションで以下のコマンドを実行します。

systemctl list-units --type service --all

また、利用可能なサービスユニットを一覧表示して、各ユニットが有効かどうかを確認できます。これには、以下のコマンドを実行します。

systemctl list-unit-files --type service

このコマンドにより、各サービスユニットの完全な名前 (UNIT FILE) と、サービスユニットが有効かどうか (STATE) が表示されます。個別のサービスユニットの状態を判断する方法は 「Displaying service status」 を参照してください。

例3.1 サービスの一覧表示

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

~]$ systemctl list-units --type service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
abrt-ccpp.service              loaded active exited  Install ABRT coredump hook
abrt-oops.service              loaded active running ABRT kernel log watcher
abrt-vmcore.service            loaded active exited  Harvest vmcores for ABRT
abrt-xorg.service              loaded active running ABRT Xorg log watcher
abrtd.service                  loaded active running ABRT Automated Bug Reporting Tool
…​
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
tog-pegasus.service            loaded active running OpenPegasus CIM Server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'

インストール済みのサービスユニットファイルを一覧表示して、そのユニットが有効かどうかを判断するには、以下コマンドを実行します。

~]$ systemctl list-unit-files --type service
UNIT FILE                                   STATE
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
…​
wpa_supplicant.service                      disabled
ypbind.service                              disabled

208 unit files listed.

3.2.2. サービスステータスの表示

システムサービスに対応するサービスユニットに関する詳細情報を表示するには、シェルプロンプトで以下を実行します。

systemctl status name.service

name を、確認するサービスユニット名 (gdm など) に置き換えます。このコマンドでは、選択したサービスユニット名の後に、その説明と、表3.5「利用可能なサービスユニットの情報」 にある 1 つ以上のフィールド、さらに root ユーザーが実行している場合は最新のログエントリーが表示されます。

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

フィールド説明

Loaded

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

Active

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

Main PID

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

Status

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

Process

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

CGroup

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

特定のサービスユニットが実行中かどうかだけを確認する場合は、以下のコマンドを実行します。

systemctl is-active name.service

同様に、特定のサービスユニットが有効かどうかを確認するには、以下のコマンドを実行します。

systemctl is-enabled name.service

systemctl is-active および systemctl is-enabled は両方とも、指定したサービスユニットが実行中または有効な場合に、0 の終了ステータスを返すことに注意してください。現在読み込み済みのサービスユニットの一覧を表示する方法は Listing services を参照してください。

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

GNOME Display Manager のサービスユニット名は gdm.service になります。このサービスユニットの現在のステータスを確認するには、シェルプロンプトで次のコマンドを実行します。

~]# systemctl status gdm.service
gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
   Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago
 Main PID: 1029 (gdm)
   CGroup: /system.slice/gdm.service
           ├─1029 /usr/sbin/gdm
           ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno…​
           └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r…​

Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.

例3.3 サービスの前に開始するサービスの表示

特定のサービスの前に開始するサービスを確認するには、シェルプロンプトで次のコマンドを実行します。

~]# systemctl list-dependencies --after gdm.service
gdm.service
├─dbus.socket
├─getty@tty1.service
├─livesys.service
├─plymouth-quit.service
├─system.slice
├─systemd-journald.socket
├─systemd-user-sessions.service
└─basic.target
[output truncated]

例3.4 サービスの後に開始するサービスの表示

特定のサービスの後に開始するサービスを確認するには、シェルプロンプトで次のコマンドを実行します。

~]# systemctl list-dependencies --before gdm.service
gdm.service
├─dracut-shutdown.service
├─graphical.target
│ ├─systemd-readahead-done.service
│ ├─systemd-readahead-done.timer
│ └─systemd-update-utmp-runlevel.service
└─shutdown.target
  ├─systemd-reboot.service
  └─final.target
    └─systemd-reboot.service

3.2.3. サービスの起動

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

systemctl start name.service

name を、開始するサービスユニット名 (たとえば、gdm) に置き換えます。このコマンドは、選択したサービスを現行セッションで開始します。システムの起動時にサービスユニットを開始するように設定する方法は 「Enabling a service」 を参照してください。特定のサービスユニットのステータスを判断する方法は 「Displaying service status」 を参照してください。

例3.5 サービスの起動

Apache HTTP サーバー用のサービスユニットは httpd.service です。サービスユニットをアクティブにし、現行セッションで httpd デーモンを起動するには、root で以下のコマンドを実行します。

~]# systemctl start httpd.service

3.2.4. サービスの停止

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

systemctl stop name.service

name を、停止するサービスユニット名 (たとえば bluetooth) に置き換えます。このコマンドは、選択したサービスユニットを現行セッションで停止します。システムの起動時にサービスユニットを無効にし、開始しないようにする方法は「Disabling a service」を参照してください。特定のサービスユニットの状態を確認する方法は「Displaying service status」を参照してください。

例3.6 サービスの停止

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

~]# systemctl stop bluetooth.service

3.2.5. サービスの再開

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

systemctl restart name.service

name を、再開するサービスユニット名 (たとえば、httpd) に置き換えます。このコマンドは、選択したサービスユニットを現行セッションで停止し、即座に再起動します。重要なのは、選択したサービスユニットが実行中でないと、このコマンドがそのサービスユニットを起動するということです。対応するサービスがすでに実行中の場合にのみ、サービスユニットを再起動するように systemd に設定するには、root で以下のコマンドを実行します。

systemctl try-restart name.service

システムサービスによっては、サービスの実行を中断することなく設定の再読み込みが可能です。これを実行するには、root で次のコマンドを実行します。

systemctl reload name.service

システムサービスがこの機能をサポートしない場合は、このコマンドが無視されることに注意してください。代わりに、systemctl コマンドでは、この機能をサポートしないサービスを再起動する reload-or-restart コマンドおよび reload-or-try-restart コマンドもサポートします。サービスユニットのステータスを確認する方法は 「サービスステータスの表示」を参照してください。

例3.7 サービスの再開

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

~]# systemctl reload httpd.service

3.2.6. サービスの有効化

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

systemctl enable name.service

name を、有効にするサービスユニット名 (httpd など) に置き換えます。このコマンドは、選択したサービスユニットの[Install] セクションを読み取り、/etc/systemd/system/ ディレクトリーおよびそのサブディレクトリーにある /usr/lib/systemd/system/name.service ファイルへの適切なシンボリックリンクを作成します。ただし、このコマンドは既存のリンクを上書きしません。シンボリックリンクが確実に再度作成されるようにするには、root で以下のコマンドを実行します。

systemctl reenable name.service

このコマンドは、選択したサービスユニットを無効にし、即座に再度有効にします。システムの起動時に特定のサービスユニットが有効になるかどうかを確認する方法は 「Displaying service status」 を参照してください。現行セッションでサービスを開始する方法は 「Starting a service」 を参照してください。

例3.8 サービスの有効化

システムの起動時に Apache HTTP Server が自動的に開始するように設定するには、root で以下のコマンドを実行します。

~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

3.2.7. サービスの無効化

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

systemctl disable name.service

name を、無効にするサービスユニット名 (bluetooth など) に置き換えます。このコマンドは、選択したサービスユニットの [Install] セクションを読み取り、/etc/systemd/system/ ディレクトリーおよびそのサブディレクトリーから、/usr/lib/systemd/system/name.service ファイルへの適切なシンボリックリンクを削除します。さらに、サービスユニットにマスクをして、手動で開始したり、別のサービスがこれを開始することを防いだりできます。これを実行するには、root で以下のコマンドを実行します。

systemctl mask name.service

このコマンドにより、/etc/systemd/system/name.service ファイルを、/dev/null へのシンボリックリンクに置き換え、実際のユニットファイルが systemd ファイルにアクセスできないようにします。この動作を元に戻してサービスユニットのマスクを解除するには、root で以下のコマンドを実行します。

systemctl unmask name.service

特定のサービスユニットがシステムの起動時に有効になるかどうかを確認する方法は「Displaying service status」を参照してください。現行セッションでサービスを停止する方法は「Stopping a service」を参照してください。

例3.9 サービスの無効化

例3.6「サービスの停止」 では、現行セッションで bluetooth.service ユニットを停止する方法を説明しました。このサービスユニットが起動時に開始しないようにするには、root で次のコマンドを実行します。

~]# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

3.2.8. 競合するサービスの起動

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

ユーザーが新しいサービスを起動しようとすると、systemd がすべての依存関係を自動的に解決します。これは、ユーザーに明示的に通知されることなく実行されるため注意が必要です。サービスが実行されているときに、負の依存関係を持つ別のサービスを起動しようとすると、実行しているサービスが自動的に停止します。

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

3.3. systemd ターゲットでの作業

以前のバージョンの Red Hat Enterprise Linux は、SysV init または Upstart で配布されており、特定モードのオペレーションを表す事前定義の ランレベル を実装していました。このランレベルは 0 から 6 までの数字で表され、システム管理者が各ランレベルを有効にしたときに実行されるシステムサービスが定義されていました。Red Hat Enterprise Linux 7 では、ランレベルの概念が systemd ターゲット に代わっています。

Systemd ターゲットは ターゲットユニット で表されます。ターゲットユニットは .target ファイル拡張子で終わり、その唯一の目的は依存関係の連鎖で他の systemd ユニットをグループ化することです。たとえば、グラフィカルセッションの開始に使用する graphical.target ユニットは、GNOME Display Manager (gdm.service) または Accounts Service (accounts-daemon.service) といったシステムサービスを開始するとともに、multi-user.target ユニットもアクティブにします。同様に、multi-user.target ユニットは、NetworkManager (NetworkManager.service)、D-Bus (dbus.service) といった、その他の必須システムサービスを開始し、basic.target という別のターゲットユニットをアクティブにします。

Red Hat Enterprise Linux 7 では、以前のシステムリリースの標準ランレベルと類似する定義済みターゲットが多数同梱されています。互換性目的で、このターゲットを SysV ランレベルに直接マッピングするエイリアスも提供されています。表3.6「SysV ランレベルと systemd ターゲットの比較」では、SysV ランレベルの完全なリストと、対応する systemd ターゲットが表示されています。

表3.6 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

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

systemd ターゲットを表示、変更、または設定するには、 表3.7「SysV init コマンドと systemctl の比較」 および以下のセクションの説明に従って systemctl ユーティリティーを使用します。runlevel および telinit の各コマンドは今も利用でき、期待どおりに機能しますが、このコマンドは互換性のために同梱されているため、なるべく使用しないでください。

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

古いコマンド新しいコマンド説明

runlevel

systemctl list-units --type target

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

telinit runlevel

systemctl isolate name.target

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

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

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

systemctl get-default

このコマンドは、/etc/systemd/system/default.target にあるシンボリックリンクを解決して、結果を表示します。

例3.10 デフォルトターゲットの表示

デフォルトのターゲットユニットを表示するには、以下のコマンドを実行します。

~]$ systemctl get-default
graphical.target

3.3.2. 現在のターゲットの表示

読み込み済みの現在のターゲットユニットの一覧を表示するには、シェルプロンプトで以下のコマンドを実行します。

systemctl list-units --type target

このコマンドを実行すると、各ターゲットユニットの正式名 (UNIT) の後に、そのユニットが読み込まれているかどうか (LOAD)、そのユニットファイルアクティベーションの状態の概要 (ACTIVE) および詳細 (SUB) な状態、簡単な説明 (DESCRIPTION) が表示されます。

デフォルトでは、systemctl list-units コマンドは、アクティブなユニットのみを表示します。状態に関係なく読み込み済みユニットをすべて表示する場合は、--all または -a コマンドラインオプションで以下のコマンドを実行します。

systemctl list-units --type target --all

例3.11 現在のターゲットの表示

現在読み込み済みのターゲットユニットの一覧を表示するには、以下のコマンドを実行します。

~]$ 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. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

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

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

systemctl set-default name.target

name を、デフォルトで使用するターゲットユニットの名前 (multi-user など) を置き換えます。このコマンドにより、/etc/systemd/system/default.target ファイルが、/usr/lib/systemd/system/name.target へのシンボリックリンクに置き換わります。name は、使用するターゲットユニットの名前になります。

例3.12 デフォルトターゲットの変更

デフォルトで multi-user.target ユニットを使用するようにシステムを設定するには、root で以下のコマンドを実行します。

~]# 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'

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

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

systemctl isolate name.target

name を、使用するターゲットユニットの名前 (multi-user など) に置き換えます。このコマンドは、name という名前のターゲットユニットと、その従属ユニットをすべて起動し、その他のユニットを直ちに停止します。

例3.13 現在のターゲットの変更

グラフィカルユーザーインターフェイスを無効にし、現行セッションで multi-user.target ユニットに変更するには、root で以下のコマンドを実行します。

~]# systemctl isolate multi-user.target

3.3.5. レスキューモードへの変更

レスキューモード は、便利なシングルユーザー環境を提供し、通常の起動プロセスを完了できない状況でのシステムの修復を可能にします。レスキューモードでは、システムはすべてのローカルファイルシステムのマウントと、いくつかの重要なシステムサービスの開始を試みますが、ネットワークインターフェースをアクティブにしたり、他のユーザーによるシステムへの同時ログインを許可したりすることはしません。レスキューモードでは、root パスワードが要求されます。

現在のターゲットを変更し、現行セッションでレスキューモードに入るには、root で次のコマンドを実行します。

systemctl rescue

このコマンドは systemctl isolate rescue.target と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。systemd がこのメッセージを送信しないようにするには、コマンドラインオプション --no-wall を付けてこのコマンドを実行します。

systemctl --no-wall rescue

緊急モードに入る方法は 「緊急モードへの変更」 を参照してください。

例3.14 レスキューモードへの変更

現行セッションでレスキューモードに入るには、root で以下のコマンドを実行します。

~]# 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!

3.3.6. 緊急モードへの変更

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

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

systemctl emergency

このコマンドは systemctl isolate emergency.target と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。systemd がこのメッセージを送信しないようにするには、コマンドラインオプション --no-wall を付けてこのコマンドを実行します。

systemctl --no-wall emergency

レスキューモードに入る方法は 「レスキューモードへの変更」 を参照してください。

例3.15 緊急モードへの変更

現在システムにログインしている全ユーザーにメッセージを送信せずに緊急モードに入るには、root で以下のコマンドを実行します。

~]# systemctl --no-wall emergency

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

Red Hat Enterprise Linux 7 では、systemctl ユーティリティーが、これまでのバージョンの Red Hat Enterprise Linux システムで使用されていた多くの電源管理コマンドに置き換わっています。表3.8「電源管理コマンドと systemctl の比較」 に表示されているコマンドは、互換性の理由から現在も利用することはできますが、可能な場合は systemctl の使用が推奨されます。

表3.8 電源管理コマンドと systemctl の比較

古いコマンド新しいコマンド説明

halt

systemctl halt

システムを停止します。

poweroff

systemctl poweroff

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

reboot

systemctl reboot

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

pm-suspend

systemctl suspend

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

pm-hibernate

systemctl hibernate

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

pm-suspend-hybrid

systemctl hybrid-sleep

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

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

systemctl ユーティリティーは、システムをシャットダウンするコマンドを提供します。ただし、従来の shutdown コマンドもサポートされます。shutdown コマンドは、systemctl ユーティリティーを呼び出してシャットダウンを実行しますが、time 引数もサポートするという利点があります。これは、計画メンテナンスにとりわけ役立ち、システムシャットダウンの予定に関する警告にユーザーが対応する時間をより長く確保できます。シャットダウンをキャンセルするオプションがあることも利点です。

systemctl コマンドの使用

システムをシャットダウンし、マシンの電源を切るには、root で次のコマンドを実行します。

systemctl poweroff

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

systemctl halt

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

systemctl --no-wall poweroff

shutdown コマンドの使用

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

shutdown --poweroff hh:mm

hh:mm は 24 時間形式の時刻となります。新たなログインを防ぐために、システムをシャットダウンする 5 分前に /run/nologin ファイルが作成されます。時間引数を使用する場合は、コマンドに任意のメッセージ wall message を付けることができます。

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

shutdown --halt +m

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

保留中のシャットダウンは、root で以下のコマンドを実行するとキャンセルできます。

shutdown -c

詳細なコマンドオプションは、man ページの shutdown(8) を参照してください。

3.4.2. システムの再起動

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

systemctl reboot

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

systemctl --no-wall reboot

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

システムをサスペンドするには、root で次のコマンドを実行します。

systemctl suspend

このコマンドは、システムの状態を RAM に保存し、RAM モジュール以外のほとんどのデバイスの電源を切ります。マシンの電源を戻すと、システムは再起動せずに RAM からその状態を復元します。システムの状態がハードディスクではなく RAM に保存されるので、システムのサスペンドモードから復元する場合は、休止状態からの復元と比べて大幅に速くなります。ただし、システムをサスペンドした状態は、停電に対して脆弱となります。

システムを休止状態にする方法は 「システムの休止状態」 を参照してください。

3.4.4. システムの休止状態

システムをハイバーネートにするには、root で次のコマンドを実行します。

systemctl hibernate

このコマンドは、システムの状態をハードディスクドライブに保存し、マシンの電源を切ります。マシンの電源を戻すと、システムは再起動せずに保存されたデータからその状態を復元します。システムの状態が RAM ではなくハードディスクに保存されるので、マシンが RAM モジュールに電力を維持する必要がありません。ただし、システムの休止状態から復元する場合は、サスペンドモードからの復元と比べて大幅に遅くなります。

システムを休止状態にしてサスペンドするには、root で次のコマンドを実行します。

systemctl hybrid-sleep

システムをサスペンドする方法は 「システムのサスペンド」 を参照してください。

3.5. systemd ユニットファイルでの作業

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

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

unit_name.type_extension

ここで、unit_name はユニットの名前を表し、type_extension はユニットタイプを特定します。ユニットファイルの詳細な一覧は 表3.2「利用可能な systemd unit タイプ」 を参照してください。たとえば、通常は、システムには sshd.service ユニットおよび sshd.socket ユニットがあります。

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

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

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

3.5.1. ユニットファイル構造の概要

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

  • [Unit] セクション- ユニットのタイプに依存しない一般的なオプションが含まれます。このセクションに含まれるオプションはユニットを説明し、ユニットの動作を指定し、他のユニットへの依存関係を設定します。[Unit] セクションで最もよく使用されるオプションの一覧は 表3.9「[Unit] セクションの重要なオプション」 を参照してください。
  • [Unit type] セクション - ユニットにタイプによる指定があれば、ユニットタイプにより命名されるセクションでグループ分けされます。たとえば、サービスユニットファイルには [Service] セクションが含まれます。
  • [Install] セクション - systemctl enable コマンドおよび disable コマンドでユニットをインストールした際の情報が含まれます。[Install] セクションの詳細は表3.11「[Install] セクションの重要なオプション」を参照してください。

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

オプション[a]説明

Description

ユニットの説明です。このテキストは、たとえば 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 で要件の依存関係も設定する場合、依存関係の並び順は指定する必要があります。これは、並び順と要件の依存関係が相互に依存していないためです。

表3.10 [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] セクションで設定できるオプションの詳細な一覧は、man ページの systemd.service(5) を参照してください。

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

オプション[a]説明

Alias

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

RequiredBy

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

WantedBy

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

Also

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

DefaultInstance

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

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

ユニット設定を微調整するのに使用できるさまざまなオプションがあります。以下の例は、システムにインストールされているサービスユニットの例を示しています。さらに、ユニットファイルのオプションは、「インスタンス化されたユニットの使用」に説明されているように、ユニットの動的な作成が可能な方法で定義できます。

例3.16 postfix.service ユニットファイル

次に、postfix パッケージで現在提供されている /usr/lib/systemd/system/postfix.service ユニットファイルの内容が続きます。

[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target

[Unit] セクションでは、サービスについて説明し、競合するユニットおよび並び順依存関係を指定します。[Service] では、カスタムスクリプトのシーケンスが、ユニットのアクティべーション時、停止時、および再読み込み時に実行するように指定します。EnvironmentFile は、サービスの環境変数が定義されるロケーションを参照し、PIDFile はサービスのメインプロセスの安定した PID を指定します。最後に、[Install] セクションはサービスに依存するユニットを一覧表示します。

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

ユニットファイルをゼロから作成するための複数のユースケースがあります。カスタムデーモンを実行したり、(「sshd サービスの 2 つ目のインスタンスの作成」に説明されているように) 一部の既存サービスの 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 で作成されます。その他の起動タイプは、表3.10「[Service] セクションの重要なオプション」 を参照してください。
    • WantedBy では、サービスを起動するターゲットを指定します。ターゲットは、従来のランレベルの代替と見なすことができます。詳細は 「systemd ターゲットでの作業」 を参照してください。
  4. root で以下のコマンドを実行すると、新しい name.service ファイルが存在することが systemd に通知します。

    systemctl daemon-reload
    
    systemctl start name.service
    警告

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

例3.17 emacs.service ファイルの作成

Emacs テキストエディターを使用する場合は、ファイルの編集時にプログラムの新規インスタンスを起動するよりも、バックグラウンドで実行する方がスピードが速いため便利です。以下の手順では、Emacs のユニットファイルを作成し、これをサービスのように処理する方法を説明します。

  1. /etc/systemd/system/ ディレクトリーにユニットファイルを作成し、ファイルパーミッションが正しいことを確認してください。root で以下のコマンドを実行します。

    ~]# touch /etc/systemd/system/emacs.service
    ~]# chmod 664 /etc/systemd/system/emacs.service
  2. 以下の内容をファイルに追加します。

    [Unit]
    Description=Emacs: the extensible, self-documenting text editor
    
    [Service]
    Type=forking
    ExecStart=/usr/bin/emacs --daemon
    ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
    Environment=SSH_AUTH_SOCK=%t/keyring/ssh
    Restart=always
    
    [Install]
    WantedBy=default.target

    上記の設定では、サービスの起動時に、/usr/bin/emacs 実行可能ファイルがデーモンモードで開始します。SSH_AUTH_SOCK 環境変数は、ランタイムディレクトリーを表す "%t" ユニット指定子で設定されます。また、このサービスは、emacs プロセスが予期せずに終了した場合はこれを再起動します。

  3. 以下のコマンドを実行して、設定の再読み込みを行い、カスタムサービスを起動します。

    ~]# systemctl daemon-reload
    ~]# systemctl start emacs.service

これでエディターは systemd サービスとして登録されるため、標準的な systemctl コマンドがすべて使用できます。たとえば、systemctl status emacs でエディターのステータスを表示したり、systemctl enable emacs でシステム起動時にエディターを自動的に起動したりできます。

例3.18 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

    systemctl status コマンドを使用して sshd-second.service が実行中かどうかを確認します。さらに、ポートをサービスに接続して、適切に有効になっているかどうかを確認します。

    ~]$ ssh -p 22220 user@server

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

カスタムユニットファイルの並び順および依存関係のターゲットを適切に選択する方法は、以下の Red Hat ナレッジベースの記事を参照してください。

ユニットファイルの並び順および依存関係に関する実例と追加情報は「Is there any useful information about writing unit files?」を参照してください。

systemd が開始するサービスへの制限の設定は、Red Hat ナレッジベースの記事 「RHEL 7 および systemd でサービスに制限を設定する 」 を参照してください。この制限は、サービスのユニットファイルで設定する必要があります。systemd は、/etc/security/limits.conf 設定ファイルおよび /etc/security/limits.d/*.conf 設定ファイルに設定した制限を無視する点に注意してください。このファイルに定義した制限は、ログインセッションの開始時に PAM により設定されますが、systemd が開始するデーモンは、PAM ログインセッションを使用しません。

3.5.3. 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 スクリプトはサンプルとして使用されます。作成される postfix ユニットは 例3.16「postfix.service ユニットファイル」 を参照してください。

サービス説明の検索

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

サービス依存関係の検索

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

表3.12 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

サービスのデフォルトターゲットの検索

#chkconfig で始まる行には 3 つの数値があります。最も重要な値は最初の数値で、サービスが起動するデフォルトのランレベルを示しています。ランレベルは、同等の systemd ターゲットに対応します。次に、そのターゲットを、ユニットファイルの [Install] セクションの WantedBy オプションに記述します。たとえば、postfix がランレベルの 2、3、4、および 5 で起動していた場合、これは multi-user.target および graphical.target に対応します。ただし、graphical.target は multiuser.target に依存するため、例3.16「postfix.service ユニットファイル」 の説明にあるように、両方を記述する必要はありません。また、LSB ヘッダーの #Default-Start 行および #Default-Stop 行に、デフォルト、および動作するべきでないランレベルの情報がある場合は、そちらも参照してください。

#chkconfig 行で指定した他の 2 つの値は、init スクリプトの起動およびシャットダウンの優先順位を表します。この値は、init スクリプトが読み込まれる場合は systemd によって解釈されますが、同等のユニットファイルはありません。

サービスで使用されるファイルの検索

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 は、事前に定義されたアクションのみをサポートしますが、オプションの ExecStartExecStartPreExecStartPostExecStop、および ExecReload でカスタムの実行ファイルを有効にできます、/usr/sbin/postfix はサポートスクリプトとともに、サービスの起動時に実行されます。postfix ユニットファイルは 例3.16「postfix.service ユニットファイル」 を参照してください。

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

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

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

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

ユニットのデフォルト設定に戻るには、/etc/systemd/system/ でカスタム作成した設定ファイルを削除します。システムを再起動せずにユニットファイルへの変更を適用するには、以下を実行します。

systemctl daemon-reload

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

init q

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

systemctl restart name.service
重要

SysV init スクリプトが処理しているサービスのプロパティ (依存関係やタイムアウトなど) を変更するときは、init スクリプト自体は変更しないでください。代わりに、「Extending the default unit configuration」「Overriding the default unit configuration」 にあるように、サービスの 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 と命名されるのはそのためです。

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

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

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

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

作成したディレクトリーに設定ファイルを作成します。ファイル名の接尾辞は .conf にする必要があることに注意してください。以下のコマンドを実行します。

touch /etc/systemd/system/name.service.d/config_name.conf

config_name を、設定ファイルの名前に置き換えます。このファイルは、通常のユニットファイル構造に基づくため、すべてのディレクティブは該当するセクションで指定する必要があります。「ユニットファイル構造の概要」 を参照してください。

たとえば、カスタムの依存性を追加するには、以下の内容で設定ファイルを作成します。

[Unit]
Requires=new_dependency
After=new_dependency

ここで、new_dependency は依存性としてマークが付けられるユニットを表します。次の例は、30 秒の遅延後のメインプロセス終了後にサービスを再起動する設定ファイルです。

[Service]
Restart=always
RestartSec=30

1 つのタスクだけを扱う簡単な設定ファイルを作成することが推奨されます。これにより、他のサービスの設定ディレクトリーに簡単に移動したり、リンクします。

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

systemctl daemon-reload
systemctl restart name.service

例3.19 httpd.service 設定の拡張

Apache サービスの起動時にカスタムシェルスクリプトが自動的に実行されるように httpd.service ユニットを変更するには、以下の手順で行います。まず、ディレクトリーおよびカスタム設定ファイルを作成します。

~]# mkdir /etc/systemd/system/httpd.service.d/
~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf

Apache で自動的に起動するスクリプトが /usr/local/bin/custom.sh にある場合は、以下のテキストを custom_script.conf ファイルに挿入します。

[Service]
ExecStartPost=/usr/local/bin/custom.sh

ユニットの変更を適用するには、以下を実行します。

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

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

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

ユニットファイルを提供するパッケージの更新後も変更を持続させるには、最初にファイルを /etc/systemd/system/ ディレクトリーにファイルをコピーします。それを行うには、root で以下のコマンドを実行します。

cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

name は、変更するサービスユニットの名前を表します。上記の構文はすべてのユニットタイプに適用されます。

コピーされたファイルをテキストエディターで開き、必要な変更を行います。ユニットの変更を適用するには、root で以下を実行します。

systemctl daemon-reload
systemctl restart name.service

例3.20 タイムアウト制限の変更

サービスごとにタイムアウト値を指定すると、正常に動作していないサービスによってシステムがフリーズすることを防ぐことができます。タイムアウト値を指定しないサービスには、通常のサービスの場合は 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 を変更します。

上書きされたユニットのモニタリング

上書きされたか、または変更されたユニットファイルの概要を表示するには、以下のコマンドを使用します。

systemd-delta

上記のコマンドを実行すると、以下のような出力になります。

[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service

--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always

 [Install]
 WantedBy=multi-user.target

[MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
[EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf

4 overridden configuration files found.

表3.13「systemd-delta の相違タイプ」 は、systemd-delta の出力で表示される上書きタイプを一覧表示します。ファイルが上書きされた場合は、デフォルトで systemd-delta が、diff コマンドの出力に似た変更の要約を表示します。

表3.13 systemd-delta の相違タイプ

タイプ説明

[MASKED]

マスクされたユニットファイルです。ユニットマスクの説明は 「サービスの無効化」 を参照してください。

[EQUIVALENT]

元のファイルを上書きしますが、コンテンツは変更されていないコピーです。通常はシンボリックリンクです。

[REDIRECTED]

別のファイルにリダイレクトされるファイルです。

[OVERRIDEN]

上書きされ、変更されたファイルです。

[EXTENDED]

/etc/systemd/system/unit.d/ ディレクトリーの .conf ファイルで拡張されているファイルです。

[UNCHANGED]

--type=unchanged オプションが使用される場合にのみ表示される、変更されていないファイルです。

システムの更新後に、systemd-delta を実行して、デフォルトユニットに対してカスタム設定で上書きした更新があるかどうかを確認できます。さらに、出力する更新を、特定のタイプに制限することもできます。たとえば、上書きされたユニットのみを表示するには、以下のコマンドを実行します。

systemd-delta --type=overridden

ユニットファイルを編集し、送信した変更でドロップインファイルを自動的に作成するには、以下のコマンドを使用します。

~]# systemctl edit unit_name.type_extension

オーバーライド、およびドロップインをすべて適用するユニット設定をダンプするには、以下のコマンドを使用します。

~]# systemctl cat unit_name.type_extension

unit_name.type_extension を、必要なユニット名と、そのタイプ (たとえば tuned.service) に置き換えます。

3.5.5. インスタンス化されたユニットの使用

ランタイム時に、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 が、最初に指定したサービスユニットを検索します。該当するユニットが見つからないと、「@」とタイプ接尾辞の間にある部分は無視され、getty@.service ファイルを検索し、そこから設定を読み取り、サービスを起動します。

ワイルドカード文字 (ユニット指定子 とも呼ばれる) をすべてのユニット設定ファイルで使用できます。ユニット指定子は、ランタイム時に特定のユニットパラメーターに置き換えて解釈されます。表3.14「重要なユニット指定子」 で、特にテンプレートユニットで役に立つユニット指定子の一覧を紹介します。

表3.14 重要なユニット指定子

ユニット指定子意味説明

%n

完全ユニット名

タイプ接尾辞を含む完全ユニット名を表します。%N には同じ意味がありますが、禁止文字を ASCII コードに置き換えます。

%p

接頭辞名

タイプ接尾辞が削除されたユニット名を表します。インスタンス化されたユニットの %p は、ユニット名の「@」文字の前の部分を表します。

%i

インスタンス名

インスタンス化されたユニット名の「@」文字およびタイプ接尾辞間の部分です。%I には同じ意味がありますが、禁止文字を ASCII コードにも置き換えます。

%H

ホスト名

ユニット設定が読み込まれる時点の実行中システムのホスト名を表します。

%t

ランタイムディレクトリー

ランタイムディレクトリーを表します。これは、root ユーザーの /run、または非特権ユーザー XDG_RUNTIME_DIR 変数になります。

ユニット指定子の詳細な一覧は、man ページの systemd.unit(5) を参照してください。

たとえば、 getty@.service テンプレートには以下のディレクティブが含まれます。

[Unit]
Description=Getty on %I
…​
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
…​

上記のテンプレートから getty@ttyA.service および getty@ttyB.service をインスタンス化する場合、Description= は Getty on ttyA および Getty on ttyB として解決されます。

3.6. 関連資料

systemd と、Red Hat Enterprise Linux での使用方法は、以下に挙げる資料を参照してください。

3.6.1. インストールされているドキュメント

  • systemctl(1) - systemctl コマンドラインユーティリティーの man ページでは、サポートされるオプションとコマンドの完全なリストが提供されます。
  • systemd(1) - systemd システムおよびサービスマネージャーの man ページでは、その概念に関する詳細情報が提供され、利用可能なコマンドラインオプションと環境変数、サポートされる設定ファイルとディレクトリー、認識されるシグナル、および利用可能なカーネルオプションが説明されています。
  • systemd-delta(1) - 拡張され、上書きされた設定ファイルの検索を可能にする systemd-delta ユーティリティーの man ページです。
  • systemd.directives(7) - systemd.directives という名前の man ページは、systemd ディレクティブの詳細が提供されます。
  • systemd.unit(5) - systemd.unit の man ページでは、systemd ユニットファイルの詳細情報と、利用可能なすべての設定オプションが説明されてます。
  • systemd.service(5) - systemd.service の man ページは、サービスユニットファイルの形式が紹介されています。
  • systemd.target(5) - systemd.target の man ページには、ターゲットユニットファイルの形式が説明されています。
  • systemd.kill(5) - systemd.kill の man ページでは、プロセスの強制終了手順の設定が説明されています。

3.6.2. オンラインのドキュメント

  • systemd ホームページ - このプロジェクトのホームページでは、systemd に関する詳細情報が提供されています。

3.7. 起動時間を短縮するための systemd の最適化

デフォルトで有効になっている systemd ユニットファイルの一覧があります。システムの起動時に、このようなユニットファイルで定義されているシステムサービスが自動的に実行し、システムの起動時間に影響を及ぼします。

このセクションでは、以下について説明します。

  • システムの起動パフォーマンスを調べるツール
  • systemd ユニットがデフォルトで無効になっている目的と、起動時間を短縮するために、このような systemd ユニットを安全に無効にする状況

3.7.1. システムの起動パフォーマンスの調査

システムブートのパフォーマンスを調べるためには、systemd-analyze コマンドを使用できます。このコマンドでは、多数のオプションが使用できますが、本セクションでは、起動時間を短縮するために、systemd の調整の点で重要になるものだけを説明します。

オプションの完全リストおよび詳細な説明は、man ページの systemd-analyze を参照してください。

前提条件

システムの起動時に調整するために、systemd を調べ始める前に、有効なサービスの一覧を表示することもできます。

~]$ systemctl list-unit-files --state=enabled
システム全体の起動時間の分析
手順
  • システムが最後に起動してからの時間に関する総合的な情報を表示するには、次のコマンドを実行します。
~]$ systemd-analyze
ユニットの初期化時間の分析
手順
  • 各 systemd ユニットの初期化時間の詳細を確認するには、次のコマンドを実行します。
~]$ systemd-analyze blame

この出力では、システムが最後に起動した時に初期化にかかった時間に応じて、ユニットが降順で表示されます。

重要なユニットの識別
手順
  • システムが最後に起動した時に、初期化に最も時間がかかったユニットを特定するには、次のコマンドを実行します。
~]$ systemd-analyze critical-chain

この出力では、起動に非常に時間がかかっているユニットが、赤字で強調表示されています。

図3.1 systemd-analyze critical-chain コマンドの出力

systemd analyze critical

3.7.2. 安全に無効にできるサービスを選択するためのガイド

システムの起動時に時間がかかっている場合は、デフォルトで起動時に有効になっているサービスの一部を無効にすることで、起動時間を短くできます。

このようなサービスを一覧表示するには、次のコマンドを実行します。

~]$ systemctl list-unit-files --state=enabled

サービスを無効にするには、次のコマンドを実行します。

~]# systemctl disable service_name

ただし、お使いのオペレーティングシステムが安全で、希望通りに機能できるように、特定のサービスは有効にしたままにしておく必要があります。

次の表は、安全に無効にできるサービスを選択するためのガイドとして使用できます。この表では、Red Hat Enterprise Linux 8 の最小インストールで、デフォルトで有効になっているすべてのサービスと、各サービスを安全に無効にできるかどうかを説明します。

その他にも、サービスを無効にできる状況と、そのサービスを無効にすべきではない理由を示しています。

表3.15 RHEL 8 の最小インストールで、デフォルトで有効になっているサービス

サービス名無効にすることはできますか?詳細情報

auditd.service

yes

auditd.service は、カーネルからの監査メッセージが必要ない場合に限り無効にします。auditd.service を無効にすると、/var/log/audit/audit.log ファイルが生成されないことに注意してください。これにより、ユーザーログイン、サービスの起動、パスワードの変更などの、一般的に確認されるアクションまたはレビューをさかのぼって確認することはできません。auditd には、カーネルの部分と、サービスそのものが含まれることに注意してください。systemctl disable auditd コマンドを実行すると、サービスを無効にするだけで、カーネル部分は無効にしません。システムの監査を完全に無効にするには、カーネルのコマンドラインに audit=0 と設定します。

autovt@.service

no

このサービスは、それが本当に必要な場合に限り実行されるため、無効にする必要はありません。

crond.service

yes

crond.service を無効にすると crontab からアイテムが実行しないことに注意してください。

dbus-org.fedoraproject.FirewallD1.service

yes

firewalld.service へのシンボリックリンク

dbus-org.freedesktop.NetworkManager.service

yes

NetworkManager.service へのシンボリックリンク

dbus-org.freedesktop.nm-dispatcher.service

yes

NetworkManager-dispatcher.service へのシンボリックリンク

firewalld.service

yes

ファイアウォールが必要ない場合に限り firewalld.service を無効にします。

getty@.service

no

このサービスは、それが本当に必要な場合に限り実行されるため、無効にする必要はありません。

import-state.service

yes

import-state.service は、ネットワークストレージからの起動が必要ない場合に限り無効にします。

irqbalance.service

yes

irqbalance.service は、CPU が 1 つしかない場合に限り無効にします。システムに CPU が複数ある場合は irqbalance.service を無効にしないでください。

kdump.service

yes

kdump.service は、カーネルクラッシュからのレポートが必要ない場合に限り無効にします。

loadmodules.service

yes

このサービスは、/etc/rc.modules ディレクトリーまたは /etc/sysconfig/modules ディレクトリーがなければ起動しません。つまり、RHEL 8 の最小インストールでは起動しません。

lvm2-monitor.service

yes

lvm2-monitor.service は、論理ボリュームマネージャー (LVM) を使用しない場合に限り無効にします。

microcode.service

no

そのサービスは、CPU 内のマイクロコードソフトウェアの更新を提供するため、無効にしないでください。

NetworkManager-dispatcher.service

yes

NetworkManager-dispatcher.service は、ネットワーク設定変更の通知が必要ない場合 (静的ネットワークなど) に限り無効にします。

NetworkManager-wait-online.service

yes

NetworkManager-wait-online.service は、システムの起動直後にネットワーク接続が利用できるようになっている必要がない場合に限り無効にします。このサービスを有効にすると、ネットワーク接続が有効になるまで、システムの起動が完了しません。これにより、起動時間が大幅に長くなることがあります。

NetworkManager.service

yes

NetworkManager.service は、ネットワークへの接続が必要ない場合に限り無効にします。

nis-domainname.service

yes

nis-domainname.service は、ネットワークインフォメーションサービス (NIS) を使用しない場合に限り無効にします。

rhsmcertd.service

no

 

rngd.service

yes

rngd.service は、お使いのシステムでエントロピーが多数必要ない場合、またはハードウェアジェネレーターがない場合に限り無効にします。このサービスは、X.509 証明書の生成に使用されるシステム (たとえば FreeIPA サーバー) など、良好なエントロピーを多数必要とする環境で必要になります。

rsyslog.service

yes

rsyslog.service は、永続的なログが必要ない場合に限り、または systemd-journald を永続モードに設定した場合に限り無効にします。

selinux-autorelabel-mark.service

yes

selinux-autorelabel-mark.service は、SELinux を使用しない場合に限り無効にします。

sshd.service

yes

sshd.service は、OpenSSH サーバーへのリモートログインが必要ない場合に限り無効にします。

sssd.service

yes

sssd.service は、ネットワークを介して (たとえば LDAP や Kerberos を使用して) システムにログインするユーザーがいない場合に限り無効にします。sssd.service を無効にした場合は、すべての sssd-* ユニットを無効にすることを Red Hat は推奨します。

syslog.service

yes

rsyslog.service のエイリアス

tuned.service

yes

tuned.service は、パフォーマンスチューニングを使用する必要がない場合に限り無効にします。

lvm2-lvmpolld.socket

yes

lvm2-lvmpolld.socket は、論理ボリュームマネージャー (LVM) を使用しない場合に限り無効にします。

dnf-makecache.timer

yes

dnf-makecache.timerは、パッケージメターデータを自動的に更新する必要がない場合に限り無効にします。

unbound-anchor.timer

yes

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 ディレクトリーのドロップインファイルが含まれます。

ドロップインファイルの詳細は、man ページの systemd.unit を参照してください。

systemctl help コマンドは、特定サービスの man ページを表示します。

第4章 ユーザーアカウントおよびグループアカウントの管理、およびファイルのアクセス権の設定

ユーザーとグループの制御は、Red Hat Enterprise Linux システム管理の中核となる要素です。本セクションでは、グラフィカルユーザーインターフェースおよびコマンドラインを使用してユーザーとグループを追加、管理、削除する方法を説明し、グループディレクトリーの作成などの高度なトピックを扱います。

4.1. ユーザーとグループの概要

ユーザーは、人 (物理的なユーザーに結び付けられたアカウント)、または使用する特定のアプリケーションに対して存在するアカウントのいずれかを指し、グループは、共通の目的でユーザーをまとめる組織の論理的表現です。グループ内のユーザーは、そのグループが所有するファイルの読み取り、書き込み、実行権限を共有します。

各ユーザーは、ユーザー ID (UID) と呼ばれる一意の数値 ID に関連付けられています。同様に、各グループは group ID (GID) に関連付けられています。ファイルを作成するユーザーは、そのファイルの所有者であり、グループ所有者でもあります。ファイルには、所有者、グループ、その他に対して読み取り、書き込み、実行のパーミッションが別々に割り当てられます。フファイル所有者の変更ができるのは root のみです。アクセスパーミッションは、root ユーザーとファイル所有者の両方が変更できます。

4.2. 予約されているユーザーとグループ ID

Red Hat Enterprise Linux は、1000 以下のユーザー ID とグループ ID を、システムユーザーとグループ用に予約しています。ユーザー管理 には、デフォルトではシステムユーザーが表示されません。予約されているユーザーおよびグループ ID の詳細は、setup パッケージに記載されています。このドキュメントを表示するには、以下のコマンドを使用します。

cat /usr/share/doc/setup*/uidgid

予約に使用される ID の範囲は今後広がる可能性があるため、ID には 5,000 以降の番号を割り当てることが推奨されます。新規ユーザーに割り当てる ID を 5,000 から始まるようにするには、/etc/login.defs ファイルのディレクティブ UID_MIN および GID_MIN を変更します。

[file contents truncated]
UID_MIN                  5000
[file contents truncated]
GID_MIN                  5000
[file contents truncated]
注記

UID_MIN ディレクティブおよび GID_MIN ディレクティブを変更する前に作成したユーザーの UID は、デフォルトの 1,000 から開始します。

新規ユーザーおよびグループの ID を 5,000 から始まるようにした場合でも、1,000 を上限とするシステムとの競合を避けるため、システムが予約する ID は 1,000 以降にならないようにすることが推奨されます。

4.3. ユーザープライベートグループ

Red Hat Enterprise Linux では、UPG (ユーザープライベートグループ) スキームが使用されているため、UNIX グループを簡単に管理できます。ユーザープライベートグループは、新規ユーザーがシステムに追加される度に作成されます。ユーザープライベートグループは作成されたユーザーと同じ名前となり、そのユーザーがそのユーザープライベートグループの唯一のメンバーになります。

ユーザープライベートグループを使用すると、新規に作成したファイルまたはディレクトリーに対して確実にデフォルトのパーミッションを設定できます。作成したユーザーと、そのユーザーのグループ の両方がファイルやディレクトリーを修正できるようになります。

新規に作成するファイルまたはディレクトリーに適用される権限を決める設定は umask と呼ばれ、/etc/bashrc ファイルで設定します。従来の UNIX ベースのシステムでは、umask022 に設定されており、ファイルまたはディレクトリーを作成したユーザーしか変更できず、作成者のグループのメンバーなど、他のユーザーは変更できませんでした。しかし、UPG スキームでは、すべてのユーザーがそれぞれプライベートグループを持つため、この「グループ保護」は必須ではなくなりました。

グループの一覧は、/etc/group 設定ファイルに保存されます。

4.4. シャドウパスワード

マルチユーザー環境では、shadow-utils パッケージで提供される シャドウパスワード を使用することが非常に重要です。これを使用することで、システムの認証ファイルのセキュリティーを強化できます。このため、インストールプログラムでは、デフォルト設定でシャドウパスワードを有効にしています。

UNIX ベースのシステムでパスワードを格納する従来の方法と比較して、シャドウパスワードには以下の利点があります。

  • シャドウパスワードは、暗号化されたパソワードハッシュを、あらゆるユーザーが読み取り可能な /etc/passwd ファイルから、root ユーザーのみが読み取り可能な /etc/shadow に移動して、システムセキュリティーを向上させます。
  • シャドウパスワードは、パスワードエージングに関する情報を保存します。
  • シャドウパスワードを使用すると、/etc/login.defs ファイルで設定したセキュリティーポリシーの実施が可能になります。

shadow-utils パッケージが提供するほとんどのユーティリティーは、シャドウパスワードが有効かどうかに関わらず適切に動作します。ただし、パスワードエージングの情報は /etc/shadow ファイルにのみ格納されているため、シャドウパスワードを有効にしないと、以下のユーティリティーとコマンドは動作しません。

  • パスワードエージングパラメーターを設定する chage ユーティリティー
  • /etc/group ファイルを管理するための gpasswd ユーティリティー
  • -e, --expiredate オプションまたは -f, --inactive オプションを使用した usermod コマンド
  • -e, --expiredate オプションまたは -f, --inactive オプションを使用した useradd コマンド

4.5. グラフィカル環境でのユーザーの管理

Users ユーティリティーは、グラフィカルユーザーインターフェースで、ローカルユーザーを表示、編集、追加、削除できます。

4.5.1. ユーザー設定ツールの使用

Super キーを押してアクティビティーの概要に入り、Users と入力して Enter を押します。Users 設定ツールが表示されます。Super キーはキーボードや他のハードウェアによって外見が異なりますが、通常はスペースバーの左側にある Windows キーまたは Command キーになります。また、画面の右上にある自分のユーザー名をクリックし、Settings (設定) メニューから Users ユーティリティーを開くこともできます。

ユーザーアカウントに変更を加えるには、最初に Unlock ボタンを選択し、表示されたダイアログボックスに従って自身を認証します。スーパーユーザー特権がない場合は、root で認証するよう求められます。ユーザーを追加および削除するには、+ ボタンと - ボタンをそれぞれクリックします。管理グループ wheel にユーザーを追加するには、Account Typeを Standard から Administrator に変更します。ユーザーの言語設定を編集するには、言語を選択します (ドロップダウンメニューが表示されます)。

図4.1 ユーザー設定ツール

managing users

新しいユーザーを作成しても、パスワードを設定するまでアカウントは無効になります。Password (パスワード) ドロップダウンメニュー (図4.2「パスワードメニュー」 を参照) には、管理者がすぐにパスワードを設定できるオプションが含まれます。最初のログイン時にユーザーがパスワードを選択するか、ログインパスワードなしでゲストアカウントを作成します。また、このメニューからアカウントを無効または有効にすることもできます。

図4.2 パスワードメニュー

managing users password

4.6. コマンドラインツールを使用したユーザーの管理

「ユーザー設定ツールの使用」で説明されている Users 設定ツール (ユーザーの基本的な管理に使用) のほかに、次の表に挙げられるユーザーとグループの管理コマンドラインツールを使用できます。

表4.1 ユーザーとグループを管理するためのコマンドラインユーティリティー

ユーティリティー説明

id

ユーザーおよびグループの ID を表示します。

useradd, usermod, userdel

ユーザーアカウントを追加、修正、削除する標準ユーティリティーです。

groupadd, groupmod, groupdel

グループを追加、修正、削除する標準ユーティリティーです。

gpasswd

ユーティリティーは、newgrp コマンドが使用する /etc/gshadow ファイルでグループパスワードの修正に主に使用されます。

pwck, grpck

パスワード、グループ、関連シャドウファイルを検証するユーティリティーです。

pwconv, pwunconv

通常のパスワードをシャドウパスワードに変換する、または逆にシャドウパスワードから通常のパスワードに変換するユーティリティーです。

grpconv, grpunconv

pwconv、pwunconv と同様、このユーティリティーは、グループアカウントのシャドウ化された情報を変換するのに使用できます。

4.6.1. 新規ユーザーの追加

システムにユーザーを追加するには、root で次のコマンドを実行します。

useradd options username

ここでの options は、表4.2「一般的な useradd コマンドラインオプション」 に記載されているコマンドオプションです。

デフォルトでは、useradd コマンドは、ロックされたユーザーアカウントを作成します。アカウントをアンロックするには、root で次のコマンドを実行して、パスワードを割り当てます。

passwd username

表4.2 一般的な useradd コマンドラインオプション

オプション 

-c 'comment'

comment にはどの文字列でも使用できます。このオプションは、通常、ユーザーの氏名を指定するのに使用されます。

-d home_directory

デフォルトの /home/username/ の代わりに使用するホームディレクトリーです。

-e date

アカウントを無効にする日付 (形式は YYYY-MM-DD) です。

-f days

パスワードが失効してからアカウントが無効になるまでの日数です。0 を指定すると、パスワードが失効した直後にアカウントが無効になります。-1 を指定すると、パスワードが失効してもアカウントは無効になりません。

-g group_name

ユーザーのデフォルト (プライマリー) グループ用のグループ名またはグループ番号です。グループは、ここで指定するよりも前に作成されている必要があります。

-G group_list

ユーザーがメンバーとなる追加 (補助、デフォルト以外のもの) のグループ名またはグループ番号の一覧で、コンマで区切ります。グループは、ここで指定する前に作成しておく必要があります。

-m

ホームディレクトリーがない場合は、これを作成します。

-M

ホームディレクトリーを作成しません。

-N

ユーザー用のユーザープライベートグループを作成しません。

-p password

crypt を使用してパスワードを暗号化しました。

-r

UID が 1000 未満でホームディレクトリーがないシステムアカウントを作成します。

-s

ユーザーのログインシェルです。デフォルトは /bin/bash に設定されています。

-u uid

ユーザーのユーザー ID です。一意の番号で 999 より大きい数にする必要があります。

重要

Red Hat Enterprise Linux 7 では、システムユーザーおよび通常のユーザーのデフォルトの ID 範囲が変更になりました。Red Hat Enterprise Linux 7 以前はシステムユーザーに UID 1 ~ 499 が使用され、500 以降の値が通常のユーザーに使用されていました。変更後は、システムユーザーのデフォルト範囲が 1 ~ 999 になりました。この変更により、既存のユーザーの UID と GID に 500 ~ 999 を使用している場合に Red Hat Enterprise Linux 8 に移行すると、問題が発生する場合があります。UID と GID のデフォルトの範囲は /etc/login.defs ファイルで変更できます。

以下の手順は、シャドウパスワードが有効なシステムで useradd juan コマンドを実行したときに発生する内容を解説したものです。

  1. juan 用の新しい行が /etc/passwd に作成されます。

    juan:x:1001:1001::/home/juan:/bin/bash

    この行には以下の特徴があります。

    • ユーザー名 juan で始まります。
    • パスワードフィールドには x が表示され、システムがシャドウパスワードを使用していることを示しています。
    • 999 より大きい UID が作成されます。Red Hat Enterprise Linux 7 では、1000 未満の UID は、システムが使用するために予約されています。1000 未満の UID はユーザーに割り当てないでください。
    • 999 より大きい GID が作成されます。 Red Hat Enterprise Linux 7 では、1000 未満の GID は、システムが使用するために予約されています。1000 未満の GID はユーザーに割り当てないでください。
    • オプションの GECOS 情報は空白のままになっています。GECOS フィールドは、氏名や電話番号などユーザーの追加情報を提供するために使用されます。
    • juan のホームディレクトリーは、/home/juan/ に設定されます。
    • デフォルトシェルは /bin/bash に設定されます。
  2. juan 用の新しい行が /etc/shadow に作成されます。

    juan:!!:14798:0:99999:7:::

    この行には以下の特徴があります。

    • ユーザー名 juan で始まります。
    • /etc/shadow ファイルのパスワードフィールドには 2 つの感嘆符 (!!) が表示され、アカウントがロックされていることを示しています。

      注記

      暗号化したパスワードを、-p フラグを使用して渡す場合は、そのユーザー用に、/etc/shadow ファイルに新しい行が追加されます。

    • パスワードは有効期限なしで設定されています。
  3. juan という名前のグループ用に、新しい行が /etc/group に作成されます。

    juan:x:1001:

    ユーザーと同じ名前のグループは、ユーザープライベートグループ と呼ばれます。ユーザープライベートグループの詳細は 「ユーザープライベートグループ」 を参照してください。

    /etc/group に作成した行には、以下の特徴があります。

    • グループ名 juan で始まります。
    • パスワードフィールドには x が表示され、システムがシャドウグループパスワードを使用していることを示しています。
    • GID は、/etc/passwd で設定されている juan のプライマリーグループに記載されているものと一致します。
  4. juan という名前のグループ用の新しい行が /etc/gshadow に作成されました。

    juan:!::

    この行には以下の特徴があります。

    • グループ名 juan で始まります。
    • /etc/gshadow ファイルのパスワードフィールドには 1 つの感嘆符 (!) が表示され、グループがロックされていることを示しています。
    • その他のフィールドはすべて空白です。
  5. /home ディレクトリーに、ユーザー juan のディレクトリーが作成されます。

    ~]# ls -ld /home/juan
    drwx------. 4 juan juan 4096 Mar  3 18:23 /home/juan

    このディレクトリーはユーザー juan およびグループ juan が所有します。このディレクトリーの 読み取り書き込み、および 実行 の権限は、juan ユーザーに のみ 割り当てられます。その他のパーミッションは拒否されます。

  6. (デフォルトユーザー設定を含む) /etc/skel/ ディレクトリーが、新しい /home/juan/ ディレクトリーにコピーされます。

    ~]# ls -la /home/juan
    total 28
    drwx------. 4 juan juan 4096 Mar  3 18:23 .
    drwxr-xr-x. 5 root root 4096 Mar  3 18:23 ..
    -rw-r—​r--. 1 juan juan   18 Jun 22  2010 .bash_logout
    -rw-r—​r--. 1 juan juan  176 Jun 22  2010 .bash_profile
    -rw-r—​r--. 1 juan juan  124 Jun 22  2010 .bashrc
    drwxr-xr-x. 4 juan juan 4096 Nov 23 15:09 .mozilla

この時点では、juan という名前のロックされたアカウントがシステムに存在します。このアカウントをアクティベートするには、管理者が passwd コマンドを使用して、アカウントにパスワードに割り当てる必要があります。パスワードエージングのガイドラインを設定することもできます。

4.6.2. 新規グループの追加

システムに新しいグループを追加するには、root で次のコマンドを実行します。

groupadd options group_name

ここでの options は、表4.3「一般的な groupadd コマンドラインオプション」 に記載されているコマンドラインオプションです。

表4.3 一般的な groupadd コマンドラインオプション

オプション説明

-f, --force

groupadd-g と共にすると、gid および gid が存在している場合に、そのグループに別の一意の gid を選択します。

-g gid

グループのグループ ID です。一意の番号で、999 より大きい数にする必要があります。

-K, --key key=value

/etc/login.defs のデフォルトを上書きします。

-o--non-unique

GID が重複するグループの作成を許可します。

-p--password password

新規グループに、この暗号化されたパスワードを使用します。

-r

GID が 1000 未満のシステムグループを作成します。

4.6.3. 既存グループへの既存ユーザーの追加

usermod ユーティリティーを使用して、既存のユーザーを既存のグループに追加します。

usermod のさまざまなオプションは、ユーザーのプライマリーグループと補助グループにさまざまな影響を与えます。

ユーザーのプライマリーグループを上書きするには、root で以下のコマンドを実行します。

usermod -g group_name user_name

ユーザーの補助グループを上書きするには、root で以下のコマンドを実行します。

usermod -G group_name1,group_name2,…​ user_name

この場合、ユーザーの補助グループは、すべて新しいグループに置き換えられます。

ユーザーの補助グループにグループを追加するには、root で以下のコマンドのいずれかを実行します。

usermod -aG group_name1,group_name2,…​ user_name
usermod --append -G group_name1,group_name2,…​ user_name

この場合、新しいグループが、ユーザーの現在の補助グループに追加されます。

4.6.4. グループディレクトリーの作成

システム管理者は、通常、主要なプロジェクトに対してそれぞれグループを作成し、そのプロジェクトのファイルにアクセスする必要がある場合に、そのユーザーをグループに割り当てる傾向があります。こうした従来型のスキームの場合は、誰かがファイルを作成すると、そのユーザーが属するプライマリーグループにそのファイルが関連付けられるため、ファイル管理は困難になり、1 人のユーザーが複数のプロジェクトに関わっている場合に、正しいファイルを正しいグループに関連付けることは難しくなります。一方、UPG スキームを使用すると、グループは setgid ビットセットを持つディレクトリーに作成されたファイルに自動的に割り当てられます。setgid ビットにより、共通のディレクトリーを共有するグループプロジェクトを非常に簡単に管理できます。ユーザーがディレクトリー内で作成するすべてのファイルは、ディレクトリーを所有するグループが所有するためです。

たとえば、あるグループが /opt/myproject/ ディレクトリーのファイルを作業する必要があるとします。グループの中には、このディレクトリーのコンテンツの修正を信頼して任せられる人もいますが、全員ではありません。

  1. root で以下のコマンドを実行して、/opt/myproject/ ディレクトリーを作成します。

    mkdir /opt/myproject
  2. myproject グループをシステムに追加します。

    groupadd myproject
  3. /opt/myproject/ ディレクトリーのコンテンツを、myproject グループに関連付けます。

    chown root:myproject /opt/myproject
  4. グループのユーザーがそのディレクトリーにファイルを作成し、setgid ビットを設定できるようにします。

    chmod 2775 /opt/myproject

    この設定により、ユーザーが新たにファイルを作成するたびに、管理者がファイルのパーミッションを変更しなくても、myproject グループの全メンバーが /opt/myproject/ ディレクトリーのファイルを作成および編集できます。パーミッションが正しく設定されていることを確認するには、以下のコマンドを実行します。

    ls -ld /opt/myproject
    drwxrwsr-x. 3 root myproject 4096 Mar  3 18:31 /opt/myproject
  5. myproject グループにユーザーを追加します。

    usermod -aG myproject username

4.6.5. umask を使用した、新規ファイルのデフォルト権限の設定

プロセスがファイルを作成すると、そのファイルにはデフォルト権限 (-rw-rw-r-- など) が設定されます。こうした初期権限は、ファイルモード作成マスク (ファイル権限マスク または umask とも呼ばれる) で部分的に定義されます。たとえば、bashumask は、デフォルトで 0022 となるなど、すべてのプロセスにそれぞれの umask が設定されています。プロセスの umask は変更できます。

4.6.5.1. umask を構成するもの

umask は、標準のファイル権限に対応するビットで構成されています。たとえば、umask 0137 の場合、その数字は次のような意味になります。

  • 0 = 意味なし。必ず 0 になります (umask は特別なビットに影響しません)
  • 1 = オーナーの権限。実行ビットが設定されます。
  • 3 = グループの権限。実行および書き込みビットが設定されます。
  • 7 = その他のユーザーの権限。実行、書き込み、読み取りビットが設定されます。

umask では 2 進法、8 進法、またはシンボリック表示が使用できます。たとえば、8 進法の 0137 はシンボリック表示では u=rw-,g=r--,o=--- となります。シンボリック表示は 8 進法表示とは異なり、禁止権限ではなく、許可された権限を示します。

4.6.5.2. umask の仕組み

Umask は、ファイルに アクセス権を設定しない ようにします。

  • umask に設定しているビットは、ファイルには設定されません。
  • umask に設定していないビットは、他の要素にもよりますが、ファイルに設定されます。

以下の図は、umask 0137 が新しいファイルの作成にどのように影響するかを示しています。

図4.3 ファイルの作成時に umask を適用

Users Groups Umask Example
重要

セキュリティー上の理由から、レギュラーファイルにはデフォルトで実行権限が設定されていません。したがって、umask がいかなる権限も禁止しない 0000 であっても、新しいレギュラーファイルは実行権限を持ちません。ただし、ディレクトリーは実行権限を持つ状態で作成できます。

[john@server tmp]$ umask 0000
[john@server tmp]$ touch file
[john@server tmp]$ mkdir directory
[john@server tmp]$ ls -lh .
total 0
drwxrwxrwx. 2 john john 40 Nov  2 13:17 directory
-rw-rw-rw-. 1 john john  0 Nov  2 13:17 file

4.6.5.3. シェルで umask の管理

bashkshzshtcsh などのよく使用されるシェルでは、umask は、シェル builtinumask を使用して管理されます。シェルから起動したプロセスは、その umask を継承します。

4.6.5.3.1. 現在のマスクの表示

現在の umask を 8 進法で表示するには、以下のコマンドを実行します。

~]$ umask
0022

現在の umask をシンボリック表示で表示するには、以下のコマンドを実行します。

umask -S
u=rwx,g=rx,o=rx
4.6.5.3.2. umask を使用したシェルにおけるマスクの設定

8 進法を使用して、現行シェルセッションに umask を設定するには、以下のコマンドを実行します。

umask octal_mask

octal_mask を、0 から 7 の 4 桁以下の数値に置き換えます。3 桁以下の数値を指定すると、頭に 0 が付いた 4 桁の数値として権限が設定されます。たとえば、入力したコマンドが umask 7 であれば、そのコマンドの数値は 0007 として解釈されます。

例4.1 8 進法を使用した umask の設定

新しいファイルで、オーナーとグループに書き込み権限と実行権限を持たせず、その他のユーザーにはいかなる権限も持たせないようにするには、以下を実行します。

umask 0337

または

umask 337

シンボリック表記法を使用して、現行シェルセッションの umask を設定するには、以下のコマンドを実行します。

umask -S symbolic_mask

例4.2 シンボリック表示を使用した umask の設定

シンボリック表記法を使用して umask 0337 を設定するには、以下のコマンドを実行します。

umask -S u=r,g=r,o=
4.6.5.3.3. デフォルトシェルの umask での作業

シェルには、通常、デフォルトの umask が設定されている設定ファイルがあります。bash の場合は /etc/bashrc です。デフォルトの bash umask を表示するには、以下のコマンドを実行します。

grep -i -B 1 umask /etc/bashrc

出力では、umask の設定が、umask コマンドまたは UMASK 変数のいずれかを使用して行われていることが示されます。以下の例では、umask コマンドを使用して、umask022 に設定されています。

grep -i -B 1 umask /etc/bashrc
    # By default, we want umask to get set. This sets it for non-login shell. —     if [ $UID -gt 199 ] && [ “id -gn” = “id -un” ]; then
       umask 002
    else
       umask 022

bash のデフォルト umask を変更するには、/etc/bashrcumask コマンドの呼び出し、または UMASK 変数の割り当てを変更します。この例では、デフォルトの umask0227 に変更します。

    if [ $UID -gt 199 ] && [ “id -gn” = “id -un” ]; then
       umask 002
    else
       umask 227
4.6.5.3.4. 特定ユーザーのデフォルトシェル umask での作業

デフォルトでは、新規ユーザーのデフォルトの bash umask は、/etc/bashrc に定義したものに設定されます。

特定ユーザーの bash umask を変更するには、そのユーザーの $HOME/.bashrc ファイルで、umask コマンドの呼び出しを追加します。たとえば、ユーザー johnbash umask0227 に変更するには、以下のコマンドを実行します。

john@server ~]$ echo 'umask 227' [] /home/john/.bashrc
4.6.5.3.5. 新規作成されたホームディレクトリーのデフォルト権限設定

作成したユーザーホームディレクトリーの権限を変更するには、/etc/login.defs ファイルでの UMASK 変数を変更します。

# The permission mask is initialized to this value. If not specified,
# the permission mask will be initialized to 022.
UMASK 077

4.7. 関連資料

Red Hat Enterprise Linux でユーザーとグループを管理する方法は、下記の資料を参照してください。

4.7.1. インストールされているドキュメント

ユーザーおよびグループの管理に使用する各種ユーティリティーの詳細情報は、以下の man ページを参照してください。

  • useradd(8) - useradd コマンドの man ページでは、新しいユーザーを作成する方法が説明されています。
  • userdel(8) - userdel コマンドの man ページでは、ユーザーを削除する方法が説明されています。
  • usermod(8) - usermod コマンドの man ページでは、ユーザーを変更する方法が説明されています。
  • groupadd(8) - groupadd コマンドの man ページでは、新しいグループを作成する方法が説明されています。
  • groupdel(8) - groupdel コマンドの man ページでは、グループを削除する方法が説明されています。
  • groupmod(8) - groupmod コマンドの man ページでは、グループのメンバーシップを修正する方法が説明されています。
  • gpasswd(1) - gpasswd コマンドの man ページでは、/etc/group ファイルを管理する方法が説明されています。
  • grpck(8) - grpck コマンドの man ページでは、これを使用して /etc/group ファイルの統合を確認する方法が説明されています。
  • pwck(8) - pwck コマンドの man ページでは、これを使用して /etc/passwd ファイルおよび /etc/shadow ファイルの統合を確認する方法が説明されています。
  • pwconv(8) - pwconvpwunconvgrpconv、および grpunconv の各コマンドの man ページでは、パスワードおよびグループ用にシャドウ情報を変換する方法が説明されています。
  • id(1) - id コマンドの man ページでは、ユーザー ID およびグループ ID を表示する方法が説明されています。

関連する設定ファイルの詳細は、以下をご覧ください。

  • group(5) - /etc/group ファイルの man ページでは、システムグループを定義する方法が説明されています。
  • passwd(5) - /etc/passwd ファイルの man ページでは、このファイルを使用して、ユーザー情報を定義する方法が説明されています。
  • shadow(5) - /etc/shadow ファイルの man ページでは、システムにおけるパスワードとアカウントの有効期限情報の設定方法が説明されています。

第5章 Chrony スイートを使用した NTP の設定

5.1. chrony を使用した NTP の設定の概要

IT では、多くの理由で正確な時間の維持が重要です。たとえばネットワーキングでは、パケットとログのタイムスタンプが正確であることが必要です。Linux システムでは、NTP プロトコルがユーザースペースで実行しているデーモンにより実装されます。

ユーザースペースのデーモンは、カーネルで実行されているシステムクロックを更新します。システムクロックはさまざまなクロックソースを使用して時間を維持しています。一般的に使用されるのは Time Stamp Counter (TSC) です。TSC は、最後にリセットされた時点からのサイクル数を計測する CPU レジスターです。非常に高速でハイレゾリューションであり、中断も発生しません。

Red Hat Enterprise Linux 8 では、NTP プロトコルは chronyd デーモンにより実装されます。このデーモンは、chrony パッケージのリポジトリーから利用できます。

本セクションは、chrony スイートの使用を説明します。

5.2. chrony スイートの概要

chronyNetwork Time Protocol (NTP) の実装です。chrony は、以下に使用できます。

  • システムクロックを、NTP サーバーと同期する
  • システムクロックを、GPS レシーバーなどの基準クロックと同期する
  • システムクロックを、手動で入力した時間と同期する
  • ネットワーク内の他のコンピューターにタイムサービスを提供する NTPv4(RFC 5905) サーバーまたはピアとして

chrony は、ネットワーク接続が頻繁に切断される、ネットワークの混雑が長時間続く、温度が変わる (一般的なコンピューターのクロックは温度に敏感) といったさまざまな状況や、継続的に実行されない、または仮想マシンで実行されているといったシステムにおいても、良好に動作します。

インターネット上で同期している 2 つのマシン間の一般的精度は数ミリ秒以内、LAN 上のマシン間では数十マイクロ秒以内です。ハードウェアタイムスタンプまたはハードウェア基準クロックは、同期している 2 つのマシン間の精度をサブマイクロ秒レベルにまで高めることができます。

chrony は、ユーザースペースで実行する chronyd と、chronyd のパフォーマンスを監視し、実行時にさまざまなオペレーティングパラメーターを変更するのに使用できるコマンドラインプログラムである chronyc で構成されます。

chrony デーモンである chronyd は、コマンドラインユーティリティーの chronyc を使用して監視と管理を行います。このユーティリティーは、chronyd の現在の状態にクエリーを実行し、その設定を変更する多数のコマンド入力を可能にするコマンドプロンプトを提供します。デフォルトでは、chronydchronyc のローカルインスタンスのコマンドのみを受け付けますが、リモートホストから監視コマンドを受け付けるように設定することも可能です。リモートアクセスは制限することが推奨されます。

5.2.1. chronyc を使用した chronyd の制御

対話モードでコマンドラインユーティリティー chronycを使用して chronyd のローカルインスタンスを変更するには、root で以下のコマンドを実行します。

~]# chronyc

制限されているコマンドを使用する場合は、rootchronyc を実行する必要があります。

以下のように、chronyc コマンドプロンプトが表示されます。

chronyc>

そのコマンドの一覧を表示するには、help と入力します。

このユーティリティーは、以下のようなコマンドで呼び出すと、非対話型コマンドモードでも呼び出すことができます。

chronyc command
注記

chronyc を使用して変更した内容は永続的ではなく、chronyd を再起動すると元に戻ります。永続的に変更する場合は、/etc/chrony.conf を変更してください。

5.3. chrony と ntp の相違点

Network Time Protocol (NTP) には、基本的な機能が似ている 2 つの実装 (ntpchrony) があります。

ntpchrony のいずれも、NTP サーバーにシステムクロックを同期させる NTP クライアントとして動作したり、ネットワーク上の別のコンピューターに対する NTP サーバーとして動作できます。各実装には、固有の機能があります。ntp および chrony の比較は「Comparison of NTP implementations」を参照してください。

NTP クライアントに固有の設定は、ほとんどの場合同じです。NTP サーバーは、server ディレクティブで指定します。サーバーのプールは、pool ディレクティブで指定します。

NTP サーバーに固有の設定は、クライアントアクセスの制御方法により異なります。デフォルトでは、ntpd は任意のアドレスからクライアントリクエストに応答します。このアクセスは restrict ディレクティブで制御できますが、ntpd が任意のサーバーをクライアントとして使用している場合は、アクセスを完全に無効にできません。chronyd は、デフォルトではいずれのアクセスも許可せず、NTP クライアントとして動作します。chronyNTP サーバーとして動作させるようにするには、allow ディレクティブでいくつかのアドレスを指定する必要があります。

ntpdchronyd は、システムクロックの修正に対するデフォルト動作も異なります。ntpd は、オフセットが 128 ミリ秒より大きい場合に、step でクロックを修正します。オフセットが 1000 秒よりも大きい場合は、これがクロックの最初の修正でない場合は ntpd が終了し、-g オプションで ntpd が起動します。chronyd は、デフォルトでクロックを一気に修正する (step) ことはしませんが chrony パッケージで提供されているデフォルトの chrony.conf ファイルでは、クロックの最初の 3 つの更新で step を許可します。その後の修正はすべて、クロックの速度を速めるか遅らせて徐々に修正します。chronyc makestep コマンドを実行すれば、chronyd によりクロックを強制的に step できます。

5.4. chrony への移行

Red Hat Enterprise Linux 7 では、正確な時間管理を行う方法として、ntp または chrony を選択できます。ntpchrony の相違点、および ntpdchronyd の相違点は「Differences between ntpd and chronyd」を参照してください。

Red Hat Enterprise Linux 8 では ntp がサポートされなくなりました。デフォルトで chrony が有効になります。このため、ntp から chrony への移行が必要になる場合があります。

ntp から chrony への移行は、ほとんどの場合簡単です。対応するプログラムの名前、設定ファイルおよびサービスは、次のとおりです。

表5.1 ntp から chrony へ移行する際に、プログラム、設定ファイル、サービスに対応する名前

ntp の名前chrony の名前

/etc/ntp.conf

/etc/chrony.conf

/etc/ntp/keys

/etc/chrony.keys

ntpd

chronyd

ntpq

chronyc

ntpd.service

chronyd.service

ntp-wait.service

chrony-wait.service

ntpdate ユーティリティーおよび sntp ユーティリティーは ntp ディストリビューションに含まれていますが、-q オプションまたは -t オプションを使用して chronyd に置き換えることができます。この設定は、/etc/chrony.conf を読み込まないようにコマンドラインで指定できます。たとえば、ntpdate ntp.example.com を実行する代わりに、以下のように chronyd を起動できます。

# chronyd -q 'server ntp.example.com iburst'
2018-05-18T12:37:43Z chronyd version 3.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 +DEBUG)
2018-05-18T12:37:43Z Initial frequency -2.630 ppm
2018-05-18T12:37:48Z System clock wrong by 0.003159 seconds (step)
2018-05-18T12:37:48Z chronyd exiting

ntpstat ユーティリティーは、ntp パッケージに含まれていましたが、ntpd だけをサポートしていました。現在は、ntpdchronyd の両方をサポートします。これは、ntpstat パッケージで入手できます。

5.4.1. 移行スクリプト

chrony パッケージのドキュメント (/usr/share/doc/chrony) には、ntp2chrony.py という名前の Python スクリプトがあります。このスクリプトは、既存の ntp 設定を chrony に自動的に変換します。ntp.conf ファイルで最も一般的なディレクティブおよびオプションがサポートされます。変換で無視されている行はすべて、確認のために、生成された chrony.conf ファイルにコメントとして追加されます。ntp 鍵ファイルに指定し、ntp.conf で信頼される鍵としてマークされていない鍵は、生成された chrony.keys ファイルにコメントとして追加されます。

デフォルトでは、スクリプトはいずれのファイルも上書きしません。/etc/chrony.conf または /etc/chrony.keys がすでに存在する場合は、-b オプションを使用してファイルの名前を変更してバックアップとして使用できます。このスクリプトはその他のオプションもサポートします。--help オプションを使用すると、サポートされるすべてのオプションが表示されます。

ntp で提供されるデフォルトの ntp.conf を使用したスクリプトの呼び出し例は以下のようになります。

# python3 /usr/share/doc/chrony/ntp2chrony.py -b -v
Reading /etc/ntp.conf
Reading /etc/ntp/crypto/pw
Reading /etc/ntp/keys
Writing /etc/chrony.conf
Writing /etc/chrony.keys

この場合に無視される唯一のディレクティブは disable monitor です。これは、noclientlog ディレクティブで chrony に相当するものがありますが、増幅攻撃を軽減するためだけに、デフォルトの ntp.conf に含まれていました。

生成した chrony.conf ファイルには、通常、ntp.conf の制御行に対応する allow ディレクティブが多数含まれています。chronydNTP サーバーとして実行しない場合は、allow ディレクティブをすべて chrony.conf から削除します。

5.5. chrony の設定

chronyd のデフォルト設定ファイルは /etc/chrony.conf です。-f オプションは、代替の設定ファイルパスを指定するのに使用できます。詳細は man ページの chrony.conf(5) を参照してください。使用できるディレクティブの一覧は「The chronyd configuration file」を参照してください。

以下は、chronyd 設定オプションです。

コメント
コメントの前には、#、%、;、または ! を付けます。
allow

必要に応じて、NTP サーバーとして動作しているマシンへの接続が許可されるホスト、サブネット、またはネットワークを指定します。デフォルトでは、接続は許可されません。

以下に例を示します。

allow 192.0.2.0/24

特定のネットワークへのアクセスを許可するときにこのコマンドを使用します。

allow 2001:0db8:85a3::8a2e:0370:7334

このコマンドを使用して、IPv6 へのアクセスを付与します。

クライアントアクセスを可能にするため、ファイアウォールで UDP ポート番号 123 を開いておく必要があります。

~]#  firewall-cmd --zone=public --add-port=123/udp

ポート 123 を永続的に開くには、--permanent オプションを使用します。

~]#  firewall-cmd --permanent --zone=public --add-port=123/udp
cmdallow
これは allow ディレクティブと似ていますが (allow セクションを参照)、特定のサブセットまたはホストへの制御アクセスを許可します (これは NTP クライアントアクセスとは異なります)。「制御アクセス」とは、chronyc がこのようなホストで実行可能であり、このコンピューター上で chronyd に正常に接続できることを意味します。構文は同じになります。また、cmdallow all ディレクティブと動作が似ている cmddeny all もあります。
dumpdir
chronyd の再起動にまたがる測定履歴を保存するディレクトリーへのパスです (これが実行していない時にシステムクロックの動作が変更されていないことを想定しています)。(設定ファイルの dumponexit コマンド、chronycdump コマンドから) この機能を使用する場合は、dumpdir コマンドを使用して測定履歴を保存するディレクトリーを定義してください。
dumponexit
このコマンドが存在する場合は、chronyd が、プログラムの終了時に常に記録された時間ソースの測定履歴を保存することを示しています (上記の dumpdir コマンドを参照)。
hwtimestamp
hwtimestamp ディレクティブは、ハードウェアタイムスタンプの非常に精度の高い同期を可能にします。詳細は man ページの chrony.conf(5) を参照してください。
local

local キーワードは、現行の同期ソースがない場合でも、(それをポーリングしているクライアントから見ると) chronyd がリアルタイムに同期しているように見えるようにします。このオプションは、通常、孤立したネットワークで「master」となるコンピューターで使用されます。ここでは、いくつかのコンピューターが相互に同期するようになり、「master」は、手動入力でリアルタイムと一致させます。

以下はコマンド例を示します。

local stratum 10

10 という大きな値が示しているのは「基準クロックからのホップ数が非常に多いため、時間の信頼性が低い」ということです。基準クロックに最終的に同期している別のコンピューターにアクセスするコンピューターは、確実に 10 よりも下の階層に存在することになります。このため、local コマンドで 10 のように高い値を設定すると、リアルサーバーの視認性があるクライアントにリークしたとしても、マシン自体の時間がリアルタイムと混乱することを防ぎます。

log

log コマンドは、特定情報がログ記録されることを意味します。以下のオプションを取ります。

measurements
このオプションは、生の NTP 測定値とその関連情報を、measurements.log という名前のログファイルに記録します。
statistics
このオプションは、回帰処理の情報を statistics.log ファイルにログ記録します。
tracking
このオプションは、システムの時間が進んだり遅れたりする予測に対する変更や、発生した slew 調整を、tracking.log と呼ばれるファイルにログ記録します。
rtc
このオプションは、システムのリアルタイムクロックに関する情報をログ記録します。
refclocks
このオプションは、生およびフィルター処理された基準クロックの測定を、refclocks.log ファイルにログ記録します。
tempcomp

このオプションは、温度測定とシステムレートの補正を tempcomp.log と呼ばれるファイルにログ記録します。

ログファイルは、logdir コマンドが指定するディレクトリーに書き込まれます。

以下はコマンド例を示します。

log measurements statistics tracking
logdir

このディレクティブは、ログファイルが書き込まれるディレクトリーを指定します。

このディレクティブの使用例は、以下のようになります。

logdir /var/log/chrony
makestep

通常、chronyd は、必要に応じてクロックの速度を下げるかまたは上げることで、システムに対して時間オフセットの段階的修正を実施します。特定の状況では、このスルーイング (slewing) プロセスでシステムクロックを修正するのに非常に時間がかかり、システムクロックが不安定な状態になることがあります。このディレクティブは、調整がしきい値を上回ったときに、chronyd にシステムクロックを一度に修正 (step) します。 ただしこれは、chronyd が起動した後に、指定した制限を超えてクロック更新が行われなかった場合に限ります (負の数は制限値の無効化に使用されます)。initstepslew ディレクティブは NTP のソースのみに対応しているため、この方法は基準クロックを使用しているときに特に有用です。

このディレクティブの使用例は、以下のようになります。

makestep 1000 10

この場合、調整幅が 1000 秒よりも大きければシステムクロックは更新されますが、最初の 10 回の更新しか行われません。

maxchange

このディレクティブは、クロック更新で修正される許容オフセットの最大値を設定します。更新が指定された回数行われた後にのみチェックが実行されるため、システムクロックの初回の調整が大きくなります。指定された最大値よりも大きなオフセットが発生すると、そのオフセットは指定した回数の間無視され、その後に chronyd が終了します (マイナス値を使用すると、終了しないようになります)。いずれの場合も、メッセージは syslog に送信されます。

このディレクティブの使用例は、以下のようになります。

maxchange 1000 1 2

最初のクロック更新後に、chronyd がすべてのクロック更新でオフセットをチェックし、1000 秒よりも大きい調整を 2 回無視して、3 回目に終了します。

maxupdateskew

chronyd のタスクの 1 つは、コンピュータのクロックがその基準源に対してどれくらい速くまたは遅く動くかを調べることです。また、推定値の誤差範囲の推定値を計算します。

エラーの範囲が広すぎる場合は、測定が落ち着いていないこと、そして推定増加または損失率に信頼性があまりないことを示しています。

maxupdateskew パラメーターは、パラメーター推定値を使用できるほどには信頼できないかどうかを判定するためのしきい値です。デフォルトでは、しきい値は 1000 ppm です。

構文は以下のようになります。

maxupdateskew skew-in-ppm

skew-in-ppm の一般的な値は、電話回線を介してサーバーにダイアルアップ接続を行う場合は 100、LAN 上のコンピューターの場合は 5 または 10 になります。

信頼性のない予測の使用に対する保護の方法は、これだけではないことに注意してください。chronyd は常に、予想される進みまたは遅れのレートと、予測のエラー範囲を追跡しています。ソースの 1 つで測定が作成された後に別の予測が新たに生成されると、加重組み合わせのアルゴリズムを使用してマスター予測が更新されます。このため、chronyd に信頼性の高い既存のマスター予測があり、エラー範囲の広い新たな予測が生成されると、既存のマスター予測が新規のマスター予測を特徴づけることになります。

minsources

minsources ディレクティブは、ローカルクロックを更新する前にソース選択アルゴリズムで選択可能なものとして考慮されるべきソースの最小数を設定します。

構文は以下のようになります。

minsources number-of-sources

number-of-sources は、デフォルトでは 1 です。数値を 1 よりも大きくすると、信頼性が向上します。複数のソースが互いに対応することが必要となるためです。

noclientlog
引数を取らないこのディレクティブは、クライアントアクセスをログに記録しないことを指定します。通常はログに記録されますが、統計を chronyc でクライアントコマンドを使用して報告し、クライアントが server ディレクティブの xleave オプションでインターリーブモードを使用するようにできます。
reselectdist

chronyd が、利用可能なソースから同期ソースを選ぶ際に、同期距離が最短のものを優先します。ただし、同様の距離のソースが複数存在して、再選択が繰り返されるのを回避するため、現在選択されていないソースからの距離に、固定距離が追加されます。これは、reselectdist オプションで設定できます。デフォルトでは、この距離は 100 ミリ秒となります。

構文は以下のようになります。

reselectdist dist-in-seconds
stratumweight

stratumweight ディレクティブは、chronyd が利用可能なソースから同期ソースを選択する際に、階層ごとに追加される同期距離を設定します。

構文は以下のようになります。

stratumweight dist-in-seconds

デフォルトでは、dist-in-seconds は 1 ミリ秒です。つまり、通常、より低い stratum を持つソースは、たとえ距離が著しく離れていても、より高い stratum を持つソースを選びます。stratumweight を 0 に設定すると、chronyd はソースを選択するときに stratum を無視します。

rtcfile

rtcfile ディレクティブは、システムのリアルタイムクロック (RTC) の正確性の追跡に関連するパラメーターを chronyd が保存できるファイル名を定義します。

構文は以下のようになります。

rtcfile /var/lib/chrony/rtc

chronyd は、このファイルが存在し、chronycwritertc コマンドを実行すると、情報をこのファイルに保存します。保存される情報は、あるエポックでの RTC のエラー、そのエポック (1970 年 1 月 1 日以降の秒数)、および RTC の時間が早まるもしくは遅れる変化量です。リアルタイムクロックのコードはシステム固有のものなので、すべてのリアルタイムクロックがサポートされるわけではありません。このディレクティブを使用する場合は、リアルタイムクロックを手動で調整しないでください。リアルタイムクロックがランダムな間隔で調整されると、その変化量を測定する chrony の必要性が干渉されるためです。

rtcsync
rtcsync ディレクティブは、デフォルトで /etc/chrony.conf ファイルにあります。これにより、システムクロックが同期されていることがカーネルに知らされ、カーネルによりリアルタイムクロックが 11 分ごとに更新されます。

5.5.1. chrony でセキュリティーの設定

chronyc は、以下の 2 つの方法で chronyd にアクセスします。

  • インターネットプロトコル (IPv4 または IPv6)
  • Unix ドメインソケット (ユーザー root または chrony がローカルにアクセス可能)

デフォルトでは、chronyc は、Unix ドメインソケットに接続します。デフォルトのパスは /var/run/chrony/chronyd.sock です。この接続に失敗すると (たとえば非特権ユーザーで chronyc を実行していると失敗する可能性があります)、chronyc は 127.0.0.1 への接続を試み、その後 ::1 を試みます。

chronyd の動作に影響しない次の監視コマンドのみが、ネットワークに許可されています。

  • activity
  • manual list
  • rtcdata
  • smoothing
  • sources
  • sourcestats
  • tracking
  • waitsync

chronyd がこのコマンドを受け取るホスト郡は、chronyd の設定ファイルにある cmdallow ディレクティブ、または chronyccmdallow コマンドで設定できます。デフォルトでは、このコマンドが許可されるのは、ローカルホスト (127.0.0.1 or ::1) のものだけになります。

その他のコマンドはすべて、Unix ドメインソケットのみを介して許可されます。ネットワーク上で送信されると、たとえローカルホストであっても、chronydNot authorised エラーを返します。

chronyc を使用して chronyd にリモートでアクセス

  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

allow ディレクティブは NTP のアクセス用で、cmdallow ディレクティブは、リモートコマンドの受け取りを可能にします。ローカルで実行している chronyc を使用すると、この変更を一時的なものにできます。永続的に変更するときは設定ファイルを変更します。

5.6. chrony の使用

5.6.1. chrony のインストール

Red Hat Enterprise Linux では、chrony スイートがデフォルトでインストールされます。インストールされていることを確認するには、root で以下のコマンドを実行します。

~]# yum install chrony

chrony デーモンのデフォルトの場所は /usr/sbin/chronyd です。このコマンドラインユーティリティーは /usr/bin/chronyc にインストールされます。

5.6.2. chronyd ステータスの確認

chronyd のステータスを確認するには、以下のコマンドを実行します。

~]$ systemctl status chronyd
chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)
   Active: active (running) since Wed 2013-06-12 22:23:16 CEST; 11h ago

5.6.3. chronyd の起動

chronyd を開始するには、root で以下のコマンドを実行します。

~]# systemctl start chronyd

システムの起動時に chronyd を自動的に起動するように設定するには、root で以下のコマンドを実行します。

~]# systemctl enable chronyd

5.6.4. chronyd の停止

chronyd を停止するには、root で以下のコマンドを実行します。

~]# systemctl stop chronyd

システムの起動時に chronyd を自動的に起動しないように設定するには、root で以下のコマンドを実行します。

~]# systemctl disable chronyd

5.6.5. chrony の同期確認

chrony が同期されているかどうかを確認するには、tracking コマンド、sources コマンド、および sourcestats コマンドを使用します。

5.6.5.1. chrony トラッキングの確認

chrony のトラッキングを確認するには、以下のコマンドを実行します。

~]$ chronyc tracking
Reference ID    : CB00710F (foo.example.net)
Stratum         : 3
Ref time (UTC)  : Fri Jan 27 09:49:17 2017
System time     :  0.000006523 seconds slow of NTP time
Last offset     : -0.000006747 seconds
RMS offset      : 0.000035822 seconds
Frequency       : 3.225 ppm slow
Residual freq   : 0.000 ppm
Skew            : 0.129 ppm
Root delay      : 0.013639022 seconds
Root dispersion : 0.001100737 seconds
Update interval : 64.2 seconds
Leap status     : Normal

各フィールドは、以下のとおりです。

Reference ID
コンピューターが同期しているサーバー (利用可能である場合) の参照 ID および参照名 (または IP アドレス) です。参照 ID は IPv4 アドレスとの混同を避けるため 16 進数の数値になっています。
Stratum
基準クロックのあるコンピューターから何ホップ離れているかを示します。上記の例のコンピューターは stratum-1 コンピューターであるため、2 ホップ離れていることになります (つまり、a.b.c が stratum-2 で、stratum-1 から同期しています)。
Ref time
参照ソースからの最後の測定が処理された時間 (UTC) です。
System time
chronyd は、通常の操作ではシステムクロックを更新しません。タイムスケールにおけるジャンプは、いかなるものでも特定のアプリケーションプログラムに有害な結果をもたらすためです。代わりに、システムクロックのエラーをわずかに早めたり遅くしたりして、エラーがなくなるまで修正し、修正が完了したら、システムクロックを通常のスピードに戻します。その結果、(gettimeofday() システムコールを使用した他のプログラム、またはシェルの日付コマンドが読み取る) システムクロックは、chronyd が予測する現在の実際の時間 (サーバーモードで稼働している場合はこれを NTP クライアントに報告) と異なることになります。この行で報告される値は、これによる差異です。
Last offset
最後のクロック更新におけるローカルオフセットの予測です。
RMS offset
長期的な、オフセット値の平均です。
Frequency
「frequency」は、chronyd が修正しない場合にシステムクロックが間違う変化量です。これは、ppm (100 万分の 1) で表されます。たとえば、1 ppm という値は、システムクロックにおける 1 秒が、実際の時間と比較すると 1.000001 秒進んでいることを意味します。
Residual freq

これは、現在選択されている基準源の「残留周波数」を示しています。これは、基準源からの測定値が、示すべき周波数と、実際に使用されている周波数との違いを反映しています。

これが常にゼロにならない理由は、補正する手順が周波数に提供されているためです。参照ソースから測定を取得し、新たな剰余周波数が計算されるたびに、この剰余の予測される正確性は、既存の周波数の値の予測される正確性 (skew を参照) と比較されます。新たな周波数の加重平均は、加重がその正確性に依存して計算されます。参照ソースからの測定に一貫した傾向がある場合、剰余は時間をかけてゼロになります。

Skew
周波数の予測されるエラー範囲です。
Root delay
コンピューターが最終的に同期する stratum-1 コンピューターの、ネットワークパスの遅延の合計数です。Root delay の値はナノ秒の分解能で出力されます。値は、極端な状況では負数になります (これは、コンピューター同士が互いの周波数を追跡せず、各コンピューターのターンアラウンド時間に比較してネットワークの遅延が非常に短い、対称的なピア配置において発生する場合があります)。
Root dispersion
コンピューターが最後に同期する stratum-1 コンピューターへ戻るすべてのコンピューターの分散を累積した合計値です。分散は、システムクロックの分解能や統計的測定の変動等に起因します。Root の分散値は、ナノ秒の分解能で出力されます。
Leap status
Leap のステータスで、Normal、Insert second、Delete second、または Not synchronized のいずれかになります。

5.6.5.2. chrony ソースの確認

sources コマンドは、chronyd がアクセスしている現行時間ソースの情報を表示します。

任意の引数 -v (verbose (詳細) の意) を指定できます。この例では、余分なキャプション行は、コラムの意味を説明するものとして表示されます。

~]$ chronyc sources
	210 Number of sources = 3
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#* GPS0                          0   4   377    11   -479ns[ -621ns] /-  134ns
^? a.b.c                         2   6   377    23   -923us[ -924us] +/-   43ms
^ d.e.f                         1   6   377    21  -2629us[-2619us] +/-   86ms

各コラムの表示内容は、以下のとおりです。

M
ソースのモードを示します。^ はサーバーを、= はピアを、# はローカル接続している基準クロックを意味します。
S
このコラムは、ソースの状態を示します。「*」は、chronyd が現在同期しているソースを示します。「+」は、選択したソースと結合する受け入れ可能なソースを示します。「-」は、受け入れ可能なソースで、結合アルゴリズムにより除外されたものを示します。「?」は、接続が切断されたソース、またはパケットがすべてのテストをパスしないソースを示します。「x」は、chronydfalseticker と考える (つまり、その時間が他の大半のソースと一致しない) クロックを示します。「~」は、時間の変動性が大きすぎるように見えるソースを示します。「?」条件は、少なくとも 3 つのサンプルが収集されるまで開始時にも表示されます。
Name/IP address
ソースの名前または IP アドレス、もしくは基準クロックの参照 ID を表示します。
Stratum
直近で受信したサンプルでレポートされているソースの stratum を表示します。Stratum 1 は、ローカルで基準クロックに接続されているコンピューターを示します。Stratum 1 コンピューターに同期しているコンピューターは、stratum 2 に存在することになります。Stratum 2 コンピューターに同期しているコンピューターは stratum 3 に存在することになり、以後も同様に続きます。
Poll

ソースがポーリングされるレートで、間隔のベース-2 対数を秒数で示します。つまり、値が 6 の場合は、64 秒ごとに測定が行われます。

chronyd は、一般的な条件に応じて、ポーリングレートを自動的に変更します。

Reach
ソースの到達可能性のレジスターで、8 進法で表示されます。レジスターは 8 ビットで、ソースからパケットを受信するたびに、またはミスするたびに更新されます。値が 377 の場合、最近の 8 回の通信全体についての有効な返信が受信されたことを意味します。
LastRx
このコラムは、ソースから最後のサンプルがいつ受信されたかを表示します。通常は、秒数で表示されます。mhd、および y の各文字は、それぞれ分、時間、日、年を意味します。値が 10 年の場合は、このソースからまだサンプルを受信していないことを示します。
Last sample
このコラムは、ローカルクロックと、最後に測定されたソースの間のオフセットを表示します。角括弧内の数字は、実際に測定されたオフセットを表示します。これには ns (ナノ秒)、us (マイクロ秒)、ms (ミリ秒)、または s (秒) の各接尾辞が付く場合があります。角括弧の左側は元の測定を示し、slew がそれ以降にローカルクロックに適用可能になるように調整されています。+/- に続く数字は、測定におけるエラーのマージンを示します。オフセットの値がプラスの場合は、ローカルクロックがソースよりも進んでいることを意味します。

5.6.5.3. chrony ソースの統計情報の確認

sourcestats コマンドは、chronyd が現在調べている各ソースに関するドリフト量とオフセット推定プロセスの情報を表示します。

任意の引数 -v (verbose (詳細) の意) を指定できます。この例では、余分なキャプション行は、コラムの意味を説明するものとして表示されます。

~]$ chronyc sourcestats
210 Number of sources = 1
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
===============================================================================
abc.def.ghi                11   5   46m     -0.001      0.045      1us    25us

各コラムの表示内容は、以下のとおりです。

Name/IP address
これは、NTP サーバー (またはピア) の名前または IP アドレス、またはその行の残りの部分が関連する基準クロックの参照 ID です。
NP
現在サーバーで保持されているサンプルポイントの数です。誤差レートと現在のオフセットは、このポイントを使って線形回帰を実行することで予測されます。
NR
最新の回帰を追跡している同一サインを持つ剰余の実行数です。この数字がサンプル数に対して少なくなりすぎる場合は、直線がデータに適合しなくなったことを意味します。実行数が少なすぎる場合、chronyd は古いサンプルを破棄し、実行数が受け入れ可能なものになるまで回帰を再実行します。
Span
一番古いサンプルと最新のサンプルの間隔です。単位が表示されない場合は、秒数を表しています。この例の間隔は 46 分です。
Frequency
これは予測されるサーバーの剰余周波数で、ppm (100 万分の 1) で表されます。このケースでは、コンピューターのクロックはサーバーよりも 109 分の 1 遅く実行していると推定されています。
Freq Skew
Freq の予測されるエラー範囲です (ppm (100 万分の 1) で表されます) 。
Offset
ソースの予測されるオフセットです。
Std Dev
サンプルの予測される標準偏差です。

5.6.6. システムクロックの手動調整

システムクロックを徐々に調整していく (slew) のを止め、一度に修正 (step) するには、root で以下のコマンドを実行します。

~]# chronyc makestep

rtcfile ディレクティブを使用している場合は、リアルタイムクロックを手動で調整しないでください。ランダムな調整を行うと、リアルタイムクロックがずれる変化量を測定する必要がある chrony に影響を与えます。

5.7. 異なる環境での chrony の設定

5.7.1. 孤立したネットワークでのシステムにおける chrony の設定

インターネットに接続していないネットワークに関しては、1 台のコンピューターをマスタータイムサーバーとし、もう 1 台のコンピューターをマスタータイムサーバーの直接クライアント、またはクライアントのクライアントとします。マスターでは、ドリフトファイルは、システムクロックのドリフトの平均率を使用して手動で設定します。マスターは、再起動すると周囲のシステムから時間を取得し、平均値を計算してシステムクロックを設定します。ドリフトファイルは settime コマンドが使用されたときに自動的に更新されます。

マスターにしたシステムで、root でテキストエディターを実行し、以下のように /etc/chrony.conf を実行します。

driftfile /var/lib/chrony/drift
commandkey 1
keyfile /etc/chrony.keys
initstepslew 10 client1 client3 client6
local stratum 8
manual
allow 192.0.2.0

192.0.2.0 は、クライアントが接続できるネットワークアドレスまたはサブネットアドレスです。

マスターのダイレクトクライアントにしたシステムで、root でテキストエディターを実行し、以下のように /etc/chrony.conf を実行します。

server master
driftfile /var/lib/chrony/drift
logdir /var/log/chrony
log measurements statistics tracking
keyfile /etc/chrony.keys
commandkey 24
local stratum 10
initstepslew 20 master
allow 192.0.2.123

ここでの 192.0.2.123 はマスターのアドレスで、master はマスターのホスト名になります。この設定になっているクライアントは、システムが再起動するとマスターと再同期を行います。

マスターの直接のクライアントにはならないクライアントシステムの /etc/chrony.conf ファイルでは、local ディレクティブおよび allow ディレクティブが省略される以外は同じになるべきです。

孤立したネットワークでは、ローカルの参照モードを有効にする local ディレクティブも使用できます。このモードは、NTP サーバーが一度も同期されていなかったり、クロックの最終更新から長い時間が経過している場合でも、NTP サーバーが実時間に同期したように見せる chronyd のオペレーションを可能にします。

複数のサーバーをポーリングしているクライアントを混同することなく、ネットワーク上の複数のサーバーに同じローカル設定を使用し、互いを同期させるには、Orphan モードを有効にする local ディレクティブの orphan オプションを使用します。各サーバーは、他のすべてのサーバーを local でポーリングするように設定する必要があります。これにより、最小の参照 ID を持つサーバーでのみローカル参照が有効になり、他のサーバーはそれに同期します。サーバーが有効化に失敗すると別のサーバーが引き継ぎます。

5.8. ハードウェアのタイムスタンプを使用した Chrony

5.8.1. ハードウェアタイムスタンプの概要

ハードウェアタイムスタンプは、一部の Network Interface Controller (NIC) でサポートされている機能です。これは、送受信されるパケットの正確なタイムスタンプを提供します。NTP タイムスタンプは通常、カーネルおよび chronyd がシステムクロックを使用して作成します。ただし、ハードウェアのタイムスタンプを有効にしていると、パケットがリンク層または物理層に出入りする際に、NIC が独自のクロックを使用してタイムスタンプを生成します。ハードウェアタイムスタンプを NTP と共に使用すると、同期の精度を大幅に向上できます。最高精度を実現するには、NTP サーバーと NTP クライアントの両方がハードウェアタイムスタンプを使用している必要があります。理想的な条件下では、サブマイクロ秒単位の精度を実現できるかもしれません。

ハードウェアのタイムスタンプを使用する時間同期の別のプロトコルには、PTP があります。

NTP とは異なり、PTP は、ネットワークスイッチおよびルーターの補助に依存しています。同期の精度を最高の状態にしたい場合は、PTP をサポートしているスイッチやルーターがあるネットワークで PTP 使用し、そのようなスイッチおよびルーターがないネットワークでは NTP を使用することが推奨されます。

5.8.2. ハードウェアタイムスタンプのサポートの確認

NTP を使用したハードウェアのタイムスタンプがインターフェースで、サポートされていることを確認するには、ethtool -T コマンドを実行します。ethtool が、SOF_TIMESTAMPING_TX_HARDWARE 機能および SOF_TIMESTAMPING_TX_SOFTWARE 機能と、HWTSTAMP_FILTER_ALL フィルターモードを一覧表示する場合は、NTP でハードウェアタイムスタンプにインターフェースが使用できます。

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

5.8.3. ハードウェアタイムスタンプの有効化

ハードウェアタイムスタンプを有効にするには、/etc/chrony.conf ファイルの hwtimestamp ディレクティブを使用します。ディレクティブは、個別のインターフェースを指定できますが、ワイルドカードキャラクターを使用して、ハードウェアタイムスタンプをサポートするすべてのインターフェースでハードウェアタイムスタンプを有効にすることもできます。linuxptp パッケージの ptp4l などのアプリケーションなど、そのインターフェースでその他のアプリケーションがハードウェアタイムスタンプを使用していない場合があるため、ワイルドカード仕様を使用してください。chrony 設定ファイルで、複数の hwtimestamp ディレクティブが使用されます。

例5.2 hwtimestamp のディレクティブを使用したハードウェアタイムスタンプの有効化

hwtimestamp eth0
hwtimestamp eth1
hwtimestamp *

5.8.4. クライアントポーリング間隔の設定

インターネット上のサーバーのポーリング間隔は、デフォルトの範囲である 64 秒から 1024 秒が推奨されています。ローカルサーバーおよびハードウェアのタイムスタンプでは、システムクロックのオフセットを最小限にとどめるため、ポーリング間隔は短く設定する必要があります。

/etc/chrony.conf における以下のディレクティブは、1 秒のポーリング間隔を使用してローカルの NTP サーバーを指定します。

server ntp.local minpoll 0 maxpoll 0

5.8.5. インターリーブモードの有効化

ハードウェアの NTP アプライアンスではなく、chrony など、ソフトウェアの NTP 実装を実行する汎用コンピューターの NTP サーバーは、パケット送信後にのみハードウェア転送先タイムスタンプを取得します。この動作により、サーバーは、対応するパケットのタイムスタンプを保存できません。NTP クライアントが、転送後に生成された転送先タイムスタンプを受け取るようにするには、/etc/chrony.conf のサーバーディレクティブに xleave オプションを追加し、クライアントが NTP インターリーブモードを使用するように設定します。

server ntp.local minpoll 0 maxpoll 0 xleave

5.8.6. 多数のクライアント向けのサーバーの設定

デフォルトのサーバー設定では、最多で数千のクライアントが同時にインターリーブモードを使用できます。さらに多くのクライアント向けにサーバーを設定するには、/etc/chrony.confclientloglimit ディレクティブを増やします。このディレクティブは、サーバーでクライアントのアクセスログに割り当てられるメモリーの最大サイズを指定します。

clientloglimit 100000000

5.8.7. ハードウェアタイムスタンプの確認

インターフェースがハードウェアタイムスタンプを有効にできたことを確認するには、システムログを確認してください。ログには、chronyd からの各インターフェース向けメッセージに、有効にしたハードウェアタイムスタンプが追記されているはずです。

例5.3 ハードウェアタイムスタンプが有効になったインターフェースのログメッセージ

chronyd[4081]: Enabled HW timestamping on eth0
chronyd[4081]: Enabled HW timestamping on eth1

chronyd が、NTP クライアントまたはピアとして設定されている場合は、chronyc ntpdata コマンドにより、転送先と受信先のタイムスタンプ及びインターリーブモードを、各 NTP ソースに報告できます。

例5.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

例5.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

5.8.8. PTP-NTP ブリッジの設定

非常に精度が高い Precision Time Protocol (PTP) のグランドマスターが、PTP サポートのあるスイッチまたはルーターを持たないネットワークで利用可能な場合、コンピューターは、PTP スレーブおよび stratum-1 NTP サーバーとしての操作に専念する可能性があります。このようなコンピューターには、2 つ以上のネットワークインターフェースが必要なほか、グランドマスターに近いか、またはグランドマスターと直接接続されている必要があります。これにより、ネットーワークで非常に精度の高い同期が確実に実行されます。

1 つのインターフェースを使用して PTP を使用してシステムクロックを同期するように、linuxptp パッケージの ptp4l プログラムおよび phc2sys プログラムを設定します。

chronyd を設定して、その他のインターフェースを使用してシステム時間を提供するには、以下を行います。

例5.6 その他のインターフェースを使用してシステム時間を提供するように chronyd の設定

bindaddress 203.0.113.74
hwtimestamp eth1
local stratum 1

5.9. chrony において、以前 NTP でサポートされていたいくつかの設定を実現

ntp がサポートする Red Hat Enterprise Linux のメジャーバージョンにあった一部の設定が、chrony ではサポートされません。このセクションはそのような設定の一覧と、chrony を使用して、システムでそれを実現する方法を説明します。

5.9.1. ntpq および ntpdc によるモニタリング

chronyd は、ntp ディストリビューションの ntpq ユーティリティーおよび ntpdc ユーティリティーからは監視できません。なぜなら、chrony は、NTP モード 6 および 7 をサポートしないためです。これは、別のプロトコルをサポートし、 chronyc はクライアント実装です。詳細は man ページの chronyc(1) を参照してください。

chronyd で同期しているシステムクロックの状態を監視するには、次のことができます。

  • 追跡コマンドの使用
  • ntpstat ユーティリティーを使用します。これは、chrony をサポートし、ntpd で使用されたときと同様の出力を提供します。

例5.7 追跡コマンドの使用

$ chronyc -n tracking
Reference ID    : 0A051B0A (10.5.27.10)
Stratum         : 2
Ref time (UTC)  : Thu Mar 08 15:46:20 2018
System time     : 0.000000338 seconds slow of NTP time
Last offset     : +0.000339408 seconds
RMS offset      : 0.000339408 seconds
Frequency       : 2.968 ppm slow
Residual freq   : +0.001 ppm
Skew            : 3.336 ppm
Root delay      : 0.157559142 seconds
Root dispersion : 0.001339232 seconds
Update interval : 64.5 seconds
Leap status     : Normal

例5.8 ntpstat ユーティリティーの使用

$ ntpstat
synchronised to NTP server (10.5.27.10) at stratum 2
   time correct to within 80 ms
   polling server every 64 s

5.9.2. 公開鍵暗号に基づく認証メカニズムの使用

Red Hat Enterprise Linux 7 では、ntp がサポートする Autokey は、公開鍵暗号に基づく認証メカニズムです。Autokeychronyd ではサポートされていません。

Red Hat Enterprise Linux 8 システムでは、対称鍵を代わりに使用することが推奨されます。鍵の作成には chronyc keygen コマンドを使用します。クライアントおよびサーバーは、/etc/chrony.keys で指定した鍵を共有する必要があります。クライアントは、serverpoolpeer の各ディレクティブで、key オプションを使用して認証を有効にできます。

5.9.3. 一時的な対称関係の使用

Red Hat Enterprise Linux 7 では、ntpd が、ntp.conf 設定ファイルで指定しないピアからのパケットにより収集できる一時的な対称関係をサポートしていました。Red Hat Enterprise Linux 8 では、chronyd は、chrony.conf ですべてのピアを指定する必要があります。一時的な対称関係はサポートされません。

peer ディレクティブで有効にした対象モードと比べると、server ディレクティブまたは pool ディレクティブで有効になっているクライアント/サーバーモードを使用したほうが安全です。

5.9.4. マルチキャストまたはブロードキャストのクライアント

Red Hat Enterprise Linux 7 は、クライアントの設定を簡素化するブロードキャスト/マルチキャストの NTP モードをサポートしていました。このモードでは、個々のユーザーの特定名またはアドレスに対してリッスンする代わりに、マルチキャスト/ブロードキャストのアドレスに送られらたパケットのみをリッスンするようにクライアントを設定できます。これは、時間の経過とともに変化する場合があります。

Red Hat Enterprise Linux 8 では、chronyd はブロードキャストモードまたはマルチキャストモードをサポートしていません。主な理由は、通常のクライアント/サーバーおよび対象モードに比べて、あまり正確でなく、セキュリティーも保護されていないからです。

NTP のブロードキャスト/マルチキャスト設定からの移行には、オプションがいくつかあります。

  • 1 つの名前 (ntp.example.com など) を、異なるサーバーの複数のアドレスに変換するように DNS を設定します。

    クライアントには、複数サーバーと同期するために、プールディレクティブを 1 つだけ使用した静的な設定を指定できます。サーバーがプールから到達できない場合、または同期に適切ではない場合、クライアントは自動的に、プールの別サーバーに置き換えます。

  • DHCP における NTP サーバーリストを配布します。

    NetworkManager が、DHCP サーバーから NTP サーバーの一覧を取得すると、それを使用するように chronyd が自動的に設定されます。この機能は、PEERNTP=no/etc/sysconfig/network ファイルに追加すると無効にできます。

  • Precision Time Protocol (PTP) を使用します。

    このオプションは、サーバーが頻繁に変更する環境、または、大規模なクライアントグループが、宛先サーバーを持たずに、相互に同期できるようにする必要がある場合に主に適しています。

    PTP は、マルチキャストメッセージング用に設計されており、NTP ブロードキャストモードと同じように動作します。PTP 実装は、linuxptp パッケージから入手できます。

    通常、PTP が適切に動作するには、ハードウェアタイムスタンプとネットワークスイッチのサポートが必要になります。ただし、ブロードキャストモードでは、ソフトウェアタイムスタンプを使用し、ネットワークスイッチのサポートがない場合でも、PTP の方が NTP よりも適しています。

    1 つの通信経路に非常に多くの PTP スレーブがあるネットワークでは、そのスレーブが生成したネットワークトラフィックの量を減らすために、hybrid_e2e オプションで PTP スレーブを設定することが推奨されます。NTP クライアント (場合により NTP サーバー) として chronyd を実行するコンピューターを設定し、マルチキャストメッセージングを使用して、同期した時間を多数のコンピューターに配信する PTP グランドマスターとして動作させることができます。

5.10. 関連資料

以下の資料は、chrony に関するその他の情報を提供します。

5.10.1. インストールされているドキュメント

  • chronyc(1) の man ページ - chronyc コマンドラインインターフェースと、そのコマンドおよびコマンドオプションを説明します。
  • chronyd(8) の man ページ - chronyd デーモンと、そのコマンドおよびコマンドオプションが説明されています。
  • man ページの chrony.conf(5) - chrony 設定ファイルが説明されています。

5.10.2. オンラインのドキュメント

FAQ への回答は https://chrony.tuxfamily.org/faq.html を参照してください。

第6章 Red Hat Enterprise Linux 8 での Python の使用

6.1. Python の概要

Python は、オブジェクト指向、命令、機能、手順などの複数のプログラミングパラダイムをサポートする高レベルのプログラミング言語です。Python は動的なセマンティクスを持ち、汎用プログラミングに使用できます。

Red Hat Enterprise Linux では、システムツールを提供するパッケージ、データ分析または Web アプリケーションのツールなど、システムにインストールされている多くのパッケージは、Python で記述されています。このパッケージを使用できるようにするには、python パッケージがインストールされている必要があります。

6.1.1. Python のバージョン

Python で互換性のない 2 つのバージョン (Python 2.x および Python 3.x) が広く使用されています。

Red Hat Enterprise Linux 8 では、デフォルトで Python 3.6 を使用しますが、既存ソフトウェアをサポートするために Python 2.7 も提供されています。

警告

デフォルトの python パッケージまたはバージョンを指定しない /usr/bin/python 実行ファイルは、いずれも Red Hat Enterprise Linux 8 では配布されません。

重要

Python のインストール時、起動時、対話時にはメジャーバージョンを常に指定します。たとえば、パッケージ名またはコマンド名で、python の代わりに python3 を使用します。Python 関連のすべてのコマンドにもバージョンを含む必要があります (pip3pip2 など)。

もしくは、「バージョンを指定しない Python の設定」 の説明に従って alternatives コマンドを使用して、システムのデフォルトバージョンを設定します。

以下の理由により、システム管理者は 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 から選択できます。

6.1.2. 内部プラットフォームの python パッケージ

Red Hat Enterprise Linux 8 のシステムツールは、内部の platform-python パッケージで提供される Python バージョン 3.6 を使用します。Red Hat は、代わりに python36 パッケージを使用することを推奨します。

6.2. Python のインストールおよび使用

警告

バージョンを指定しない python コマンドを使用して Python をインストールまたは実行すると曖昧なためデフォルトでは動作しません。「Python 3 のインストールおよび使用」および「Python 2 のインストールおよび使用」の説明に従って、Python のメジャーバージョンを常に指定します。「バージョンを指定しない Python の設定」 の説明に従って、alternatives コマンドを使用して、システムのデフォルトバージョンを設定します。

6.2.1. Python 3 のインストールおよび使用

Red Hat Enterprise Linux 8 では、Python 3 は、AppStream リポジトリーの python36 モジュールとして配信されます。

モジュールの詳細は 『Application Stream の使用』 を参照してください。

6.2.1.1. Python 3 のインストール

Python 3 をインストールするには、root で以下のコマンドを実行します。

yum install python3

このコマンドは、AppStream の python36 から Python 3.6 をインストールします。

6.2.1.2. Python 3 の使用

Python 3 を実行するには、python3 コマンドを実行します。その他のすべての関連コマンドでこのバージョンを使用します (例: pip3)。

6.2.1.3. Python 3 パッケージの命名規則

Python 3 用のアドオンモジュールのパッケージは、通常、接頭辞 python3- を使用します。

たとえば、HTTP クライアントを書き込むために使用される Requests モジュールをインストールするには、以下のコマンドを実行します。

yum install python3-requests

6.2.2. Python 2 のインストールおよび使用

一部のソフトウェアは Python 3 に完全には移植されておらず、動作するのに Python 2 が必要となります。Red Hat Enterprise Linux 8 では、Python 3 と Python 2 を同時にインストールできます。Python 2 機能が必要な場合は python27 モジュールをインストールしてください。これは AppStream リポジトリーで利用できます。

モジュールの詳細は 『Application Stream の使用』 を参照してください。

警告

Python 3 は、Python プロジェクトの主な開発方針です。Python 2 のサポートは終了しつつあります。python27 モジュールは、Red Hat Enterprise Linux 8 でのサポート期間が短くなります。

6.2.2.1. Python 2 のインストール

Python 2 をインストールするには、root で以下のコマンドを実行します。

yum install python2

このコマンドは、AppStream の python27 から Python 2.7 をインストールします。

6.2.2.2. Python 2 の使用

Python 2 を実行するには、python2 コマンドを実行します。その他のすべての関連コマンドでこのバージョンを使用します (例: pip2)。

6.2.2.2.1. Python 2 パッケージの命名規則

Python 2 用のアドオンモジュールのパッケージは、通常、接頭辞 python2- を使用します。

たとえば、HTTP クライアントを書き込むために使用される Requests モジュールをインストールするには、以下のコマンドを実行します。

yum install python2-requests

6.2.3. バージョンを指定しない Python の設定

システム管理者は、alternatives コマンドを使用して、バージョンを管理しない python コマンドを設定できます。必要なパッケージ (python3 または python2) は、バージョンを指定しないコマンドを各バージョンに設定する前にインストールする必要があります。

バージョンを指定しない python コマンドを Python 3 に直接設定するには、以下のコマンドを実行します。

alternatives --set python /usr/bin/python3

Python 2 を選択した場合は類似コマンドを使用してください。

もしくは、対話式に、バージョンを指定しない python コマンドを設定できます。

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

    alternatives --config python
  2. 表示された一覧から必要なバージョンを選択します。

この設定をリセットし、バージョンを指定しない python をコマンドを削除するには、以下のコマンドを実行します。

alternatives --auto python
警告

その他の Python 関連のコマンド (pip3) には、バージョンを指定しないで設定可能なバリアントがあります。

6.3. Python 2 から Python 3 への移行

開発者は、Python 2 で記述したコードを Python 3 に移行できます。大規模なコードベースを Python 3 に移行する方法は 「The Conservative Python 3 Porting Guide」 を参照してください。

この移行が終了すると、元の Python 2 コードは Python 3 インタープリターにより解釈できるようになり、同様に Python 2 インタープリターは解釈できるままとなることに注意してください。

6.4. Python 3 RPM のパッケージング

ほとんどの Python プロジェクトは、パッケージングに Setuptools を使用して、setup.py ファイルにパッケージ情報を定義します。Setuptools パッケージングの詳細は Setuptools ドキュメント を参照してください。

Python プロジェクトを RPM パッケージにパッケージ化することもできます。これには、Setuptools パッケージングと比較して以下の以下の利点があります。

  • (Pythonでなくても) その他の RPM のパッケージの依存関係の指定
  • 電子署名

    電子署名を使用すると、RPM パッケージの内容は、オペレーティングシステムのその他の部分とともに検証、統合、およびテストできます。

RPM パッケージングの詳細は、『RPM Packaging Guide』 を参照してください。

6.4.1. Python RPM パッケージ用の典型的な SPEC ファイルの説明

SPEC ファイルには、RPM を構築するために rpmbuild ユーティリティーが使用する命令が含まれています。命令は、一連のセクションに含まれています。SPEC ファイルには、セクションが定義されている 2 つの主要部分があります。

  • プリアンブル (ボディーに使用されている一連のメタデータ項目が含まれています)
  • ボディー (命令の主要部分が含まれています)

SPEC ファイルの詳細は 『RPM Packaging Guide』 を参照してください。

Python プロジェクトの RPM SPEC ファイルには、非 Python RPM SPEC ファイルと比較していくつかの詳細があります。中でも注目すべきは、Python ライブラリーの RPM パッケージの名前に、python3 接頭辞が常に指定されている必要があるということです。

その他の詳細は、次の SPEC ファイルの python3-detox パッケージの例 に記載されています。その詳細の説明は、例の下に記載されている注意事項を参照してください。

%global modname detox                                                           1

Name:           python3-detox                                                   2
Version:        0.12
Release:        4%{?dist}
Summary:        Distributing activities of the tox tool
License:        MIT
URL:            https://pypi.io/project/detox
Source0:        https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  python36-devel                                                  3
BuildRequires:  python3-setuptools
BuildRequires:  python36-rpm-macros
BuildRequires:  python3-six
BuildRequires:  python3-tox
BuildRequires:  python3-py
BuildRequires:  python3-eventlet

%?python_enable_dependency_generator                                            4

%description

Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel.
Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox.

    $ detox

%prep
%autosetup -n %{modname}-%{version}

%build
%py3_build                                                                      5

%install
%py3_install

%check
%{__python3} setup.py test                                                      6

%files -n python3-%{modname}
%doc CHANGELOG
%license LICENSE
%{_bindir}/detox
%{python3_sitelib}/%{modname}/
%{python3_sitelib}/%{modname}-%{version}*

%changelog
...
1
modname マクロは、Python プロジェクトの名前が含まれます。この例では detox となります。
2
Python プロジェクトを RPM にパッケージ化する場合は、常にプロジェクトの元の名前に接頭辞 python3 を追加する必要があります。ここでの元の名前は detox で、RPM の名前python3-detox です。
3
BuildRequires は、このパッケージのビルドおよびテストに必要なパッケージを指定します。BuildRequires では、Python パッケージをビルドするのに必要なツールを提供する項目 (python36-devel および python3-setuptools) が常に含まれます。/usr/bin/python3 shebangs があるファイルが自動的に /usr/bin/python3.6 に変更されるようにするには、python36-rpm-macros パッケージが必要です。詳細は 「Python スクリプトにおける hashban の処理」 を参照してください。
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 など) が含まれます。リテラルパスではなく、マクロを使用することが常に推奨されます。

6.4.2. Python 3 RPM パッケージ用の一般的なマクロ

SPEC ファイルでは、常にその値をハードコーディングするのではなく、以下のマクロを使用します。

マクロ名では、バージョンを指定しない python ではなく、python3 または python2 を使用してください。

マクロ一般的な定義説明

%{__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 コマンドを実行します。

6.4.3. Python RPM パッケージの自動 Provides

Python プロジェクトをパッケージ化する際、以下のディレクトリーが存在する場合は、結果の RPM に含まれます。

  • .dist-info
  • .egg-info
  • .egg-link

このディレクトリーから、RPM ビルドプロセスは自動的に仮想 pythonX.Ydist Provides (python3.6dist(detox) など) を生成します。この仮想 Provides は、%python_enable_dependency_generator マクロにより指定されるパッケージにより提供されます。

6.4.4. Python スクリプトにおける hashban の処理

Red Hat Enterprise Linux 8 では、実行可能な Python スクリプトが、主な Python バージョンを明示的に指定する hashbang (shebangs) を使用することを期待します。

/usr/lib/rpm/redhat/brp-mangle-shebangs BRP (buildroot policy) スクリプトは、RPM パッケージを構築する際に自動的に実行され、実行可能なすべてのファイルで hashbang を修正します。BRP スクリプトは、以下のようにあいまいな hashbang で Python スクリプトが発生すると、エラーが作成されます。

#! /usr/bin/python

または

#! /usr/bin/env python

Python スクリプトで、RPM ビルド時にエラーが発生する hashbang を修正するには、platform-python-devel パッケージの pathfix.py スクリプトを使用します。

pathfix.py -pn -i %{__python3} PATH …​

複数の PATH を指定できます。PATH がディレクトリーの場合、pathfix.py は Python スクリプトを再起的にスキャンして、^[a-zA-Z0-9_]+\.py$ パターンに一致するものを探します。これは、あいまいな hashbang があるものだけではありません。このコマンドを %prep セクション、または %install セクションに追加します。

別の方法として、パッケージ化した Python スクリプトを、期待されるフォーマットに準拠するように変更します。この目的のために、pathfix.py は、RPM ビルドプロセス以外でも使用できます。pathfix.py を RPM ビルド以外で実行する場合は、上述の例の __python3 を、hashbang のパス (/usr/bin/python3 など) に置き換えます。

パッケージ化した Python スクリプトに Python バージョン 2 が必要な場合は、上記コマンドで 3 を 2 に置き換えます。

また、/usr/bin/python3 の形式での hashbang は、Red Hat Enterprise Linux を使用するシステムツールに使用される platform-python の Python を示す hashbang にデフォルトで置き換えられます。

カスタムパッケージで /usr/bin/python3 hashbang を変更して、/usr/bin/python3.6 の形式で、Application Stream からインストールする Python のバージョンを指定するには、SPEC ファイルの BuildRequires セクションに python36-rpm-macros パッケージを追加します。

BuildRequires:  python36-rpm-macros
注記

BRP スクリプトが hashbang の確認と修正を行わないようにするには、以下の RPM ディレクティブを使用します。

%undefine %brp_mangle_shebangs

第7章 言語パックのインストールおよび使用

7.1. 言語パッケージの概要

Langpacks は、システムにインストールされているすべてのパッケージに対する翻訳、ディクショナリー、およびロケールを含む追加のアドオンパッケージをインストールするメタパッケージです。

Red Hat Enterprise Linux 8 システムでは、langpacks インストールは langpacks-<langcode> 言語メタパッケージおよび RPM の弱い依存関係 (補完タグ) に基づいています。

選択した言語に langpacks を使用する条件が 2 つあります。

  1. 選択した言語の langpacks-<langcode> 言語メタパッケージがインストールされている。

    Red Hat Enterprise Linux 8 では、言語パックのメタパッケージは、Application Stream リポジトリーで利用できるため、Anaconda インストーラーを使用して、オペレーティングシステムの初期インストールで自動的にインストールされます。

    どの言語が言語パックを提供するかを確認するには、以下のコマンドを実行します。

    ~]# yum list langpacks-*
  2. ローカルパッケージを検索するベースパッケージは、システムにすでにインストールされています。

この前提条件が満たされている場合は、言語のメタパッケージが選択した言語の言語パックをトランザクションセットに自動的に取得します。

7.2. RPM の弱い依存関係ベースの言語パックでの作業

7.2.1. RPM の弱い依存関係ベースの言語パックのクエリー

インストールされている言語サポートの一覧を表示するには、以下のコマンドを実行します。

~]# yum list installed langpacks*

別の言語に言語サポートが利用できるかどうかを確認するには、以下のコマンドを実行します。

~]# yum list available langpacks*

任意の言語にインストールしたパッケージの一覧を取得するには、以下のコマンドを実行します。

~]# yum repoquery --whatsupplements langpacks-<locale_code>

7.2.2. 言語サポートのインストール

新しい言語サポートを追加するには、root で以下のコマンドを実行します。

~]# yum install langpacks-<locale_code>

7.2.3. 言語サポートの削除

インストールされている言語サポートを削除するには、root で以下のコマンドを実行します。

~]# yum remove langpacks-<locale_code>

7.3. glibc-langpack-<locale_code> を使用したディスク領域の節約

現在、すべてのロケールは /usr/lib/locale/locale-archive ファイルに格納されますが、多くのディスク領域が必要になります。

コンテナーやクラウドなど、ディスク容量が重要なシステム、または少数のロケールが必要なシステムでは、glibc ロケール言語パックパッケージ (glibc-langpack-<locale_code>) を使用できます。「言語サポートのインストール」 で説明されている内容ではなく、以下のコマンドを使用すると個別のロケールをインストールできるため、パッケージインストールフットプリントはより小さくなります。

~]# yum install glibc-langpack-<locale_code>

Anaconda でオペレーティングシステムをインストールする場合は、インストール時に使用する言語と、追加言語として選択した言語の glibc-langpack-<locale_code> がインストールされます。すべてのロケールが含まれている glibc-all-langpacks はデフォルトでインストールされており、一部のロケールだけをインストールすることは非推奨であることに注意してください。1 つ以上の選択した言語の glibc-langpack-<locale_code> をインストールする場合は、インストール後に glibc-all-langpacks を削除して、ディスク領域を空けることができます。

glibc-all-langpacks の代わりに、選択した glibc-langpack-<locale_code> パッケージだけをインストールすると、ランタイムパフォーマンスに影響を及ぼします。

注記

ディスク領域が問題でない場合は、glibc-all-langpacks パッケージを使用してすべてのロケールをインストールします。

第8章 Red Hat Enterprise Linux 8 の Tcl/Tk の概要

8.1. Tcl/Tk の概要

Tool command language (Tcl) は、動的なプログラミング言語です。この言語のインタープリターと C ライブラリーは、tcl パッケージにより提供されます。

Tk (Tcl/Tk) とともに Tcl を使用すると、プラットフォーム間共通の GUI アプリケーションを作成できます。Tk は、tk パッケージから入手できます。

Tk は、以下のいずれかを参照します。

  • 複数言語のプログラミングツールキット
  • Tk C ライブラリーバインディングは、C、Ruby、Perl、Python などの複数言語で利用できます。
  • Tk コンソールのインスタンスを作成する wish インタープリター
  • 特定の Tcl インタープリターに新しいコマンドを多数追加する Tk の拡張

Tcl/Tk の詳細は、Tcl/Tk マニュアルまたは Tcl/Tk ドキュメントの Web ページ を参照してください。

8.2. Tcl/Tk 8.6 に関する注目すべき変更点

Tcl/Tk 8.5 と比較した Tcl/Tk 8.6 における主な変更点は以下の通りです。

  • オブジェクト指向のプログラミングサポート
  • スタックレス評価の実装
  • 強化された例外処理
  • Tcl で構築およびインストールしたサードパーティーパッケージのコレクション
  • 有効なマルチスレッド操作
  • SQL データベースを提供するスクリプトサポート
  • IPv6 ネットワーキングサポート
  • ビルドインの zlib 圧縮
  • リスト処理

    新しい 2 つのコマンド lmap および dict map が利用できます。これにより、Tcl コンテナーにおける変換の表現が可能になります。

  • スクリプトによって積み上げられたチャンネル

    新しい 2 つのコマンド chan push および chan pop が利用できるため、I/O チャンネルへ、または I/O からのチャンネルへの変換を追加または削除できます。

Tk の主な変更は、以下のようになります。

  • ビルドイン PNG イメージサポート
  • ビジーウィンドウ

    新しいコマンド tk busy が利用できます。これは、ウィンドウまたはウィジェットのユーザーとの対話を無効にし、ビジーカーソルが表示されます。

  • 新しいフォント選択ダイアログインターフェース
  • 角度のついたテキストサポート
  • キャンバスサポートでの移動

Tcl 8.5 から Tcl 8.6 への変更点の詳細は 「Changes in Tcl/Tk 8.6」 を参照してください。

8.3. Tcl/Tk 8.6 への移行

Red Hat Enterprise Linux 7 では Tcl/Tk 8.5 が使用されていました。Red Hat Enterprise Linux 8 では、Tcl/Tk version 8.6 は、Base OS リポジトリーで提供されます。

本セクションでは、以下を対象に、Tcl/Tk 8.6 への移行パスを説明します。

8.3.1. Tcl 拡張機能の開発者のための移行パス

Tcl 8.6 は、interp 構造のメンバーへの直接アクセスを制限します。たとえば、コードが interp→errorLine を読み込む場合は、Tcl_GetErrorLine(interp) 関数を使用するコードを書き直します。

コードを、Tcl 8.5 および Tcl 8.6 の両方と互換性を持たせるには、C または C++ アプリケーションのヘッダーファイル、または Tcl ライブラリーを含む拡張に、以下のコードスニペットを使用してください。

# include <tcl.h>
# if !defined(Tcl_GetErrorLine)
# define Tcl_GetErrorLine(interp) (interp→errorLine)
# endif

8.3.2. Tcl/Tk を使用してタスクのスクリプトを作成したユーザーのパスの移行

Tcl 8.6 では、ほとんどのスクリプトが、以前のバージョン Tcl と同じように動作します。ポータブルなコードを記載する場合は、Tk 8.6 でサポートされないコマンドを使用しないようにする必要があります。

  • tkIconList_Arrange
  • tkIconList_AutoScan
  • tkIconList_Btn1
  • tkIconList_Config
  • tkIconList_Create
  • tkIconList_CtrlBtn1
  • tkIconList_Curselection
  • tkIconList_DeleteAll
  • tkIconList_Double1
  • tkIconList_DrawSelection
  • tkIconList_FocusIn
  • tkIconList_FocusOut
  • tkIconList_Get
  • tkIconList_Goto
  • tkIconList_Index
  • tkIconList_Invoke
  • tkIconList_KeyPress
  • tkIconList_Leave1
  • tkIconList_LeftRight
  • tkIconList_Motion1
  • tkIconList_Reset
  • tkIconList_ReturnKey
  • tkIconList_See
  • tkIconList_Select
  • tkIconList_Selection
  • tkIconList_ShiftBtn1
  • tkIconList_UpDown

サポートされていないコマンドの一覧は、 /usr/share/tk8.6/unsupported.tcl ファイルで確認できます。

第9章 イーサネットネットワークインターフェイスの命名に prefixdevname を使用

このドキュメントは、イーサネットネットワークインターフェースへの一貫した命名規則を利用しない場合に、インタフェースの名前に接頭辞を設定する方法を説明します。

ただし、Red Hat は、Red Hat Enterprise Linux 7 と同じデフォルトの命名規則を使用することを推奨します。このスキームの詳細は『Consistent Network Device Naming』を参照してください。

9.1. prefixdevname の概要

prefixdevname ツールは、Ethernet ネットワークインターフェースの命名に使用した接頭辞を定義する udev ヘルパーユーティリティーです。

9.2. prefixdevname の設定

prefixdevname を使用した接頭辞の設定は、システムのインストール時に行われます。

イーサネットネットワークインターフェースに必要な接頭辞を設定にして有効にするには、カーネルコマンドラインに次の行を追加します。

net.ifnames.prefix=<required prefix>
警告

Red Hat は、デプロイ済みのシステムで prefixdevname を使用することはサポートしていません。

接頭辞を一度設定し、オペレーティングシステムを再起動すると、接頭辞は、ネットワークインターフェースが表示されるたびに有効になります。新しいデバイスは、<PREFIX><INDEX> の形式で名前に割り当てられます。たとえば、選択した接頭辞が net で、net0 接頭辞および net1 接頭辞がシステムにすでに存在している場合、新しいインターフェースの名前は net2 となります。次に、prefixdevname ユーティリティーは、新しい .link ファイルを /etc/systemd/network ディレクトリーに生成し、表示されたばかりの MAC アドレスを持つインターフェイスにその名前を適用します。この設定は、システムを再起動しても持続します。

9.3. prefixdevname の制限事項

イーサネットネットワークインターフェースの接頭辞には一定の制限があります。

選択する接頭辞は、次の要件を満たす必要があります。

  • ASCII 文字列である
  • 英数字文字列である
  • 16 文字を超えないこと
警告

この接頭辞は、Linux の命名に使用される周知な接頭辞 (ethenoensem など) と競合させることはできません。

法律上の通知

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.