Red Hat Training

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

システム管理者のガイド

Red Hat Enterprise Linux 7

Red Hat Enterprise Linux 7 の導入、設定、管理

Marie Doleželová

Red Hat Customer Content Services

Marc Muehlfeld

Red Hat Customer Content Services

Adam Kvítek

Red Hat Customer Content Services

Maxim Svistunov

Red Hat Customer Content Services

Stephen Wadeley

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Jaromír Hradílek

Red Hat Customer Content Services

Douglas Silas

Red Hat Customer Content Services

Jana Heves

Red Hat Customer Content Services

Petr Kovář

Red Hat Customer Content Services

Peter Ondrejka

Red Hat Customer Content Services

Petr Bokoč

Red Hat Customer Content Services

Martin Prpič

Red Hat Product Security

Eliška Slobodová

Red Hat Customer Content Services

Eva Kopalová

Red Hat Customer Content Services

Miroslav Svoboda

Red Hat Customer Content Services

David O'Brien

Red Hat Customer Content Services

Michael Hideo

Red Hat Customer Content Services

Don Domingo

Red Hat Customer Content Services

John Ha

Red Hat Customer Content Services

概要

システム管理者のガイド』 では、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 パッケージから利用できます。chronyd を使用した NTP の設定および使用に関する詳細は 17章chrony スイートを使用した NTP 設定 を参照してください。
  • ntpd
    ntpd デーモンは、ntp パッケージから利用できます。ntpd を使用した NTP の設定および使用に関する詳細は 18章ntpd を使用した NTP 設定 を参照してください。
デフォルトの chronyd ではなく ntpd を使用する場合は、chronyd を無効にし、18章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 インストールプログラムのグラフィカルユーザーインターフェースの Installation Summary 画面での Network & Hostname メニュー
  • Anaconda インストールプログラムのテキストモードにおける Network settings オプション
  • キックスタートファイル
インストール完了後に初めてシステムを起動すると、インストール中に設定したネットワークインターフェースが自動的にアクティブになります。
インストールプロセス中のネットワークアクセスの設定に関する詳細は『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 ネットワークガイド』の「NetworkManager コマンドラインツール (nmcli) の使用」を参照してください。

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

NetworkManager のテキスト形式のユーザーインターフェース (TUI) ユーティリティーである nmtui は、NetworkManager を制御するテキストインターフェースを提供してネットワークを設定します。
テキスト形式のインターフェースツールである nmtui のインストールおよび使用に関する詳細は『Red Hat Enterprise Linux 7 ネットワークガイド』を参照してください。

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

CockpitNetworking メニューを使用すると、以下を実行できます。
  • 最近送受信したパケットの表示
  • 利用可能なネットワークインターフェースの最も重要な特徴の表示
  • ネットワーキングログのコンテンツの表示
  • ネットワークインターフェースの様々なタイプ (ボンディング、チーム、ブリッジ、VLAN) の追加
Cockpit でのネットワーキング管理

図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.1 システムの登録およびサブスクリプション

  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.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 は、systemd ユニットという概念を導入する Linux オペレーティングシステムのシステムおよびサービスマネージャーです。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 を選択します。ここで状態を確認したり、開始/停止、有効化/無効化を設定できます。
Cockpit でのサービス管理

図1.2 Cockpit でのサービス管理

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 を無効した場合は、任意アクセス制御 (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 モードを表示し、必要に応じてモードを設定するには以下を実行します。

手順1.2 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 ファイルのデフォルト設定を変更しても、次回のシステム起動時に設定が自動的に元に戻る点に注意してください。
Cockpit での SELinux 管理

図1.3 Cockpit での SELinux 管理

1.6.3. SSH ベース認証の使用

1.6.3.1. SSH ベースの認証とシステムセキュリティーの強化方法

別のコンピューターとの通信の安全性を確保したい場合は、SSH ベースの認証を使用することが可能です。
SSH (Secure Shell) は、クライアントとサーバーとの間の通信を容易にし、ユーザーが SSH を実行するホストシステムにリモートでログインできるようにするプロトコルです。SSH は接続を暗号化します。クライアントは、暗号化した認証情報をサーバーへ送信します。セッション中に送受信したすべてのデータは暗号化されて転送されます。
SSH は、パスワードなしでユーザーが認証できるようにします。これを行うために、SSH は公開鍵/秘密鍵スキームを使用します。
SSH の保護手段に関する詳細は 「主な特長」 を参照してください。

1.6.3.2. SSH 接続の確立

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

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

  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 セキュリティーガイド』を参照してください。

手順1.4 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 のシステム管理の中心的要素を表しています。

グループおよびその使用可能な目的

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

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

ユーザーアカウントとグループを管理する最も基本的なタスク、および適切なコマンドラインツールは、以下のとおりです。
  • ユーザーおよびグループ 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 メニューを選択します。
Cockpit におけるユーザーアカウントの管理

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

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 のインストールを確認し、設定するには以下を実行します。

手順1.5 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 用に確保しているメモリー容量
  • クラッシュダンプファイルの場所
Cockpit での kdump の設定

図1.5 Cockpit での kdump の設定

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 プロトコルに基づいています。特定のプログラムがこのシステムを使用してイベントを記録し、ログファイルに整理します。これは、オペレーティングシステムの監査および様々な問題のトラブルシューティングの際に役立ちます。
ログファイルの詳細は、22章ログファイルの表示と管理 を参照してください。

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 ナレッジケースの記事 「Ret Hat サポートチームにファイル (vmcore、rhev logcollector、sosreport、ヒープダンプ、ログファイルなど) を送付する 」 を参照してください。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 オプションが含まれていると、RPM マクロ _install_langs でこの値が使用され、それに応じてインストール済みのロケールが設定されます。ただし、この設定は今回のインストールにのみ影響し、その後のアップグレードには影響しません。アップグレードの際に glibc パッケージを再インストールすると、インストール中にユーザーがリクエストしたロケールではなく、ロケール全体がアップグレードされます。
これを回避するには、永続化させるロケールを選択します。次のような方法があります。

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

  • キックスタートファイルの %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

手順2.2 システム全体に 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 とローカルタイムのいずれかを使用できますが、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 権限で、timedatectl コマンドに set-local-rtc オプションを付けて実行します。
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「システムの現在日時の表示」 を参考にして、format を、サポートされる 1 つまたは複数のコントロールシーケンスに置き換えます。よく使用されるフォーマットオプションのリストは 表3.1「よく使われるコントロールシーケンス」 を参照してください。オプションの完全なリストは、man ページの date(1) を参照してください。

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

コントロールシーケンス詳細
%HHH フォーマットでの時間 (例: 17)。
%MMM フォーマットでの分 (例: 30)。
%SSS フォーマットでの秒 (例: 24)。
%dDD フォーマットでの日 (例: 16)。
%mMM フォーマットでの月 (例: 09)。
%YYYYY フォーマットでの年 (例: 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. システムの現在時刻の変更

システムの現在時刻を変更するには、root で、date コマンドに --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. システムの現在日の変更

現在の日付を変更するには、rootdate コマンドを --set オプションまたは -s オプションと共に実行します。
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 ファイルにその設定を保存します。このファイルは、時刻を手動で設定したり、ハードウェアクロックをシステム時間に同期したりするなどの初回の変更時に作成されます。

注記

hwclock コマンドは、Red Hat Enterprise Linux 6 ではシステムがシャットダウンまたは再起動する際に自動的に実行されますが、Red Hat Enterprise Linux 7 では実行されません。システムクロックが Network Time Protocol (NTP) または Precision Time Protocol (PTP) に同期される場合は、カーネルが 11分ごとに自動的にハードウェアクロックをシステムクロックに同期します。
NTP の詳細は 17章chrony スイートを使用した NTP 設定 および 18章ntpd を使用した NTP 設定 を参照してください。PTP の詳細は 19章ptp4l を使用した PTP の設定 を参照してください。ntpdate を実行した後のハードウェアクロックの設定方法は 「ハードウェアクロック更新の設定」 を参照してください。

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

root ユーザーで、オプションを付けずに hwclock を実行すると、標準出力にローカルタイムの日時が返されます。
hwclock
hwclock コマンドで --utc オプションまたは --localtime オプションを使用しても、ハードウェアクロックタイムが UTC またはローカルタイムで表示されるわけではありません。これらのオプションは、ハードウェアクロックのいずれかの設定を変更するために使用されます。また、hwclock --utc コマンドまたは hwclock --local コマンドを使用しても、/etc/adjtime ファイルの記録は変更されません。したがって、このコマンドは、/etc/adjtime に保存された設定が誤っていても、その設定を変更したくない場合には役に立つかもしれません。ただし、このコマンドを間違った方法で使用すると、情報を誤って理解してしまう可能性があります。詳細は man ページの hwclock(8) を参照してください。

例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 の詳細は、setup パッケージに記載されています。このドキュメントを表示するには、以下のコマンドを使用します。
cat /usr/share/doc/setup*/uidgid
予約に使用される ID の範囲は将来広がる可能性があるため、5,000 以降の番号を ID に割り当てることが推奨されます。新規ユーザーへの割り当て ID がデフォルトで 5,000 から始まるようにするには、/etc/login.defs ファイルの UID_MINGID_MIN のディレクティブを変更します。
ファイル内容を省略
UID_MIN                  5000ファイル内容を省略
GID_MIN                  5000ファイル内容を省略

注記

UID_MIN ディレクティブおよび GID_MIN ディレクティブの変更前に作成されたユーザーの UID については、デフォルトの 1000 から始まります。
新規ユーザーおよびグループの 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 セキュリティーガイド』 の「パスワードのセキュリティー」を参照してください。
  • /etc/group ファイルを管理する gpasswd ユーティリティー。
  • -e、--expiredate または -f、--inactive オプションを使用した usermod コマンド。
  • -e、--expiredate または -f、--inactive オプションを使用した useradd コマンド。

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

Users ユーティリティーを使用すると、グラフィカルユーザーインターフェースでローカルユーザーを参照、変更、追加、および削除できます。

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

Super キーを押してアクティビティーの概要に入り、 Users と入力して Enter を押します。Users 設定ツールが表示されます。Super キーはキーボードや他のハードウェアによって外見が異なりますが、通常はスペースバーの左側にある Windows キーまたは Command キーになります。また、画面の右上隅にある自分のユーザー名をクリックし、Settings (設定) メニューから Users ユーティリティーを開くこともできます。
ユーザーアカウントに変更を加えるには、最初に Unlock (ロック解除) ボタンを選択し、表示されたダイアログボックスに従って自身を認証します。スーパーユーザー特権がない場合は、root で認証するよう求められます。ユーザーを追加および削除するには、+ ボタンと - ボタンをそれぞれクリックします。管理グループ wheel にユーザーを追加するには、Account Type (アカウントタイプ)Standard (標準) から Administrator (管理者) に変更します。ユーザーの言語設定を編集するには、言語を選択します (ドロップダウンメニューが表示されます)。
ユーザー設定ツール

図4.1 ユーザー設定ツール

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

図4.2 パスワードメニュー

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

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

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

ユーティリティー詳細
idユーザーおよびグループの ID を表示します。
useradd, usermod, userdelユーザーアカウントを追加、修正、削除する標準ユーティリティーです。
groupadd, groupmod, groupdelグループを追加、修正、削除する標準ユーティリティーです。
gpasswdnewgrp コマンドで使用する /etc/gshadow ファイル内のグループパスワードの修正に使用するユーティリティーです。
pwck, grpckパスワード、グループ、関連シャドウファイルを検証するユーティリティーです。
pwconv, pwunconv通常のパスワードをシャドウパスワードに変換する、または逆にシャドウパスワードから通常のパスワードに変換するユーティリティーです。
grpconvgrpunconvpwconv、pwunconv と同様、このユーティリティーは、グループアカウントのシャドウ化された情報を変換するのに使用できます。

4.3.1. 新規ユーザーの追加

システムにユーザーを追加するには、root でシェルプロンプトに以下を入力します。
useradd [options] username
ここでの options表4.2「一般的な useradd コマンドラインオプション」 の説明にあるコマンドラインオプションです。
デフォルトでは、useradd コマンドはロックされたユーザーアカウントを作成します。アカウントのロックを解除するには、root で以下のコマンドを実行し、パスワードを割り当てます。
passwd username
オプションで、パスワードエージングポリシーを設定できます。『Red Hat Enterprise Linux 7 セキュリティーガイド』 の 「パスワードのセキュリティー」 を参照してください。

表4.2 一般的な useradd コマンドラインオプション

オプション
-c 'comment'comment にはどの文字列でも使用できます。このオプションは、通常、ユーザーの氏名を指定するのに使用されます。
-d home_directoryデフォルトの /home/username/ の代わりに使用するホームディレクトリーです。
-e dateYYYY-MM-DD の形式でアカウントを無効にする日付です。
-f daysパスワードが失効してからアカウントが無効になるまでの日数です。0 を指定すると、パスワードが失効した直後にアカウントが無効になります。-1 を指定すると、パスワードが失効してもアカウントは無効になりません。
-g group_nameユーザーのデフォルト (プライマリー) グループ用のグループ名またはグループ番号です。グループはここで指定するよりも前に作成されている必要があります。
-G group_listユーザーがメンバーとなる追加 (補助、デフォルト以外) のグループ名またはグループ番号の一覧で、コンマで区切ります。グループはここで指定するよりも前に作成されている必要があります。
-mホームディレクトリーがない場合は、これを作成します。
-Mホームディレクトリーを作成しません。
-Nユーザー用のユーザープライベートグループを作成しません。
-p passwordcrypt で暗号化されたパスワードです。
-rUID が 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. /etc/passwd に、juan の新しい行が作成されます。
    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. /etc/shadow に、juan 用の新しい行が作成されます。
    juan:!!:14798:0:99999:7:::
    この行には以下の特徴があります。
    • ユーザー名 juan で始まっています。
    • /etc/shadow ファイルのパスワードフィールドに 2 つの感嘆符 (!!) が表示され、これがアカウントをロックします。

      注記

      -p フラグを使用して暗号化されたパスワードを渡した場合は、/etc/shadow ファイル内の、このユーザー用に新たに作成された行に置かれます。
    • パスワードは有効期限なしで設定されています。
  3. /etc/group に、juan という名前のグループ用に新しい行が作成されます。
    juan:x:1001:
    ユーザーと同じ名前のグループは、ユーザープライベートグループ と呼ばれます。ユーザープライベートグループの詳細は 「ユーザープライベートグループ」 を参照してください。
    /etc/group に作成された行には、以下の特徴があります。
    • グループ名 juan で始まります。
    • パスワードフィールドに x が表示され、システムがシャドウグループパスワードを使用していることを示しています。
    • GID は、/etc/passwd 内の juan の プライマリーグループに対する GID と一致します。
  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-uniqueGID が重複するグループの作成を許可します。
-p, --password password新規グループ用にこの暗号化されたパスワードを使用します。
-rGID が 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 は、標準のファイル権限に対応するビットで構成されています。たとえば、umask0137 の場合、その数字は次のような意味になります。
  • 0 = 意味なし、必ず 0 になります (umask は特別なビットに影響しません)
  • 1 = オーナーの権限 (実行ビット) が設定されます
  • 3 = グループの権限 (実行および書き込みビット) が設定されます
  • 7 = その他の人の権限 (実行、書き込み、読み取りビット) が設定されます
umask は 2 進法、8 進法、またはシンボリック表示で表されます。たとえば、8 進法の 0137 はシンボリック表示では u=rw-,g=r--,o=--- となります。シンボリック表示は 8 進法表示と逆に、禁止権限ではなく許可された権限を示します。

umask の仕組み

umask はファイルに禁止権限を設定します (どの権限を設定できないかを指定します)。
  • umask にビットを設定すると、ファイルの設定は解除されます。
  • umask にビットが設定されていないと、他の要素にもよりますが、ファイルで設定できます。
以下の図は、umask 0137 が新しいファイルの作成にどのように影響するのかを示しています。
ファイルの作成時に umask を適用

図4.3 ファイルの作成時に 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 の管理

bashksh, zshtcsh などの一般的なシェルでは、umask シェル ビルトイン を使用して umask を管理します。シェルから開始するプロセスは umask を継承します。

現在のマスクの表示

8 進法で現在の umask を表示するには、以下のコマンドを実行します。
~]$ 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 の設定

シンボリック表示を使用して、umask0337 に設定するには、以下のコマンドを実行します。
~]$ umask -S u=r,g=r,o=

