Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

システム管理者のガイド

Red Hat Enterprise Linux 7

RHEL 7 の導入、設定、および管理

概要

システム管理者のガイド』 では、Red Hat Enterprise Linux 7 の導入、設定、管理の関連情報を説明します。本書は、システムに関する基本的な理解があるシステム管理者を対象としています。
注記
専門知識を深めるために、トレーニングコース Red Hat System Administration I (RH124)Red Hat System Administration II (RH134)Red Hat System Administration III (RH254)、または RHCSA Rapid Track (RH199) を受講することをお勧めします。
Red Hat Enterprise Linux 7 を Linux のコンテナー機能と一緒に使用する場合は、Red Hat Enterprise Linux Atomic Host の製品ドキュメント をご覧ください。Linux コンテナーの一般概念、および Red Hat Enterprise Linux 7 に実装されているコンテナーの最新機能の概要は、『Overview of Containers in Red Hat Systems』 をご覧ください。コンテナーの管理に関連するトピックは 『Red Hat Enterprise Linux Atomic Host 7 Managing Containers』ガイドで詳しく説明しています。

パート I. システムの基本設定

ここでは、キーボードの設定、日付と時刻の設定、ユーザーとグループの管理、権限の取得など、インストール後の基本的なタスクおよび基本的なシステム管理タスクを取り上げます。

第1章 はじめに

本章では、Red Hat Enterprise Linux 7 のインストール直後に実行する必要のある基本的なタスクを説明します。

これらのアイテムには、通常はインストールプロセス中に実行済みとなるタスクが含まれている可能性がありますが、システムの登録など、実行する必要がないものもあることに注意してください。本章の各セクションではこのようなタスクを扱い、インストール中に必要な方法と、別セクションにある関連ドキュメントへのリンクを紹介します。

Red Hat Enterprise Linux 7 のインストールに関する詳細は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。

注記

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

インストール後の一般的なタスクの詳細は、『インストールガイド』の「Red Hat Enterprise Linux 7 インストール後」を参照してください。

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

Cockpit の概要と使用可能なタスク

Cockpit はシステム管理ツールで、Web ブラウザーを通して監視サーバーおよび管理サーバーのユーザーインターフェースを提供します。

Cockpit は、これらのタスクの実行を可能にします。

  • ハードウェア、インターネット接続、パフォーマンスの特徴など、基本的なシステム機能の監視
  • システムログファイルのコンテンツの分析
  • インターフェース、ネットワークログ、パケットサイズなど、基本的なネットワーキング機能の設定
  • ユーザーアカウントの管理
  • システムサービスの監視および設定
  • 診断レポートの作成
  • カーネルダンプ構成の設定
  • SELinux の設定
  • システムサブスクリプションの管理
  • ターミナルへのアクセス

Cockpit のインストールおよび使用に関する詳細は『Red Hat Enterprise Linux 7 Getting Started with Cockpit Guide』を参照してください。

1.1. 環境の基本設定

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

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

通常、これらのアイテムの設定は、インストールプロセスに含まれます。

詳細は、インストール方法に応じた適切な資料を参照してください。

インストール後に、環境の基本的な特徴を再設定する必要がある場合は、このセクションの指示に従います。

1.1.1. 日付と時刻の設定について

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

Red Hat Enterprise Linux 7 は以下のデーモンを使用して、NTP を実装します。

  • chronyd

    デフォルトでは、chronyd デーモンを使用します。これは chrony パッケージから利用できます。chronydNTP を設定および使用する方法は、18章chrony スイートを使用した NTP 設定を参照してください。

  • ntpd

    ntpd デーモンは、ntp パッケージから利用できます。ntpd を使用した NTP の設定および使用に関する詳細は 19章ntpd を使用した NTP 設定 を参照してください。

デフォルトの chronyd ではなく ntpd を使用する場合は、chronyd を無効にし、19章ntpd を使用した NTP 設定 に従って ntpd をインストールして有効にし、設定する必要があります。

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

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

~]$ date
~]$ timedatectl

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

日付と時刻の設定に関する詳細は 3章日付と時刻の設定 を参照してください。

1.1.2. システムロケールの設定について

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

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

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

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

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

    ~]# localectl set-locale LANG=locale

システムロケールの設定に関する詳細は、2章システムロケールおよびキーボード設定 を参照してください。

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

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

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

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

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

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

    ~]# localectl set-keymap

キーボードレイアウトの設定に関する詳細は、2章システムロケールおよびキーボード設定 を参照してください。

1.2. ネットワークアクセスの設定および検査

通常、ネットワークアクセスはインストールプロセス中に設定されます。しかし、インストールプロセスでは、一部の共通インストールパスでネットワークインターフェースの設定を求めるプロンプトは表示されません。その結果、インストール後にネットワークアクセスが設定されていない可能性があります。その場合は、インストール後にネットワークアクセスを設定します。

インストール中のネットワークアクセスの設定に関するクイックスタートは 「インストールプロセス時のネットワークアクセスの設定」 を参照してください。インストール後にネットワークアクセスを設定するには、『Red Hat Enterprise Linux 7 ネットワークガイド』で説明されている nmcli コマンドラインユーティリティーか、『 Red Hat Enterprise Linux 7 ネットワークガイド』で説明されている テキスト形式のユーザーインターフェースユーティリティー nmtui のいずれかを使用できます。

nmcli および nmtui ユーティリティーは、1 つ以上の新しいネットワーク接続を追加するだけでなく、既存接続の変更および調査も可能にします。nmcli を使用してネットワーク接続を作成し、管理する場合は「nmcli を使用したインストールプロセス後のネットワーク接続管理」を参照してください。nmtui を使用してネットワーク接続を作成し、管理する場合は 「nmtui を使用したインストールプロセス後のネットワーク接続管理」 を参照してください。

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

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

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

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

インストールプロセス中のネットワークアクセスの設定に関する詳細は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。

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

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

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

~]# nmcli con add type type of the connection "con-name" connection name ifname ifname interface-name the name of the interface ipv4 address ipv4 address gw4 address gateway address

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

~]# nmcli con mod "con-name"

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

~]# nmcli con show

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

~]# nmcli con show --active

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

~]# nmcli con show "con-name"

nmcli コマンドラインユーティリティーに関する詳細は『Red Hat Enterprise Linux 7 ネットワークガイド』の「Red Hat Enterprise Linux 7 ネットワークガイド」を参照してください。

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

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

テキスト形式のインターフェースツールである nmtui のインストールおよび使用に関する詳細は『Red Hat Enterprise Linux 7 ネットワークガイド』を参照してください。

1.2.4. Cockpit でのネットワーキング管理

CockpitNetworking メニューを使用すると、以下を実行できます。

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

図1.1 Cockpit でのネットワーキング管理

ネットワーク

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

1.3.1. Red Hat サブスクリプションの概要、およびサブスクリプションを使用できるタスク

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

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

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

1.3.2. インストール時のシステム登録

本セクションでは、インストールプロセス中に行う Red Hat Enterprise Linux 7 の登録について簡単な概要を説明します。インストールしてもオペレーティングシステムが登録されていない場合は、本セクションを読むことで、インストール中に設定しなかった項目を確認できます。詳細は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。

基本的に、インストール中にシステムを登録する方法は 2 つあります。

  • 通常、登録は、初期設定の設定プロセスで行います。詳細は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。
  • または、インストール後のスクリプトでサブスクリプションマネージャー を実行して行います。この場合は、インストールの完了と同時 (システムが最初の再起動を実施する前) に、自動登録を実行します。これを行うには、キックスタートファイルの %post セクションを変更します。インストール後のスクリプトとしてサブスクリプションマネージャーを実行する場合は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。

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

インストールプロセス中にシステムの登録をしなかった場合は、以下の手順に従ってインストール後に登録できます。この手順で紹介するコマンドはすべて 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

システムの登録および Red Hat コンテンツ配信ネットワークサブスクリプションの割り当て方法は、7章システム登録およびサブスクリプション管理 を参照してください。

1.3.4. システムの EUS コンテンツへの登録

延長アップデートサポート (EUS) コンテンツにアクセスするには、以下のようにシステムを登録します。

  1. EUS エンタイトルメントが利用可能であることを確認します。

    ~]# subscription-manager list --available --matches="Extended Update Support"
        +-------------------------------------------+
            Available Subscriptions
        +-------------------------------------------+
        Subscription Name:   Extended Update Support
        Provides:            Red Hat Enterprise Linux High Availability for x86_64 - Extended Update Support
                             Red Hat Enterprise Linux Resilient Storage for x86_64 - Extended Update Support
                             Red Hat Enterprise Linux for x86_64 - Extended Update Support
                             Red Hat EUCJP Support (for RHEL Server) - Extended Update Support
                             RHEL for SAP - Extended Update Support
                             Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support
                             Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support
                             Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support
                             RHEL for SAP HANA - Extended Update Support
                             Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support
                             Oracle Java (for RHEL Server) - Extended Update Support
                             Red Hat S-JIS Support (for RHEL Server) - Extended Update Support
        SKU:                 RH00030
        Contract:            12069074
        Pool ID:             8a99f9ac7238188b01723d9c8a8a06a9
        Provides Management: No
        Available:           8
        Suggested:           0
        Service Level:       Layered
        Service Type:        L1-L3
        Subscription Type:   Instance Based
        Starts:              05/22/2020
        Ends:                05/21/2021
        System Type:         Physical
  2. プール ID を使用して該当サブスクリプションを割り当てます。

    ~]# subscription-manager attach --pool 8a99f9ac7238188b01723d9c8a8a06a9
  3. システムに有効なデフォルトのリポジトリーを EUS バリアントに置き換えます。

    ~]# subscription-manager repos --disable \*
  4. 使用中の RHEL リビジョンの EUS コンテンツセットを表すリポジトリーを有効にします。

    ~]# subscription-manager repos --enable rhel-7-server-eus-rpms
  5. エンドシステムで必要な、サポート対象のリリースを選択します。

    ~]# subscription-manager release --set 7.6

現在サポートされている EUS リリースについては、「Extended Update Support Add-on」を参照してください。

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

本セクションでは、Red Hat Enterprise Linux 7 システムにソフトウェアをインストールする際の基本的な内容を紹介します。「ソフトウェアインストールの前提条件」 では、ソフトウェアをインストールできるようにするために実行すべき前提条件を説明します。「ソフトウェアパッケージングとソフトウェアリポジトリーのシステム」 では、ソフトウェアパッケージングとソフトウェアリポジトリーに関する基本情報を説明します。また、「サブスクリプションマネージャーおよび yum を使用したソフトウェアインストールの基本タスクの管理」 では、ソフトウェアのインストールに関連する基本的なタスクの実行方法を説明します。

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

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

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

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

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

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

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

1.4.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.5. 起動時の systemd サービスの開始

systemd は、Linux オペレーティングシステム用のシステムおよびサービスのマネージャーで、systemd ユニットの概念が使用されています。systemd に関する詳細は 「systemd の概要」 を参照してください。

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

1.5.1. サービスの有効化/無効化

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

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

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

無効にするサービスの一覧は、有効にするサービスの一覧の前に処理されます。したがって、同じサービスが両方の一覧に記載されていると、そのサービスは有効になります。サービスの一覧はコンマ区切りのフォーマットで指定する必要があります。サービスの一覧には空白文字を使用しないでください。詳細は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。

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

~]# systemctl enableservice_name
~]# systemctl disableservice_name

詳細は、「システムサービスの管理」 を参照してください。

1.5.2. Cockpit でのサービス管理

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

図1.2 Cockpit でのサービス管理

systemd n

1.5.3. systemd サービスのその他のリソース

systemd に関する詳細は 10章systemd によるサービス管理 を参照してください。

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

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

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

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

1.6.1.1. ファイアウォールの概要およびシステムセキュリティーの強化方法

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

Red Hat Enterprise Linux 7 では、firewalld サービスがファイアーウォールを提供します。このサービスは、Red Hat Enterprise Linux のインストール時に自動的に有効になりますが、キックスタートの設定などでこのサービスを明示的に無効にした場合は、「ファイアウォールサービスの再有効化」 に従って、再度有効にすることができます。Kickstart ファイルにおけるファイアーウォールの設定オプションの概要は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。

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

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

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

~]$ systemctl status firewalld

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

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

firewalld に関するインストール後の手順は『Red Hat Enterprise Linux 7 セキュリティーガイド』を参照してください。ファイアーウォールの設定および使用に関する詳細は『Red Hat Enterprise Linux 7 セキュリティーガイド』を参照してください。

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

1.6.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 (アクセスベクターキャッシュ) へのアクセスを拒否する必要がある場合など、特定のケースで役立ちます。

Red Hat Enterprise Linux 7 の SELinux に関する詳細は『Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド』を参照してください。

1.6.2.2. SELinux の状態の確認

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

ただし、SELinux を明示的に Permissive モードに設定している場合や、インストール済みのオペレーティングシステムで無効になっている場合もあります。これは、たとえば、キックスタート設定で設定できます。キックスタートファイルにおける SELinux 設定オプションの概要は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください。

重要

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.6.2.3. Cockpit での SELinux 管理

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

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

図1.3 Cockpit での SELinux 管理

SELinux on n

1.6.3. SSH ベースの認証の使用

1.6.3.1. SSH ベースの認証の概要およびシステムセキュリティーの強化方法

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

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

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

SSH の保護手段に関する詳細は 「主な特長」 を参照してください。

1.6.3.2. SSH 接続の確立

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

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

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

    ~]$ ssh-keygen

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

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

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

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

    ~]# ssh-copy-id USER@hostname

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

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

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

このトピックに関する詳細は『Red Hat Enterprise Linux 7 セキュリティーガイド』を参照してください。

SSH root ログインの無効化

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

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

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

    ~]# systemctl restart sshd

1.7. ユーザーアカウント管理の基礎

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

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

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

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

警告

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

システムアカウント用に、1000 番未満のユーザー ID が予約されています。通常のアカウントには、1000 から始まる ID を使用できます。ただし、5000 以降の 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.7.1. ユーザーアカウントとグループを管理する最も基本的なコマンドラインツール

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

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

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

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

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

    ~]# usermod -a -G group_name user_name

ユーザーおよびグループの管理方法は4章ユーザーとグループの管理を参照してください。

ユーザーおよびグループの管理に GUI (グラフィカルユーザーインターフェース) を使用する場合は 「グラフィカル環境でのユーザーの管理」 を参照してください。

1.7.2. Cockpit におけるユーザーアカウントの管理

Cockpit のアカウントを管理するには、Accounts メニューを選択します。

図1.4 Cockpit におけるユーザーアカウントの管理

アカウント n

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

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

kdump サービスの有効化はインストールプロセスで行われ、デフォルトではインストール時に kdump が有効になります。本セクションでは、「インストールプロセス中の kdump の有効化および実行」 で、インストール時に kdump を有効にする方法を説明し、「インストールプロセス後に kdump のインストールと有効化」 で、インストール後に無効の kdump サービスを手動で有効にする方法を説明します。

Cockpit を使用して kdump を設定することも可能です。詳細は「Cockpit での kdump の設定」を参照してください。

1.8.1. kdump の概要と使用できるタスク

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

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

1.8.2. インストールプロセス中の kdump の有効化および実行

インストール中の kdump の有効化および実行は、Anaconda インストーラー、またはキックスタートファイルの %addon com_redhat_kdump コマンドのいずれかを使用して行います。

詳細は、インストール方法に応じた適切な資料を参照してください。

  • Anaconda インストーラーを使用してインストールする場合は、以下を参照してください。

    『Red Hat Enterprise Linux 7 インストールガイド』の「Anaconda を使用したインストール

  • キックスタートファイルを使用してインストールする場合は、以下を参照してください。

    『Red Hat Enterprise Linux 7 インストールガイド』の「キックスタートのコマンドとオプション

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

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

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

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

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

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

    コマンドラインまたはグラフィカルユーザーインターフェースのいずれかを使用します。

    両方のオプションの詳細は「Red Hat Enterprise Linux 7 カーネルクラッシュダンプガイド」を参照してください。

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

    ~]# yum install system-config-kdump

1.8.4. Cockpit での kdump の設定

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

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

図1.5 Cockpit での kdump の設定

kdump n

1.8.5. kdump に関するその他のリソース

kdump に関する詳細は 『Red Hat Enterprise Linux 7 カーネルクラッシュダンプガイド』を参照してください。

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

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

1.9.1. ReaR の概要および使用できるタスク

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

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

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

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

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

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

~]# yum install rear genisoimage syslinux

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

詳細は「基本的な ReaR の使用方法」を参照してください。

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

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

ReaR を使用したレスキューシステムの作成方法は 「レスキューシステムの作成」 を参照してください。

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

ReaR NETFS の内部バックアップメソッドの使用方法は 「ビルトインバックアップの場合」 を参照してください。

サポート対象の外部バックアップメソッドおよびサポート対象外のバックアップメソッドの詳細は 「サポート対象のバックアップメソッド」 および 「サポート対象外のバックアップメソッド」 を参照してください。

1.10. 問題のトラブルシューティングにおけるログファイルの使用

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

ログファイルの詳細は、23章ログファイルの表示と管理 を参照してください。

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

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

  • systemd-journald デーモン: カーネル、システムの起動プロセスの初期段階、デーモンを開始して実行する際の標準出力およびエラー、syslog からのメッセージを収集し、それらのメッセージをさらに処理するために rsyslog サービスに転送します。
  • rsyslog サービスは、タイプおよび優先順で syslog のメッセージを分類し、/var/log ディレクトリー内のファイルに書き込みます。 ここでは、ログが永続的に保存されます。

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

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

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

1.11. Red Hat サポートへのアクセス

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

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

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

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

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

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

Red Hat カスタマーポータルサービスでは、以下の方法で Red Hat サポートをご利用いただけます。

  • Web ブラウザー
  • Red Hat Support Tool

1.11.1.1. Red Hat Support Tool の概要および利用できるタスク

Red Hat Support Tool は、サブスクリプションベースの Red Hat アクセスサービスにテキストコンソールインターフェースを提供するコマンドラインベースのツールです。このツールは、redhat-support-tool パッケージに含まれています。

Red Hat Support Tool を利用すると、以下のようなサポート関連のタスクを実行できるようになります。

  • サポートケースの作成または更新
  • Red Hat ナレッジベースソリューションでの検索
  • Python および Java のエラーの分析

インタラクティブモードでツールを起動するには、以下のコマンドを入力します。

~]$ redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help):

インタラクティブモードで ? を入力すると、利用可能なコマンドが表示されます。

Command (? for help): ?

Red Hat Support Tool のインストールおよび利用に関する詳細は、8章Red Hat Support Tool を使用したサポートへのアクセス および Red Hat ナレッジベースの記事「 Red Hat Access の Red Hat Support Tool」を参照してください。

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

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

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

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章 システムロケールおよびキーボード設定

システムロケール では、システムサービスおよびユーザーインターフェースの言語設定を指定します。キーボードレイアウト の設定では、テキストコンソールおよびグラフィカルユーザーインターフェースで使用するレイアウトを管理します。

これらの設定は、/etc/locale.conf 設定ファイルを修正するか localectl ユーティリティーを使用して行います。グラフィカルユーザーインターフェースを使用して設定することもできます。詳細は 『Red Hat Enterprise Linux 7 インストールガイド』 を参照してください。

2.1. システムロケールの設定

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

/etc/locale.conf の基本的なファイル形式は、改行で区切られた変数割り当ての一覧です。たとえば、ロケールがドイツ語でメッセージが英語の場合、/etc/locale.conf は以下のようになります。

LANG=de_DE.UTF-8
LC_MESSAGES=C

ここでは LC_MESSAGES オプションを使用して、標準エラー出力に書き出される診断メッセージ用ロケールを決定します。/etc/locale.conf でさらにロケール設定を指定するには、いくつかのオプションが使用でき、関連性の高いものが 表2.1「/etc/locale.conf で設定可能なオプション」 にまとめられています。これらのオプションの詳細は、man ページの locale(7) を参照してください。/etc/locale.conf には、すべてのオプションを可能にする LC_ALL オプションは設定しないように注意してください。

表2.1 /etc/locale.conf で設定可能なオプション

オプション詳細

LANG

システムロケールのデフォルト値になります。

LC_COLLATE

ローカルのアルファベット文字列を比較する機能の動作を変更します。

LC_CTYPE

文字処理、分類機能、マルチバイト文字機能の動作を変更します。

LC_NUMERIC

数値が通常出力される方法を設定します (小数点を表すコンマなど)。

LC_TIME

現在の時間表記を、24 時間表記または 12 時間表記に変更します。

LC_MESSAGES

標準エラー出力に書き出される診断メッセージに使用されるロケールを決定します。

2.1.1. 現行ステータスの表示

localectl コマンドを使用すると、システムロケールおよびキーボードレイアウト設定へのクエリーまたは変更が可能になります。現在の設定を表示するには、status オプションを使用します。

localectl status

例2.1 現行ステータスの表示

上記のコマンドを実行すると、ロケールの現行設定と、コンソールおよび X11 ウィンドウシステムに設定されているキーボードレイアウトが出力されます。

~]$ localectl status
  System Locale: LANG=en_US.UTF-8
    VC Keymap: us
   X11 Layout: n/a

2.1.2. 利用可能なロケールの一覧表示

ご使用のシステムで利用可能なロケールを一覧表示するには、以下を入力します。

localectl list-locales

例2.2 ロケールの一覧表示

特定の英語ロケールを選択するとき、そのロケールがシステムで利用可能であるかどうかわからないとします。以下のコマンドを使用すると、英語ロケールの一覧を表示することで確認できます。

~]$ localectl list-locales | grep en_
en_AG
en_AG.utf8
en_AU
en_AU.iso88591
en_AU.utf8
en_BW
en_BW.iso88591
en_BW.utf8

output truncated

2.1.3. ロケールの設定

デフォルトのシステムロケールを設定するには、root で以下のコマンドを使用します。

localectl set-locale LANG=locale

locale を、localectl list-locales コマンドで見つかったロケール名に置き換えます。上記の構文は、表2.1「/etc/locale.conf で設定可能なオプション」 のパラメーター設定にも使用できます。

例2.3 デフォルトロケールの変更

たとえば、イギリス英語をデフォルトのロケールに設定する場合は、最初に list-locales を使用して、このロケールの名前を見つけます。次に、root で以下の形式のコマンドを入力します。

~]# localectl set-locale LANG=en_GB.utf8

2.1.4. キックスタートを使用したインストール時にシステムロケールの設定を永続化

Red Hat キックスタートインストールを使用して Red Hat Enterprise Linux をインストールすると、オペレーティングシステムをアップグレードした後にシステムロケールの設定が永続化されないことがあります。

キックスタートファイルの %packages セクションに --instLang オプションが含まれる場合は、_install_langs RPM マクロはこのインストールの特定の値に設定され、インストールしたロケールのセットが調整されます。ただし、この設定は今回のインストールにのみ影響し、その後のアップグレードには影響しません。アップグレードの際に glibc パッケージを再インストールすると、インストール中にユーザーがリクエストしたロケールではなく、ロケール全体がアップグレードされます。

これを回避するには、永続化させるロケールを選択します。次のような方法があります。

キックスタートインストール中に RPM マクロの設定

  1. キックスタートファイルの %post セクションを変更します。

    LANG=en_US
    echo "%_install_langs $LANG" > /etc/rpm/macros.language-conf
    
    awk '(NF==0amp amp!done){print "override_install_langs='$LANG'";done=1}{print}' \
       < /etc/yum.conf > /etc/yum.conf.new
    mv /ec/yum.conf.new /etc/yum.conf

システム全体に RPM マクロの設定

  1. 以下の設定を追加した RPM 設定ファイルを /etc/rpm/macros.language-conf に作成します。

    %_install_langs LANG

    LANG は、instLang オプションの値です。

  2. 以下を使用して、/etc/yum.conf ファイルを更新します。

    override_install_langs=LANG

2.2. キーボードレイアウトの変更

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

2.2.1. 現行設定の表示

上記の説明にあるように、現行のキーボードレイアウト設定は、以下のコマンドで確認できます。

localectl status

例2.4 キーボード設定の表示

以下の出力では、仮想コンソールおよび X11 ウィンドウシステム用に設定されているキーボードレイアウトが表示されています。

~]$ localectl status
  System Locale: LANG=en_US.utf8
    VC Keymap: us
   X11 Layout: us

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

システムに設定可能なキーボードレイアウトの一覧を表示するには、以下を入力します。

localectl list-keymaps

例2.5 特定のキーマップの検索

grep を使用すると、上記のコマンド出力から特定のキーマップ名を探すことができます。現在設定されているロケールと互換性のあるキーマップが複数存在する場合も少なくありません。たとえば、利用可能な Czech キーボードレイアウトを見つけるには、以下のコマンドを実行します。

~]$ localectl list-keymaps | grep cz
cz
cz-cp1250
cz-lat2
cz-lat2-prog
cz-qwerty
cz-us-qwertz
sunt5-cz-us
sunt5-us-cz

2.2.3. キーマップの設定

システムでデフォルトのキーボードレイアウトを設定するには、root で以下のコマンドを使用します。

localectl set-keymap map

map を、localectl list-keymaps コマンドの出力から取得したキーマップの名前に置き換えます。--no-convert オプションが渡されない限り、選択した設定は、最も一致する X11 キーボードマッピングに変換してから X11 ウィンドウシステムのデフォルトのキーボードマッピングにも適用されます。これは逆の方法でも適用できます。root で以下のコマンドを実行すると、両方のキーマップを指定できます。

localectl set-x11-keymap map

このコンソールレイアウトを X11 レイアウトに設定しない場合は、--no-convert オプションを使用します。

localectl --no-convert set-x11-keymap map

このオプションを使用すると、X11 キーマップではこれまでのコンソールレイアウト設定が引き続き使用されます。

例2.6 X11 キーマップの個別設定

グラフィカルインターフェースでは German キーボードレイアウトを使用し、コンソール操作では引き続き US キーマップを使用します。これを実行するには、root で次のコマンドを実行します。

~]# localectl --no-convert set-x11-keymap de

ステータスで、設定が正常に行われたかを確認できます。

~]$ localectl status
  System Locale: LANG=de_DE.UTF-8
    VC Keymap: us
   X11 Layout: de

キーボードレイアウト (map) の他に、以下の 3 つのオプションが指定できます。

localectl set-x11-keymap map model variant options

model はキーボードのモデル名、variant はキーボードのバリアント、そして options はオプションコンポーネントに置き換えます。このコマンドを使用すると、キーボードの動作を強化できます。これらのオプションは、デフォルトでは設定されていません。X11 モデル、X11 バリアント、および X11 オプションの詳細は、man ページの kbd(4) を参照してください。

2.3. 関連資料

Red Hat Enterprise Linux でキーボードレイアウトを設定する方法は、以下を参照してください。

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

  • localectl(1): localectl コマンドラインユーティリティーの man ページには、このツールを使用してシステムロケールとキーボードレイアウトを設定する方法が説明されています。
  • loadkeys(1): loadkeys コマンドの man ページには、このツールを使用して仮想コンソールでキーボードレイアウトを変更する方法が説明されています。

関連項目

  • 6章権限の取得 では、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。
  • 10章systemd によるサービス管理 では、systemd の詳細情報と、systemctl コマンドを使用してシステムサービスを管理する方法が説明されています。

第3章 日付と時刻の設定

最新のオペレーティングシステムは、以下の 2 つのタイプのクロックを区別します。

  • リアルタイムクロック (RTC) は、一般に ハードウェアクロック と呼ばれ、通常、システムボード上の集積回路で、オペレーティングシステムの状態からは完全に独立しており、コンピューターがシャットダウンしても稼働します。
  • システムクロックソフトウェアクロック とも呼ばれ、カーネルが維持し、その初期値はリアルタイムクロックに基づいています。システムが起動するとシステムクロックは初期化され、リアルタイムクロックからは完全に独立したものになります。

システム時間は常に 協定世界時 (UTC) で維持され、必要に応じてアプリケーション内でローカル時間に変換されます。ローカルタイム は、夏時間 (DST) を考慮に入れた現行タイムゾーンの実際の時刻です。リアルタイムクロックは UTC またはローカルタイムのいずれかを使用できます。これは推奨オプションです。

Red Hat Enterprise Linux 7 は、システムの日付と時刻に関する情報を設定および表示するのに使用できる 3 つのコマンドラインツールを提供します。

  • timedatectl ユーティリティー (Red Hat Enterprise Linux 7 の新機能で、systemd に含まれる)。
  • 従来の date コマンド
  • ハードウェアクロックにアクセスするための hwclock ユーティリティー

3.1. timedatectl コマンドの使用

timedatectl ユーティリティーは、systemd システムおよびサービスマネージャーの一部として配布されており、システムクロック設定を確認および変更できます。このツールを使用すると、現在の日付および時間の変更、タイムゾーンの設定、リモートサーバーとシステムクロックとの自動同期の有効化が可能になります。

カスタマイズした形式で現在の日付と時間を表示する方法は 「date コマンドの使用」 も参照してください。

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

現在の日時をシステムおよびハードウェアクロック設定の詳細情報と共に表示するには、timedatectl コマンドをオプションなしで実行します。

timedatectl

これで、ローカル時間、ユニバーサル時間、現在使用しているタイムゾーン、ネットワーク時刻プロトコル (NTP) 設定、DST に関する追加情報が表示されます。

例3.1 システムの現在日時の表示

以下の例は、システムクロックとリモートサーバーの同期に NTP を使用しないシステムで timedatectl コマンドを実行したときの出力です。

~]$ timedatectl
   Local time: Mon 2016-09-16 19:30:24 CEST
 Universal time: Mon 2016-09-16 17:30:24 UTC
    Timezone: Europe/Prague (CEST, +0200)
   NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
   DST active: yes
 Last DST change: DST began at
         Sun 2016-03-31 01:59:59 CET
         Sun 2016-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
         Sun 2016-10-27 02:59:59 CEST
         Sun 2016-10-27 02:00:00 CET
重要

timedatectl は、chrony または ntpd のステータスへの変更を即座に認識しません。これらのツールの設定またはステータスを変更した場合は、以下のコマンドを実行します。

~]# systemctl restart systemd-timedated.service

3.1.2. システムの現在時刻の変更

システムの現在時刻を変更するには、root でシェルプロンプトに以下を入力します。

timedatectl set-time HH:MM:SS

HH は時間、MM は分、SS は秒 (すべて 2 桁) の数字に置き換えます。

このコマンドは、システム時間とハードウェアクロックの両方を更新します。結果は、date --set および hwclock --systohc コマンドの両方を使用する場合と同様になります。

NTP サービスが有効になっていると、このコマンドは失敗します。このサービスを一時的に無効にする方法は 「システムクロックのリモートサーバーとの同期」 を参照してください。

例3.2 システムの現在時刻の変更

システムの現在時刻を午後 11 時 26 分に変更するには、root で以下のコマンドを実行します。

~]# timedatectl set-time 23:26:00

デフォルトでは、システムは UTC を使用するように設定されています。ローカルタイムでクロックを維持するようにシステムを設定するには、root 権限で、set-local-rtc オプションとともに timedatectl コマンドを実行します。

timedatectl set-local-rtc boolean

ローカルタイムでクロックを維持するようにシステムを設定するには、booleanyes (または ytruet、または 1) に置き換えます。UTC を使用するようにシステムを設定するには、booleanno (または nfalsef、または 0) に置き換えます。デフォルトオプションは no です。

3.1.3. システムの現在日の変更

システムの現在の日付を変更するには、root でシェルプロンプトに以下を入力します。

timedatectl set-time YYYY-MM-DD

YYYY は 4 桁の年に、MMDD は 2 桁の月と日に置き換えます。

時間を指定せずに日付を変更すると、時間は 00:00:00 に設定されることに注意してください。

