次の手順では、Web コンソールで実行するシステムの再起動を説明します。

選択した内容で、システムが再起動します。

次の手順では、Web コンソールで実行したシステムのシャットダウンを説明します。

選択した内容に従って、システムの電源がオフになります。

ホスト名はシステムを識別します。デフォルトでは、ホスト名は localhost に設定されていますが、変更できます。

ホスト名は、以下の 2 つの部分から構成されます。

RHEL Web コンソールで Pretty ホスト名を設定することもできます。Pretty ホスト名には、大文字やスペースなどのホスト名を入力できます。Pretty ホスト名は Web コンソールに表示されますが、ホスト名に対応させる必要はありません。

例:

Pretty ホスト名 - My Machine

ホスト名: mymachine

実際のホスト名 (完全修飾ドメイン名): mymachine.idm.company.com

ホスト名は /etc/hostname ファイルに保存されますが、Web コンソールでホスト名を設定したり変更したりできます。

ホスト名が適切に設定されていることを確認するには、Web コンソールからログアウトして、新しいホスト名を使用してブラウザーにアドレスを追加します。

次の手順では、RHEL 8 システムを IdM ドメインに参加させる方法を説明します。

システムが IdM ドメインに参加していると、RHEL 8 Web コンソールにエラーが表示されず、システム 画面でドメイン名を確認できます。

本セクションでは、以下の設定方法を説明します。

この変更が、システム タブで利用できるようになります。

Red Hat Enterprise Linux 8 には、以下を最適化するパフォーマンスプロファイルが同梱されています。

次の手順では、Web コンソールでパフォーマンスプロファイルを設定する方法を説明します。

RHEL 8 Web コンソールでは、tuned サービスを構成します。

tuned サービスの詳細は、『システムの状態とパフォーマンスの監視と管理』を参照してください。

この変更が、システム タブで利用できるようになります。

本セクションでは、CPU の同時マルチスレッドを悪用した攻撃が発生した場合に、SMT (Simultaneous Multi Threading) を無効にする方法を説明します。

SMT を無効にすると、以下のような新しいタイプの Intel プロセッサーにおけるセキュリティー脆弱性を回避できます。

この構成では、システムを再起動する必要があります。

システムの再起動後、CPU は同時マルチスレッドを使用しません。

Red Hat Enterprise Linux システムロールは、複数の RHEL システムをリモートで管理する構成インターフェースを提供する Ansible ロールおよびモジュールの集合です。このインターフェースは、RHEL の複数のバージョンにわたるシステム設定の管理と、新しいメジャーリリースの導入を可能にします。

Red Hat Enterprise Linux 7.4 で、Red Hat Enterprise Linux システムロールが導入されました。詳細は、Red Hat ナレッジベースの記事「Red Hat Enterprise Linux (RHEL) System Roles」を参照してください。

Red Hat Enterprise Linux 8 には、現在、以下のロールから構成されます。

これらのロールはすべて、AppStream リポジトリーで利用可能な rhel-system-roles パッケージで提供されます。

特定のロールを適用するには、以下の前提条件を満たす必要があります。

特定のロールを適用するには、以下の手順に従います。

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

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

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

システムロケールを処理する基本的なタスクには、以下が含まれます。

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

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

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

この項目は、通常、インストールプロセス時に設定されます。詳細は『標準的な RHEL インストールの実行』を参照してください。

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

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

インストールプロセス時のネットワークアクセスの設定方法は「標準的な RHEL インストールの実行」および「高度な RHEL インストールの実行」を参照してください。

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

接続を新たに作成するには、以下のコマンドを実行します。

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

以下を置き換えます。

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

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

# nmcli -a con add

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

# nmcli con mod 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 コマンドを実行します。

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

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

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

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

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

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

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

# SPDX-License-Identifier: BSD-3-Clause
---
- hosts: network-test
  vars:
    network_connections:

      # Create one ethernet profile and activate it.
      # The profile uses automatic IP addressing
      # and is tied to the interface by MAC address.
      - name: prod1
        state: up
        type: ethernet
        autoconnect: yes
        mac: "00:00:5e:00:53:00"
        mtu: 1450

  roles:
    - rhel-system-roles.network