デフォルトシェル umask での作業

シェルには通常、デフォルトの umask が設定されている設定ファイルがあります。bash の場合、そのファイルは /etc/bashrc です。bash のデフォルトの umask を表示するには、以下を実行します。
~]$ grep -i -B 1 umask /etc/bashrc
出力では、umaskumask コマンドまたは 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 での作業

デフォルトで、新しいユーザーの bash umask は、/etc/bashrc で定義されたものになっています。
特定のユーザーの bashumask を変更するには、そのユーザーの $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 が認識されます。これは、Samba が --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 グループに追加するユーザー名に置き換えます。
また、ユーザー 設定ツールを使用して以下のようにグループのメンバーを修正することもできます。この手順を実行するには、管理者権限が必要なことに注意してください。
  1. スーパー キーを押してアクティビティーの概要に入り、Users と入力して Enter キーを押します。ユーザー 設定ツールが表示されます。スーパー キーはキーボードやハードウェアによって異なりますが、通常は スペースバー の左側にある Windows キーまたは Command キーです。
  2. 変更を有効にするには、ロック解除 ボタンをクリックし、有効な管理者パスワードを入力します。
  3. 左側の列でユーザーアイコンをクリックし、右側のペインでユーザーのプロパティーを表示します。
  4. アカウントの種類Standard から Administrator に変更します。これにより、ユーザーが wheel グループに追加されます。
ユーザー ツールの詳細は 「グラフィカル環境でのユーザーの管理」 を参照してください。
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 ページには、このファイルのオプションの詳細なリストが記載されています。

重要

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) の使用方法が説明されています。

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

関連項目

  • 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 をカスタマーポータルに登録するには、以下のコマンドを実行します。
  1. ~]# redhat-support-tool config user username
    username は、Red Hat カスタマーポータルアカウントのユーザー名に置き換えます。
  2. ~]# 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

手順8.1 インタラクティブモードでの 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 value

注記

-g または --global オプションを使用して設定をグローバルで保存するには、Red Hat Support Toolroot で実行する必要があります。通常のユーザーは /etc/redhat-support-tool.conf に書き込むのに必要なパーミッションを持っていないためです。
値またはオプションをローカル設定ファイルから削除するには、以下のように -u、または --unset オプションを追加します。
Command (? for help): config setting -u value
これにより、ツールからパラメーターが削除および設定解除され、(利用可能な場合は) グローバル設定ファイルにある同等の設定が使用されます。

注記

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

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

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

インタラクティブモードで新しいサポートケースを作成するには、以下の手順を実行します。
  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. オプションで、ファイルを添付することを選択します。

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

インタラクティブモードで既存のサポートケースを表示および更新するには、以下の手順を実行します。
  1. 以下のコマンドを入力してツールを起動します。
    ~]# redhat-support-tool
  2. getcase コマンドを入力します。
    Command (? for help): getcase case-number
    case-number は、表示および更新するケースの番号です。
  3. 画面に表示されたプロンプトに従ってケースを表示し、コメントを変更または追加して、添付ファイルを取得または追加します。

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

インタラクティブモードで既存のサポートケースの属性を変更するには、以下の手順を実行します。
  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 Access の 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 コマンドを使用してカーネル (kernel パッケージ)、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 によりシステムに行われる変更を常に調べる必要があります。その結果、発生する可能性がある問題を簡単にトラブルシューティングできます。また、パッケージをインストールせずにダウンロードすることも選択もできます。この場合は、ダウンロードプロンプトで 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 には upgrade コマンドもあります。これは、obsoletes 設定オプションを有効にした update と同様のものです (「[main] オプションの設定」 参照)。デフォルトでは、obsoletes/etc/yum.conf で on になっており、これによりこの 2 つのコマンドが同等のものになっています。

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

すべてのパッケージとそれらの依存関係を更新するには、引数なしで yum update コマンドを使用します。
yum update
パッケージでセキュリティー更新が利用可能な場合は、これらのパッケージのみを最新のバージョンに更新できます。root として次のコマンドを入力します。
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
term を、検索するパッケージ名に置き換えます。

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

vimgvim、または 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[出力は省略されています]

============================ N/S matched: emacs =============================
emacs.x86_64 : GNU Emacs text editor
emacs-auctex.noarch : Enhanced TeX modes for Emacs[出力は省略されています]

  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

例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

例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

例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
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. パッケージのインストール

単一パッケージと、そのパッケージでインストールされていない依存関係をすべてインストールするには、root 権限で、以下の形式でコマンドを入力します。
yum install package_name
複数パッケージを同時にインストールするには、その名前を引数として追加します。root で以下を入力します。
yum install package_name package_name
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