例3.3 システムの現在日の変更

システムの現在日を 2017 年 6 月 2 日に変更し、現在時刻は変更しない (午後 11:26) 場合は、root で以下のコマンドを実行します。

~]# timedatectl set-time 2017-06-02 23:26:00

3.1.4. タイムゾーンの変更

利用可能なタイムゾーンの一覧を表示するには、シェルプロンプトで以下を入力します。

timedatectl list-timezones

現在使用中のタイムゾーンを変更するには、root で以下を入力します。

timedatectl set-timezone time_zone

time_zone を、timedatectl list-timezones コマンドで表示される値に置き換えます。

例3.4 タイムゾーンの変更

現在の場所に最も適したタイムゾーンを特定するには、timedatectl コマンドに list-timezones オプションを付けて実行します。たとえば、ヨーロッパのタイムゾーンの一覧を表示するには、以下のコマンドを実行します。

~]# timedatectl list-timezones | grep Europe
Europe/Amsterdam
Europe/Andorra
Europe/Athens
Europe/Belgrade
Europe/Berlin
Europe/Bratislava

タイムゾーンを Europe/Prague に変更するには、root で以下を入力します。

~]# timedatectl set-timezone Europe/Prague

3.1.5. システムクロックのリモートサーバーとの同期

上記の説明にある手動での調整の他に、timedatectl コマンドで NTP プロトコルを使用して、システムクロックを自動でリモートサーバーのグループと同期させる方法もあります。NTP を有効にすると、chronyd サービスまたは ntpd サービスのうち、インストールされている方が有効になります。

NTP サービスは、以下のコマンドを使用して有効または無効にできます。

timedatectl set-ntp boolean

システムでシステムクロックをリモートの NTP サーバーと同期させるには、booleanyes に置き換えます (デフォルトのオプション)。この機能を無効にするには、booleanno に置き換えます。

例3.5 システムクロックのリモートサーバーとの同期

システムクロックとリモートサーバーの自動同期を有効にするには、以下を入力します。

~]# timedatectl set-ntp yes

このコマンドは、NTP サービスがインストールされていないと失敗します。詳細は「chrony のインストール」を参照してください。

3.2. date コマンドの使用

date ユーティリティーはすべての Linux システムで利用可能で、システムの現在日時の表示および設定を可能にします。システムクロックに関する詳細情報をカスタマイズされた形式で表示するために、スクリプト内で使用されることがよくあります。

タイムゾーンの変更、またはシステムクロックとリモートサーバーの自動同期を有効にする方法は timedatectl コマンドの使用」 を参照してください。

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

現在の日時を表示するには、date コマンドをオプションを付けずに実行します。

date

このコマンドを実行すると、曜日、日付、ローカルタイム、タイムゾーンの省略形、年が表示されます。

date コマンドは、デフォルトではローカルタイムを表示します。UTC の時間を表示するには、コマンドラインオプション--utc または -u を指定してコマンドを実行します。

date --utc

また、+"format" オプションをコマンドラインに指定することで、表示される情報のフォーマットをカスタマイズすることもできます。

date +"format"

例3.6「システムの現在日時の表示」 を参考にして、フォーマットを、サポートされる 1 つまたは複数のコントロールシーケンスに置き換えます。よく使用されるフォーマットオプションのリストは 表3.1「よく使われるコントロールシーケンス」 を参照してください。これらのオプションの完全なリストは、man ページの date(1) を参照してください。

表3.1 よく使われるコントロールシーケンス

コントロールシーケンス詳細

%H

HH フォーマットでの時間 (例: 17)。

%M

MM フォーマットでの分 (例: 30)。

%S

SS フォーマットでの秒 (例: 24)。

%d

DD フォーマットでの日 (例: 16)。

%m

MM フォーマットでの月 (例: 09)。

%Y

YYYY フォーマットでの年 (例: 2016)。

%Z

タイムゾーンの省略形 (例: CEST)。

%F

非省略形の YYYY-MM-DD フォーマットでの日付 (例: 2016-09-16)。このオプションは、%Y-%m-%d と同等です。

%T

非省略形の HH:MM:SS フォーマットでの時間 (例: 17:30:24)。このオプションは、%H:%M:%S と同等です。

例3.6 システムの現在日時の表示

現在日とローカル時間を表示するには、シェルプロンプトで以下を入力します。

~]$ date
Mon Sep 16 17:30:24 CEST 2016

UTC で現在日時を表示するには、シェルプロンプトで以下を入力します。

~]$ date --utc
Mon Sep 16 15:30:34 UTC 2016

date コマンドの出力をカスタマイズするには、以下を入力します。

~]$ date +"%Y-%m-%d %H:%M"
2016-09-16 17:30

3.2.2. システムの現在時刻の変更

システムの現在時刻を変更するには、rootdate コマンドに --set オプションまたは -s オプションを指定して実行します。

date --set HH:MM:SS

HH は時間、MM は分、SS は秒 (すべて 2 桁) の数字に置き換えます。

date コマンドは、デフォルトでは、システムクロックをローカルタイムに設定します。システムクロックを UTC で設定するには、コマンドラインオプション--utc または -u を指定してコマンドを実行します。

date --set HH:MM:SS --utc

例3.7 システムの現在時刻の変更

システムの現在時刻を午後 11 時 26 分に変更するには、root で以下のコマンドを実行します。

~]# date --set 23:26:00

3.2.3. システムの現在日の変更

現在の日付を変更するには、root--set または -s を指定して date コマンドを実行します。

date --set YYYY-MM-DD

YYYY は 4 桁の年に、MMDD は 2 桁の月と日に置き換えます。

時間を指定せずに日付を変更すると、時間は 00:00:00 に設定されることに注意してください。

例3.8 システムの現在日の変更

システムの現在日を 2017 年 6 月 2 日に変更し、現在時刻は変更しない (午後 11:26) 場合は、root で以下のコマンドを実行します。

~]# date --set "2017-06-02 23:26:00"

3.3. hwclock コマンドの使用

hwclock は、ハードウェアクロックにアクセスするためのユーティリティーです。これは、リアルタイムクロック (RTC) とも呼ばれています。ハードウェアクロックは使用中のオペレーティングシステムから独立しており、マシンがシャットダウンしても作動します。このユーティリティーは、ハードウェアクロックの時刻を表示するために使用されます。また hwclock には、ハードウェアクロック内の体系的なずれを補正する機能もあります。

ハードウェアクロックタイムは、年、月、日、時間、分、秒の値を保存します。ローカルタイムや協定世界時 (UTC) の時刻を保存したり、夏時間 (DST) を設定したりすることはできません。

hwclock ユーティリティーは、/etc/adjtime ファイルにその設定を保存します。このファイルは、時刻を手動で設定したり、ハードウェアクロックをシステム時間に同期したりするなどの初回の変更時に作成されます。

注記

Red Hat Enterprise Linux 6 では、システムのシャットダウンまたは再起動ごとに hwclock コマンドが自動的に実行されていましたが、Red Hat Enterprise Linux 7 には含まれていません。システムクロックが Network Time Protocol (NTP) または Precision Time Protocol (PTP) に同期される場合は、カーネルが 11分ごとに自動的にハードウェアクロックをシステムクロックに同期します。

NTP の詳細は 18章chrony スイートを使用した NTP 設定 および 19章ntpd を使用した NTP 設定 を参照してください。PTP の詳細は 20章ptp4l を使用した PTP の設定 を参照してください。ntpdate を実行した後のハードウェアクロックの設定方法は 「ハードウェアクロック更新の設定」 を参照してください。

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

root ユーザーで、オプションを付けずに hwclock を実行すると、標準出力にローカルタイムの日時が返されます。

hwclock

hwclock コマンドで --utc オプションまたは --localtime オプションを指定しても、ハードウェアクロック時間が UTC またはローカルタイムで表示される訳ではないことに注意してください。これらのオプションは、ハードウェアクロックのいずれかの設定を変更するために使用されます。この時間は常にローカル時間で表示されます。したがって、hwclock --utc または hwclock --local コマンドを実行しても、/etc/adjtime 保存された設定が変更されるわけではありません。このコマンドは、/etc/adjtime に保存されている設定が正しくないことを把握していて設定を変更したくない場合に便利です。一方、このコマンドを誤った方法で使用すると、誤解を招く情報を受け取る可能性があります。詳細は、hwclock(8) man ページを参照してください。

例3.9 システムの現在日時の表示

ハードウェアクロックからシステムの現在の日付およびローカルタイムを表示するには、root で以下を実行します。

~]# hwclock
Tue 15 Apr 2017 04:23:46 PM CEST   -0.329272 seconds

CEST は 中央ヨーロッパ夏時間 (Central European Summer Time) の省略形です。

タイムゾーンの変更方法は 「タイムゾーンの変更」 を参照してください。

3.3.2. 日付と時刻の設定

ハードウェアクロックは、日付と時刻を表示するほかに、手動で特定の時刻に設定することができます。

ハードウェアクロックの日時を変更する場合は、コマンドに --set および --dateオプションを追加します。

hwclock --set --date "dd mmm yyyy HH:MM"

dd は日 (2 桁)、mmm は月の省略形 (3 文字) に、yyyy は年 (4 桁)、HH は時間 (2 桁)、MM は分 (2 桁) に置き換えます。

同時に、--utc または --localtime オプションをそれぞれ追加して、UTC またはローカルタイムのいずれかで時刻を維持するようにハードウェアクロックを設定することもできます。この場合、UTC または LOCAL/etc/adjtime ファイルに記録されます。

例3.10 ハードウェアクロックの特定の日時への設定

たとえば、日時を 2016 年 10 月 21 日 21:17 に設定し、UTC のハードウェアクロックを維持する場合は、root で以下のコマンドを実行します。

~]# hwclock --set --date "21 Oct 2016 21:17" --utc

3.3.3. 日付と時刻の同期

ハードウェアクロックとシステムの現在時刻の同期を両方向で実行できます。

  • 以下のコマンドを使用して、ハードウェアクロックを、システムの現在時刻に設定できます。

    hwclock --systohc

    NTP を使用すると、ハードウェアクロックは 11 分ごとにシステムクロックに自動的に同期されるため、このコマンドは、システムのブート時に、妥当な初期のシステム時間を取得するためにのみ役立つことに注意してください。

  • または、以下のコマンドを使用してハードウェアクロックからシステム時間を設定できます。

    hwclock --hctosys

ハードウェアクロックとシステム時間を同期する場合は、--utc または --localtime を追加してローカルタイムまたは UTC でハードウェアクロックを保持するかどうかを指定できます。--set の使用と同様に、UTC または LOCAL/etc/adjtime ファイルに記録されます。

hwclock --systohc --utc コマンドは timedatectl set-local-rtc false に機能的に類似しており、hwclock --systohc --local コマンドは timedatectl set-local-rtc true の代替コマンドになります。

例3.11 システムタイムへのハードウェアクロックの同期

ハードウェアクロックをシステムの現在時刻に設定し、ハードウェアクロックをローカルタイムで維持するには、root で以下のコマンドを実行します。

~]# hwclock --systohc --localtime

タイムゾーンおよび DST の切り替えに関する問題を避けるには、ハードウェアクロックを UTC で維持することを推奨します。例3.11「システムタイムへのハードウェアクロックの同期」 は、Windows システムとのマルチブートの場合などに役立ちます。この場合、デフォルトでハードウェアクロックがローカルタイムで実行されることが想定され、その他のシステムもすべてローカルタイムを使用して対応する必要があります。同様に仮想マシンでも必要になる場合があります。ホストが提供する仮想ハードウェアクロックがローカルタイムで実行中の場合は、ゲストシステムもローカルタイムを使用するように設定する必要があります。

3.4. 関連資料

Red Hat Enterprise Linux 7 でキーボードレイアウトを設定する方法は、以下を参照してください。

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

  • timedatectl(1): timedatectl コマンドラインユーティリティーの man ページでは、このツールを使用して、システムクロックおよびその設定をクエリーして変更する方法が説明されています。
  • date(1): date コマンドの man ページでは、サポートされるオプションの完全なリストが提供されます。
  • hwclock(8): hwclock コマンドの man ページでは、サポートされるオプションの完全なリストが提供されます。

関連項目

第4章 ユーザーとグループの管理

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

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

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

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

さらに、Red Hat Enterprise Linux はファイルとディレクトリーに対する アクセス制御リスト (ACL) をサポートします。これにより、所有者以外の特定のユーザーにパーミッションを設定できます。この機能の詳細は 5章アクセス制御リスト を参照してください。

予備のユーザーとグループ ID

Red Hat Enterprise Linux は、1000 以下のユーザー ID とグループ 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 から始まるようにした場合でも、システムが予約する ID が 1000 より上にならないようにすることが推奨されます。こうすることで、1000 を上限とするシステムとの競合を避けることができます。

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

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

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

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

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

4.1.2. シャドウパスワード

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

以下は、UNIX ベースシステムでパスワードを格納する従来の方法と比べた場合のシャドウパスワードの利点です。

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

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

  • パスワードエージングパラメーターを設定する chage ユーティリティー詳細は、Red Hat Enterprise Linux 7 セキュリティーガイドPassword Security セクションをご覧ください。
  • /etc/group ファイルを管理する gpasswd ユーティリティー
  • -e, --expiredate オプションまたは -f (--inactive) オプションを使用した usermod コマンド
  • -e, --expiredate オプションまたは -f, --inactive オプションを使用した useradd コマンド

4.2. グラフィカル環境でのユーザーの管理

Users ユーティリティーは、グラフィカルユーザーインターフェースで、ローカルユーザーを表示、編集、追加、削除できます。

4.2.1. ユーザー設定ツールの使用

Super キーを押してアクティビティーの概要に入り、Users と入力して Enter を押します。ユーザー 設定ツールが表示されます。Super キーはキーボードや他のハードウェアによって外見が異なりますが、通常はスペースバーの左側にある Windows キーまたは Command キーになります。また、画面の右上にある自分のユーザー名をクリックし、設定メニューから ユーザー ユーティリティーを開くこともできます。

ユーザーアカウントに変更を加えるには、最初に Unlock (ロック解除) ボタンを選択し、表示されたダイアログボックスに従って自身を認証します。スーパーユーザー特権がない場合は、root で認証するよう求められます。ユーザーを追加および削除するには、+ ボタンと - ボタンをそれぞれクリックします。管理グループ wheel にユーザーを追加するには、アカウントの種類を Standard から Administrator に変更します。ユーザーの言語設定を編集するには、言語を選択します (ドロップダウンメニューが表示されます)。

図4.1 ユーザー設定ツール

ユーザー設定ツール

新しいユーザーを作成しても、パスワードを設定するまでアカウントは無効になります。Password (パスワード) ドロップダウンメニュー (図4.2「パスワードメニュー」 を参照) には、管理者がすぐにパスワードを設定できるオプションが含まれます。最初のログイン時にユーザーがパスワードを選択するか、ログインパスワードなしでゲストアカウントを作成します。また、このメニューからアカウントを無効または有効にすることもできます。

図4.2 パスワードメニュー

パスワードメニュー

4.3. コマンドラインツールの使用

「グラフィカル環境でのユーザーの管理」 で説明されている Users 設定ツール (ユーザーの基本的な管理用) のほかに、表4.1「ユーザーとグループを管理するためのコマンドラインユーティリティー」 に挙げられているユーザーとグループの管理コマンドラインツールを使用できます。

表4.1 ユーザーとグループを管理するためのコマンドラインユーティリティー

ユーティリティー詳細

id

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

useraddusermoduserdel

ユーザーアカウントを追加、修正、削除する標準ユーティリティーです。

groupaddgroupmodgroupdel

グループを追加、修正、削除する標準ユーティリティーです。

gpasswd

ユーティリティーは、主に、newgrp コマンドが使用する /etc/gshadow ファイルでグループパスワードの修正に使用されます。

pwckgrpck

パスワード、グループ、関連シャドウファイルを検証するユーティリティーです。

pwconvpwunconv

通常のパスワードをシャドウパスワードに変換する、またはシャドウパスワードから通常のパスワードに変換するユーティリティーです。

grpconvgrpunconv

pwconv、pwunconv と同様、このユーティリティーは、グループアカウントのシャドウ化された情報を変換するのに使用できます。

4.3.1. 新規ユーザーの追加

システムにユーザーを追加するには、root で次のコマンドを実行します。

useradd options username

ここで、options表4.2「一般的な useradd コマンドラインオプション」 で説明されているコマンドラインオプションです。

デフォルトでは、useradd コマンドは、ロックされたユーザーアカウントを作成します。アカウントをアンロックするには、root で次のコマンドを実行して、パスワードを割り当てます。

passwd username

オプションで、パスワードエージングポリシーを設定できます。詳細は、Red Hat Enterprise Linux 7 セキュリティーガイドPassword Security セクションをご覧ください。

表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 範囲が変更になりました。以前はシステムユーザーに UID 1 ~ 499 が使用され、それよりも上の値が通常のユーザーに使用されていました。変更後は、システムユーザーのデフォルト範囲が 1 ~ 999 になりました。この変更により、既存のユーザーの UID と GID に 500 ~ 999 を使用している場合に Red Hat Enterprise Linux 7 に移行すると、問題が発生する場合があります。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 コマンドを使用して、このアカウントにパスワードを割り当てる必要があります。オプションでパスワードエージングのガイドラインを設定することもできます (詳細は Red Hat Enterprise Linux 7 セキュリティーガイドパスワードセキュリティー を参照)。

4.3.2. 新規グループの追加

システムに新しいグループを追加するには、root で次のコマンドを実行します。

groupadd options group_name

ここで、options表4.3「一般的な groupadd コマンドラインオプション」 で説明されているコマンドラインオプションです。

表4.3 一般的な groupadd コマンドラインオプション

オプション詳細

-f, --force

-g gid を使用し、gid が存在していると、groupadd により、そのグループに別の一意の gid を選択します。

-g gid

グループのグループ ID です。一意の番号で 999 より大きい数でなければなりません。

-K, --key key=value

/etc/login.defs のデフォルトを上書きします。

-o--non-unique

GID が重複するグループの作成を許可します。

-p, --password password

新規グループ用にこの暗号化されたパスワードを使用します。

-r

GID が 1000 未満のシステムグループを作成します。

4.3.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.3.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.3.5. umask を使用した、新規ファイルのデフォルト権限の設定

プロセスがファイルを作成すると、そのファイルにはデフォルト権限 (-rw-rw-r-- など) が設定されます。こうした初期権限は、ファイルモード作成マスク (ファイル権限マスク または umask とも呼ばれる) で部分的に定義されます。たとえば、bashumask は、デフォルトで 0022 となるなど、すべてのプロセスにそれぞれの umask が設定されています。プロセスの umask は変更できます。

umask を構成するもの

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

  • 0 = 意味なし。必ず 0 になります (umask は特別なビットに影響しません)。
  • 1 = オーナーの権限。実行ビットが設定されます。
  • 3 = グループの権限。実行ビットおよび書き込みビットが設定されます。
  • 7 = その他のユーザーの権限。実行ビット、書き込みビット、読み取りビットが設定されます。

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

umask の仕組み

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

  • umask に設定しているビットは、ファイルには設定されません。
  • umask に設定していないビットは、他の要素にもよりますが、ファイルに設定されます。

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

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

ユーザーグループ umask の例
重要

セキュリティー上の理由から、レギュラーファイルにはデフォルトで実行権限が設定されていません。したがって、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.3.5.1. シェルで umask の管理

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

現在のマスクの表示

現在の umask を 8 進法で表示するには、以下のコマンドを実行します。

~]$ umask
0022

現在の umask をシンボリック表示で表示するには、以下のコマンドを実行します。

~]$ umask -S
u=rwx,g=rx,o=rx
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=
デフォルトシェルの 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
特定ユーザーのデフォルトシェルの umask での作業

デフォルトでは、新規ユーザーのデフォルトの bashumask は、/etc/bashrc に定義したものに設定されます。

特定ユーザーの bash umask を変更するには、そのユーザーの $HOME/.bashrc ファイルで、umask コマンドの呼び出しを追加します。たとえば、ユーザー johnbashumask0227 に変更するには、次のコマンドを実行します。

john@server ~]$ echo 'umask 227' >> /home/john/.bashrc
新しく作成されたホームディレクトリーのデフォルト権限設定

作成したユーザーホームディレクトリーの権限を変更するには、/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.4. 関連資料

Red Hat Enterprise Linux でユーザーとグループを管理する方法は、下記の資料を参照してください。

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

ユーザーおよびグループの管理に使用する各種ユーティリティーの詳細情報は、以下の 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 を表示する方法が説明されています。
  • umask(2): umask コマンドの man ページでは、ファイルモード作成マスクの使用方法が説明されています。

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

  • group(5): /etc/group ファイルの man ページでは、システムグループを定義する方法が説明されています。
  • passwd(5): /etc/passwd ファイルの man ページでは、このファイルを使用して、ユーザー情報を定義する方法が説明されています。
  • shadow(5): /etc/shadow ファイルの man ページでは、システムでパスワードおよびアカウントの有効期限情報を設定する方法が説明されています。

オンラインドキュメント

  • Red Hat Enterprise Linux 7 セキュリティーガイド: Red Hat Enterprise Linux 7 の セキュリティーガイド では、パスワードのエージングとユーザーアカウントのロックを有効にして、パスワードとワークステーションのセキュリティーを高める追加情報を提供しています。

関連項目

  • 6章権限の取得 では、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。

第5章 アクセス制御リスト

ファイルとディレクトリーには、ファイルの所有者、そのファイルに関連したグループ、およびシステムを使用する他のすべてのユーザーの権限セットが設定されます。しかし、これらの権限には制限があります。たとえば、ユーザーごとに異なる権限を設定することはできません。そのため アクセス制御リスト (ACL) が実装されています。

Red Hat Enterprise Linux カーネルは、ext3 ファイルシステムと NFS でエクスポートしたファイルシステムに対して ACL サポートを提供します。ACL は、Samba 経由でアクセスする ext3 ファイルシステムでも認識されます。

ACL の実装には、カーネルでのサポートと acl パッケージが必要になります。このパッケージには、ACL 情報の追加、修正、削除および、取得のためのユーティリティーが同梱されています。

cp コマンドと mv コマンドは、ファイルとディレクトリーに関連するすべての ACL のコピーまたは移動を実行します。

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

ファイルやディレクトリー用に ACL を使用する前に、そのファイルまたはディレクトリーのパーティションを ACL サポートでマウントする必要があります。ローカルの ext3 ファイルシステムの場合は、以下のコマンドでマウントできます。

mount -t ext3 -o acl device-name partition

以下に例を示します。

mount -t ext3 -o acl /dev/VolGroup00/LogVol02 /work

もしくは、パーティションが /etc/fstab ファイルにリストされている場合は、パーティションのエントリーに acl オプションを含むことができます。

LABEL=/work   /work    ext3  acl    1 2

Samba 経由で ext3 ファイルシステムにアクセスし、そのアクセスに対して ACL が有効になっている場合は、ACL が認識されます。これは、--with-acl-support オプションでコンパイルされているためです。Samba 共有のアクセス時またはマウント時に特別なフラグは必要ありません。

5.1.1. NFS

デフォルトでは、NFS サーバーでエクスポートされているファイルシステムが ACL をサポートし、NFS クライアントが ACL を読み込める場合は、クライアントシステムで ACL が使用されています。

サーバーを設定する際に NFS 共有上の ACL を無効にするには、/etc/exports ファイルに no_acl オプションを追加します。クライアントに NFS 共有をマウントする際に ACL を無効にするには、コマンドライン経由、または /etc/fstab ファイルに no_acl オプションを追加してマウントします。

5.2. アクセス ACL の設定

ACL には、アクセス ACLデフォルト ACL と 2 つのタイプがあります。アクセス ACL は、特定のファイルまたはディレクトリーに対するアクセス制御リストです。デフォルト ACL は、ディレクトリーにのみ適用されます。ディレクトリー内のファイルにアクセス ACL が設定されていない場合は、そのディレクトリーにデフォルト ACL のルールが適用されます。デフォルト ACL は任意です。

ACL は以下のように設定できます。

  1. 各ユーザー
  2. 各グループ
  3. 実効権マスクを使用して
  4. ファイルのユーザーグループに属さないユーザーに対して

setfacl ユーティリティーは、ファイルとディレクトリー用の ACL を設定します。-m オプションを使用すると、ファイルまたはディレクトリーの ACL を追加または修正できます。

# setfacl -m rules files

ルール (rules) は、以下の形式で指定する必要があります。複数のルールをコンマで区切って同じコマンドに指定することもできます。

u:uid:perms
ユーザーにアクセス ACL を設定します。ユーザー名または UID を指定できます。システムで有効な任意のユーザーを指定できます。
g:gid:perms
グループにアクセス ACL を設定します。グループ名または GID を指定できます。システムで有効な任意のグループを指定できます。
m:perms
実効権マスクを設定します。このマスクは、所有グループの全権限と、ユーザーおよびグループの全エントリーを結合したものです。
o:perms
ファイルのグループに属さないユーザーにアクセス ACL を設定します。

権限 (perms) は、読み取り、書き込み、および実行を表す rw、および x の文字の組み合わせで表示されます。

ファイルまたはディレクトリーにすでに ACL が設定されている状態で、setfacl コマンドを使用した場合は、設定するルールが既存の ACL に追加されるか、または既存のルールが修正されます。

例5.1 読み取りと書き込みの権限付与

たとえば、ユーザー「andrius」に読み取りと書き込みの権限を付与するには以下を実行します。

# setfacl -m u:andrius:rw /project/somefile

ユーザー、グループ、またはその他のユーザーからすべての権限を削除するには、-x オプションにいずれの権限も指定せずにコマンドを実行します。

# setfacl -x rules files

例5.2 すべての権限の削除

たとえば、UID 500 のユーザーからすべての権限を削除するには以下を実行します。

# setfacl -x u:500 /project/somefile

5.3. デフォルト ACL の設定

デフォルト ACL を設定するには、d: をルールの前に追加してから、ファイル名ではなくディレクトリー名を指定します。

例5.3 デフォルト ACL の設定

たとえば、/share/ ディレクトリーにデフォルト ACL を設定し、ユーザーグループに属さないユーザーの読み取りと実行を設定するには、以下のコマンドを実行します (これにより、個別ファイルのアクセス ACL が上書きされます)。

# setfacl -m d:o:rx /share

5.4. ACL の取り込み

ファイルまたはディレクトリーに設定されている ACL を確認するには、getfacl コマンドを使用します。以下の例では、getfacl でファイルの既存 ACL を確認します。

例5.4 ACL の取り込み

# getfacl home/john/picture.png

上記のコマンドは、次のような出力を返します。

# file: home/john/picture.png
# owner: john
# group: john
user::rw-
group::r--
other::r--

ディレクトリーにデフォルト ACL が指定されている場合は、以下のようにデフォルト ACL も表示されます。たとえば、getfacl home/sales/ を実行すると以下のような出力になります。

# file: home/sales/
# owner: john
# group: john
user::rw-
user:barryg:r--
group::r--
mask::r--
other::r--
default:user::rwx
default:user:john:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

5.5. ACL が設定されているファイルシステムのアーカイブ作成

デフォルトでは、dump コマンドによるバックアップ操作時に ACL が保存されます。tar コマンドで、ファイルまたはファイルシステムのアーカイブを作成する場合は、--acls オプションを付けて ACL を保存します。同様に、cp コマンドで、ACL が設定されているファイルをコピーする場合は、--preserve=mode オプションを付けて ACL もコピーされるようにします。さらに、cp-a オプション (-dR --preserve=all と同等) も、バックアップ時にタイムスタンプ、SELinux コンテキストなどの情報と一緒に ACL を保存します。dumptar、または cp の詳細は、それぞれの man ページを参照してください。

star ユーティリティーは、ファイルのアーカイブ生成に使用される点で tar ユーティリティーと似ています。しかし、一部のオプションは異なります。最も一般的に使用されるオプションの一覧は 表5.1「star のコマンドラインオプション」 を参照してください。すべての利用可能なオプションは、man star を参照してください。このユーティリティーを使用するには star パッケージが必要になります。

表5.1 star のコマンドラインオプション

オプション詳細

-c

アーカイブファイルを作成します。

-n

ファイルを抽出しません。-x と併用すると、ファイルが行う抽出を表示します。

-r

アーカイブ内のファイルを入れ替えます。パスとファイル名が同じファイルが置き換えられ、アーカイブファイルの末尾に書き込まれます。

-t

アーカイブファイルのコンテンツを表示します。

-u

アーカイブファイルを更新します。アーカイブにファイルが存在しない場合や、アーカイブ内にある同名のファイルよりも新しい場合は、そのファイルがアーカイブの末尾に書き込まれます。このオプションは、アーカイブがファイルか、またはバックスペース可能な非ブロックテープの場合にのみ機能します。

-x

アーカイブからファイルを抽出します。-U と併用すると、アーカイブ内のファイルがファイルシステムにあるファイルよりも古い場合、そのファイルは抽出されません。

-help

最も重要なオプションを表示します。

-xhelp

最も重要ではないオプションを表示します。

-/

アーカイブからファイルを抽出する際に、ファイル名から先頭のスラッシュを削除します。デフォルトでは、ファイルの抽出時に先頭のスラッシュが削除されます。

-acl

作成時または抽出時に、ファイルとディレクトリーに関連付けられているすべての ACL をアーカイブするか、または復元します。

5.6. 旧システムとの互換性

指定したファイルシステムのいずかのファイルに ACL が設定されている場合、そのファイルシステムは ext_attr 属性を持ちます。この属性は、以下のコマンドを使用すると確認できます。

# tune2fs -l filesystem-device

ext_attr 属性を持つファイルシステムは古いカーネルでマウントできますが、それらのカーネルは設定されている ACL を強制しません。

バージョン 1.22 以降の e2fsprogs パッケージ (Red Hat Enterprise Linux 2.1 および 4 のバージョンも含む) に含まれている e2fsck ユーティリティーのバージョンは、ext_attr 属性を使用してファイルシステムを確認できます。古いバージョンではこの確認が拒否されます。

5.7. ACL 参照情報

詳細情報は以下の man ページを参照してください。

  • man acl: ACL の説明
  • man getfacl: ファイルアクセス制御リストの取得方法
  • man setfacl: ファイルアクセス制御リストの設定方法
  • man star: star ユーティリティーとそのオプションの詳細説明

第6章 権限の取得

システム管理者は (時にはユーザーも)、管理者アクセスでタスクを実行する必要があります。システムに root ユーザーでアクセスすることは危険を伴う可能性があり、システムおよびデータの著しい破損につながる場合もあります。本章では、susudo といった setuid プログラムを使用して管理者権限を取得する方法を説明します。これらのプログラムを使用すると、高レベルの制御およびシステムセキュリティーを維持しつつ、通常は root ユーザーしかできないタスクを特定のユーザーが実行できます。

管理者制御や潜在的な危険、特権アクセスの不適切な使用によるデータ破損を回避する方法は Red Hat Enterprise Linux 7 セキュリティーガイドを参照してください。

6.1. su ユーティリティーを使用した管理アクセスの設定

ユーザーは、su を実行するとroot パスワードを求められます。認証されると root シェルプロンプトが表示されます。

su コマンドでログインすると、そのユーザーは root ユーザーとなり、システムへの絶対管理アクセスを持つことになります。このアクセスが有効になっている場合は、SELinux によって課される制限が適用されることに注意してください。また、ユーザーが root になったら、パスワードを求められることなく、su コマンドを使用してシステム上の他のユーザーに変更を加えることができます。

このプログラムは非常に強力なので、組織内の管理者はこのコマンドにアクセスできるユーザーを制限してください。

簡単な制限方法は、wheel と呼ばれる特別な管理グループにユーザーを追加することです。これを実行するには、root で以下のコマンドを実行します。