network ロールの適用の詳細、およびロールの使用例は、システムロールのドキュメント を参照してください。

サブスクリプションは、インストールプロセスで登録できます。詳細は『標準的な RHEL インストールの実行』を参照してください。

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

ここでは、RHEL 8 Web コンソールを使用して、新たにインストールした Red Hat Enterprise Linux のサブスクライブ方法を説明します。

これで、RHEL 8 システムが正常に登録されました。

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

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

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

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

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

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

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

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

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

# systemctl enable service_name

# systemctl disable service_name

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

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

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

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

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

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

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

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

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

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

selinux ロールを使用すると、複数のターゲットマシンでさまざまな SELinux のローカルカスタマイズを管理できます。

以下の例は、selinux ロールを適用して SELinux モードを設定し、変更を適用する必要がある場合に管理するホストを再起動する方法を示しています。

- hosts: selinux-test
  vars:
    # possible values: enforcing, permissive, disabled
    selinux_state: enforcing
  tasks:
    - name: execute the role and catch errors
      block:
        - include_role:
            name: rhel-system-roles.selinux
      rescue:
        # Fail if failed for a different reason than selinux_reboot_required.
        - name: handle errors
          fail:
            msg: "role failed"
          when: not selinux_reboot_required
        - name: Unconditionally reboot the machine with all defaults
          reboot:

ファイルシステムツリーの一部に restorecon を適用したり、ファイルコンテキスト、SELinux ブール値、ログイン、ポートを管理したりなど、さまざまなローカルカスタマイズを管理する selinux ロールを適用する方法は、システムロールのドキュメント を参照してください。

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

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

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

システムアカウント用に、1000 番未満のユーザー ID が予約されています。通常のアカウントには、1000 から始まる ID を使用できます。ただし、5000 以降の ID を割り当てることが推奨されます。詳細は、「予約されているユーザー 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

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

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

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

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

RHEL 8 Web コンソールにログインすると、以下が可能になります。

アカウント 設定でアカウントを管理できます。

ここでは、RHEL 8 Web コンソールでシステムユーザーアカウントを追加する方法と、アカウントに管理者権限を設定する方法を説明します。

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

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

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

kdump の詳細は『カーネルの管理、監視、および更新』を参照してください。

kdump のインストールと設定の方法は、「kdump のインストールと設定」を参照してください。

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

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

kdump ロールを使用して、複数のターゲットマシンに kdump を設定できます。

以下の例は、kdump ロールを適用してクラッシュダンプファイルの場所を設定する方法を示しています。

---
- hosts: kdump-test
  vars:
    kdump_path: /var/crash
  roles:
    - rhel-system-roles.kdump

kdump ロールを適用してさまざまな kdump の構成を管理する方法は、システムロールのドキュメント を参照してください。

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

バックアップソフトウェアを使用すると、障害復旧向けに ReaR を統合できます。

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

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

# yum install rear genisoimage syslinux

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

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

# rear mkrescue

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

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

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

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

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

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

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

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

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

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

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 の役割と取得方法」を参照してください。

Red Hat Enterprise Linux 8.0 では、アプリケーションストリームの概念が導入されました。ユーザー領域コンポーネントのバージョンは複数配信され、コアオペレーティングシステムのパッケージよりも頻繁に更新されるようになりました。これによりプラットフォームや特定のデプロイメントの基本的な安定性に影響を及ぼすことなく、Red Hat Enterprise Linux をカスタマイズする柔軟性が向上します。

アプリケーションストリームとして使用できるコンポーネントは、モジュールまたは RPM パッケージとしてパッケージ化され、RHEL 8 の AppStream リポジトリーを介して配信されます。アプリケーションストリームコンポーネントには、それぞれライフサイクルが指定されています。詳細は「Red Hat Enterprise Linux のライフサイクル」を参照してください。