例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
install-n を使用した場合は、その後の name が正確なパッケージ名を指していると yum は解釈します。また、install-na では、ピリオドを使用してパッケージ名とアーキテクチャーを指定しており、install-nevra では、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 (はい) または N (いいえ) オプションの他に、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 によりパッケージがダウンロードされますが、インストールは行いません。このようなパッケージは、後でオフラインで yum localinstall コマンドを使用してインストールしたり、別のデバイスと共有したりできます。ダウンロードしたパッケージは、キャッシュディレクトリーのサブディレクトリー (デフォルトでは /var/cache/yum/$basearch/$releasever/packages/) の 1 つに保存されます。ダウンロードはバックグラウンドで行われるため、並行して yum を他の操作に使用できます。

9.2.6. パッケージの削除

パッケージのインストールと同様に、yum を使用するとパッケージのアンインストールができます。特定のパッケージと、
それに依存するすべてのパッケージをアンインストールするには、root で以下のコマンドを実行します。
yum remove package_name
複数のパッケージをインストールする場合と同様、コマンドに複数のパッケージ名を追加すると、一度に複数のパッケージを削除できます。

例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
このコマンドで使用できるオプションには、たとえば以下のようなものがあります。hidden はユーザー表示可能とマークされていないグループも一覧表示し、ids はグループ ID を表示します。また、languageenvironmentinstalledavailable などのオプションを追加して、出力を特定のグループタイプに制限することもできます。
特定のグループに含まれている必須およびオプションパッケージを一覧表示するには、以下のコマンドを使用します。
yum group info glob_expression

例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 を渡すとこれら両方を含めることができます。

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. パッケージグループの削除

パッケージグループ名またはその ID を使用して、install 構文に類似した構文でパッケージグループを削除できます。root で以下のコマンドを入力します。
yum group remove group_name
yum group remove groupid
また、groupid または引用符で囲んだグループ名を@ マークに続けて、remove コマンドに渡すことも可能です。これにより、yum コマンドに、group remove の実行を認識させます。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

例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省略形詳細
DowngradeD1 つ以上のパッケージが旧バージョンにダウングレードされました。
EraseE1 つ以上のパッケージが削除されました。
InstallI1 つ以上の新しいパッケージがインストールされました。
ObsoletingO1 つ以上のパッケージが廃止として記録されました。
ReinstallR1 つ以上のパッケージが再インストールされました。
UpdateU1 つ以上のパッケージが新しいバージョンに更新されました。

表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

例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

例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
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 を設定することも可能です。これらの設定オプションの詳細は、man ページの yum.conf(5) を参照してください。

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 オプションを設定できます。また、1 つ以上の [repository] セクションを含めてリポジトリー固有のオプションを設定することもできます。ただし、/etc/yum.repos.d/ ディレクトリー内にある、新規または既存の .repo ファイルで個々のリポジトリーを定義することが推奨されます。/etc/yum.conf ファイルの各 [repository] セクションで定義した値は、[main] セクションで設定された値よりも優先されます。
このセクションでは以下の方法を紹介します。
  • /etc/yum.conf 設定ファイルの [main] セクションを編集して yum のグローバルオプションを設定する方法
  • /etc/yum.conf[repository] セクションと /etc/yum.repos.d/ ディレクトリー内の .repo ファイルを編集することで、個々のリポジトリーのオプションを設定する方法
  • 動的バージョンとアーキテクチャーの値が適切に処理されるように /etc/yum.conf の yum 変数と /etc/yum.repos.d/ ディレクトリー内のファイルを使用する方法
  • コマンドラインで yum リポジトリーを追加、有効、無効にする方法
  • カスタムの yum リポジトリーを設定する方法

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

/etc/yum.conf 設定ファイルには、1 つの [main] セクションが含まれます。このセクションにあるキー値ペアの中には 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
[コメントは省略されています ]