~]# usermod -a -G wheel username

このコマンドで、username を、wheel グループに追加するユーザー名に置き換えます。

また、Users 設定ツールを使用して以下のようにグループのメンバーを修正することもできます。この手順を実行するには、管理者権限が必要なことに注意してください。

  1. Super キーを押してアクティビティーの概要に入り、Users と入力して Enter を押します。ユーザー 設定ツールが表示されます。Super キーはキーボードまたはその他のハードウェアに応じて様々なキーで表示されますが、多くの場合、Windows または Command キーとして通常は Spacebar の左側に表示されます。
  2. 変更を有効にするには、ロック解除 ボタンをクリックし、有効な管理者パスワードを入力します。
  3. 左側の列でユーザーアイコンをクリックし、右側のペインでユーザーのプロパティーを表示します。
  4. アカウントの種類を Standard から Administrator に変更します。これにより、ユーザーが wheel グループに追加されます。

Users ツールの詳細は 「グラフィカル環境でのユーザーの管理」 を参照してください。

wheel グループにユーザーを追加したら、この追加した特定のユーザーにのみ su コマンドの使用を許可することが推奨されます。それには、su の PAM (プラグ可能な認証モジュール) 設定ファイル (/etc/pam.d/su) を編集する必要があります。このファイルをテキストエディターで開き、以下の行の # 文字を削除してコメント設定を解除します。

#auth      required    pam_wheel.so use_uid

この変更で、wheel の管理グループメンバーのみが、su コマンドを使用して別のユーザーに切り換えることができるようになります。

注記

root ユーザーはデフォルトで wheel グループの一員になっています。

6.2. sudo ユーティリティーを使用した管理アクセスを設定

ユーザーに管理アクセスを付与する別のアプローチとして sudo コマンドを利用できます。信頼されるユーザーが、管理コマンドの前に sudo を付けると、このユーザー自身の パスワードが要求されます。ユーザーが認証され、コマンドが許可されると、管理コマンドは root 権限で実行されます。

sudo コマンドの基本的なフォーマットは、以下のとおりです。

sudo command

上記の例の command の部分を、通常は root ユーザーのみが使用する mount といったコマンドに置き換えます。

sudo コマンドでは、ハイレベルの柔軟性が可能になります。たとえば、/etc/sudoers 設定ファイルに記載されているユーザーのみが sudo コマンドを使うことができ、root シェルではなく、そのユーザーの シェルでコマンドが実行されます。これは、Red Hat Enterprise Linux 7 セキュリティーガイド に示されるように、root シェルを完全に無効にできることを意味します。

sudo コマンドを使用した正常な認証のログはすべて /var/log/messages ファイルに記録され、このコマンドを実行したユーザー名で実行されたコマンドは /var/log/secure ファイルに記録されます。新たなログが必要な場合は、以下の行を /etc/pam.d/system-auth ファイルに追加して、pam_tty_audit モジュールで特定ユーザーの TTY 監査を有効にします。

session required pam_tty_audit.so disable=pattern enable=pattern

pattern で表示されるのはコンマで区切ったユーザーのリストで、オプションでグロブを使用できます。たとえば、以下の設定は、root ユーザーのTTY 監査を有効にし、その他のユーザーについては無効にします。

session required pam_tty_audit.so disable=* enable=root
重要

TTY の監査システムの pam_tty_audit PAM モジュールを設定すると、TTY 入力のみが記録されます。つまり、監査されるユーザーがログインすると、pam_tty_audit には、/var/log/audit/audit.log ファイルに記録されるキーストロークと同じ内容が記録されます。詳細は、man ページの pam_tty_audit(8) を参照してください。

sudo コマンドのもう一つの利点は、各ユーザーのニーズに応じて特定のコマンドへのアクセスを管理者が許可できることです。

管理者が sudo 設定ファイルである /etc/sudoers を編集する場合は、visudo コマンドを使用することが推奨されます。

他のユーザーに完全な管理権限を付与する場合は、visudo と入力し、ユーザー権限の指定セクションに以下の行を追加します。

juan ALL=(ALL) ALL

この例では、ユーザーの juan は、sudo を使用すればどのホストからでもどのコマンドを実行できることを示しています。

以下の例では、sudo を設定する際に可能な粒度を示しています。

%users localhost=/usr/sbin/shutdown -h now

この例が示しているのは、コンソールからであれば、 users システムグループのどのユーザーでも、/sbin/shutdown -h now コマンドを実行できるということです。

sudoers の man ページには、このファイルのオプションの詳細なリストが記載されています。

/etc/sudoers ファイルで NOPASSWD オプションを指定して、パスワードを指定する必要がない sudo ユーザーを設定することもできます。

user_name ALL=(ALL)	NOPASSWD: ALL

ただし、このようなユーザーであっても、sudo は PAM (Pluggable Authentication Module) アカウント管理モジュールを実行します。これにより、認証フェーズ外で PAM モジュールに課せられた制限を確認できるようになります。これにより、PAM モジュールが正しく動作するようになります。たとえば、pam_time モジュールの場合、時間ベースのアカウント制限は失敗しません。

警告

PAM ベースのすべてのアクセス制御ルールで、sudo を、許可されるサービスの一覧に常に含めるようにしてください。そうしないと、ユーザーが sudo にアクセスしようとしたときに「permission denied」エラーメッセージが表示されますが、現行のアクセス制御ルールに基づいてアクセスが禁止されます。

詳細は、Red Hat ナレッジベースの記事「After patching to Red Hat Enterprise Linux 7.6 sudo gives a permission denied error.」を参照してください。

重要

sudo コマンドの使用時には、潜在的なリスクがいくつか存在することを覚えておく必要があります。このリスクは、上記のように visudo を使用して /etc/sudoers 設定ファイルを編集することで回避できます。/etc/sudoers ファイルをデフォルトの状態にしておくと、wheel グループのユーザー全員に無制限の root アクセスを与えることになります。

  • sudo は、デフォルトで 5 分間、パスワードを保存します。この間はコマンドを続けて使用しても、ユーザーはパスワードを要求されません。このため、ユーザーがログイン状態のままワークステーションを離れたりロックしない状態にしておくと、攻撃者に悪用されかねません。この動作は、以下の行を /etc/sudoers ファイルに追加することで変更できます。

    Defaults  timestamp_timeout=value

    value には、指定するタイムアウトの分数を入れます。value を 0 にすると sudo は毎回パスワードを要求します。

  • sudo 使用者のアカウントが侵害されると、攻撃者は sudo を使用して管理権限のある新たなシェルを開くことができます。

    sudo /bin/bash

    この方法や同様の方法で root として新たなシェルを開くと、/etc/sudoers ファイルで指定されたタイムアウト時間を無視し、新たに開かれたセッションが閉じられるまで攻撃者に sudo パスワード入力を要求することがないため、理論上は時間の制限なく攻撃者に管理アクセスを与えることになります。

6.3. 関連資料

ユーザーに管理者権限を与えるプログラムは潜在的なセキュリティーリスクでありますが、セキュリティーの説明は本ガイドの対象外となります。セキュリティーや管理者アクセスに関する情報は、以下に挙げる資料を参照してください。

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

  • su(1): su の man ページには、このコマンドで利用可能なオプションの情報があります。
  • sudo(8): sudo の man ページには、このコマンドの動作のカスタマイズで利用可能なオプションのリストがあります。
  • pam(8): この man ページでは、Linux 向け Pluggable Authentication Modules (PAM) の使用方法が説明されています。

オンラインドキュメント

  • Red Hat Enterprise Linux 7 セキュリティーガイド: Red Hat Enterprise Linux 7 の セキュリティーガイド では、setuid プログラムに関する潜在的なセキュリティー問題の詳細と、そのリスクを低減するテクニックを紹介します。

関連項目

  • 4章ユーザーとグループの管理 では、グラフィカルユーザーインターフェースとコマンドラインを使用したシステムユーザーとグループの管理方法を説明します。

パート II. サブスクリプションおよびサポート

Red Hat Enterprise Linux システムのソフトウェアへの更新を受け取るには、Red Hat Content Delivery Network (CDN)、および有効で適切なリポジトリーをサブスクライブしている必要があります。ここでは、システムを Red Hat Content Delivery Network にサブスクライブする方法を説明します。

Red Hat は カスタマーポータル からサポートを提供していますが、このサポートには、Red Hat Support Tool を使用してコマンドラインから直接アクセスできます。ここでは、そのコマンドラインツールの使用方法を説明します。

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

サブスクリプションサービスは、Red Hat ソフトウェアインベントリーを処理するメカニズムを提供し、yum パッケージマネージャーを使用して追加のソフトウェアをインストールしたり、インストールされているプログラムを新規バージョンに更新したりすることを可能にします。Red Hat Enterprise Linux 7 で、システムを登録し、サブスクリプションを割り当てる方法としては Red Hat サブスクリプション管理 の使用が推奨されます。

注記

さらに、初期設定プロセスでのインストール後にシステムを登録し、サブスクリプションを割り当てることもできます。初期設定の詳細情報は、Red Hat Enterprise Linux 7 の インストールガイド初期設定と初期起動 の章を参照してください。初期設定アプリケーションは、インストール時に X Window System でインストールしたシステムでのみ利用できることに注意してください。

7.1. システム登録およびサブスクリプションの割り当て

Red Hat Subscription Management を使用してシステムを登録し、1 つ以上のサブスクリプションを割り当てる手順を完了してください。subscription-manager コマンドはすべて root で実行することに注意してください。

  1. 以下のコマンドを実行してシステムを登録します。ユーザー名とパスワードを入力するように求められます。ユーザー名とパスワードは、Red Hat カスタマーポータルのログイン認証情報と同じであることに注意してください。

    subscription-manager register
  2. 必要なサブスクリプションのプール ID を確認します。これを行うには、シェルプロンプトで以下のコマンドを入力し、システムで利用できるサブスクリプションの一覧を表示します。

    subscription-manager list --available

    このコマンドは、利用可能な各サブスクリプションの名前、固有 ID、有効期限、およびそのサブスクリプションに関連するその他の詳細情報を表示します。全アーキテクチャー向けのサブスクリプションを一覧表示するには、--all オプションを追加します。プール ID は、Pool ID で始まる行に一覧表示されます。

  3. 以下のコマンドを実行して、該当するサブスクリプションをシステムに割り当てます。

    subscription-manager attach --pool=pool_id

    pool_id を、直前のステップで確認したプール ID に置き換えます。

    システムに割り当てているサブスクリプションの一覧を随時確認するには、以下を実行します。

    subscription-manager list --consumed

Red Hat Subscription Management を使用してシステムを登録し、サブスクリプションに関連付ける方法は、「Red Hat Subscription-Manager を使用して Red Hat カスタマーポータルにシステムを登録してサブスクライブする」 を参照してください。サブスクリプションに関する包括的な情報は Red Hat Subscription Management のガイドを参照してください。

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

Red Hat コンテンツ配信ネットワークにシステムをサブスクライブすると、/etc/yum.repos.d/ ディレクトリーにリポジトリーファイルが作成されます。これを確認するには、yum を使用して有効にしたリポジトリーの一覧を表示します。

yum repolist

Red Hat Subscription Management を使用すると、Red Hat が提供するソフトウェアリポジトリーを手動で有効にしたり、無効にしたりすることもできます。利用可能なリポジトリーの一覧を表示するには、以下のコマンドを実行します。

subscription-manager repos --list

リポジトリー名は、使用している Red Hat Enterprise Linux のバージョンによって異なり、以下のフォーマットに基づいています。

rhel-version-variant-rpms
rhel-version-variant-debug-rpms
rhel-version-variant-source-rpms

ここで、version は Red Hat Enterprise Linux システムのバージョン (6 または 7) を示し、variant は Red Hat Enterprise Linux システムのバリアント (server または workstation) を示します。以下は例になります。

rhel-7-server-rpms
rhel-7-server-debug-rpms
rhel-7-server-source-rpms

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

subscription-manager repos --enable repository

repository を、有効にするリポジトリーの名前に置き換えます。

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

subscription-manager repos --disable repository

「Yum と Yum リポジトリーの設定」 では、yum を使用したソフトウェアリポジトリー管理の詳細情報を説明します。

リポジトリーの更新を自動的にダウンロードするには、yum-cron サービスを使用できます。詳細は「yum-cron を使用したパッケージデータベースの自動更新および更新のダウンロード」を参照してください。

7.3. サブスクリプションの削除

特定のサブスクリプションを削除するには、以下の手順を行います。

  1. すでに割り当てられているサブスクリプションの情報を一覧表示し、削除する必要があるサブスクリプションのシリアル番号を確認します。

    subscription-manager list --consumed

    シリアル番号は、serial に記載されている番号です。たとえば、以下の例では 744993814251016831 になります。

    SKU:        ES0113909
    Contract:     01234567
    Account:      1234567
    Serial:      744993814251016831
    Pool ID:      8a85f9894bba16dc014bccdd905a5e23
    Active:      False
    Quantity Used:   1
    Service Level:   SELF-SUPPORT
    Service Type:   L1-L3
    Status Details:
    Subscription Type: Standard
    Starts:      02/27/2015
    Ends:       02/27/2016
    System Type:    Virtual
  2. 以下のコマンドを実行して、選択したサブスクリプションを削除します。

    subscription-manager remove --serial=serial_number

    serial_number を、直前のステップで確認したシリアル番号に置き換えます。

システムに割り当てられているすべてのサブスクリプションを削除するには、以下のコマンドを実行します。

subscription-manager remove --all

7.4. 関連資料

Red Hat Subscription Management を使用してシステムを登録し、サブスクリプションに関連付ける方法は、以下の資料を参照してください。

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

  • subscription-manager(8): Red Hat Subscription Management の man ページは、サポートされているオプションおよびコマンドの完全リストを提供します。

関連項目

  • 6章権限の取得 では、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。
  • 9章Yum では、yum パッケージマネージャーを使用してソフトウェアをインストールし、更新する方法を提供しています。

第8章 Red Hat Support Tool を使用したサポートへのアクセス

redhat-support-tool パッケージの Red Hat Support Tool はインタラクティブシェルおよび単一実行プログラムとして機能します。SSH または任意のターミナルで実行できます。また、コマンドラインから Red Hat ナレッジベースを検索したり、コマンドラインでソリューションを直接コピーしたり、サポートケースを作成または更新したり、分析のために Red Hat にファイルを送信したりできます。

8.1. Red Hat Support Tool のインストール

Red Hat Support Tool はデフォルトで Red Hat Enterprise Linux にインストールされます。必要な場合は、確実にインストールするために root で以下のコマンドを入力します。

~]# yum install redhat-support-tool

8.2. コマンドラインを使用した Red Hat Support Tool の登録

コマンドラインを使用して Red Hat Support Tool をカスタマーポータルに登録するには、以下のコマンドを実行します。

~]# redhat-support-tool config user username

username は、Red Hat カスタマーポータルアカウントのユーザー名に置き換えます。

~]# redhat-support-tool config password
Please enter the password for username:

8.3. インタラクティブシェルモードでの Red Hat Support Tool の使用

インタラクティブモードでツールを起動するには、以下のコマンドを入力します。

~]$ redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help):

ツールは、非特権ユーザーまたは root で実行できます。非特権ユーザーの場合は使用できるコマンドが少なくなります、

? 文字を入力するとコマンドの一覧を表示できます。プログラムまたはメニューの選択は、q または e の文字を入力して終了できます。ナレッジベースまたはサポートケースを初めて検索する場合は、Red Hat カスタマーポータルのユーザー名とパスワードを入力するよう求められます。また、インタラクティブモードで Red Hat カスタマーポータルアカウントのユーザー名とパスワードを設定し、オプションで設定ファイルに保存することもできます。

8.4. Red Hat Support Tool の設定

インタラクティブモードの場合は、コマンド config --help を入力して設定オプションの一覧を表示できます。

~]# redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help): config --help

Usage: config [options] config.option <new option value>

Use the 'config' command to set or get configuration file values.
Options:
 -h, --help  show this help message and exit
 -g, --global Save configuration option in /etc/redhat-support-tool.conf.
 -u, --unset  Unset configuration option.

The configuration file options which can be set are:
 user   : The Red Hat Customer Portal user.
 password : The Red Hat Customer Portal password.
 debug   : CRITICAL, ERROR, WARNING, INFO, or DEBUG
 url    : The support services URL. Default=https://api.access.redhat.com
 proxy_url : A proxy server URL.
 proxy_user: A proxy server user.
 proxy_password: A password for the proxy server user.
 ssl_ca  : Path to certificate authorities to trust during communication.
 kern_debug_dir: Path to the directory where kernel debug symbols should be downloaded and cached. Default=/var/lib/redhat-support-tool/debugkernels

Examples:
- config user
- config user my-rhn-username
- config --unset user

インタラクティブモードでの Red Hat Support Tool の登録

インタラクティブモードを使用して Red Hat Support Tool をカスタマーポータルに登録するには、以下のコマンドを実行します。

  1. 以下のコマンドを入力してツールを起動します。

    ~]# redhat-support-tool
  2. Red Hat カスタマーポータルのユーザー名を入力します。

    Command (? for help): config user username

    ユーザー名をグローバル設定ファイルに保存するには、-g オプションを追加します。

  3. Red Hat カスタマーポータルのパスワードを入力します。

    Command (? for help): config password
    Please enter the password for username:

8.4.1. 設定ファイルへの設定の保存

Red Hat Support Tool は、(他の方法が設定されていない場合に) ~/.redhat-support-tool/redhat-support-tool.conf 設定ファイルを使用して現在のユーザーのホームディレクトリーに値とオプションをローカルで保存します。必要に応じて、パスワードをこのファイルに保存することが推奨されます。この場合、パスワードは特定のユーザーのみが確認できます。ツールが起動すると、グローバル設定ファイル /etc/redhat-support-tool.conf とローカル設定ファイルから値が読み取られます。ローカルに保存された値とオプションは、グローバルに保存された設定よりも優先されます。

警告

グローバルな /etc/redhat-support-tool.conf 設定ファイルにパスワードを保存することは推奨されません。パスワードは base64 でエンコードされているだけなので簡単にデコードできます。また、ファイルは誰でも読み取り可能です。

値とオプションをグローバル設定ファイルに保存するには、以下のように -g, --global オプションを追加します。

Command (? for help): config setting -g 値
注記

-g, --global オプションを使用して設定をグローバルで保存できるようにするには、Red Hat Support Toolroot で実行する必要があります。これは、通常のユーザーには /etc/redhat-support-tool.conf への書き込みに必要なパーミッションがないためです。

値またはオプションをローカル設定ファイルから削除するには、以下のように -u, --unset オプションを追加します。

Command (? for help): config setting -u 値

これにより、ツールからパラメーターが削除および設定解除され、(利用可能な場合は) グローバル設定ファイルにある同等の設定が使用されます。

注記

非特権ユーザーとして実行している場合は、グローバル設定ファイルに保存される値は -u, --unset オプションで削除できません。しかし、-g, --global オプションと -u, --unset オプションを同時に使用して、ツールの現在の実行中のインスタンスから、設定を解除することができます。root で実行している場合は、-g, --global-u, --unset オプションを同時に使用してグローバル設定ファイルから値とオプションを削除できます。

8.5. インタラクティブモードでのサポートケースの作成および更新

インタラクティブモードでの新しいサポートケースの作成

インタラクティブモードで新しいサポートケースを作成するには、以下の手順を実行します。

  1. 以下のコマンドを入力してツールを起動します。

    ~]# redhat-support-tool
  2. opencase コマンドを入力します。

    Command (? for help): opencase
  3. 画面に表示されたプロンプトに従って製品とバージョンを選択します。
  4. ケースの要約を入力します。
  5. ケースの説明を入力し、完了したら空の行で Ctrl+D を押します。
  6. ケースの重大度を選択します。
  7. オプションで、サポートケースを作成する前に、この問題のソリューションが存在するかどうかを確認することを選択します。
  8. サポートケースを作成することを確定します。

    Support case 0123456789 has successfully been opened
  9. オプションで、SOS レポートを添付することを選択します。
  10. オプションで、ファイルを添付することを選択します。

インタラクティブモードでの既存のサポートケースの表示および更新

インタラクティブモードで既存のサポートケースを表示および更新するには、以下の手順を実行します。

  1. 以下のコマンドを入力してツールを起動します。

    ~]# redhat-support-tool
  2. getcase コマンドを入力します。

    Command (? for help): getcase case-number

    case-number は、表示および更新するケースの番号です。

  3. 画面に表示されたプロンプトに従ってケースを表示し、コメントを変更または追加して、添付ファイルを取得または追加します。

インタラクティブモードでの既存のサポートケースの変更

インタラクティブモードで既存のサポートケースの属性を変更するには、以下の手順を実行します。

  1. 以下のコマンドを入力してツールを起動します。

    ~]# redhat-support-tool
  2. modifycase コマンドを入力します。

    Command (? for help): modifycase case-number

    case-number は、表示および更新するケースの番号です。

  3. 変更の選択リストが表示されます。

    Type the number of the attribute to modify or 'e' to return to the previous menu.
     1 Modify Type
     2 Modify Severity
     3 Modify Status
     4 Modify Alternative-ID
     5 Modify Product
     6 Modify Version
    End of options.

    画面に表示されたプロンプトに従って 1 つまたは複数のオプションを変更します。

  4. たとえば、ステータスを変更する場合は、3 と入力します。

    Selection: 3
     1  Waiting on Customer
     2  Waiting on Red Hat
     3  Closed
    Please select a status (or 'q' to exit):

8.6. コマンドラインでのサポートケースの表示

コマンドラインでケースの内容を表示すると、コマンドラインからソリューションを素早く簡単に適用できます。

コマンドラインで既存のサポートケースを表示するには、以下のようにコマンドを入力します。

~]# redhat-support-tool getcase case-number

case-number は、ダウンロードするケースの番号です。

8.7. 関連資料

Red Hat ナレッジベースの記事 Red Hat Support Tool には、追加情報、例、および動画チュートリアルが含まれます。

パート III. ソフトウェアのインストールおよび管理

Red Hat Enterprise Linux システムのソフトウェアすべては RPM パッケージとして分割されており、インストール、アップグレード、削除が可能です。ここで、Yum を使用して Red Hat Enterprise Linux でパッケージを管理する方法を説明します。

第9章 Yum

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

yum は、新たに追加されたリポジトリー、または パッケージソース で設定でき、その機能を強化または拡張するプラグインを多数提供します。また、Yum は RPM が実行可能な同じタスクの多くを行うことができます。さらに、多数のコマンドラインオプションも似ています。Yum を使用することで、1 つのマシンまたはマシンのグループ上でのパッケージ管理を簡単かつシンプルに行うことができます。

以下のセクションでは、ご使用のシステムが、 Red Hat Enterprise Linux 7 インストールガイド の従ってインストール中に Red Hat サブスクリプション管理で登録されたことを前提としています。システムがサブスクライブされていない場合は、7章システム登録およびサブスクリプション管理 を参照してください。

重要

Yum は、GPG (Gnu Privacy Guard (別名 GnuPG)) の署名付きパッケージの GPG 署名認証をすべてのパッケージリポジトリー (パッケージソース) または個々のリポジトリーで有効にすることで、セキュアなパッケージ管理を実現します。署名認証が有効になっていると、Yum は正しいキーで GPG 署名されていないパッケージのそのリポジトリーへのインストールを拒否します。つまり、使用中のシステムにダウンロードしてインストールする RPM パッケージが Red Hat などの信頼されたソースからのものであり、ダウンロード中に変更されていないことを保証します。Yum の署名認証を有効にする方法は 「Yum と Yum リポジトリーの設定」 を参照してください。

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

システム管理タスクの実行には Yum が最速の方法であることが多いため、これを使用することが推奨されます。また、Yum は、PackageKit グラフィカルパッケージ管理ツールが提供する以上の機能を提供します。

注記

yum を使用して、システムにパッケージをインストール、更新、削除するにはスーパーユーザー権限が必要です。本章のすべての例では、su または sudo コマンドを使用することでスーパーユーザー権限をすでに持っていると仮定しています。

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

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

9.1.1. 更新の確認

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

yum check-update

例9.1 yum check-update コマンドの出力例

yum check-update の出力は以下のようになります。

~]# yum check-update
Loaded plugins: product-id, search-disabled-repos, subscription-manager
dracut.x86_64             033-360.el7_2   rhel-7-server-rpms
dracut-config-rescue.x86_64      033-360.el7_2   rhel-7-server-rpms
kernel.x86_64             3.10.0-327.el7   rhel-7-server-rpms
rpm.x86_64              4.11.3-17.el7   rhel-7-server-rpms
rpm-libs.x86_64            4.11.3-17.el7   rhel-7-server-rpms
rpm-python.x86_64           4.11.3-17.el7   rhel-7-server-rpms
yum.noarch              3.4.3-132.el7   rhel-7-server-rpms

上記の出力に表示されているパッケージには利用可能な更新があります。一覧の最初のパッケージは dracut です。出力例の各行は複数の項目で構成されます。dracut の場合は、以下の構成になっています。

  • dracut: パッケージ名
  • x86_64: パッケージがビルドされた CPU アーキテクチャー
  • 033: インストールする更新パッケージのバージョン
  • 360.el7: 更新パッケージのリリース
  • _2: ビルドバージョン (z-stream 更新として追加)
  • rhel-7-server-rpms: 更新済みのパッケージがあるリポジトリー

また上記の出力はすべて、yum コマンドを使用してカーネル (yum パッケージ)、Yum および RPM (yum および rpm パッケージ)、さらにはその依存関係 (rpm-libsrpm-python パッケージ) をすべて更新できることも示しています。

9.1.2. パッケージの更新

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

単一パッケージの更新

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

yum update package_name

例9.2 rpm パッケージの更新

rpm パッケージを更新するには、以下を入力します。

~]# yum update rpm
Loaded plugins: langpacks, product-id, subscription-manager
Updating Red Hat repositories.
INFO:rhsm-app.repolib:repos updated: 0
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package rpm.x86_64 0:4.11.1-3.el7 will be updated
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-libs-4.11.1-3.el7.x86_64
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-python-4.11.1-3.el7.x86_64
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-build-4.11.1-3.el7.x86_64
---> Package rpm.x86_64 0:4.11.2-2.el7 will be an update
--> Running transaction check
...
--> Finished Dependency Resolution

Dependencies Resolved
=============================================================================
 Package          Arch    Version     Repository    Size
=============================================================================
Updating:
 rpm            x86_64   4.11.2-2.el7  rhel      1.1 M
Updating for dependencies:
 rpm-build         x86_64   4.11.2-2.el7  rhel      139 k
 rpm-build-libs      x86_64   4.11.2-2.el7  rhel       98 k
 rpm-libs         x86_64   4.11.2-2.el7  rhel      261 k
 rpm-python        x86_64   4.11.2-2.el7  rhel       74 k

Transaction Summary
=============================================================================
Upgrade 1 Package (+4 Dependent packages)

Total size: 1.7 M
Is this ok [y/d/N]:

この出力で重要となる項目がいくつかあります。

  1. Loaded plugins: langpacks, product-id, subscription-manager: yum は、どの Yum プラグインがインストールされ有効であるかを常に通知します。Yum プラグインに関する一般的情報は 「yum のプラグイン」 を参照してください。また、個別のプラグインに関する説明は 「yum プラグインの使用方法」 を参照してください。
  2. rpm.x86_64: 新しい rpm パッケージとその依存関係をダウンロードしてインストールできます。これらの各パッケージに対してトランザクションチェックが行われます。
  3. yum を使用すると、更新情報を表示し、更新を確認できます。yum は、デフォルトで対話的に動作します。yum コマンドが実行する予定のトランザクションがすでに分かっている場合は、-y オプションを使用して、yum が質問する質問 (この場合は非対話的に実行) に対して、自動的に yes と回答できます。オプションを使用して、yum が尋ねるすべての質問に自動的に yes と回答するように設定できます (この場合は非対話的に実行されます)。ただし、yum によりシステムに行われる変更を常に調べる必要があります。これを行うには、ダウンロードプロンプトで d オプションを選択します。これにより、選択されたパッケージのバックグラウンドでのダウンロードが開始します。

    トランザクションが正しく行われなかった場合は、「トランザクション履歴の活用」 にあるように yum history コマンドを使用して Yum のトランザクション履歴を表示できます。

重要

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

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

同様に、パッケージグループを更新できます。root で次のコマンドを入力します。

yum group update group_name

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

Yum は、obsoletes 設定オプションを有効にして 更新 する upgrade コマンドも提供します (「[main] オプションの設定」 を参照)。obsoletes/etc/yum.conf で on になっており、これによりこの 2 つのコマンドが同等のものになっています。

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

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

yum update
yum update --security

また、最新のセキュリティー更新を含むバージョンにのみパッケージを更新することもできます。root で次のコマンドを入力します。

yum update-minimal --security

たとえば、以下の例を考えてみます。

  • kernel-3.10.0-1 パッケージがシステムにインストールされている。
  • kernel-3.10.0-2 パッケージがセキュリティ更新としてリリースされている。
  • kernel-3.10.0-3 パッケージがバグ修正の更新としてリリースされている。

この場合、yum update-minimal --security だとパッケージが kernel-3.10.0-2 に更新され、yum update --security だとパッケージが kernel-3.10.0-3 に更新されます。

パッケージの自動更新

パッケージのデータベースを更新し、更新を自動的にダウンロードするには、yum-cron サービスを使用できます。詳細は「yum-cron を使用したパッケージデータベースの自動更新および更新のダウンロード」を参照してください。

9.1.3. ISO と Yum を使用してシステムをオフラインでアップグレード

インターネットまたは Red Hat Network から切断されたシステムの場合は、yum update コマンドと Red Hat Enterprise Linux インストール ISO イメージを使用すると、システムを最新のマイナーバージョンに簡単かつ素早くアップグレードできます。以下の手順はアップグレードプロセスを示しています。

  1. ISO イメージをマウントするターゲットディレクトリーを作成します。このディレクトリーは、マウント時に自動的に作成されません。root で以下のコマンドを実行します。

    mkdir mount_dir

    mount_dir は、マウントディレクトリーへのパスに置き換えます。通常は、ユーザーが /media ディレクトリー内のサブディレクトリーとして作成します。

  2. 以前に作成されたターゲットディレクトリーに Red Hat Enterprise Linux 7 インストール ISO イメージをマウントします。root で以下のコマンドを実行します。

    mount -o loop iso_name mount_dir

    iso_name を ISO イメージへのパスと置き換え、mount_dir をターゲットディレクトリーへのパスと置き換えます。ブロックデバイスとしてファイルをマウントするには、-o loop オプションが必要です。

  3. media.repo ファイルをマウントディレクトリーから /etc/yum.repos.d/ ディレクトリーにコピーします。正常に機能するために、このディレクトリーの設定ファイルの拡張子は .repo である必要があります。

    cp mount_dir/media.repo /etc/yum.repos.d/new.repo

    これにより、yum リポジトリーの設定ファイルが作成されます。new.repo をファイル名と置き換えます (例: rhel7.repo)。

  4. Red Hat Enterprise Linux インストール ISO を参照するよう新しい設定ファイルを編集します。以下の行を /etc/yum.repos.d/new.repo ファイルに追加します。

    baseurl=file:///mount_dir

    mount_dir をマウントポイントへのパスと置き換えます。

  5. 前の手順で作成された /etc/yum.repos.d/new.repo を含むすべての yum リポジトリーを更新します。root で以下のコマンドを実行します。

    yum update

    これにより、システムはマウントされた ISO イメージで提供されたバージョンにアップグレードされます。

  6. アップグレードに成功したら、ISO イメージをアンマウントできます。root で以下のコマンドを実行します。

    umount mount_dir

    ここで、mount_dir はマウントディレクトリーへのパスです。また、最初の手順で作成されたマウントディレクトリーを削除することもできます。root で以下のコマンドを実行します。

    rmdir mount_dir
  7. 以前に作成された設定ファイルを別のインストールまたは更新に使用しない場合は、その設定ファイルを削除できます。root で以下のコマンドを実行します。

    rm /etc/yum.repos.d/new.repo