モジュールは、論理ユニット (アプリケーション、言語スタック、データベース、またはツールセット) を表すパッケージの集まりです。これらのパッケージはまとめてビルドされ、テストされ、そしてリリースされます。

モジュールストリームは、アプリケーションストリームコンポーネントのバージョンを表します。たとえば、postgresql モジュールでは 2 つのストリーム (バージョン) の PostgreSQL データベースサーバー、つまり PostgreSQL 10 (デフォルトストリーム) および PostgreSQL 9.6 が利用できます。システムにインストールできるモジュールストリームは 1 つだけです。複数のコンテナーで異なるバージョンを使用できます。

詳細なモジュールコマンドは 『ユーザー空間コンポーネントのインストール、管理、および削除』を参照してください。AppStream で利用可能なモジュールの一覧は『パッケージマニフェスト』を参照してください。

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

yum check-update

yum update package_name

yum group update group_name

yum update

yum update --security

yum update-minimal --security

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

yum search term...

yum list --all

yum list glob_expression...

yum list --installed glob_expression...

yum list --available glob_expression...

yum repolist

yum repoinfo

yum repolist --all

yum info package_name...

yum install package_name

yum install package_name package_name...

yum install package_name.arch

yum install glob_expression...

yum install /usr/sbin/named

yum install-n name

yum install-na name.architecture

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

yum install path

yum remove package_name...

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

yum groups summary

yum group list glob_expression...

yum group info glob_expression...

yum group install group_name

yum group install groupid

yum install @group

yum install @group

yum group remove group_name

yum group remove groupid

yum remove @group

yum remove @group

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

yum history list

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

yum history info id...

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

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

yum history undo id

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

yum history redo id

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

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

yum グローバルオプションの現在の値 (つまり /etc/yum.conf ファイルの [main] セクションで指定しているオプション) を表示するには、次の手順に従います。

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

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

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

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

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

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

yum-config-manager --add-repo repository_url

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

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

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

plugins=1

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

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

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

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

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

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

DNF Automatic の動作は、設定ファイル (デフォルトでは /etc/dnf/automatic.conf ファイル) で定義されます。

DNF Automatic を実行するには、常に特定の systemd タイマーユニットを有効にして起動する必要があります。dnf-automatic パッケージで提供されるタイマーユニットのいずれかを使用するか、必要に応じて独自のタイマーユニットを作成することができます。

dnf-automatic パッケージには、次の systemd タイマーユニットが含まれます。

デフォルトでは、DNF Automatic は、動作を定義するための設定ファイルとして /etc/dnf/automatic.conf を使用します。

設定ファイルは、以下のトピックセクションに分かれています。

特定のセクションの詳細は、『DNF Automatic ドキュメント』を参照してください。

/etc/dnf/automatic.conf のデフォルト設定では、DNF Automatic は、利用可能な更新を自動的にチェックし、ダウンロードして、結果を標準出力として報告します。

DNF Automatic を実行するには、以下を実行します。

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

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

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

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

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) が表示されます。個別のサービスユニットの状態を判断する方法は「サービスステータスの表示」を参照してください。

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

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

systemctl status name.service

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

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

systemctl is-active name.service

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

systemctl is-enabled name.service

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

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

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

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

# systemctl list-dependencies --before 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

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

systemctl start name.service

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

# systemctl start httpd.service

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

systemctl stop name.service

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

# systemctl stop bluetooth.service

システムサービスに対応するサービスユニットを再開する場合は、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 コマンドもサポートします。特定のサービスユニットのステータスを確認する方法は「サービスステータスの表示」を参照してください。

# systemctl reload httpd.service

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

systemctl enable name.service

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

systemctl reenable name.service

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

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

システムの起動時に、システムサービスに対応するサービスユニットを自動的に起動しないように設定するには、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

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

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

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

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

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

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

systemctl get-default

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

$ systemctl get-default
graphical.target

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

systemctl list-units --type target

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

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

systemctl list-units --type target --all