# 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=0 は、デバッグ出力を無効にします。デフォルト値は debuglevel=2 です。
exactarch=value
このオプションを使用すると、インストール済みのパッケージを更新する際に、yum が正確なアーキテクチャーを考慮するように設定できます。value を以下のいずれかで置き換えます。
0: パッケージの更新時には正しいアーキテクチャーを考慮に入れて実行しません。
1 (デフォルト値): パッケージの更新時に正しいアーキテクチャーを考慮します。このように設定すると、yum が、64 ビットアーキテクチャーのシステムにインストールされているパッケージの更新に、32 ビットアーキテクチャーのパッケージを使用しません。
exclude=package_name [more_package_names]
exclude オプションを使用すると、インストールまたはシステムの更新中にキーワードを使用してパッケージを除外できます。除外する複数のパッケージを一覧表示する場合は、パッケージをスペースで区切り、引用符で囲みます。ワイルドカードを使用したシェルの glob 表現 (*? など) が利用できます。
gpgcheck=value
gpgcheck オプションを使用すると、yum がパッケージに 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 upgrade、および yum group remove の各コマンドがパッケージグループを処理する方法を指定できます。value を以下のいずれかで置き換えます。
simple: パッケージグループのすべてのメンバーをインストールします。以前にインストールされたパッケージのみを更新し、その間にグループに追加されたパッケージはインストールしません。
compat: simple に似ていますが、yum upgrade は前回の更新以降にグループに追加されたパッケージもインストールします。
objects: (デフォルト)。このオプションでは、yum は以前にインストールされたグループを追跡し、グループの一部としてインストールされたパッケージと、個別にインストールされたパッケージを区別します。例9.15「LibreOffice パッケージグループの情報表示」 を参照してください。
group_package_types=package_type [more_package_types]
このオプションでは、yum group install コマンドが呼び出された際にどのタイプのパッケージがインストールされるか (optionaldefault、または mandatory) を指定できます。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 でインストールを行い、更新を行わないパッケージの一覧をスペースで区切って提供できます。デフォルトでインストールのみに設定されているパッケージの一覧は、man ページの yum.conf(5) を参照してください。
installonlypkgs ディレクティブを /etc/yum.conf に追加する場合は、yum.conf(5) の installonlypkgs セクションに表示されているものも含め、インストールだけを行う すべての パッケージを表示します。特に、カーネルパッケージは常に installonlypkgs (デフォルトのとおり) に表示するようにします。また、デフォルトのカーネルが起動に失敗した場合でも、バックアップカーネルを常に利用できるように、installonly_limit に設定する値は常に 2 より大きい値にすることを推奨します。
installonly_limit=value
このオプションは、installonlypkgs ディレクティブでリストされるパッケージを同時にインストールできる数を設定します。value を、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 がヘッダーおよびパッケージのキャッシュを保持するかどうかを指定します。ここでは、value を以下のいずれかに置き換えます。
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-bit バージョンをインストールします。
all: 常に全パッケージ用の可能なあらゆるアーキテクチャーをインストールします。たとえば、AMD64 システムで multilib_policyall に設定すると、yum はパッケージの i686 および AMD64 が利用可能であれば両バージョンをインストールします。
obsoletes=value
obsoletes オプションは、更新の実行時に 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 に設定した場合は、yum プラグインの設定ファイル内で enabled=0 を設定することでそのプラグインを無効にすることも可能です。
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 がファイルの取得を試行する回数を設定します。value0 以上の整数で、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
リポジトリーパッケージの並行ダウンロードを制御します。value は、以下のいずれかになります。
auto: (デフォルト) 可能な場合、並行ダウンロードを使用します。つまり、失敗を回避するために yum はプラグインが作成したリポジトリーについては自動的にこれを無効にします。
on: リポジトリーの並行ダウンロードが有効になります。
off: リポジトリーの並行ダウンロードが無効になります。
他にも多くの [repository] オプションがあります。このうちのいくつかは、[main] オプションと同一形式、同一機能になります。オプションの一覧は、man ページ yum.conf(5) の [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
glob 表現を使用して、適合する全セクションの設定を表示することもできます。
yum-config-manager glob_expression

例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[出力は省略されています]

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 ファイルに追加します。yum は、このディレクトリーにある .repo ファイル拡張子が付いたすべてのファイルを読み取ることができます。リポジトリーは /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
ここでの repository は、一意のリポジトリー ID になります (利用可能なリポジトリー ID を一覧表示するには yum repolist all を使用)。別の方法では、glob 表現を使用すると、一致するすべてのリポジトリーを有効にできます。
yum-config-manager --enable glob_expression

例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[出力は省略されています]

例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[出力は省略されています]
成功すると、yum-config-manager --enable コマンドは現在のリポジトリー設定を表示します。

Yum リポジトリーの無効化

yum リポジトリーを無効にするには、root で以下のコマンドを実行します。
yum-config-manager --disable repository
ここでの repository は一意のリポジトリー ID になります (利用可能なリポジトリー ID を一覧表示するには yum repolist all を使用)。yum-config-manager --enable と同様に、glob 表現を使用して、一致するすべてのリポジトリーを同時に無効にできます。
yum-config-manager --disable glob_expression

例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[出力は省略されています]
成功すると、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 を参照してください。/mnt/local_repo/repodata にはメタデータだけが含まれるためです。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[出力は省略されています]
Loaded plugins に続くプラグインの名前は --disableplugins=plugin_name オプションに渡すことが可能な名前である点に注意して下さい。

9.6.1. Yum プラグインを有効、設定、無効にする方法

yum プラグインを有効にするには、plugins= で始まる行が /etc/yum.conf[main] セクションにあり、値が 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 plugins の行の後に表示されている名前と同じです。複数のプラグインを無効にするには、名前をコンマで区切ります。さらに 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 オプションとともに実行された場合、または assumeyes ディレクティブが /etc/yum.conf で有効な場合は、プラグインが確認を要求せずに無効なリポジトリーを一時的および永久的に有効にします。この結果、有効にしたくないリポジトリーが有効になるといった問題が発生することがあります。
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=valueenforcing モードを有効または無効にできます。value1 (有効) または 0 (無効) にする必要があります。デフォルトでは、このオプションはコメントアウトされ kabi プラグインは警告メッセージのみを表示します。
product-id (subscription-manager)
product-id プラグインは、Content Delivery Network (コンテンツ配信ネットワーク) からインストールされた製品の製品識別証明書を管理します。product-id プラグインはデフォルトでインストールされています。
langpacks (yum-langpacks)
langpacks プラグインは、インストールされているすべてのパッケージ用に選択された言語のロケールパッケージを検索するために使用します。langpacks プラグインはデフォルトでインストールされます。
aliases (yum-plugin-aliases)
aliases プラグインは、yum コマンドでのエイリアスの設定および使用を可能にする alias オプションを追加します。
yum-changelog (yum-plugin-changelog)
yum-changelog プラグインは、更新の前後でパッケージ変更ログの表示を可能にする --changelog コマンドラインオプションを追加します。
yum-tmprepo (yum-plugin-tmprepo)
yum-tmprepo プラグインにより、リポジトリーファイルの URL を受け、1 回限りでこれをダウンロードして有効する --tmprepo コマンドラインオプションが追加されます。このプラグインはリポジトリーの安全な一時的使用を確保します。デフォルトでは、gpg 確認を無効にしません。
yum-verify (yum-plugin-verify)
yum-verify プラグインは、システム上の検証データを表示するための verifyverify-rpmverify-all の各コマンドラインオプションを追加します。
yum-versionlock (yum-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_from オプション、email_to オプション、email_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 カスタマーポータルラボ: Red Hat カスタマーポータルラボに 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 units という概念が導入されています。これらの unit は 表10.2「Systemd Unit ファイルの場所」 にあるディレクトリーの 1 つに置かれる unit 設定ファイルで表示され、システムサービスやリスニングソケット、init システムに関連するその他のオブジェクトに関する情報を要約します。利用可能な systemd unit タイプの完全な一覧は表10.1「利用可能な systemd Unit タイプ」を参照してください。

表10.1 利用可能な systemd Unit タイプ

Unit タイプファイル拡張子詳細
Service unit.serviceシステムサービス
Target unit.targetsystemd unit のグループ
Automount unit.automountファイルシステムの自動マウントポイント
Device unit.deviceカーネルが認識するデバイスファイル
Mount unit.mountファイルシステムのマウントポイント
Path unit.pathファイルシステム内のファイルまたはディレクトリー
Scope unit.scope外部作成のプロセス
Slice unit.sliceシステムプロセスを管理する階層的に組織された unit グループ
Snapshot unit.snapshotsystemd マネージャーの保存状態
Socket unit.socketプロセス間の通信ソケット
Swap unit.swapスワップデバイスまたはスワップファイル
Timer unit.timersystemd タイマー

表10.2 Systemd Unit ファイルの場所

ディレクトリー詳細
/usr/lib/systemd/system/インストール済みの RPM パッケージで配布された systemd unit ファイル
/run/systemd/system/ランタイム時に作成された systemd unit ファイル。このディレクトリーは、インストール済みのサービス unit ファイルのディレクトリーに優先します。
/etc/systemd/system/systemctl enable で作成された systemd unit ファイルおよびサービス拡張向けに追加された unit ファイル。このディレクトリーは、runtime unit ファイルのディレクトリーに優先します。

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

10.1.2. 互換性の変更点

systemd システムおよびサービスマネージャーは、SysV init および Upstart とほぼ互換するように設計されています。以下では、Red Hat Enterprise Linux システムの以前のメジャーリリースとの比較で最も顕著な互換性の変更点を挙げています。
  • Systemd のランレベルのサポートは限定的なものです。ランレベルに直接マッピング可能なターゲットユニットを数多く提供し、互換性のために以前の runlevel コマンドで配布されます。ただし、systemd ターゲットのすべてがランレベルに直接マッピング可能な訳ではないため、このコマンドが不明なランレベルを示す N を返す場合もあります。可能な場合は、runlevel コマンドの使用を避けることが推奨されます。
    systemd ターゲットとそれらのランレベルとの比較に関する詳細は、「systemd ターゲットでの作業」 を参照してください。
  • systemctl ユーティリティーは、カスタマイズされたコマンドをサポートしません。SysV init スクリプでは、startstop、および status といった標準のコマンドに加えて、任意のコマンドサポートを実装して数多くの機能を提供できます。たとえば、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 の後に、その名前が続きます。
Status対応するシステムサービスに関する追加情報。
Process関連プロセスに関する追加情報。
CGroup関連する Control Group (cgroups) に関する追加情報。
特定のサービスユニットが実行中かどうかだけを確認する場合は、以下のコマンドを実行します。
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[出力は省略されています]

例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 Server のサービスユニット名は 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 サービスを実行しようとすると、最初に systemdpostfix を自動的に停止させます。これら 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 ターゲットの比較

ランレベルターゲットユニット詳細
0runlevel0.targetpoweroff.targetシステムをシャットダウンし、電源を切ります。
1runlevel1.targetrescue.targetレスキューシェルを設定します。
2runlevel2.targetmulti-user.target非グラフィカルな複数ユーザーシステムを設定します。
3runlevel3.targetmulti-user.target非グラフィカルな複数ユーザーシステムを設定します。
4runlevel4.targetmulti-user.target非グラフィカルな複数ユーザーシステムを設定します。
5runlevel5.targetgraphical.targetグラフィカルな複数ユーザーシステムを設定します。
6runlevel6.targetreboot.targetシステムをシャットダウンして再起動します。
systemd ターゲットを表示、変更、または設定するには、表10.7「SysV init コマンドと systemctl の比較」 および以下のセクションでの説明通りに systemctl ユーティリティーを使用します。runlevel および telinit の各コマンドはシステムで利用可能なままで、期待どおりに機能しますが、これらが含まれているのは互換性が目的であり、使用は避けてください。

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

古いコマンド新しいコマンド詳細
runlevelsystemctl list-units --type target現在読み込まれているターゲットユニットを表示します。
telinit runlevelsystemctl 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 では、レスキューモードは シングルユーザーモード と同等であり、root パスワードを必要とします。
現在のターゲットを変更し、現行セッションでレスキューモードに入るには、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 の比較

古いコマンド新しいコマンド詳細
haltsystemctl haltシステムを停止します。
poweroffsystemctl poweroffシステムの電源を切ります。
rebootsystemctl rebootシステムを再起動します。
pm-suspendsystemctl suspendシステムをサスペンドします。
pm-hibernatesystemctl hibernateシステムを休止状態にします。
pm-suspend-hybridsystemctl 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 ファイルが作成されます。time 引数が使用される場合は、オプションのメッセージである ウォールメッセージ をコマンドに追加することができます。
マシンの電源を切らずにシステムを一定の遅延後にシャットダウンし、停止するには、root で以下のフォーマットでコマンドを使用します。
shutdown --halt +m
ここで、+m は遅延時間 (分単位) です。now キーワードは +0 のエイリアスです。
保留中のシャットダウンは、以下のように root ユーザーでキャンセルできます。
shutdown -c
追加のコマンドオプションについては、man ページの shutdown(8) を参照してください。

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 Unit ファイルの場所」 は、システム上のユニットファイルが保存される 3 つのメインディレクトリーを一覧表示し、/etc/systemd/system/ ディレクトリーは、システム管理者が作成するか、またはカスタマイズするユニットファイル用に予約されます。
ユニットファイル名は以下のフォーマットを使用します。
unit_name.type_extension
ここで、unit_name はユニットの名前を表し、type_extension はユニットタイプを特定します。ユニットタイプの詳細な一覧は、表10.1「利用可能な systemd Unit タイプ」 を参照してください。たとえば、通常システムには 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]詳細
Descriptionユニットの分かりやすい説明です。このテキストは、たとえば systemctl status コマンドの出力に表示されます。
Documentationユニットのドキュメントを参照する URI の一覧を提供します。
After[b]ユニットが開始する順序を定義します。ユニットは、After で指定されたユニットがアクティブにされた後にのみ開始されます。Requires とは異なり、After は指定されたユニットを明示的にアクティブ化しません。Before オプションには、After とは反対の機能があります。
Requires他のユニットに依存関係を設定します。Requires に一覧表示されるユニットは、該当ユニットと共にアクティブになります。必要なユニットのいずれかが開始しないと、ユニットはアクティブになりません。
WantsRequires よりも強度の弱い依存関係を設定します。一覧表示されるユニットのいずれかが正常に開始しない場合も、ユニットのアクティべーションには影響を与えません。これは、カスタムのユニット依存関係を設定する際に推奨される方法です。
ConflictsRequires とは反対の、負の依存関係を設定します。
[a] [Unit] セクションで設定可能なオプションの詳細な一覧は、man ページの systemd.unit(5) を参照してください。
[b] ほとんどの場合、After および Before のユニットファイルオプションで依存関係の並び順を設定するだけで十分です。Wants (推奨) または Requires で要件の依存関係も設定する場合、依存関係の並び順は指定する必要があります。これは、並び順と要件の依存関係が相互に依存していないためです。

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

オプション[a]詳細
TypeExecStart および関連オプションの機能に影響を与えるユニットプロセスの起動タイプを設定します。以下のいずれかになります。
  • 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 コマンドによる完全な停止の例外により、そのプロセスの終了後にサービスが再起動します。
RemainAfterExitTrue に設定すると、サービスは、そのプロセスがすべて終了していてもアクティブと見なされます。デフォルトの値は False です。このオプションは、Type=oneshot が設定されている場合にとくに役に立ちます。
[a] [Service] セクションで設定可能なオプションの詳細な一覧は、man ページの systemd.service(5) を参照してください。

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

オプション[a]詳細
Aliasユニット名の追加一覧を、スペース区切りで提供します。systemctl enable を除くほとんどの systemctl コマンドでは、実際のユニット名の代わりにエイリアスを使用できます。
RequiredBy該当ユニットに依存するユニットの一覧です。このユニットが有効な場合、RequiredBy に一覧表示されるユニットは、このユニットに関する Require 依存関係を取得します。
WantedBy該当ユニットに弱く依存するユニットの一覧です。このユニットが有効な場合、WantedBy に一覧表示されるユニットは、このユニットに関する Want 依存関係を取得します。
Also該当ユニットと共にインストールまたはアンインストールされるユニットの一覧を指定します。
DefaultInstanceインスタンス化されたユニットに制限された状態で、このオプションは、ユニットが有効にされているデフォルトインスタンスを指定します。「インスタンス化されたユニットの使用」 を参照してください。
[a] [Install] セクションで設定可能なオプションの詳細な一覧は、man ページの systemd.unit(5) を参照してください。
ユニット設定を微調整するのに使用できる様々なオプションがあります。例10.17「postfix.service ユニットファイル」 は、システムにインストールされたサービスユニットの例を示しています。さらに、ユニットファイルのオプションは、「インスタンス化されたユニットの使用」 に説明されているようにユニットの動的な作成が可能な方法で定義できます。

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

次に、postfix パッケージで現在提供されている /usr/lib/systemd/system/postifix.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 つ目のインスタンスの作成」 に説明されているように) 一部の既存サービスの 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 で以下のコマンドを実行して、systemd に対して、新規の name.service ファイルが存在することを通知します。
    systemctl daemon-reload
    systemctl start name.service

    警告

    新規のユニットファイルの作成または既存のユニットファイルの変更後に常に systemctl daemon-reload コマンドを実行します。実行しないと、systemctl start コマンドまたは systemctl enable コマンドは、systemd の状態と、ディスク上の実際のサービスユニットファイルの状態の間にある不一致により失敗する可能性があります。
    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. 1 つ前のステップで作成された 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. -f /etc/ssh/sshd-second_config パラメーターを sshd コマンドに追加し、代替の設定ファイルが使用されるようにします。
      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 番目のインスタンスへの接続を許可するために、それが適切に設定されていることを確認してください。