例9.3 Red Hat Enterprise Linux 7.0 から 7.1 へのアップグレード

インターネットにアクセスせずに ISO イメージ (例: rhel-server-7.1-x86_64-dvd.iso) を使用してシステムを新しいバージョンにアップグレードする必要がある場合は、/media/rhel7/ などのマウント用ターゲットディレクトリーを作成します。root で ISO イメージがあるディレクトリーに移動し、以下のコマンドを入力します。

~]# mount -o loop
    rhel-server-7.1-x86_64-dvd.iso /media/rhel7/

次に、マウントディレクトリーから media.repo ファイルをコピーして、イメージ用の yum リポジトリーをセットアップします。

~]# cp /media/rhel7/media.repo /etc/yum.repos.d/rhel7.repo

yum にマウントポイントをリポジトリーとして認識させるために、前の手順でコピーした /etc/yum.repos.d/rhel7.repo に以下の行を追加します。

baseurl=file:///media/rhel7/

この時点で、yum リポジトリーを更新すると、rhel-server-7.1-x86_64-dvd.iso により提供されたバージョンにシステムがアップグレードされます。root で以下のコマンドを実行します。

~]# yum update

システムが正常にアップグレードされたら、イメージをアンマウントし、ターゲットディレクトリーと設定ファイルを削除できます。

~]# umount /media/rhel7/
~]# rmdir /media/rhel7/
~]# rm
     /etc/yum.repos.d/rhel7.repo

9.2. パッケージでの作業

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

9.2.1. パッケージの検索

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

yum search term&hellip;

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

例9.4 特定の文字列に一致するパッケージの検索

vim や gvim、または emacs に一致するパッケージを一覧表示するには、以下を入力します。

~]$ yum search vim gvim emacs
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
============================= N/S matched: vim ==============================
vim-X11.x86_64 : The VIM version of the vi editor for the X Window System
vim-common.x86_64 : The common files needed by any version of the VIM editor
[output truncated]

============================ N/S matched: emacs =============================
emacs.x86_64 : GNU Emacs text editor
emacs-auctex.noarch : Enhanced TeX modes for Emacs
[output truncated]

 Name and summary matches mostly, use "search all" for everything.
Warning: No matches found for: gvim

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

結果のフィルタリング

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

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

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

以下のセクションの例では、上記の両方の使用例を説明します。

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

すべてのインストール済み および 利用可能なパッケージに関する情報を一覧表示するには、シェルプロンプトで以下を入力します。

yum list all

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

yum list glob_expression&hellip;

例9.5 ABRT 関連パッケージの一覧

各種の ABRT アドオンとプラグインを持つパッケージは abrt-addon- か abrt-plugin- で始まります。これらのパッケージを一覧表示するには、シェルプロンプトで以下を入力します。ワイルドカード文字の前にバックスラッシュ文字を置くことでエスケープしていることに注意してください。

~]$ yum list abrt-addon\* abrt-plugin\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
abrt-addon-ccpp.x86_64          2.1.11-35.el7       @rhel-7-server-rpms
abrt-addon-kerneloops.x86_64       2.1.11-35.el7       @rhel-7-server-rpms
abrt-addon-pstoreoops.x86_64       2.1.11-35.el7       @rhel-7-server-rpms
abrt-addon-python.x86_64         2.1.11-35.el7       @rhel-7-server-rpms
abrt-addon-vmcore.x86_64         2.1.11-35.el7       @rhel-7-server-rpms
abrt-addon-xorg.x86_64          2.1.11-35.el7       @rhel-7-server-rpms

installed キーワードを使用して、システムにインストールされているパッケージを一覧表示するには、以下のコマンドを実行します。出力の右端の列には、パッケージを取得したリポジトリーが表示されます。

yum list installed glob_expression&hellip;

例9.6 インストール済み krb パッケージの一覧表示

以下の例では、krb で始まり、その後に正確に 1 文字とハイフンが続くインストール済みパッケージを一覧表示する方法を示しています。この方法では数字でバージョンが見分けられるので、特定コンポーネントの全バージョンを一覧表示したい場合に便利です。glob 表現全体を引用符で囲むことで適切な処理が確実になります。

~]$ yum list installed "krb?-*"
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
krb5-libs.x86_64         1.13.2-10.el7          @rhel-7-server-rpms

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

yum list available glob_expression&hellip;

例9.7 利用可能な gstreamer プラグインの一覧表示

たとえば、gstreamer とその後に plugin を含む名前の利用可能なパッケージを一覧表示するには、以下のコマンドを実行します。

~]$ yum list available gstreamer*plugin\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Available Packages
gstreamer-plugins-bad-free.i686       0.10.23-20.el7     rhel-7-server-rpms
gstreamer-plugins-base.i686         0.10.36-10.el7     rhel-7-server-rpms
gstreamer-plugins-good.i686         0.10.31-11.el7     rhel-7-server-rpms
gstreamer1-plugins-bad-free.i686      1.4.5-3.el7      rhel-7-server-rpms
gstreamer1-plugins-base.i686        1.4.5-2.el7      rhel-7-server-rpms
gstreamer1-plugins-base-devel.i686     1.4.5-2.el7      rhel-7-server-rpms
gstreamer1-plugins-base-devel.x86_64    1.4.5-2.el7      rhel-7-server-rpms
gstreamer1-plugins-good.i686        1.4.5-2.el7      rhel-7-server-rpms

リポジトリーの一覧表示

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

yum repolist

これらのリポジトリーの詳細情報を一覧表示するには、-v オプションを追加します。このオプションを有効にすると、各リポジトリーでファイル名や全体のサイズ、最終更新日、ベース URL といった情報が表示されます。別の方法としては、repoinfo コマンドを使用して同じ出力を作成することもできます。

yum repolist -v
yum repoinfo

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

yum repolist all

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

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

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

yum info package_name&hellip;

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

例9.8 abrt パッケージ情報の表示

abrt パッケージに関する情報を表示するには、以下を入力します。

~]$ yum info abrt
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
Name    : abrt
Arch    : x86_64
Version   : 2.1.11
Release   : 35.el7
Size    : 2.3 M
Repo    : installed
From repo  : rhel-7-server-rpms
Summary   : Automatic bug detection and reporting tool
URL     : https://fedorahosted.org/abrt/
License   : GPLv2+
Description : abrt is a tool to help users to detect defects in applications and
      : to create a bug report with all information needed by maintainer to fix
      : it. It uses plugin system to extend its functionality.

yum info package_name コマンドは rpm -q --info package_name コマンドに似ていますが、追加情報として RPM パッケージのインストール元である yum リポジトリーの名前を提供します (出力の From repo: の行を参照)。

yumdb の使用

以下のコマンドを使用して、パッケージに関する代替情報や有用な情報について Yum データベースにクエリーすることもできます。

yumdb info package_name

このコマンドは、パッケージのチェックサム (および SHA-256 などのチェックサムを算出するためのアルゴリズム)、パッケージのインストール開始に使用されたコマンドラインのコマンド (存在する場合)、パッケージがシステムにインストールされた理由 (user はユーザーがインストールしたことを、dep は依存関係として取り入れたことを意味します) などのパッケージに関する追加情報を提供します。

例9.9 yum パッケージに関する情報を yumdb でクエリー

yum パッケージに関する追加情報を表示するには、以下を入力します。

~]$ yumdb info yum
Loaded plugins: langpacks, product-id
yum-3.4.3-132.el7.noarch
   changed_by = 1000
   checksum_data = a9d0510e2ff0d04d04476c693c0313a11379053928efd29561f9a837b3d9eb02
   checksum_type = sha256
   command_line = upgrade
   from_repo = rhel-7-server-rpms
   from_repo_revision = 1449144806
   from_repo_timestamp = 1449144805
   installed_by = 4294967295
   origin_url = https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os/Packages/yum-3.4.3-132.el7.noarch.rpm
   reason = user
   releasever = 7Server
   var_uuid = 147a7d49-b60a-429f-8d8f-3edb6ce6f4a1

yumdb コマンドの詳細は、man ページの yumdb(8) を参照してください。

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

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

yum install package_name

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

yum install package_name package_name&hellip;

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

yum install package_name.arch

例9.10 multilib システムでのパッケージのインストール

i686 アーキテクチャー用の sqlite パッケージをインストールするには、以下を入力します。

~]# yum install sqlite.i686

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

yum install glob_expression&hellip;

例9.11 audacious の全プラグインのインストール

似た名前の複数のパッケージをインストールするには、glob 表現が便利です。audacious プラグインをすべてインストールするには、以下の形式でコマンドを使用します。

~]# yum install audacious-plugins-\*

パッケージ名と 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 コマンドでは、後続の引数で、ピリオドを使用してパッケージ名とアーキテクチャーを指定していると yum は解釈します。一方、install-nevra では、yum で、name-epoch:version-release.architecture の形で引数を指定していることが必要になります。同様に、削除するパッケージを検索する際は、yum remove-nyum remove-na、および yum remove-nevra が必要です。

注記

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

~]# yum provides "*bin/named"
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-
       : manager
32:bind-9.9.4-14.el7.x86_64 : The Berkeley Internet Name Domain (BIND) DNS
              : (Domain Name System) server
Repo    : rhel-7-server-rpms
Matched from:
Filename  : /usr/sbin/named

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

例9.12 インストールプロセス

以下の例は、yum を使用したインストールの概要を示しています。最新バージョンの httpd パッケージをダウンロードしてインストールするには、root で以下のコマンドを実行します。

~]# yum install httpd
Loaded plugins: langpacks, product-id, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-12.el7 will be updated
---> Package httpd.x86_64 0:2.4.6-13.el7 will be an update
--> Processing Dependency: 2.4.6-13.el7 for package: httpd-2.4.6-13.el7.x86_64
--> Running transaction check
---> Package httpd-tools.x86_64 0:2.4.6-12.el7 will be updated
---> Package httpd-tools.x86_64 0:2.4.6-13.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

上記のコマンドを実行した後、yum は必要なプラグインを読み込み、トランザクションチェックを実行します。このケースでは、httpd が既にインストールされています。インストール済みのパッケージが利用可能な最新バージョンよりも古いことから、これは更新されます。httpd が依存する httpd-tools にも同様のことが行われます。すると、トランザクションサマリーは以下のように表示されます。

================================================================================
 Package    Arch   Version         Repository        Size
================================================================================
Updating:
 httpd     x86_64  2.4.6-13.el7      rhel-x86_64-server-7  1.2 M
Updating for dependencies:
 httpd-tools  x86_64  2.4.6-13.el7      rhel-x86_64-server-7   77 k

Transaction Summary
================================================================================
Upgrade 1 Package (+1 Dependent package)

Total size: 1.2 M
Is this ok [y/d/N]:

このステップでは、yum がインストールを確認するプロンプトを表示します。y (yes) および N (no) オプションのほかに、d (ダウンロードのみ) を選択してパッケージをダウンロードしますが、直接インストールすることはできません。y を選択すると、以下のメッセージが出て、インストールが正常に完了するまで続行します。

Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
 Updating  : httpd-tools-2.4.6-13.el7.x86_64               1/4
 Updating  : httpd-2.4.6-13.el7.x86_64                  2/4
 Cleanup  : httpd-2.4.6-12.el7.x86_64                  3/4
 Cleanup  : httpd-tools-2.4.6-12.el7.x86_64               4/4
 Verifying : httpd-2.4.6-13.el7.x86_64                  1/4
 Verifying : httpd-tools-2.4.6-13.el7.x86_64               2/4
 Verifying : httpd-tools-2.4.6-12.el7.x86_64               3/4
 Verifying : httpd-2.4.6-12.el7.x86_64                  4/4

Updated:
 httpd.x86_64 0:2.4.6-13.el7

Dependency Updated:
 httpd-tools.x86_64 0:2.4.6-13.el7

Complete!

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

yum localinstall path

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

9.2.5. パッケージのダウンロード

例9.12「インストールプロセス」 にあるように、インストールプロセスのある時点で、インストールを確認する以下のメッセージが表示されます。

...
Total size: 1.2 M
Is this ok [y/d/N]:
...

d オプションを指定すると、yum は、パッケージをインストールせずにダウンロードを行います。ダウンロードしたパッケージは、キャッシュディレクトリーのサブディレクトリー (デフォルトでは /var/cache/yum/$basearch/$releasever/packages/) の 1 つに保存されます。ダウンロードしたパッケージは、キャッシュディレクトリーのサブディレクトリー (デフォルトでは /var/cache/yum/$basearch/$releasever/packages/) のいずれかに保存されます。ダウンロードはバックグラウンドモードで続行されるため、yum を並行して他の操作に使用できます。

9.2.6. パッケージの削除

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

yum remove package_name&hellip;

複数のパッケージをインストールする場合と同様、コマンドに複数のパッケージ名を追加すると、一度に複数のパッケージを削除できます。

例9.13 複数パッケージの削除

totem を削除するには、シェルプロンプトで以下を入力します。

~]# yum remove totem

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

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

Yum では、パッケージを削除して、その依存パッケージを残すことはできません。こうした動作は RPM でのみ実行可能であり、推奨されません。システムが機能しなくなる、またはアプリケーションに誤作動やクラッシュが生じる恐れがあるためです。

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

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

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

summary オプションを使用すると、インストール済みのグループ数、利用可能なグループ数、利用可能な環境グループ数、インストール済みの言語グループ数、利用可能な言語グループ数が表示されます。

yum groups summary

例9.14 yum groups summary の出力例

~]$ yum groups summary
Loaded plugins: langpacks, product-id, subscription-manager
Available Environment Groups: 12
Installed Groups: 10
Available Groups: 12

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

yum group list glob_expression&hellip;

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

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

yum group info glob_expression&hellip;

例9.15 LibreOffice パッケージグループの情報表示

 ~]$ yum group info LibreOffice
Loaded plugins: langpacks, product-id, subscription-manager

Group: LibreOffice
 Group-Id: libreoffice
 Description: LibreOffice Productivity Suite
 Mandatory Packages:
 =libreoffice-calc
  libreoffice-draw
 -libreoffice-emailmerge
  libreoffice-graphicfilter
 =libreoffice-impress
 =libreoffice-math
 =libreoffice-writer
 +libreoffice-xsltfilter
 Optional Packages:
  libreoffice-base
  libreoffice-pyuno

上記の例で分かるように、このパッケージグループに含まれているパッケージは、以下の記号でマークされている状態に分けられます。

  • -: パッケージはインストールされておらず、このパッケージグループではインストールされません。
  • +: パッケージはインストールされていませんが、次回の yum upgrade または yum group upgrade でインストールされます。
  • =: パッケージはインストールされており、パッケージグループの一部としてインストールされました。
  • 記号なし: パッケージはインストールされていますが、パッケージグループとしてはインストールされませんでした。このため、yum group remove ではこのパッケージを削除できません。

この区別は、group_command 設定パラメーターがデフォルト設定の objects に設定されている場合にのみ行われます。グループの一部として、または個別にパッケージをインストールしたかを yum で追跡したくない場合は、このパラメーターを異なる値に設定します。すると、"記号なし" パッケージと "=" パッケージが同じ意味になります。

yum group mark コマンドを使用する上記のパッケージの状態を変更することもできます。たとえば、yum group mark packages は、特定のインストール済みパッケージを指定されたグループのメンバーとしてマークします。グループ更新で新たなパッケージのインストールをしないようにするには、yum group mark blacklist を使用します。yum group mark の詳細な機能は man ページの yum(8) を参照してください。

注記

@^ 接頭辞を使用すると環境グループが特定でき、パッケージグループには @ のマークが付きます。yum group listinfoinstall、または remove を使用する場合は、@group_name を渡すてパッケージグループを指定し、@^group_name で環境グループを指定します。または group_name の両方を含める場合は group_name を渡します。

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

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

yum group list ids

例9.16 パッケージグループの名前と groupid の表示

パッケージグループ (例: KDE デスクトップ環境に関連するグループ) の名前または ID を検索するには、以下のコマンドを入力します。

~]$ yum group list ids kde\*
Available environment groups:
  KDE Plasma Workspaces (kde-desktop-environment)
Done

一部のグループは、設定されたリポジトリーの設定により非表示になっています。たとえば、サーバーで hidden コマンドオプションを使用すると、非表示グループも表示されます。

~]$ yum group list hidden ids kde\*
Loaded plugins: product-id, subscription-manager
Available Groups:
  KDE (kde-desktop)
Done

パッケージグループをインストールするには、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

例9.17 KDE Desktop グループをインストールする 4 つの方法

上記で説明したように、パッケージグループをインストールする方法は 4 つあります。KDE Desktop の場合、コマンドは以下のようになります。

~]# yum group install "KDE Desktop"
~]# yum group install kde-desktop
~]# yum install @"KDE Desktop"
~]# yum install @kde-desktop

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

例9.18 KDE Desktop グループを削除する 4 つの方法

インストールする場合と同様に、パッケージグループを削除する方法は 4 つあります。KDE Desktop の場合、コマンドは以下のようになります。

~]# yum group remove "KDE Desktop"
~]# yum group remove kde-desktop
~]# yum remove @"KDE Desktop"
~]# yum remove @kde-desktop

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

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

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

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

yum history list

すべてのトランザクションを表示するには、all のキーワードを追加します。

yum history list all

特定の範囲内のトランザクションのみを表示したい場合は、以下の形式でコマンドを使用します。

yum history list start_id..end_id

特定のパッケージに関するトランザクションのみを一覧表示することもできます。そのためには、パッケージ名か glob 表現を付けてコマンドを実行します。

yum history list glob_expression&hellip;

例9.19 最も古いトランザクション 5 件を表示する

yum history list の出力では、最新のトランザクションがリストの上部に表示されます。履歴データベースにある最も古い 5 件のトランザクションに関する情報を表示するには、以下を入力します。

~]# yum history list 1..5
Loaded plugins: langpacks, product-id, subscription-manager
ID   | Login user        | Date and time  | Action(s)   | Altered
-------------------------------------------------------------------------------
   5 | User <user>       | 2013-07-29 15:33 | Install    |  1
   4 | User <user>       | 2013-07-21 15:10 | Install    |  1
   3 | User <user>       | 2013-07-16 15:27 | I, U      |  73
   2 | System <unset>      | 2013-07-16 15:19 | Update     |  1
   1 | System <unset>      | 2013-07-16 14:38 | Install    | 1106
history list

yum history list コマンドのすべての形式で、以下のコラムで構成される各行を含む表形式出力を生成します。

  • ID: 特定のトランザクションを識別する整数値です。
  • Login user: トランザクションが開始したログインセッションのユーザー名。この情報は、通常 Full Name <username> の形式で表示されます。ユーザーが実行しなかったトランザクションに関しては (システムの自動更新など)、代わりに System <unset> が使用されます。
  • Date and time: トランザクションが発生した日時です。
  • Action(s): 表9.1「Action フィールドの値」 の説明通りに、トランザクション中に実行された動作の一覧です。
  • Altered: 表9.2「Altered フィールドの値」 の説明通りに、トランザクションにより影響を受けたパッケージ数、場合によっては追加情報も含まれます。

表9.1 Action フィールドの値

Action省略形詳細

Downgrade

D

1 つ以上のパッケージが旧バージョンにダウングレードされました。

Erase

E

1 つ以上のパッケージが削除されました。

Install

I

1 つ以上の新しいパッケージがインストールされました。

Obsoleting

O

1 つ以上のパッケージが廃止として記録されました。

Reinstall

-R

1 つ以上のパッケージが再インストールされました。

Update

U

1 つ以上のパッケージが新しいバージョンに更新されました。

表9.2 Altered フィールドの値

記号詳細

<

トランザクションが終了する前に、rpmdb データベースが yum 以外で変更されました。

>

トランザクションが終了した後に、rpmdb データベースが yum 以外で変更されました。

*

トランザクションは失敗して終了しました。

#

トランザクションは正常に終了しましたが、yum はゼロ以外の終了コードを返しました。

E

トランザクションは正常に終了しましたが、エラーまたは警告が表示されました。

%P

トランザクションは正常に終了しましたが、rpmdb データベースに問題がすでに存在していました。

s

トランザクションは正常に終了しましたが、--skip-broken コマンドラインオプションが指定され、特定のパッケージが省略されました。

インストール済みパッケージの rpmdb または yumdb データベースのコンテンツを、現在使用されている rpmdb または yumdb データベースと同期するには、以下を入力します。

yum history sync

現在使用している履歴データベースに関する全体的な統計数字を表示するには、以下のコマンドを使用します。

yum history stats

例9.20 yum history stats の出力例

~]# yum history stats
Loaded plugins: langpacks, product-id, subscription-manager
File    : //var/lib/yum/history/history-2012-08-15.sqlite
Size    : 2,766,848
Transactions: 41
Begin time : Wed Aug 15 16:18:25 2012
End time  : Wed Feb 27 14:52:30 2013
Counts   :
 NEVRAC : 2,204
 NEVRA : 2,204
 NA   : 1,759
 NEVR  : 2,204
 rpm DB : 2,204
 yum DB : 2,204
history stats

Yum を使用すると、過去に発生したすべてのトランザクションのサマリーを表示することもできます。root で以下の形式のコマンドを実行します。

yum history summary

特定の範囲内でのトランザクションのみを表示するには、以下を入力します。

yum history summary start_id..end_id

yum history list コマンドと同様に、パッケージの名前または glob 表現を指定することで、特定のパッケージに関するトランザクションのサマリーを表示できます。

yum history summary glob_expression&hellip;

例9.21 最新のトランザクション 5 件のサマリー

~]# yum history summary 1..5
Loaded plugins: langpacks, product-id, subscription-manager
Login user         | Time        | Action(s)    | Altered
-------------------------------------------------------------------------------
Jaromir ... <jhradilek>  | Last day      | Install     |    1
Jaromir ... <jhradilek>  | Last week      | Install     |    1
Jaromir ... <jhradilek>  | Last 2 weeks    | I, U       |    73
System <unset>       | Last 2 weeks    | I, U       |   1107
history summary

yum history summary コマンドはすべての形式で、yum history list の出力に似た、簡略化された表形式出力を生成します。

上記のように、yum history list および yum history summary とも、トランザクション向けに設定されています。特定のパッケージに関連するトランザクションのみを表示することができますが、パッケージバージョンのような重要な詳細は表示されません。パッケージに関連するトランザクションを一覧表示するには、root で以下のコマンドを実行します。

yum history package-list glob_expression&hellip;

例9.22 パッケージ履歴の追跡

たとえば、subscription-manager および関連パッケージの履歴を調べるには、シェルプロンプトで以下を入力します。

~]# yum history package-list subscription-manager\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
ID   | Action(s)   | Package
-------------------------------------------------------------------------------
   2 | Updated    | subscription-manager-1.13.22-1.el7.x86_64     EE
   2 | Update     |           1.15.9-15.el7.x86_64     EE
   2 | Obsoleted   | subscription-manager-firstboot-1.13.22-1.el7.x86_64 EE
   2 | Updated    | subscription-manager-gui-1.13.22-1.el7.x86_64   EE
   2 | Update     |             1.15.9-15.el7.x86_64   EE
   2 | Obsoleting   | subscription-manager-initial-setup-addon-1.15.9-15.el7.x86_64 EE
   1 | Install    | subscription-manager-1.13.22-1.el7.x86_64
   1 | Install    | subscription-manager-firstboot-1.13.22-1.el7.x86_64
   1 | Install    | subscription-manager-gui-1.13.22-1.el7.x86_64
history package-list

上記の例では、初期のシステムインストール時に subscription-managersubscription-manager-firstbootsubscription-manager-gui の 3 パッケージがインストールされています。3 つ目のトランザクションでは、これらの全パッケージはバージョン 1.10.11 から 1.10.17 に更新されています。

9.4.2. トランザクションの検証

単一のトランザクションのサマリーを表示するには、root で以下の形式で yum history summary コマンドを使用します。

yum history summary id

ここでは、id はトランザクションの ID を表します。

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

yum history info id&hellip;

id の引数はオプションです。これを省略する場合は、yum は自動的に最後のトランザクションを使用します。複数のトランザクションを指定する場合は、範囲を指定することもできます。

yum history info start_id..end_id

例9.23 yum history info の出力例

以下は、2 つのトランザクションに関する出力のサンプルです。それぞれ新しいパッケージを 1 つインストールしています。

~]# yum history info 4..5
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Transaction ID : 4..5
Begin time   : Mon Dec 7 16:51:07 2015
Begin rpmdb  : 1252:d2b62b7b5768e855723954852fd7e55f641fbad9
End time    :      17:18:49 2015 (27 minutes)
End rpmdb   : 1253:cf8449dc4c53fc0cbc0a4c48e496a6c50f3d43c5
User      : Maxim Svistunov <msvistun>
Return-Code  : Success
Command Line  : install tigervnc-server.x86_64
Command Line  : reinstall tigervnc-server
Transaction performed with:
  Installed   rpm-4.11.3-17.el7.x86_64         @rhel-7-server-rpms
  Installed   subscription-manager-1.15.9-15.el7.x86_64 @rhel-7-server-rpms
  Installed   yum-3.4.3-132.el7.noarch         @rhel-7-server-rpms
Packages Altered:
  Reinstall tigervnc-server-1.3.1-3.el7.x86_64 @rhel-7-server-rpms
history info

また、トランザクション時に使用された設定オプション、特定のパッケージをインストールしたリポジトリー、その理由などの追加情報も閲覧できます。特定のトランザクションに関して入手可能な追加情報を表示する場合は、root としてシェルプロンプトで以下を入力します。

yum history addon-info id

yum history info と同様に、id が指定されていない場合、yum は自動的に最新のトランザクションを使用します。別の方法として、最新のトランザクションを参照するには、last キーワードを使用することもできます。

yum history addon-info last

例9.24 yum history addon-info の出力例

履歴の 4 番目のトランザクションを指定すると、yum history addon-info は以下のような出力を返します。

~]# yum history addon-info 4
Loaded plugins: langpacks, product-id, subscription-manager
Transaction ID: 4
Available additional history information:
 config-main
 config-repos
 saved_tx

history addon-info

yum history addon-info コマンドの出力では、以下の 3 種類の情報が表示されます。

  • config-main: トランザクション時に使用された yum のグローバルオプション。グローバルオプションの変更方法は 「[main] オプションの設定」 を参照してください。
  • config-repos: 個々の yum リポジトリー用のオプションです。個々のリポジトリー用のオプションを変更する方法は 「[repository] オプションの設定」 を参照してください。
  • saved_tx: 別のマシンでトランザクションを繰り返すために yum load-transaction コマンドにより利用できるデータです (下記参照)。

選択した種類の追加情報を表示するには、root で以下のコマンドを実行してください。

yum history addon-info id information

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

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

yum history undo id

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

yum history redo id

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

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

複数の同一システムを管理する場合、yum を使用すると、1 つのシステムでトランザクションを実行して、そのトランザクションの詳細をファイルに格納し、テスト期間の終了後に残りのシステムで同じトランザクションを繰り返すことができます。トランザクションの詳細をファイルに保存するには、root でシェルプロンプトに以下を入力します。

yum -q history addon-info id saved_tx > file_name

このファイルを目的のシステムにコピーしたら、root で以下のコマンドを使用してトランザクションを繰り返すことができます。

yum load-transaction file_name

欠けているパッケージまたは rpmdb バージョンを無視するように load-transaction を設定できます。これらの設定オプションの詳細は、yum.conf(5) man ページを参照してください。

9.4.4. 新しいトランザクション履歴の開始

Yum は単一の SQLite データベースファイルにトランザクション履歴を保存します。新しいトランザクションの履歴を開始するには、root で以下のコマンドを実行します。

yum history new

これにより /var/lib/yum/history/ ディレクトリーに新しい空のデータベースファイルが作成されます。古いトランザクション履歴は保存されますが、新しいデータベースファイルがディレクトリーにある限りアクセスすることはできません。

9.5. Yum と Yum リポジトリーの設定

注記

専門知識を深めるために、Red Hat System Administration III (RH254) トレーニングコースと RHCSA Rapid Track (RH199) トレーニングコースを受講することをお勧めします。

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.conf ファイル、および/etc/yum.repos.d/ ディレクトリーの .repo ファイルの [repository] セクションを編集して、個々のレポジトリーにオプションを設定する方法
  • 動的バージョンとアーキテクチャーの値が適切に処理されるように /etc/yum.conf の yum 変数と /etc/yum.repos.d/ ディレクトリー内のファイルを使用する方法
  • コマンドラインで yum リポジトリーを追加、有効、無効にする方法
  • カスタムの yum リポジトリーを設定する方法

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

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

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

以下は、/etc/yum.conf 設定ファイルのサンプルです。

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3

[comments abridged]

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

以下は、[main] セクションで最もよく使用されるオプションです。

assumeyes=value

assumeyes オプションは、yum が重要なアクションに関する確認を行うかどうかを決定します。value を、以下のいずれかで置き換えます。

0: (デフォルト)。yum は、実行する重要な動作の確認を行います。

1: yum は、実行する重要な動作の確認を行いません。assumeyes=1 を設定すると、yum はコマンドラインオプション -y および --assumeyes と同じように動作します。

cachedir=directory

このオプションを使用して、yum がキャッシュおよびデータベースファイルを保存するディレクトリーを設定します。directory をディレクトリーへの絶対パスで置き換えます。デフォルトでは、yum のキャッシュディレクトリーは /var/cache/yum/$basearch/$releasever/ です。

yum 変数 $basearch および $releasever の詳細は、「yum 変数の使用」を参照してください。

debuglevel=value
このオプションは、yum が生成するデバッグ出力の詳細を指定します。ここでは、value1 から 10 までの整数になります。debuglevel 値を高く設定すると、yum はより詳細なデバッグ出力を表示します。debuglevel=2 はデフォルトです。一方、debuglevel=0 はデバッグの出力を無効にします。
exactarch=value

このオプションを使用すると、インストール済みのパッケージを更新する際に、yum が正確なアーキテクチャーを考慮するように設定できます。value を以下のいずれかで置き換えます。

0: パッケージの更新時には正しいアーキテクチャーを考慮に入れて実行しません。

1 (デフォルト値): パッケージの更新時に正しいアーキテクチャーを考慮します。このように設定すると、yum が、64 ビットアーキテクチャーのシステムにインストールされているパッケージの更新に、32 ビットアーキテクチャーのパッケージを使用しません。

exclude=package_name more_package_names
exclude オプションでは、インストールまたはシステム更新の際にキーワードでパッケージを除外できます。除外する複数のパッケージの一覧を表示するには、スペースで区切ったパッケージの一覧を引用符で囲みます。ワイルドカードを使用したシェル glob 表現 (*? など) を使用できます。
gpgcheck=value

gpgcheck オプションを指定して、GPG 著名チェックをパッケージで行う必要があるかどうかを指定します。value を以下のいずれかで置き換えます。

0: インストールされるローカルパッケージなど、全リポジトリー内のパッケージでの GPG 署名確認を無効にします。

1 (デフォルト): インストールされるローカルパッケージなど、全リポジトリーのすべてのパッケージで GPG 署名確認を有効にします。gpgcheck を有効にすると、すべてのパッケージ署名が確認されます。

このオプションが /etc/yum.conf ファイルの [main] セクションで設定されている場合は、全リポジトリーに対して GPG 確認ルールが設定されます。ただし、個々のリポジトリーに gpgcheck=value を設定することもできます。つまり、あるリポジトリーで GPG チェックを有効にしつつ、別のレポジトリーで無効にすることができます。対応の .repo ファイルの個別のレポジトリーに gpgcheck=value を設定すると、/etc/yum.conf にデフォルト値がある場合はそれを無効にします。