$ systemctl list-units --type target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network.target        loaded active active Network
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
sockets.target        loaded active active Sockets
sound.target          loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
time-sync.target      loaded active active System Time Synchronized
timers.target         loaded active active Timers

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

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

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

systemctl set-default name.target

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

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

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

systemctl isolate name.target

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

# systemctl isolate multi-user.target

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

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

systemctl rescue

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

systemctl --no-wall rescue

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

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

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

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

systemctl emergency

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

systemctl --no-wall emergency

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

# systemctl --no-wall emergency

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) を参照してください。

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

systemctl reboot

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

systemctl --no-wall reboot

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

systemctl suspend

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

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

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

systemctl hibernate

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

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

systemctl hybrid-sleep

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

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

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

[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

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

ユニットファイルの並び順および依存関係に関する実例と追加情報は「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 ログインセッションを使用しません。

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 ヘッダーの依存関係オプション」を参照してください。

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

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

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

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

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

systemctl daemon-reload

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

init q

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

systemctl restart name.service

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

追加の設定オプションでデフォルトのユニットファイルを拡張するには、最初に /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

# mkdir /etc/systemd/system/httpd.service.d/

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

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

# systemctl daemon-reload

# systemctl restart httpd.service

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

ユニットファイルを提供するパッケージの更新後も変更を持続させるには、最初にファイルを /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

上書きされたユニットの監視

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

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 コマンドの出力に似た変更の要約をデフォルトで表示します。

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

systemd-delta --type=overridden

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

# systemctl edit unit_name.type_extension

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

# systemctl cat unit_name.type_extension

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

ランタイム時に、1 つのテンプレート設定ファイルから複数のユニットをインスタンス化できます。「@」文字は、テンプレートにマークを付け、ユニットをこれに関連付けるために使用されます。インスタンス化されたユニットは、(Requires オプションまたは Wants オプションを使用して) 別のユニットから開始することも、systemctl start コマンドで開始することもできます。インスタンス化されたサービスユニットの名前は以下のような形式となります。

template_name@instance_name.service

ここで、template_name は、テンプレート設定ファイルの名前になります。instance_name を、ユニットインスタンスの名前に置き換えます。複数のインスタンスが同じテンプレートファイルを参照し、このテンプレートには、ユニットの全インスタンスに共通する設定オプションが含まれます。テンプレートユニットの名前には以下の形式が使用されます。

unit_name@.service

たとえば、ユニットファイルに次の Wants 設定を指定すると、

Wants=getty@ttyA.service getty@ttyB.service

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

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

ユニット指定子の詳細な一覧は、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 として解決されます。

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

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

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

システム全体の起動時間の分析

$ systemd-analyze

ユニットの初期化時間の分析

$ systemd-analyze blame

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

重要なユニットの識別

$ systemd-analyze critical-chain

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

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

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

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

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

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

# systemctl disable service_name

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

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

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

サービスの詳細は、次のいずれかのコマンドを実行すると表示できます。

$ 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.1 ユーザー設定ツール

本セクションでは、ユーザー 設定ツールを使用してユーザーアカウントを変更する方法を説明します。

4.4.2.5. ユーザー設定ツールを使用したパスワードの管理

新しいユーザーを作成しても、パスワードを設定するまでアカウントは無効になります。

図4.2「パスワードメニュー」に示されるパスワードドロップダウンメニューには、以下のオプションが含まれます。

• すぐに管理者がパスワードを設定する。
• 最初のログイン時にユーザーがパスワードを選択する。
• ログインに必要なパスワードを設定せずにゲストアカウントを作成する。
• このメニューからアカウントを無効または有効にする。

図4.2 パスワードメニュー

ユーザーおよびグループを管理する以下のコマンドラインツールは、Red Hat Enterprise Linux 8 で利用できます。

本セクションでは、useradd コマンドを使用して、新しいユーザーを追加する方法を説明します。

本セクションでは、groupadd コマンドを使用して、新しいグループを追加する方法を説明します。

本セクションでは、usermod ユーティリティーを使用して、既存のユーザーを既存のグループに追加する方法を説明します。

usermod のさまざまなオプションは、ユーザーのプライマリーグループと補助グループにさまざまな影響を及ぼします。

# usermod -g group_name user_name

# usermod -G group_name1,group_name2,…​ user_name

システム管理者は、通常、主要なプロジェクトに対してそれぞれグループを作成し、そのプロジェクトのファイルにアクセスする必要がある場合に、アクセスするユーザーをそのグループに割り当てます。

こうした従来型のスキームの場合は、誰かがファイルを作成すると、そのユーザーが属するプライマリーグループにそのファイルが関連付けられるため、ファイル管理は困難になります。このため、1 人のユーザーが複数のプロジェクトに関わっている場合に、正しいファイルを正しいグループに関連付けることは難しくなります。

一方、UPG スキームを使用すると、グループは setgid ビットセットを持つディレクトリーに作成されたファイルに自動的に割り当てられます。setgid ビットにより、共通のディレクトリーを共有するグループプロジェクトを非常に簡単に管理できます。ユーザーがディレクトリー内で作成するすべてのファイルは、ディレクトリーを所有するグループが所有するためです。

本セクションでは、グループディレクトリーを作成するユースケースを説明します。

sudo コマンドは、root ユーザーのパスワードを使用せずに、管理アクセスを持つユーザーを提供する方法です。ユーザーが、通常、root ユーザー用に予約される管理コマンドを実行する場合は、コマンドの前に sudo を付けることができます。パスワードを入力すると、そのコマンドは root ユーザーとして実行されます。

以下の制限事項に注意してください。

また、Identity Management や LDAP などのサービスを使用して sudo アクセスを管理することもできます。

以下の手順に従って、ユーザーアカウントへの sudo アクセスを付与します。

su コマンドを使用して、セッション内の別のユーザーに切り替えることができます。su を使用する場合は、切り替えるユーザーのパスワードが必要になります。

su は強力なツールであるため、その使用を特権ユーザーに限定できます。以下の手順に従って、wheel 管理グループのメンバーへの su アクセスを制限します。

前提条件

root ユーザーとしてログインできる。

root ユーザーとして root パスワードを変更するには、以下の手順に従います。

手順

# passwd

passwd コマンドを使用して、wheel グループに属する非 root ユーザーとして、root パスワードを変更またはリセットできます。

前提条件

wheel グループに属する root 以外のユーザーでログインできます。

wheel グループのメンバーである root 以外のユーザーで root パスワードを変更するには、以下の手順に従います。

手順

$ sudo passwd root

root パスワードを忘れてしまった際に、wheel グループに属する非 root ユーザーとしてログインできない場合は、chroot jail 環境に切り替えることで、システムの起動時に root パスワードをリセットできます。chroot jail は、プロセスとその子プロセスを、残りのシステムから分離できるようにする環境です。

chroot jail のパスワードファイルを更新すると、SELinux セキュリティーコンテキストが正しくないファイルが作成されます。したがって、次回のシステム起動時にすべてのファイルの再ラベル付けが必要になります。ただし、特にディスクが大きくなると、再ラベル付けプロセスに時間がかかる場合があります。再ラベルプロセスを回避するには、SELinux を Permissive モードに切り替えることで作業できます。詳細は「SELinux を Permissive モードで変更すると、chroot jail で root パスワードのリセット」を参照してください。

SELIinux を Enforcing モードで使用する場合は、「Enfocimg モードで SElinux を使用した chroot jail で root パスワードのリセット」に記載されている手順を実行してください。

ユーザーおよびグループの管理に使用する各種ユーティリティーの詳細情報は、以下の man ページを参照してください。

関連する設定ファイルの詳細は、以下をご覧ください。

umask は、標準のファイル権限に対応するビットで構成されています。たとえば、umask 0137 の場合、その数字は次のような意味になります。

umask では 2 進法、8 進法、またはシンボリック表示が使用できます。たとえば、8 進法の 0137 はシンボリック表示では u=rw-,g=r--,o=--- となります。シンボリック表示は 8 進法表示とは異なり、禁止権限ではなく、許可された権限を示します。

umask は、ファイルに パーミッションを付与するのを禁止する ようにします。

以下の図は、umask 0137 が新しいファイルの作成にどのように影響するかを示しています。

図5.1 ファイルの作成時に umask を適用

[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

bash、ksh、zsh、tcsh などのよく使用されるシェルでは、umask は、umask シェルの builtin を使用して管理されます。シェルから起動したプロセスは、その umask を継承します。

$ umask 0337

$ umask 337

$ umask -S u=r,g=r,o=

対話モードでコマンドラインユーティリティー chronyc を使用して、chronyd のローカルインスタンスを変更するには、root で以下のコマンドを実行します。

# chronyc

制限されているコマンドを使用する場合は、root で chronyc を実行する必要があります。

以下のように、chronyc コマンドプロンプトが表示されます。

chronyc>

このコマンドの一覧を表示するには、help と入力します。

このユーティリティーは、以下のようなコマンドで呼び出すと、非対話型コマンドモードで呼び出すこともできます。

chronyc command

chrony パッケージのドキュメント (/usr/share/doc/chrony) には、ntp2chrony.py という名前の Python スクリプトがあります。このスクリプトは、既存の ntp 設定を chrony に自動的に変換します。ntp.conf ファイルで最も一般的なディレクティブおよびオプションがサポートされます。変換で無視されている行はすべて、確認のために、生成された chrony.conf ファイルにコメントとして追加されます。ntp 鍵ファイルに指定し、ntp.conf で信頼される鍵としてマークされていない鍵は、生成された chrony.keys ファイルにコメントとして追加されます。

デフォルトでは、スクリプトはいずれのファイルも上書きしません。/etc/chrony.conf または /etc/chrony.keys が存在する場合は、-b オプションを使用してファイルの名前を変更すれば、バックアップとして使用できます。このスクリプトはその他のオプションもサポートします。--help オプションを使用すると、サポートされるすべてのオプションが表示されます。

ntp パッケージで提供されるデフォルトの ntp.conf を使用したスクリプトの呼び出し例は以下のようになります。

# python3 /usr/share/doc/chrony/ntp2chrony.py -b -v
Reading /etc/ntp.conf
Reading /etc/ntp/crypto/pw
Reading /etc/ntp/keys
Writing /etc/chrony.conf
Writing /etc/chrony.keys

この場合に無視される唯一のディレクティブは disable monitor です。これは、noclientlog ディレクティブで chrony に相当するものがありますが、アンプ攻撃を軽減するためだけに、デフォルトの ntp.conf に含まれていました。

生成した chrony.conf ファイルには、通常、ntp.conf の制御行に対応する allow ディレクティブが多数含まれています。chronyd を NTP サーバーとして実行しない場合は、allow ディレクティブをすべて chrony.conf から削除します。

Red Hat Enterprise Linux 7 システムで timesync ロール を使用すると、システムが ntp または chrony を使用して NTP プロトコルを実装するかどうかにかかわらず、RHEL 6 以降のすべてのバージョンの RHEL で同じ Playbook を使用できるため、chrony への移行が容易になります。

時間同期の管理に timesync ロールを使用する方法は、システムロールのドキュメント を参照してください。

chronyc は、以下の 2 つの方法で chronyd にアクセスします。

デフォルトでは、chronyc は、Unix ドメインソケットに接続します。デフォルトのパスは /var/run/chrony/chronyd.sock です。この接続に失敗すると (たとえば非特権ユーザーで chronyc を実行していると失敗する可能性があります)、chronyc は 127.0.0.1 への接続を試み、その後 ::1 への接続を試みます。

chronyd の動作に影響しない次の監視コマンドのみが、ネットワークに許可されています。

chronyd がこのコマンドを受け取るホスト郡は、chronyd の設定ファイルにある cmdallow ディレクティブ、または chronyc の cmdallow コマンドで設定できます。デフォルトでは、このコマンドが許可されるのは、ローカルホスト (127.0.0.1 or ::1) のものだけになります。