カスタムユニットファイルの並び順および依存関係のターゲットを適切に選択する方法は、以下の記事を参照してください。
ユニットファイルの並び順および依存関係にトリガーされたケースの実例の一部と追加情報は、「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 スクリプトはサンプルとして使用されます。例10.17「postfix.service ユニットファイル」 で作成される postfix ユニットを参照してください。

サービス説明の検索

#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-StartRequired-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 は事前に定義されたアクションのみをサポートしますが、オプションの ExecStartExecStartPreExecStartPostExecStop、および ExecReload でカスタム実行可能ファイルを実行できます。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 サービスの設定を拡張するときは、/etc/rc.d/init.d/network init スクリプトファイルは変更せず、代わりに新しいディレクトリー /etc/systemd/system/network.service.d/systemd ドロップインファイル /etc/systemd/system/network.service.d/my_config conf を作成します。そして変更した値をドロップインファイルに入力します。注記: systemdnetwork サービスを 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/ のユニットファイルに優先します。そのため、設定ファイルに Description または ExecStart などの 1 回のみ指定できるオプションが含まれる場合は、このオプションのデフォルト値が上書きされます。「上書きされたユニットのモニタリング」 で説明されているように、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] セクションに TimeoutStartUSec 値を指定します。
    ...
    [Service]...
    PrivateTmp=true
    TimeoutStartSec=10
    
    [Install]
    WantedBy=multi-user.target...
  3. systemd デーモンを再読み込みします。
    systemctl daemon-reload
  4. オプション。新しいタイムアウト値を検証します。
    systemctl show httpd -p TimeoutStartUSec

注記

タイムアウト値をグローバルに変更するには、DefaultTimeoutStartSec/etc/systemd/system.conf ファイルに入力します。「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 の相違タイプ

タイプ詳細
[MASKED]
マスクされたユニットファイルです。ユニットのマスクについての説明は 「サービスの無効化」 を参照してください。
[EQUIVALENT]
元のファイルを上書きしますが、コンテンツは変更されていないコピーです。通常はシンボリックリンクです。
[REDIRECTED]
別のファイルにリダイレクトされるファイルです。
[OVERRIDEN]
上書きされ、変更されたファイルです。
[EXTENDED]
/etc/systemd/system/unit.d/ ディレクトリーの .conf ファイルで拡張されるファイルです。
[UNCHANGED]
--type=unchanged オプションが使用される場合にのみ表示される、変更されないファイルです。
システムの更新後に、カスタム設定で上書きされているデフォルトユニットへの更新があるかどうかを確認するために systemd-delta を実行できます。さらに、出力を特定の相違タイプに制限することもできます。たとえば、上書きされたユニットのみを表示するには、以下を実行します。
systemd-delta --type=overridden

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

ランタイム時に単一の設定ファイルから複数のユニットをインスタンス化できます。「@」文字は、テンプレートにマークを付け、ユニットをこれに関連付けるために使用されます。インスタンス化されたユニットは、(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 および 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 デスクトップの移行計画、導入、設定、および管理について説明しています。logind サービスの概要とその最重要機能を挙げているほか、loginctl ユーティリティーを使用してアクティブなセッションを一覧表示し、マルチシートサポートを有効にする方法を説明しています。
  • 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 Home Page: このプロジェクトのホームページでは、systemd に関する詳細情報が提供されています。

関連項目

  • 2章システムロケールおよびキーボード設定 では、システムロケールとキーボードのレイアウトを管理する方法を説明しています。コマンドラインで localectl ユーティリティーを使用して現在のロケールを表示、利用可能なロケールを一覧表示、コマンドラインでシステムロケールを設定、現在のキーボードレイアウトを表示、利用可能なキーマップを一覧表示、そして特定のキーボードレイアウトを有効にする方法が説明されています。
  • 3章日付と時刻の設定 では、システムの日時を管理する方法を説明しています。リアルタイムクロックとシステムクロックの違いや、timedatectl ユーティリティーを使用して現在のシステムクロックの設定を表示、日時を設定、タイムゾーンを変更、およびシステムクロックをリモートサーバーと同期させる方法が説明されています。
  • 6章権限の取得 で、su および sudo コマンドを使って管理者権限を取得する方法を説明しています。
  • 12章OpenSSH は、SSH サーバーの設定方法や、クライアントユーティリティーの sshscp、および sftp を使用してこのサーバーにアクセスする方法を説明しています。
  • 22章ログファイルの表示と管理 では、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 ファイルを使用する方法は、ユーザーまたはグループをファイルに割り当てられるファイルシステムのみに適しています。

手順11.1 /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

手順11.2 /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 文字から成るドライバー識別コードを指定します。

手順11.3 点字ドライバーの設定

  • 適切な点字ドライバーを見つけるときに、自動検知機能を使用するかどうか決定します。
    1. 自動検知機能を使用する場合は braille driver をデフォルト設定の auto のままにしておきます。
      braille-driver	auto	 # autodetect

      警告

      自動検知機能はすべてのドライバーに実行されます。したがって、時間がかかったり検出に失敗したりする可能性もあります。そのため、特定の点字ドライバーに設定しておくことが推奨されます。
    2. 自動検知機能を使用しない場合は、braille-driver ディレクティブで必要な点字ドライバーの識別コードを指定してください。
      /etc/brltty.conf に記載されている一覧から、必要な点字ドライバーの識別コードを選択します。たとえば、以下のようになります。
      braille-driver	xw	 # XWindow
      複数のドライバーをコンマで区切って設定することもできます。自動検知はそれらの中で実行されます。

点字装置の設定

/etc/brltty.conf にある braille-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
複数の装置をコンマで区切って設定することもできます。それぞれの装置が順番に精査されます。

警告

装置を USB シリアルアダプターで接続している場合、braille-device から usb: への設定は動作しません。その場合は、カーネルがこのアダプター用に作成した仮想シリアル装置を指定します。仮想シリアル装置は、以下のように表示されます。
serial:ttyUSB0
実際の装置名は、以下のコマンドにより、装置プラグのカーネルメッセージから確認できます。
~]# dmesg | fgrep ttyUSB0

点字ディスプレイへ特定のパラメーターの設定

点字ディスプレイに特定のパラメーターを設定する必要がある場合は、/etc/brltty.conf にある braille-parameters ディレクティブを使用します。braille-parameters ディレクティブは、非汎用パラメーターを点字ドライバーへ渡します。/etc/brltty.conf にある一覧から必要なパラメーターを選択します。

テキストテーブルの設定

/etc/brltty.conf にある text-table ディレクティブは、記号のエンコードに使用するテキストテーブルを指定します。テキストテーブルの相対パスは /etc/brltty/Text/ ディレクトリーにあります。

手順11.4 テキストテーブルの設定

  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.conf にある contraction-table ディレクティブは、略語のエンコードに使用するテーブルを指定します。特定の contraction テーブルの相対パスは /etc/brltty/Contraction/ ディレクトリーにあります。
/etc/brltty.conf の一覧から必要な contraction-table を選択します。
たとえば、米語、グレード 2 の contraction テーブルを使用する場合は、以下のようになります。
contraction-table	en-us-g2	 # English (US, grade 2)

警告

指定しない場合、contraction テーブルは使用されません。

11.2. ユニバーサルアクセスメニューを常に表示 (Always Show Universal Access Menu) のスイッチをオン

Orca スクリーンリーダーのスイッチを入れるには、Super+Alt+S を同時に押します。するとトップバーに ユニバーサルアクセスメニュー (Universal Access Menu) アイコンが表示されます。

警告

ユーザーがユニバーサルアクセスメニュー (Universal Access Menu) にあるすべてのオプションのスイッチをオフにしていると、このアイコンは表示されません。アイコンが表示されないと、視覚障害を持つユーザーの利用に支障をきたします。システム管理者はユニバーサルアクセスメニューを常に表示 (Always Show Universal Access Menu) のスイッチをオンにすれば、アイコンが利用できない状態を防げます。ユニバーサルアクセスメニューを常に表示 (Always Show Universal Access Menu) のスイッチをオンにすると、このメニューのすべてのオプションのスイッチがオフになっていても、アイコンはトップバーに表示されます。

手順11.5 ユニバーサルアクセスメニューを常に表示 (Always Show Universal Access Menu) のスイッチをオンにする

  1. Gnome 設定メニューを開き、Universal Access をクリックします。
  2. ユニバーサルアクセスメニューを常に表示 (Always Show Universal Access Menu) のスイッチをオンにします。
  3. オプション: このメニューのすべてのオプションのスイッチがオフになっていても、ユニバーサルアクセスメニュー (Universal Access Menu) アイコンがトップバーに表示されていることを確認します。

11.3. Festival Speech Synthesis System の有効化

デフォルトでは OrcaeSpeak 音声合成装置を使用していますが、Festival Speech Synthesis System にも対応しています。eSpeakFestival Speech Synthesis System (Festival) は、異なる方法で音声を合成します。ユーザーの中にはデフォルトの eSpeak よりも Festival を好む方がいるかもしれません。Festival を有効化する手順は以下のとおりです。

手順11.6 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. 新規 festival.service ファイルが存在していることを systemd に通知します。
      ~]# 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 サーバー (openssh-server) およびクライアント (openssh-clients) パッケージが含まれています。OpenSSH パッケージでは、いくつかの重要な暗号化ライブラリーをインストールし、OpenSSH の暗号化通信を可能にする OpenSSL パッケージ (openssl-libs) が必要になる点に注意してください。

12.1. SSH プロトコル

12.1.1. SSH を使用する理由