group_command=value

group_command オプションを指定して、yum group installyum group upgradeyum group remove がパッケージグループを処理する方法を指定します。value を、以下のいずれかで置き換えます。

simple: パッケージグループのすべてのメンバーをインストールします。以前にインストールされたパッケージのみを更新し、その間にグループに追加されたパッケージはインストールしません。

compat: simple に似ていますが、yum upgrade は前回の更新以降にグループに追加されたパッケージもインストールします。

オブジェクト: (デフォルト)。 このオプションでは、yum は以前にインストールされたグループを追跡し、グループの一部としてインストールされたパッケージと、個別にインストールされたパッケージを区別します。例9.15「LibreOffice パッケージグループの情報表示」を参照してください。

group_package_types=package_type more_package_types
yum group install コマンドが呼び出されたときにインストールされるパッケージのタイプ (オプションデフォルト必須) を指定することができます。default および mandatory のパッケージタイプがデフォルトで選択されます。
history_record=value

このオプションを使用すると、yum はトランザクション履歴を記録します。value を、以下のいずれかで置き換えます。

0: yum はトランザクションの履歴エントリーを記録しません

1 (デフォルト値): yum はトランザクションの履歴エントリーを記録します。この操作により、ある程度のディスク領域が使用され、トランザクションの時間が少し長くなりますが、過去の操作に関する多くの情報が提供されます。これは、yum history コマンドで表示できます。history_record=1 がデフォルトです。

yum history コマンドの詳細は、「トランザクション履歴の活用」 を参照してください。

注記

yum は履歴記録を使用して、yum 以外で行われた rpmdb データベースへの変更を検出します。変更が検出されると、yum は警告を表示し、rpmdb の変更によって起こり得る問題を自動的に検索します。history_record がオフになっていると、yum はこのような変更を検出できず、自動チェックは実行されません。

installonlypkgs=space separated list of packages

ここでは、yum でインストールを行い、更新を行わないパッケージの一覧をスペースで区切って提供できます。デフォルトでインストールのみに設定されているパッケージの一覧は、yum.conf(5) man ページを参照してください。

installonlypkgs ディレクティブを /etc/yum.conf に追加する場合は、yum.conf(5) の installonlypkgs セクションに一覧表示されているものを含め、インストールのみのパッケージをすべてリストするようにしてください。特に (デフォルトで) カーネルパッケージが常に installonlypkgs で一覧表示され、installonly_limit の値が常に 2 よりも大きく設定され、デフォルトが起動に失敗した場合にバックアップカーネルを常に利用可能にするようにしてください。

installonly_limit=value

このオプションは、installonlypkgs ディレクティブにリストされている多くのパッケージを同時にインストールできる数を設定します。installonlypkgs に一覧表示されている単一のパッケージに同時にインストールできるようにバージョンの最大数を示す整数にを置き換えます。

installonlypkgs ディレクティブのデフォルトには複数のカーネルパッケージが含まれています。そのため、installonly_limit の値を変更すると、インストール済みの単一のカーネルパッケージのバージョンの最大数にも影響することに注意してください。/etc/yum.conf に一覧表示されるデフォルト値は installonly_limit=3 で、使用できる最小値は installonly_limit=2 です。

installonly_limit=1 に設定すると yum によって実行中のカーネルが削除されるため、設定することはできません。installonly_limit=1 を使用すると、yum は失敗します。

installonly_limit=2 を使用すると、1 つのバックアップカーネルが利用可能になります。ただし、2 つのバックアップカーネルを利用できるようにするためにも、デフォルト設定 installonly_limit=3 を使用し続けることが推奨されます。

keepcache=value

keepcache オプションはインストールに成功した後に、yum がヘッダーのキャッシュを維持するかどうかを決めます。は、以下のいずれかになります。

0: (デフォルト)。インストールの成功後は、ヘッダーとパッケージのキャッシュを保持しません。

1: インストールの成功後も、キャッシュを保持します。

logfile=file_name
ログ出力の場所を指定するため、file_name を、yum がログ出力を書き込むファイルへの絶対パスで置き換えます。デフォルトでは、yum は /var/log/yum.log にログを記録します。
max_connenctions=number
ここでの value は、同時接続の最大数を表します。デフォルトは 5 です。
multilib_policy=value

multilib_policyは、複数のアーキテクチャーバージョンがパッケージのインストールに利用できる場合に、インストール動作を設定します。ここで、value は以下を表します。

best: このシステムに最適なアーキテクチャーをインストールします。たとえば、AMD64 システムに multilib_policy=best を設定すると、yum は全パッケージの 64 ビットバージョンをインストールします。

all: 常に全パッケージ用の可能なあらゆるアーキテクチャーをインストールします。たとえば、AMD64システムで multilib_policyall に設定すると、yum は i686 および AMD64 のパッケージが利用可能であれば両方のバージョンをインストールします。

obsoletes=value

obsoletes オプションでは、更新中に廃止プロセス論理を有効化します。あるパッケージのスペックファイルで、別のパッケージを廃止することを宣言すると、廃止宣言したパッケージのインストール時に、廃止宣言されたパッケージが、廃止宣言したパッケージに置き換えられます。たとえば、パッケージ名が変更された場合などに廃止が宣言されます。value を、以下のいずれかで置き換えます。

0: 更新の実行時に yum の廃止処理ロジックを無効にします。

1: (デフォルト)。更新の実行時に yum の廃止処理ロジックを有効にします。

plugins=value

これは、yum プラグインを有効または無効にするグローバルスイッチです。value は以下のいずれかになります。

0: yum のプラグインをグローバルで無効にします。

重要

一部のプラグインは重要な yum サービスを提供するため、すべてのプラグインを無効にすることは推奨されません。特に、product-id および subscription-manager プラグインは、証明書ベースの Content Delivery Network (CDN) のサポートを提供します。プラグインをグローバルで無効にするオプションは便利なオプションとして提供されていますが、通常は yum に潜在的な問題があると判断された場合にのみ使用することが推奨されます。

1 (デフォルト値): すべての yum プラグインを全体的に有効にします。plugins=1 では、そのプラグインの設定ファイルに enabled=0 を設定して、特定の yum プラグインを無効にすることができます。

yum の各種プラグインの詳細は 「yum のプラグイン」 を参照してください。プラグインの制御に関する詳細は 「yum プラグインを有効、設定、および無効にする方法」 を参照してください。

reposdir=directory
ここでの directory.repo ファイルがあるディレクトリーへの絶対パスです。すべての .repo ファイルには、リポジトリー情報 (/etc/yum.conf[repository] セクションと類似) が含まれています。yum は .repo ファイルおよび /etc/yum.conf ファイルの [repository] セクションからすべてのリポジトリー情報を収集し、トランザクションに使用するリポジトリーのマスター一覧を作成します。reposdir が設定されていない場合は、yum はデフォルトのディレクトリーである /etc/yum.repos.d/ を使用します。
retries=value
このオプションは、エラーを返す前に yum がファイルの取得を試行する回数を設定します。 は、0 以上の整数です。値を 0 に設定すると、yum はその試行を何度も続けます。デフォルト値は 10 です。

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

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

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

[repository] セクションでは、少なくとも以下の例のような形式が必要になります。

[repository]
name=repository_name
baseurl=repository_url

すべての [repository] セクションには、以下のディレクティブを含める必要があります。

name=repository_name
repository_name は、人間が判読可能な、リポジトリーを説明する文字列になります。
baseurl=repository_url

repository_url を、リポジトリーの repodata ディレクトリーが置かれているディレクトリーへの URL に置き換えます。

  • リポジトリーが HTTP にある場合は、http://path/to/repo を使用します。
  • リポジトリーが FTP にある場合は、ftp://path/to/repo を使用します。
  • リポジトリーがマシンのローカルにある場合は、file:///path/to/local/repo を使用します。
  • 特定のオンラインリポジトリーでベーシック HTTP 認証が必要な場合は、username:password@link として URL にプリペンドして、ユーザー名とパスワードを指定できます。たとえば、http://www.example.com/repo/ のリポジトリーで「user」のユーザー名およびパスワード「password」が必要な場合、baseurl リンクは http://user:password@www.example.com/repo/ として指定できます。

    通常この URL は以下のような HTTP リンクになります。

    baseurl=http://path/to/repo/releases/$releasever/server/$basearch/os/

    yum は、常に URL の $releasever$arch$basearch 変数を展開する点に注意して下さい。yum 変数の詳細は 「yum 変数の使用」 を参照してください。

以下のような便利な [repository] ディレクティブもあります。

enabled=value

このオプションを使用すれば、yum が特定のリポジトリーを使用するか無視するかを簡単に設定できます。value は、以下のいずれかになります。

0: 更新およびインストールの実行時には、パッケージソースとしてこのリポジトリーを含めません。これはリポジトリーを迅速に有効または無効にする簡単な方法です。更新またはインストールには無効にしているリポジトリーから、単一パッケージが欲しい場合に便利です。

1: パッケージソースとしてこのリポジトリーを含めます。

リポジトリーのオンとオフは、--enablerepo=repo_name または --disablerepo=repo_name オプションを yum に渡すか、PackageKit ユーティリティーの ソフトウェアの追加/削除 ウィンドウから実行できます。

async=value

リポジトリーパッケージの並行ダウンロードを制御します。は、以下のいずれかになります。

auto (デフォルト): 可能な場合、並行ダウンロードを使用します。つまり、失敗を回避するために yum はプラグインが作成したリポジトリーについては自動的にこれを無効にします。

on: リポジトリーの並行ダウンロードが有効になります。

off: リポジトリーの並行ダウンロードが無効になります。

他にも多くの [repository] オプションがあります。このうちのいくつかは、[main] オプションと同一形式、同一機能になります。オプションの一覧は、yum.conf(5) man ページの [repository] OPTIONS セクションを参照してください。

例9.25 /etc/yum.repos.d/redhat.repo ファイルのサンプル

以下は、/etc/yum.repos.d/redhat.repo ファイルのサンプルです。

#
# Red Hat Repositories
# Managed by (rhsm) subscription-manager
#

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/os
enabled = 1
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-source-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Source RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/source/SRPMS
enabled = 0
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-debug-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Debug RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/debug
enabled = 0
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

9.5.3. yum 変数の使用

yum コマンドおよびすべての yum 設定ファイル (つまり /etc/yum.conf および /etc/yum.repos.d/ ディレクトリー内のすべての .repo ファイル) 内で、以下の組み込み変数を使用および参照できます。

$releasever
この変数を使用すると、Red Hat Enterprise Linux のリリースバージョンを参照できます。yum は /etc/yum.conf 設定ファイルにある distroverpkg=value の行から $releasever の値を取得します。/etc/yum.conf にそのような行がない場合、yum は redhat-release ファイルを提供する redhat-releaseproduct パッケージからバージョン番号を取得することで、正しい値を推測します。
$arch
この変数を使用して、Python の os.uname() 関数を呼び出す時に返り値としてシステムの CPU アーキテクチャーを参照できます。$arch の有効な値は、i586i686x86_64 です。
$basearch
$basearch を使用すると、システムのベースアーキテクチャーを参照できます。たとえば、i686 および i586 の両マシンには i386 のベースアーキテクチャーがあり、AMD64 および Intel 64 の両マシンには x86_64 のベースアーキテクチャーがあります。
$YUM0-9
これら 10 個の変数は、それぞれ同じ名前を持つシェル環境変数の値に置換されます。これら変数のいずれかが (たとえば /etc/yum.conf で) 参照され、同じ名前を持つシェル環境変数が存在しない場合、設定ファイルの変数は置換されません。

カスタム変数の定義、既存の変数値の上書きを行うには、/etc/yum/vars/ ディレクトリー内に変数と同じ名前を持つファイルを作成して ($ 記号はなし) 、1 行目に希望する値を追加します。

たとえば多くの場合、リポジトリーの詳細にはオペレーティングシステムの名前が含まれます。$osname と呼ばれる新しい変数を定義するには、1 行目に Red Hat Enterprise Linux の名前を持つ新しいファイルを作成して、/etc/yum/vars/osname として保存します。

~]# echo "Red Hat Enterprise Linux 7" > /etc/yum/vars/osname

.repo ファイルでは、Red Hat Enterprise Linux 7 の代わりに以下を使用することができます。

name=$osname $releasever

9.5.4. 現在の設定の表示

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

yum-config-manager

別の設定セクションの内容を一覧表示するには、以下の形式でコマンドを実行します。

yum-config-manager section&hellip;

glob 表現を使用して、適合する全セクションの設定を表示することもできます。

yum-config-manager glob_expression&hellip;

例9.26 main セクションの設定を表示する

すべての設定オプションとそれらに対応する値を一覧表示するには、シェルプロンプトで以下を入力します。

~]$ yum-config-manager main \*
Loaded plugins: langpacks, product-id, subscription-manager
================================== main ===================================
[main]
alwaysprompt = True
assumeyes = False
bandwith = 0
bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%206&component=yum
cache = 0
[output truncated]

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

注記

専門知識を深めるには、Red Hat System Administration III (RH254) トレーニングコースの受講をお勧めします。

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

重要

システムが Red Hat Subscription Management で証明書ベースの Content Delivery Network (CDN) に登録されている場合、/etc/yum.repos.d/redhat.repo ファイル内のリポジトリー管理には Red Hat サブスクリプションマネージャー ツールが使用されます。

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 ファイルへのリンクになります。

例9.27 example.repo の追加

http://www.example.com/example.repo にあるリポジトリーを追加するには、シェルプロンプトで以下を入力します。

~]# yum-config-manager --add-repo http://www.example.com/example.repo
Loaded plugins: langpacks, product-id, subscription-manager
adding repo from: http://www.example.com/example.repo
grabbing file http://www.example.com/example.repo to /etc/yum.repos.d/example.repo
example.repo                       | 413 B   00:00
repo saved to /etc/yum.repos.d/example.repo

yum リポジトリーの有効化

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

yum-config-manager --enable repository&hellip;

ここでの repository は一意のリポジトリー ID になります (利用可能なリポジトリー ID を一覧表示するには yum repolist all を使用)。別の方法では、glob 表現を使用すると、一致するすべてのリポジトリーを有効にできます。

yum-config-manager --enable glob_expression&hellip;

例9.28 /etc/yum.conf のカスタムセクションで定義されるリポジトリーを有効にする

[example][example-debuginfo][example-source] セクション内で定義されたリポジトリーを有効にするには、以下を入力します。

~]# yum-config-manager --enable example\*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example
[output truncated]

例9.29 すべてのリポジトリーの有効化

/etc/yum.conf ファイルと /etc/yum.repos.d/ ディレクトリーで定義されたすべてのリポジトリーを有効にするには、以下のコマンドを入力します。

~]# yum-config-manager --enable \*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example
[output truncated]

成功すると、yum-config-manager --enable コマンドは現在のリポジトリー設定を表示します。

yum リポジトリーの無効化

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

yum-config-manager --disable repository&hellip;

ここでの repository は一意のリポジトリー ID になります (利用可能なリポジトリー ID を一覧表示するには yum repolist all を使用)。yum-config-manager --enable と同様に、glob 表現を使用して、一致するすべてのリポジトリーを同時に無効にできます。

yum-config-manager --disable glob_expression&hellip;

例9.30 すべてのリポジトリーの無効化

/etc/yum.conf ファイルと /etc/yum.repos.d/ ディレクトリーで定義されたすべてのリポジトリーを無効にするには、以下のコマンドを入力します。

~]# yum-config-manager --disable \*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example
[output truncated]

成功すると、yum-config-manager --disable コマンドは現在の設定を表示します。

9.5.6. yum リポジトリーの作成

yum リポジトリーを設定するには、以下を行います。

  1. createrepo パッケージをインストールします。

    # yum install createrepo
  2. 新しいリポジトリーのパッケージをすべて 1 つのディレクトリー (/tmp/local_repo/ など) にコピーします。

    cp /your/packages/*.rpm /tmp/local_repo/
  3. リポジトリーの実行を作成するには、以下を行います。

    createrepo /tmp/local_repo/

    これにより、yum リポジトリーから必要なメタデータが、新たに作成したサブディレクトリー repodata に作成されます。

    このリポジトリーを yum で利用できるようになりました。このリポジトリーは HTTP または FTP プロトコルで共有でき、ローカルマシンから直接参照できます。yum リポジトリーを設定する方法は 「[repository] オプションの設定」 セクションを参照してください。

    注記

    リポジトリーの URL を構築するには、/mnt/local_repo/repodata ではなく /mnt/local_repo を参照してください。実際の yum パッケージは /mnt/local_repo にあります。

9.5.6.1. 作成した yum リポジトリーへのパッケージの追加

作成した yum リポジトリーにパッケージを追加するには、以下を行います。

  1. リポジトリーディレクトリー (/tmp/local_repo/ など) に新しいパッケージをコピーします。

    cp /your/packages/*.rpm /tmp/local_repo/
  2. メタデータで新たに追加されたパッケージを反映するには、以下を実行します。

    createrepo --update /tmp/local_repo/
  3. 任意: 新たに更新したリポジトリーで yum コマンドを使用している場合は、以下のコマンドを実行します。

    yum clean expire-cache

9.5.7. Optional および Supplementary リポジトリーの追加

Optional および Supplementary のサブスクリプションチャンネルでは、オープンソースのライセンス付きソフトウェア (Optional チャンネル) と商用ライセンス付きソフトウェア (Supplementary チャンネル) をカバーする Red Hat Enterprise Linux 用の追加ソフトウェアパッケージが提供されます。

Optional および Supplementary チャンネルをサブスクライブする前に、「対象範囲の詳細」を参照してください。これらのチャンネルからパッケージをインストールする場合は、Red Hat カスタマーポータルの記事「証明書ベースの管理を使用して、Optional および Supplementary チャンネル、-devel パッケージにアクセスする方法」で説明されている手順を行ってください。

9.6. yum のプラグイン

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

~]# yum info yum
Loaded plugins: langpacks, product-id, subscription-manager
[output truncated]

Loaded plugins に続くプラグイン名は --disableplugin=plugin_name オプションに指定できる名前です。

9.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/yum/pluginconf.d/ ディレクトリーにそれぞれの設定ファイルがあります。このファイルに、プラグイン固有のオプションを設定できます。たとえば、以下のように aliases プラグインの aliases.conf 設定ファイルがあるとします。

[main]
enabled=1

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

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

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

1 つの yum コマンドで、1 つ以上の yum プラグインを無効にする場合は、そのコマンドに --disableplugin=plugin_name オプションを追加します。たとえば、システムの更新中に aliases プラグインを無効にするには、以下を入力します。

~]# yum update --disableplugin=aliases

--disableplugin= オプションに指定したプラグイン名は、yum コマンドの出力の Loaded プラグイン 行の後に一覧表示される名前と同じです。名前をコンマで区切ることにより、複数のプラグインを無効にすることができます。さらに、glob 表現を使用して、複数のプラグイン名に一致したり、長いプラグイン名を短くすることができます。

~]# yum update --disableplugin=aliases,lang*

9.6.2. 追加の Yum プラグインのインストール

yum プラグインは通常、 yum-plugin-plugin_name 規則に従いますが、常に kabi プラグインを提供するパッケージは kabi-yum-plugins という名前です。yum プラグインは、他のパッケージをインストールするのと同じ方法でインストールできます。たとえば、yum-aliases プラグインをインストールするには、シェルプロンプトで次のコマンドを実行します。

~]# yum install yum-plugin-aliases

9.6.3. yum プラグインの使用方法

以下では、便利な yum プラグインの説明と使用方法を紹介しています。プラグインは名前で表示されており、括弧内はパッケージ名になります。

search-disabled-repos (subscription-manager)

search-disabled-repos プラグインを使用すると、依存関係を解決するために無効なリポジトリーを一時的または永久的に有効にできます。このプラグインが有効な場合は、依存関係の解決に失敗して Yum がパッケージのインストールに失敗したときに、無効なリポジトリーを一時的に有効し、再試行することが提示されます。インストールが成功した場合、Yum は使用されているリポジトリーを永久的に有効にすることも提示します。プラグインは subscription-manager により管理されているリポジトリーとのみ連携し、カスタムリポジトリーとは連携しません。

重要

yum--assumeyes または -y オプションで実行されるか、/etc/yum.confassumeyes ディレクティブが有効になっている場合、プラグインは、確認を求めるプロンプトなしに、一時的に、そして永続的に無効なリポジトリーを有効にします。この結果、有効にしたくないリポジトリーが有効になるといった問題が発生することがあります。

search-disabled-repos プラグインを設定するには、/etc/yum/pluginconf.d/search-disabled-repos.conf にある設定ファイルを編集します。[main]セクションで使用できるディレクティブのリストについては、以下の表を参照してください。

表9.3 サポートされている search-disabled-repos.conf ディレクティブ

ディレクティブ詳細

enabled=value

プラグインを有効または無効にできます。value1 (有効) または 0 (無効) にする必要があります。プラグインはデフォルトで有効です。

notify_only=value

プラグインの動作を通知のみに制限できます。value1 (Yum の動作の変更なしで通知のみ) または 0 (Yum の動作の変更) のいずれかにする必要があります。デフォルトでは、プラグインはユーザーへの通知のみを行います。

ignored_repos=repositories

プラグインで有効でないリポジトリーを指定できます。

kabi (kabi-yum-plugins)

kabi プラグインは、ドライバー更新パッケージが公式の Red Hat kernel Application Binary Interface (kABI) と適合するかどうかを確認します。このプラグインが有効な状態で、ユーザーがホワイトリストにないカーネルシンボルを使用するパッケージのインストールを試行する場合は、警告メッセージがシステムログに書き込まれます。さらには、プラグインを enforcing モードで実行するように設定すると、そうしたパッケージがインストールされないようにできます。

kabi プラグインを設定するには、/etc/yum/pluginconf.d/kabi.conf にある設定ファイルを編集します。[main] セクションに使用できるディレクティブの一覧を以下の表に示します。

表9.4 サポートされている kabi.conf ディレクティブ

ディレクティブ詳細

enabled=value

プラグインを有効または無効にできます。value1 (有効) または 0 (無効) にする必要があります。インストール時には、プラグインはデフォルトで有効です。

whitelists=directory

サポートされているカーネルシンボルを持つファイルがある directory を指定できます。デフォルトでは、kabi プラグインは kernel-abi-whitelists パッケージ (/usr/lib/modules/kabi-rhel70/ ディレクトリー) が提供するファイルを使用します。

enforce=value

enforcing モードを有効または無効にできます。value1 (有効) または 0 (無効) にする必要があります。デフォルトでは、このオプションはコメントアウトされ kabi プラグインは警告メッセージのみを表示します。

product-id (subscription-manager)
product-id プラグインは、Content Delivery Network (コンテンツ配信ネットワーク) からインストールされた製品の製品識別証明書を管理します。product-id プラグインはデフォルトでインストールされています。
langpacks (yum-langpacks)
langpacks プラグインは、インストールされているすべてのパッケージ用に選択された言語のロケールパッケージを検索するために使用します。langpacks プラグインはデフォルトでインストールされます。
エイリアスyum-plugin-aliases
aliases プラグインは、yum のエイリアスの設定と使用を可能にする alias コマンドラインオプションを追加します。
yum-changelog (yum-plugin-changelog)
yum-changelog プラグインは、更新前後にパッケージ変更ログの表示を有効にする --changelog コマンドラインオプションを追加します。
yum-tmprepo (yum-plugin-tmprepo)
yum-tmprepo プラグインは、リポジトリーファイルの URL を取り扱う --tmprepo コマンドラインオプションを追加し、1 つのトランザクションに対してのみダウンロードおよび有効化します。このプラグインはリポジトリーの安全な一時的使用を確保します。デフォルトでは、gpg 確認を無効にしません。
yum-verifyyum-plugin-verify
yum-verify プラグインは、システム上の検証データを表示するための verifyverify-rpmverify-all コマンドラインオプションを追加します。
yum-versionlockyum-plugin-versionlock
yum-versionlock プラグインは選択されたパッケージの他のバージョンを除外し、パッケージが最新バージョンに更新されることを防ぎます。versionlock コマンドラインオプションを使用すると、ロックされたパッケージを表示して、編集できます。

9.7. yum-cron を使用したパッケージデータベースの自動更新および更新のダウンロード

yum-cron サービスがパッケージの更新を自動的に確認してダウンロードします。yum-cron が提供する cron ジョブは、yum-cron パッケージのインストール後すぐにアクティブになります。また、yum-cron サービスは、ダウンロードした更新を自動的にインストールできます。

yum-cron サービスのデフォルト設定では、以下を行います。

  • 1 時間ごとに yum cache のメタデータを更新。
  • yum cache で保留になっているパッケージの更新を 1 日 1 回ダウンロード。リポジトリーで新しいパッケージが利用可能になると、メールが送信されます。詳細は 「任意のメール通知の設定」 の章を参照してください。

yum-cron サービスには設定ファイルが 2 つあります。

/etc/yum/yum-cron.conf
日次タスクの場合。
/etc/yum/yum-cron-hourly.conf
1 時間ごとのタスクの場合。

9.7.1. 更新の自動インストールの有効化

ダウンロードした更新の自動インストールを有効にするには、日次設定ファイル (日次インストールの場合) または 1 時間単位の設定ファイル (1 時間ごとのインストールの場合) で apply_updates を以下のように設定します。

apply_updates = yes

9.7.2. 任意のメール通知の設定

デフォルトでは、yum-cron サービスは cron を使用して、実行したコマンドの出力を含むメール送信を行います。このメールは cron 設定に従って送信されますが、通常はローカルのスーパーユーザー、および /var/spool/mail/root ファイルに設定されているユーザーに送信されます。

すべての cron ジョブに影響する設定とは異なり、特定のメール設定を使用できます。ただし、このメール設定では TLS および全体のメールの組み込みロジックはサポートされません。

yum-cron の組み込みメール通知を有効にするには、以下を実行します。

  1. 選択した yum-cron 設定ファイルを開きます。

    /etc/yum/yum-cron.conf
    日次タスクの場合。
    /etc/yum/yum-cron-hourly.conf
    1 時間ごとのタスクの場合。
  2. [emitters] セクションで、以下のオプションを設定します。

    emit_via = email
  3. 必要に応じて、email_fromemail_toemail_host オプションを指定します

9.7.3. 個別のリポジトリーの有効化または無効化

yum-cron は、リポジトリーの特定の設定をサポートしません。yum ではなく、yum-cron で個別のリポジトリーを有効または無効にするには、以下の手順を行ってください。

  1. システムの任意の場所に空のリポジトリー設定ディレクトリーを作成します。
  2. /etc/yum.repos.d/ ディレクトリーから、新たに作成したこのディレクトリーに設定ファイルをすべてコピーします。
  3. /etc/yum.repos.d/ 内の各 .repo 設定ファイルで、以下のように enabled オプションを設定します。

    enabled = 1
    リポジトリーを有効にするには、以下を行います。
    enabled = 0
    リポジトリーを無効にするには、以下を行います。
  4. 選択した yum-cron 設定ファイルの最後に、新たに作成したリポジトリーのディレクトリーを指定する以下のオプションを追加します。

    reposdir=/path/to/new/reposdir

9.7.4. Yum-cron 設定のテスト

次に予定されている yum-cron タスクを待たずに yum-cron 設定をテストするには、以下を行います。

  1. 選択した yum-cron 設定ファイルを開きます。

    /etc/yum/yum-cron.conf
    日次タスクの場合。
    /etc/yum/yum-cron-hourly.conf
    1 時間ごとのタスクの場合。
  2. 以下のように、選択した設定ファイルに random_sleep オプションを設定します。

    random_sleep = 0
  3. 設定を保存します。

    # yum-cron /etc/yum/yum-cron.conf
    # yum-cron /etc/yum/yum-cron-hourly.conf

9.7.5. yum-cron メッセージの無効

yum-cron メッセージを完全に無効にすることはできませんが、優先度が重大なメッセージだけに制限することはできます。メッセージを制限するには、以下を行います。

  1. 選択した yum-cron 設定ファイルを開きます。

    /etc/yum/yum-cron.conf
    日次タスクの場合。
    /etc/yum/yum-cron-hourly.conf
    1 時間ごとのタスクの場合。
  2. 設定ファイルの [base] セクションに以下のオプションを設定します。

    debuglevel = -4

9.7.6. パッケージの自動削除

yum-cron サービスは、yum clean all コマンドと同様に、パッケージを削除する設定オプションはサポートしていません。パッケージを自動的に削除するには、実行可能なシェルスクリプトとして cron ジョブを作成できます。

  1. /etc/cron.daily/ ディレクトリーにシェルスクリプトを作成し、以下を追加します。

    #!/bin/sh
    yum clean all
  2. スクリプトを実行可能にします。

    # chmod +x /etc/cron.daily/script-name.sh

9.8. 関連資料

Red Hat Enterprise Linux でソフトウェアパッケージを管理する方法についての詳細情報は、下記のリソースを参照してください。

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

  • yum(8): yum コマンドラインユーティリティーの man ページには、サポートされるオプションおよびコマンドの完全なリストを提供します。
  • yumdb(8): yumdb コマンドラインユーティリティーの man ページでは、このツールを使用してクエリーを行い、必要であれば yum データベースを変更する方法が説明されています。
  • yum.conf(5): yum.conf の man ページでは、利用できる yum 設定オプションが説明されています。
  • yum-utils(1): yum-utils の man ページでは、yum 設定の管理、リポジトリーの操作、yum データベースの作業を行う追加ユーティリティーの一覧表示と簡単な説明が提供されます。

オンラインリソース

  • Yum Guides: プロジェクトホームページ上の Yum Guides では、追加のドキュメンテーションのリンクがあります。
  • Red Hat Customer Portal Labs: Red Hat Customer Portal Labs で「Yum Repository Configuration Helper」をご利用になれます。

関連項目

  • 6章権限の取得 では、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。

パート IV. インフラストラクチャーサービス

ここでは、サービスおよびデーモンの設定方法と、Red Hat Enterprise Linux マシンへのリモートアクセスを可能にする方法を提供します。

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

10.1. systemd の概要

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

systemd は、systemd unit の概念を導入します。これらの unit は 表10.2「systemd のユニットファイルの場所」 にあるディレクトリーの 1 つに置かれる unit 設定ファイルで表示され、システムサービスやリスニングソケット、init システムに関連するその他のオブジェクトに関する情報を要約します。利用可能な systemd unit タイプの完全な一覧は表10.1「利用可能な systemd のユニットタイプ」を参照してください。

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

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

サービスユニット

.service

システムサービス

ターゲットユニット

.target

systemd ユニットのグループ

自動マウントユニット

.automount

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

デバイスユニット

.device

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

マウントユニット

.mount

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

パスユニット

.path

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

スコープユニット

.scope

外部作成のプロセス

スライスユニット

.slice

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

スナップショットユニット

.snapshot

systemd マネージャーの保存状態。

ソケットユニット

.socket

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

スワップユニット

.swap

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

タイマーユニット

.timer

systemd タイマー

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

ディレクトリー詳細

/usr/lib/systemd/system/

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

/run/systemd/system/

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

/etc/systemd/system/

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

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

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

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

DefaultTimeoutStartSec=required value

例10.21「タイムアウト制限の変更」も参照してください。

10.1.1. 主な特長

Red Hat Enterprise Linux 7 では、systemd システムおよびサービスマネージャーは以下の主要な機能を提供します。

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

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

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

10.1.2. 互換性の変更点

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

  • systemd のランレベルのサポートは限定的なものです。ランレベルに直接マッピング可能なターゲットユニットを数多く提供し、互換性のために以前の runlevel コマンドで配布されます。ただし、systemd ターゲットのすべてがランレベルに直接マッピングできるわけではないため、このコマンドが不明なランレベルを示す N を返す場合もあります。可能な場合は、runlevel コマンドの使用を避けることが推奨されます。

    systemd ターゲットの詳細と、ランレベルとの比較は「systemd ターゲットでの作業」を参照してください。

  • systemctl ユーティリティーは、カスタマイズされたコマンドをサポートしません。SysV init スクリプトでは、startstopstatus といった標準のコマンドのほかに、任意のコマンドを実装して多くの機能を提供できます。たとえば、Red Hat Enterprise Linux 6 の iptables の init スクリプトは、panic コマンドで実行できます。これにより、パニックモードが即座に有効になり、システムを再設定して受信パケットおよび送信パケットをすべて切断します。これは systemd ではサポートされておらず、systemctl は文書化されたコマンドのみ受け付けます。

    systemctl ユーティリティー、および以前の service ユーティリティーとの比較は、「システムサービスの管理」 を参照してください。

  • 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 から生成されるサービス用にハードコーディングされ、変更することができません。ただし、個別の設定ファイルを使用して、サービスごとにタイムアウト値を長くすることができます。例10.21「タイムアウト制限の変更」を参照してください。

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

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

注記

専門知識のさらなる拡充を図るには、Red Hat System Administration II (RH134) トレーニングコースもあります。

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

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

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

サービスsystemctl詳細

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

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

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

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

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

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

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

systemctl status name.service

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

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

フィールド詳細

Loaded

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

Active

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

Main PID

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

状態

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

Process

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

CGroup

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

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

systemctl is-active name.service

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

systemctl is-enabled name.service

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

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

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

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

10.2.3. サービスの起動

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

systemctl start name.service

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

例10.5 サービスの起動

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

~]# systemctl start httpd.service

10.2.4. サービスの停止

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

systemctl stop name.service

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

例10.6 サービスの停止

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

~]# systemctl stop bluetooth.service

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

例10.7 サービスの再開

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

~]# systemctl reload httpd.service

10.2.6. サービスの有効化

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

systemctl enable name.service

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

systemctl reenable name.service

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

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

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

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

例10.9 サービスの無効化

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

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

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

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

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

10.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 ランレベルに直接マッピングするエイリアスも提供されています。表10.6「SysV ランレベルと systemd ターゲットの比較」に、SysV ランレベルの完全なリストと、対応する systemd ターゲットを記載します。

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

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

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

runlevel

systemctl list-units --type target

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

telinit runlevel

systemctl isolate name.target

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

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

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

systemctl get-default

このコマンドは、/etc/systemd/system/default.target にあるシンボリックリンクを解決して、結果を表示します。デフォルトのターゲット変更する方法は 「デフォルトターゲットの変更」 を参照してください。現在、読み込み済みのターゲットユニットを一覧表示する方法は 「現在のターゲットの表示」 を参照してください。

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

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

~]$ systemctl get-default
graphical.target

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

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

systemctl list-units --type target

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

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

systemctl list-units --type target --all

デフォルトターゲット 「デフォルトターゲットの表示」 の表示方法は、を参照してください。現在のターゲットを変更する方法は、「現在のターゲットの変更」 を参照してください。

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

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

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

systemctl set-default name.target

name を、デフォルトで使用するターゲットユニットの名前 (multi-user など) に置き換えます。このコマンドにより、/etc/systemd/system/default.target ファイルが、/usr/lib/systemd/system/name.target へのシンボリックリンクに置き換わります。name は、使用するターゲットユニットの名前になります。現在のターゲットを変更する方法は、「現在のターゲットの変更」 を参照してください。現在、読み込み済みのターゲットユニットを一覧表示する方法は 「現在のターゲットの表示」 を参照してください。

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

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

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

systemctl isolate name.target

name を、使用するターゲットユニットの名前 (multi-user など) に置き換えます。このコマンドは、name という名前のターゲットユニットと、その従属ユニットをすべて起動し、その他のユニットを直ちに停止します。デフォルトのターゲット変更する方法は 「デフォルトターゲットの変更」 を参照してください。現在、読み込み済みのターゲットユニットを一覧表示する方法は 「現在のターゲットの表示」 を参照してください。

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

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

~]# systemctl isolate multi-user.target

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

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

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

systemctl rescue

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

systemctl --no-wall rescue

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

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

10.3.6. 緊急モードへの変更

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

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

systemctl emergency

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

systemctl --no-wall emergency

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

例10.15 緊急モードへの変更

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

~]# systemctl --no-wall emergency

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

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

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

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

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

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

10.4.2. システムの再起動

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

systemctl reboot

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

systemctl --no-wall reboot

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

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

systemctl suspend

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

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

10.4.4. システムの休止状態

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

systemctl hibernate

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

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

systemctl hybrid-sleep

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

10.5. リモートマシン上での systemd の制御

systemd システムおよびサービスマネージャーをローカルで制御することに加え、systemctl ユーティリティーでは、SSH プロトコルを使用してリモートマシン上で実行している systemd と対話できます。sshd サービスがリモートマシン上で実行中であれば、systemctl コマンドに --host または -H オプションを指定して実行することで、このマシンに接続できます。

systemctl --host user_name@host_name command

user_name を、リモートユーザーの名前、host_name をマシンのホスト名に置き換え、command は上記の systemctl コマンドのいずれかに置き換えます。指定したユーザーが SSH プロトコルを使用してリモートアクセスできるようにリモートマシンを設定する必要があることに注意してください。SSH サーバーの設定に関する詳細情報は 12章OpenSSH を参照してください。

例10.16 リモート管理

server-01.example.com という名前のリモートマシンに root ユーザーとしてログインし、httpd.service ユニットの現在の状態を判断するには、シェルプロンプトに以下を入力します。

~]$ systemctl -H root@server-01.example.com status httpd.service
>>>>>>> systemd unit files -- update
root@server-01.example.com's password:
httpd.service - The Apache HTTP Server
  Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
  Active: active (running) since Fri 2013-11-01 13:58:56 CET; 2h 48min ago
 Main PID: 649
  Status: "Total requests: 0; Current requests/sec: 0; Current traffic:  0 B/sec"
  CGroup: /system.slice/httpd.service

10.6. systemd のユニットファイルの作成および変更

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

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

unit_name.type_extension

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

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

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

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

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

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

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

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

オプション[a] セクション、systemd.unit(5) man ページ]詳細

詳細

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

Documentation

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

After[b]

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

Requires

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

Wants

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

Conflicts

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

[a] [Unit] で設定可能なオプションの完全リスト
[b] ほとんどの場合、ユニットファイルオプションの After および Before で依存関係の並び順を設定するだけで十分です。Wants (推奨) または Requires で要件の依存関係も設定する場合は、依存関係の並び順を指定する必要があります。これは、並び順と要件の依存関係が相互に依存していないためです。

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

オプション[a] セクション、systemd.service(5)のマニュアルページを参照してください。]詳細

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] で設定可能なオプションの完全リスト

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

オプション[a] セクション、systemd.unit(5) man ページ]詳細

Alias

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

RequiredBy

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

WantedBy

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

Also

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

DefaultInstance

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

[a] [Install] で設定可能なオプションの完全リスト

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

例10.17 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] セクションはサービスに依存するユニットを一覧表示します。

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

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

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

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

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

  3. 上の手順で作成した name.service ファイルを開き、サービス設定オプションを追加します。作成するサービスのタイプに応じて、さまざまなオプションを使用できます。「ユニットファイル構造の概要」を参照してください。以下は、ネットワーク関連サービスのユニットの設定例になります。

    [Unit]
    Description=service_description
    After=network.target
    
    [Service]
    ExecStart=path_to_executable
    Type=forking
    PIDFile=path_to_pidfile
    
    [Install]
    WantedBy=default.target

    詳細は以下のようになります。

    • service_description は、ジャーナルログファイルおよび systemctl status コマンドの出力に表示される役立つ説明です。
    • After 設定により、このサービスは、ネットワークが実行してから起動します。関連するサービスまたはターゲットは、スペースで区切って追加します。
    • path_to_executable は、サービス実行ファイルへのパスを表します。
    • Type=forking は、fork システム呼び出しを行うデーモンに使用します。サービスのメインプロセスは、path_to_pidfile で指定した PID で作成されます。その他の起動タイプは、表10.10「[Service] セクションの重要なオプション」を参照してください。
    • WantedBy では、サービスを起動するターゲットを指定します。ターゲットは、従来のランレベル概念の代替と見なすことができます。詳細は「systemd ターゲットでの作業」を参照してください。
  4. root で以下のコマンドを実行すると、新しい name.serviceファイルが存在することが、systemd に通知されます。

    systemctl daemon-reload
    systemctl start name.service
    警告

    新しいユニットファイルを作成したり、既存のユニットファイルを修正したら常に systemctl daemon-reload コマンドを実行します。このコマンドを実行しないと、systemd のステータスと、ディスクの実際のサービスユニットファイルが一致しなくなるため、systemctl start コマンドや systemctl enable コマンドが失敗します。

    name.service ユニットは、「システムサービスの管理」 に説明通りにコマンドでその他のシステムサービスとして管理できます。

例10.18 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 でシステム起動時にエディターを自動的に起動したりできます。

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

10.6.3. SysV Init スクリプトのユニットファイルへの変換

SysV init スクリプトをユニットファイルに変換する前に、すでに別の場所で変換が行われていないことを確認します。Red Hat Enterprise Linux 7 にインストールされるすべてのコアサービスにデフォルトのユニットファイルが同梱されていますが、数多くのサードパーティーソフトウェアパッケージにも同様のことが言えます。

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 ユニットは例10.17「postfix.service ユニットファイル」を参照してください。

サービス説明の検索

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

サービス依存関係の検索

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

表10.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 ターゲットにマップするには、表10.6「SysV ランレベルと systemd ターゲットの比較」 を使用します。次に、そのターゲットを、ユニットファイルの [Install] セクションの WantedBy オプションに記述します。たとえば、postfix はこれまではランレベル 2、3、4、および 5 で起動しました。これは、Red Hat Enterprise Linux 7 では multi-user.target と graphical.target に変換されます。ただし、graphical.target は multiuser.target に依存するため、例10.17「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 は、事前に定義されたアクションのみをサポートしますが、オプションの ExecStartExecStartPreExecStartPostExecStopExecReload でカスタムの実行ファイルを有効にできます。Red Hat Enterprise Linux 7 の postfix の場合、/usr/sbin/postfix はサポートスクリプトと共に、サービスの起動時に実行されます。postfix ユニットファイルの詳細は、例10.17「postfix.service ユニットファイル」を参照してください。

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

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

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

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

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

systemctl daemon-reload

daemon-reload オプションは、すべてのユニットファイルを再読み込みし、ユニットファイルへの変更をすぐに適用するのに必要な依存関係ツリー全体を再作成します。別の方法として、次のコマンドで同じ結果を得ることができます。

init q

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

systemctl restart name.service
重要

SysV init スクリプトが処理しているサービスのプロパティ (依存関係やタイムアウトなど) を変更するときは、init スクリプト自体は変更しないでください。代わりに、「デフォルトのユニット設定の拡張」「デフォルトのユニット設定の上書き」 にあるように、サービスの systemd ドロップイン設定ファイルを作成します。その後、通常の systemd サービスと同じ方法でサービスを管理します。

たとえば、network サービスの設定を拡張するときは、init スクリプトファイル /etc/rc.d/init.d/network を変更しないでください。代わりに、新しいディレクトリー /etc/systemd/system/network.service.d/ と、systemd ドロップインファイル /etc/systemd/system/network.service.d/my_config.conf を作成します。そして、ドロップインファイルの値を変更します。systemd は、network サービスを network.service として認識することに注意してください。作成したディレクトリーが network.service.d と命名されるのはそのためです。

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

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

例10.20 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/ のユニットファイルに優先します。そのため、設定ファイルに、一度だけ指定できるオプション (DescriptionExecStart など) が含まれる場合は、このオプションのデフォルト値が上書きされます。「上書きされたユニットの監視」 で説明されているように、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

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

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

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

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

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.

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

表10.13 systemd-delta の相違タイプ

Type詳細

[MASKED]

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

[EQUIVALENT]

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

[REDIRECTED]

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

[OVERRIDEN]

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

[EXTENDED]

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

[UNCHANGED]

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

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

systemd-delta --type=overridden

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

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

表10.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 として解決されます。

10.7. サービスの管理中に考慮すべき事項

通常の操作時に、systemd は、ユニットの抽象化と、システムでアクティブな基本プロセスの関連付けを維持します。

From: man systemd

Processes systemd spawns are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy. (see cgroups.txt[1] for more information about control groups, or short "cgroups"). systemd uses this to effectively keep track of processes. Control group information is maintained in the kernel, and is accessible via the file system hierarchy (beneath /sys/fs/cgroup/systemd/), or in tools such as ps(1) (ps xawf -eo pid,user,cgroup,args is particularly useful to list all processes and the systemd units they belong to).

cgroup 階層は、systemd のプロセスおよびサービスの健全性の表示に重要です。プロセスがそれ自体を分岐すると、プロセスは作成プロセスの cgroup を継承します。この場合は、特定のユニットに関連付けられているすべてのプロセスは、次のような適切な cgroup.procs ファイルの内容を読み取ることで検証できます。

~]# cat /sys/fs/cgroup/systemd/system.slice/httpd.service/cgroup.procs
11854
11855
11856
11857
11858
11859

この出力は、systemctl status unit 操作時に返される CGroup 情報と一致します。

~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
  Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
  Active: active (running) since Wed 2019-05-29 12:08:16 EDT; 45s ago
   Docs: man:httpd(8)
      man:apachectl(8)
 Main PID: 11854 (httpd)
  Status: "Total requests: 0; Current requests/sec: 0; Current traffic:  0 B/sec"
  CGroup: /system.slice/httpd.service
      ├─11854 /usr/sbin/httpd -DFOREGROUND
      ├─11855 /usr/sbin/httpd -DFOREGROUND
      ├─11856 /usr/sbin/httpd -DFOREGROUND
      ├─11857 /usr/sbin/httpd -DFOREGROUND
      ├─11858 /usr/sbin/httpd -DFOREGROUND
      └─11859 /usr/sbin/httpd -DFOREGROUND

May 29 12:08:16 localhost systemd[1]: Starting The Apache HTTP Server...
May 29 12:08:16 localhost systemd[1]: Started The Apache HTTP Server.

システム全体で、このようなプロセスの分類を直接表示するには、systemd-cgls ユーティリティーを使用できます。

~]# systemd-cgls | head -17
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
├─user.slice
│ └─user-0.slice
│  └─session-168.scope
│   ├─ 3049 login -- root
│   ├─11884 -bash
│   ├─11943 systemd-cgls
│   └─11944 head -17
└─system.slice
 ├─httpd.service
 │ ├─11854 /usr/sbin/httpd -DFOREGROUND
 │ ├─11855 /usr/sbin/httpd -DFOREGROUND
 │ ├─11856 /usr/sbin/httpd -DFOREGROUND
 │ ├─11857 /usr/sbin/httpd -DFOREGROUND
 │ ├─11858 /usr/sbin/httpd -DFOREGROUND
 │ └─11859 /usr/sbin/httpd -DFOREGROUND
 ├─rhnsd.service

systemd が適切に機能するには、サービスを systemd システムから起動または停止して、ユニットの分類に対して適切なプロセスを維持する必要があります。外部アクションを実行する操作を行うと、必要な cgroup 構造が作成されません。これは、systemd が、開始されるプロセスの特別な性質を認識しないために発生します。

上記の制約で、たとえば httpd サービスを停止し、/usr/sbin/httpd を直接実行すると、以下のようになります。

~]# systemctl stop httpd
~]# /usr/sbin/httpd
# systemd-cgls | head -17
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
├─user.slice
│ └─user-0.slice
│  └─session-168.scope
│   ├─ 3049 login -- root
│   ├─11884 -bash
│   ├─11957 /usr/sbin/httpd
│   ├─11958 /usr/sbin/httpd
│   ├─11959 /usr/sbin/httpd
│   ├─11960 /usr/sbin/httpd
│   ├─11961 /usr/sbin/httpd
│   ├─11962 /usr/sbin/httpd
│   ├─11963 systemd-cgls
│   └─11964 head -17
└─system.slice
 ├─rhnsd.service
 │ └─3261 rhnsd

httpd プロセスは、user-0.slice および a session-168.scope の下に表示されることに注意してください。このサービスは systemd が直接監視および管理する必要があるシステムサービスとは対照的に、ユーザーが開始したプロセスとして扱われます。この不整合により発生する可能性のある障害には次のものが含まれますが、これに限定されません。

  • システムのシャットダウンまたは再起動のイベント時に、サービスが適切にシャットダウンされません。
  • ユーザーのログアウト中に、SIGHUP や SIGTERM などの予期しない信号が配信されます。
  • Restart= ディレクティブがあるにも関わらず、失敗したプロセスが自動的に再起動しません。
注記

アプリケーションシャットダウンイベントが正常に行われないと、クライアント側の障害やデータ損失、ディスク上の破損などの多くのアプリケーション障害が発生することがあります。

10.8. 関連資料

systemd および Red Hat Enterprise Linux 7 でのその使用については、以下に一覧表示されているリソースを参照してください。

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

  • systemctl(1) - systemctl コマンドラインユーティリティーの man ページには、サポートされるオプションとコマンドの完全なリストが提供されます。
  • systemd(1) - systemd システムおよびサービスマネージャーの man ページでは、その概念に関する詳細情報が提供され、利用可能なコマンドラインオプションと環境変数、サポートされる設定ファイルとディレクトリー、認識されるシグナル、および利用可能なカーネルオプションが説明されています。
  • systemd-delta(1): 拡張され、上書きされた設定ファイルの検索を可能にする systemd-delta ユーティリティーの man ページです。
  • 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 ページでは、プロセスの強制終了手順の設定が説明されています。

オンラインドキュメント

  • Red Hat Enterprise Linux 7 ネットワークガイド: Red Hat Enterprise Linux 7 の ネットワークガイド では、このシステムにおけるネットワークインターフェース、ネットワーク、ネットワークサービスの設定および管理に関する情報を説明しています。hostnamectl ユーティリティーの概要のほか、これを使用してコマンドラインでホスト名を表示して設定する方法が説明されています。また、選択されたホスト名およびドメイン名に関する重要な情報も提供されています。
  • Red Hat Enterprise Linux 7 デスクトップの移行および管理ガイド: Red Hat Enterprise Linux 7 の デスクトップの移行および管理ガイド は、本システム上での GNOME 3 デスクトップの移行計画、導入、設定、および管理について説明しています。loginctl サービスが導入され、最も重要な機能を列挙し、logind ユーティリティーを使用してアクティブなセッションを一覧表示し、マルチシートサポートを有効にする方法を説明します。
  • Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド: Red Hat Enterprise Linux 7 の SELinux ユーザーおよび管理者のガイド では、SELinux の原則と、SELinux を Apache HTTP Server や Postfix、PostgreSQL、OpenShift などの様々なサービスに設定して使用する方法が詳細に説明されています。また、SELinux アクセスパーミッションを systemd が管理するシステムサービス用に設定する方法も説明しています。
  • Red Hat Enterprise Linux 7 インストールガイド - Red Hat Enterprise Linux 7 の インストールガイド では、AMD64 システムおよび Intel 64 システム、64 ビット IBM Power Systems サーバー、および IBM Z にシステムをインストールする方法を説明します。また、キックスタートインストール、PXE インストール、VNC プロトコルへの高度なインストール方法も取り上げています。さらに、インストール後の一般的なタスクと、レスキューモードへの起動方法や root パスワードの回復方法などの詳細な手順を含むインストールの問題に関するトラブルシュートについても説明されています。
  • Red Hat Enterprise Linux 7 セキュリティガイド - Red Hat Enterprise Linux 7 の セキュリティガイド は、ユーザーおよび管理者が、ローカルおよびリモートからの侵入、悪用、悪意のある行為に対してワークステーションおよびサーバーを保護するプロセスとプラクティスを学習する際に役に立ちます。また、重大なシステムサービスを保護する方法についても説明しています。
  • systemd ホームページ - このプロジェクトのホームページでは、systemd に関する詳細情報が提供されています。

関連項目

  • 2章システムロケールおよびキーボード設定 では、システムロケールとキーボードのレイアウトを管理する方法を説明しています。コマンドラインで localectl ユーティリティーを使用して現在のロケールを表示、利用可能なロケールを一覧表示、コマンドラインでシステムロケールを設定、現在のキーボードレイアウトを表示、利用可能なキーマップを一覧表示、そして特定のキーボードレイアウトを有効にする方法が説明されています。
  • 3章日付と時刻の設定 では、システムの日時を管理する方法を説明しています。リアルタイムクロックとシステムクロックの違いや、timedatectl ユーティリティーを使用して現在のシステムクロックの設定を表示、日時を設定、タイムゾーンを変更、およびシステムクロックをリモートサーバーと同期させる方法が説明されています。
  • 6章権限の取得 では、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。
  • 12章OpenSSH は、SSH サーバーの設定方法や、クライアントユーティリティーの sshscp、および sftp を使用してこのサーバーにアクセスする方法を説明しています。
  • 23章ログファイルの表示と管理 では、journald の概要が提供されています。ジャーナルの説明と journald サービスの概要のほか、journalctl ユーティリティーを使ってログエントリーを表示する方法、ライブ表示モードへの切り替え、ログエントリーのフィルター方法を説明しています。さらに、この章では、root 以外のユーザーにシステムログへのアクセスを許可し、一貫性のあるログファイルの保存を可能にする方法も説明されています。

第11章 アクセシビリティーのためのシステム設定

Red Hat Enterprise Linux 7 のアクセシビリティーは、オペレーティングシステムのデフォルトインストールに含まれる Orca スクリーンリーダーによって確保されています。本章では、システム管理者が、視覚障害を持つユーザーに有用なシステムを設定する方法を説明します。

Orca は画面から情報を読み取り、以下を使用してユーザーに伝えます。

  • 音声合成装置 (音声出力を提供)
  • 点字ディスプレイ (触知可能な出力を提供)

Orca の設定に関する詳細は、ヘルプページ をご覧ください。

Orca のコミュニケーション出力を正常に機能させるために、システム管理者は以下を行う必要があります。

11.1. brltty サービスの構成

点字ディスプレイは、brltty サービスを使用して視覚障害のあるユーザーに触知可能な出力を提供します。

brltty サービスを有効する

点字ディスプレイは、brltty が実行していないと作動しません。デフォルトでは、brltty は無効になっています。brltty を有効にし、ブート時に起動するようにします。

~]# systemctl enable brltty.service

ユーザーへの点字ディスプレイの使用許可

点字ディスプレイの使用を許可されているユーザーを設定するには、以下のいずれか 1 つの手順を選択してください。/etc/brltty.conf ファイルを使用した手順は、ユーザーまたはグループをファイルに割り当てることができないファイルシステムにも適しています。/etc/brlapi.key ファイルを使用する方法は、ユーザーまたはグループをファイルに割り当てられるファイルシステムのみに適しています。

/etc/brltty.conf を使用した点字ディスプレイへのアクセスの設定

  1. /etc/brltty.conf ファイルを開き、Application Programming Interface Parameters というセクションを見つけます。
  2. ユーザーを指定します。

    1. 1 人以上の個々のユーザーを指定するには、次の行にユーザーを追加します。

      api-parameters Auth=user:user_1, user_2, ... 		# Allow some local user
    2. ユーザーグループを指定するには、次の行に名前を入力します。

      api-parameters Auth=group:group		# Allow some local group

/etc/brlapi.key を使用して点字ディスプレイへのアクセス設定

  1. /etc/brlapi.key ファイルを作成します。

    ~]# mcookie > /etc/brlapi.key
  2. /etc/brlapi.key の所有権を特定のユーザーまたはグループに変更します。

    1. 個々のユーザーを指定するには、次のコマンドを実行します。

      ~]# chown user_1 /etc/brlapi.key
    2. グループを指定するには、次のコマンドを実行します。

      ~]# chown group_1 /etc/brlapi.key
  3. /etc/brltty.conf の内容を調整し、以下を追加します。

    api-parameters Auth=keyfile:/etc/brlapi.key

点字ドライバーの設定

/etc/brltty.conf ファイルの braille-driver ディレクティブは、点字ディスプレイ用のドライバーの 2 文字のドライバー識別コードを指定します。

点字ドライバーの設定

  1. 適切な点字ドライバーを見つけるときに、自動検知機能を使用するかどうか決定します。

    1. 自動検出を使用する場合は、点字ドライバー をデフォルトのオプションである auto に指定しておきます。

      braille-driver	auto	 # autodetect
      警告

      自動検出はすべてのドライバーを試行します。そのため、時間がかかるか、失敗することさえあります。そのため、特定の点字ドライバーに設定しておくことが推奨されます。

    2. 自動検出を使用しない場合は、braille-driver ディレクティブで必要な点字ドライバーの識別コードを指定します。

      /etc/brltty.conf に記載されている一覧から、必要な点字ドライバーの識別コードを選択します。たとえば、以下のようになります。

      braille-driver	xw	 # XWindow

      複数のドライバーをコンマで区切って設定することもでき、それらの間で自動検出が実行されます。

点字装置の設定

/etc/brltty.confbraille-device ディレクティブは、点字ディスプレイに接続する装置を指定します。以下の装置の種類に対応しています (表11.1「点字装置の種類と対応する構文」 を参照)。

表11.1 点字装置の種類と対応する構文

点字デバイスの種類タイプの構文

シリアルデバイス

serial:path [a]

USB デバイス

[serial-number] [b]

Bluetooth デバイス

bluetooth:address

[a] 相対パスは /dev にあります。
[b] 括弧はオプションを示します。

以下は、特定の装置の設定例です。

braille-device	serial:ttyS0	        # First serial device
braille-device	usb:	            # First USB device matching braille driver
braille-device	usb:nnnnn	        # Specific USB device by serial number
braille-device	bluetooth:xx:xx:xx:xx:xx:xx	# Specific Bluetooth device by address

また、複数のデバイスをコンマで区切って設定することもでき、各デバイスは順番にプローブされます。

警告

デバイスが serial-to-USB アダプターで接続されている場合は、braille-deviceusb: に設定しても機能しません。この場合は、カーネルがアダプター用に作成した仮想シリアルデバイスを識別します。仮想シリアルデバイスは次のようになります。

serial:ttyUSB0
You can find the actual device name in the kernel messages on the device plug with the following command:
~]# dmesg | fgrep ttyUSB0

点字ディスプレイへ特定のパラメーターの設定

特定の点字ディスプレイデバイスに特定のパラメーターを設定するには、/etc/brltty.conf ファイルで braille-parameters ディレクティブを使用します。braille-parameters ディレクティブは、非汎用パラメーターを点字ドライバーに渡します。/etc/brltty.conf の一覧から必要なパラメーターを選択します。

テキストテーブルの設定

/etc/brltty.conftext-table ディレクティブは、シンボルのエンコードに使用されるテキストテーブルを指定します。テキストテーブルの相対パスは /etc/brltty/Text/ ディレクトリーにあります。

テキストテーブルの設定

  1. 適切なテキストテーブルを見つけるために自動選択を使用するかどうかを決定します。
    1. 自動選択を使用する場合は、text-table をデフォルトオプションの auto に指定したままにします。

      text-table	auto	 # locale-based autoselection

      これにより、en-nabcc へのフォールバックを使用したローカルベースの自動選択が実行されます。

    2. 自動選択を使用しない場合は、/etc/brltty.conf の一覧から必要な text-table を選択します。

      たとえば、アメリカ英語のテキストテーブルを使用するには、次を指定します。

      text-table	en_US	 # English (United States)

Contraction テーブルの設定

/etc/brltty.confcontraction-table ディレクティブは、略語のエンコードに使用されるテーブルを指定します。特定の contraction テーブルの相対パスは /etc/brltty/Contraction/ ディレクトリーにあります。

/etc/brltty.conf の一覧から必要な contraction-table を選択します。

たとえば、グレード 2 のアメリカ英語の収縮表を使用するには、次を指定します。

contraction-table	en-us-g2	 # English (US, grade 2)
警告

指定しない場合、収縮表は使用されません。

11.2. Always Show Universal Access Menu をオンにします。

Orca スクリーンリーダーのスイッチを入れるには、Super+Alt+S キーを同時に押します。これにより、Universal Access Menu アイコンがトップバーに表示されます。

universal access menu
警告

ユーザーがユニバーサルアクセスメニュー (Universal Access Menu) にあるすべてのオプションのスイッチをオフにしていると、このアイコンは表示されません。アイコンがないと、視覚障害のあるユーザーのご利用が難しくなります。システム管理者は Always Show Universal Access Menu のスイッチをオンにすれば、アイコンが利用できない状態を防げます。Always Show Universal Access Menu を有効にすると、このメニューのすべてのオプションが無効になっている場合でも、アイコンがトップバーに表示されます。

ユニバーサルアクセスメニューを常に表示 (Always Show Universal Access Menu) のスイッチをオンにする

  1. Gnome Settings メニューを開き、Universal Access をクリックします。
  2. Always Show Universal Access Menu をオンにします。

    常にunivアクセスメニューを表示
  3. オプション: このメニューのすべてのオプションのスイッチがオフになっていても、ユニバーサルアクセスメニュー (Universal Access Menu) アイコンがトップバーに表示されていることを確認します。

    universal access menu

11.3. Festival Speech Synthesis System の有効化

デフォルトでは OrcaeSpeak 音声合成装置を使用していますが、Festival Speech Synthesis System にも対応しています。eSpeak および Festival Speech Synthesis System (Festival) は、異なる方法で音声を合成します。一部のユーザーは、デフォルトの eSpeakシンセサイザーより、Festival を好む場合があります。Festival を有効化する手順は以下のとおりです。

Festival のインストールとブート時の実行

  1. Festival をインストールします。

    ~]# yum install festival festival-freebsoft-utils
  2. Festival を起動時に実行します。

    1. 新規 systemd ユニットファイルを作成します。

      ファイルを /etc/systemd/system/ ディレクトリーに作成し、実行可能な状態にします。

      ~]# touch /etc/systemd/system/festival.service
      ~]# chmod 664 /etc/systemd/system/festival.service
    2. /usr/bin/festival_server ファイルにあるスクリプトが Festival の実行に使用されるよう設定します。以下の内容を /etc/systemd/system/festival.service ファイルに追加します。

      [Unit]
      Description=Festival speech synthesis server
      [Service]
      ExecStart=/usr/bin/festival_server
      Type=simple
    3. systemd に新しい festival.service ファイルが存在することを通知します。

      ~]# systemctl daemon-reload
      ~]# systemctl start festival.service
    4. festival.service を有効化します。

      ~]# systemctl enable festival.service

Festival の音声の選択

Festival には複数の音声が用意されています。

音声を利用するには、以下の一覧から関連するパッケージをインストールしてください。

  • festvox-awb-arctic-hts
  • festvox-bdl-arctic-hts
  • festvox-clb-arctic-hts
  • festvox-kal-diphone
  • festvox-ked-diphone
  • festvox-rms-arctic-hts
  • festvox-slt-arctic-hts
  • hispavoces-pal-diphone
  • hispavoces-sfl-diphone

特定の音声に関する詳細は以下でご覧ください。

~]# yum info package_name

必要な音声を利用するには、その音声を含むパッケージをインストールして、再起動します。

~]# yum install package_name
~]# reboot

第12章 OpenSSH

SSH (Secure Shell) は、クライアント/サーバーアーキテクチャーを使用する 2 つのシステム間でのセキュアな通信を容易にし、ユーザーがリモートでサーバーホストシステムにログインできるようにするプロトコルです。FTPTelnet などの他のリモート通信プロトコルとは異なり、SSH はログインセッションを暗号化するため、侵入者が接続して暗号化されていないパスワードを入手するのが困難になります。

ssh プログラムは、telnetrsh などのリモートホストへのログインに使用される、旧式で、セキュリティー保護が十分でない端末アプリケーションに代わるものとして設計されています。また、scp と呼ばれる関連プログラムが、ホスト間でファイルをコピーするために設計された rcp などの旧式プログラムの代わりとなります。このような旧式アプリケーションは、クライアントとサーバーとの間で送信するパスワードを暗号化しないため、可能な限り使用しないようにしてください。リモートシステムへのログインにセキュアな方法を使用することで、クライアントシステムとリモートホストの両方に対するリスクが低減されます。

Red Hat Enterprise Linux には、一般的な openssh パッケージと、OpenSSH のサーバー (openssh-server) およびクライアント (openssh-clients) のパッケージが含まれます。OpenSSH パッケージには、OpenSSL パッケージ (openssl-libs) が必要です。このパッケージは、重要な暗号化ライブラリーをインストールし、暗号化通信を提供する OpenSSH を有効にします。

12.1. SSH プロトコル

12.1.1. SSH を使用する理由

潜在的な侵入者は、ネットワークトラフィックの中断、傍受、経路変更を可能にする様々なツールを自由に駆使して、システムに侵入します。一般的には、これらの脅威は以下のとおり分類できます。

2 つのシステム間の通信の傍受

攻撃者は、ネットワーク上で通信を行う二者の間のどこかに潜み、両者間で渡される情報をコピーしている可能性があります。攻撃者は情報を傍受して保持する、または情報を改ざんして元の受信者に送信する場合があります。

このような攻撃は、通常 パケットスニファー を使用して行われます。パケットスニファーは、ネットワークを通過する各パケットをキャプチャーしてその内容を分析する、ごく一般的なネットワークユーティリティーです。

特定のホストの偽装

攻撃者のシステムは、送信の対象となる受信者を装うように設定されます。これに成功すると、ユーザーのシステムは不正なホストと通信していることに気がつかないままとなります。

この攻撃は、DNS ポイズニング として知られる手法か、IP スプーフィング と呼ばれる手法を用いて実行されます。前者の場合、侵入者はクラックされた DNS サーバーを使用して、クライアントシステムを不当に複製されたホストへ指定します。後者の場合、侵入者は、信頼されたホストから送信されたように見せかけた偽装ネットワークパケットを送信します。

いずれの手法でも、潜在的な機密情報を傍受することが可能です。その傍受が悪意のある理由で行われる場合には、多大な損害をもたらしかねません。リモートシェルログインとファイルコピー用に SSH を使用すると、こうしたセキュリティーの脅威を大幅に軽減できます。これは、SSH クライアントとサーバーがデジタル署名を使用してそれぞれの ID を確認するためです。さらに、クライアントシステムとサーバーシステムとの間の通信はすべて暗号化されます。各パケットはローカルシステムとリモートシステムのみに知られている鍵を使用して暗号化されるため、通信のいずれか一方の ID をスプーフィングする試みは成功しません。

12.1.2. 主な特長

SSH プロトコルは、以下のような保護手段を提供します。

対象のサーバーになりすますことができない
クライアントは、初回接続後に、以前接続したサーバーと同じサーバーに接続していることを確認できます。
認証情報の取得ができない
クライアントは、強力な 128 ビット暗号化を使用して、サーバーへ認証情報を送信します。
通信の傍受ができない
セッション中に送受信された全データは、128 ビット暗号化を使用して転送されるため、傍受された送信データの暗号解読と読み取りは非常に困難になります。

さらに、以下のようなオプションも提供されます。

ネットワーク上でグラフィカルアプリケーションを使用するセキュアな手段を提供する
クライアントは、X11 転送 と呼ばれる手法を使用して、サーバーから X11 (X Window System) アプリケーションを転送できます。
セキュアでないプロトコルをセキュアにする手段を提供する
SSH プロトコルは、送受信するものをすべて暗号化します。SSH サーバーは、ポート転送 と呼ばれる技術を使用して、POP のようなセキュアではないプロトコルをセキュアにし、システムとデータ全体のセキュリティーを強化できます。
セキュアなチャンネルを作成する
OpenSSH サーバーとクライアントは、サーバーマシンとクライアントマシンとの間のトラフィックに対して、仮想プライベートネットワークに似たトンネルを作成するように設定できます。
Kerberos 認証をサポートする
OpenSSH サーバーとクライアントは、Kerberos ネットワーク認証プロトコルの GSSAPI (Generic Security Services Application Program Interface: 汎用セキュリティーサービス API) 実装を使用して認証を行うように設定できます。

12.1.3. プロトコルのバージョン

現在、SSH にはバージョン 1 とバージョン 2 があります。Red Hat Enterprise Linux 7 の OpenSSH スイートは、SSH バージョン 2 を使用します。バージョン 1 の既知の不正使用の影響を受けない、強化された鍵交換アルゴリズムを備えています。Red Hat Enterprise Linux 7 では、OpenSSH スイートはバージョン 1 の接続に対応していません。

12.1.4. SSH 接続のイベントシーケンス

以下に挙げる一連のイベントは、2 つのホスト間で行われる SSH 通信の整合性を保護するのに役立ちます。

  1. 暗号化ハンドシェイクが行われ、クライアントが正しいサーバーと通信していることを確認できます。
  2. クライアントとリモートホストとの間の接続のトランスポート層が、対称暗号方式を使用して暗号化されます。
  3. クライアントが、サーバーに対して自己認証します。
  4. クライアントは、暗号化された接続でリモートホストと対話します。

12.1.4.1. トランスポート層

トランスポート層の主な役割は、認証時とその後の通信中に、2 つのホスト間の通信を簡単に安全でセキュアなものにすることです。トランスポート層は、データの暗号化と復号を処理し、データパケットの送受信時にその整合性を保護することでその役割を果たします。また、トランスポート層は、情報を圧縮して転送を高速にします。

SSH クライアントがサーバーに接続すると鍵情報が交換されるため、両システムでトランスポート層が適正に構築できます。以下は、こうした鍵情報の交換中に発生する手順です。

  • 鍵を交換する
  • 公開鍵暗号化アルゴリズムが決定する
  • 対称暗号化アルゴリズムが決定する
  • メッセージ認証アルゴリズムが決定する
  • ハッシュアルゴリズムが決定する

鍵交換の間、サーバーは一意の ホスト鍵 を用いて、クライアントに対して自己識別を行います。クライアントがこの特定のサーバーと過去に通信したことがなければ、クライアントはサーバーのホスト鍵を知らないため、接続が成立しません。OpenSSH は、この問題に対処するためにサーバーのホスト鍵を承認します。これは、ユーザーが通知を受けて新規のホスト鍵を受け取り、検証した後に行われます。それ以降の接続では、サーバーのホスト鍵が、クライアント上に保存されているバージョンと照合され、クライアントが実際に目的のサーバーと通信していることを確信できます。この後、ホスト鍵が一致しなくなった場合は、接続前にクライアントに保存してあるバージョンをユーザーが削除する必要があります。

警告

ローカルシステムは、対象サーバーと攻撃者が設定した偽サーバーとの違いを認識しないため、攻撃者は初回コンタクト中に SSH サーバーをマスカレードすることが可能です。この問題を防ぐために、初回接続の前かホスト鍵の不一致が発生した場合には、サーバー管理者へ連絡して新しい SSH サーバーの整合性を確認してください。

SSH は、ほとんどすべての公開鍵アルゴリズムまたはエンコード形式に対応するように設計されています。初回の鍵交換で、交換に使用されるハッシュ値と共有秘密値が作成されると、2 つのシステムは新しい鍵とアルゴリズムの計算を直ちに開始して、認証と、今後の接続で送信されるデータを保護します。

所定の鍵とアルゴリズムを使用して一定量のデータ (正確な量は SSH 実装により異なる) が送信された後に、もう 1 回鍵交換が行われてハッシュ値と新しい共有秘密値の別のセットが生成されます。攻撃者がハッシュ値と共有秘密値を判別できたとしても、その情報が役に立つのは限られた時間のみです。

12.1.4.2. 認証

トランスポート層が、2 つのシステム間で情報を渡すためのセキュアなトンネルを構築すると、サーバーは、秘密鍵でエンコードされた署名の使用やパスワードの入力など、サポートされている別の認証方法をクライアントに伝えます。次に、クライアントが、対応しているいずれかの方法を使用して、サーバーに対して自己認証を試みます。

SSH サーバーとクライアントは、異なるタイプの認証を採用するように設定できるため、双方の制御が最適化されます。サーバーは、そのセキュリティーモデルに基づいて、対応する暗号化方法を決定できます。クライアントは、利用可能なオプションの中から、試行する認証方法の順番を選択できます。

12.1.4.3. チャンネル

SSH トランスポート層での認証に成功すると、多重化 と呼ばれる手法により複数のチャンネルが開きます。[1].これらの各チャンネルは、異なるターミナルセッションと、転送された X11 セッションの通信を処理します。

クライアントとサーバーの両方で、新しいチャンネルを作成できます。その後、各接続の両端に、別々の番号が割り当てられます。クライアントが新しいチャンネルを開こうとする際、要求と共にチャンネル番号を送信します。この情報はサーバーにより保存され、そのチャンネルに通信を移動するのに使用されます。これは、異なるタイプのセッションが相互に影響しないように、あるセッションの終了時にそのチャンネルが SSH による一次接続を停止せずに閉じることができるようにするためです。

また、チャンネルは フロー制御 にも対応しているため、規則的な方法でデータを送受信できます。この方法では、チャンネルが開いているというメッセージをクライアントが受信するまで、チャンネルでデータが送信されません。

クライアントが要求するサービスのタイプと、ユーザーがネットワークに接続される方法に応じて、クライアントとサーバーは、各チャンネルの特性を自動的にネゴシエートします。これにより、プロトコルの基本インフラストラクチャーを変更しなくても、異なるタイプのリモート接続を非常に柔軟に処理できます。

12.2. OpenSSH の設定

12.2.1. 設定ファイル

設定ファイルには、クライアントプログラム用 (sshscp および sftp) とサーバー用 (sshd デーモン) の異なる 2 つのセットがあります。

システム全体の SSH 設定情報は、表12.1「システム全体の設定ファイル」 にあるように、/etc/ssh/ ディレクトリー内に格納されています。ユーザー固有の SSH 設定情報は、ユーザーのホームディレクトリー内の ~/.ssh/ に格納されています。詳細は、表12.2「ユーザー固有の設定ファイル」 に記載しています。

表12.1 システム全体の設定ファイル

ファイル詳細

/etc/ssh/moduli

セキュアなトランスポート層を構築するのに非常に重要となる、Diffie-Hellman 鍵交換に使用される Diffie-Hellman グループが置かれています。SSH セッションの初めに鍵が交換される時、共有秘密値が作成されますが、どちらか一方の当事者だけでは決定できません。この値は、ホスト認証を行うのに使用されます。

/etc/ssh/ssh_config

デフォルトの SSH クライアント設定ファイルです。~/.ssh/config が存在する場合は、これにより上書きされる点に注意して下さい。

/etc/ssh/sshd_config

sshd デーモンの設定ファイルです。

/etc/ssh/ssh_host_ecdsa_key

sshd デーモンが使用する ECDSA 秘密鍵です。

/etc/ssh/ssh_host_ecdsa_key.pub

sshd デーモンが使用する ECDSA 公開鍵です。

/etc/ssh/ssh_host_rsa_key

sshd デーモンが使用する SSH プロトコルのバージョン 2 用の RSA 秘密鍵です。

/etc/ssh/ssh_host_rsa_key.pub

sshd デーモンが使用する SSH プロトコルのバージョン 2 用の RSA 公開鍵です。

/etc/pam.d/sshd

sshd デーモンの PAM 設定ファイルです。

/etc/sysconfig/sshd

sshd サービスの設定ファイルです。

表12.2 ユーザー固有の設定ファイル

ファイル詳細

~/.ssh/authorized_keys

サーバー用の認証済み公開鍵の一覧があります。クライアントがサーバーに接続すると、サーバーが、このファイル内に格納されている署名済み公開鍵を確認してクライアントを認証します。

~/.ssh/id_ecdsa

ユーザーの ECDSA 秘密鍵を格納します。

~/.ssh/id_ecdsa.pub

ユーザーの ECDSA 公開鍵です。

~/.ssh/id_rsa

ssh が使用する SSH プロトコルのバージョン 2 用の RSA 秘密鍵です。

~/.ssh/id_rsa.pub

ssh が使用する SSH プロトコルのバージョン 2 用の RSA 公開鍵です。

~/.ssh/known_hosts

ユーザーがアクセスする SSH サーバーのホスト鍵を格納します。このファイルは、SSH クライアントが正しい SSH サーバーに接続していることを確認するのに使用するため、非常に重要です。

警告

SSH サーバーを設定する場合は、/etc/ssh/sshd_config ファイルの UsePrivilegeSeparation no ディレクティブで Privilege Separation 機能をオフにしないでください。Privilege Separation をオフにすると、多くのセキュリティー機能が無効になるため、サーバーが潜在的な脆弱性にさらされ、攻撃対象となります。UsePrivilegeSeparation の詳細は、sshd_config(5) man ページ、または Red Hat ナレッジベースの記事「What is the significance of UsePrivilegeSeparation directive in /etc/ssh/sshd_config file and how to test it?」を参照してください。Red Hatナレッジベースの記事。

SSH 設定ファイルに使用可能な各種ディレクティブの情報は、ssh_config(5) および sshd_config(5) の man ページを参照してください。

12.2.2. OpenSSH サーバーの起動

OpenSSH サーバーを実行するには、openssh-server パッケージがインストールされている必要があります。新規パッケージのインストール方法は 「パッケージのインストール」 を参照してください。

現行のセッションで sshd デーモンを起動するには、root 権限でシェルプロンプトに以下を入力します。

~]# systemctl start sshd.service

現行のセッションで sshd デーモンを停止するには、root として以下のコマンドを使用します。

~]# systemctl stop sshd.service

ブート時にデーモンが自動的に起動するようにするには、root で以下を入力します。

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

sshd デーモンは network.target ターゲットユニットに依存しますが、静的設定のネットワークインターフェースやデフォルトの ListenAddress 0.0.0.0 オプションの場合はこれで十分です。ListenAddress ディレクティブで別のアドレスを指定し、より遅い動的ネットワーク設定を使用するには、network-online.target ターゲットユニットの依存関係を sshd.service ユニットファイルに追加します。これを行うには、/etc/systemd/system/sshd.service.d/local.conf ファイルを以下のオプションで作成します。

 [Unit]
 Wants=network-online.target
 After=network-online.target

この後、次のコマンドを実行して、systemd マネージャー設定を再ロードします。

~]# systemctl daemon-reload

Red Hat Enterprise Linux でシステムサービスを管理する方法は、10章systemd によるサービス管理 を参照してください。

システムを再インストールすると、新しい識別鍵のセットが作成される点に注意してください。したがって、再インストールの前にいずれかの OpenSSH ツールを使用してシステムに接続したことがあるクライアントには、以下のようなメッセージが表示されます。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@: REMOTE HOST IDENTIFICATION HAS CHANGED!   @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

これを防ぐには、/etc/ssh/ ディレクトリーから関連ファイルをバックアップしておきます。ファイルの一覧は表12.1「システム全体の設定ファイル」を参照してください。これで、システムの再インストール時にファイルを復元できます。

12.2.3. リモート接続に必要な SSH

SSH を本当の意味で有効なものにするためには、セキュリティー保護されていない接続プロトコルは使用しないことをお勧めします。このような接続プロトコルを使用すると、ユーザーのパスワード自体は SSH を使用した 1 回のセッションで保護されても、その後に Telnet を使用してログインした時に傍受されてしまうためです。無効にするサービスには、telnetrshrloginvsftpd などがあります。

vsftpd サービスの設定方法は 「FTP」 を参照してください。Red Hat Enterprise Linux 7でシステムサービスを管理する方法については、10章systemd によるサービス管理をお読みください。

12.2.4. 鍵ベース認証の使用

システムのセキュリティーをさらに強化するには、SSH 鍵のペアを生成し、パスワード認証を無効にすることで鍵ベース認証を強制します。これを行うには、vinano などのテキストエディターで /etc/ssh/sshd_config 設定ファイル開き、PasswordAuthentication オプションを以下のように変更します。

PasswordAuthentication no

新規のデフォルトインストール以外のシステムで作業をしている場合は、PubkeyAuthentication no が設定されて いない ことを確認してください。リモートで接続している場合は、コンソールもしくは帯域外アクセスを使用せず、パスワード認証を無効にする前にプロセス内で鍵ベースのログをテストすることが推奨されます。

sshscp、または sftp を使用してクライアントマシンからサーバーに接続できるようにするには、以下の手順に従って認証鍵ペアを生成します。鍵はユーザーごとに別々に生成する必要がある点に注意してください。

NFS がマウントされたホームディレクトリーで鍵ベースの認証を使用するには、最初に SELinux ブール値 use_nfs_home_dirs を有効にします。

~]# setsebool -P use_nfs_home_dirs 1

Red Hat Enterprise Linux 7 は、デフォルトで SSH プロトコル 2 および RSA 鍵を使用します (詳細は 「プロトコルのバージョン」を 参照してください)。

重要

これらのステップを root で完了すると、鍵を使用できるのは root のみになります。

注記

システムを再インストールする際に、生成しておいた鍵ペアを引き続き使用する場合は、~/.ssh/ ディレクトリーのバックアップを作成します。再インストール後に、このディレクトリーをホームディレクトリーにコピーします。この手順は、システムの全ユーザー (root を含む) が実行できます。

12.2.4.1. 鍵ペアの生成

以下の手順に従って、SSH プロトコルのバージョン 2 用の RSA 鍵ペアを生成します。

  1. RSA 鍵ペアを生成するには、シェルプロンプトで次のコマンドを実行します。

    ~]$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/USER/.ssh/id_rsa):
  2. Enter キーを押して、新規作成される鍵のデフォルトの場所 (~/.ssh/id_rsa) を確認します。
  3. パスフレーズを入力します。プロンプトが表示されたら再入力して確認します。セキュリティー上の理由により、アカウントのログイン時に使用するパスワードは使用しないでください。

    この後、以下のようなメッセージが表示されます。

    Your identification has been saved in /home/USER/.ssh/id_rsa.
    Your public key has been saved in /home/USER/.ssh/id_rsa.pub.
    The key fingerprint is:
    SHA256:UNIgIT4wfhdQH/K7yqmjsbZnnyGDKiDviv492U5z78Y USER@penguin.example.com
    The key's randomart image is:
    +---[RSA 2048]----+
    |o ..==o+.    |
    |.+ . .=oo    |
    | .o. ..o     |
    | ... ..    |
    |    .S    |
    |o .   .    |
    |o+ o .o+ ..   |
    |+.++=o*.o .E   |
    |BBBo+Bo. oo   |
    +----[SHA256]-----+
    注記

    以前のバージョンでデフォルトのフィンガープリントである MD5 鍵フィンガープリントを取得する場合は、ssh-keygen コマンドで -E md5 オプションを使用します。

  4. デフォルトで、~/.ssh/ ディレクトリーのパーミッションは、rwx------ または 8 進数表記の 700 に設定されます。これは、USER のみがコンテンツを表示できるようにする設定です。必要に応じて、次のコマンドで確認できます。

    ~]$ ls -ld ~/.ssh
    drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
  5. 公開鍵をリモートマシンにコピーするには、次の形式でコマンドを実行します。

     ssh-copy-id user@hostname

    これにより、最近変更した ~/.ssh/id*.pub 公開鍵がインストールされていない場合は、その公開鍵をコピーします。または、以下のように、公開鍵のファイルを指定します。

    ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname

    これにより、~/.ssh/id_rsa.pub の内容が、接続するマシンの ~/.ssh/authorized_keys ファイルにコピーされます。ファイルが存在する場合は、鍵がその最後に追加されます。

SSH プロトコルのバージョン 2 用の ECDSA 鍵ペアを生成するには、以下の手順に従います。

  1. ECDSA 鍵ペアを生成するには、シェルプロンプトで次のコマンドを実行します。

    ~]$ ssh-keygen -t ecdsa
    Generating public/private ecdsa key pair.
    Enter file in which to save the key (/home/USER/.ssh/id_ecdsa):
  2. Enter キーを押して、新規作成された鍵用のデフォルトの場所 (~/.ssh/id_ecdsa) を確認します。
  3. パスフレーズを入力します。プロンプトが表示されたら再入力して確認します。セキュリティー上の理由により、アカウントのログイン時に使用するパスワードは使用しないでください。

    この後、以下のようなメッセージが表示されます。

    Your identification has been saved in /home/USER/.ssh/id_ecdsa.
    Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub.
    The key fingerprint is:
    SHA256:8BhZageKrLXM99z5f/AM9aPo/KAUd8ZZFPcPFWqK6+M USER@penguin.example.com
    The key's randomart image is:
    +---[ECDSA 256]---+
    |   . .   +=|
    | . . . =   o.o|
    | + . * .  o...|
    | = . . * . + +..|
    |. + . . So o * ..|
    |  . o . .+ = ..|
    |   o oo ..=. .|
    |    ooo...+ |
    |    .E++oo  |
    +----[SHA256]-----+
  4. デフォルトで、~/.ssh/ ディレクトリーのパーミッションは、rwx------ または 8 進数表記の 700 に設定されます。これは、USER のみがコンテンツを表示できるようにする設定です。必要に応じて、次のコマンドで確認できます。

    ~]$ ls -ld ~/.ssh
           ~]$ ls -ld ~/.ssh/
    drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
  5. 公開鍵をリモートマシンにコピーするには、次の形式でコマンドを実行します。

    ssh-copy-id USER@hostname

    これにより、最近変更した ~/.ssh/id*.pub 公開鍵がインストールされていない場合は、その公開鍵をコピーします。または、以下のように、公開鍵のファイルを指定します。

    ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname

    これにより、~/.ssh/id_ecdsa.pub の内容が、接続するマシンの ~/.ssh/authorized_keys にコピーされます。ファイルが存在する場合は、鍵がその最後に追加されます。

システムにパスフレーズを記憶させる設定方法については 「ssh-agent の設定」 を参照してください。

重要

秘密鍵は、個人使用を目的としているため、他人には決して教えないでください。

12.2.4.2. ssh-agent の設定

ssh-agent 認証エージェントを使用するとパスフレーズを保存することができるため、リモートマシンとの接続を開始する度にパスフレーズを入力する必要がなくなります。GNOME を実行している場合は、ログイン時には常にパスフレーズを求めるプロンプトを表示して、セッションを通してそのパスフレーズを記憶させておくように設定できます。それ以外の方法として、特定のシェルプロンプト用にパスフレーズを保存しておくことも可能です。

以下のステップに従って、GNOME セッション中にパスフレーズを保存します。

  1. openssh-askpass パッケージがインストールされていることを確認します。Red Hat Enterprise Linux に新しいパッケージをインストールする方法の詳細は、「パッケージのインストール」 を参照してください。
  2. Super キーを押してアクティビティーの概要に入り、 Startup Applications と入力して Enter を押します。Startup Applications Preferences ツールが表示されます。デフォルトでは、利用可能なスタートアッププログラムの一覧を含むタブが表示されます。Super キーはキーボードや他のハードウェアによって外見が異なりますが、通常はスペースバーの左側にある Windows キーまたは Command キーになります。

    図12.1 自動起動するアプリの設定

    自動起動するアプリの設定
  3. 右側の 追加 ボタンをクリックして、コマンド フィールドに /usr/bin/ssh-add と入力します。

    図12.2 新規アプリケーションの追加

    新規アプリケーションの追加
  4. 追加 をクリックした後に、新しく追加した項目の横のチェックボックスにチェックマークが付いていることを確認してください。

    図12.3 アプリケーションの有効化

    アプリケーションの有効化
  5. 一度ログアウトしてから再度ログインします。パスフレーズの入力を求めるダイアログボックスが表示されます。これ以降は、sshscp、または sftp によるパスワードの入力を要求されることはありません。

    図12.4 パスフレーズの入力

    パスフレーズの入力

特定のシェルプロンプト用のパスフレーズを保存するには、以下のコマンドを使用します。

~]$ ssh-add
Enter passphrase for /home/USER/.ssh/id_rsa:

ログアウト時には、パスフレーズは記憶されない点に注意してください。仮想コンソールまたはターミナルウィンドウにログインする度にコマンドを実行する必要があります。

12.3. OpenSSH クライアント

クライアントマシンから OpenSSH サーバーに接続するには、openssh-clients パッケージがインストールされている必要があります (&MAJOROS; に新規パッケージをインストールする方法については 「パッケージのインストール」 を参照)。

12.3.1. ssh ユーティリティーの使用

ssh ユーティリティーを使用すると、リモートマシンにログインしてそのマシン上でコマンドを実行することできます。これは、rloginrsh および telnet プログラムに代わるセキュアな手段です。

telnet コマンドと同様に、以下のコマンドを使用してリモートマシンにログインします。

ssh hostname

たとえば、penguin.example.com という名前のリモートマシンにログインするには、シェルプロンプトで以下を入力します。

~]$ ssh penguin.example.com

これで、ローカルマシンで使用しているユーザー名でログインします。別のユーザー名を指定する場合には、以下の形式のコマンドを使用してください。

ssh username@hostname

たとえば、USER として penguin.example.com にログインするには、以下のように入力します。

~]$ ssh USER@penguin.example.com

初回接続時には、以下のようなメッセージが表示されます。

The authenticity of host 'penguin.example.com' can't be established.
ECDSA key fingerprint is SHA256:vuGKK9dsW34zrZzwjl5g+vOE6EZQvHRQ8zObKYO2mW4.
ECDSA key fingerprint is MD5:7e:15:c3:03:4d:e1:dd:ee:99:dc:3e:f4:b9:67:6b:62.
Are you sure you want to continue connecting (yes/no)?

このダイアログの質問に答える前に、常にフィンガープリントが正しいか確認してください。ユーザーは、鍵が正しいかサーバー管理者に尋ねることができます。これは、安全で事前に合意した方法で行う必要があります。サーバーのホスト鍵にユーザーがアクセスできる場合、フィンガープリントは以下のように ssh-keygen コマンドを使用することで確認できます。

~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
SHA256:vuGKK9dsW34zrZzwjl5g+vOE6EZQvHRQ8zObKYO2mW4
注記

以前のバージョンでデフォルトのフィンガープリントである MD5 鍵フィンガープリントを取得する場合は、ssh-keygen コマンドで -E md5 オプションを使用します。例:

~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub -EM md5
MD5:7e:15:c3:03:4d:e1:dd:ee:99:dc:3e:f4:b9:67:6b:62

yes と入力して鍵を受け入れ、接続を確定します。サーバーが既知ホストの一覧に追加されたことを知らせるメッセージと、パスワードの入力を求めるプロンプトが以下のように表示されます。

Warning: Permanently added 'penguin.example.com' (ECDSA) to the list of known hosts.
USER@penguin.example.com's password:
重要

SSH サーバーのホスト鍵が変更された場合、クライアントはサーバーのホスト鍵が ~/.ssh/known_hosts ファイルから削除されるまで接続を開始できないことをユーザーに知らせます。ただし、これを実行する前に、SSH サーバーのシステム管理者に連絡して、サーバーが被害を受けていないことを確認してください。

~/.ssh/known_hosts ファイルから鍵を削除するには、以下のようにコマンドを発行します。

~]# ssh-keygen -R penguin.example.com
# Host penguin.example.com found: line 15 type ECDSA
/home/USER/.ssh/known_hosts updated.
Original contents retained as /home/USER/.ssh/known_hosts.old

パスワードを入力すると、リモートマシン用のシェルプロンプトが表示されます。

別の方法として、シェルプロンプトにログインせずに、ssh プログラムを使用してリモートマシン上でコマンドを実行することができます。

ssh username@hostname command

たとえば、 / etc / redhat-releaseファイルは、Red Hat Enterprise Linuxのバージョンに関する情報を提供します。penguin.example.com でこのファイルの内容を表示するには、以下を入力します。

~]$ ssh USER@penguin.example.com cat /etc/redhat-release
USER@penguin.example.com's password:
Red Hat Enterprise Linux Server release 7.0 (Maipo)

正しいパスワードを入力すると、ユーザー名が表示され、ローカルのシェルプロンプトに戻ります。

12.3.2. scp ユーティリティーの使用

scp を使用すると、暗号化されたセキュアな接続でマシン間のファイル転送を行うことができます。設計に関しては、rcp と非常に似ています。

ローカルファイルをリモートシステムへ転送するには、以下の形式でコマンドを使用します。

scp localfile username@hostname:remotefile

たとえば、taglist.vimpenguin.example.com という名前のリモートマシンに転送したい場合は、シェルプロンプトで以下のように入力します。

~]$ scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim
USER@penguin.example.com's password:
taglist.vim                  100% 144KB 144.5KB/s  00:00

一度に複数のファイルを指定することも可能です。.vim/plugin/ の内容を penguin.example.com のリモートマシン上の同じディレクトリーに転送するには、以下のコマンドを入力します。

~]$ scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/
USER@penguin.example.com's password:
closetag.vim                 100%  13KB 12.6KB/s  00:00
snippetsEmu.vim                100%  33KB 33.1KB/s  00:00
taglist.vim                  100% 144KB 144.5KB/s  00:00

リモートファイルをローカルシステムへ転送するには、以下の構文を使用します。

scp username@hostname:remotefile localfile

たとえば .vimrc 設定ファイルをリモートマシンからダウンロードするには、以下のように入力します。

~]$ scp USER@penguin.example.com:.vimrc .vimrc
USER@penguin.example.com's password:
.vimrc                    100% 2233   2.2KB/s  00:00

12.3.3. sftp ユーティリティーの使用

sftp ユーティリティーを使用すると、セキュアでインタラクティブな FTP セッションを開始することができます。その設計では、ftp と似ていますが、暗号化された接続を使用します。

リモートシステムに接続するには、以下の形式でコマンドを使用します。

sftp username@hostname

たとえば penguin.example.com という名前のリモートマシンに USER というユーザー名でログインするには、以下のように入力します。

~]$ sftp USER@penguin.example.com
USER@penguin.example.com's password:
Connected to penguin.example.com.
sftp>

正しいパスワードを入力すると、プロンプトが表示されます。sftp ユーティリティーは、ftp で使用されるコマンドセットと同様のものを使用します (表12.3「利用可能な sftp コマンドの抜粋」 を参照)。

表12.3 利用可能な sftp コマンドの抜粋

コマンド詳細

ls [directory]

リモート directory の内容を一覧表示します。指定がない場合は、デフォルトで現在の作業ディレクトリーが使用されます。

cd directory

リモートの作業ディレクトリーを directory に変更します。

mkdir ディレクトリー

リモートの directory を作成します。

rmdir path

リモートの directory を削除します。

put localfile [remotefile]

localfile をリモートマシンに転送します。

get remotefile [localfile]

remotefile をリモートマシンから転送します。

利用可能なコマンドの詳細リストは、 sftp(1) の man ページを参照してください。

12.4. セキュアなシェルの追加

セキュアなコマンドラインインターフェースは、数多くある SSH の用途の中でも初歩的なものに過ぎません。十分な帯域幅があれば、X11 セッションは SSH チャンネル上で送信できます。あるいは、TCP/IP 転送を使用することで、以前はセキュリティー保護されていなかったシステム間のポート接続を特定の SSH チャンネルにマッピングすることができます。

12.4.1. X11 転送

SSH 接続上で X11 セッションを開始するには、以下の形式でコマンドを使用します。

ssh -Y username@hostname

たとえば penguin.example.com という名前のリモートマシンに USER というユーザー名でログインするには、以下のように入力します。

~]$ ssh -Y USER@penguin.example.com
USER@penguin.example.com's password:

セキュアなシェルプロンプトから X プログラムを実行すると、SSH クライアントとサーバーは新しいセキュアなチャンネルを作成し、X プログラムデータはそのチャンネル上で透過的にクライアントマシンに送信されます。

X11 転送の前に X Window System がインストールされている必要があることに注意してください。root で以下のコマンドを入力し、X11 パッケージグループをインストールします。

~]# yum group install "X Window System"

パッケージグループの詳細は「パッケージグループでの作業」を参照してください。

X11 転送は非常に便利なものです。たとえば、X11 転送を使用すると、Print Settings ユーティリティーのセキュアかつインタラクティブなセッションを作成できます。これを行うには、ssh を使用してサーバーに接続し、以下のコマンドを入力します。

~]$ system-config-printer &

印刷設定 ツールが表示され、リモートユーザーがリモートシステムで安全に印刷を設定できます。

12.4.2. ポート転送

SSH は、ポート転送によりセキュリティー保護されていない TCP/IP プロトコルをセキュアにすることができます。この手法を使用する場合、SSH サーバーは SSH クライアントをつなぐ暗号化された経路となります。

ポート転送は、クライアント上のローカルポートをサーバー上のリモートポートにマッピングすることで機能します。SSH ではサーバーの任意のポートをクライアント上の任意のポートにマッピングすることが可能です。このテクニックが機能するためにポート番号が一致する必要はありません。

注記

1024 未満のポートで待機するようにポート転送を設定するには、root レベルのアクセスが必要です。

localhost 上で接続を待機する TCP/IP ポート転送チャンネルを作成するには、以下の形式でコマンドを使用します。

ssh -L local-port:remote-hostname:remote-port username @ hostname

たとえば、暗号化された接続で POP3 を使用して、mail.example.com と呼ばれるサーバーでメールを確認するには、以下のコマンドを使用します。

~]$ ssh -L 1100:mail.example.com:110 mail.example.com

ポート転送チャンネルがクライアントマシンとメールサーバー間に配置されたら、POP3 メールクライアントに対し localhost 上のポート 1100 を使用して、新規のメールを確認するように指示します。クライアントシステム上のポート 1100 に送信される要求は、安全に mail.example.com サーバーに向けられます。

SSH サーバーを実行しているのが mail.example.com ではなく、同一のネットワーク上にある別のマシンの場合でも、SSH を使用して接続の一部をセキュアにすることができます。ただし、若干異なるコマンドが必要になります。

~]$ ssh -L 1100:mail.example.com:110 other.example.com

この例では、クライアントマシン上のポート 1100 からの POP3 要求がポート 22 の SSH 接続を介して SSH サーバー other.example.com に転送されます。次に、other.example.commail.example.com 上のポート 110 に接続して、新規のメールを確認します。この手法を使用する場合、クライアントシステムと other.example.com SSH サーバー間の接続のみがセキュアである点に注意してください。

OpenSSH スイートは、UNIX ドメインソケットのローカルおよびリモートのポート転送も提供します。UNIX ドメインソケットをネットワークを介して別のマシンへ転送するには、ssh -L local-socket:remote-socket username@hostname コマンドを使用します。以下に例を示します。

~]$ ssh -L /var/mysql/mysql.sock:/var/mysql/mysql.sock username@hostname

ポート転送は、ネットワークのファイアウォール経由でセキュアに情報を取得する場合にも使用できます。ファイアウォールが標準ポート (ポート 22) 経由の SSH トラフィックを許可するよう設定されているものの、他のポートへのアクセスはブロックする場合でも、確立された SSH 接続にそのような通信をリダイレクトすることにより、ブロックされたポートを使用した 2 つのホスト間の接続は可能になります。

重要

この方法でポート転送を使って接続を転送すると、クライアントシステム上のどのユーザーもそのサービスに接続できます。クライアントシステムが侵害された場合、攻撃者は転送されたサービスにアクセスすることもできます。

ポート転送に関するシステム管理者は、/etc/ssh/sshd_configAllowTcpForwarding 行に No パラメーターを指定して sshd サービスを再起動することで、この機能をサーバー上で無効にできます。

12.5. 関連資料

Red Hat Enterprise Linux で OpenSSH サーバーを設定し、接続する方法は、以下の資料を参照してください。

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

  • sshd(8): sshd デーモンの man ページでは、利用可能なコマンドラインオプションと、対応している設定ファイルおよびディレクトリーがすべて説明されています。
  • ssh(1): ssh クライアントアプリケーションの man ページでは、利用可能なコマンドラインオプションと、対応している設定ファイルおよびディレクトリーがすべて説明されています。
  • scp(1): scp ユーティリティーの man ページでは、このユーティリティーの詳細な説明とその使用方法が説明されています。
  • sftp(1) - sftp ユーティリティーの man ページ
  • ssh-keygen(1) - ssh-keygen ユーティリティーの man ページは、このユーティリティーを使用して ssh が使用する認証鍵を生成、管理、変換する詳細な方法が説明されています。
  • ssh_config(5) - ssh_config の man ページでは、利用可能な SSH クライアント設定オプションが説明されています。
  • sshd_config(5) - sshd_config の man ページでは、利用可能な SSH デーモン設定オプションが詳細に説明されています。

オンラインドキュメント

  • OpenSSH Home Page - その他のドキュメントや FAQ、メーリングリストへのリンク、バグレポートなどの役立つリソースを掲載した OpenSSH のホームページです。
  • OpenSSL Home Page - その他のドキュメントや FAQ、メーリングリストへのリンクなどの役立つリソースを掲載した OpenSSL のホームページです。

関連項目

  • 6章権限の取得 では、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。
  • 10章systemd によるサービス管理 では、systemd の詳細情報と、systemctl コマンドを使用してシステムサービスを管理する方法が説明されています。


[1] 多重接続は、共有されている共通のメディアで送信されるいくつかのシグナルで構成されます。SSH により、異なるチャンネルが共通のセキュアな接続で送信されます。

第13章 TigerVNC

TigerVNC (Tiger Virtual Network Computing) は、グラフィカルデスクトップシェアリングのシステムで、他のコンピューターのリモート制御を可能にします。

TigerVNC は、クライアントサーバープリンシパルで機能します。サーバーはその出力 (vncserver) を共有し、クライアント (vncviewer) はサーバーに接続します。

注記

以前の Red Hat Enterprise Linux ディストリビューションとは異なり、Red Hat Enterprise Linux 7 の TigerVNC は、その設定に systemd システム管理デーモンを使用します。/etc/sysconfig/vncserver 設定ファイルに代わり、/etc/systemd/system/vncserver@.service が使用されるようになりました。

13.1. VNC Server

vncserver は、VNC (Virtual Network Computing) デスクトップを起動するユーティリティーです。適切なオプションで Xvnc が実行され、VNC デスクトップ上でウィンドウマネージャーが起動します。vncserver を使用すると、どこからでもいくつものクライアントがアクセス可能なマシン上で独立したセッションを同時に実行できます。

13.1.1. VNC サーバーのインストール

TigerVNC サーバーをインストールするには、root 権限で以下のコマンドを実行します。

~]# yum install tigervnc-server

13.1.2. VNC サーバーの設定

VNC サーバーでは、表示、ネットワークアドレス、ポート、セキュリティーの設定などに対するオプションのパラメーターを使用して、1 人または複数のユーザー用の画面を起動するよう設定できます (ユーザーのシステムがシステムに存在する場合)。

1 人のユーザー用に VNC サーバーの設定

  1. /etc/systemd/system/vncserver@.service という名前の設定ファイルが必要になります。このファイルを作成するには、/usr/lib/systemd/system/vncserver@.service ファイルを root でコピーします。

    ~]# cp /usr/lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@.service

    systemd は、オンデマンドでメモリー内に適切な名前が付けられたインスタンスを自動的に作成し、サービスファイル内の '%i' はディスプレイ番号に置き換えられるため、ファイル名に表示番号を含める必要はありません。単一ユーザーの場合は、ファイルの名前を変更する必要がありません。複数ユーザーの場合は、たとえば、ユーザー名をファイル名に追加して、各ユーザーに対して一意な名前が付けられたサービスファイルが必要です。詳細は「2 人のユーザー用に VNC サーバーの設定」を参照してください。

  2. /etc/systemd/system/vncserver@.service を修正して、USER を実際のユーザー名で置き換えます。その他の行は、そのままにしておきます。-geometry 引数は、作成される VNC デスクトップのサイズを指定します。デフォルトでは 1024x768 に設定されます。

    ExecStart=/usr/sbin/runuser -l USER -c "/usr/bin/vncserver %i -geometry 1280x1024"
    PIDFile=/home/USER/.vnc/%H%i.pid
  3. 変更を保存します。
  4. 変更を直ちに反映させるには、以下のコマンドを実行します。

    ~]# systemctl daemon-reload
  5. 設定ファイルで定義されたユーザー用のパスワードを設定します。最初に root から USER に切り替える必要があることに注意してください。

    ~]# su - USER
    ~]$ vncpasswd
    Password:
    Verify:
    重要

    保存されたパスワードは暗号化されていません。パスワードファイルへのアクセスが可能であれば、誰でもプレーンテキストのパスワードを見ることができます。

「VNC サーバーの起動」 に進みます。

13.1.2.1. 2 人のユーザー用に VNC サーバーの設定

同一マシンで複数のユーザーを設定する場合は、ユーザーごとに異なるテンプレートタイプのサービスファイルを作成します。

  1. たとえば、vncserver-USER_1@.servicevncserver-USER_2@.service の 2 つのサービスファイルを作成します。これら 2 つのファイルで、USER を正しいユーザー名に置き換えます。
  2. 両方のユーザーでパスワードを設定します。

    ~]$ su - USER_1
    ~]$ vncpasswd
    Password:
    Verify:
    ~]$ su - USER_2
    ~]$ vncpasswd
    Password:
    Verify:

13.1.3. VNC サーバーの起動

サービスを起動もしくは有効にするには、コマンドで直接ディスプレイ番号を指定します。1 人のユーザー用に VNC サーバーの設定 の上記で設定したファイルはテンプレートとして機能し、そこでは %isystemd によりディスプレイ番号に置き換えます。有効な番号を用いて、以下のコマンドを実行します。

~]# systemctl start vncserver@:display_number.service

また、システム起動時に自動的にサービスが開始するようにすることもできます。そうすると、ログイン時に vncserver が自動的に開始されます。root で以下のコマンドを発行します。

~]# systemctl enable vncserver@:display_number.service

この時点で、他のユーザーは VNC ビューアープログラムを使用して、定義されたディスプレイ番号とパスワードで VNC サーバーに接続できます。グラフィカルデスクトップがインストールされている場合は、そのデスクトップのインスタンスが表示されます。これは、ターゲットマシンで現在表示されているものと同じインスタンスではありません。

13.1.3.1. ユーザー 2 人および 2 つの別個のディスプレイ用に VNC サーバーの設定

vncserver-USER_1@.service および vncserver-USER_2@.service という 2 つの設定済み VNC サーバーで、異なるディスプレイ番号を有効にできます。たとえば、以下のコマンドでは、USER_1 の VNC サーバーがディスプレイ 3 で起動し、USER_2 の VNC サーバーがディスプレイ 5 で起動することになります。

~]# systemctl start vncserver-USER_1@:3.service
~]# systemctl start vncserver-USER_2@:5.service

13.1.4. GDM 用の XDMCP を使用した xinetd ベースの VNC セットアップ

GDM 用の X Display Manager Control Protocol (XDMCP) を使用した xinetd ベースの VNC セットアップは、主にシンクライアントで構成されているクライアントシステムに有益なセットアップです。セットアップ後、クライアントは GDM ログインウィンドウにアクセスでき、システムアカウントにログインできます。設定の前提条件は、gdmvnc -server &、および xinetd パッケージがインストールされていることです。

~]# yum install gdm tigervnc tigervnc-server xinetd

サービス xinetd を有効化する必要があります。

~]# systemctl enable xinetd.service

システムのデフォルトターゲットユニットは graphical.target になっているはずです。現在設定されているデフォルトターゲットユニットを取得するには、以下を使用します。

~]# systemctl get-default

以下を使用して、デフォルトターゲットユニットを変更できます。

~]# systemctl set-default target_name

GDM ログインウィンドウへのアクセスとログイン

  1. /etc/gdm/custom.conf 設定ファイルを編集して、GDM を設定して XDMCP を有効にします。

    [xdmcp]
    Enable=true
  2. 以下のコンテンツで /etc/xinetd.d/xvncserver というファイルを作成します。

    service service_name
    {
    disable = no
    protocol = tcp
    socket_type = stream
    wait = no
    user = nobody
    server = /usr/bin/Xvnc
    server_args = -inetd -query localhost -once -geometry selected_geometry -depth selected_depth securitytypes=none
    }

    server_args セクションでは、-query localhost オプションにより、xdmcp セッションに対して各 Xvnc インスタンスのクエリー localhost が作成されます。-depth オプションは、作成する VNC デスクトップの─深さ (ビット) を指定します。使用できる値は、8、15、16、および 24 です。その他の値は、アプリケーションの予測できない動作を引き起こします。

  3. /etc/services ファイルを編集して、サービスを定義します。これを行うには、以下の内容を /etc/services ファイルに追加します。

    # VNC xinetd GDM base
    service_name 5950/tcp
  4. 設定の変更が反映されるようにするには、マシンを再起動します。

    あるいは、以下を実行します。init レベルを 3 に変更し、5 に戻して、gdm をリロードします。

    # init 3
    # init 5

    gdm が UDP ポート 177 をリッスンしていることを確認します。

    # netstat -anu|grep 177
    udp    0   0 0.0.0.0:177         0.0.0.0:*

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

    ~]# systemctl restart xinetd.service

    xinetd サービスが新しいサービスを読み込んだことを確認します。

    # netstat -anpt|grep 595
    tcp    0   0 :::5950           :::*            LISTEN   3119/xinetd
  5. vncviewer コマンドを使用して設定をテストします。

    # vncviewer localhost:5950

    コマンドは、パスワードが求められない localhost に対して VNC セッションを起動します。GDM ログイン画面が表示され、有効なユーザー名とパスワードでシステムのユーザーアカウントにログインできます。それから、リモート接続で同じテストを実行できます。

その設定に対してファイアウォールを設定します。ファイアウォール設定ツールを実行し、TCP ポート 5950 を追加してシステムへの接続を許可します。

~]# firewall-cmd --permanent --zone=public --add-port=5950/tcp
~]# firewall-cmd --reload

13.1.5. VNC セッションの終了

vncserver サービスの有効化と同様に、システム開始時に自動的にサービスの起動を無効にできます。

~]# systemctl disable vncserver@:display_number.service

または、システムの実行中に、以下のコマンドを root で発行すると、サービスを停止できます。

~]# systemctl stop vncserver@:display_number.service

13.2. 既存のデスクトップの起動

デフォルトでは、ログインしているユーザーはディスプレイ 0 の X サーバーにより提供されたデスクトップを使用します。ユーザーは TigerVNC サーバー x0vncserver を使用してデスクトップを共有できます。

X デスクトップの共有

ログインしているユーザーのデスクトップを x0vncserver を使用して共有するには、以下の手順を実行します。

  1. root で次のコマンドを実行します。

    ~]# yum install tigervnc-server
  2. ユーザーの VNC パスワードを設定します。

    ~]$ vncpasswd
    Password:
    Verify:
  3. そのユーザーで以下のコマンドを入力します。

    ~]$ x0vncserver -PasswordFile=.vnc/passwd -AlwaysShared=1

ファイアウォールがポート 5900 への接続を許可するよう設定されている場合、リモートビューアーはディスプレイ 0 に接続し、ログインしているユーザーのデスクトップを表示できます。ファイアウォールの設定方法は 「VNC のためのファイアウォールの設定」 を参照してください。

13.3. VNC ビューアー

vncviewer は、グラフィカルユーザーインターフェースを表示し、vncserver をリモートで制御するプログラムです。

vncviewer の操作では、エントリーを含むポップアップメニューがあり、これでフルスクリーンモードの切り替え、ビューアーの終了などの様々なアクションを実行します。また、ターミナルから vncviewer を操作することもできます。vncviewer のパラメーターの一覧を表示するには、コマンドラインで vncviewer -h を入力します。

13.3.1. VNC ビューアーのインストール

TigerVNC (vncviewer) クライアントをインストールするには root で以下のコマンドを発行します。

~]# yum install tigervnc

13.3.2. VNC サーバーへの接続

VNC サーバーを設定すると、VNC サーバーを任意の VNC ビューアーに接続できます。

SSH を使用した VNC サーバーへの接続

  1. 引数なしで vncviewer コマンドを入力すると、VNC Viewer: Connection Details ユーティリティーが表示されます。接続する VNC サーバーを指定するよう要求されます。
  2. 必要な場合は、同じ画面への既存の VNC 接続の切断を回避するために、以下のようにデスクトップの共有を許可するオプションを選択します。

    1. Options (オプション) ボタンを選択します。
    2. Misc. (その他) タブを選択します。
    3. Shared (共有) ボタンを選択します。
    4. OK を選択してメインメニューに戻ります。
  3. 接続するアドレスとディスプレイ番号を入力してください。

    address:display_number
  4. Connect (接続) を押して VNC サーバー画面に接続します。
  5. VNC パスワードを入力するよう求められます。これは、グローバルなデフォルトの VNC パスワードが設定されていない限り、ディスプレイ番号に対応するユーザーの VNC パスワードです。

    VNC サーバーデスクトップを示すウィンドウが表示されます。これは通常のユーザーに表示されるデスクトップではなく、Xvnc デスクトップであることに注意してください。

CLI を使用した VNC サーバーへの接続

  1. 引数としてアドレスとディスプレイ番号を指定して、viewer コマンドを入力します。

    vncviewer address:display_number

    ここで、addressIP アドレスまたはホスト名です。

  2. VNC パスワードを入力して自分自身を認証します。これは、グローバルなデフォルトの VNC パスワードが設定されていない限り、ディスプレイ番号に対応するユーザーの VNC パスワードです。
  3. VNC サーバーデスクトップを示すウィンドウが表示されます。これは通常のユーザーに表示されるデスクトップではなく、Xvnc デスクトップであることに注意してください。

13.3.2.1. VNC のためのファイアウォールの設定

暗号化されていない接続を使用する場合は、firewalld が接続を拒否する可能性があります。firewalld が VNC パケットを通過させることを許可するには、TCP トラフィックに特定のポートを開きます。-via オプションを使用する場合、トラフィックは firewalld においてデフォルトで有効な SSH を介してリダイレクトされます。

注記

VNC サーバーのデフォルトのポートは 5900 です。リモートデスクトップにアクセス可能なポートに到達するには、このデフォルトのポートとユーザーに割り当てられたディスプレイ番号の合計を計算します。たとえば、2 つ目のディスプレイは 2 + 5900 = 5902 のようになります。

ディスプレイ 0 から 3 については、以下で説明しているように service オプションによって、VNCサービスの firewalld のサポートを利用します。ディスプレイ番号が 3 よりも大きい場合は、firewalld でポートを開く で説明されているように、対応するポートを特別に開く必要があります。

firewalld での VNC サービスの有効化

  1. firewalld 設定の情報を確認するには、以下のコマンドを実行します。

    ~]$ firewall-cmd --list-all
  2. 特定のアドレスからのすべての VNC 接続を許可するには、以下のコマンドを実行します。

    ~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.122.116" service name=vnc-server accept'
    success

    ここで変更する内容は、システムの再起動後は維持されないことに注意してください。ファイアウォールを永続的に変更するには、コマンドに --permanent オプションを繰り返し追加してください。ファイアウォールのリッチ言語コマンドの使用方法はRed Hat Enterprise Linux 7 Security Guide (Red Hat Enterprise Linux 7 セキュリティーガイド)を参照してください。

  3. 上記の設定を確認するには、以下のコマンドを使用します。

    ~]# firewall-cmd --list-all
    public (default, active)
     interfaces: bond0 bond0.192
     sources:
     services: dhcpv6-client ssh
     ports:
     masquerade: no
     forward-ports:
     icmp-blocks:
     rich rules:
    	rule family="ipv4" source address="192.168.122.116" service name="vnc-server" accept

特定のポートまたはポートの範囲を開くには、--add-port オプションを使用して firewall-cmd コマンドラインツールに使用します。たとえば、VNC 画面 4 では、TCP トラフィックに対してポート 5904 を開く必要があります。

firewalld でポートを開く

  1. パブリックゾーンで TCP トラフィックのポートを開くには、root で以下のようにコマンドを発行します。

    ~]# firewall-cmd --zone=public --add-port=5904/tcp
    success
  2. パブリックゾーンに対して現在開かれているポートを表示するには、以下のコマンドを発行します。

    ~]# firewall-cmd --zone=public --list-ports
    5904/tcp

ポートは、firewall-cmd --zone=zone --remove-port=number/protocol コマンドを使用して削除できます。

ここで変更する内容は、システムの再起動後は維持されないことに注意してください。ファイアウォールを永続的に変更するには、コマンドに --permanent オプションを繰り返し追加してください。firewalld でのポートのオープンおよびクローズの詳細については、Red Hat Enterprise Linux 7 Security Guide を参照してください。

13.3.3. SSH を使用した VNC サーバーへの接続

VNC は、通信への攻撃に対するセキュリティーがないクリアテキストネットワークプロトコルです。通信をセキュアにするには、-via オプションを指定してサーバークライアント接続を暗号化します。これにより、VNC サーバーとクライアントとの間に SSH トンネルが作成されます。

VNC サーバークライアント接続を暗号化するコマンドの形式は以下のとおりです。

vncviewer -via user@host:display_number

例13.1 -via オプションの使用

  1. SSH を使用して VNC サーバーに接続するには、以下のようなコマンドを入力します。

    ~]$ vncviewer -via USER_2@192.168.2.101:3
  2. プロンプトが表示されたら、パスワードを入力し、Enter を押して確認します。
  3. リモートデスクトップのウィンドウが画面に表示されます。
VNC アクセスの制限

暗号化した接続のみを選択する場合は、systemd.service ファイルの ExecStart 行で -localhost オプションを使用すると、暗号化されていない接続を完全に回避できます。

ExecStart=/usr/sbin/runuser -l user -c "/usr/bin/vncserver -localhost %i"

これにより、vncserver は、-via オプションの結果として SSH を使用して送信されたローカルホストおよびポート転送された接続以外の接続を許可しません。

SSH の使用の詳細は、12章OpenSSH を参照してください。

13.4. 関連資料

TigerVNC に関する詳細は、以下の資料を参照してください。

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

  • vncserver(1): VNC サーバーユーティリティーの man ページです。
  • vncviewer(1): VNC ビューアーの man ページです。
  • vncpasswd(1): VNC パスワードコマンドの man ページです。
  • Xvnc(1): Xvnc サーバー設定オプションの man ページです。
  • x0vncserver(1): 既存の X サーバーを共有する TigerVNC サーバーの man ページです。

パート V. サーバー

ここでは、Web サーバーの設定方法やネットワーク上でのファイルとディレクトリーの共有方法など、サーバーに関連する様々なトピックを説明します。

第14章 Web サーバー

Web サーバー は、Web 経由でクライアントにコンテンツを提供するネットワークサービスです。これは通常 Web ページを指しますが、他のドキュメントも当てはまります。Web サーバーは、ハイパーテキスト転送プロトコル (HTTP) を使用するため、HTTP サーバーとも呼ばれます。

Red Hat Enterprise Linux 7 で利用可能な Web サーバーは以下のとおりです。

  • Apache HTTP サーバー
  • nginx
重要

nginx web サーバーは、Red Hat Enterprise Linux 7 の Software Collection としてのみ利用できます。nginx へのアクセス方法や、Software Collections などの使用方法は Red Hat Software Collections のリリースノートを参照してください。

14.1. Apache HTTP サーバー

本セクションでは、Apache HTTP Server 2.4httpd を説明します。これは、Apache Software Foundation により開発されたオープンソースの Web サーバーです。

Red Hat Enterprise Linux の以前のリリースからアップグレードする場合は、適切に httpd サービス設定を更新する必要があります。本セクションでは、新たに追加された機能のいくつか、Apache HTTP Server 2.4 とバージョン 2.2 の重要な違い、古い設定ファイルの更新方法について説明します。

14.1.1. 主な変更点

Red Hat Enterprise Linux 6 と比較して Red Hat Enterprise Linux 7 の Apache HTTP Server には以下の変更があります。

httpd サービスの制御

SysV init スクリプトからの移行に伴い、サーバー管理者は service コマンドの代わりに apachectl コマンドと systemctl コマンドを使用してサービスを制御することが推奨されます。以下の例は、httpd サービスに固有です。

コマンド:

service httpd graceful

は以下に置き換えられます。

apachectl graceful

httpd 用の systemd ユニットファイルは、以下のように init スクリプトと異なる動作を持ちます。

  • サービスがリロードすると、デフォルトで正常な再起動が使用されます。
  • サービスが停止すると、デフォルトで正常な停止が使用されます。

    コマンド:

    service httpd configtest

    は以下に置き換えられます。

    apachectl configtest
プライベート /tmp
システムのセキュリティーを高めるため、systemd ユニットファイルは、プライベートの /tmp ディレクトリーを使用して httpd デーモンを実行します。これは、システムの /tmp ディレクトリーとは別のものです。
設定レイアウト

モジュールをロードする設定ファイルは、/etc/httpd/conf.modules.d/ ディレクトリーにあります。このディレクトリーには、php など、追加でロードできる httpd 用モジュールを提供するパッケージによりファイルが配置されます。/etc/httpd/conf/httpd.conf ファイルのメインセクションの前に置かれた Include ディレクティブは、/etc/httpd/conf.modules.d/ ディレクトリー内にファイルを追加するために使用されます。つまり、conf.modules.d/ にある設定ファイルはすべて、httpd.conf のメインセクションが処理される前に処理されます。/etc/httpd/conf.d/ ディレクトリーのファイルに対する IncludeOptional ディレクティブは、httpd.conf ファイルの最後に配置されます。したがって、/etc/httpd/conf.d/ 内のファイルは、httpd.conf のセクションが処理されてから処理されます。

そのほかにも、httpd パッケージが設定ファイルをいくつか提供しています。

  • /etc/httpd/conf.d/autoindex.conf: これは mod_autoindex ディレクトリーのインデックス作成を設定します。
  • /etc/httpd/conf.d/userdir.conf: これにより、http://example.com/~username/ などのユーザーディレクトリーへのアクセスが設定されます。このようなアクセスは、セキュリティー上の理由からデフォルトでは無効になっています。
  • /etc/httpd/conf.d/welcome.conf: 以前のリリースと同様に、http://localhost/ でコンテンツがない場合に表示される「ようこそ」ページが設定されます。
デフォルト設定
最小限の httpd.conf ファイルがデフォルトで提供されるようになりました。TimeoutKeepAlive といった一般的な設定の多くは、デフォルトで明示的に設定されることはなくなり、ハードコーディングされるようになります。このハードコーディングされた全設定ディレクティブ用のデフォルト設定は、マニュアルに記載されています。詳細は「インストール可能なドキュメント」を参照してください。
互換性がない構文の変更
既存の設定を httpd 2.2 から httpd 2.4 に移行する場合は、httpd 設定の構文に後方互換性がない変更が含まれるため、変更が必要になります。http://httpd.apache.org/docs/2.4/upgrading.html のアップグレードに関する詳細は、以下の Apache ドキュメントを参照してください。
処理モデル

Red Hat Enterprise Linux の以前のリリースでは、さまざまな マルチプロセスモデル (MPM) が、さまざまなな httpd バイナリーとして利用できていました。つまり、分岐モデルの prefork を /usr/sbin/httpd として、またスレッドベースのモデルである worker を /usr/sbin/httpd.worker としてしました。

Red Hat Enterprise Linux 7 では、単独の httpd バイナリーのみが使われ、3 つの MPM はロード可能なモジュール (worker、prefork (デフォルト)、および event) として利用可能です。必要に応じて、コメント文字 # を追加および削除して 3 つの MPM モジュールの 1 つだけがロードされるよう設定ファイル /etc/httpd/conf.modules.d/00-mpm.conf を編集します。

パッケージ変更

LDAP 認証および承認の各モジュールは、個別のサブパッケージ mod_ldap で提供されています。新たなモジュール mod_session と関連のヘルパーモジュールは、新しいサブパッケージ mod_session で提供されています。新しいモジュールの mod_proxy_htmlmod_xml2enc は、新しいサブパッケージ mod_proxy_html で提供されています。これらのパッケージはすべて Optional チャンネルにあります。

注記

Optional および Supplementary チャンネルをサブスクライブする前に、「対象範囲の詳細」を参照してください。これらのチャンネルからパッケージをインストールする場合は、Red Hat カスタマーポータルの記事「証明書ベースの管理を使用して、Optional および Supplementary チャンネル、-devel パッケージにアクセスする方法」で説明されている手順を行ってください。

ファイルシステムのレイアウトのパッケージ

/var/cache/mod_proxy/ ディレクトリーは提供されなくなりました。代わりに、/var/cache/httpd/ ディレクトリーが proxy サブディレクトリーおよび ssl サブディレクトリーとパッケージ化されています。

httpd で提供されていたパッケージ化されたコンテンツは、/var/www/ から /usr/share/httpd/ に移動しています。

  • /usr/share/httpd/icons/: ディレクトリーインデックスで使用されるアイコンセットを含むディレクトリーは、(以前の /var/www/icons/ ディレクトリーから) /usr/share/httpd/icons/ に変更になりました。デフォルト設定では http://localhost/icons/ で利用可能です。アイコンの場所と利用可能性は、/etc/httpd/conf.d/autoindex.conf ファイルで設定可能です。
  • /usr/share/httpd/manual/: /var/www/manual//usr/share/httpd/manual/ に変更になりました。httpd-manual パッケージに含まれるこのディレクトリーには httpd の HTML バージョンのマニュアルが含まれます。このパッケージがインストールされている場合は、http://localhost/manual/ で利用可能です。マニュアルの場所と利用可能性は /etc/httpd/conf.d/manual.conf ファイルで設定できます。
  • usr/share/httpd/error/: /var/www/error//usr/share/httpd/error/ に移動しました。カスタムの複数言語の HTTP エラーページです。デフォルトでは設定されておらず、設定ファイルの例は /usr/share/doc/httpd-VERSION/httpd-multilang-errordoc.conf で提供されています。
認証、認可、およびアクセス制御
認証、認可、およびアクセス制御に使用される設定ディレクティブは、大幅に変更されました。OrderDeny、および Allow の各ディレクティブを使用している既存の設定ファイルは、新たな Require 構文を使うようにしてください。詳細は、以下の Apache ドキュメントを参照してください。http://httpd.apache.org/docs/2.4/howto/auth.html
suexec
システムのセキュリティーを改善するために、suexec バイナリーは、root ユーザーと同じようにインストールされなくなりました。代わりに、より限定的なパーミッションセットを可能にするファイルシステムのケイパビリティーセットがあります。この変更に加えて、suexec バイナリーは /var/log/httpd/suexec.log ログファイルを使用しなくなりました。代わりに、ログメッセージは syslog に送信されます。デフォルトでは、これらのメッセージは /var/log/secure ログファイルに表示されます。
モジュールインターフェース

httpd モジュールインターフェースが変更したため、httpd 2.2 に対して構築されたサードパーティーのバイナリーモジュールは、httpd 2.4 と互換性がありません。これらのモジュールは、必要に応じて httpd 2.4 モジュ