潜在的な侵入者は、ネットワークトラフィックの中断、傍受、経路変更を可能にする様々なツールを自由に駆使して、システムに侵入します。一般的には、これらの脅威は以下のとおり分類できます。
2 システム間の通信の傍受
攻撃者は、ネットワーク上で通信を行う二者の間のどこかに潜み、両者間で渡される情報をコピーしている可能性があります。攻撃者は情報を傍受して保持する、または情報を改ざんして対象となる受信者に送信する場合があります。
このような攻撃は、通常 パケットスニファー を使用して行われます。パケットスニファーは、ネットワークを通過するパケットをキャプチャーしてその内容を分析する、ごく一般的なネットワークユーティリティーです。
特定のホストの偽装
攻撃者のシステムは、送信の対象となる受信者を装うように設定されます。これに成功すると、ユーザーのシステムは不正なホストと通信していることに気がつかないままとなります。
この攻撃は、DNS ポイズニング として知られる手法か IP スプーフィング と呼ばれる手法を用いて実行されます。前者の場合、侵入者はクラックされた DNS サーバーを使用して、クライアントシステムを不当に複製されたホストへポイントします。後者の場合は、侵入者は信頼されたホストから送信されたように見せかけた偽装ネットワークパケットを送信します。
いずれの手法でも、潜在的な機密情報を傍受することが可能です。その傍受が悪意のある理由で行われる場合には、悲惨な結果をもたらしかねません。リモートシェルログインとファイルコピー用に SSH を使用すると、こうしたセキュリティー脅威を大幅に軽減することができます。これは、SSH クライアントとサーバーがデジタル署名を使用してそれぞれの ID を確認するためです。さらに、クライアントシステムとサーバーシステム間の全通信は暗号化されます。各パケットはローカルシステムとリモートシステムのみに知られている鍵を使用して暗号化されるため、通信のいずれか一方の ID をスプーフィングする試みは成功しません。

12.1.2. 主な特長

SSH プロトコルは、以下のような保護手段を提供します。
対象のサーバーとして装うことができません
初回接続後に、クライアントは以前に接続したサーバーと同じサーバーに接続していることを確認できます。
認証情報の取得はできません
クライアントは、強力な 128 ビット暗号化を使用してサーバーへ認証情報を送信します。
通信の傍受はできません
セッション中に送受信された全データは、128 ビット暗号化を使用して転送されるため、傍受された送信データの暗号解読と読み取りは非常に困難になります。
さらに、SSH プロトコルは以下のようなオプションも提供します。
ネットワーク上でグラフィカルアプリケーションを使用するセキュアな手段を提供します
クライアントは、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 (新規) の 2 つの種類があります。Red Hat Enterprise Linux 7 の OpenSSH スイートでは、SSH バージョン 2 を使用します。バージョン 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_configsshd デーモン用の設定ファイルです。
/etc/ssh/ssh_host_ecdsa_keysshd デーモンで使用する ECDSA 秘密鍵です。
/etc/ssh/ssh_host_ecdsa_key.pubsshd デーモンで使用する ECDSA 公開鍵です。
/etc/ssh/ssh_host_rsa_keysshd デーモンにより使用される SSH プロトコルのバージョン 2 用の RSA 秘密鍵です。
/etc/ssh/ssh_host_rsa_key.pubsshd デーモンにより使用される SSH プロトコルのバージョン 2 用の RSA 公開鍵です。
/etc/pam.d/sshdsshd デーモン用の PAM 設定ファイルです。
/etc/sysconfig/sshdsshd サービスの設定ファイルです。

表12.2 ユーザー固有の設定ファイル

ファイル詳細
~/.ssh/authorized_keysサーバー用の認証済み公開鍵の一覧が含まれています。クライアントがサーバーに接続する時、サーバーはこのファイル内に格納されている署名済み公開鍵を確認してクライアントを認証します。
~/.ssh/id_ecdsaユーザーの ECDSA 秘密鍵を格納しています。
~/.ssh/id_ecdsa.pubユーザーの ECDSA 公開鍵です。
~/.ssh/id_rsassh により使用される SSH プロトコルのバージョン 2 用の RSA 秘密鍵です。
~/.ssh/id_rsa.pubssh により使用される 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 ?」を参照してください。
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 鍵のペアを生成し、パスワード認証を無効にすることで鍵ベース認証を強制します。これを行うには、/etc/ssh/sshd_config の設定ファイルを vinano などのテキストエディターで開き、PasswordAuthentication オプションを以下のように変更します。
PasswordAuthentication no
新規のデフォルトインストール以外のシステムで作業をしている場合は、PubkeyAuthentication no が設定されて いない ことを確認してください。リモートで接続している場合は、コンソールもしくは帯域外アクセスを使用せず、パスワード認証を無効にする前にプロセス内で鍵ベースのログをテストすることが推奨されます。
sshscpsftp を使用してクライアントマシンからサーバーに接続できるようにするには、以下のステップに従って認証鍵ペアを生成します。鍵はユーザーごとに別々に生成する必要がある点に注意してください。
NFS がマウントされたホームディレクトリーで鍵ベースの認証を使うには、最初に use_nfs_home_dirs SELinux ブール値を有効にします。
~]# 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 鍵フィンガープリントを取得するには、-E md5 オプションと共に ssh-keygen コマンドを使用します。
  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 パッケージがインストールされている必要があります (Red Hat Enterprise Linux に新規パッケージをインストールする方法については 「パッケージのインストール」 を参照して下さい)。

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 鍵フィンガープリントを取得するには、-E md5 オプションと共に ssh-keygen コマンドを使用します。以下に例を示します。
~]# 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リモートの 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 転送を使用すると、印刷設定 ユーティリティーのセキュアかつインタラクティブなセッションを作成できます。これを行うには、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_config にある AllowTcpForwarding の行に 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 サーバー

vncserver は、VNC (Virtual Network Computing) デスクトップを起動するユーティリティーです。適切なオプションで Xvnc が実行され、VNC デスクトップ上でウィンドウマネージャーが起動します。vncserver を使用すると、どこからでもいくつものクライアントがアクセス可能なマシン上で独立したセッションを同時に実行できます。

13.1.1. VNC サーバーのインストール

TigerVNC サーバーをインストールするには、root 権限で以下のコマンドを実行します。
~]# yum install tigervnc-server

13.1.2. VNC サーバーの設定

VNC サーバーでは、表示、ネットワークアドレス、ポート、セキュリティーの設定などに対するオプションのパラメーターを使用して、1 人または複数のユーザー用の画面を起動するよう設定できます (ユーザーのシステムがシステムに存在する場合)。

手順13.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 サーバーの起動

サービスを起動もしくは有効にするには、コマンドで直接ディスプレイ番号を指定します。手順13.1「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 ログインウィンドウにアクセスでき、システムアカウントにログインできます。セットアップの条件は gdmvncvnc-server、および xinetd パッケージがインストールされていることです。
~]# yum install gdm tigervnc tigervnc-server xinetd
サービス xinetd を有効化する必要があります。
~]# systemctl enable xinetd.service
システムのデフォルトターゲットユニットは graphical.target になっているはずです。現在設定されているデフォルトターゲットユニットを取得するには、以下を使用します。
~]# systemctl get-default
以下を使用して、デフォルトターゲットユニットを変更できます。
~]# systemctl set-default target_name

手順13.2 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 を使用してデスクトップを共有できます。

手順13.3 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 ビューアーに接続できます。

手順13.4 SSH を使用した VNC サーバーへの接続

  1. 引数なしで vncviewer コマンドを入力します。VNC Viewer: Connection Details (VNC ビューアー: 接続の詳細) ユーティリティーが表示されます。接続する VNC サーバーを指定するよう要求されます。
  2. 必要な場合は、同じ画面への既存の VNC 接続の切断を回避するために、以下のようにデスクトップの共有を許可するオプションを選択します。
    1. Options (オプション) ボタンを選択します。
    2. Misc. (その他) タブを選択します。
    3. Shared (共有) ボタンを選択します。
    4. OK を押してメインメニューに戻ります。
  3. 接続するアドレスおよびディスプレイ番号を入力します。
    address:display_number
  4. Connect (接続) を押して VNC サーバー画面に接続します。
  5. VNC パスワードを入力するよう求められます。これは、グローバルなデフォルトの VNC パスワードが設定されていない限り、ディスプレイ番号に対応するユーザーの VNC パスワードです。
    VNC サーバーデスクトップを示すウィンドウが表示されます。これは通常のユーザーに表示されるデスクトップではなく、Xvnc デスクトップであることに注意してください。

手順13.5 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 のようになります。
03 のディスプレイの場合は、以下で説明されているように service オプションを使用して VNC サービスの firewalld のサポートを使用します。ディスプレイ番号が 3 よりも大きい場合は、手順13.7「firewalld でポートを開く」 で説明されているように、対応するポートを特別に開く必要があります。

手順13.6 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
特定のポートまたはポート範囲を開くには、firewall-cmd コマンドラインツールに --add-port オプションを使用します。たとえば、VNC 画面 4 では、TCP トラフィックに対してポート 5904 を開く必要があります。

手順13.7 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 (Red Hat Enterprise Linux 7 セキュリティーガイド)』を参照してください。

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
により置き換えられます。
Private /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 設定の構文に後方互換性がない変更が含まれるため、変更が必要になります。アップグレードの詳細は Apache ドキュメント (http://httpd.apache.org/docs/2.4/upgrading.html) を参照してください。
プロセスモデル
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 モジュールインターフェース用に設定を変更し、再構築する必要があります。バージョン 2.4 における API の変更一覧は、http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html で参照できます。
ソースからのモジュール構築に使用される apxs バイナリーは、/usr/sbin/apxs から /usr/bin/apxs に移動しました。
削除されたモジュール
Red Hat Enterprise Linux 7 で削除された httpd モジュールは以下のとおりです。
mod_auth_mysql、mod_auth_pgsql
httpd 2.4 は、mod_authn_dbd モジュールで SQL データベース認証サポートを内部で提供します。
mod_perl
アップストリームの httpd 2.4 では、mod_perl が公式にサポートされていません。
mod_authz_ldap
httpd 2.4 では、mod_authnz_ldap を使用してサブパッケージ mod_ldap の LDAP サポートが提供されます。

14.1.2. 設定の更新

Apache HTTP サーバーバージョン 2.2 の設定ファイルを更新するには、以下の手順を行います。
  1. モジュールは変更されている可能性があるため、すべてのモジュール名が正しいことを確認してください。名前が変更した各モジュールの LoadModule ディレクティブを調整します。
  2. サードパーティーのモジュールは、読み込みを試みる前にすべて再コンパイルをします。これは一般的に認証と権限付与のモジュールに該当します。
  3. mod_userdir モジュールを使用する場合は、ディレクトリー名 (通常 public_html) を示す UserDir ディレクティブが指定されていることを確認します。
  4. Apache HTTP Secure Server を使用する場合は、Secure Sockets Layer (SSL) プロトコルの有効化に関する重要な情報について 「mod_ssl モジュールの有効化」 を参照してください。
以下のコマンドを使用すると、設定エラーを確認できます。
~]# apachectl configtest
Syntax OK
Apache HTTP サーバーの設定をバージョン 2.2 から 2.4 に更新する方法は http://httpd.apache.org/docs/2.4/upgrading.html を参照してください。

14.1.3. httpd サービスの実行

このセクションでは、Apache HTTP サーバーの起動、停止、再起動、および現在のステータスのチェック方法を説明します。httpd サービスを有効にするには、まず、以下のコマンドを使用して httpd がインストールされていることを確認します。
~]# yum install httpd
ターゲットの概念と Red Hat Enterprise Linux 内のシステムサービスの管理方法全般の詳細は、10章systemd によるサービス管理を参照してください。

14.1.3.1. サービスの開始

httpd サービスを実行するには、シェルプロンプトで root として以下のコマンドを入力します。
~]# systemctl start httpd.service
起動時にサービスを自動的にスタートする場合には、以下のコマンドを入力します。
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

注記

Apache HTTP サーバーをセキュアサーバーとして実行している場合は、暗号化したプライベートの SSL キーを使用すると、マシンが起動した後にパスワードが要求される可能性があります。

14.1.3.2. サービスの停止

実行中の httpd サービスを停止するには、シェルプロンプトで root として以下を入力します。
~]# systemctl stop httpd.service
ブート時にサービスが自動的に起動しないようにする場合は、以下を入力します。
~]# systemctl disable httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

14.1.3.3. サービスの再起動

実行中の httpd サービスを再起動する方法は、3 通りあります。
  1. サービスを完全に再起動するには、root で以下のコマンドを入力します。
    ~]# systemctl restart httpd.service
    これで実行中の httpd サービスが停止し、直ちに再開します。このコマンドは、PHP のような動的に読み込まれたモジュールをインストールもしくは削除した後に使用してください。
  2. 設定のリロードだけを行うには、root で以下のコマンドを入力します。
    ~]# systemctl reload httpd.service
    これで実行中の httpd サービスが設定ファイルを再読み込みします。現在処理中の要求はいずれも割り込みされるので、クライアントのブラウザーがエラーメッセージを表示したり、ページの一部のみが表示される可能性があります。
  3. アクティブな要求に影響を与えずに設定をリロードするには、root で以下のコマンドを入力します。
    ~]# apachectl graceful
    これにより、実行中の httpd サービスは設定ファイルをリロードします。現在処理中の要求は、いずれも古い設定を使用し続けます。
Red Hat Enterprise Linux 7 でシステムサービスを管理する詳細情報は10章systemd によるサービス管理を参照してください。

14.1.3.4. サービスステータスの確認

httpd サービスが実行中であることを確認するには、シェルプロンプトに以下を入力します。
~]# systemctl is-active httpd.service
active

14.1.4. 設定ファイルの編集

httpd サービスを開始すると、デフォルトで 表14.1「httpd サービスの設定ファイル」 に一覧表示してある場所から設定を読み取ります。

表14.1 httpd サービスの設定ファイル

パス詳細
/etc/httpd/conf/httpd.conf主要設定ファイル
/etc/httpd/conf.d/主要設定ファイル内に含まれている設定ファイル用の補助ディレクトリー
デフォルト設定はほとんどの状況に適していますが、重要な設定オプションをいくつか知っておくと役に立ちます。変更を有効にするには、web サーバーを再起動する必要があることに注意してください。httpd サービスを再起動する方法は「サービスの再起動」を参照してください。
設定でエラーの可能性をチェックするには、シェルプロンプトで以下を入力します。
~]# apachectl configtest
Syntax OK
ファイルの変更に失敗してもすぐにやり直せるように、ファイルを編集する前にコピーを作成しておくことをお勧めします。

14.1.5. モジュールを使った作業

モジュラーアプリケーションである httpd サービスは、必要に応じて実行時に動的にロードまたはアンロードできる複数の Dynamic Shared Objects (動的共有オブジェクト) (DSO) と一緒に配布されます。Red Hat Enterprise Linux 7 では、これらのモジュールは /usr/lib64/httpd/modules/ 内にあります。

14.1.5.1. モジュールのロード

特定の DSO モジュールをロードするには、LoadModule ディレクティブを使用します。個別のパッケージで提供されるモジュールでは多くの場合、設定ファイルが /etc/httpd/conf.d/ ディレクトリーにあることに注意してください。

例14.1 mod_ssl DSO のロード

LoadModule ssl_module modules/mod_ssl.so
操作が終了したら、Web サーバーを再起動して設定を再読み込みします。httpd サービスの再起動の方法は 「サービスの再起動」 を参照してください。

14.1.5.2. モジュールの書き込み

新たに DSO モジュールを作成する場合は、httpd-devel パッケージがインストールされていることを確認してください。確認するには、root で以下のコマンドを入力します。
~]# yum install httpd-devel
このパッケージには、モジュールをコンパイルするために必要なファイル、ヘッダーファイル、および APache eXtenSion (apxs) ユーティリティーが含まれています。
書き込みが終了したら、以下のコマンドでモジュールをビルドできます。
~]# apxs -i -a -c module_name.c
ビルドが成功すると、Apache HTTP サーバーで配布されている他のモジュールと同じようにこのモジュールをロードできるようになります。

14.1.6. 仮想ホストのセットアップ

Apache HTTP サーバーに組み込まれている仮想ホストにより、サーバーは要求される IP アドレス、ホスト名、またはポートに基づいて異なる情報を提供できます。
名前ベースの仮想ホストを作成するには、まず設定ファイルの例である /usr/share/doc/httpd-VERSION/httpd-vhosts.conf/etc/httpd/conf.d/ ディレクトリーにコピーし、@@Port@@@@ServerRoot@@ のプレースホルダーの値を置き換えます。例14.2「仮想ホスト設定のサンプル」 にあるように、実際の要件に合わせてオプションをカスタマイズします。

例14.2 仮想ホスト設定のサンプル

<VirtualHost *:80>
    ServerAdmin webmaster@penguin.example.com
    DocumentRoot "/www/docs/penguin.example.com"
    ServerName penguin.example.com
    ServerAlias www.penguin.example.com
    ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
    CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common
</VirtualHost>
ServerName は、マシンに割り当てられている有効な DNS 名にする必要があります。<VirtualHost> コンテナーは高度にカスタマイズが可能で、メインサーバー設定内で利用できるほとんどのディレクティブを受け付けます。このコンテナー内でサポートされていないディレクティブには UserGroup があり、これらは SuexecUserGroup に置き換えられています。

注記

仮想ホストがデフォルト以外のポートでリッスンするように設定する場合は、/etc/httpd/conf/httpd.conf ファイルのグローバル設定で Listen ディレクティブを適切に更新することを忘れないでください。
新規に作成された仮想ホストをアクティブ化するには、Web サーバーを再起動する必要があります。httpd サービスを再起動する方法は 「サービスの再起動」 を参照してください。

14.1.7. SSL サーバーのセットアップ

Secure Sockets Layer (セキュアソケットレイヤー) (SSL) は暗号化プロトコルであり、サーバーとクライアント間の安全な通信を可能にします。その拡張および改善バージョンである Transport Layer Security (トランスポートレイヤーセキュリティ) (TLS) と共に、SSL はプライバシーとデータの整合性を保証します。Apache HTTP Server は、SSL/TLS サポートを提供するために OpenSSL ツールキットを使用するモジュールである mod_ssl と共に、一般的に SSL サーバーと呼ばれます。また、Red Hat Enterprise Linux は、TLS 実装としての Mozilla NSS の使用をサポートします。Mozilla NSS のサポートは mod_nss モジュールにより提供されます。
傍受できる人は誰でも読み取りと修正が可能な HTTP 接続とは異なり、HTTP を介した SSL/TLS (HTTPS と呼ばれます) を使用すると、送信されたコンテンツの検査や修正を阻止できます。本セクションでは、Apache HTTP Server 設定内でこのモジュールを有効にする基本的な方法と、秘密鍵と自己署名の証明書の生成プロセスを説明します。

14.1.7.1. 証明書とセキュリティーの概要

安全な通信は鍵の使用に基づいています。従来の symmetric cryptography (対称型暗号化) では、トランザクションの両側に、互いの通信の解読に使用できる同一の鍵があります。それに対し、パブリックの asymmetric cryptography (非対称型暗号化) では、2 つの鍵が共存します。秘密鍵 は秘密として守られ、公開鍵 は通常、一般に公開されます。公開鍵でエンコードされたデータは秘密鍵でのみデコードされるのに対し、秘密鍵でエンコードされたデータは逆に公開鍵でのみデコードできます。
SSL を使用して安全な通信を提供するためには、SSL サーバーは Certificate Authority (CA) (認証局) で署名された電子証明書を使用する必要があります。証明書はサーバーの様々な属性 (サーバーのホスト名、企業の名前、その住所など) と CA の秘密鍵で生成した署名を一覧表示します。この署名は、特定の認証局が証明書に署名したこと、また証明書がいかなる方法でも修正されていないことを保証するものです。
Web ブラウザーは新規の SSL 接続を確立する際に、Web サーバーから提供される証明書をチェックします。証明書に信頼できる CA からの署名がない場合や、証明書に表記してあるホスト名が接続確立で使用されたホスト名と一致しない場合、Web ブラウザーはそのサーバーとの交信を拒否し、通常はユーザーに適切なエラーメッセージを表示します。
デフォルトでは、ほとんどの Web ブラウザーが広く使用されている認証局のグループを信用するように設定されています。そのため、セキュアサーバーをセットアップする時には適切な CA (認証局) を選択する必要があります。そうすることで、対象ユーザーは接続を信頼できますが、そうでない場合はエラーメッセージが表示され、手動で証明書を承認する必要があります。証明書のエラーメッセージを無視するようにユーザーに推奨することは攻撃者の侵略を許すことにつながるので、できる限り信頼できる CA を使用してください。詳細は 表14.2「一般的な Web ブラウザーで使用される CA 一覧に関する情報」 を参照してください。

表14.2 一般的な Web ブラウザーで使用される CA 一覧に関する情報

SSL サーバーをセットアップする際には、証明書要求と秘密鍵を生成してから、証明書要求と企業の識別証明と支払いを認証局に送ります。認証局は証明書要求と識別を確認すると、サーバーで使用できる署名付きの証明書を送ってきます。その他の方法として、CA 署名のない自己署名の証明書を作成することができますが、これはテスト目的にのみ使用してください。

14.1.8. mod_ssl モジュールの有効化

mod_ssl を使用して SSL または HTTPS サーバーをセットアップする場合は、別のアプリケーションまたはモジュール (mod_nss など) で同じポートを使用するよう設定できません。HTTPS のデフォルトポートはポート 443 です。
mod_ssl モジュールと OpenSSL ツールキットを使用して SSL サーバーをセットアップするには、mod_ssl および openssl パッケージをインストールします。root で以下のコマンドを入力します。
~]# yum install mod_ssl openssl
これにより、中心となる Apache HTTP サーバー設定ファイルにデフォルトで含まれている /etc/httpd/conf.d/ssl.confmod_ssl 設定ファイルが作成されます。このモジュールを読み込むには、「サービスの再起動」 の記載通りに httpd サービスを再起動します。

重要

POODLE: SSLv3 脆弱性 (CVE-2014-3566)』 で示された脆弱性のため、Red Hat は、SSL を無効にし、TLSv1.1 または TLSv1.2 のみを使用することを推奨します。後方互換性は、TLSv1.0 を使用して実現できます。Red Hat がサポートする多くの製品は SSLv2 または SSLv3 プロトコルを使用するか、デフォルトでそれらのプロトコルを有効にできます。ただし、SSLv2 または SSLv3 を使用することが強く推奨されます。

14.1.8.1. mod_ssl での SSL および TLS の有効化および無効化

SSL および TLS プロトコルの特定のバージョンを有効および無効にするには、設定ファイルの ## SSL Global Context セクションに SSLProtocol ディレクティブを追加し、他のすべての部分でそのディレクティブを削除するか、すべての VirtualHost セクションの # SSL Protocol support の下にあるデフォルトエントリーを編集することによりグローバルで設定します。ドメインごとの VirtualHost セクションで指定しない場合、設定はグローバルセクションから継承されます。プロトコルバージョンが確実に無効になるように、管理者は SSLProtocol を、SSL Global Context セクションにのみ指定するか、ドメインごとのすべての VirtualHost セクションで指定する必要があります。

手順14.1 SSLv2 および SSLv3 の無効化

すべての VirtualHost セクションで SSL バージョン 2 および SSL バージョン 3 を無効にするには (SSL バージョン 2 および SSL バージョン 3 以外をすべて有効にすることを意味します)、以下の手順を実行します。
  1. root/etc/httpd/conf.d/ssl.conf ファイルを開き、SSLProtocol ディレクティブのすべてのインスタンスを検索します。デフォルトでは、設定ファイルに以下のような 1 つのセクションが含まれます。
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
    このセクションは、VirtualHost セクション内にあります。
  2. SSLProtocol 行を以下のように編集します。
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2 -SSLv3
    すべての VirtualHost セクションに対してこのアクションを繰り返します。ファイルを保存し、閉じます。
  3. すべての SSLProtocol ディレクティブが以下のように変更されたことを確認します。
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf
    SSLProtocol all -SSLv2 -SSLv3
    この手順は、デフォルトの VirtualHost セクションが複数の場合に特に重要になります。
  4. Apache デーモンを以下のように再起動します。
    ~]# systemctl restart httpd
    すべてのセッションが中断されることに注意してください。

手順14.2 TLS 1 以上を除くすべての SSL および TLS プロトコルの無効化

TLS バージョン 1 以上を除く SSL および TLS プロトコルバージョンをすべて無効にするには、以下の手順を実行します。
  1. root/etc/httpd/conf.d/ssl.conf ファイルを開き、SSLProtocol ディレクティブのすべてのインスタンスを検索します。デフォルトでは、設定ファイルに以下のような 1 つのセクションが含まれます。
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
  2. SSLProtocol 行を以下のように編集します。
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
    ファイルを保存してから閉じます。
  3. 以下のように変更を確認します。
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf 
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
  4. Apache デーモンを以下のように再起動します。
    ~]# systemctl restart httpd
    すべてのセッションが中断されることに注意してください。

手順14.3 SSL および TLS プロトコルのステータスのテスト

有効または無効な SSL および TLS のバージョンを確認するには、openssl s_client -connect コマンドを使用します。コマンドの形式は以下のようになります。
openssl s_client -connect hostname:port -protocol
ここで、port はテストするポートであり、protocol はテストするプロトコルバージョンです。ローカルで実行されている SSL サーバーをテストするには、ホスト名として localhost を使用します。たとえば、SSLv3 が有効であるかどうかを確認するためにセキュアな HTTPS 接続のデフォルトポートであるポート 443 をテストするには、以下のようにコマンドを発行します。
  1. ~]# openssl s_client -connect localhost:443 -ssl3
    CONNECTED(00000003)
    139809943877536:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
    139809943877536:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:出力省略
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : SSLv3output truncated
    上記の出力は、ハンドシェイクが失敗し、暗号化がネゴシエートされなかったことを示しています。
  2. ~]$ openssl s_client -connect localhost:443 -tls1_2
    CONNECTED(00000003)
    depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = localhost.localdomain, emailAddress = root@localhost.localdomain出力省略
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1.2output truncated
    上記の出力は、ハンドシェイクが失敗せず、暗号化セットがネゴシエートされたことを示しています。
openssl s_client コマンドオプションは、man ページの s_client(1) で文書化されています。
SSLv3 の脆弱性とそのテスト方法の詳細は、Red Hat ナレッジベースの記事 『POODLE: SSLv3 脆弱性 (CVE-2014-3566)』 を参照してください。

14.1.9. mod_nss Module の有効化

mod_nss を使用して HTTPS サーバーをセットアップする場合は、mod_ssl がデフォルトで 443 (デフォルトの HTTPS ポート) を使用するため、mod_ssl パッケージをデフォルト設定でインストールできません。可能な限り、このパッケージを削除します。
mod_ssl を削除するには、root で以下のコマンドを入力します。
~]# yum remove mod_ssl

注記

他の目的のために mod_ssl が必要な場合は、443 以外のポートを使用するよう /etc/httpd/conf.d/ssl.conf を変更して、リッスンするポートが 443 に変更されたときに mod_sslmod_nss が競合しないようにします。
1 つのポートを所有できるモジュールは 1 つだけです。したがって、mod_nssmod_ssl は、異なるポートを使用する場合のみ共存できます。このため、mod_nss はデフォルトで 8443 を使用しますが、HTTPS のデフォルトポートはポート 443 です。ポートは Listen ディレクティブと VirtualHost 名またはアドレスで指定されます。
NSS のすべてはトークンに関連付けられます。ソフトウェアトークンは NSS データベースに存在しますが、証明書を含む物理トークンを使用することもできます。OpenSSL では、個別証明書と秘密鍵は PEM ファイルに保持されます。NSS では、これらはデータベースに格納されます。各証明書およびキーはトークンと関連付けられ、各トークンにはパスワードを設定して保護することもできます。このパスワードはオプションですが、パスワードが使用される場合、Apache HTTP サーバーはシステムの起動時にユーザーの介入なしでデータベースを開くためにパスワードのコピーを必要とします。

手順14.4 mod_nss の設定

  1. rootmod_nss をインストールします。
    ~]# yum install mod_nss
    これにより、/etc/httpd/conf.d/nss.confmod_nss 設定ファイルが作成されます。/etc/httpd/conf.d/ ディレクトリーは、デフォルトでメインの Apache HTTP Server 設定ファイルに含まれます。モジュールをロードするには、「サービスの再起動」 の説明通りに httpd サービスを再起動します。
  2. root/etc/httpd/conf.d/nss.conf ファイルを開き、Listen ディレクティブのすべてのインスタンスを検索します。
    Listen 8443 行を以下のように編集します。
    Listen 443
    ポート 443HTTPS のデフォルトポートです。
  3. デフォルトの VirtualHost _default_:8443 行を以下のように編集します。
    VirtualHost _default_:443
    デフォルト以外の他のすべての仮想ホストセクション (存在する場合) を編集します。ファイルを保存し、閉じます。
  4. Mozilla NSS では、証明書は/etc/httpd/conf.d/nss.conf ファイルの NSSCertificateDatabase ディレクティブで指定されたサーバー証明書データベースに保存されます。デフォルトでは、パスはインストール時に作成された NSS データベースである /etc/httpd/alias に設定されます。
    デフォルトの NSS データベースを表示するには、以下のコマンドを実行します。
    ~]# certutil -L -d /etc/httpd/alias
    
    Certificate Nickname                                         Trust Attributes
                                                                 SSL,S/MIME,JAR/XPI
    
    cacert                                                       CTu,Cu,Cu
    Server-Cert                                                  u,u,u
    alpha                                                        u,pu,u
    上記のコマンド出力で、Server-Cert はデフォルトの NSSNickname です。-L オプションは、証明書データベース内のすべての証明書を一覧表示するか、指定された証明書に関する情報を表示します。-d オプションは、証明書およびキーデータベースファイルを含むデータベースディレクトリーを指定します。その他のコマンドラインオプションは、man ページの certutil(1) を参照してください。
  5. 別のデータベースを使用するよう mod_nss を設定するには、/etc/httpd/conf.d/nss.conf ファイルの NSSCertificateDatabase 行を編集します。デフォルトファイルの VirtualHost セクション内には以下の行が含まれます。
    #   Server Certificate Database:
    #   The NSS security database directory that holds the certificates and
    #   keys. The database consists of 3 files: cert8.db, key3.db and secmod.db.
    #   Provide the directory that these files exist.
    NSSCertificateDatabase /etc/httpd/alias
    上記のコマンド出力で、alias はデフォルトの NSS データベースディレクトリーである /etc/httpd/alias/ です。
  6. デフォルトの NSS 証明書データベースにパスワードを適用するには、root で以下のコマンドを使用します。
    ~]# certutil -W -d /etc/httpd/alias
    Enter Password or Pin for "NSS Certificate DB":
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
    Password changed successfully.
  7. HTTPS サーバーをデプロイする前に、認証局 (CA) により署名された証明書を使用して新しい証明書データベースを作成します。

    例14.3 Mozilla NSS データベースへの証明書の追加

    certutil コマンドは、CA 証明書を NSS データベースファイルに追加するために使用されます。
    certutil -d /etc/httpd/nss-db-directory/ -A -n "CA_certificate" -t CT,, -a -i certificate.pem
    上記のコマンドは、certificate.pem という名前の PEM 形式のファイル に保存されている CA 証明書を追加します。-d オプションは証明書およびキーデータベースファイルを含む NSS データベースディレクトリーを指定し、-n オプションは証明書の名前を設定します。-t CT,, は、証明書が TLS クライアントおよびサーバーでの使用に信頼できることを意味します。-A オプションは既存の証明書を証明書データベースに追加します。データベースは、存在しない場合は作成されます。-a オプションは出入力での ASCII 形式の使用を可能にします。-i オプションは、certificate.pem 入力ファイルをコマンドに渡します。
    その他のコマンドラインオプションは、man