Product SiteDocumentation Site

Fedora 16

システム管理者ガイド

Fedora 16 の導入、設定および管理

エディッション 1

Hradílek Jaromír [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Silas Douglas [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Prpič Martin [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Kopalová Eva [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Slobodová Eliška [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Čapek Tomáš [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Kovář Petr [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Svoboda Miroslav [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Ha John [FAMILY Given]

Red Hat, Inc. Engineering Content Services

O'Brien David [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Hideo Michael [FAMILY Given]

Red Hat, Inc. Engineering Content Services

Domingo Don [FAMILY Given]

Red Hat, Inc. Engineering Content Services

法律上の通知

Copyright © 2011 Red Hat, Inc. and others.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.
概要
システム管理者ガイドは、Fedora 16 の導入、設定および管理に関連する情報をドキュメント化しています。システムの基本的な理解をしているシステム管理者向けになっています。

序文
1. 対象の読者
2. この本の読み方
3. 表記方法
3.1. 印刷における表記方法
3.2. 引用における表記方法
3.3. 注記および警告
4. Feedback
5. Acknowledgments
I. 基本的なシステム設定
1. 言語とキーボードの設定
1.1. 言語の変更
1.2. 日付、時刻および数字の形式の変更
1.3. キーボードのレイアウト変更
1.4. 現在の設定の表示
2. 日付と時刻の設定
2.1. 日付と時刻の設定ツールの使い方
2.2. コマンドラインツールの使用
2.2.1. 日付の変更方法
2.2.2. 時刻の変更方法
2.2.3. Network Time Protocol の設定
2.3. その他のリソース
2.3.1. インストールされているドキュメント
3. ユーザーとグループの管理
3.1. ユーザーとグループのイントロダクション
3.1.1. ユーザープライベートグループ
3.1.2. シャドウパスワード
3.2. ユーザー アカウントのツールを使う
3.2.1. アカウントの設定
3.2.2. 新規ユーザーを追加する
3.2.3. ユーザーの削除
3.3. ユーザー管理のツールを使う
3.3.1. ユーザーとグループを閲覧する
3.3.2. 新規ユーザーを追加する
3.3.3. 新規グループを追加する
3.3.4. ユーザーのプロパティを変更する
3.3.5. グループのプロパティを変更する
3.4. コマンドラインのツールを使う
3.4.1. 新規ユーザーを追加する
3.4.2. 新規グループを追加する
3.4.3. パスワードエージングの有効化
3.4.4. 自動ログアウトの有効化
3.4.5. グループ用ディレクトリーの作成
3.5. その他のリソース
3.5.1. インストールされているドキュメント
II. パッケージ管理
4. Yum
4.1. パッケージの確認と更新
4.1.1. 更新の確認
4.1.2. パッケージの更新
4.1.3. 設定ファイル変更の保存
4.2. パッケージとパッケージ グループ
4.2.1. パッケージの検索
4.2.2. パッケージの一覧
4.2.3. パッケージ情報の表示
4.2.4. パッケージのインストール
4.2.5. パッケージの削除
4.2.6. 処理とトランザクションの履歴
4.3. Yum と Yum リポジトリーの設定
4.3.1. [main] オプションの設定
4.3.2. [repository] オプションの設定
4.3.3. Yum 変数の使い方
4.3.4. 現在の設定の表示
4.3.5. Yum リポジトリの追加・有効化および無効化
4.3.6. Yum リポジトリーの作成
4.4. Yum プラグイン
4.4.1. Yum プラグインの無効化、有効化、設定
4.4.2. 追加の Yum プラグインのインストール
4.4.3. プラグインの説明
4.5. その他のリソース
5. PackageKit
5.1. ソフトウェアの更新を用いたパッケージの更新
5.1.1. 更新の確認間隔の設定
5.1.2. ソフトウェアソースの設定
5.2. ソフトウェアの追加/削除の使用
5.2.1. ソフトウェアソースの更新 (Yum リポジトリー)
5.2.2. フィルターを用いたパッケージの検索
5.2.3. パッケージ(および依存するもの)のインストールおよび削除
5.2.4. パッケージグループのインストールおよび削除
5.2.5. トランザクションログの表示
5.3. PackageKit アーキテクチャー
5.4. その他のリソース
III. ネットワーク
6. ネットワーク・インターフェース
6.1. ネットワーク設定ファイル
6.2. インターフェース設定ファイル
6.2.1. イーサネット インターフェース
6.2.2. チャンネル・ボンディング・インターフェース
6.2.3. エイリアス ファイルとクローン ファイル
6.2.4. ダイヤルアップ インターフェース
6.2.5. 他のインターフェース
6.3. インターフェース制御スクリプト
6.4. スタティック ルートの設定
6.5. ネットワーク機能ファイル
6.6. その他のリソース
6.6.1. インストールされているドキュメント
IV. インフラストラクチャーサービス
7. サービスおよびデーモン
7.1. サービスの設定
7.1.1. サービスの有効化
7.1.2. サービスの無効化
7.2. サービスの実行
7.2.1. サービスの状態の確認
7.2.2. サービスの実行
7.2.3. サービスの停止
7.2.4. サービスの再起動
7.3. その他のリソース
7.3.1. インストールされているドキュメント
7.3.2. 関連書籍
8. 認証の設定
8.1. 認証の設定ツール
8.1.1. 識別と認証
8.1.2. 高度なオプション
8.1.3. コマンドライン版
8.2. The System Security Services Daemon (SSSD)
8.2.1. What is SSSD?
8.2.2. SSSD Features
8.2.3. Setting Up SSSD
8.2.4. Configuring Services
8.2.5. Configuring Domains
8.2.6. Setting Up Kerberos Authentication
8.2.7. Configuring a Proxy Domain
8.2.8. Troubleshooting
8.2.9. SSSD Configuration File Format
9. OpenSSH
9.1. SSH プロトコル
9.1.1. なぜ SSH を使うのか?
9.1.2. 主な機能
9.1.3. プロトコル・バージョン
9.1.4. SSH コネクションのイベント・シーケンス
9.2. OpenSSH の設定
9.2.1. 設定ファイル
9.2.2. OpenSSH サーバーの起動
9.2.3. リモート接続に対する SSH の要求
9.2.4. キー認証の使用
9.3. OpenSSH クライアント
9.3.1. ssh ユーティリティの使用方法
9.3.2. scp ユーティリティの使用方法
9.3.3. sftp ユーティリティの使用方法
9.4. 安全なシェル以上のもの
9.4.1. X11 転送
9.4.2. ポート転送
9.5. 追加のリソース
9.5.1. インストールされているドキュメント
9.5.2. 役に立つ Web サイト
V. サーバー
10. DHCP サーバー
10.1. DHCP を使用する理由
10.2. DHCP サーバーの設定
10.2.1. 設定ファイル
10.2.2. リースデータベース
10.2.3. サーバーの起動と停止
10.2.4. DHCP リレーエージェント
10.3. DHCP クライアントの設定
10.4. Configuring a Multihomed DHCP Server
10.4.1. ホストの設定
10.5. IPv6 向け DHCP (DHCPv6)
10.6. その他のリソース
10.6.1. インストールされているドキュメント
11. DNS サーバー
11.1. DNS の概要
11.1.1. ネームサーバーゾーン
11.1.2. ネームサーバーのタイプ
11.1.3. ネームサーバーとしての BIND
11.2. BIND
11.2.1. named サービスの設定
11.2.2. ゾーンファイルの編集
11.2.3. rndc ユーティリティの使用法
11.2.4. dig ユーティリティの使用
11.2.5. BIND の高度な機能
11.2.6. よくある間違いを避けるために
11.2.7. その他のリソース
12. ウェブ サーバー
12.1. Apache HTTP サーバー
12.1.1. 新機能
12.1.2. 注目すべき変更
12.1.3. 設定の更新
12.1.4. httpd サービスの実行方法
12.1.5. 設定ファイルの編集
12.1.6. Working with Modules
12.1.7. 仮想ホストのセットアップ
12.1.8. SSL サーバーのセットアップ
12.1.9. その他のリソース
13. メールサーバー
13.1. 電子メールプロトコル
13.1.1. メール トランスポートのプロトコル
13.1.2. メール アクセスのプロトコル
13.2. 電子メールプログラム分類
13.2.1. メール転送エージェント (Mail Transport Agent)
13.2.2. メール配送エージェント (Mail Delivery Agent)
13.2.3. メール ユーザー エージェント
13.3. Mail Transport Agent
13.3.1. Postfix
13.3.2. Sendmail
13.3.3. Fetchmail
13.3.4. Mail Transport Agent (MTA) の設定
13.4. メール配送エージェント
13.4.1. Procmail の設定
13.4.2. Procmail レシピ
13.5. メールユーザーエージェント
13.5.1. 通信のセキュリティ
13.6. その他のリソース
13.6.1. インストールされているドキュメント
13.6.2. 役に立つ Web サイト
13.6.3. 関連書籍
14. ディレクトリー サーバー
14.1. OpenLDAP
14.1.1. Introduction to LDAP
14.1.2. OpenLDAP 製品群のインストール
14.1.3. OpenLDAP サーバーの設定法
14.1.4. Running an OpenLDAP Server
14.1.5. システムが OpenLDAP を使用して認証を実行するように設定する
14.1.6. その他のリソース
15. File and Print Servers
15.1. Samba
15.1.1. Samba の概要
15.1.2. Samba デーモンと関連サービス
15.1.3. Samba シェアへの接続
15.1.4. Samba サーバーの設定
15.1.5. Samba の開始と停止
15.1.6. Samba サーバー形式と smb.conf ファイル
15.1.7. Samba のセキュリティモード
15.1.8. Samba のアカウント情報データベース
15.1.9. Samba ネットワークブラウジング
15.1.10. CUPS 印刷サポートを使った Samba
15.1.11. Samba ディストリビューションプログラム
15.1.12. その他のリソース
15.2. FTP
15.2.1. ファイル伝送プロトコル
15.2.2. FTP サーバー
15.2.3. Files Installed with vsftpd
15.2.4. vsftpd の開始と停止
15.2.5. vsftpd 設定オプション
15.2.6. その他のリソース
15.3. プリンタの設定
15.3.1. Starting the Printer Configuration Tool
15.3.2. Starting Printer Setup
15.3.3. ローカルプリンタの追加
15.3.4. Adding an AppSocket/HP JetDirect printer
15.3.5. IPP プリンタの追加
15.3.6. Adding an LPD/LPR Host or Printer
15.3.7. Adding a Samba (SMB) printer
15.3.8. プリンタモデルの選択と終了
15.3.9. Printing a test page
15.3.10. 既存プリンタの変更
15.3.11. その他のリソース
VI. 監視および自動化
16. システム監視ツール
16.1. Viewing System Processes
16.1.1. Using the ps Command
16.1.2. Using the top Command
16.1.3. Using the System Monitor Tool
16.2. Viewing Memory Usage
16.2.1. Using the free Command
16.2.2. Using the System Monitor Tool
16.3. Viewing Block Devices and File Systems
16.3.1. Using the lsblk Command
16.3.2. Using the blkid Command
16.3.3. Using the partx Command
16.3.4. Using the findmnt Command
16.3.5. Using the df Command
16.3.6. Using the du Command
16.3.7. Using the System Monitor Tool
16.4. Viewing Hardware Information
16.4.1. Using the lspci Command
16.4.2. Using the lsusb Command
16.4.3. Using the lspcmcia Command
16.4.4. Using the lscpu Command
16.5. Monitoring Performance with Net-SNMP
16.5.1. Installing Net-SNMP
16.5.2. Running the Net-SNMP Daemon
16.5.3. Configuring Net-SNMP
16.5.4. Retrieving Performance Data over SNMP
16.5.5. Extending Net-SNMP
16.6. その他のリソース
16.6.1. インストールされているドキュメント
17. Viewing and Managing Log Files
17.1. Configuring rsyslog
17.1.1. Global Directives
17.1.2. Modules
17.1.3. Rules
17.1.4. rsyslog Command Line Configuration
17.2. ログファイルを探す
17.2.1. Configuring logrotate
17.3. ログファイルの表示
17.4. Adding a Log File
17.5. ログファイルを監視する
17.6. その他のリソース
17.6.1. インストールされているドキュメント
17.6.2. 役に立つ Web サイト
18. Automating System Tasks
18.1. Cron and Anacron
18.1.1. サービスの起動と停止
18.1.2. Configuring Anacron Jobs
18.1.3. Configuring Cron Jobs
18.1.4. Cron へのアクセスの制御
18.1.5. Black/White Listing of Cron Jobs
18.2. at コマンドと batch コマンド
18.2.1. At ジョブの設定
18.2.2. batch ジョブの設定
18.2.3. 保留ジョブの表示
18.2.4. その他のコマンドラインオプション
18.2.5. at と batch へのアクセスの制御
18.2.6. サービスの起動と停止
18.3. その他のリソース
18.3.1. インストールされているドキュメント
19. OProfile
19.1. Overview of Tools
19.2. Configuring OProfile
19.2.1. Specifying the Kernel
19.2.2. Setting Events to Monitor
19.2.3. Separating Kernel and User-space Profiles
19.3. Starting and Stopping OProfile
19.4. Saving Data
19.5. Analyzing the Data
19.5.1. Using opreport
19.5.2. Using opreport on a Single Executable
19.5.3. Getting more detailed output on the modules
19.5.4. Using opannotate
19.6. Understanding /dev/oprofile/
19.7. Example Usage
19.8. OProfile Support for Java
19.8.1. Profiling Java Code
19.9. Graphical Interface
19.10. OProfile and SystemTap
19.11. Additional Resources
19.11.1. Installed Docs
19.11.2. Useful Websites
VII. カーネル、モジュールおよびドライバーの設定
20. カーネルをアップグレードする
20.1. カーネルパッケージの概要
20.2. アップグレードの準備
20.3. アップグレードされたカーネルをダウンロードする
20.4. アップグレードの実行
20.5. 初期RAMディスクイメージの確認
20.6. ブートローダの確認
20.6.1. Configuring the GRUB Boot Loader
20.6.2. Configuring the OS/400 Boot Loader
20.6.3. Configuring the YABOOT Boot Loader
21. Working with Kernel Modules
21.1. Listing Currently-Loaded Modules
21.2. Displaying Information About a Module
21.3. Loading a Module
21.4. Unloading a Module
21.5. Setting Module Parameters
21.6. Persistent Module Loading
21.7. Specific Kernel Module Capabilities
21.7.1. 複数のイーサネットカードの使用
21.7.2. Using Channel Bonding
21.8. その他のリソース
21.8.1. インストールされているドキュメント
21.8.2. 役に立つ Web サイト
22. The kdump Crash Recovery Service
22.1. Configuring the kdump Service
22.1.1. Using the Kernel Dump Configuration Utility
22.1.2. Configuring kdump on the Command Line
22.1.3. Testing the Configuration
22.2. Analyzing the Core Dump
22.2.1. Running the crash Utility
22.2.2. Displaying the Message Buffer
22.2.3. Displaying a Backtrace
22.2.4. Displaying a Process Status
22.2.5. Displaying Virtual Memory Information
22.2.6. Displaying Open Files
22.2.7. Exiting the Utility
22.3. その他のリソース
22.3.1. インストールされているドキュメント
22.3.2. 役に立つ Web サイト
A. Consistent Network Device Naming
A.1. Affected Systems
A.2. System Requirements
A.3. Enabling and Disabling the Feature
A.4. Notes for Administrators
B. RPM
B.1. RPM の設計目標
B.2. RPMの使用法
B.2.1. RPM パッケージの検索
B.2.2. インストールとアップグレード
B.2.3. Configuration File Changes
B.2.4. アンインストール
B.2.5. インストール済みのアップグレードの実行
B.2.6. 問い合わせ
B.2.7. 検証
B.3. パッケージの署名を確認する
B.3.1. Importing Keys
B.3.2. Verifying Signature of Packages
B.4. Practical and Common Examples of RPM Usage
B.5. その他のリソース
B.5.1. インストールされているドキュメント
B.5.2. 役に立つ Web サイト
B.5.3. 関連書籍
C. X Window System
C.1. The X Server
C.2. デスクトップ環境とウィンドウマネージャ
C.2.1. デスクトップ環境
C.2.2. ウィンドウマネージャ
C.3. X サーバー設定ファイル
C.3.1. The Structure of the Configuration
C.3.2. The xorg.conf.d Directory
C.3.3. The xorg.conf File
C.4. フォント
C.4.1. Fontconfig へのフォントの追加
C.5. その他のリソース
C.5.1. インストールされているドキュメント
C.5.2. 役に立つ Web サイト
D. The sysconfig Directory
D.1. Files in the /etc/sysconfig/ Directory
D.1.1. /etc/sysconfig/arpwatch
D.1.2. /etc/sysconfig/authconfig
D.1.3. /etc/sysconfig/autofs
D.1.4. /etc/sysconfig/clock
D.1.5. /etc/sysconfig/dhcpd
D.1.6. /etc/sysconfig/firstboot
D.1.7. /etc/sysconfig/i18n
D.1.8. /etc/sysconfig/init
D.1.9. /etc/sysconfig/ip6tables-config
D.1.10. /etc/sysconfig/keyboard
D.1.11. /etc/sysconfig/ldap
D.1.12. /etc/sysconfig/named
D.1.13. /etc/sysconfig/network
D.1.14. /etc/sysconfig/ntpd
D.1.15. /etc/sysconfig/quagga
D.1.16. /etc/sysconfig/radvd
D.1.17. /etc/sysconfig/samba
D.1.18. /etc/sysconfig/selinux
D.1.19. /etc/sysconfig/sendmail
D.1.20. /etc/sysconfig/spamassassin
D.1.21. /etc/sysconfig/squid
D.1.22. /etc/sysconfig/system-config-users
D.1.23. /etc/sysconfig/vncservers
D.1.24. /etc/sysconfig/xinetd
D.2. Directories in the /etc/sysconfig/ Directory
D.3. その他のリソース
D.3.1. インストールされているドキュメント
E. The proc File System
E.1. A Virtual File System
E.1.1. Viewing Virtual Files
E.1.2. Changing Virtual Files
E.2. Top-level Files within the proc File System
E.2.1. /proc/buddyinfo
E.2.2. /proc/cmdline
E.2.3. /proc/cpuinfo
E.2.4. /proc/crypto
E.2.5. /proc/devices
E.2.6. /proc/dma
E.2.7. /proc/execdomains
E.2.8. /proc/fb
E.2.9. /proc/filesystems
E.2.10. /proc/interrupts
E.2.11. /proc/iomem
E.2.12. /proc/ioports
E.2.13. /proc/kcore
E.2.14. /proc/kmsg
E.2.15. /proc/loadavg
E.2.16. /proc/locks
E.2.17. /proc/mdstat
E.2.18. /proc/meminfo
E.2.19. /proc/misc
E.2.20. /proc/modules
E.2.21. /proc/mounts
E.2.22. /proc/mtrr
E.2.23. /proc/partitions
E.2.24. /proc/slabinfo
E.2.25. /proc/stat
E.2.26. /proc/swaps
E.2.27. /proc/sysrq-trigger
E.2.28. /proc/uptime
E.2.29. /proc/version
E.3. Directories within /proc/
E.3.1. Process Directories
E.3.2. /proc/bus/
E.3.3. /proc/bus/pci
E.3.4. /proc/driver/
E.3.5. /proc/fs
E.3.6. /proc/irq/
E.3.7. /proc/net/
E.3.8. /proc/scsi/
E.3.9. /proc/sys/
E.3.10. /proc/sysvipc/
E.3.11. /proc/tty/
E.3.12. /proc/PID/
E.4. Using the sysctl Command
E.5. 参考文献
F. 改訂履歴
索引

序文

The System Administrator's Guide contains information on how to customize the Fedora 16 system to fit your needs. If you are looking for a comprehensive, task-oriented guide for configuring and customizing your system, this is the manual for you.
このマニュアルは、下記のような中級のトピックについて説明しています。
  • パッケージのインストールや管理に使用する PackageKit やコマンドライン Yum パッケージ マネージャー
  • Setting up a network—from establishing an Ethernet connection using NetworkManager to configuring channel bonding interfaces to increase server bandwidth
  • Configuring DHCP, BIND, Apache HTTP Server, Postfix, Sendmail and other enterprise-class servers and software
  • Gathering information about your system, including obtaining kernel-space crash data with kdump
  • Easily working with kernel modules and upgrading the kernel

1. 対象の読者

The Deployment Guide assumes you have a basic understanding of the Fedora operating system. If you need help with the installation of this system, refer to the Fedora 16 Installation Guide.

2. この本の読み方

このマニュアルは主に下記のカテゴリーに分けられます。
パートI「基本的なシステム設定」
このパートは、キーボードの設定、日付と時間の設定、ユーザーとグループの管理といった基本体系な管理タスクをカバーします。
1章言語とキーボードの設定 covers basic language and keyboard setup. Read this chapter if you need to configure the language of your desktop, change the keyboard layout, or add the keyboard layout indicator to the panel.
2章日付と時刻の設定 covers the configuration of the system date and time. Read this chapter if you need to change the date and time setup, or configure the system to synchronize the clock with a remote Network Time Protocol (NTP) server.
3章ユーザーとグループの管理 covers the management of users and groups in a graphical user interface and on the command line. Read this chapter if you need to manage users and groups on your system, or enable password aging.
パートII「パッケージ管理」
This part describes how to manage software packages on Fedora using both Yum and the PackageKit suite of graphical package management tools.
4章Yum describes the Yum package manager. Read this chapter for information how to search, install, update, and uninstall packages on the command line.
5章PackageKit describes the PackageKit suite of graphical package management tools. Read this chapter for information how to search, install, update, and uninstall packages using a graphical user interface.
パートIII「ネットワーク」
このパートは Fedora のネットワーク設定の仕方について記述しています。
6章ネットワーク・インターフェース explores various interface configuration files, interface control scripts, and network function files located in the /etc/sysconfig/network-scripts/ directory. Read this chapter for information how to use these files to configure network interfaces.
パートIV「インフラストラクチャーサービス」
このパートはリモート ログインの有効化、認証の設定、daemon やサービスの設定方法についての情報を提供します。
7章サービスおよびデーモン covers the configuration of the services to be run when a system is started, and provides information on how to start, stop, and restart the services on the command line using the systemctl utility.
8章認証の設定 describes how to configure user information retrieval from Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS), and Winbind user account databases, and provides an introduction to the System Security Services Daemon (SSSD). Read this chapter if you need to configure authentication on your system.
9章OpenSSH describes how to enable a remote login via the SSH protocol. It covers the configuration of the sshd service, as well as a basic usage of the ssh, scp, sftp client utilities. Read this chapter if you need a remote access to a machine.
パートV「サーバー」
This part discusses various topics related to servers such as how to set up a Web server or share files and directories over the network.
10章DHCP サーバー guides you through the installation of a Dynamic Host Configuration Protocol (DHCP) server and client. Read this chapter if you need to configure DHCP on your system.
11章DNS サーバー introduces you to Domain Name System (DNS), explains how to install, configure, run, and administer the BIND DNS server. Read this chapter if you need to configure a DNS server on your system.
12章ウェブ サーバー focuses on the Apache HTTP Server 2.2, a robust, full-featured open source web server developed by the Apache Software Foundation. Read this chapter if you need to configure a web server on your system.
13章メールサーバー reviews modern email protocols in use today, and some of the programs designed to send and receive email, including Postfix, Sendmail, Fetchmail, and Procmail. Read this chapter if you need to configure a mail server on your system.
14章ディレクトリー サーバー covers the installation and configuration of OpenLDAP 2.4, an open source implementation of the LDAPv2 and LDAPv3 protocols. Read this chapter if you need to configure a directory server on your system.
15章File and Print Servers guides you through the installation and configuration of Samba, an open source implementation of the Server Message Block (SMB) protocol, and vsftpd, the primary FTP server shipped with Fedora. Additionally, it explains how to use the Printer Configuration tool to configure printers. Read this chapter if you need to configure a file or print server on your system.
パートVI「監視および自動化」
This part describes various tools that allow system administrators to monitor system performance, automate system tasks, and report bugs.
16章システム監視ツール discusses applications and commands that can be used to retrieve important information about the system. Read this chapter to learn how to gather essential system information.
17章Viewing and Managing Log Files describes the configuration of the rsyslog daemon, and explains how to locate, view, and monitor log files. Read this chapter to learn how to work with log files.
18章Automating System Tasks provides an overview of the cron, at, and batch utilities. Read this chapter to learn how to use these utilities to perform automated tasks.
19章OProfile covers OProfile, a low overhead, system-wide performance monitoring tool. Read this chapter for information how to use OProfile on your system.
パートVII「カーネル、モジュールおよびドライバーの設定」
このパートはカーネルのカスタマイズと管理を支援するさまざまなツールをカバーします。
20章カーネルをアップグレードする provides important information how to manually update a kernel package using the rpm command instead of yum. Read this chapter if you cannot update a kernel package with the Yum package manager.
21章Working with Kernel Modules explains how to display, query, load, and unload kernel modules and their dependencies, and how to set module parameters. Additionally, it covers specific kernel module capabilities such as using multiple Ethernet cards and using channel bonding. Read this chapter if you need to work with kernel modules.
22章The kdump Crash Recovery Service explains how to configure, test, and use the kdump service in Fedora, and provides a brief overview of how to analyze the resulting core dump using the crash debugging utility. Read this chapter to learn how to enable kdump on your system.
付録A Consistent Network Device Naming
This appendix covers consistent network device naming for network interfaces, a feature that changes the name of network interfaces on a system in order to make locating and differentiating the interfaces easier. Read this appendix to learn more about this feature and how to enable or disable it.
付録B RPM
This appendix concentrates on the RPM Package Manager (RPM), an open packaging system used by Fedora, and the use of the rpm utility. Read this appendix if you need to use rpm instead of yum.
付録C X Window System
This appendix covers the configuration of the X Window System, the graphical environment used by Fedora. Read this appendix if you need to adjust the configuration of your X Window System.
付録D The sysconfig Directory
This appendix outlines some of the files and directories located in the /etc/sysconfig/ directory. Read this appendix if you want to learn more about these files and directories, their function, and their contents.
付録E The proc File System
This appendix explains the concept of a virtual file system, and describes some of the top-level files and directories within the proc file system (that is, the /proc/ directory). Read this appendix if you want to learn more about this file system.

3. 表記方法

本ガイドは特定の単語や語句を強調したり、 記載内容の特定部分に注意を引かせる目的で次のような表記方法を使用しています。
PDF版 および印刷版では、 Liberation Fonts セットから採用した書体を使用しています。 ご使用のシステムに Liberation Fonts セットがインストールされている場合、 HTML 版でもこのセットが使用されます。 インストールされていない場合は代替として同等の書体が表示されます。 注記: Red Hat Enterprise Linux 5 およびそれ以降のバージョンにはデフォルトで Liberation Fonts セットが収納されます。

3.1. 印刷における表記方法

特定の単語や語句に注意を引く目的で 4 種類の表記方法を使用しています。 その表記方法および適用される状況は以下の通りです。
等幅の太字
シェルコマンド、ファイル名、パスなどシステムへの入力を強調するために使用しています。またキー配列やキーの組み合わせを強調するのにも使用しています。 例えば、
現在作業中のディレクトリ内のファイル my_next_bestselling_novel の内容を表示させるには、 シェルプロンプトで cat my_next_bestselling_novel コマンドを入力してから Enter を押してそのコマンドを実行します。
上記にはファイル名、シェルコマンド、キーが含まれています。 すべて等幅の太字で表されているため文中内で見分けやすくなっています。
キーが 1 つの場合と複数のキーの組み合わせになる場合を区別するため、 その組み合わせを構成するキー同士をハイフンでつないでいます。 例えば、
Enter を押してコマンドを実行します。
1 番目の仮想ターミナルに切り替えるは、 Ctrl+Alt+F2 を押します。 X-Windows セッションに戻るには、 Ctrl+Alt+F1 を押します。
最初の段落では押すべき 1 つのキーを特定して強調しています。 次の段落では同時に押すべき 3 つのキーの組み合わせが 2 種類ありそれぞれ強調されています。
ソースコードの説明では 1 段落内で提示されるクラス名、 メソッド、 関数、 変数名、 戻り値を上記のように 等幅の太字 で表示します。 例えば、
ファイル関連のクラス群はファイルシステムに対しては filesystem、 ファイルには file、 ディレクトリには dir をそれぞれ含みます。 各クラスは個別に関連する権限セットを持っています。
プロポーショナルの太字
アプリケーション名、 ダイアログボックスのテキスト、ラベル付きボタン、 チェックボックスとラジオボタンのラベル、 メニュータイトルとサブメニュータイトルなどシステム上で見られる単語や語句を表します。 例えば、
メインメニューバーから システム > 個人設定 > マウス の順で選択し マウスの個人設定 を起動します。 ボタン タブ内で 左ききのマウス チェックボックスをクリックしてから 閉じる をクリックしマウスの主要ボタンを左から右に切り替えます (マウスを左ききの人が使用するのに適した設定にする)。
gedit ファイルに特殊な文字を挿入する場合は、 メインメニューバーから アプリケーション > アクセサリ > 文字マップ の順で選択します。 次に 文字マップ メニューバーから 検索 > 検索… と選択して 検索 フィールド内にその文字名を入力し をクリックします。 探している文字が 文字表 内で強調表示されます。 この強調表示された文字をダブルクリックすると コピーするテキスト フィールド内に置かれるので次に コピー ボタンをクリックします。 ここでドキュメントに戻り gedit メニューバーから 編集 > 貼り付け を選択します。
上記には、 アプリケーション名、 システム全体のメニュー名と項目、 アプリケーション固有のメニュー名、 GUI インタフェースで見られるボタンやテキストがあります。 すべてプロポーショナルの太字で表示されているため文中内で見分けやすくなっています。
等幅の太字で且つ斜体 または プロポーショナルの太字で且つ斜体
等幅の太字やプロポーショナルの太字はいずれであっても斜体の場合は置換可能なテキストか変化するテキストを示します。 斜体は記載されている通りには入力しないテキスト、あるいは状況に応じて変化する出力テキストを表します。 例えば、
ssh を使用してリモートマシンに接続するには、 シェルプロンプトで ssh username@domain.name と入力します。 リモートマシンが example.com であり、 そのマシンで使用しているユーザー名が john なら ssh john@example.com と入力します。
mount -o remount file-system コマンドは指定したファイルシステムを再マウントします。 例えば、 /home ファイルシステムを再マウントするコマンドは mount -o remount /home になります。
現在インストールされているパッケージのバージョンを表示するには、 rpm -q package コマンドを使用します。 結果として次を返してきます、 package-version-release
上記の太字斜体の単語 — username、 domain.name、 file-system、 package、 version、 release に注目してください。 いずれもコマンドを発行するときに入力するテキスト用のプレースホルダーかシステムにより出力されるテキスト用のプレースホルダーになっています。
タイトル表示のような標準的な使用の他、 斜体は新しい重要な用語が初めて出現する場合にも使用されます。 例えば、
Publican は DocBook の発行システムです。

3.2. 引用における表記方法

端末の出力とソースコード一覧は、視覚的に周囲の文から区別されています。
端末に送信される出力は mono-spaced roman (等幅の Roman) にセットされるので以下のように表示されます。
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
ソースコードの一覧も mono-spaced roman (等幅の Roman) でセットされますが、以下のように強調表示されます。
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

3.3. 注記および警告

情報が見過ごされないよう 3 種類の視覚的なスタイルを使用して注意を引いています。

注記

注記は説明している部分に対するヒントや近道あるいは代替となる手段などになります。注記を無視しても悪影響はありませんが知っておくと便利なコツを見逃すことになるかもしれません。

重要

重要ボックスは見逃しやすい事項を詳細に説明しています。現在のセッションにのみ適用される設定上の変更点、 更新を適用する前に再起動が必要なサービスなどがあります。重要ボックスを無視してもデータを喪失するような結果にはなりませんがイライラ感やフラストレーションが生じる可能性があります。

警告

警告は無視しないでください。警告を無視するとデータを喪失する可能性が非常に高くなります。

4. Feedback

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla against the product Fedora Documentation.
When submitting a bug report, be sure to provide the following information:
  • Manual's identifier: system-administrator's-guide
  • Version number: 16
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

5. Acknowledgments

Certain portions of this text first appeared in the Deployment Guide, copyright © 2007 Red Hat, Inc., available at http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/index.html.
「Monitoring Performance with Net-SNMP」 is based on an article written by Michael Solberg.
The authors of this book would like to thank the following people for their valuable contributions: Adam Tkáč, Andrew Fitzsimon, Andrius Benokraitis, Brian Cleary Edward Bailey, Garrett LeSage, Jeffrey Fearn, Joe Orton, Joshua Wulf, Karsten Wade, Lucy Ringland, Marcela Mašláňová, Mark Johnson, Michael Behm, Miroslav Lichvár, Radek Vokál, Rahul Kavalapara, Rahul Sundaram, Sandra Moore, Zbyšek Mráz, Jan Včelák, Peter Hutterer, T.C. Hollingsworth, and James Antill, among many others.

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

このパートは、キーボードの設定、日付と時刻の設定、およびユーザーとグループの管理のような基本的なシステムの管理作業を取り扱います。

第1章 言語とキーボードの設定

Fedora 16 は地域と言語設定ツールを同梱しています。これは、キーボード配置、デスクトップ環境の言語、および他の地域の設定をできます。ツールを開始するには、アクティビティメニューからアプリケーションシステムツールシステム設定を選択することによりシステム設定ウィンドウを開き、地域と言語をクリックします。

1.1. 言語の変更

デスクトップの言語を設定するには、地域と言語アプリケーションの言語タブを選択します。一般的な言語の簡単な一覧が表示されます。
言語の変更
言語の変更
図1.1 言語の変更

デフォルトで、このリストはいくつかの利用可能な言語のみを含みます。他の言語を追加するには、リストの下にある + (プラス記号) ボタンをクリックします。ダイアログウィンドウが表示され、希望する言語を選択できます。ダイアログウィンドウの下部にある入力フィールドを使用して、そこに言語名の最初の数文字を入力すると表示される言語を減らすことができるようになります(たとえば、スロバキア語には slov です)。言語を選択すると、選んだものを確認するために選択ボタンをクリックします。
他の言語の追加
言語の追加
図1.2 他の言語の追加

一覧の中から特定の言語を選択するには、その名前をクリックします。変更は次回ログイン時に有効になります。

1.2. 日付、時刻および数字の形式の変更

デフォルトの日付、時刻、および通貨のフォーマットを変更するには、地域と言語アプリケーションのフォーマットタブを選択します。利用可能なフォーマットの簡単な一覧が表示されます。
日付、時刻および数字の形式の変更
日付、時刻および数字の形式の変更
図1.3 日付、時刻および数字の形式の変更

デフォルトで、このリストはいくつかの利用可能なフォーマットのみを含みます。他のフォーマットを追加するには、リストの下にある + (プラス記号) ボタンをクリックします。ダイアログウィンドウが表示され、地域により希望するフォーマットを選択できます。ダイアログウィンドウの下部にある入力フィールドを使用して、そこに地域名の最初の数文字を入力すると表示される言語を減らすことができるようになります(たとえば、スロバキアには slov です)。言語を選択すると、選んだものを確認するために選択ボタンをクリックします。
フォーマットの追加
フォーマットの追加
図1.4 フォーマットの追加

一覧の中から特定のフォーマットを選択するには、その名前をクリックします。変更は次回ログイン時に有効になります。

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

システム管理者がインストール中にインストールプログラムによりキーボード配置を設定できるにも関わらず、デフォルトの設定は現在の要望に対して常に適切ではないかもしれません。デフォルトのキーボードレイアウトを変更するには、地域と言語アプリケーションのレイアウトタブを選択します。現在有効なレイアウトの一覧が表示されます。
キーボードのレイアウトの変更
キーボードのレイアウトの変更
図1.5 キーボードのレイアウトの変更

他のレイアウトを一覧に追加するには、リストの下にある + (プラス記号) ボタンをクリックします。ダイアログウィンドウが表示され、希望するレイアウトを選択できます。ダイアログウィンドウの下部にある入力フィールドを使用して、そこにレイアウト名の最初の数文字を入力すると表示される言語を減らすことができるようになります(たとえば、スロバキアのレイアウトには slov です)。言語を選択すると、選んだものを確認するために追加ボタンをクリックします。
キーボードのレイアウトの追加
キーボードのレイアウトの追加
図1.6 キーボードのレイアウトの追加

一覧の最初にあるレイアウトが常にデフォルトと考えられます。特定のレイアウトを一覧において上下させるには、それを選択して、それぞれ (上矢印) または (下矢印) ボタンをクリックします。レイアウトを削除するには、 (マイナス記号) ボタンをクリックします。さらに、ウィンドウの右側にあるオプションボタンを選択することにより、個々のウィンドウに対して異なるキーボード配置を使用するか、すべてのウィンドウに対して一つのレイアウトを使用するかを選択できます。
複数のレイアウトを有効にしているとき、レイアウトを切り替えられるよう、パネルにキーボードインジケーターが表示されます。
キーボードのレイアウトのインジケーター
キーボードのレイアウトのインジケーター
図1.7 キーボードのレイアウトのインジケーター

1.4. 現在の設定の表示

現在の設定を表示するには、地域と言語アプリケーションのシステムタブを選択します。あなた自身の設定とシステム全体の設定の比較が表示されます。
現在の設定の表示
現在の設定の表示
図1.8 現在の設定の表示

第2章 日付と時刻の設定

本章は Fedora においてシステムの日付と時刻を設定することについて取り扱いします。手動による方法と Network Time Protocol (NTP) を用いる方法どちらもです。また、適切なタイムゾーンを設定することも取り扱います。どちらの方法も、日付と時刻の設定ツールを用いて日付と時刻を設定する方法と同じことをコマンドラインにおいて実行する方法を取り扱います。

2.1. 日付と時刻の設定ツールの使い方

Fedora 16 は日付と時刻設定ツールを同梱しています。これは、システムの日付と時刻を変更する、システムにより使用されるタイムゾーンを設定する、および時刻サーバーとシステムクロックを同期するために NTP (Network Time Protocol) デーモンをセットアップすることができます。ツールを起動するには、アクティビティメニューからアプリケーションシステムツールシステム設定を選択して日付と時刻アイコンを選択するか、ドロップダウンメニューから日付と時刻の設定を選択します。
日付と時刻の設定ツール
日付と時刻の設定ツール
図2.1 日付と時刻の設定ツール

デフォルトで、ツールは現在の設定を表示することのみできます。root のみがシステムの日付と時刻を設定できるからです。変更するために設定ツールをロック解除するには、ウィンドウの右上角にある解除ボタンをクリックして、プロンプトが出たときに正しいパスワードを入力します。
システムの現在の時刻を変更するには、ネットワーク時刻スイッチをクリックすることによりネットワーク上で同期するようシステムを設定するか、または数字の上と下にある上下の矢印をクリックすることにより手動で設定します。24時間形式を有効または無効にするために、24時間または AM/PM を選択できます。
タイムゾーンを変更するには、地図をクリックするか、地域および都市のドロップダウンリストから地域と都市を選択してください。
システムの現在の日付を変更するには、時刻の下にあるドロップダウンリストから月を選択して、日と年を選択するために上下の矢印を使用します。
この変更は直ちに反映されます。

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

Fedora 16 は、手動または NTP プロトコルを用いて日付と時刻を設定できるコマンドラインツールを提供しています。

2.2.1. 日付の変更方法

システムの日付を変更するには、シェルプロンプトにおいて root として以下のとおり入力します:
date +%D -s YYYY-MM-DD
…ここで YYYY は4桁の年、MM は2桁の月、DD は2桁の日です。たとえば、日付を2010年6月2日に変更するには、次のとおり入力します:
~]# date +%D -s 2010-06-02
何も引数をつけずに date を実行することにより現在の設定を確認できます。

2.2.2. 時刻の変更方法

現在の時刻を変更するには、root として以下のコマンドを実行します:
date +%T -s HH:MM:SS
…ここで HH は時間を意味して、MM は時間、SS は秒です。システムクロックが UTC (Coordinated Universal Time) を使用するよう設定されているならば、以下のオプションも追加してください:
date +%T -s HH:MM:SS -u
たとえば、システムクロックを UTC を使用して 11:26 PM に設定するには、次のとおり入力します:
~]# date +%T -s 23:26:00 -u
何も引数をつけずに date を実行することにより現在の設定を確認できます。

2.2.3. Network Time Protocol の設定

上述の手動セットアップと対照的に、Network Time Protocol (NTP) を通してリモートサーバーとシステムクロックを同期することもできます。一度だけの同期には、ntpdate コマンドを使用します:
  1. 以下の形式で ntpdate を使用することにより、選択した NTP サーバーがアクセス可能であるかを確認します:
    ntpdate -q server_address
    たとえば、0.fedora.pool.ntp.org に接続するには、次のとおり入力します:
    ~]$ ntpdate -q 0.fedora.pool.ntp.org
    server 204.15.208.61, stratum 2, offset -39.275438, delay 0.16083
    server 69.65.40.29, stratum 2, offset -39.269122, delay 0.17191
    server 148.167.132.201, stratum 2, offset -39.270239, delay 0.20482
    17 Oct 17:41:09 ntpdate[10619]: step time server 204.15.208.61 offset -39.275438 sec
  2. 良好なサーバーを検索するとき、root として、1つ以上のサーバーアドレスを引数として ntpdate コマンドを実行してください:
    ntpdate server_address…
    たとえば:
    ~]# ntpdate 0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
    17 Oct 17:42:13 ntpdate[10669]: step time server 204.15.208.61 offset -39.275436 sec
    エラーメッセージが何も表示されなければ、システム時刻が設定されます。date コマンドを引数なしで実行することにより現在の時刻を確認できます。
  3. 大抵の場合、これらの手順で十分です。1つ以上のサービスが常に現在の時刻を使用する必要が本当にあるならば、root として以下のコマンドを実行することにより、起動時に ntpdate を実行するようにします:
    systemctl enable ntpdate.service
    システムサービスとそのセットアップに関する詳細は、7章サービスおよびデーモンを参照してください。

    注記

    起動時に時刻サーバーと同期を続けることに失敗するならば、関連するエラーメッセージを /var/log/boot.log において確認できます。以下の行を /etc/sysconfig/network に追加してみてください:
    NETWORKWAIT=1
しかしながら、起動時に時刻を自動的に同期されるためのより便利な方法は ntpd デーモンを設定することです:
  1. root として、NTP 設定ファイル /etc/ntp.conf をテキストエディターで開きます。もしまだ存在しなければ、新しいものを作成します。
  2. 公開されている NTP サーバーの一覧を追加または編集します。Fedora 16 を使用しているならば、すでに以下の行が含まれているファイルが存在しますが、必要に応じてこれらを気軽に変更や拡張してください:
    server 0.fedora.pool.ntp.org iburst
    server 1.fedora.pool.ntp.org iburst
    server 2.fedora.pool.ntp.org iburst

    初期同期の高速化

    初期同期を高速化するには、iburst ディレクティブを各サーバー設定行の最後に加えることが推奨されます。
  3. 同じファイルにおいて、適切なパーミッションを設定して、localhost のみにアクセスを制限します:
    restrict default kod nomodify notrap nopeer noquery
    restrict -6 default kod nomodify notrap nopeer noquery
    restrict 127.0.0.1
    restrict -6 ::1
  4. 変更を保存して、エディタを終了して、NTP デーモンを再起動します:
    systemctl restart ntpd.service
  5. 加えて、ntpd デーモンがブート時に起動することを確実にします:
    systemctl enable ntpd.service

2.3. その他のリソース

日付と時刻の設定に関する詳細は、以下のリソースを参照してください。

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

  • date(1) — date ユーティリティのマニュアルページです。
  • ntpdate(8) — ntpdate ユーティリティのマニュアルページです。
  • ntpd(8) — ntpd サービスのマニュアルページです。

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

ユーザーとグループの管理は Fedora のシステム管理の中心的な要素です。本章は、グラフィカルユーザーインターフェースとコマンドラインにおいてユーザーとグループを追加、管理および削除する方法について説明しています。また、パスワードエージングやグループディレクトリの作成などの高度な話題を取り扱います。

3.1. ユーザーとグループのイントロダクション

ユーザーが人(アカウントが物理的なユーザーにひもづいていることを意味します)または特定のアプリケーションが使用するために存在するアカウントである一方、グループは共通の目的のために一緒なユーザーとひもづく組織の論理的な表現です。
各ユーザーはユーザー ID (UID) という一意な数値の識別番号と関連づけられます。同様に、各グループはグループ ID (GID) と関連づけられます。ファイルを作成するユーザーはそのファイルの所有者と所有グループになります。ファイルは所有者、グループおよび全員に対する読み込み、書き込みおよび実行のパーミッションを別々に割り当てられます。ファイル所有者は root によってのみ変更できます。また、アクセス権は root ユーザーとファイル所有者のどちらによっても変更できます。
さらに Fedora は、所有者以外の特定のユーザーに対してパーミッションを設定できるアクセス制御リスト (ACLs: access control lists) をファイルとディレクトリに対してサポートしています。この機能の詳細については、Storage Administration GuideAccess Control Lists の章を参照してください。

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

Fedora は、UNIX グループをより簡単に管理できる、ユーザープライベートグループ (UPG: user private group) スキーマを使用します。新規ユーザーがシステムに追加されるとき、ユーザープライベートグループが作成されます。それは作成されたユーザーと同じ名前を持ち、そのユーザーのみがユーザープライベートグループのメンバーです。
ユーザープライベートグループは新しく作成されたファイルやディレクトリに対してデフォルトのパーミッションを安全に設定します。ユーザーとユーザーのグループはどちらも、ファイルやディレクトリを変更できるようにします。
新しく作成されたファイルやディレクトリに適用されるパーミッションを決める設定は、umask と呼ばれ、/etc/bashrc ファイルにおいて設定されます。UNIX システムにおいては伝統的に、ファイルやディレクトリを作成したユーザーのみが変更をできる、umask022 に設定されます。このスキーマの下では、 作成者のグループのメンバーを含めてすべての他のユーザーはすべての変更が許可されません。しかしながら、UPG スキーマにおいては、すべてのユーザーが自分のプライベートグループを持つので、このグループ保護は必要ありません。

3.1.2. シャドウパスワード

複数のユーザーを持つ環境においてはとくに、システムの認証ファイルのセキュリティを向上させるために、shadow-utils パッケージにより提供されるシャドウパスワードを使用することは非常に重要です。このため、インストールプログラムはデフォルトでシャドウパスワードを有効にします。
以下は、UNIX ベースのシステムにおいてパスワードを保存する伝統的な方法に対してシャドウパスワードが持つ優位性の一覧です:
  • シャドウパスワードは暗号化されたパスワードハッシュを全体読み書き可能な /etc/passwd ファイルから root ユーザーのみが読み込み可能な /etc/shadow に移動することによりシステムセキュリティを向上させます。
  • シャドウパスワードはパスワードエージングに関する情報を保存します。
  • シャドウパスワードは /etc/login.defs ファイルがセキュリティポリシーを強制できます。
shadow-utils パッケージにより提供されるユーティリティの多くは、シャドウパスワードが有効かどうかによらず適切に機能します。しかしながら、パスワードエージング情報は /etc/shadow ファイルにだけ保存されるので、パスワードエージング情報を作成または変更するコマンドはすべて動作しません。以下は最初にシャドウパスワードを有効にしないと動作しないユーティリティとコマンドの一覧です:
  • chage ユーティリティ。
  • gpasswd ユーティリティ。
  • -e または -f オプションをつけた usermod コマンド。
  • -e または -f オプションをつけた useradd コマンド。

3.2. ユーザー アカウントのツールを使う

ユーザーアカウント設定ツールは、ローカルユーザーを表示、修正、追加、および削除をできます。ツールを実行するには、アクティビティメニューからアプリケーションシステムツールシステム設定を選択して、ユーザーアカウントアイコンをクリックします。
ユーザー アカウントの設定ツール
ユーザー アカウントの設定ツール
図3.1 ユーザー アカウントの設定ツール

デフォルトで、ツールは自分のアカウントに関連する特定の設定のみを変更できます。このため、root ユーザーのみがユーザーとグループを設定できます。すべての種類の変更のために設定ツールをロック解除するには、ウィンドウの右上角にあるロック解除ボタンをクリックして、プロンプトに正しいパスワードを入力します。

3.2.1. アカウントの設定

アカウントに関連づけられている画像を変更するには、アカウント名の次にあるアイコンをクリックして、プルダウンリストから画像を選択するか、ローカルドライブから画像を使用するために他の画像も参照... をクリックします。
アカウントに関連する名前を変更するには、編集するために名前の次にあるアイコンをクリックします。
アカウントの種類を変更するには、アカウントの種類ラベルの次にあるテキストをクリックします。この変更は、自分自身のアカウントを変更するときでも、設定ツールがロック解除されている必要があることに注意してください。
アカウントのデフォルトの言語を変更するには、言語ラベルの次のあるテキストをクリックして、一覧から言語を選択します。
パスワードを変更するには、パスワードラベルの次にあるテキストをクリックします。ダイアログボックスが表示され、新しいパスワードを設定できます。変更を確認するには現在をパスワードを入力しなければいけません。これをすると、変更を保存するために変更ボタンをクリックします。
パスワードの変更
パスワードの変更
図3.2 パスワードの変更

パスワードのセキュリティのアドバイス

非常に長いパスワードを使用することをお勧めします。これにより、侵入者がパスワードを推測して、権限なくアカウントにアクセスすることを難しくなるからです。また、パスワードは辞書に載っている単語を基にしないことをお勧めします。文字、数字と特殊文字の組み合わせを使用します。
最後に、特定のアカウントに対して自動ログインを設定するには、自動的にログインスイッチを有効にします。変更をするには、設定ツールがロック解除されなければいけません。

3.2.2. 新規ユーザーを追加する

新しいユーザーを追加するには、確実に設定ツールがロック解除して、アカウント一覧の下にある + ボタン(つまり、プラス記号)をクリックします。ダイアログウィンドウが表示され、ユーザーの詳細を決められます。
新しいアカウントの作成
新しいアカウントの作成
図3.3 新しいアカウントの作成

アカウントを作成するために以下の手順をとります:
  1. アカウントの種類プルダウンリストからアカウントの種類を選択します。利用可能なアカウントの種類は管理者標準(デフォルトのオプション)です。
  2. アカウントに関連づける名前を設定するには、フルネーム入力フィールドを記入します。この名前はログインマネージャーにより使用され、パネルに表示されます。
  3. ユーザー名プルダウンリストから推奨されたユーザー名を選択するか、対応する入力フィールドを記入します。
  4. 設定を確認するには、作成ボタンをクリックします。
Fedora は ユーザープライベートグループ (UPG: user private group) スキーマを使用します。UPG スキーマは標準的な UNIX のグループの取り扱い方法を何も追加や変更をしません。新しい利便性を提供します。新規ユーザーを作成すると必ず、ユーザーと同じ名前を持つ一意なグループが作成されます。
新規アカウントが作成されたとき、デフォルトの設定ファイルが /etc/skel/ ディレクトリから新規ホームディレクトリの中にコピーされます。

3.2.3. ユーザーの削除

ユーザーを削除するには、設定ツールを確実にロック解除して、アカウント一覧から希望するアカウントを選択して、アカウント一覧の下にある ボタン(つまり、マイナス記号)をクリックします。ダイアログが表示され、変更を確認するかキャンセルできます。
アカウントの削除
アカウントの削除
図3.4 アカウントの削除

ユーザーに属しているファイルやディレクトリ(つまり、ホームディレクトリ、メールスプールおよび一時ファイル)を削除するには、ファイルを削除ボタンをクリックします。これらのファイルをそのまま残して、ユーザーアカウントのみを削除するには、ファイルを残すをクリックします。削除を中止するには、キャンセルをクリックします。

3.3. ユーザー管理のツールを使う

ユーザー管理アプリケーションにより、グラフィカルユーザーインターフェースにおいてローカルユーザーとグループを表示、編集、追加および削除できます。アプリケーションを起動するには、アクティビティメニューからアプリケーションその他ユーザーとグループを選択するか、シェルプロンプトにおいて system-config-users と入力します。スーパーユーザー権限がなければ、アプリケーションが root として認証するプロンプトを表示することに注意してください。

3.3.1. ユーザーとグループを閲覧する

ユーザー管理のメインウィンドウは2つのタブに分けられています: ユーザータブは、ローカルユーザーの一覧とそのユーザー ID、プライマリグループ、ホームディレクトリ、ログインシェル、およびフルネームに関する追加情報を提供します。グループタブは、ローカルグループの一覧とそのグループ ID およびグループのメンバーに関する追加情報を提供します。
ユーザーとグループを閲覧する
ユーザーとグループを閲覧する
図3.5 ユーザーとグループを閲覧する

特定のユーザーまたはグループを検索するには、検索フィルターフィールドに最初の数文字を入力して、Enter を押すか、フィルターの適用ボタンをクリックします。列のヘッダーをクリックすると、利用可能な列は何でも項目を並べ替えることができます。
Fedora は、1000未満のユーザー ID とグループ ID をシステムユーザーとグループのために予約しています。デフォルトで、ユーザー管理はシステムユーザーを表示しません。すべてのユーザーとグループを表示するには、設定ダイアログを開くために編集設定を選択して、システムユーザーとグループを非表示チェックボックスを外します。

3.3.2. 新規ユーザーを追加する

新しいユーザーを追加するには、ユーザーの追加ボタンをクリックします。図3.6「新しいユーザーを追加する」にあるようなウィンドウが表示されます。
新しいユーザーを追加する
新しいユーザーを追加する
図3.6 新しいユーザーを追加する

新規ユーザーの追加ダイアログボックスにより、新しく作成するユーザーに関する情報を提供できます。ユーザーを作成するために、適切なフィールドにユーザー名とフルネームを、パスワードパスワードの確認フィールドにユーザーのパスワードを入力します。パスワードは少なくても6文字でなければいけません。

パスワードのセキュリティのアドバイス

非常に長いパスワードを使用することをお勧めします。これにより、侵入者がパスワードを推測して、権限なくアカウントにアクセスすることを難しくなるからです。また、パスワードは辞書に載っている単語を基にしないことをお勧めします。文字、数字と特殊文字の組み合わせを使用します。
ログインシェルプルダウンリストにより、ユーザーのログインシェルを選択できます。選択するシェルが確かではなければ、デフォルトの /bin/bash を受け入れてください。
デフォルトで、ユーザー管理アプリケーションは /home/username/ に新しいユーザーのためのホームディレクトリを作成します。ホームディレクトリの作成チェックボックスを外してホームディレクトリを作成しないことを選択できます。またはホームディレクトリテキストボックスの内容を編集することにより、このディレクトリを変更できます。ホームディレクトリを作成するときに、デフォルトの設定ファイルが /etc/skel/ ディレクトリの中からコピーされることに注意してください。
Fedora はユーザープライベートグループ (UPG) スキーマを使用します。新規ユーザーを作成すると必ず、ユーザーと同じ名前を持つ一意なグループがデフォルトで作成されます。このグループを作成したくなければ、ユーザーのプライベートグループを作成するチェックボックスを外します。
ユーザーのユーザー ID を指定するには、ユーザー ID を手動で指定するを選択します。このオプションが選択されなければ、1000以上で次に利用可能なユーザー ID が新規ユーザーに割り当てられます。Fedora は1000未満のユーザー ID をシステムユーザーのために予約しているので、ユーザー ID を手動で 1-999 に割り当てることはお勧めできません。
OK ボタンをクリックして新規ユーザーを作成します。パスワード有効期限のようなさらに高度なユーザーのプロパティを設定するには、ユーザーの追加後にユーザーのプロパティを修正します。

3.3.3. 新規グループを追加する

新規ユーザーグループを追加するには、ツールバーからグループの追加を選択します。図3.7「新規グループ」のようなウィンドウが表示されます。新規グループの名前を入力します。グループ ID を手動で指定を選択して、GID を選択します。Fedora は1000未満のグループ ID をシステムグループのために予約していることにも注意してください。
新規グループ
新規グループの作成
図3.7 新規グループ

グループを作成するには OK をクリックします。新規グループがグループ一覧に表示されます。

3.3.4. ユーザーのプロパティを変更する

既存のユーザーのプロパティを表示するには、ユーザータブをクリックして、ユーザーの一覧からユーザーを選択します。そして、メニューからプロパティをクリックします(またはプルダウンメニューからファイルプロパティPropertiesを選びます)。図3.8「ユーザーのプロパティ」のようなウィンドウが表示されます。
ユーザーのプロパティ
ユーザーのプロパティを修正する
図3.8 ユーザーのプロパティ

ユーザーのプロパティウィンドウは複数のタブページに分割されています:
  • ユーザーデータ — ユーザーを追加するときに設定する基本的なユーザー情報を表示します。ユーザーのフルネーム、パスワード、ホームディレクトリまたはログインシェルを変更するために、このタブを使用します。
  • アカウント情報 — アカウントを特定の日付に失効されたければ、アカウント失効を有効にするを選択します。ユーザーアカウントをロックして、ユーザーがシステムにログインできないようにするには、ローカルパスワードがロックされていますを選択します。
  • パスワード情報 — ユーザーのパスワードが最後に変更された日付を表示します。特定の日数経過後にパスワードの変更を強制するには、パスワード失効を有効にするを選択して、変更が要求されるまでの日数:フィールドに希望する値を入力します。ユーザーのパスワードが失効するまでの日数、パスワードの変更を警告されるまでの日数、アカウントが無効になるまでの日数も変更できます。
  • グループ — ユーザーのプライマリーグループ、およびユーザーをメンバーにしたいグループを表示および設定することができます。

3.3.5. グループのプロパティを変更する

既存のグループのプロパティを表示するには、グループの一覧からグループを選択して、メニューからプロパティをクリックします(または、プルダウンメニューからファイルプロパティを選びます)。図3.9「グループのプロパティ」のようなウィンドウが表示されます。
グループのプロパティ
グループのプロパティを変更する
図3.9 グループのプロパティ

グループユーザータブは、どのユーザーがグループのメンバーであるかを表示します。グループのユーザーを追加または削除するには、このタブを使用します。変更を保存するには OK をクリックします。

3.4. コマンドラインのツールを使う

Fedora においてユーザーとグループを管理する最も簡単な方法は、「ユーザー管理のツールを使う」に説明されているように、ユーザー管理アプリケーションを使用することです。しかしながら、コマンドラインツールを好むか、X Window System をインストールしていなければ、表3.1「ユーザーとグループの管理のためのコマンドライン」に一覧化されているコマンドラインユーティリティを使用できます。
表3.1 ユーザーとグループの管理のためのコマンドライン
ユーティリティ 説明
useradd, usermod, userdel ユーザーの追加と修正、削除のための標準的なユーティリティです。
groupadd, groupmod, groupdel グループの追加と修正、削除のための標準的なユーティリティです。
gpasswd /etc/group 設定ファイルを管理するための標準的なユーティリティです。
pwck, grpck パスワード、グループおよび関連するシャドウファイルの検証に使用できるユーティリティです。
pwconv, pwunconv パスワードからシャドウパスワードに変換する、またはシャドウパスワードから標準的なパスワードに戻すために使用できるユーティリティです。

3.4.1. 新規ユーザーを追加する

新規ユーザーをシステムに追加するには、シェルプロンプトにおいて root として以下のように入力します:
useradd [options] username
…ここで options表3.2「useradd のコマンドライン オプション」において説明されているコマンドラインオプションです。
デフォルトで、useradd コマンドはロックされたユーザーアカウントを作成します。アカウントをロック解除するには、パスワードを割り当てるために root として以下のコマンドを実行します:
passwd username
オプションとして、パスワードエージングポリシーを設定することができます。パスワードエージングを有効にする方法は「パスワードエージングの有効化」を参照してください。
表3.2 useradd のコマンドライン オプション
オプション 説明
-c 'comment' comment は任意の文字列で置き換えることができます。このオプションは一般的にユーザーのフルネームを指定するために使用されます。
-d home_directory デフォルトの /home/username/ の代わりに使用するホームディレクトリです。
-e date アカウントが無効化される YYYY-MM-DD 形式の日付です。
-f days パスワード期限切れ後にアカウントが無効化されるまでの日数です。0 が指定されると、アカウントはパスワード期限切れ後すぐに無効化されます。-1 が指定されると、アカウントはパスワード期限切れ後に無効化されません。
-g group_name ユーザーのデフォルトグループのグループ名とグループ番号です。グループはここに指定される以前から存在していなければなりません。
-G group_list ユーザーがメンバーとなる追加グループ (デフォルト以外) のグループ名とグループ番号をコンマで区切って入れます。グループはここに指定される以前から存在していなければなりません。
-m 存在しない場合に、ホームディレクトリを作成します。
-M ホームディレクトリを作成しません。
-N ユーザー用のユーザープライベートグループを作成しません。
-p password crypt を用いてパスワードを暗号化します。
-r 1000未満の UID を持ち、ホームディレクトリを持たないシステムアカウントを作成します。
-s ユーザーのログインシェルです。デフォルトは /bin/bash です。
-u uid ユーザーのためのユーザー ID は、一意かつ1000以上でなければいけません。

手順の説明

以下の手順は、コマンド useradd juan がシャドウパスワードが有効なシステムにおいて実行されたときに何が起こるかを説明します:
  1. juan の新しい行が /etc/passwd に作成されます:
    juan:x:501:501::/home/juan:/bin/bash
    行は以下の特徴を持ちます:
    • ユーザー名 juan で始まります。
    • システムがシャドウパスワードを使用していることを意味する、パスワードフィールドに x があります。
    • 1000以上の UID が作成されます。Fedora では、1000未満の UID はシステムユーザーのために予約されていて、ユーザーに割り当てるべきではありません。
    • 1000以上の GID が作成されます。Fedora では、1000未満の GID はシステム利用のために予約されていて、ユーザーに割り当てるべきではありません。
    • オプションの GECOS 情報は空白のままです。
    • juan のホームディレクトリが /home/juan/ に設定されます。
    • デフォルトのシェルが /bin/bash に設定されます。
  2. juan の新しい行が /etc/shadow に作成されます:
    juan:!!:14798:0:99999:7:::
    行は以下の特徴を持ちます:
    • ユーザー名 juan で始まります。
    • /etc/shadow のパスワードフィールドに感嘆符記号2つ (!!) が表示され、アカウントがロックします。

      注記

      暗号化パスワードが -p フラグを使用して渡されると、それがユーザーのために新しい行に/etc/shadow ファイルに置かれます。
    • パスワードは失効期限無しに設定される。
  3. juan という名前のグループの新しい行が /etc/group に作成されます:
    juan:x:501:
    ユーザーと同じ名前を持つグループはユーザープライベートグループと呼ばれます。ユーザープライベートグループの詳細は「ユーザープライベートグループ」を参照してください。
    /etc/group に作成された行は以下の特徴を持ちます:
    • グループ名 juan で始まります。
    • システムがシャドウグループパスワードを使用していることを意味する、パスワードフィールドに x があります。
    • GID は /etc/passwd においてユーザー juan に対してリストされたものと一致します。
  4. juan という名前のグループに対する新しい行が /etc/gshadow に作成されます:
    juan:!::
    行は以下の特徴を持ちます:
    • グループ名 juan で始まります。
    • 感嘆符記号 (!) が /etc/gshadow ファイルのパスワードフィールドに表示され、グループをロックします。
    • その他フィールドはすべて空白になっている。
  5. ユーザー juan のためのディレクトリが /home/ ディレクトリに作成されます:
    ~]# ls -l /home
    total 4
    drwx------. 4 juan juan 4096 Mar  3 18:23 juan
    このディレクトリはユーザー juan およびグループ juan により所有されます。ユーザー juan のみread, write, および execute 権限を持ちます。他のパーミッションはすべて拒否されます。
  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. 2 juan juan 4096 Jul 14  2010 .gnome2
    drwxr-xr-x. 4 juan juan 4096 Nov 23 15:09 .mozilla
ここで、juan というロックされたアカウントがシステムに存在します。有効化するには次に、管理者が passwd コマンドを使用してアカウントにパスワードを割り当てなければいけません。また、オプションとしてパスワードエージングガイドラインを設定します。

3.4.2. 新規グループを追加する

システムに新しいグループを追加するには、シェルプロンプトにおいて root として以下のように入力します:
groupadd [options] group_name
…ここで options表3.3「groupadd のコマンドライン オプション」に説明されているコマンドラインオプションです。
表3.3 groupadd のコマンドライン オプション
オプション 説明
-f, --force -g gid とともに使用され、gid がすでに存在するとき、groupadd がグループ用に他の一意な gid を選択します。
-g gid グループのグループ ID は一意かつ1000以上でなければいけません。
-K, --key key=value /etc/login.defs のデフォルトを上書きします。
-o, --non-unique 重複したグループの作成を許可します。
-p, --password password 新しいグループのためにこの暗号化されたパスワードを使用します。
-r 1000未満の GID を持つシステムグループを作成します。

3.4.3. パスワードエージングの有効化

セキュリティの理由から、ユーザーがパスワードを定期的に変更するよう要求することをお勧めします。ユーザーの管理アプリケーションのパスワード情報タブにおいてユーザーを追加または編集するときに、または chage コマンドを使用することにより、これを実行できます。

chage を使用するためにシャドウパスワードが有効化されなければいけません

シャドウパスワードは chage コマンドを使用するために有効化されなければいけません。詳細は「シャドウパスワード」を参照してください。
シェルプロンプトからユーザーのパスワード有効期限を設定するには、root として以下のコマンドを実行します:
chage [options] username
…ここで options表3.4「chhage のコマンドライン オプション」において説明されているコマンドラインオプションです。chage コマンドが直接ユーザー名を引数としているとき (つまり、コマンドラインオプションを何も指定していないとき)、現在のパスワードエージング値が表示され、対話的に変更することができます。
表3.4 chhage のコマンドライン オプション
オプション 説明
-d days パスワードが変更された日を 1970 年 1 月 1 日からの日数で指定します。
-E date アカウントがロックされる日付を YYYY-MM-DD の形式で指定します。日付を指定する代わりに、 1970 年 1 月 1 日からの起算日数で指定することも可能です。
-I days アカウントをロックする前にパスワード期限切れ後のインアクティブな日数を指定します。値が 0 ならば、アカウントはパスワード期限切れ後にロックされません。
-l アカウントの現在のエージング設定を一覧表示します。
-m days ユーザーがパスワードを変更しなければいけない最小日数を指定します。値が 0 ならば、パスワードは期限切れしません。
-M days パスワードが有効な最大日数を指定します。このオプションにより指定された日数に加えて、-d オプションで指定された日数が現在の日数よりも小さいとき、ユーザーはアカウントを使用する前にパスワードを変更しなければいけません。
-W days ユーザーにパスワード失効の日付を警告するまでの日数を指定します。

ユーザーが初めてログインするときにパスワードが失効するように設定できます。これによりユーザーが直ちにパスワードを変更するよう強制されます。
  1. 初期パスワードをセットアップします。これには一般的な手順が2つあります: デフォルトのパスワードを割り当てることができます、または空白のパスワードを使用することができます。
    デフォルトのパスワードを割り当てるには、シェルプロンプトにおいて root として以下のように入力します:
    passwd username
    代わりに空のパスワードを割り当てるには、以下のコマンドを使用します:
    passwd -d username

    できる限り空白のパスワードの使用を避けます

    空白のパスワードを使用することは便利ですが、非常に危険なことです。あらゆる第三者がセキュアではないユーザー名を使用して最初にログインして、システムにアクセスすることができます。必ず、空白のパスワードを持つアカウントをロック解除する前にログインする準備ができていることを確実にしてください。
  2. Force immediate password expiration by running the following command as root として以下のように実行することにより、直ちにパスワードを強制的に期限切れにできます:
    chage -d 0 username
    このコマンドは、パスワードが最後に変更された日付の値を 1970 年 1 月 1 日に設定します。この値は、いかなるパスワードエージングのポリシーが設定されていようと関係なく、直ちにパスワードを強制的に失効させます。
初回ログイン時、ユーザーは新しいパスワードを入力するよう要求されます。

3.4.4. 自動ログアウトの有効化

とくに root としてログインしているとき、参加していないログインセッションが重要なセキュリティリスクを引き起こすかもしれません。このリスクを減らすには、一定時間経過後に使用していないユーザーを自動的にログアウトさせるようシステムを設定できます。
  1. screen パッケージが確実にインストールされていることを確認してください。root として以下のコマンドを実行すると確認できます:
    yum install screen
    Fedora にパッケージをインストールする方法の詳細は、「パッケージのインストール」を参照してください。
  2. このファイルが割り込みできないことを確実にするには、root として、/etc/profile ファイルの最初に以下の行を追加します。
    trap "" 1 2 3 15
  3. ユーザーが仮想コンソールにログインするかリモートログインするたびに screen セッションを開始するには、/etc/profile ファイルの最後に以下の行を追加します:
    SCREENEXEC="screen"
    if [ -w $(tty) ]; then
      trap "exec $SCREENEXEC" 1 2 3 15
      echo -n 'Starting session in 10 seconds'
      sleep 10
      exec $SCREENEXEC
    fi
    新しいセッションが開始されるときは毎回、メッセージが表示され、ユーザーが10秒待たなければいけません。セッションを開始するまでの待ち時間を調整するには、sleep コマンドの後の値を変更します。
  4. 与えられた未使用時間の経過後に screen セッションを閉じるには、/etc/screenrc 設定ファイルに以下の行を追加します:
    idle 120 quit
    autodetach off
    これは120秒を制限時間に設定します。この制限を調整するには、idle ディレクティブの後にある値を変更します。
    代わりに、以下の行を使用することにより、システムがセッションをロックだけするよう設定できます:
    idle 120 lockscreen
    autodetach off
    このように、セッションをロック解除するためにパスワードが必要になります。
ユーザーが次回システムにログインしたときに変更が反映されます。

3.4.5. グループ用ディレクトリーの作成

システム管理者は通常、主要な各プロジェクトに対するグループを作成して、プロジェクトのファイルにアクセスが必要なときにユーザーをグループに割り当てたいと考えます。この伝統的なスキーマを用いると、ファイル管理は難しいです。誰かがファイルを作成するとき、ユーザーが属しているプライマリグループと関連づけられます。一人が複数のプロジェクトにおいて仕事をしているとき、正しいファイルと正しいグループを関連づけることは難しいです。しかしながら、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 -l /opt
total 4
drwxrwsr-x. 3 root myproject 4096 Mar  3 18:31 myproject

3.5. その他のリソース

ユーザーとグループの管理に関する詳細は以下のリソースを参照してください。

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

ユーザーとグループを管理するためのさまざまなユーティリティに関する詳細は、以下のマニュアルページを参照してください:
  • chage(1) — パスワードのエージングポリシーとアカウントの期限切れ日を変更するためのコマンドです。
  • gpasswd(1) — /etc/group ファイルを管理するコマンドです。
  • groupadd(8) — グループを追加するコマンドです。
  • grpck(8) — /etc/group ファイルを検証するコマンドです。
  • groupdel(8) — グループを削除するコマンドです。
  • groupmod(8) — グループのメンバーを修正するコマンドです。
  • pwck(8) — /etc/passwd/etc/shadow ファイルを検証するコマンドです。
  • pwconv(8) — 標準的なパスワードから shadow 形式のパスワードに変換するツールです。
  • pwunconv(8) — shadow 形式のパスワードから標準的なパスワードに変換するツールです。
  • useradd(8) — ユーザーを追加するコマンドです。
  • userdel(8) — ユーザーを削除するコマンドです。
  • usermod(8) — ユーザーを修正するコマンドです。
関連する設定ファイルに関する詳細は、以下を参照してください:
  • group(5) — システムのグループ情報を含むファイルです。
  • passwd(5) — システムのユーザー情報を含むファイルです。
  • shadow(5) — パスワードおよびシステムに対するアカウント期限切れ情報を含むファイルです。

パート II. パッケージ管理

Fedora システムにおいてすべてのソフトウェアは、インストール、更新、または削除できる RPM パッケージに分割されています。このパートは Fedora において Yum およびグラフィカルなパッケージ管理ツールの PackageKit 製品群を使用してパッケージを管理する方法を説明しています。

目次

4. Yum
4.1. パッケージの確認と更新
4.1.1. 更新の確認
4.1.2. パッケージの更新
4.1.3. 設定ファイル変更の保存
4.2. パッケージとパッケージ グループ
4.2.1. パッケージの検索
4.2.2. パッケージの一覧
4.2.3. パッケージ情報の表示
4.2.4. パッケージのインストール
4.2.5. パッケージの削除
4.2.6. 処理とトランザクションの履歴
4.3. Yum と Yum リポジトリーの設定
4.3.1. [main] オプションの設定
4.3.2. [repository] オプションの設定
4.3.3. Yum 変数の使い方
4.3.4. 現在の設定の表示
4.3.5. Yum リポジトリの追加・有効化および無効化
4.3.6. Yum リポジトリーの作成
4.4. Yum プラグイン
4.4.1. Yum プラグインの無効化、有効化、設定
4.4.2. 追加の Yum プラグインのインストール
4.4.3. プラグインの説明
4.5. その他のリソース
5. PackageKit
5.1. ソフトウェアの更新を用いたパッケージの更新
5.1.1. 更新の確認間隔の設定
5.1.2. ソフトウェアソースの設定
5.2. ソフトウェアの追加/削除の使用
5.2.1. ソフトウェアソースの更新 (Yum リポジトリー)
5.2.2. フィルターを用いたパッケージの検索
5.2.3. パッケージ(および依存するもの)のインストールおよび削除
5.2.4. パッケージグループのインストールおよび削除
5.2.5. トランザクションログの表示
5.3. PackageKit アーキテクチャー
5.4. その他のリソース

第4章 Yum

Yum は、パッケージに関する情報を問い合わせる、リポジトリからパッケージを取得する、自動的に依存解決を使用してパッケージをインストールおよびアンインストールする、システム全体を最新の利用可能なパッケージに更新することができる、The Fedora Project パッケージマネージャーです。Yum は更新、インストール、削除しているパッケージの依存解決を自動的に実行します。このように、利用可能な依存するパッケージをすべて自動的に決定、取得、インストールできます。Yum は新規リポジトリ、追加リポジトリ、またはパッケージソースを用いて設定できます。また、機能を向上および拡張させる多くのプラグインも提供します。Yum は RPM ができるのと同じ作業の多くを実行できます。さらに、同様のコマンドラインオプションを持ちます。Yum は単独のマシンまたはそれらのグループにおいて簡単でシンプルなパッケージ管理をできるようにします。

GPG 署名パッケージを用いたセキュアなパッケージ管理

Yum は GPG 署名されたパッケージにおいて GPG (Gnu Privacy Guard、GnuPGとしても知られています) 署名の検証を、すべてのパッケージリポジトリまたは個々のリポジトリに対して有効にすることによりセキュアなパッケージ管理を提供します。署名検証が有効にされたとき、Yum はリポジトリに対して正しいキーを用いて GPG 署名されていないあらゆるパッケージをインストールすることを拒否します。つまり、The Fedora Project のような信頼されたソースからシステムにダウンロードしてインストールして、転送中に変更されていないことを信頼できます。Yum を用いて署名検証を有効にすることに関する詳細は「Yum と Yum リポジトリーの設定」を参照してください、または一般に GPG 署名された RPM パッケージを検証することについては「パッケージの署名を確認する」を参照してください。
Yum は他のマシンにある RPM パッケージのダウンロードとインストールのために自身のリポジトリを簡単に設定することができます。
Yum はシステム管理作業を実行する最も速い方法であり、PackageKit グラフィカルパッケージ管理アプリケーションにより提供されるものを超えた機能を提供するので、Yum を学習することは価値のある投資です。PackageKit の使い方の詳細は5章PackageKitを参照してください。

Yum とスーパーユーザー権限

インストールに yum を使用するためには、スーパーユーザー権限を持っていなければいけません。本章にあるすべての例は、su または sudo コマンドを使用することにより、スーパーユーザー権限をすでに持っていることを前提にしています。

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

4.1.1. 更新の確認

システムにインストールされているパッケージが利用可能な更新があるかを確認するには、以下のコマンドを使用します
yum check-update
例:
~]# yum check-update
Loaded plugins: langpacks, presto, refresh-packagekit

PackageKit.x86_64                    0.6.14-2.fc15                 fedora
PackageKit-command-not-found.x86_64  0.6.14-2.fc15                 fedora
PackageKit-device-rebind.x86_64      0.6.14-2.fc15                 fedora
PackageKit-glib.x86_64               0.6.14-2.fc15                 fedora
PackageKit-gstreamer-plugin.x86_64   0.6.14-2.fc15                 fedora
PackageKit-gtk-module.x86_64         0.6.14-2.fc15                 fedora
PackageKit-gtk3-module.x86_64        0.6.14-2.fc15                 fedora
PackageKit-yum.x86_64                0.6.14-2.fc15                 fedora
PackageKit-yum-plugin.x86_64         0.6.14-2.fc15                 fedora
gdb.x86_64                           7.2.90.20110429-36.fc15       fedora
kernel.x86_64                        2.6.38.6-26.fc15              fedora
rpm.x86_64                           4.9.0-6.fc15                  fedora
rpm-libs.x86_64                      4.9.0-6.fc15                  fedora
rpm-python.x86_64                    4.9.0-6.fc15                  fedora
yum.noarch                           3.2.29-5.fc15                 fedora
上の出力にあるパッケージは利用可能な更新があるものとして一覧化されています。一覧にある最初のパッケージは PackageKit というグラフィカルパッケージマネージャーです。出力例にある行は次のことを意味します:
  • PackageKit — パッケージの名前
  • x86_64 — パッケージがビルトされた対象の CPU アーキテクチャー
  • 0.6.14 — インストールされる更新パッケージのバージョン
  • fedora — 更新パッケージが置かれているリポジトリー
カーネル(kernel パッケージ)、Yum および RPM 自身(yum および rpm パッケージ)だけでなく、その依存物(kernel-firmware, rpm-libs, および rpm-python パッケージのような)をすべて yum を使用して更新できることを出力は示しています。

4.1.2. パッケージの更新

単一パッケージ、複数パッケージまたは全パッケージを一度に更新することを選べます。更新するパッケージに依存するあらゆるものに利用可能な更新があれば、それらも更新されます。

シンプルなパッケージの更新

root で次のコマンドを実行し、ひとつのパッケージを更新します:
yum update package_name
たとえば、udev パッケージを更新するには、次のとおり入力します:
~]# yum update udev
Loaded plugins: langpacks, presto, refresh-packagekit
Updating Red Hat repositories.
INFO:rhsm-app.repolib:repos updated: 0
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package gdb.x86_64 0:7.2.90.20110411-34.fc15 will be updated
---> Package gdb.x86_64 0:7.2.90.20110429-36.fc15 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package     Arch         Version                          Repository      Size
================================================================================
Updating:
 gdb         x86_64       7.2.90.20110429-36.fc15          fedora         1.9 M

Transaction Summary
================================================================================
Upgrade       1 Package(s)

Total download size: 1.9 M
Is this ok [y/N]:
この出力は関心がある項目をいくつか含んでいます:
  1. Loaded plugins:yum はインストールされて有効にされている Yum プラグインを必ず通知します。ここでは、yumlangpacks, presto, および refresh-packagekit プラグインを使用しています。Yum プラグインに関する一般的な情報は「Yum プラグイン」を参照してください、または特定のプラグインの説明は「プラグインの説明」を参照してください。
  2. gdb.x86_64 — 新しい gdb パッケージのダウンロードとインストールができます。
  3. yum は、更新の情報を表示して、更新を実行したいかどうかを確認します。yum はデフォルトで対話的に動作します。どのトランザクションが実行する yum 計画をすでに知っているならば、yum が尋ねてくる質問にすべて yes を答えるように -y オプションを使用できます(非対話的に実行する場合です)。しかしながら、発生したあらゆる問題を簡単にトラブルシューティングできるように、どのような変更がシステムに対して行われるか yum 計画を常に確認すべきです。
    トランザクションがうまくいかなければ、「処理とトランザクションの履歴」 に説明されているように yum history コマンドを使用することにより、 Yum のトランザクション履歴を表示することができます。

Yum でのカーネルのインストールとアップグレード

コマンド rpm -i kernel を使用するときに RPM が新しいカーネルをインストールするのと同じ意味で、yum は必ず新しいカーネルをインストールします。そのため、yum を使用するときにカーネルをインストールするのか更新するのかについて心配する必要がありません。 yum update または yum install コマンドのどちらを使用しているかに関わらず、適切なものを実行します。
一方、RPM を使用しているときは、rpm -u kernel (現在のカーネルを置き換えます) の代わりに、rpm -i kernel コマンド (新しいカーネルをインストールします) を使用することが重要です。RPM を用いたカーネルのインストール/アップグレードの詳細は「インストールとアップグレード」を参照してください。

全パッケージおよびそれらの依存性の更新

すべてのパッケージとそれに依存するものを更新するには、単に yum update と入力します(引数は何もありません):
yum update

セキュリティ関連のパッケージの更新

利用可能なセキュリティ更新を持つパッケージを発見すること、そしてそれらのパッケージを迅速かつ簡単に更新することは重要です。Yum はこの目的のためのプラグインを提供します。security プラグインはセキュリティ中心のコマンド、サブコマンドおよびオプションの組を用いて yum コマンドを拡張します。具体的な情報は「プラグインの説明」を参照してください。

4.1.3. 設定ファイル変更の保存

あなたは自分の Fedora システムを使用するので、パッケージによりインストールされた設定ファイルに必ず変更するでしょう。Yum がシステムに変更を実行するために使用する RPM は、それらの完全性を保証するためのメカニズムを提供します。パッケージの更新をまたがり設定ファイルへの変更を管理する方法の詳細は「インストールとアップグレード」を参照してください。

4.2. パッケージとパッケージ グループ

4.2.1. パッケージの検索

次のコマンドですべての RPM パッケージ名や説明、要約で検索できます。
yum search term
このコマンドは各項目に一致するものの一覧を表示します。たとえば、meld または kompare に一致するすべてのパッケージを一覧表示するには、次のように入力します:
~]# yum search meld kompare
Loaded plugins: langpacks, presto, refresh-packagekit
============================== N/S Matched: meld ===============================
meld.noarch : Visual diff and merge tool
python-meld3.x86_64 : HTML/XML templating system for Python

============================= N/S Matched: kompare =============================
komparator.x86_64 : Kompare and merge two folders

  Name and summary matches only, use "search all" for everything.
yum search コマンドは、名前はよくわからないが、関連する語句を知っているパッケージを検索するために有用です。

4.2.2. パッケージの一覧

yum list および関連するコマンドは、パッケージ、パッケージのグループおよびリポジトリーに関する情報を提供します。
すべての Yum の list コマンドは引数として複数のグロブ表現を追加することにより結果をフィルターできます。グロブ表現は、ワイルドカード文字 * (あらゆる文字に複数回マッチするよう展開されます) および ? (あらゆる文字に1回マッチするよう展開されます) を複数含む文字列です。

glob 表記で結果のフィルタリング

引数を yum コマンドに渡すとき、グロブ表現をエスケープすることに注意してください。そうでなければ、Bash シェルはこれらの表現をパス名 拡張として解釈します。潜在的にグロブに一致する現在のディレクトリにあるすべてのファイルを yum に渡します。グロブ表現が意図したとおり yum に渡されることを確実にするには、次のようにします:
  • バックスラッシュを手前につけることによりワイルドカード文字を
  • グロブ表現全体を二重引用符または引用符でくくります
yum list glob_expression
全 glob 表記に一致するインストール済みと利用できるパッケージ情報の一覧です。
例4.1 すべての ABRT アドオンとプラグインのグロブ表現を用いた一覧表示
さまざまな ABRT アドオンとプラグインを持つパッケージは abrt-addon- または abrt-plugin- から始まります。これらのパッケージを一覧表示するには、シェルプロンプトにおいて以下のように入力します:
~]# yum list abrt-addon\* abrt-plugin\*
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
abrt-addon-ccpp.x86_64               2.0.2-5.fc15     @fedora
abrt-addon-kerneloops.x86_64         2.0.2-5.fc15     @fedora
abrt-addon-python.x86_64             2.0.2-5.fc15     @fedora
abrt-plugin-bugzilla.x86_64          2.0.2-5.fc15     @fedora
abrt-plugin-logger.x86_64            2.0.2-5.fc15     @fedora
Available Packages
abrt-plugin-mailx.x86_64             2.0.2-5.fc15     updates
abrt-plugin-reportuploader.x86_64    2.0.2-5.fc15     updates
abrt-plugin-rhtsupport.x86_64        2.0.2-5.fc15     updates

yum list all
インストール済みかつ利用可能なパッケージの一覧です。
例4.2 インストール済みと利用できる全パッケージの一覧
~]# yum list all
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
ConsoleKit.x86_64                       0.4.4-1.fc15                  @fedora
ConsoleKit-libs.x86_64                  0.4.4-1.fc15                  @fedora
ConsoleKit-x11.x86_64                   0.4.4-1.fc15                  @fedora
GConf2.x86_64                           2.32.3-1.fc15                 @fedora
GConf2-gtk.x86_64                       2.32.3-1.fc15                 @fedora
ModemManager.x86_64                     0.4-7.git20110201.fc15        @fedora
NetworkManager.x86_64                   1:0.8.998-4.git20110427.fc15  @fedora
NetworkManager-glib.x86_64              1:0.8.998-4.git20110427.fc15  @fedora
NetworkManager-gnome.x86_64             1:0.8.998-4.git20110427.fc15  @fedora
NetworkManager-openconnect.x86_64       0.8.1-9.git20110419.fc15      @fedora
[出力の省略]

yum list installed
システムにインストールされているすべてのパッケージを一覧表示します。出力の一番右の列は、パッケージが取得されたリポジトリーを表示します。
例4.3 二重引用符のグロブ表現を用いたインストール済みパッケージの一覧表示
厳密に krb から始まり1文字以上の文字とハイフンが続く、インストール済みパッケージをすべて表示するには、次のように入力します:
~]# yum list installed "krb?-*"
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
krb5-libs.x86_64              1.9-7.fc15              @fedora

yum list available
有効な全リポジトリーと利用できる全パッケージの一覧です。
例4.4 エスケープされたワイルドカード文字を用いた単一グロブ表現を使用した利用可能なパッケージの一覧表示
gstreamer とその後に plugin を含む名前を持つ利用可能なパッケージをすべて表示するには、以下のコマンドを実行します:
~]# yum list available gstreamer\*plugin\*
Loaded plugins: langpacks, presto, refresh-packagekit
Available Packages
gstreamer-plugin-crystalhd.x86_64               3.5.1-1.fc14       fedora
gstreamer-plugins-bad-free.x86_64               0.10.22-1.fc15     updates
gstreamer-plugins-bad-free-devel.x86_64         0.10.22-1.fc15     updates
gstreamer-plugins-bad-free-devel-docs.x86_64    0.10.22-1.fc15     updates
gstreamer-plugins-bad-free-extras.x86_64        0.10.22-1.fc15     updates
gstreamer-plugins-base.x86_64                   0.10.33-1.fc15     updates
gstreamer-plugins-base-devel.x86_64             0.10.33-1.fc15     updates
gstreamer-plugins-base-devel-docs.noarch        0.10.33-1.fc15     updates
gstreamer-plugins-base-tools.x86_64             0.10.33-1.fc15     updates
gstreamer-plugins-espeak.x86_64                 0.3.3-3.fc15       fedora
gstreamer-plugins-fc.x86_64                     0.2-2.fc15         fedora
gstreamer-plugins-good.x86_64                   0.10.29-1.fc15     updates
gstreamer-plugins-good-devel-docs.noarch        0.10.29-1.fc15     updates

yum grouplist
全パッケージ グループの一覧です。
例4.5 全パッケージ グループの一覧
~]# yum grouplist
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Group Process
Installed Groups:
   Administration Tools
   Design Suite
   Dial-up Networking Support
   Fonts
   GNOME Desktop Environment
[出力の省略]

yum repolist
有効な 各リポジトリーに対してリポジトリー ID、名前、および提供されるパッケージ数を一覧表示します。
例4.6 有効なリポジトリーの一覧表示
~]# yum repolist
Loaded plugins: langpacks, presto, refresh-packagekit
repo id                      repo name                                    status
fedora                       Fedora 15 - i386                             19,365
updates                      Fedora 15 - i386 - Updates                   3,848
repolist: 23,213

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

複数のパッケージに関する情報を表示するには(ここでもグロブ表現が有効です)、以下のコマンドを使用します:
yum info package_name
たとえば、 abrt パッケージに関する情報を表示するには、次のように入力します:
~]# yum info abrt
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
Name        : abrt
Arch        : x86_64
Version     : 2.0.1
Release     : 2.fc15
Size        : 806 k
Repo        : installed
From repo   : fedora
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 informations 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 リポジトリの ID を追加情報として提供します。(出力において From repo: 行を探してください)。
以下のコマンドを使用することにより、代替物とパッケージに関する有用な情報を Yum データベースに問い合わせすることもできます:
yumdb info package_name
このコマンドは、パッケージのチェックサム(および、それを生成するために使用された SHA-256 のようなアルゴリズム)、パッケージをインストールするために呼び出されたコマンドラインに与えられたコマンド(もしあれば)、パッケージがシステムにインストールされた理由(ここで user はユーザーによりインストールされたことを意味します、dep は依存性のためもたらされたことを意味します。)を含め、パッケージに関するさらなる情報を提供します。たとえば、yum パッケージに関するさらなる情報を表示するには、次のように入力します:
~]# yumdb info yum
Loaded plugins: langpacks, presto, refresh-packagekit
yum-3.2.29-4.fc15.noarch
     checksum_data = 249f21fb43c41381c8c9b0cd98d2ea5fa0aa165e81ed2009cfda74c05af67246
     checksum_type = sha256
     from_repo = fedora
     from_repo_revision = 1304429533
     from_repo_timestamp = 1304442346
     installed_by = 0
     reason = user
     releasever = $releasever
yumdb コマンドの詳細は yumdb(8) マニュアルページを参照してください。

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

Yum は単一のパッケージ、複数のパッケージ、および選択したパッケージのグループをインストールできます。

各パッケージのインストール

単一のパッケージおよびインストールされていない依存パッケージすべてをインストールするには、以下の形式でコマンドを入力します:
yum install package_name
引数として名前を追加することにより、同時に複数のパッケージをインストールすることもできます:
yum install package_name package_name
AMD64 や Intel64 マシンのような multilib システムにおいてパッケージをインストールしているならば、パッケージ名に .arch を追加することにより、(有効なリポジトリーにおいて利用可能ならば)パッケージのアーキテクチャーを指定できます。たとえば、i586sqlite2 をインストールするには、次のように入力します:
~]# yum install sqlite2.i586
同じような名前の複数のパッケージを素早くインストールするためにグロブ表現を使用することができます:
~]# yum install audacious-plugins-\*
パッケージ名とグロブ表現に加えて、ファイル名を yum install に提供することもできます。インストールしたいバイナリの名前がわかっているならば、yum install にパス名を与えることもできます:
~]# yum install /usr/sbin/named
そして、yum はそのパッケージ一覧を検索して、/usr/sbin/named を探して、もしあればインストールしたいかどうかを確認します。

ファイルを所有するパッケージの検索

named バイナリを含むパッケージをインストールしたいと思っているが、bin または sbin ディレクトリにインストールされるファイルがわからないならば、yum provides コマンドをグロブ表現を用いて使用します:
~]# yum provides "*bin/named"
Loaded plugins: langpacks, presto, refresh-packagekit
32:bind-9.8.0-3.P1.fc15.i686 : The Berkeley Internet Name Domain (BIND) DNS
                             : (Domain Name System) server
Repo        : fedora
Matched from:
Filename    : /usr/sbin/named
yum provides "*/file_name" は、file_name を含むパッケージを探すための一般的かつ有用なテクニックです。

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

パッケージグループはパッケージと似ています: それ自体は有用ではありませんが、あるものをインストールすることにより、共通の目的を取り扱っている依存したパッケージのグループを取ってきます。パッケージグループは名前と groupid を持ちます。yum grouplist -v コマンドは、すべてのパッケージグループの名前と、それに続けて括弧内にグループ ID を一覧表示します。グループ ID は必ず、以下の例にある kde-desktop のように、括弧の最後の組にあります:
~]# yum -v grouplist kde\*
Not loading "blacklist" plugin, as it is disabled
Loading "langpacks" plugin
Loading "presto" plugin
Loading "refresh-packagekit" plugin
Not loading "whiteout" plugin, as it is disabled
Adding en_US to language list
Config time: 0.900
Yum Version: 3.2.29
Setting up Group Process
rpmdb time: 0.002
group time: 0.995
Available Groups:
   KDE Software Compilation (kde-desktop)
   KDE Software Development (kde-software-development)
Done
完全なグループ名を(グループ ID 部分なしで) groupinstall に渡すことによりパッケージのグループをインストールできます:
yum groupinstall group_name
groupidを使用してインストールすることもできます:
yum groupinstall groupid
@-記号(yumgroupinstall を実行したいことを伝えます)を前につけると、 install コマンドにグループ ID を渡すこともできます:
yum install @group
たとえば、以下は代わりになりますが、KDE Desktop グループをインストールする同等の方法です:
~]# yum groupinstall "KDE Desktop"
~]# yum groupinstall kde-desktop
~]# yum install @kde-desktop

4.2.5. パッケージの削除

パッケージのインストールと同様に、Yumは個別のパッケージとパッケージのグループをアンインストール (RPM と Yum の言葉においては削除) することができます。

個別のパッケージの削除

特定のパッケージおよびそれに依存するあらゆるパッケージをアンインストールするには、root として以下のコマンドを実行します:
yum remove package_name
複数のパッケージをインストールするときのように、複数のパッケージ名をコマンドに追加することにより同時に削除できます。たとえば、totem, rhythmbox, および sound-juicer を削除するには、シェルプロンプトにおいて以下のように入力します:
~]# yum remove totem rhythmbox sound-juicer
install 同様、remove もこれらの引数をとることができます:
  • パッケージ名
  • グロブ表記
  • ファイルの一覧
  • 提供されるパッケージ

他のパッケージに依存するときのパッケージの削除

Yum はあるパッケージに依存しているパッケージを削除せずにそれを削除することはできません。この種の操作は RPM によってのみ実行できますが、推奨されません。そして、潜在的にシステムを機能しない状態にする可能性がありまる、またはアプリケーションを不正動作かつ/またはクラッシュさせる可能性があります。さらなる情報は RPM の章にある「アンインストール」を参照してください。

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

install 構文を用いて構文一致を使用してパッケージグループを削除できます:
yum groupremove group
yum remove @group
以下はそれぞれ異なりますが、KDE Desktop グループを削除する同等の方法です:
~]# yum groupremove "KDE Desktop"
~]# yum groupremove kde-desktop
~]# yum remove @kde-desktop

インテリジェントなパッケージグループの削除

yum にパッケージグループを削除するよう指示するとき、それらのパッケージが他のパッケージグループのメンバーであったり、他のインストールされているパッケージに依存したりしていても、そのグループにあるすべてのパッケージが削除されます。しかしながら、groupremove_leaf_only=1 ディレクティブを /etc/yum.conf 設定ファイルの [main] セクションに追加することにより、あらゆる他のパッケージやグループに必要とされないパッケージのみを削除するよう yum に指示することもできます。このディレクティブの詳細は「[main] オプションの設定」を参照してください。

4.2.6. 処理とトランザクションの履歴

yum history コマンドにより、ユーザーが時系列の Yum トランザクション、それらが発生した日時、影響されたパッケージの数、トランザクションが成功したか中断されたかどうか、およびトランザクション中に RPM データベースが変更されたかどうか、に関する情報を確認できます。加えて、このコマンドは特定のトランザクションを元に戻したり、再実行したりするために使用できます。

トランザクションの一覧

最新のトランザクション20個の一覧を表示するには、rootとして、引数なしで yum history を実行します、またはシェルプロンプトにおいて以下のように入力します:
yum history list
すべてのトランザクションを表示するには、all キーワードを追加します:
yum history list all
与えられた範囲にあるトランザクションのみを表示するには、以下の形式でコマンドを使用します:
yum history list start_id..end_id
特定のパッケージに関するトランザクションのみを一覧表示することもできます。そうするには、パッケージ名またはグロブ表現とともにコマンドを使用します:
yum history list glob_expression
たとえば、以下のように最初の5トランザクションの一覧が表示されます:
~]# yum history list 1..5
Loaded plugins: langpacks, presto, refresh-packagekit
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     5 | Jaromir ... <jhradilek>  | 2011-07-29 15:33 | Install        |    1
     4 | Jaromir ... <jhradilek>  | 2011-07-21 15:10 | Install        |    1
     3 | Jaromir ... <jhradilek>  | 2011-07-16 15:27 | I, U           |   73
     2 | System <unset>           | 2011-07-16 15:19 | Update         |    1
     1 | System <unset>           | 2011-07-16 14:38 | Install        | 1106
history list
すべての形式の yum history list コマンドは、以下の列から構成される各行をタブ区切りを生成します:
  • ID — 特定のトランザクションを識別する整数値です。
  • Login user — トランザクションを初期化するために使用されたログインセッションのユーザー名です。この情報は一般的にFull Name (完全名) <username (ユーザー名) > 形式で表現されます。(自動的なシステム更新のように)ユーザーにより発行されていないトランザクションは、System <unset> が代わりに使用されます。
  • Date and time — トランザクションが発行された日付と時刻です。
  • Action(s)表4.1「Action(s) フィールドの取り得る値」に説明されているように、トランザクション中に実行されたアクションの一覧です。
  • Altered — トランザクションにより影響を受けるパッケージの数です。表4.2「Altered フィールドの利用可能な値」に記載されているように追加の情報を続けることができます。
表4.1 Action(s) フィールドの取り得る値
アクション 略号 説明
Downgrade D 少なくとも1つのパッケージが古いバージョンにダウングレードされました。
Erase E 少なくとも 1 つのパッケージが削除されました。
インストール I 少なくとも 1 つの新規パッケージがインストールされました。
Obsoleting O 少なくとも一つのパッケージに推奨されないという印がついています。
再インストール R 少なくとも 1 つのパッケージを再インストールしました。
アップグレード U 少なくとも 1 つのパッケージを新しいバージョンに更新しました。

表4.2 Altered フィールドの利用可能な値
シンボル 説明
< トランザクションの終了前で、データベース rpmdb が Yum 以外で変更されました。
> トランザクションの終了後、rpmdb データベースが Yum 以外で更新されました
* トランザクションの終了に失敗しました。
# トランザクションの実行に成功しましたが、yum は 0 以外の終了コードを返しました。
E トランザクションの終了に成功しましたが、エラーか警告が表示されました。
P トランザクションが正常に終了しましたが、問題はすでにrpmdb データベースに存在しました。
s トランザクションが正常に終了しました。ただし、--skip-broken コマンドラインオプションが使用され、特定のパッケージがスキップされました。

Yum は過去のトランザクションすべての概要を表示することもできます。そうするには、root として以下の形式でコマンドを実行します:
yum history summary
指定した範囲のトランザクションのみを表示するには、次のように入力します:
yum history summary start_id..end_id
yum history list コマンドと同様に、パッケージ名またはグロブ表現を与えることにより特定のパッケージに関するトランザクションの概要を表示することもできます:
yum history summary glob_expression
たとえば、上に表示されたトランザクション履歴の概要は以下にあるように見えます:
~]# yum history summary 1..5
Loaded plugins: langpacks, presto, refresh-packagekit
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 listyum history summary はどちらもトランザクション指向です。与えられたパッケージに関連するトランザクションのみを表示できますが、パッケージのバージョンのような重要な詳細が不足しています。パッケージの観点からトランザクションを一覧表示するには、以下のコマンドを root として実行します:
yum history package-list glob_expression
たとえば、subscription-manager と関連するパッケージの履歴を追跡するには、シェルプロンプトにおいて以下のように入力します:
~]# yum history package-list subscription-manager\*
Loaded plugins: langpacks, presto, refresh-packagekit
ID     | Action(s)      | Package
-------------------------------------------------------------------------------
     3 | Updated        | subscription-manager-0.95.11-1.el6.x86_64
     3 | Update         |                      0.95.17-1.el6_1.x86_64
     3 | Updated        | subscription-manager-firstboot-0.95.11-1.el6.x86_64
     3 | Update         |                                0.95.17-1.el6_1.x86_64
     3 | Updated        | subscription-manager-gnome-0.95.11-1.el6.x86_64
     3 | Update         |                            0.95.17-1.el6_1.x86_64
     1 | Install        | subscription-manager-0.95.11-1.el6.x86_64
     1 | Install        | subscription-manager-firstboot-0.95.11-1.el6.x86_64
     1 | Install        | subscription-manager-gnome-0.95.11-1.el6.x86_64
history package-list
この例では、3つのパッケージがシステムの初期インストール中にインストールされました: subscription-manager, subscription-manager-firstboot, および subscription-manager-gnome。3回目のトランザクションにおいて、すべてのパッケージがバージョン 0.95.11 からバージョン 0.95.17 に更新されました。

トランザクションの検証

単一のトランザクションの概要を表示するには、root として yum history summary コマンドを以下の形式で使用します:
yum history summary id
特定のトランザクションを詳細に確認するには、root として以下のコマンドを実行します:
yum history info id
id 引数はオプションです。省略したとき、yum は自動的に最後のトランザクションを使用します。複数のトランザクションを指定するときに、範囲を使用することもできることに注意してください:
yum history info start_id..end_id
以下は、2つのトランザクションのサンプル出力です。それぞれ新規パッケージを1つインストールしています:
~]# yum history info 4..5
Loaded plugins: langpacks, presto, refresh-packagekit
Transaction ID : 4..5
Begin time     : Thu Jul 21 15:10:46 2011
Begin rpmdb    : 1107:0c67c32219c199f92ed8da7572b4c6df64eacd3a
End time       :            15:33:15 2011 (22 minutes)
End rpmdb      : 1109:1171025bd9b6b5f8db30d063598f590f1c1f3242
User           : Jaromir Hradilek <jhradilek>
Return-Code    : Success
Command Line   : install screen
Command Line   : install yum-plugin-fs-snapshot
Transaction performed with:
    Installed     rpm-4.8.0-16.el6.x86_64
    Installed     yum-3.2.29-17.el6.noarch
    Installed     yum-metadata-parser-1.1.2-16.el6.x86_64
Packages Altered:
    Install screen-4.0.3-16.el6.x86_64
    Install yum-plugin-fs-snapshot-1.1.30-6.el6.noarch
history info
トランザクションを実行したときに使用された設定オプションや、どのリポジトリからパッケージがインストールされたか、特定のパッケージがなぜインストールされたか、などのような追加の情報を表示することもできます。特定のトランザクションに対してどの追加の情報が利用可能であるかを決めるには、シェルプロンプトにおいて root として以下のように入力します:
yum history addon-info id
yum history info と同様、id を与えないとき、yum は自動的に最後のトランザクションを使用します。最後のトランザクションを参照する別の方法は last キーワードを使用することです:
yum history addon-info last
たとえば、前の例にある最初のトランザクションに対して、yum history addon-info コマンドは以下のように出力します:
~]# yum history addon-info 4
Loaded plugins: langpacks, presto, refresh-packagekit
Transaction ID: 4
Available additional history information:
  config-main
  config-repos
  saved_tx

history addon-info
この例では、3種類の情報が利用可能です:
  • config-main — トランザクション中に使用される Yum 全体オプションです。全体オプションを変更する方法については「[main] オプションの設定」を参照してください。
  • config-repos — 各 Yum リポジトリーに対するオプションです。各リポジトリーに対するオプションを変更する方法については「[repository] オプションの設定」を参照してください。
  • saved_tx — 他のマシンにおいてトランザクションを繰り返すために yum load-transaction コマンドにより使用できるデータです(以下、参照)。
選択した形式の追加の情報を表示するには、root として以下のコマンドを実行します:
yum history addon-info id information

トランザクションの復帰および繰り返し

トランザクション履歴の確認のほか、yum history コマンドは選択したトランザクションの復帰および繰り返しをする手段を提供します。トランザクションを復帰するには、シェルプロンプトにおいて以下のコマンドを root として入力します:
yum history undo id
特定のトランザクションを繰り返すには、root として以下のコマンドを実行します:
yum history redo id
どちらのコマンドも、最後に実行したトランザクションを取り消すまたは繰り返すために、last キーワードを受け付けます。
yum history undoyum history redo コマンドはどちらも単にトランザクション中に実行された手順を復帰または繰り返すだけであることに注意してください。トランザクションが新しいパッケージをインストールしているならば、yum history undo コマンドはそれをアンインストールします。逆もまた同様です。可能ならば、このコマンドはすべての更新したパッケージをそれらの前のバージョンにダウングレードしようとしますが、これらの古いパッケージはもはや利用可能ではないかもしれません。もしシステムを更新前の状態に復元できる必要があるならば、「プラグインの説明」において説明されている fs-snapshot プラグインの使用を検討してください。
いくつかの同一システムを管理するとき、Yumはそのうちのどれか1つにおいてトランザクションを実行し、トランザクションの詳細をファイルに保存し、テスト後に同じトランザクションを残りのシステムにおいて同じように繰り返すこともできるようにします。トランザクションの詳細をファイルに保存するには、シェルプロンプトにおいて root として以下のように入力します:
yum -q history addon-info id saved_tx > file_name
一度このファイルを対象システムにコピーすると、root として以下のコマンドを使用することによりトランザクションを繰り返すことができます:
yum load-transaction file_name
しかしながら、ファイルに保存されている rpmdb バージョンは対象システムにおけるバージョンと同一でなければいけません。yum version nogroups コマンドを使用することにより rpmdb のバージョンを確認できます。

新規トランザクション履歴の開始

Yum はトランザクション履歴を単独の SQLite データベースファイルに保存します。新規トランザクション履歴を開始するには、root として以下のコマンドを実行します:
yum history new
これにより、新しい空のデータベースファイルが /var/lib/yum/history/ ディレクトリに作成されます。古いトランザクション履歴は保持されますが、新しいデータベースがディレクトリに存在する限りアクセスできません。

4.3. Yum と Yum リポジトリーの設定

yum と関連ユーティリティの設定ファイルは /etc/yum.conf にあります。このファイルは、必須の [main] セクション(全体に影響を持つ Yum オプションを設定できます)を含みます。また1つ以上の [repository] セクション(リポジトリ固有のオプションを設定できます)を含むかもしれません。しかしながら、ベストプラクティスは /etc/yum.repos.d/ ディレクトリに新規または既存の .repo ファイルにおいてそれぞれのリポジトリを定義することです。/etc/yum.conf ファイルの [main] セクションにおいて定義した値は、それぞれの [repository] セクションにおいて設定した値をオーバーライドするかもしれません。
このセクションは以下の方法を説明します:
  • /etc/yum.conf 設定ファイルの [main] セクションを編集することにより、Yum の全体オプションを設定します;
  • /etc/yum.conf および /etc/yum.repos.d/ ディレクトリの .repo にある [repository] セクションを編集することにより各リポジトリに対するオプションを設定します;
  • バージョンとアーキテクチャーを動的に正しく取り扱えるように /etc/yum.conf および /etc/yum.repos.d/ ディレクトリにあるファイルに Yum 変数を使用します;
  • コマンドラインで Yum リポジトリの追加、有効化および無効化をします、また、
  • 独自 Yum リポジトリを導入します。

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

/etc/yum.conf 設定ファイルはちょうど一つの [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
…ここで value は次のどれかです:
0yum はクリティカルなアクションの実行について確認のプロンプトを表示します。これがデフォルトです。
1 — クリティカルな yum アクションについて確認のプロンプトを表示します。もし assumeyes=1 が設定されていると、yum はコマンドラインにおいて -y オプションをつけたときと同じ方法の動作をします。
cachedir=directory
…ここで directory は、Yum がキャッシュとデータベースファイルを保存するディレクトリの絶対パスです。Yum のキャッシュディレクトリはデフォルトで /var/cache/yum/$basearch/$releasever です。
$basearch および $releasever Yum 変数の記述については「Yum 変数の使い方」を参照してください。
debuglevel=value
…ここで value1 から 10 の間の整数です。debuglevel 値により大きな値を設定することにより、yum がより詳細なデバッグ情報を表示します。debuglevel=0 はデバッグ出力を無効にします。debuglevel=2 がデフォルトです。
exactarch=value
…ここで value は次のどれかです:
0 — パッケージを更新するときに、厳密なアーキテクチャーを考慮しません。
1 — パッケージを更新するときに、厳密なアーキテクチャーを考慮します。この設定をすると、yum は、システムにすでにインストールされている i386 パッケージを更新するために、i686 パッケージをインストールすることはしません。これがデフォルトです。
exclude=package_name [more_package_names]
このオプションはインストール/更新中にキーワードによりパッケージを除外できます。スペース区切りでパッケージの一覧をクオートすることにより、除外する複数のパッケージを一覧にできます。ワイルドカード (たとえば、* および ?) を使用するシェルのグロブ表現が許可されます。
gpgcheck=value
…ここで value は次のどれかです:
0 — ローカルパッケージのインストールを含め、すべてのリポジトリーにおいてパッケージの GPG 署名検証を無効にします。
1 — ローカルパッケージのインストールを含め、すべてのリポジトリーにおいてすべてのパッケージの GPG 署名検証を有効にします。gpgcheck=1 がデフォルトで、すべてのパッケージの署名がチェックされます。
このオプションが /etc/yum.conf[main] セクションにおいて設定されていると、すべてのリポジトリに対して GPG チェックのルールを設定します。しかしながら、代わりに各リポジトリに対して gpgcheck=value を設定することもできます。つまり、あるリポジトリにおいて GPG チェックを有効にしながら、他において無効にすることができます。もし /etc/yum.conf にあるならば、各リポジトリに対して対応する .repo ファイルにおいて gpgcheck=value を設定することによりデフォルトをオーバーライドします。
GPG 署名チェックに関する詳細は「パッケージの署名を確認する」を参照してください。
groupremove_leaf_only=value
…ここで value は次のどれかです:
0yum はパッケージグループを削除するとき各パッケージの依存物を確認しません。この設定を用いると、yum は、他のパッケージやグループにより必要とされるパッケージかどうかによらず、パッケージグループにあるすべてのパッケージを削除します。groupremove_leaf_only=0 はデフォルトです。
1yum は、パッケージグループを削除するとき各パッケージの依存性を確認して、あらゆる他のパッケージやグループにより必要とされないパッケージのみを削除します。
パッケージの削除に関する詳細はインテリジェントなパッケージグループの削除を参照してください。
installonlypkgs=space separated list of packages
ここに yumインストールできるが、更新しないパッケージの一覧を空白区切りで提供できます。デフォルトでインストールのみとなっているパッケージの一覧は yum.conf(5) マニュアルページを参照してください。
installonlypkgs ディレクティブを /etc/yum.conf に追加したければ、yum.conf(5) の installonlypkgs の中に一覧化されているものすべてを含めて、インストールのみにするすべてのパッケージを一覧にすることを確認します。とくに、kernel パッケージは必ず installonlypkgs (デフォルトであります) に一覧化すべきです。また、デフォルトのカーネルが起動に失敗した場合に、バックアップのカーネルが必ず利用可能であるよう、\ninstallonly_limit は必ず 2 よりも大きな値に設定すべきです。
installonly_limit=value
…ここで valueinstallonlypkgs ディレクティブに一覧されている単一パッケージすべてに対して同時にインストールできるバージョンの最大数を表す整数です。
installonlypkgs ディレクティブのデフォルトはそれぞれの異なる kernel パッケージを含みます。そのため、installonly_limit の値を変更することにより、あらゆる単一の kernel パッケージについてインストールされたバージョンの最大数にも影響します。/etc/yum.conf に記載されたデフォルト値は installonly_limit=3 です。そして、この値を減らすこと、特に 2 以下にすることは推奨されません。
keepcache=value
…ここで value は次のどれかです:
0 — 正常にインストールされた後、ヘッダーとパッケージのキャッシュを保持しません。これがデフォルトです。
1 — 正常にインストールした後、キャッシュを保持します。
logfile=file_name
…ここで file_nameyum がログ出力を書き込むファイルの絶対パスです。デフォルトで yum/var/log/yum.log にログをとります。
multilib_policy=value
…ここで value は次のどれかです:
best — このシステムに最適なアーキテクチャーをインストールします。たとえば、AMD64 システムにおいて multilib_policy=best を設定することにより、yum はすべてのパッケージの 64 ビットバージョンをインストールします。
all — 常にすべてのパッケージについてすべての利用可能なアーキテクチャーをインストールします。たとえば、AMD64 システムにおいて multilib_policyall に設定すると、yum は、i586 と AMD64 の両方が利用可能ならば、パッケージの両方のバージョンをインストールします。
obsoletes=value
…ここで value は次のどれかです:
0 — 更新を実行するとき yum の推奨されない処理ロジックを無効にします。
1 — 更新を実行するときに yum の推奨されない処理ロジックを有効にします。あるパッケージが他のパッケージを推奨しないよう SPEC ファイルにおいて宣言するとき、後者のパッケージは前者のパッケージがインストールされるときに前者のパッケージにより置き換えられます。たとえば、パッケージが名前変更されるとき、推奨しないことが宣言されます。obsoletes=1 がデフォルトです。
plugins=value
…ここで value は次のどれかです:
0 — Yum プラグイン全体を無効にします。

すべてのプラグインを無効にすることは推奨されません

あるプラグインは重要な Yum サービスを提供するので、すべてのプラグインを無効にすることは推奨されません。プラグインを全体的に無効にすることは、便利なオプションとして提供され、一般的に Yum に関する潜在的な問題を診断するときにのみ推奨されます。
1 — すべての Yum プラグインを有効にします。plugins=1 を用いても、プラグインの設定ファイルにおいて enabled=0 と設定されている特定の Yum プラグインを無効にすることもできます。
さまざまな Yum プラグインの詳細は「Yum プラグイン」を参照してください。プラグインの制御に関する詳細は「Yum プラグインの無効化、有効化、設定」を参照してください。
reposdir=directory
…ここで directory.repo ファイルが置かれる場所の絶対パスです。すべての .repo ファイルはリポジトリの情報(/etc/yum.conf[repository] セクションと似ています)を含みます。yum はトランザクションのために使用するリポジトリのマスター一覧を作成するために、.repo ファイルと /etc/yum.conf ファイルの [repository] セクションからすべてのリポジトリの情報を収集します。reposdir が設定されていなければ、yum はデフォルトの /etc/yum.repos.d/ ディレクトリを使用します。
retries=value
…ここで value0 以上の整数です。この値は yum がエラーを返す前にファイルの取得を試みる回数を設定します。これを 0 に設定することにより、yum が無限に再試行します。デフォルト値は 10 です。
利用可能な [main] オプションの完全な一覧は、yum.conf(5) マニュアルページの [main] OPTIONS セクションを参照してください。

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

[repository] セクション、ここで repositorymy_personal_repo のような一意なリポジトリ ID です(空白は許可されません)、は個々の Yum リポジトリを定義できます。
以下は [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
…ここで value は次のどれかです:
0 — 更新およびインストールを実行するとき派ケージソースとしてこのリポジトリを含めません。これは素早くリポジトリをオンオフする簡単な情報です。これは更新またはインストールのために有効にしたくないリポジトリから単一のパッケージを希望するときに有用です。
1 — このリポジトリをパッケージソースとして含めます。
リポジトリを有効または無効にするには、--enablerepo=repo_name or --disablerepo=repo_name オプションを yum に渡すことにより、または、PackageKit ユーティリティのソフトウェアの追加/削除 ウィンドウにより実行できます。
さらに多くの [repository] オプションが存在します。完全な一覧は yum.conf(5) マニュアルページの [repository] OPTIONS セクションを参照してください。

4.3.3. Yum 変数の使い方

yum コマンドと Yum 設定ファイル(つまり、/etc/yum.conf および /etc/yum.repos.d/ ディレクトリにあるすべての .repo ファイル)において以下の組み込み変数を使用および参照できます:
$releasever
Fedora のリリースバージョンを参照するためにこの変数を使用できます。Yum は /etc/yum.conf 設定ファイルの distroverpkg=value 行から $releasever の値を取得します。もし /etc/yum.conf にそのような行がなければ、yumredhat-release パッケージからバージョン番号を取り出すことにより正しい値を推測します。
$arch
Python の os.uname() 関数を呼び出すとき返されるように、システムの CPU アーキテクチャーを参照するためにこの値を使用できます。$arch の有効な値は次のとおりです: i586, i686 および x86_64
$basearch
システムの基本アーキテクチャーを参照するために $basearch を使用できます。たとえば、i686 と i586 のマシンはどちらも i386 の基本アーキテクチャーを持ちます。また、AMD64 と Intel64 のマシンは x86_64 の基本アーキテクチャーを持ちます。
$YUM0-9
これらの10個の変数は、同じ名前のシェル環境変数の値でそれぞれ置き換えられます。これらの変数のどれかが(たとえば /etc/yum.conf において)参照され、同じ名前を持つシェル環境変数が存在しなければ、設定ファイルの変数は置き換えられません。
個別の変数を定義する、または既存のものの値を上書きするには、/etc/yum/vars/ ディレクトリに、変数と同じ名前を持つファイルを($ 記号なしで)作成します。そして、その最初の行に希望する値を追加します。
たとえば、リポジトリ記述はしばしばオペレーティングシステム名を含みます。$osname という新しい変数を定義するには、最初の行に Fedora を持つ新しいファイルを作成して、/etc/yum/vars/osname として保存します:
~]# echo "Red Hat Enterprise Linux" > /etc/yum/vars/osname
Fedora 16 の代わりに、.repo ファイルにおいて以下を使用することができます:
name=$osname $releasever

4.3.4. 現在の設定の表示

Yum の全体オプション(つまり、/etc/yum.conf ファイルの [main] セクションにおいて指定されているオプション)の現在の値を表示するには、コマンドラインのオプションなしで yum-config-manager を実行します:
yum-config-manager
異なる設定セクションの内容を一覧表示するには、以下の形式でコマンドを使用します:
yum-config-manager section
すべての一致するセクションの設定を表示するためにグロブ表現を使用することもできます:
yum-config-manager glob_expression
たとえば、すべての設定オプションとそれぞれ対応する値を一覧表示するには、シェルプロンプトにおいて以下のように入力します:
~]$ yum-config-manager main \*
Loaded plugins: langpacks, presto, refresh-packagekit
================================== 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
[出力の省略]

4.3.5. Yum リポジトリの追加・有効化および無効化

「[repository] オプションの設定」は Yum リポジトリを定義するために使用できるさまざまなオプションを説明しています。このセクションは yum-config-manager コマンドを使用することによりリポジトリを追加、有効化、および無効化する方法について説明しています。

Yum リポジトリの追加

新しいリポジトリを定義するには、/etc/yum.conf ファイルに [repository] セクションを追加するか、/etc/yum.repos.d/ ディレクトリに .repo ファイルを追加します。このディレクトリにある .repo ファイル拡張子を持つすべてのファイルは yum により読み込まれます。/etc/yum.conf にリポジトリを定義する代わりに、ここに定義することが最も良いです。

信頼できないソフトウェア提供元を使用するとき注意してください

検証されていない、もしくは信頼されていないソフトウェア提供元からソフトウェアを取得またはインストールすることは、潜在的なセキュリティリスクになります、または、セキュリティ、安定性、互換性およびメンテナンス性の問題を引き起こす可能性があります。
Yum リポジトリは一般的に自身の .repo ファイルを提供します。そのようなリポジトリをシステムに追加して有効にするには、root として以下のコマンドを実行します:
yum-config-manager --add-repo repository_url
…ここで repository_url.repo ファイルへのリンクです。たとえば、http://www.example.com/example.repo にあるリポジトリを追加するには、シェルプロンプトにおいて以下のとおり入力します:
~]# yum-config-manager --add-repo http://www.example.com/example.repo
Loaded plugins: langpacks, presto, refresh-packagekit
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 を使用します)。代わりに、すべての一致するリポジトリを有効にするためにグロブ表現を使用できます。
yum-config-manager --enable glob_expression
たとえば、[example], [example-debuginfo], および [example-source] セクションに定義されたリポジトリーを無効にするには、次のように入力します:
~]# yum-config-manager --enable example\*
Loaded plugins: langpacks, presto, refresh-packagekit
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/6Server
baseurl = http://www.example.com/repo/6Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/6Server/example
[出力の省略]
成功したとき、yum-config-manager --enable コマンドが現在のリポジトリ設定を表示します。

Yum リポジトリの無効化

Yum リポジトリを無効にするには、rootとして以下のコマンドを実行します:
yum-config-manager --disable repository
…ここで repository は一意なリポジトリ ID です(利用可能なリポジトリ ID を一覧表示するには yum repolist all を使用します)。yum-config-manager --enable と同様に、すべての一致するリポジトリを同時に無効にするためにグロブ表現を使用できます。
yum-config-manager --disable glob_expression
成功したとき、yum-config-manager --disable コマンドが現在のリポジトリ設定を表示します。

4.3.6. Yum リポジトリーの作成

Yum リポジトリーを構築するには、これらの手順に従ってください:
  1. createrepo パッケージのインストール:
    ~]# yum install createrepo
  2. /mnt/local_repo/ のような 1 つのディレクトリーに全パッケージをコピーします。
  3. そのディレクトリーで createrepo --database を実行します:
    ~]# createrepo --database /mnt/local_repo

    Fedora 5 で createrepo コマンドを使う

    Fedora 16 の RPM パッケージは XZ ロスなしデータ圧縮形式を使用して圧縮されていて、SHA-256 のような代替の(強力な)ハッシュアルゴリズムを使用して署名もされているので、Fedora パッケージ用のパッケージのメタ情報を作成するために Fedora 5 において createrepo を実行することはできません。createrepo コマンドはパッケージを開いて検査するために rpm に依存します。また、Fedora 5 において rpm は改善された Fedora 16 RPM パッケージ形式を開けません。
これにより Yum リポジトリに対して必要なメタデータだけでなく、yum 操作を速度向上させるために sqlite データベースを作成します。

4.4. Yum プラグイン

Yum はその機能を拡張および向上させるプラグインを提供します。特定のプラグインはデフォルトでインストールされます。あらゆる yum コマンドを呼び出すときは必ず、Yum はプラグインがあればどれが読み込まれて有効化されているかを必ず通知します。たとえば:
~]# yum info yum
ロードされたプラグイン: langpacks, presto, refresh-packagekit
[出力の省略]
Loaded plugins に続くプラグイン名は --disableplugins=plugin_name オプションに対して提供できる名前であることに注意してください。

4.4.1. Yum プラグインの無効化、有効化、設定

Yum プラグインを有効にするには、/etc/yum.conf[main] セクションに plugins= で始まる行が存在して、その値が 1 に設定されていることを確実にします:
plugins=1
この行を plugins=0 に変更することにより、すべてのプラグインを無効にできます。

すべてのプラグインを無効にすることは推奨されません

あるプラグインは重要な Yum サービスを提供するので、すべてのプラグインを無効にすることは推奨されません。プラグインを全体的に無効にすることは、便利なオプションとして提供され、一般的に Yum に関する潜在的な問題を診断するときにのみ推奨されます。
すべてのインストールされたプラグインは /etc/yum/pluginconf.d/ ディレクトリに自身の設定ファイルを持ちます。これらのファイルにプラグイン固有のオプションを設定できます。たとえば、これは refresh-packagekit プラグインの refresh-packagekit.conf 設定ファイルです:
[main]
enabled=1
プラグインの設定ファイルは必ず [main] セクション(Yum の /etc/yum.conf ファイルと似ています)を含みます。yum コマンドを実行するときにプラグインを有効にするかどうかを制御する enabled= オプションがあります(もしなければ置くことができます)。
/etc/yum.conf において enabled=0 を設定することにより、すべてのプラグインを無効にしているならば、すべてのプラグインは各設定ファイルにおいて有効にしているかどうかによらず無効にされます。
単に1回の yum コマンドのためにすべての Yum プラグインを無効にしたいならば、--noplugins オプションを使用します。
1回の yum コマンドのために1つかそれ以上の Yum プラグインを無効にしたいならば、コマンドに --disableplugin=plugin_name オプションを追加します。たとえば、システムを更新中に presto プラグインを無効にするには、次のとおり入力します:
~]# yum update --disableplugin=presto
--disableplugin= オプションに提供するプラグイン名は、すべての yum コマンドの出力において Loaded plugins 行に表示される名前と同じものです。複数のプラグインの名前をコンマで区切ることにより、それらを無効にできます。さらに、グロブ表現を使用することにより、複数のプラグイン名に一致されたり、長いものを省略したりできます:
~]# yum update --disableplugin=presto,refresh-pack*

4.4.2. 追加の Yum プラグインのインストール

Yum プラグインは通常 yum-plugin-plugin_name パッケージ命名規約に従いますが、必ずしもそうとは限りません。たとえば、presto プラグインを提供するパッケージは yum-presto という名前です。他のパッケージをインストールする方法と同じように Yum プラグインをインストールできます。たとえば、security プラグインをインストールするには、シェルプロンプトにおいて以下のように入力します:
~]# yum install yum-plugin-security

4.4.3. プラグインの説明

以下の一覧は有用な Yum プラグインのいくつかを説明しています:
fs-snapshot (yum-plugin-fs-snapshot)
fs-snapshot プラグインは、システムの更新やパッケージの削除のようなトランザクションを進める前にファイルシステムのスナップショットを作成するよう Yum を拡張します。トランザクションにより行われた変更が期待しないものとユーザーが思えば、このメカニズムによりユーザーがスナップショットに保存されている変更をロールバックできるようになります。
プラグインが機能するためには、ルートファイルシステム(つまり、/)が LVM (Logical Volume Manager) または Btrfs ボリューム上になければいけません。LVM ボリュームにおいて fs-snapshot プラグインを使用するには、以下の手順に従います:
  1. ルートファイルシステムを持つボリュームグループが十分な空きエクステントを持つことを確実にします。必要な容量は、スナップショットのライフサイクルにおいて予想される、元の論理ボリュームへの変更量によります。適切なデフォルトは元の論理ボリューム容量の 50–80 % です。
    特定のボリュームグループに関する詳細な情報を表示するには、root として以下の形式で vgdisplay コマンドを実行します:
    vgdisplay volume_group
    フリーなエクステント数は Free PE / Size 行に一覧表示されます。
  2. ルートファイルシステムを持つボリュームグループが十分な空きエクステントを持たなければ、新しい物理ボリュームを追加します:
    1. 論理ボリュームマネージャーを用いた物理ボリュームを初期化するには、root として、以下の形式で pvcreate コマンドを実行します。
      pvcreate device
    2. 物理ボリュームをボリュームグループに追加するには、root として以下の形式で vgextend コマンドを使用します:
      vgextend volume_group physical_volume
  3. /etc/yum/pluginconf.d/fs-snapshot.conf に置かれている設定ファイルを編集します。そして、以下の変更を [lvm] セクションに行います:
    1. enabled オプションの値を 1 に変更します:
      enabled = 1
    2. lvcreate_size_args 行の先頭からハッシュ記号(つまり、#)を削除し、論理エクステントの数をスナップショットのために割り当てるよう調整します。たとえば、元の論理ボリュームの容量の 80 % を割り当てるには、以下を使用します:
      lvcreate_size_args = -l 80%ORIGIN
    利用可能な設定オプションの完全な一覧は表4.3「サポートされる fs-snapshot.conf ディレクティブ」を参照してください。
  4. 希望する yum コマンドを実行し、変更を確認してトランザクションを進める前に、fs-snapshot が読み込んだプラグイン(Loaded plugins 行)の一覧に含まれることを確実にします。fs-snapshot プラグインは、それぞれの影響する論理ボリュームに対して以下の形式で行を表示します:
    fs-snapshot: snapshotting file_system (/dev/volume_group/logical_volume): logical_volume_yum_timestamp
  5. システムが期待するとおりに動作していることを確認します:
    • 変更を保持することを決めたならば、root として lvremove コマンドを実行することにより、スナップショットを削除します:
      lvremove /dev/volume_group/logical_volume_yum_timestamp
    • 変更を元に戻して、スナップショットに保存された状態にファイルシステムを復元することを決めたならば、以下の手順をとります:
      1. スナップショットを元々の論理ボリュームに統合するには、root として、以下の形式でコマンドを実行します:
        lvconvert --merge /dev/volume_group/logical_volume_yum_timestamp
        lvconvert コマンドは変更を反映するために必要となる再起動を促します。
      2. 指示されたとおりシステムを再起動します。シェルプロンプトにおいて root として以下のように入力することに実行することもできます:
        reboot
Btrfs ファイルシステムにおいて fs-snapshot を使用するには、以下の手順を実行します:
  1. 希望する yum コマンドを実行し、変更を確認してトランザクションを進める前に、fs-snapshot が読み込んだプラグイン(Loaded plugins 行)の一覧に含まれることを確実にします。fs-snapshot プラグインは、それぞれの影響するファイルシステムに対して以下の形式で行を表示します:
    fs-snapshot: snapshotting file_system: file_system/yum_timestamp
  2. システムが期待するとおりに動作していることを確認します:
    • 変更を保持することを決めたならば、オプションで期待しないスナップショットを削除できます。Btrfs スナップショットを削除するには、root として以下の形式でコマンドを使用します:
      btrfs subvolume delete file_system/yum_timestamp
    • 変更を元に戻して、スナップショットに保存されている状態にファイルシステムを戻すことを決めたならば、以下の手順をとります:
      1. root として以下のコマンドを使用することにより特定のスナップショットの識別子を確認できます:
        btrfs subvolume list file_system
      2. root として、このスナップショットをデフォルトでマウントするようシステムを設定します:
        btrfs subvolume set-default id file_system
      3. システムを再起動します。シェルプロンプトにおいて root として以下のように入力することにより実行できます:
        reboot
Fedora 16 における注意事項として、Btrfs はこのファイルシステムを経験できるようにするテクノロジープレビューとして含まれ、64-bit x86 アーキテクチャーにおいてのみ利用可能です。価値のあるデータを含む、または重要なシステムの実行に不可欠であるかもしれないパーティションに対して Btrfs を使用しないでください。
論理ボリューム管理、Btrfs、およびファイルシステムスナップショットの詳細は Fedora 16 Storage Administration Guide を参照してください。プラグインとその設定に関する詳細は、yum-fs-snapshot(1) および yum-fs-snapshot.conf(5) のマニュアルページを参照してください。
表4.3 サポートされる fs-snapshot.conf ディレクティブ
セクション 説明
[main] enabled=value プラグインの有効化または無効化をできます。value1 (有効) または 0 (無効) でなければいけません。インストールされるとき、プラグインはデフォルトで有効になっています。
exclude=list 特定のファイルシステムを除外できます。値はスナップショットをしたくないマウントポイント(たとえば、/srv /mnt/backup)のスペース区切りの list でなければいけません。このオプションはデフォルトにより設定ファイルに含まれません。
[lvm] enabled=value LVM ボリュームにおいてプラグインの使用を有効化または無効化できます。value1 (有効) または 0 (無効) のどちらかでなければいけません。このオプションはデフォルトで無効にされています。
lvcreate_size_args=value 論理ボリュームのスナップショットの容量を指定できます。\nvalue は有効な引数が続けられる lvcreate ユーティリティに対する -l または -L コマンドラインオプション(たとえば、-l 80%ORIGIN)でなければいけません。

presto (yum-presto)
presto プラグインは、presto メタ情報を有効にしたリポジトリから更新している間に、delta RPM パッケージのダウンロードすることに関するサポートを Yum に追加します。delta RPM は、RPM パッケージを要求しているクライアントにインストールされているパッケージのバージョンとリポジトリにある更新されたバージョンの間の差異のみを含みます。
delta RPM をダウンロードすることにより、更新されたパッケージ全体をダウンロードするよりもかなり早くなり、更新を相対的に速度向上できます。一度 delta RPM がダウンロードされると、現在インストールされているパッケージに変更点を適用するためにリビルドしなければいけません、このように完全かつ更新されたパッケージを作成します。このプロセスはインストールしているマシンにおいて CPU 時間を使用します。そのため、delta RPM を使用することは、ネットワーク接続に依存するダウンロード時間、および CPU の限界によるリビルド時間のトレードオフになります。presto プラグインを使用することは、比較的低速なネットワーク接続を持つ高速なマシンとシステムのために推奨されます。一方、非常に高速な接続を持つ比較的低速なマシンは、通常の RPM パッケージをダウンロードすること、つまり presto を無効にすることの恩恵を受けられるかもしれません。
refresh-packagekit (PackageKit-yum-plugin)
refresh-packagekit プラグインは yum を実行するときに必ず PackageKit の管理情報を更新します。refresh-packagekit プラグインはデフォルトでインストールされます。
rhnplugin (yum-rhn-plugin)
rhnpluginRHN Classic への接続サポートを提供します。これにより、RHN Classic を用いて登録されたシステムはこのシステムからパッケージを更新およびインストールできるようになります。
プラグインに関する詳細はrhnplugin(8) マニュアルページを参照してください。
security (yum-plugin-security)
セキュリティ更新に関する情報を探して、簡単に適用することは、すべてのシステム管理者に対してしばしば重要になります。このため、Yum は security プラグインを提供します。これは非常に有用なセキュリティ関連のコマンド、サブコマンドおよびオプションを用いて yum を拡張します。
以下のようにセキュリティ関連の更新をチェックできます:
~]# yum check-update --security
Loaded plugins: langpacks, presto, refresh-packagekit, security
Limiting package lists to security relevant ones
updates-testing/updateinfo                               | 329 kB     00:00
9 package(s) needed for security, out of 270 available

ConsoleKit.x86_64                    0.4.5-1.fc15                  updates
ConsoleKit-libs.x86_64               0.4.5-1.fc15                  updates
ConsoleKit-x11.x86_64                0.4.5-1.fc15                  updates
NetworkManager.x86_64                1:0.8.999-2.git20110509.fc15  updates
NetworkManager-glib.x86_64           1:0.8.999-2.git20110509.fc15  updates
[出力の省略]
セキュリティ・アドバイザリにより影響されるパッケージを更新するには yum update --security または yum update-minimal --security を使用できます。これらのコマンドはどちらも、システムにあるセキュリティ・アドバイザリが発行されたパッケージをすべて更新します。yum update-minimal --security はセキュリティ・アドバイザリの一部として公開された最新のパッケージに更新します。ここで yum update --security はセキュリティ・アドバイザリにより影響されるすべてのパッケージをその利用可能なパッケージの最新バージョンに更新します。
言い換えると、たとえば:
  • kernel-2.6.38.4-20 パッケージはシステムにインストールされました;
  • the kernel-2.6.38.6-22 パッケージがセキュリティアップデートとしてリリースされました;
  • then kernel-2.6.38.6-26 はバグ修正アップデートとしてリリースされました、
...そして yum update-minimal --securitykernel-2.6.38.6-22 に更新します。また、yum update --securitykernel-2.6.38.6-26 に更新します。保守的な管理者はできる限りパッケージを更新することにより生じるリスクを減らすために update-minimal を使用したいと思うかもしれません。
security プラグインが yum に追加する機能改善に関する使用法の詳細とさらなる説明は、yum-security(8) マニュアルページを参照してください。

4.5. その他のリソース

http://yum.baseurl.org/wiki/Guides
Yum wiki の Yum Guides セクションはさらなるドキュメントが含まれます。

第5章 PackageKit

Fedora は、あなたのシステムと互換性のあるパッケージを表示、管理、更新、インストールおよびアンインストールするために PackageKit を提供します。PackageKit は、GNOME パネルメニューから、または PackageKit が更新を利用可能であることを通知するときに通知領域から開くことができるグラフィカルインターフェースがいくつかから構成されます。PackageKit のアーキテクチャーおよび利用可能なフロントエンドの詳細は、「PackageKit アーキテクチャー」を参照してください。

5.1. ソフトウェアの更新を用いたパッケージの更新

Activities メニューからアプリケーションシステムツールソフトウェアの更新をクリックすることにより、ソフトウェアの更新を開くことができます。またはシェルプロンプトにおいて、gpk-update-viewer コマンドを実行します。ソフトウェアの更新ウィンドウにおいて、すべての利用可能な更新を、更新されるパッケージ(.rpm を除き、CPU アーキテクチャーを含みます)、パッケージの概要、および一般的に更新が提供する変更の概要とともに一覧表示します。インストールしたくないすべての更新は、更新に対応するチェックボックスをチェック解除することにより、ここで選択解除できます。
ソフトウェアの更新を用いたアップデートのインストール
PackageKit のソフトウェアの更新ウィンドウを用いた 56 個の更新のインストール
図5.1 ソフトウェアの更新を用いたアップデートのインストール

ソフトウェアの更新ウィンドウのみに表示された更新は、利用可能な更新に対して現在インストールされているパッケージを表しています。 それらのパッケージに依存するもの(システムにある既存のパッケージか新しいものかどちらか)は、更新のインストールをクリックするまで表示されません。
PackageKit は、システムに変更を加える要求をするときは必ず PolicyKit ツールキットにより提供される精密なユーザー認証 機能を使用します。PackageKit にパッケージの更新、インストールまたは削除を指示すると必ず、システムに変更を加える前にスーパーユーザーのパスワードを入力するよう要求されます。
kernel パッケージを更新するよう PackageKit に指示すると、インストール後にプロンプトが表示され、システムを再起動して、新しくインストールしたカーネルから起動したいかどうかを尋ねられます。

5.1.1. 更新の確認間隔の設定

アクティビティメニューからアプリケーションその他ソフトウェアの更新を選択することにより、ソフトウェアの更新の設定ウィンドウが開きます。更新の設定タブにより、PackageKit がパッケージの更新を確認する間隔、およびすべての更新またはセキュリティ更新のみを自動的にインストールするかどうかを定義できます。モバイル接続を使用するとき更新を確認するボックスをチェック解除しておくことにより、ダウンロードするデータ量に対して課金される無線接続を使用しているときに、膨大な帯域使用を避けるために適しています。
PackageKit の更新の確認間隔の設定
PackageKit の更新確認間隔の設定
図5.2 PackageKit の更新の確認間隔の設定

5.1.2. ソフトウェアソースの設定

ソフトウェアの更新をインストールするために使用するパッケージリポジトリを選択するには、Activities メニューからアプリケーションその他ソフトウェアの更新を選択し、ソフトウェアの更新の設定ソフトウェアのソースをクリックします。
PackageKit のソフトウェアソースの設定
PackageKit のソフトウェアソースの設定
図5.3 PackageKit のソフトウェアソースの設定

PackageKit はソフトウェアのソースとして\n Yum リポジトリを参照します。すべてのソフトウェアを有効なソフトウェアのソースから取得します。ソフトウェアのソースタブは、/etc/yum.conf 設定ファイルおよび /etc/yum.repos.d/ ディレクトリにあるすべての repository.repo にあるすべての [repository] セクションの name=My Repository Name 項目に書かれているようにリポジトリ名を表示します。
有効化の列にチェックがついている項目は、対応するリポジトリがすべての更新とインストールの要求(依存関係の解決を含め)を満たすパッケージの位置を決めるために使用されます。有効化の列は [repository] セクションにおける enabled=<1 または 0> 項目に対応します。チェックボックスをチェックすることにより、Yum リポジトリを有効にします。また、チェック解除することにより無効にします。リポジトリを有効または無効にするどちらかの機能を実行することにより、PolicyKit がスーパーユーザーの認証をダイアログに要求します。PackageKit は実際に enabled=<1 または 0> が存在しなければその行を適切な [repository] セクションに挿入します。または、存在すれば値を変更します。つまり、ソフトウェアのソースウィンドウを通してリポジトリを有効化または無効化することにより、ウィンドウを閉じた後またはシステムを再起動した後に変更を永続化させます。必要に応じてリポジトリを簡単に有効化または無効化する機能は PackageKit の非常に便利な機能です。
PackageKit を通して Yum リポジトリの追加または削除ができないことに注意してください。

source RPM, test, および debuginfo リポジトリの表示

ソフトウェアのソース タブの下部にあるボックスをチェックすることにより、PackageKit が source RPM, testing および debuginfo リポジトリを同じように表示するようになります。このボックスはデフォルトでチェックされていません。

5.2. ソフトウェアの追加/削除の使用

PackageKitソフトウェアの更新 GUI ウィンドウは、直感的に同じようなインターフェースを持ちますが、ソフトウェアの追加/削除アプリケーションと独立したアプリケーションです。新しいパッケージを検索およびインストールするには、Activities メニューからアプリケーションシステムツールソフトウェアの追加/削除を選択するか、シェルプロンプトにおいて gpk-application コマンドを実行します。
PackageKit のソフトウェアの追加/削除ウィンドウ
PackageKit のソフトウェアの追加/削除ウィンドウの表示
図5.4 PackageKit のソフトウェアの追加/削除ウィンドウ

5.2.1. ソフトウェアソースの更新 (Yum リポジトリー)

Yum リポジトリを有効化または無効化するには、システムソフトウェアのソースをクリックしてダイアログボックスを開き、ソフトウェアのソースタブを選択します。利用可能な設定オプションの詳細は「ソフトウェアソースの設定」を参照してください。
適切な Yum リポジトリの有効化・無効化後、利用可能なパッケージの最新一覧を持っていることを確実にしなければいけません。システムパッケージ一覧の更新をクリックすると、PackageKit は、すべての利用可能なソフトウェアのソース、つまり Yum リポジトリからパッケージの最新一覧を取得します。

5.2.2. フィルターを用いたパッケージの検索

ソフトウェアの追加/削除を開き、システムソフトウェアのソースをクリックすることにより、すべての設定済みかつフィルターされていない(以下参照) Yum リポジトリの一覧を表示できます。一度ソフトウェアのソースが更新されると、PackageKit検索の問い合わせ結果をより速く取得できるよう、いくつかのフィルターを適用することに有益です。これはとくに、多くのパッケージ検索を実行するときに助けになります。フィルタードロップダウンメニューにある4つのフィルターは一つの基準に一致するまたは一致しないことにより結果を分割するために使用されます。デフォルトで、PackageKit が起動するとき、これらのフィルターはすべて適用されませんが(フィルターなし)、一度それらのどれかによりフィルターすると、そのフィルターは変更するか PackageKit を閉じるまで設定されたままになります。
通常システムにインストールされていない利用可能なパッケージを検索するので、フィルターインストール済 を選択し、利用可能なもののみラジオボタンを選択します。
すでにインストールされているパッケージのフィルター
すでにインストールされているパッケージのフィルター
図5.5 すでにインストールされているパッケージのフィルター

また、C ヘッダーファイルのように開発版が必要でなければ、エンドユーザーのファイルのみのためにフィルターできます。そして、そうするとき、興味がない package_name-devel をすべてフィルターで消します。
検索結果の一覧からの開発パッケージのフィルター
結果からの開発パッケージのフィルター
図5.6 検索結果の一覧からの開発パッケージのフィルター

サブメニューにある残り 2 つのフィルターは次のとおりです:
グラフィカル
GUI インターフェースを提供するアプリケーション(グラフィカルなもののみ)、またはそうではないものに検索を絞ります。このフィルターは特別な機能を実行する GUI アプリケーションを閲覧するときに有用です。
Free
フリーソフトウェアであると考えられるパッケージを検索します。承認されたライセンスの詳細は Fedora Licensing List を参照してください。
残りのチェックボックスのフィルターは必ずチェックまたは解除されます。それらは以下のものです:
サブパッケージを隠す
サブパッケージを隠す チェックボックスをチェックすることにより、一般的に必要なパッケージの依存性のみである、興味のないパッケージをフィルターします。たとえば、サブパッケージを隠すをチェックして、 package を検索することにより、以下の関連パッケージを検索結果からフィルターで隠します(もし存在すれば):
  • package-devel
  • package-libs
  • package-libs-devel
  • package-debuginfo
最新パッケージのみ
最新パッケージのみ を選択すると、結果の一覧から同じパッケージの古いバージョンはすべてフィルターされます。これは一般的に期待することでしょう。

最新パッケージのみフィルターの使用

最新パッケージのみを選択すると、結果の一覧からあらゆるパッケージの最新のバージョン以外はフィルターされます。このフィルターは、新しい(インストールされていない)パッケージの利用可能な最新バージョンを検索するために、しばしば利用可能なもののみ フィルターと組み合わせられます。
ディストリ固有のパッケージのみ
複数ライブラリのシステムにおいてディストリ固有のパッケージのみ ボックスをチェックすることにより、PackageKit互換モードにおいて実行するアーキテクチャーのためにコンパイルしたパッケージに対する結果を一覧表示することを省略します。たとえば、AMD64 CPU を持つ 64ビットシステムにおいてこのフィルターを有効にすることにより、AMD64 マシンにおいて実行できるパッケージであっても、32ビット x86 CPU アーキテクチャーのためにビルドされたパッケージをすべて結果の一覧に表示しないようにします。アーキテクチャー非依存の(つまり、crontabs-1.10-32.1.el6.noarch.rpm のような noarchの)パッケージは、ディストリ固有のパッケージのみをチェックすることによりフィルターされません。このフィルターは x86 マシンのような非複数ライブラリのシステムに影響しません。

5.2.3. パッケージ(および依存するもの)のインストールおよび削除

2つのフィルター、利用可能なもののみおよびエンドユーザーのファイルのみを選択すると、htop 対話式プロセスビューアーを検索して、パッケージをハイライトします。いくつかの非常に有用な情報を得ることができます。これは、クリック可能なプロジェクトのホームページ、もしあれば、見つかった Yum パッケージグループ、パッケージのライセンス、適用できれば、アプリケーションを開ける GNOME メニュー位置、およびダウンロードしてインストールするときに関連するパッケージの容量を含みます。
PackageKit のソフトウェアの追加/削除ウィンドウを用いたパッケージの表示およびインストール
PackageKit のソフトウェアの追加/削除ウィンドウを用いたパッケージの表示およびインストール
図5.7 PackageKit のソフトウェアの追加/削除ウィンドウを用いたパッケージの表示およびインストール

パッケージまたはグループの隣にあるチェックボックスをチェックされているとき、その項目はすでにシステムにインストールされています。チェックされてないボックスをチェックすることにより、インストールするという印をつけることになります。インストールは適用ボタンがクリックされたときのみ実行されます。このように、実際のインストールのトランザクションを実行する前に複数のパッケージまたはパッケージグループを検索および選択することができます。さらに、チェックボックスのチェックを解除することにより、インストールされたパッケージを削除できます。また、削除は適用が押されたときにすべての保留になっているインストールとともに実行されます。依存性の解決 (これはインストールまたは削除される追加のパッケージを追加するかもしれません)、適用を押した後に実行されます。その後、PackageKit はインストールまたは削除するそれらの追加のパッケージを一覧表示するウィンドウを表示して、進めるかどうかを確認します。
htop をチェックして、適用ボタンをクリックします。スーパーユーザーのパスワードを入力要求されます。それを入力すると、PackageKithtop をインストールします。PackageKit の素晴らしい機能の一つは、インストールに従って、ときどき新しくインストールされたアプリケーションの一覧を表示して、それらを直ちに実行するよう選択を提案することです。代わりに、ソフトウェアの追加/削除ウィンドウにおいて、パッケージを検索して選択することにより、アプリケーションのショートカットが置かれる GNOME メニューの場所を示すことを覚えておいてください。それはアプリケーションを実行したいときに役立ちます。
一度インストールすると、シェルプロンプトにおいて次のように入力することにより、top プロセスビューアーのカラフルかつ高度なバージョンである htop を実行できます:
htop
htop は素晴らしいですが、top で十分であるため、アンインストールすることにします。利用可能なもののみフィルターをフィルターインストール済み install it to インズトール済のもののみに忘れずに変更することにより、再び htop を検索して、チェック解除します。プログラムはそれ自身の依存するものを何もインストールしません。もしあれば、システムにインストールされた他のパッケージにそれが何も依存していなければ、自動的に同じように削除されます。

他のパッケージに依存するときにパッケージを削除する

PackageKit がパッケージのインストール中および削除中に自動的に依存関係を解決しますが、それに依存するパッケージも削除することなくパッケージを削除することはできません。この種の操作は RPM によってのみ実行できますが、推奨されません。これにより、システムが潜在的に機能しない状態になったり、アプリケーションが誤動作やクラッシュを起こしたりする可能性があります。
PackageKit のソフトウェアの追加/削除を用いたパッケージの削除
PackageKit のソフトウェアの追加/削除を用いた htop パッケージの削除
図5.8 PackageKit のソフトウェアの追加/削除を用いたパッケージの削除

5.2.4. パッケージグループのインストールおよび削除

PackageKit は、パッケージコレクションと呼ばれる Yum パッケージグループをインストールする機能もあります。ソフトウェアの更新ウィンドウにおいてカテゴリーの左上の一覧にあるパッケージコレクションをクリックすることにより、インストールしたいパッケージグループをスクロールして検索することができます。この場合、チェコ語の言語サポート(チェコ語のサポートグループ)をインストールしたいです。ボックスをチェックして、適用をクリックすることにより、パッケージグループの依存関係を満たすためにインストールしなければいけない追加のパッケージの数を表示します。
チェコ語サポートのパッケージグループのインストール
PackageKit のソフトウェアの追加/削除ウィンドウを用いてチェコ語の言語サポートをインストールするために PackageKit を使用する方法
図5.9 チェコ語サポートのパッケージグループのインストール

同様に、インストールされたパッケージグループは、パッケージコレクションを選択し、適切なチェックボックスをチェック解除し、適用することによりアンインストールできます。

5.2.5. トランザクションログの表示

PackageKit は実行したトランザクションのログ を維持します。ログを表示するには、ソフトウェアの追加/削除ウィンドウからシステムソフトウェアのログをクリックします、またはシェルプロンプトにおいて gpk-log コマンドを実行します。
ソフトウェア更新履歴ビューアーは、更新されたパッケージインストール済みパッケージ、アクションが実行された日付、アクションを実行したユーザー名、およびユーザーが使用したフロントエンドのアプリケーション(たとえば、ソフトウェアの追加/削除システムの更新)のようなアクションを表示します。詳細の列は、トランザクションが実行されたパッケージの一覧と同じように、更新インストール、または削除のような、トランザクションの種類を提供します。
ソフトウェアログビューアーを用いたパッケージ管理トランザクションのログの表示
PackageKit のソフトウェア更新履歴ビューアーウィンドウを用いたパッケージ管理トランザクションのログの表示
図5.10 ソフトウェアログビューアーを用いたパッケージ管理トランザクションのログの表示

上部のテキスト入力フィールドにパッケージの名前を入力することにより、パッケージに影響するトランザクションの一覧をフィルターします。

5.3. PackageKit アーキテクチャー

Fedora は、システムと互換性のあるパッケージおよびパッケージグループを表示、更新、インストールおよびアンインストールするためのアプリケーションである PackageKit スイートを提供します。アーキテクチャーとして、PackageKitpackagekitd デーモンのバックエンドと通信するグラフィカルなフロントエンドいくつかから構成されます。これは、いパッケージのインストールや削除などのような、実際のトランザクションを実行するために Yum を利用する、パッケージマネージャー固有のバックエンドと通信します。
表5.1「PackageKit GUI ウィンドウ、メニュー位置、およびシェルプロンプトコマンド」は、GUI ウィンドウの名前、GNOME デスクトップまたはソフトウェアの追加/削除ウィンドウからウィンドウを起動する方法、およびウィンドウを開くコマンドラインアプリケーションの名前を示しています。
表5.1 PackageKit GUI ウィンドウ、メニュー位置、およびシェルプロンプトコマンド
ウィンドウタイトル 機能 開き方 シェルコマンド
ソフトウェアの追加/削除 パッケージ情報のインストール、削除、または表示
GNOME パネルから: システム管理ソフトウェアの追加/削除
gpk-application
ソフトウェアの更新 パッケージの更新の実行
GNOME パネルから: システム管理ソフトウェアの更新
gpk-update-viewer
ソフトウェア提供元 Yum リポジトリーの有効化および無効化
ソフトウェアの追加/削除から: システムソフトウェアリポジトリ
gpk-repo
ソフトウェア更新履歴ビューアー トランザクションログの表示
ソフトウェアの追加/削除から: システムソフトウェアログ
gpk-log
ソフトウェアの更新の設定 PackageKit の設定 gpk-prefs
(通知エリアの警告) 更新が利用可能なときに警告する
GNOME パネルから: システム設定スタートアップアプリケーション, スタートアッププログラム タブ
gpk-update-icon

packagekitd デーモンは、ユーザーセッションの外で実行され、さまざまなグラフィカルフロントウィンドウと通信します。packagekitd デーモン[1] DBus システムメッセージバス経由で他のバックエンドを通信します。これは、システムに問い合わせを実行したり、変更を加えるために Yum の Python API を利用します。Red Hat Enterprise Linux と Fedora 以外の Linux システムにおいて、packagekitd は、そのシステム固有のパッケージマネージャーを使用できる他のバックエンドと通信できます。このモジュール型アーキテクチャーは、同じ種類のパッケージ管理タスクを基本的に実行できるよう、多くの異なるパッケージマネージャーとともに機能するために必要なグラフィカルインターフェースの抽象化を提供します。PackageKit フロントエンドをどのように使用するかを学ぶことは、Yum 以外のディストリビューション固有のパッケージマネージャーを利用するときさえ、多くの異なる Linux ディストリビューションにわたり同じようなグラフィカルインターフェースを使用できることを意味します。
さらに、PackageKit の関心の分離により、GUI ウィンドウ—またはユーザーの X Window セッション—のどれかのクラッシュに信頼性を与えます。これは、ユーザーセッションの外側で実行する packagekitd デーモンにより管理されるあらゆるパッケージ管理タスクに影響しません。
本章で説明されるフロントエンドのグラフィカルアプリケーションはすべて PackageKit とその依存パッケージの代わりに gnome-packagekit パッケージにより提供されます。KDE 環境を利用しているユーザーは、PackageKit の KDE インターフェースを提供する kpackagekit パッケージをインストールしたいかもしれません。
最後に、PackageKitpkcon というコンソールベースのフロントエンドからも利用できます。

5.4. その他のリソース

PackageKit ホームページ — http://www.packagekit.org/index.html
PackageKit のメーリングリストに関する情報です。
PackageKit FAQ — http://www.packagekit.org/pk-faq.html
PackageKit ソフトウェアスイートのよくある質問の参考一覧です。
PackageKit 機能マトリクス — http://www.packagekit.org/pk-matrix.html
パッケージ管理のバックエンドの長い一覧を持つ、PackageKit が提供する機能の相互参照です。


[1] システムデーモンは一般的に、ユーザーや他のプログラムにサービスを提供し、しばしば起動時に開始される、長時間実行されるプロセスです。デーモンは systemctl コマンドに応答し、systemctl enable または systemctl disable コマンドを使用することにより永続的に無効化または有効化できます。一般的に packagekitd デーモンのように d を付け加えることにより認識できます。システムサービスに関する詳細は7章サービスおよびデーモンを参照してください。

パート III. ネットワーク

第6章 ネットワーク・インターフェース

Fedora においては、すべてのネットワーク通信はシステムに接続された設定済みソフトウェアインターフェース物理ネットワークデバイスの間で発生します。
ネットワークインターフェースの設定ファイルは /etc/sysconfig/network-scripts/ ディレクトリに置かれます。これらのネットワークインターフェースを有効化および無効化するために使用されるスクリプトもここに置かれます。インターフェースのファイルの番号と種類はシステムにより異なりますが、このディレクトリに存在するファイルの区分は3つあります:
  1. インターフェースの設定ファイル
  2. インターフェースの制御スクリプト
  3. ネットワークの関数ファイル
これらの各カテゴリーのファイルは、合同で機能し各種ネットワークデバイスを動作させます。
この章では、これらファイル間の関係とファイルの使用方法について説明していきます。

6.1. ネットワーク設定ファイル

インターフェース設定ファイルを調べる前に、まずネットワーク設定において使用される主要な設定ファイルを項目別にあげましょう。Fedora システムをカスタマイズするときに役に立つネットワークスタックをセットアップすることに役立ちます。
主要なネットワーク設定ファイルは、次のようになります:
/etc/hosts
このファイルの主要な目的は、あらゆる他の方法により解決されないホスト名を解決することです。DNS サーバーのない小さなネットワークにおいてホスト名を解決するために使用することもできます。コンピューターがあるネットワークの種類によらず、このファイルは、localhost.localdomain のようなループバックデバイス(127.0.0.1)の IP アドレスを指定する行を含むべきです。詳細は hosts マニュアルページを参照してください。
/etc/resolv.conf
このファイルは DNS サーバーと検索ドメインの IP アドレスを指定します。他に設定されていなければ、ネットワーク初期化スクリプトがこのファイルを取り込みます。このファイルに関する詳細は、resolv.conf マニュアルページを参照してください。
/etc/sysconfig/network
このファイルはすべてのネットワークインターフェースに対するルーティングとホスト情報を指定します。このファイルと利用可能なディレクティブの詳細は、「 /etc/sysconfig/network 」を参照してください。
/etc/sysconfig/network-scripts/ifcfg-interface-name
各ネットワークインターフェースに対して、対応するインターフェース設定ファイルがあります。これらのファイルはそれぞれ、特定のネットワークインターフェースに固有の情報を提供します。この種のファイルと利用可能なディレクティブに関する詳細は「インターフェース設定ファイル」を参照してください。

ネットワークインターフェース名

ネットワークインターフェース名は異なるハードウェア種別において異なるかもしれません。詳細は付録A Consistent Network Device Namingを参照してください。

/etc/sysconfig/networking/ ディレクトリ

/etc/sysconfig/networking/ ディレクトリはネットワーク管理ツール (system-config-network) により使用され、その内容は手動で編集すべきではありません。設定が削除されるリスクがあるため、ネットワーク設定のために1つだけの方法を使用することが強く推奨されます。

6.2. インターフェース設定ファイル

Interface configuration files control the software interfaces for individual network devices. As the system boots, it uses these files to determine what interfaces to bring up and how to configure them. These files are usually named ifcfg-name , where name refers to the name of the device that the configuration file controls.

6.2.1. イーサネット インターフェース

One of the most common interface files is ifcfg-eth0, which controls the first Ethernet network interface card or NIC in the system. In a system with multiple NICs, there are multiple ifcfg-ethX files (where X is a unique number corresponding to a specific interface). Because each device has its own configuration file, an administrator can control how each interface functions individually.
下記は固定 IP アドレスを用いたシステム向けの ifcfg-eth0 のサンプルです。
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no
インターフェース設定ファイルにおいて必要とされる値は他の値に基づいて変更できます。たとえば、DHCP を使用しているインターフェースの ifcfg-eth0 ファイルは、IP 情報が DHCP サーバーにより提供されるので、異なって見えます:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
The Network Administration Tool (system-config-network) is an easy way to make changes to the various network interface configuration files.
但し、任意のネットワーク インターフェースの設定ファイルは、手動で編集することもできます。
以下にイーサネット インターフェースの設定ファイル内の設定パラメーターを一覧で示します。
BONDING_OPTS=parameters
sets the configuration parameters for the bonding device, and is used in /etc/sysconfig/network-scripts/ifcfg-bondN (see 「チャンネル・ボンディング・インターフェース」). These parameters are identical to those used for bonding devices in /sys/class/net/bonding device/bonding, and the module parameters for the bonding driver as described in bonding Module Directives.
This configuration method is used so that multiple bonding devices can have different configurations. It is highly recommended to place all of your bonding options after the BONDING_OPTS directive in ifcfg-name. Do not specify options for the bonding device in /etc/modprobe.d/bonding.conf, or in the deprecated /etc/modprobe.conf file.
BOOTPROTO=protocol
ここで protocol は以下のいずれかです:
  • none — 起動時のプロトコルを使用しない。
  • bootp — BOOTP プロトコルが使用される。
  • dhcp — DHCP プロトコルが使用される。
BROADCAST=address
ここで address はブロードキャストアドレスです。値は ipcalc を用いて自動的に計算されるので、このディレクティブは推奨されません。
DEVICE=name
ここで name は物理デバイスの名前です(論理名である動的に割り当てられた PPP デバイスを除きます)。
DHCP_HOSTNAME=name
ここで name は DHCP サーバーに送信される短縮ホスト名です。DHCP サーバーがクライアントに IP アドレスを受信する前にホスト名を指定するよう要求するときのみ、このオプションを使用してください。
DNS{1,2}=address
ここで addressPEERDNSyes に設定されているとき、/etc/resolv.conf に置かれるネームサーバーのアドレスです。
ETHTOOL_OPTS=options
ここで optionsethtool によりサポートされるデバイス固有のあらゆるオプションです。たとえば、100Mb、全二重を強制したいならば、次のようにします:
ETHTOOL_OPTS="autoneg off speed 100 duplex full"
個別の初期化スクリプトの代わりに、インターフェースの速度と多重度を設定するために ETHTOOL_OPTS を使用します。ネットワークの初期化スクリプト以外に実行される個別の初期化スクリプトにより、起動後のネットワークサービスを再起動する間、予期しない結果になります。

速度または多重度の設定を変更する前に "autoneg off" を設定します

速度や多重度の設定を変更するには、autoneg off オプションを用いて必ずオートネゴシエーションを無効にする必用があります。オプションのエントリーは順番に依存するため、最初にこれを指定する必要があります。
GATEWAY=address
ここで address はネットワークのルーターまたはゲートウェイデバイスの IP アドレスです(あれば)。
HOTPLUG=answer
ここで answer は次のいずれかです:
  • yes — このデバイスが活性挿入されたときに有効化します(これがデフォルトのオプションです)。
  • no — このデバイスが活性挿入されたときに有効化しません
HOTPLUG=no オプションは、bonding カーネルモジュールが読み込まれているときに、チャネルボンディングインターフェースが有効化するのを防げます。
ボンディング・インターフェースの詳細は「チャンネル・ボンディング・インターフェース」を参照してください。
HWADDR=MAC-address
where MAC-address is the hardware address of the Ethernet device in the form AA:BB:CC:DD:EE:FF. This directive must be used in machines containing more than one NIC to ensure that the interfaces are assigned the correct device names regardless of the configured load order for each NIC's module. This directive should not be used in conjunction with MACADDR.
IPADDR=address
ここで address は IP アドレスです。
LINKDELAY=time
ここで time は、デバイスを設定する前にリンクネゴシエーションを待つ秒数です。
MACADDR=MAC-address
ここで MAC-address は、AA:BB:CC:DD:EE:FF という形式のイーサーネットデバイスのハードウェアアドレスです。このディレクティブは、物理 NIC に割り当てられた MAC アドレスを上書きして、インターフェースに MAC アドレスを割り当てるために使用されます。このディレクティブは HWADDR とともに使用されるべきではありません
MASTER=bond-interface
ここで bond-interface はイーサーネットインターフェースがリンクするチャネルボンディングインターフェースです。
このディレクティブは SLAVE ディレクティブとともに使用されます。
ボンディング・インターフェースの詳細は「チャンネル・ボンディング・インターフェース」を参照してください。
NETMASK=mask
ここで mask はネットマスク値です。
NETWORK=address
ここで address はネットワークアドレスです。この値は ipcalc を用いて自動的に計算されるので、このディレクティブは推奨されません。
ONBOOT=answer
ここで answer は以下のいずれかです:
  • yes — このデバイスは起動時に有効になります。
  • no — このデバイスは起動時に有効になりません。
PEERDNS=answer
ここで answer は以下のいずれかです:
  • yes — DNS ディレクティブが設定されていると、/etc/resolv.conf を修正します。DHCP を使用していると、yes がデフォルトです。
  • no/etc/resolv.conf. を変更しません。
SLAVE=answer
ここで answer は以下のいずれかです:
  • yes — このデバイスは MASTER ディレクティブにおいて指定されたチャネル・ボンディング・インターフェースにより制御されます。
  • no — このデバイスは MASTER ディレクティブにおいて指定されたチャネル・ボンディング・インターフェースにより制御されません
このディレクティブは MASTER ディレクティブとともに使用されます。
チャネル・ボンディング・インターフェースの詳細は「チャンネル・ボンディング・インターフェース」を参照してください。
SRCADDR=address
ここで address は送信パケットに対して指定されたソース IP アドレスです。
USERCTL=answer
ここで answer は以下のいずれかです:
  • yesroot 以外のユーザーに、このデバイスの制御を許可します。
  • noroot 以外のユーザーに、このデバイスの制御を許可しません。

6.2.2. チャンネル・ボンディング・インターフェース

Fedora は管理者が bonding カーネルモジュールおよびチャネルボンディングインターフェースと呼ばれる特別なネットワークインターフェースを使用して単一チャネルの中に複数のネットワークインターフェースを一緒にバインドできます。チャネルボンディングは、同時に帯域を増加させて冗長性を提供する、2つ以上のネットワークインターフェースを1つとして動作させることができます。
To create a channel bonding interface, create a file in the /etc/sysconfig/network-scripts/ directory called ifcfg-bondN , replacing N with the number for the interface, such as 0.
The contents of the file can be identical to whatever type of interface is getting bonded, such as an Ethernet interface. The only difference is that the DEVICE= directive must be bondN , replacing N with the number for the interface.
以下は、チャンネル ボンディング設定ファイルの例です。
DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
BONDING_OPTS="スペースで区切ってボンディングのパラメーター"
チャネルボンディングインターフェースが作成された後、一緒に束ねられるネットワークインターフェースは、 MASTER= および SLAVE= ディレクティブをそれらの設定ファイルに追加することにより、設定されなければいけません。各チャネルボンディングインターフェースの設定ファイルはほぼ同一です。
たとえば、2つのイーサネットインターフェースがチャネルボンドされるならば、eth0eth1 は以下の例のようになります:
DEVICE=ethN
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
この例では、N をインターフェースの数値に置き換えます。
For a channel bonding interface to be valid, the kernel module must be loaded. To ensure that the module is loaded when the channel bonding interface is brought up, create a new file as root named bonding.conf in the /etc/modprobe.d/ directory. Note that you can name this file anything you like as long as it ends with a .conf extension. Insert the following line in this new file:
alias bondN bonding
Replace N with the interface number, such as 0. For each configured channel bonding interface, there must be a corresponding entry in your new /etc/modprobe.d/bonding.conf file.

Put all bonding module parameters in ifcfg-bondN files

Parameters for the bonding kernel module must be specified as a space-separated list in the BONDING_OPTS="bonding parameters" directive in the ifcfg-bondN interface file. Do not specify options for the bonding device in /etc/modprobe.d/bonding.conf, or in the deprecated /etc/modprobe.conf file. For further instructions and advice on configuring the bonding module and to view the list of bonding parameters, refer to 「Using Channel Bonding」.

6.2.3. エイリアス ファイルとクローン ファイル

使用頻度の少ない 2 種類のインターフェース設定ファイルが エイリアスクローン です。
Alias interface configuration files, which are used to bind multiple addresses to a single interface, use the ifcfg-if-name:alias-value naming scheme.
たとえば、ifcfg-eth0:0 ファイルは、ifcfg-eth0 において DHCP 経由で IP 情報を受信するようすでに設定されているインターフェースのエイリアスとして処理する、DEVICE=eth0:0 および静的 IP アドレス 10.0.0.2 を指定するよう設定されます。この設定において、eth0 は動的 IP アドレスに束ねられますが、同じ物理ネットワークカードが固定された 10.0.0.2 の IP アドレス経由で要求を受信できます。

注意

エイリアス インターフェースは DHCP をサポートしません。
A clone interface configuration file should use the following naming convention: ifcfg-if-name-clone-name . While an alias file allows multiple addresses for an existing interface, a clone file is used to specify additional options for an interface. For example, a standard DHCP Ethernet interface called eth0, may look similar to this:
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
USERCTL ディレクティブの初期値は no ですので、指定しなければ、ユーザーはこのインターフェースを起動・停止できません。ユーザーにインターフェースを制御する能力を与えるには、ifcfg-eth0ifcfg-eth0-user にコピーすることによりクローンを作成して、以下の行を ifcfg-eth0-user に追加します:
USERCTL=yes
この方法により、ifcfg-eth0 および ifcfg-eth0-user から設定オプションが結合されるので、ユーザーは /sbin/ifup eth0-user コマンドを使用して eth0 インターフェースを起動できます。これは非常に基本的な例ですが、この方法はさまざまなオプションおよびインターフェースで使用できます。
The easiest way to create alias and clone interface configuration files is to use the graphical Network Administration Tool.

6.2.4. ダイヤルアップ インターフェース

ダイヤルアップ接続を通してインターネットに接続する場合、インターフェース用に設定ファイルが必要です。
PPP インターフェイス ファイルは、以下の形式を使用して名付けられます:
ifcfg-pppX
ここで X は特定のインターフェースに対応する一意な番号です。
ダイヤルアップアカウントを作成するために、wvdialネットワーク管理ツール または Kppp を使用するとき、PPP インターフェース設定ファイルが自動的に作成されます。手動でこのファイルを作成および編集することもできます。
以下は一般的な ifcfg-ppp0 ファイルです:
DEVICE=ppp0
NAME=test
WVDIALSECT=test
MODEMPORT=/dev/modem
LINESPEED=115200
PAPNAME=test
USERCTL=true
ONBOOT=no
PERSIST=no
DEFROUTE=yes
PEERDNS=yes
DEMAND=no
IDLETIMEOUT=600
Serial Line Internet Protocol (SLIP) は、ほとんど使われませんが、もう一つのダイヤルアップインターフェースです。SLIP ファイルは ifcfg-sl0 のようなインターフェース設定ファイル名を持ちます。
これらのファイルで使用できる他のオプションを以下に示します:
DEFROUTE=answer
ここで answer は以下のいずれかです:
  • yes — デフォルト ルートとしてこのインターフェースを設定します。
  • no — デフォルト ルートとしてこのインターフェースを設定しません。
DEMAND=answer
ここで answer は以下のいずれかです:
  • yes — 何かがこのインターフェースを使用しようとするとき、pppd が接続を初期化できるようにします。
  • no — 接続がこのインターフェースに対して手動で確立されなければいけません。
IDLETIMEOUT=value
ここで value は、インターフェース自身が切断される前にアイドル秒数です。
INITSTRING=string
ここで string はモデムデバイスに渡される初期化文字列です。このオプションは主に SLIP インターフェースとともに使用されます。
LINESPEED=value
ここで value はデバイスのボーレートです。利用可能な標準的な値は 57600, 38400, 19200, および 9600 があります。
MODEMPORT=device
ここで device はインターフェースに対する接続を確立するために使用されるシリアルデバイスの名前です。
MTU=value
ここで value はインターフェースの Maximum Transfer Unit (MTU) 設定です。MTU はフレームが伝送できるデータの最大長を参照しますが、ヘッダー情報をカウントしません。いくつかのダイヤルアップシチュエーションにおいて、これを 576 に設定することにより、パケットの破棄を減らせ、接続のスループットがわずかに改善します。
NAME=name
ここで name はダイヤルアップ接続群に与えられる見出しへの参照です。
PAPNAME=name
ここで name は、リモートシステムに接続できるよう、Password Authentication Protocol (PAP) 交換中に与えられたユーザー名です。
PERSIST=answer
ここで answer は以下のいずれかです:
  • yes — モデムがハングアップした後に無効にされた後でも、このインターフェースがいつでも有効であるように維持します。
  • no — こnインターフェースが必ずしも常に有効であるとは限りません。
REMIP=address
ここで address はリモートシステムの IP アドレスです。これは一般的に指定されません。
WVDIALSECT=name
ここで name はこのインターフェースと /etc/wvdial.conf にあるダイヤラー設定を関連づけます。このファイルは、ダイヤルされる電話番号およびインターフェースの他の重要な情報を含みます。

6.2.5. 他のインターフェース

他の一般的なインターフェイス設定ファイルは次の項目を含みます:
ifcfg-lo
ローカルの ループバック インターフェイス はよくテストで 使用されるだけでなく、同じシステムを指定し直す IP アドレスを必要とするさまざまなアプリケーションでも使用されます。ループバックデバイスに送信されたデータはすぐにホストのネットワーク層に戻されます。

ifrcfg-lo スクリプトは手動で編集しません

ループバックインターフェースのスクリプト /etc/sysconfig/network-scripts/ifcfg-lo は、手動で編集すべきではありません。そうすると、システムが正しく動作しなくなる可能性がありません。
ifcfg-irlan0
赤外線インターフェース によって、ラップトップとプリンタなどデバイス間の情報を赤外線リンク上で流すことができます。これは、通常ピアツーピア接続で可能という事以外はイーサネットと同じような方法で動作します。
ifcfg-plip0
PLIP (Parallel Line Interface Protocol) 接続も、パラレルポートを使用すること以外は、殆んどイーサネットデバイスと同様な方法で動作します。

6.3. インターフェース制御スクリプト

インターフェース制御スクリプトはシステムインターフェースを活性化および非活性化します。/etc/sysconfig/network-scripts/ ディレクトリーに置かれている制御スクリプトにおいて呼び出す 2 つの主なインターフェース制御スクリプトがあります: /sbin/ifdown および /sbin/ifup
ifup および ifdown インターフェーススクリプトは、/sbin/ ディレクトリにあるスクリプトへのシンボリックリンクです。これらのスクリプトのいずれかが呼び出されるとき、次のように、インターフェースの値が指定される必要があります:
ifup eth0

インターフェースのスクリプト ifup と ifdown を使う

ifup および ifdown インターフェーススクリプトは、ユーザーがネットワークインターフェースを起動または停止するために使用する唯一のスクリプトです。
参考のために以下にスクリプトの例をあげておきます。
ネットワークインターフェースが起動するプロセス中にさまざまなネットワーク初期化作業を実行するために使用される2つのファイルが、/etc/rc.d/init.d/functions および /etc/sysconfig/network-scripts/network-functions です。詳細は「ネットワーク機能ファイル」を参照してください。
After verifying that an interface has been specified and that the user executing the request is allowed to control the interface, the correct script brings the interface up or down. The following are common interface control scripts found within the /etc/sysconfig/network-scripts/ directory:
ifup-aliases
複数の IP アドレスが 1 つのインターフェイスに関連付けられている場合、インターフェース設定ファイルから IP エイリアスを設定します。
ifup-ipppifdown-ippp
ISDN インターフェースをアップとダウンする為に使用します。
ifup-ipv6ifdown-ipv6
IPv6 インターフェースをアップとダウンする為に使用します。
ifup-plip
PLIP インターフェースをアップする為に使用します。
ifup-plusb
ネットワーク接続用の USB インターフェースをアップする為に使用します。
ifup-postifdown-post
これらには、インターフェイスを立ち上げた後、及び停止した後に実行されるコマンドが含まれています。
ifup-pppifdown-ppp
PPP インターフェースをアップとダウンする為に使用します。
ifup-routes
デバイスの静的ルートを、そのインターフェイスがアップするときに追加します。
ifdown-sitifup-sit
IPv4 接続内にある IPv6 トンネルのアップ/ダウンに関連した機能呼び出しを含みます。
ifup-wireless
ワイヤレスインターフェースをアップする為に使用します。

ネットワーク スクリプトの修正と削除をする際は注意をしてください!

/etc/sysconfig/network-scripts/ ディレクトリーにあるスクリプトを削除または修正することにより、インターフェース接続が不規則な振る舞いまたは失敗することを引き起こす可能性があります。高度なユーザーのみがネットワークインターフェースに関連するスクリプトを修正すべきです。
The easiest way to manipulate all network scripts simultaneously is to use the systemctl command on the network service (/etc/rc.d/init.d/network), as illustrated the following command:
systemctl action network.service
ここで、actionstart, stop, または restart のどれかです。
設定したデバイスと現在アクティブになっているネットワーク インターフェースの一覧を表示するには、次のコマンドを使用します:
service network status

6.4. スタティック ルートの設定

If static routes are required, they can be configured for each interface. This can be useful if you have multiple interfaces in different subnets. Use the route command to display the IP routing table.
静的ルーティング設定 /etc/sysconfig/network-scripts/route-interface ファイルに保存されます。たとえば、eth0 インターフェースの静的ルーティングは /etc/sysconfig/network-scripts/route-eth0 ファイルに保存されます。route-interface ファイルは2つの形式があります: IP コマンド引数および network/netmask ディレクティブ。
IP コマンドの引数形式
最初の行にデフォルトゲートウェイを定義します。デフォルトゲートウェイが DHCP 経由で設定されていないときのみ、これが必要になります:
default via X.X.X.X dev interface
X.X.X.X はデフォルトゲートウェイの IP アドレスです。interface は、デフォルトゲートウェイに接続される、または到達できるインターフェースです。
静的ルーティングを定義します。各行はそれぞれルーティングとして構文解析されます:
X.X.X.X/X via X.X.X.X dev interface
X.X.X.X/X は静的ルートに対するネットワークの番号とネットマスクです。X.X.X.X および interface はそれぞれデフォルトゲートウェイに対する IP アドレスとインターフェースです。X.X.X.X のアドレスはデフォルトゲートウェイの IP アドレスである必要がありません。多くの場合、X.X.X.X は異なるサブネットにおける IP アドレスです。また、interface は、そのサブネットに接続されている、または到達できるインターフェースです。
以下は IP コマンド引数形式を使用するサンプル route-eth0 ファイルです。デフォルトゲートウェイは 192.168.0.1、インターフェース eth0 です。2 つの静的ルートは 10.10.10.0/24 および 172.16.1.0/24 のネットワークに対するものです:
default via 192.168.0.1 dev eth0
10.10.10.0/24 via 192.168.0.1 dev eth0
172.16.1.0/24 via 192.168.0.1 dev eth0
静的ルートは他のサブネットに対してのみ設定されるべきです。上の例は、10.10.10.0/24 および 172.16.1.0/24 ネットワークに行くパケットは必ずデフォルトゲートウェイを使用するので、必要ありません。以下は、192.168.0.0/24 サブネットにあるマシンにおいて、他のサブネットへの静的ルートを設定する例です。例のマシンは、192.168.0.0/24 サブネットに eth0を、10.10.10.0/24 サブネットに eth1 インターフェース (10.10.10.1) を持ちます:
10.10.10.0/24 via 10.10.10.1 dev eth1

デフォルト ゲートウェイの複製

If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X" is a garbage.', where X.X.X.X is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.
ネットワーク/ネットマスク ディレクティブの形式
route-interface ファイルの network/netmask ディレクティブ形式を使用することもできます。以下は、その後に指示を用いた、network/netmask 形式のテンプレートです。
ADDRESS0=X.X.X.X
NETMASK0=X.X.X.X
GATEWAY0=X.X.X.X
  • ADDRESS0=X.X.X.X はスタティック ルートのネットワーク番号です。
  • NETMASK0=X.X.X.X ADDRESS0=X.X.X.X で定義されたネットワーク番号に対するネットマスクです。
  • GATEWAY0=X.X.X.X はデフォルトゲートウェイです。もしくは、ADDRESS0=X.X.X.X に到達するために使用できる IP アドレスです。
The following is a sample route-eth0 file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:
ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.0.1
ADDRESS1=172.16.1.0
NETMASK1=255.255.255.0
GATEWAY1=192.168.0.1
Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0, ADDRESS1, ADDRESS2, and so on.
Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=10.10.10.1
DHCP が使用されていると、これらの設定が自動的に割り当てられることに注意してください。

6.5. ネットワーク機能ファイル

Fedora makes use of several files that contain important common functions used to bring interfaces up and down. Rather than forcing each interface control file to contain these functions, they are grouped together in a few files that are called upon when necessary.
The /etc/sysconfig/network-scripts/network-functions file contains the most commonly used IPv4 functions, which are useful to many interface control scripts. These functions include contacting running programs that have requested information about changes in the status of an interface, setting hostnames, finding a gateway device, verifying whether or not a particular device is down, and adding a default route.
As the functions required for IPv6 interfaces are different from IPv4 interfaces, a /etc/sysconfig/network-scripts/network-functions-ipv6 file exists specifically to hold this information. The functions in this file configure and delete static IPv6 routes, create and remove tunnels, add and remove IPv6 addresses to an interface, and test for the existence of an IPv6 address on an interface.

6.6. その他のリソース

ネットワークインターフェースに関して詳細に説明しているリソースを以下に示します。

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

/usr/share/doc/initscripts-version/sysconfig.txt
この章では触れていない IPv6 オプションなど、ネットワーク設定ファイル用に利用可能なオプションへの手引きです。
/usr/share/doc/iproute-version/ip-cref.ps
This file contains a wealth of information about the ip command, which can be used to manipulate routing tables, among other things. Use the ggv or kghostview application to view this file.

パート IV. インフラストラクチャーサービス

このパートはサービスとデーモンの設定、認証の設定、およびリモートログインを有効にする方法に関する情報を提供します。

目次

7. サービスおよびデーモン
7.1. サービスの設定
7.1.1. サービスの有効化
7.1.2. サービスの無効化
7.2. サービスの実行
7.2.1. サービスの状態の確認
7.2.2. サービスの実行
7.2.3. サービスの停止
7.2.4. サービスの再起動
7.3. その他のリソース
7.3.1. インストールされているドキュメント
7.3.2. 関連書籍
8. 認証の設定
8.1. 認証の設定ツール
8.1.1. 識別と認証
8.1.2. 高度なオプション
8.1.3. コマンドライン版
8.2. The System Security Services Daemon (SSSD)
8.2.1. What is SSSD?
8.2.2. SSSD Features
8.2.3. Setting Up SSSD
8.2.4. Configuring Services
8.2.5. Configuring Domains
8.2.6. Setting Up Kerberos Authentication
8.2.7. Configuring a Proxy Domain
8.2.8. Troubleshooting
8.2.9. SSSD Configuration File Format
9. OpenSSH
9.1. SSH プロトコル
9.1.1. なぜ SSH を使うのか?
9.1.2. 主な機能
9.1.3. プロトコル・バージョン
9.1.4. SSH コネクションのイベント・シーケンス
9.2. OpenSSH の設定
9.2.1. 設定ファイル
9.2.2. OpenSSH サーバーの起動
9.2.3. リモート接続に対する SSH の要求
9.2.4. キー認証の使用
9.3. OpenSSH クライアント
9.3.1. ssh ユーティリティの使用方法
9.3.2. scp ユーティリティの使用方法
9.3.3. sftp ユーティリティの使用方法
9.4. 安全なシェル以上のもの
9.4.1. X11 転送
9.4.2. ポート転送
9.5. 追加のリソース
9.5.1. インストールされているドキュメント
9.5.2. 役に立つ Web サイト

第7章 サービスおよびデーモン

システムにおけるセキュリティを維持することは極めて重要です。このためのアプローチの一つは、システムのサービスに対するアクセスを注意深く管理することです。システムが特定のサービスに対する自由なアクセスを提供する必要があるかもしれません。(たとえば、ウェブサーバーを実行しているならば、httpd です。)しかしながら、サービスを提供する必要がなければ、可能性のあるバグのエクスプロイトに対する危険を最小限にするために、サービスを無効にしておくべきです。
本章は、システムが起動するときに実行されるサービスの設定について取り扱います。また、systemctl ユーティリティを用いてコマンドラインにおいてサービスを起動・停止・再起動する方法に関する情報を提供します。

システムをセキュアに維持する

新しいサービスに対するアクセスを許可するとき、ファイアウォールと SELinux のどちらも合わせて設定される必要があることを覚えておいてください。新しいサービスを設定するときに犯す最も一般的な間違いは、それに対するアクセスを許可するために必要なファイアウォール設定と SELinux ポリシーの実装を忘れることです。詳細は Fedora セキュリティガイド (「その他のリソース」) を参照してください。

7.1. サービスの設定

ブート時にどのサービスが開始されるかを設定できるようにするために、Fedora は systemctl コマンドラインツールを同梱しています。

ntsysv および chkconfig ユーティリティを使用しないでください

/etc/rc.d/init.d/ ディレクトリにインストールされた init スクリプトを持つサービスを管理するために、ntsysv および chkconfig ユーティリティをまだ使用できますが、systemctl ユーティリティを使用することを勧めます。

irqbalance サービスの有効化

POWER アーキテクチャーにおいて最適なパフォーマンスを確実にするために、irqbalance サービスを有効化することが推奨されます。多くの場合、このサービスは Fedora 16 のインストール中にインストールされ設定されています。irqbalance が実行されていることを確認するために、シェルプロンプトにおいて以下を入力します:
systemctl status irqbalance.service

7.1.1. サービスの有効化

起動時にサービスが自動的に開始するよう設定するには、systemctl コマンドを以下の形式で使用します:
systemctl enable service_name.service
システムの次回起動時にサービスが開始されます。サービスをすぐに開始する方法については、「サービスの実行」を参照してください。
例7.1 httpd サービスの有効化
あなたがシステムにおいて Apache HTTP Server を実行したいと想定してください。httpd パッケージをインストールされていれば、シェルプロンプトにおいて root として以下のように入力することにより httpd サービスを有効化できます:
~]# systemctl enable httpd.service

7.1.2. サービスの無効化

起動時にサービスが開始されないようにするには、systemctl コマンドを以下の形式で使用します:
systemctl disable service_name.service
システムの次回起動時にサービスが開始されません。サービスをすぐに停止する方法については、「サービスの停止」を参照してください。
例7.2 telnet サービスの無効化
システムをセキュアにするには、TELNET のようなセキュアではないコネクションプロトコルを無効にすることがユーザーに勧められます。root として以下のようなコマンドを実行することにより、telnet サービスが無効化されていることを確実にできます:
~]# systemctl disable telnet.service

7.2. サービスの実行

systemctl ユーティリティは、サービスを開始・停止・再起動するだけでなく、特定のサービスの状態を確認できるようになります。

service ユーティリティを使用しないでください

/etc/rc.d/init.d/ ディレクトリにインストールされた init スクリプトを持つサービスを管理するために、service ユーティリティをまだ使用できますが、systemctl ユーティリティを使用することを勧めます。

7.2.1. サービスの状態の確認

特定のサービスの状態を確認するには、systemctl コマンドを以下の形式で使用します:
systemctl status service_name.service
このコマンドはサービスの状態に関する詳しい状態を提供します。しかしながら、ただサービスが実行されているかを確認する必要があるだけならば、代わりに以下の形式で systemctl コマンドを使用することができます:
systemctl is-active service_name.service
例7.3 httpd サービスの状態の確認
例7.1「httpd サービスの有効化」httpd サービスを起動時に開始する方法について説明しています。システムが再起動したと想定すると、サービスが本当に実行されているかを確認する必要があります。シェルプロンプトにおいて以下のように入力することにより確認できます:
~]$ systemctl is-active httpd.service
active
以下のコマンドを実行することにより、サービスに関する詳しい情報を表示することもできます:
~]$ systemctl status httpd.service
httpd.service - LSB: start and stop Apache HTTP Server
          Loaded: loaded (/etc/rc.d/init.d/httpd)
          Active: active (running) since Mon, 23 May 2011 21:38:57 +0200; 27s ago
         Process: 2997 ExecStart=/etc/rc.d/init.d/httpd start (code=exited, status=0/SUCCESS)
        Main PID: 3002 (httpd)
          CGroup: name=systemd:/system/httpd.service
                  ├ 3002 /usr/sbin/httpd
                  ├ 3004 /usr/sbin/httpd
                  ├ 3005 /usr/sbin/httpd
                  ├ 3006 /usr/sbin/httpd
                  ├ 3007 /usr/sbin/httpd
                  ├ 3008 /usr/sbin/httpd
                  ├ 3009 /usr/sbin/httpd
                  ├ 3010 /usr/sbin/httpd
                  └ 3011 /usr/sbin/httpd

すべての有効なシステムサービスを一覧表示するには、以下のコマンドを使用します
systemctl list-units --type=service
このコマンドは、各行に以下の列をタブ区切りで提供します:
  • UNITsystemd ユニット名です。この場合、サービス名です。
  • LOADsystemd ユニットが正しくロードされているかの情報です。
  • ACTIVE — 高レベルのユニットの有効化状態です。
  • SUB — 低レベルのユニットの有効化状態です。
  • JOB — ユニットの待機中のジョブです。
  • DESCRIPTION — ユニットの概要です。
例7.4 すべての有効なサービスの一覧表示
以下のコマンドを使用することにより、すべての有効なサービスを一覧表示できます:
~]$ systemctl list-units --type=service
UNIT                      LOAD   ACTIVE SUB     JOB DESCRIPTION
abrt-ccpp.service         loaded active exited      LSB: Installs coredump handler which saves segfault data
abrt-oops.service         loaded active running     LSB: Watches system log for oops messages, creates ABRT dump directories for each oops
abrtd.service             loaded active running     ABRT Automated Bug Reporting Tool
accounts-daemon.service   loaded active running     Accounts Service
atd.service               loaded active running     Job spooling tools
[出力の省略]
上の例において、abrtd サービスが、ロード、有効化、実行されています。また、待機中のジョブは何もありません。

7.2.2. サービスの実行

サービスを実行するには、以下の形式で systemctl コマンドを使用します:
systemctl start service_name.service
これは現在のセッションにおいてサービスを開始します。起動時にサービスが開始されるよう設定するには、「サービスの有効化」を参照してください。
例7.5 httpd サービスの実行
例7.1「httpd サービスの有効化」は起動時に httpd サービスを実行する方法について説明しています。シェルプロンプトにおいて root として以下のように入力することにより直ちにサービスを開始できます:
~]# systemctl start httpd.service

7.2.3. サービスの停止

サービスを停止するには、以下の形式で systemctl コマンドを使用します:
systemctl stop service_name.service
これにより現在のセッションにおいてサービスを停止します。起動時にサービスを開始しないようにするには、「サービスの有効化」を参照してください。
例7.6 telnet サービスの停止
例7.2「telnet サービスの無効化」は起動時に telnet サービスが開始されないようにする方法を説明しています。root として以下のコマンドを実行することにより、サービスを直ちに停止できます:
~]# systemctl stop telnet.service

7.2.4. サービスの再起動

サービスを再起動するには、以下の形式で systemctl コマンドを使用します:
systemctl restart service_name.service
例7.7 sshd サービスの再起動
/etc/ssh/sshd_config 設定ファイルにおけるあらゆる変更を有効にするには、sshd サービスを再起動する必要があります。シェルプロンプトにおいて root として以下のように入力することにより再起動できます:
~]# systemctl restart httpd.service

7.3. その他のリソース

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

  • systemctl(1) — systemctl ユーティリティのマニュアルページです。

7.3.2. 関連書籍

セキュリティガイド
Fedora をセキュアにするためのガイドです。ファイアウォールの構築方法および SELinux の設定に関する有益な情報があります。

第8章 認証の設定

8.1. 認証の設定ツール

ユーザーが Fedora システムにログインするとき、ユーザー名とパスワードの組み合わせが有効かつアクティブなユーザーとして検証または認証されなければいけません。ときどき、ユーザーを検証するための情報はローカルシステムに置かれます。それ以外の場合、システムは認証をリモートシステムにあるユーザーデータベースに従います。
認証の設定ツールは、Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS), および Winbind ユーザーアカウントデータベースから取り出したユーザー情報を設定するためのグラフィカルインターフェースを提供します。このツールは LDAP または NIS を使用しているとき、認証プロトコルとして Kerberos を使用するようにも設定できます。

中高セキュリティレベルの使用

インストール中に(または、セキュリティレベルの設定ツールを用いて)中高セキュリティレベルを設定していれば、ファイアウォールが NIS 認証を防ぎます。ファイアウォールの詳細は Fedora セキュリティガイド"ファイアウォール" セクションを参照してください。
デスクトップから認証の設定のグラフィカル版を起動するには、アクティビティメニューからアプリケーションその他認証を選択します、または(たとえば XTermGNOME 端末において)シェルプロンプトにコマンド system-config-authentication を入力します。

変更は即座に適用されます

認証プログラムを終了した後、あらゆる変更は即座に反映されます。

8.1.1. 識別と認証

識別と認証タブにより、どのようにユーザーが認証されるかを設定できます。また、それぞれの認証方式に対するいくつかのオプションがあります。どのユーザーアカウントデータベースが使用されるべきかを選択するには、ドロップダウンリストからオプションを選択します。
識別と認証:ユーザーアカウントデータベースのドロップダウンにおいてオプションを変更すると、タブの内容が変更されます
図8.1 識別と認証:ユーザーアカウントデータベースのドロップダウンにおいてオプションを変更すると、タブの内容が変更されます

以下の一覧は各オプションの説明です。

LDAP

The LDAP option instructs the system to retrieve user information via LDAP. It contains the following specifications:
  • LDAP Search Base DN — Specifies that user information should be retrieved using the listed Distinguished Name (DN).
  • LDAP ServerLDAP サーバーのアドレスを指定します。
  • Use TLS to encrypt connections — When enabled, Transport Layer Security (TLC) will be used to encrypt passwords sent to the LDAP server. The Download CA Certificate option allows you to specify a URL from which to download a valid Certificate Authority certificate (CA). A valid CA certificate must be in the Privacy Enhanced Mail (PEM) format.

    Using ldaps:// in the LDAP Server field

    The Use TLS to encrypt connections option must not be ticked if an ldaps:// server address is specified in the LDAP Server field.
    CA 証明書の詳細は「証明書とセキュリティの概要」を参照してください。
The openldap-clients package must be installed for this option to work.
LDAP の詳細は「OpenLDAP」を参照してください。
LDAP は次の認証方法を提供します。
  • Kerberos password — This option enables Kerberos authentication. It contains the following specifications:
    • Realm — Configures the realm for the Kerberos server. The realm is the network that uses Kerberos, composed of one or more KDCs and a potentially large number of clients.
    • KDCs — Defines the Key Distribution Centers (KDC), which are servers that issue Kerberos tickets.
    • Admin Servers — Specifies the administration server(s) running kadmind.
    The Kerberos Settings dialog also allows you to use DNS to resolve hosts to realms and locate KDCs for realms.
    The krb5-libs and krb5-workstation packages must be installed for this option to work. For more information about Kerberos, refer to section Using Kerberos of the Fedora 16 Managing Single Sign-On and Smart Cards guide.
  • LDAP password — This option instructs standard PAM-enabled applications to use LDAP authentication with options specified in the User Account Configuration of LDAP. When using this option, you must provide an ldaps:// server address or use TLS for LDAP authentication.

SSSD サービスの設定

The SSSD service is used as a client for LDAP and Kerberos servers. Thus, offline login is enabled and supported by default. No user interaction is needed to set up the SSSD service with the Authentication Configuration Tool. For more information about the SSSD service, refer to 「The System Security Services Daemon (SSSD)」

NIS

The NIS option configures the system to connect to a NIS server (as an NIS client) for user and password authentication. To configure this option, specify the NIS domain and NIS server. If the NIS server is not specified, the daemon attempts to find it via broadcast.
The ypbind package must be installed for this option to work. If the NIS user account database is used, the portmap and ypbind services are started and are also enabled to start at boot time.
For more information about NIS, refer to section "Securing NIS" of the Fedora Security Guide.
NIS は次の認証方法を提供します。
  • Kerberos password — This option enables Kerberos authentication. For more information about configuration of the Kerberos authentication method, refer to the previous section on LDAP.
  • NIS パスワード — このオプションは NIS 認証を有効にします。NIS はユーザーを認証するために認証情報を外部のプロセスに提供できます。

Winbind

The Winbind option configures the system to connect to a Windows Active Directory or a Windows domain controller. User information from the specified directory or domain controller can then be accessed, and server authentication options can be configured. It contains the following specifications:
  • Winbind Domain — Specifies the Windows Active Directory or domain controller to connect to.
  • Security Model — Allows you to select a security model, which configures the Samba client mode of operation. The drop-down list allows you to select any of the following:
    • ads — This mode instructs Samba to act as a domain member in an Active Directory Server (ADS) realm. To operate in this mode, the krb5-server package must be installed, and Kerberos must be configured properly.
    • domain — In this mode, Samba will attempt to validate the username/password by authenticating it through a Windows NT Primary or Backup Domain Controller, similar to how a Windows NT Server would.
    • server — In this mode, Samba will attempt to validate the username/password by authenticating it through another SMB server (for example, a Windows NT Server). If the attempt fails, the user mode will take effect instead.
    • user — This is the default mode. With this level of security, a client must first log in with a valid username and password. Encrypted passwords can also be used in this security mode.
  • Winbind ADS Realm — When the ads Security Model is selected, this allows you to specify the ADS Realm the Samba server should act as a domain member of.
  • Winbind Domain Controllers — Use this option to specify which domain controller winbind should use. For more information about domain controllers, please refer to 「Domain Controller」.
  • Template Shell — When filling out the user information for a Windows NT user, the winbindd daemon uses the value chosen here to specify the login shell for that user.
  • Allow offline login — By checking this option, you allow authentication information to be stored in a local cache (provided by SSSD). This information is then used when a user attempts to authenticate while offline.
For more information about the winbindd service, refer to 「Samba デーモンと関連サービス」.
Winbind provides only one method of authentication, Winbind password. This method of authentication uses the options specified in the User Account Configuration of Winbind to connect to a Windows Active Directory or a Windows domain controller.

8.1.2. 高度なオプション

This tab allows you to configure advanced options, as listed below.
高度なオプション
図8.2 高度なオプション

ローカルの認証オプション

  • Enable fingerprint reader support — By checking this option, you enable fingerprint authentication to log in by scanning your finger with the fingerprint reader.
  • Enable local access control — When enabled, /etc/security/access.conf is consulted for authorization of a user.
  • Password Hashing Algorithm — This option lets you specify which hashing or cryptographic algorithm should be used to encrypt locally stored passwords.

その他の認証オプション

Create home directories on the first login — When enabled, the user's home directory is automatically created when they log in if it does not already exist.

スマート カードの認証オプション

Enable smart card support — This option enables smart card authentication. Smart card authentication allows you to log in using a certificate and a key associated with a smart card.
When the Enable smart card support option is checked, the following options can be specified:
  • Card Removal Action — This option defines what action the system performs when the card is removed from the card reader during an active session. Two alternatives are available:
    • Ignore — The card removal is ignored and the system continues to function as normal.
    • Lock — The current session is immediately locked.
  • Require smart card login — Requires the user to login and authenticate with a smart card. It essentially disables any other type of password authentication. This option should not be selected until after you have successfully logged in using a smart card.
The pam_pkcs11 and the coolkey packages must be installed for this option to work. For more information about smart cards, refer to the Red Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards Guide.

前の設定を復元するには Revert をクリックする

You can restore all of the options specified in the Authentication Configuration Tool to the previous configuration setup by clicking Revert.

8.1.3. コマンドライン版

The Authentication Configuration tool also supports a command line interface. The command line version can be used in a configuration script or a kickstart script. The authentication options are summarized in 表8.1「コマンドラインのオプション」.

Getting the list of supported authentication options

These options can also be found in the authconfig man page or by typing authconfig --help at the shell prompt.
表8.1 コマンドラインのオプション
オプション 説明
--enableshadow, --useshadow シャドウパスワードを有効にする
--disableshadow シャドウパスワードを解除する
--passalgo=descrypt|bigcrypt|md5|sha256|sha512 使用されるハッシュ/暗号アルゴリズム
--enablenis ユーザー アカウント設定向けの NIS を有効にする
--disablenis ユーザー アカウント設定向けの NIS を無効にする
--nisdomain=domain NIS ドメインを指定する
--nisserver=server NIS サーバーを指定する
--enableldap ユーザー アカウント設定向けの LDAP を有効にする
--disableldap ユーザー アカウント設定向けの LDAP を無効にする
--enableldaptls LDAP で TLS の使用を有効にする
--disableldaptls LDAP で TLS の使用を無効にする
--enablerfc2307bis Enable use of RFC-2307bis schema for LDAP user information lookups
--disablerfc2307bis Disable use of RFC-2307bis schema for LDAP user information lookups
--enableldapauth 認証の LDAP を有効にする
--disableldapauth 認証の LDAP を無効にする
--ldapserver=server LDAP サーバーを指定する
--ldapbasedn=dn Specify an LDAP base DN (Distinguished Name)
--ldaploadcacert=URL Load a CA certificate from the specified URL
--enablekrb5 Enable Kerberos for authentication
--disablekrb5 Disable Kerberos for authentication
--krb5kdc=server Specify Kerberos KDC server
--krb5adminserver=server Kerberos の管理サーバーを指定する
--krb5realm=realm Kerberos の realm を指定する
--enablekrb5kdcdns Kerberos KDC の検索に DNS の使用を有効にする
--disablekrb5kdcdns Kerberos KDC の検索に DNS の使用を無効にする
--enablekrb5realmdns Kerberos realm の検索に DNS の使用を有効にする
--disablekrb5realmdns Kerberos realm の検索に DNS の使用を無効にする
--enablewinbind ユーザー アカウント設定向けの winbind を有効にする
--disablewinbind ユーザー アカウント設定向けの winbind を無効にする
--enablewinbindauth 認証で winbindauth を有効にする
--disablewinbindauth 認証で winbindauth を無効にする
--winbindseparator=\ winbindusedefaultdomain が有効になっていない場合に、winbind ユーザー名のドメイン部分とユーザー部分を分離するために使用する文字です
--winbindtemplatehomedir=/home/%D/%U winbind ユーザーがホームとするディレクトリ
--winbindtemplateprimarygroup=nobody winbind ユーザーが最初のグループとするグループ
--winbindtemplateshell=/bin/false winbind ユーザーがログインシェルの初期値とするシェル
--enablewinbindusedefaultdomain ユーザー名にドメインのないユーザーはドメイン ユーザーであると winbind に仮定させる
--disablewinbindusedefaultdomain ユーザー名にドメインのないユーザーはドメイン ユーザーではないと winbind に仮定させる
--winbindjoin=Administrator Joins the winbind domain or ADS realm as the specified administrator
--enablewinbindoffline オフライン ログインを許可する winbind の設定
--disablewinbindoffline オフライン ログインを防ぐ winbind の設定
--smbsecurity=user|server|domain|ads Security mode to use for the Samba and Winbind services
--smbrealm=realm Default realm for Samba and Winbind services when security is set to ads
--enablewins ホスト名解決で Wins を有効にする
--disablewins ホスト名解決で Wins を無効にする
--enablesssd ユーザー情報の SSSD を有効にする
--disablesssd ユーザー情報の SSSD を無効にする
--enablecache nscd を有効にする
--disablecache nscd を無効にする
--enablelocauthorize Local authorization is sufficient for local users
--disablelocauthorize Local users are also authorized through a remote service
--enablesysnetauth ネットワーク サービスでシステム アカウントを認証する
--disablesysnetauth ローカルのファイルのみでシステム アカウントを認証する
--enablepamaccess アカウントの認可中に /etc/security/access.conf をチェックします
--disablepamaccess Do not check /etc/security/access.conf during account authorization
--enablemkhomedir Create a home directory for a user on the first login
--disablemkhomedir Do not create a home directory for a user on the first login
--enablesmartcard スマートカードでの認証を有効にする
--disablesmartcard スマートカードでの認証を無効にする
--enablerequiresmartcard 認証にスマートカードを要求する
--disablerequiresmartcard 認証にスマートカードを要求しない
--smartcardmodule=module 標準でスマートカードを使う
--smartcardaction=0=ロック|1=無視 スマートカードの抜き取りを検知したときのアクションです
--enablefingerprint Enable fingerprint authentication
--disablefingerprint Disable fingerprint authentication
--nostart Do not start or stop the portmap, ypbind, or nscd services even if they are configured
--test 新しい設定の表示のみで設定ファイルの更新をしない
--update, --kickstart Opposite of --test, update configuration files with changed settings
--updateall 全設定ファイルを更新する
--probe ネットワークデフォルトを調査して表示する
--savebackup=name 全設定ファイルのバックアップを保存する
--restorebackup=name 全設定ファイルのバックアップを復元する
--restorelastbackup Restore the backup of configuration files saved before the previous configuration change

8.2. The System Security Services Daemon (SSSD)

This section provides an introduction to the System Security Services Daemon (SSSD), the main features that it provides, and discusses the requirements and any limitations of a typical SSSD deployment.
This section also describes how to configure SSSD, and how to use the features that it provides. It provides information on the types of services that it supports and how to configure them, and introduces and describes the most important configuration options. Sample configuration files are also provided to help you optimize your deployment.

8.2.1. What is SSSD?

The System Security Services Daemon (SSSD) is a service which provides access to different identity and authentication providers. You can configure SSSD to use a native LDAP domain (that is, an LDAP identity provider with LDAP authentication), or an LDAP identity provider with Kerberos authentication. It provides an NSS and PAM interface to the system, and a pluggable back-end system to connect to multiple different account sources.
SSSD is also extensible; you can configure it to use new identity sources and authentication mechanisms should they arise. In addition, SSSD is fully IPv6-compatible, provided that it is built against c-ares 1.7.1 or later and krb5-libs 1.8.1 or later.

8.2.2. SSSD Features

8.2.2.1. Offline Authentication

One of the primary benefits of SSSD is offline authentication. This solves the case of users having a separate corporate account and a local machine account because of the common requirement to implement a Virtual Private Network (VPN).
SSSD can cache remote identities and authentication credentials. This means that you can still authenticate with these remote identities even when a machine is offline. In an SSSD system, you only need to manage one account.

8.2.2.2. Server Load Reduction

The use of SSSD also helps to reduce the load on identification servers. For example, using nss_ldap, every client application that needs to request user information opens its own connection to the LDAP server. Managing these multiple connections can lead to a heavy load on the LDAP server. In an SSSD system, only the SSSD Data Provider process actually communicates with the LDAP server, reducing the load to one connection per client system.

8.2.2.3. Support for Multiple Domains

You can use SSSD to specify multiple domains of the same type. Compare this to an nsswitch.conf file configuration, with which you can only request user information from a single server of any particular type (LDAP, NIS, etc.). With SSSD, you can create multiple domains of the same, or of different types of identity provider.
Beginning with version 0.6.0, SSSD maintains a separate database file for each domain. This means that each domain has its own cache, and in the event that problems occur and maintenance is necessary, it is very easy to purge the cache for a single domain, by stopping sssd and deleting the corresponding cache file. These cache files are stored in the /var/lib/sss/db/ directory.
All cache files are named according to the domain that they represent, for example cache_DOMAINNAME.ldb.
Considerations Associated with Deleting Cache Files
Deleting a domain's cache file can have some unexpected side effects. You should be aware of the following before you proceed:
  • Deleting the cache file also deletes all user data (both identification and cached credentials). Consequently, you should not proceed unless you are online and can authenticate with your username against the domain's servers, because offline authentication will fail.
  • If you are online and change your configuration to reference a different identity provider, SSSD will recognize users from both providers until the cached entries from the original provider time out.
    To avoid this situation, you can either purge the cache or use a different domain name for the new provider (this is the recommended practice). Changing the domain name means that when you restart SSSD it will create a new cache file (with the new name) and the old file will be ignored.

8.2.2.4. Support for LDAP Referrals

SSSD supports two types of LDAP referrals: object-level referrals and subtree referrals. These referral types and the extent of SSSD support is outlined below.
8.2.2.4.1. Object-level Referrals
SSSD provides full support for object-level referrals within the same LDAP server, correctly handling any differences in the distinguished name (DN) that might exist as part of the LDAP server referral configuration.
SSSD provides partial support for object-level referrals between different LDAP servers, and requires that the full DN of an LDAP request be identical on each server. SSSD does not support referrals to different DN paths on other servers.
8.2.2.4.2. Subtree Referrals
SSSD provides a similar level of support for subtree referrals as it does for object-level referrals. That is, it supports referrals to a changed DN on the local system or to an identical DN on a remote system. The difference with subtree referrals, however, is the ability to set up identical subtrees on each LDAP server and to then configure referrals between these subtrees.
8.2.2.4.3. Enabling LDAP Referrals
To take advantage of the SSSD LDAP referral functionality, you need to set the ldap_referrals option to TRUE in the LDAP domain configuration section of the /etc/sssd/sssd.conf file. This will enable anonymous access to the second LDAP server.

Make sure SSSD is compiled with OpenLDAP version 2.4.13 or later

SSSD only supports LDAP referrals when it is compiled with OpenLDAP version 2.4.13 or later.

8.2.2.5. Differentiating Like-named Users

SSSD supports the differentiation of like-named users in different domains. For example, you can differentiate the user kate in the ldap.example.com domain from the user kate in the ldap.myhome.com domain. You can use SSSD to make requests using fully-qualified usernames. If you request information for kate, you will receive the information from whichever domain is listed first in the look-up order. If you request information for kate@ldap.myhome.com, however, you will receive the correct user information.
SSSD also provides a filter_users option, which you can use to exclude certain users from being fetched from the database. Refer to the sssd.conf(5) manual page for full details about this option.

8.2.2.6. Integration with IPA

Beyond the offline authentication, multiple domain management and other features already described, SSSD is also designed to integrate with and enhance the functionality of IPA clients. In an environment with the latest version of IPA installed, SSSD provides additional functionality, including support for dynamic DNS updates, host-based access control, and password migration from an LDAP-only environment into the LDAP/Kerberos 5 environment employed by IPA.
8.2.2.6.1. Support for Dynamic DNS Updates
Because the IP address of IPA clients can change, SSSD provides the ability to dynamically update the client's DNS entry on the IPA server. Using a combination of Kerberos and GSS-TSIG (Generic Security Service Algorithm for Secret Key Transaction), IPA can determine the identity of the host machine, authenticate it, and allow that machine to edit its own DNS record. These changes are then stored in the LDAP back end.

Each IPA client can only edit its own DNS record

Using this authentication system means that each IPA client can only edit its own DNS record; it cannot edit the DNS record of any other client.
Setting up Dynamic DNS Updates
The SSSD configuration file provides two options used for setting up dynamic DNS updates: ipa_dyndns_update, used to enable dynamic DNS updates; and ipa_dyndns_iface, which specifies the interface whose IP address should be used for dynamic DNS updates.
Refer to the sssd-ipa manual page for more information about these options, and how to configure dynamic DNS updates.

Support for dynamic DNS updates

Support for dynamic DNS updates is only available on IPA version 2 or later, and with DNS correctly configured.

8.2.3. Setting Up SSSD

This section describes how to install SSSD, how to run the service, and how to configure it for each type of supported information provider.

8.2.3.1. Installing SSSD

Run the following command to install SSSD and any dependencies, including the SSSD client:
# yum install sssd
SSSD requires very few dependencies and should install very quickly, depending on the speed of your network connection.
8.2.3.1.1. Upgrading from a Previous Version
Upgrading Using RPM Packages
If you are upgrading using RPM packages, the script will run automatically when you upgrade to the new version. This will upgrade the /etc/sssd/sssd.conf file to the new format, and copy the existing version to /etc/sssd/sssd.conf.bak.
Upgrading Manually
It may be necessary to run the upgrade script manually, either because you built SSSD from source files, or because you are using a platform that does not support the use of RPM packages. The synopsis for the script is as follows:

upgrade_config.py [ -f INFILE ] [ -o OUTFILE ] [ -verbose ] [ --no-backup ]

  • -f INFILE — the configuration file to upgrade. If not specified, this defaults to /etc/sssd/sssd.conf
  • -o OUTFILE — the name of the upgraded configuration file. If not specified, this defaults to /etc/sssd/sssd.conf
  • -verbose — produce more verbose output during the upgrade process
  • --no-backup — do not produce a back-up file. If not specified, this defaults to INFILE.bak
8.2.3.1.2. Starting and Stopping SSSD

Starting SSSD for the first time

Before you start SSSD for the first time, you need to configure at least one domain. Refer to 「Configuring Domains」 for information on how to configure an SSSD domain.
You can use either the service command or the /etc/init.d/sssd script to control SSSD. For example, run the following command to start sssd:
# systemctl start sssd.service
By default, SSSD is configured not to start automatically. There are two ways to change this behavior; if you use the Authentication Configuration tool to configure SSSD, it will reconfigure the default behavior so that SSSD starts when the machine boots. Alternatively, you can use the systemctl command, as follows:
# systemctl enable sssd.service

8.2.3.2. Configuring SSSD

The global configuration of SSSD is stored in the /etc/sssd/sssd.conf file. This file consists of various sections, each of which contains a number of key/value pairs. Some keys accept multiple values; use commas to separate multiple values for such keys. This configuration file uses data types of string (no quotes required), integer and Boolean (with values of TRUE or FALSE). Comments are indicated by either a hash sign (#) or a semicolon (;) in the first column. The following example illustrates some of this syntax:
[section]
# Keys with single values
key1 = value
key2 = val2

# Keys with multiple values
key10 = val10,val11

Specifying a different configuration file

You can use the -c (or --config) parameter on the command line to specify a different configuration file for SSSD.
The format of the configuration file is described in 「SSSD Configuration File Format」
Refer to the sssd.conf(5) manual page for more information on global SSSD configuration options.
8.2.3.2.1. Configuring NSS
SSSD provides a new NSS module, sssd_nss, so that you can configure your system to use SSSD to retrieve user information. Edit the /etc/nsswitch.conf file for your system to use the sss name database. For example:
passwd: files sss
group: files sss
8.2.3.2.2. Configuring PAM

Be careful when changing your PAM configuration

Use extreme care when changing your PAM configuration. A mistake in the PAM configuration file can lock you out of the system completely. Always back up your configuration files before performing any changes, and keep a session open so that you can revert any changes you make should the need arise.
To enable your system to use SSSD for PAM, you need to edit the default PAM configuration file. On Fedora—based systems, this is the /etc/pam.d/system-auth file. Edit this file to reflect the following example, and then restart sssd:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel/
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     sufficient    pam_sss.so
session     required      pam_unix.so
8.2.3.2.2.1. Using Custom Home Directories with SSSD
If your LDAP users have home directories that are not in /home, and if your system is configured to create home directories the first time your users log in, then these directories will be created with the wrong permissions. For example, instead of a typical home directory such as /home/<username>, your users might have home directories that include their locale, such as /home/<locale>/<username>. If this is true for your system, the following steps need to be taken (preemptively):
  1. Apply the correct SELinux context and permissions from the /home directory to the home directory that you use on your system. In the example above, the following command would achieve this result (replace the directory names with those that apply to your system):
    # semanage fcontext -a -e /home /home/locale
  2. Ensure the oddjob-mkhomedir package is installed on your system and then re-run the Authentication Configuration tool.
    This package provides the pam_oddjob_mkhomedir.so library, which the Authentication Configuration tool will then use to create your custom home directories. You need to use this library to create your home directories, and not the default pam_mkhomedir.so library, because the latter cannot create SELinux labels.

    The pam_oddjob_mkhomedir and pam_mkhomedir libraries

    The Authentication Configuration tool will automatically use the pam_oddjob_mkhomedir.so library if it is available. Otherwise, it will default to using pam_mkhomedir.so.
If the preceding steps were not performed before the custom home directories were created, you can use the following commands to correct the permissions and SELinux contexts (again, replace the directory names with those that apply to your system):
# semanage fcontext -a -e /home /home/locale
# restorecon -R -v /home/locale
8.2.3.2.2.2. Using "include" Statements in PAM Configurations
Recent PAM implementations allow you to use include statements in PAM configurations. For example:
...
session     include      system-auth
session     optional     pam_console.so
...
In the preceding example, if a sufficient condition from system-auth returns PAM_SUCCESS, pam_console.so will not be executed.
8.2.3.2.3. Configuring Access Control
SSSD provides a rudimentary access control mechanism, offering two solutions based on the value of the access_provider option in the [domain/<NAME>] section in the /etc/sssd/sssd.conf file.
8.2.3.2.3.1. The Simple Access Provider
The first of these solutions is known as the Simple Access Provider, and is based on the implementation of access or deny lists of usernames. To enable the Simple Access Provider, you need to set the access_provider option to simple, and then add usernames as a comma-separated list to either the simple_allow_users or simple_deny_users options.
Using the Simple Access Provider
By using the Simple Access Provider, you can continue to support a number of network logins to maintain common network accounts on company or department laptops, but you might want to restrict the use of a particular laptop to one or two users. This means that even if a different user authenticated successfully against the same authentication provider, the Simple Access Provider would prevent that user from gaining access.
The following example demonstrates the use of the Simple Access Provider to grant access to two users. This example assumes that SSSD is correctly configured and example.com is one of the domains specified in the [sssd] section, and only shows the Simple Access Provider-specific options.
[domain/example.com]
access_provider = simple
simple_allow_users = user1, user2

Using the Local ID provider

The Local ID provider does not support simple as an access provider.
Access Control Rules
The Simple Access Provider adheres to the following three rules to determine which users should or should not be granted access:
  • If both lists are empty, access is granted.
  • If simple_allow_users is set, only users from this list are allowed access. This setting supersedes the simple_deny_users list (which would be redundant).
  • If the simple_allow_users list is empty, users are allowed access unless they appear in the simple_deny_users list.

Do not define both simple_allow_users and simple_deny_users

Defining both simple_allow_users and simple_deny_users is a configuration error. If this occurs, SSSD will output an error to the /var/log/sssd/sssd_default.log log file when loading the back end, but continue to start normally. Future versions of SSSD will output an error and fail to start.
8.2.3.2.3.2. The LDAP Access Provider
The second access control solution uses the LDAP server itself as the access provider (access_provider=ldap) and the associated filter option (ldap_access_filter) to specify which users are granted access to the specified host. Note that these two options are codependent; if you use LDAP as your access provider then you must specify a value for the ldap_access_filter option, otherwise all users will be denied access. If you are not using LDAP as your access provider, then the ldap_access_filter option has no effect.
Using the LDAP Access Provider
The following example demonstrates the use of the LDAP Access Provider to grant access to members of the "allowedusers" group in LDAP. This example assumes that SSSD is correctly configured and example.com is one of the domains specified in the [sssd] section, and only shows the LDAP Access Provider-specific options.
[domain/example.com]
access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com

Using offline caching

Offline caching for this feature is limited to determining whether or not the user's last online login attempt was successful. If they were granted access during their last login, they will continue to be granted access while offline, and vice-versa.
Refer to the sssd-ldap manual page for more information about using the LDAP Access Provider.
8.2.3.2.4. Configuring Failover
The failover feature allows back ends to automatically switch to a different server if the primary server fails. These servers are entered as a case-insensitive, comma-separated list in the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and listed in order of preference. This list can contain any number of servers.
For example, if you have configured a native LDAP domain, you could specify the following as your ldap_uri values:
ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org
In this configuration, ldap://ldap0.mydomain.org functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to ldap1.mydomain.org, and if that server is unavailable, it then attempts to connect to ldap2.mydomain.org.
If the parameter that specifies which server to connect to for the specific domain (for example, ldap_uri, krb5_server, …) is not specified, the back end defaults to using Use service discovery. Refer to 「Using SRV Records with Failover」 for more information on service discovery.

Do not use multiple ldap_uri parameters

Do not use multiple ldap_uri parameters to specify your failover servers. The failover servers must be entered as a comma-separated list of values for a single ldap_uri parameter. If you enter multiple ldap_uri parameters, SSSD only recognizes the last entry.
Future versions of SSSD will throw an error upon receiving additional ldap_uri entries.
8.2.3.2.4.1. Using SRV Records with Failover
SSSD also supports the use of SRV records in its failover configuration. This means that you can specify a server that is later resolved into a list of specific servers using SRV requests. The priority and weight attributes of SRV records provide further opportunity for specifying which servers should be contacted first in the event that the primary server fails.
For every service with which you want to use service discovery, you need to add a special DNS record to your DNS server using the following form:
_service._protocol._domain TTL priority weight port hostname
A typical configuration would contain multiple such records, each with a different priority (for failover) and different weights (for load balancing).
The client then makes an SRV DNS query to retrieve a list of host names, their priorities, and weights. These queries are of the form _service._protocol._domain, for example, _ldap._tcp._redhat.com. The client then sorts this list according to the priorities and weights, and connects to the first server in this sorted list.
For more information on SRV records, refer to RFC 2782.
8.2.3.2.4.2. How the Failover Mechanism Works
The failover mechanism distinguishes between machines and services. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this machine for any other service. If the resolution attempt succeeds, the back end tries to connect to a service on this machine. If the service connection attempt fails, then only this particular service is considered offline and the back end automatically switches over to the next service. The machine is still considered online and might still be tried for another service.
The failover mechanism does not handle DNS A records with multiple IP addresses; instead it only uses the first address. DNS round-robin cannot be used for failover. Further, providing multiple A records does not provide failover. Only the first A record is used, and if a lookup attempt on the first record fails then the system attempts no further lookups. To find multiple servers with a single request, and thus implementing failover, SSSD relies on SRV resource records, as explained in 「Using SRV Records with Failover」.
Further connection attempts are made to machines or services marked as offline after a specified period of time; this is currently hard coded to 30 seconds. If there are no more machines to try, the back end as a whole switches to offline mode, and then attempts to reconnect every 30 seconds.

8.2.4. Configuring Services

Individual pieces of SSSD functionality are provided by special SSSD services that are started and stopped together with SSSD. The services provided by SSSD have their own configuration sections. The [sssd] section also lists the services that are active and should be started when sssd starts within the services directive.
SSSD currently provides several services:
  • NSS — An NSS provider service that answers NSS requests from the sssd_nss module.
  • PAM — A PAM provider service that manages a PAM conversation through the sssd_pam PAM module.
  • monitor — A special service that monitors all other SSSD services, and starts or restarts them as needed. Its options are specified in the [sssd] section of the /etc/sssd/sssd.conf configuration file.

8.2.4.1. Configuration Options

The following sections cover the most important SSSD configuration options. Refer to the sssd.conf(5) manual page that ships with SSSD for information on all the available configuration options.
8.2.4.1.1. General Configuration Options
  • debug_level (integer)
    Sets the debug level for a particular service. This is a per-service setting (that is, it can appear in any of the [service/<NAME>] sections in the SSSD configuration file).
  • reconnection_retries (integer)
    In the event of a data provider crash or restart, this specifies the number of times that a service should attempt to reconnect.

    DNS lookup of IPv6 addresses

    If a DNS lookup fails to return an IPv4 address for a hostname, SSSD attempts to look up an IPv6 address before returning a failure. Note that this only ensures that the async resolver identifies the correct address; there is currently a bug in the LDAP code that prevents SSSD from connecting to an LDAP server over IPv6. This is being investigated separately.
8.2.4.1.2. NSS Configuration Options
Use the following options to configure the Name Service Switch (NSS) service. Refer to the sssd.conf(5) manual page for full details about each option.
  • enum_cache_timeout (integer)
    Specifies for how long (in seconds) sssd_nss should cache enumerations (requests for information about all users).
  • entry_cache_nowait_percentage (integer)
    Specifies for how long sssd_nss should return cached entries before initiating an out-of-band cache refresh (0 disables this feature).
    You can configure the entry cache to automatically update entries in the background if they are requested beyond a percentage of the entry_cache_timeout value for the domain.
    Valid values for this option are 0-99, and represent a percentage of the entry_cache_timeout value for each domain.
  • entry_negative_timeout (integer)
    Specifies for how long (in seconds) sssd_nss should cache negative cache hits (that is, queries for invalid database entries, such as nonexistent ones) before asking the back end again.
  • filter_users, filter_groups (string)
    Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts such as root.
  • filter_users_in_groups (Boolean)
    If set to TRUE, specifies that users listed in the filter_users list do not appear in group memberships when performing group lookups. If set to FALSE, group lookups return all users that are members of that group. If not specified, defaults to TRUE.
8.2.4.1.3. PAM Configuration Options
Use the following options to configure the Pluggable Authentication Module (PAM) service.
  • offline_credentials_expiration (integer)
    If the authentication provider is offline, specifies for how long to allow cached log-ins (in days). This value is measured from the last successful online log-in. If not specified, defaults to 0 (no limit).
  • offline_failed_login_attempts (integer)
    If the authentication provider is offline, specifies how many failed log in attempts are allowed. If not specified, defaults to 0 (no limit).
  • offline_failed_login_delay (integer)
    Specifies the time in minutes after the value of offline_failed_login_attempts has been reached before a new log in attempt is possible.
    If set to 0, the user cannot authenticate offline if the value of offline_failed_login_attempts has been reached. Only a successful online authentication can re-enable offline authentication. If not specified, defaults to 5.

8.2.5. Configuring Domains

A domain is a database of user information. SSSD can use more than one domain at the same time, but at least one must be configured for SSSD to start. Using SSSD domains, it is possible to use several LDAP servers providing several unique namespaces. You can specify not only where users' identity information is stored, but how users authenticate against each of the specified domains.
SSSD supports the following identity and authentication combinations:
LDAP/LDAP
This combination uses an LDAP back end as both the identity and authentication provider. For more information, refer to 「Configuring an LDAP Domain」.
LDAP/KRB5
This combination uses an LDAP back end as the identity provider, and uses Kerberos to provide authentication. For more information, refer to 「Setting Up Kerberos Authentication」.
proxy
Specifying a proxy identity or an authentication provider uses an existing NSS library or a customized PAM stack, but takes advantage of the SSSD caching mechanism. For more information, refer to 「Configuring a Proxy Domain」.
The following example assumes that SSSD is correctly configured and FOO is one of the domains in the [sssd] section. This example shows only the configuration of Kerberos authentication; it does not include any identity provider.
[domain/FOO]
auth_provider = krb5
krb5_server = 192.168.1.1
krb5_realm = EXAMPLE.COM

8.2.5.1. Domain Configuration Options

You can add new domain configurations to the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and then add the list of domains to the domains attribute of the [sssd] section, in the order you want them to be queried.
8.2.5.1.1. General Domain Configuration Options
You can use the following configuration options in a domain configuration section:
  • min_id,max_id (integer)
    Specifies the UID and GID limits for the domain. If a domain contains entries that are outside these limits, they are ignored.
    The default value for min_id is 1; the default value for max_id is 0 (unbounded).

    Avoid conflicts with users in /etc/passwd

    If min_id is unspecified, it defaults to 1 for any back end. This default was chosen to provide compatibility with existing systems and to ease any migration attempts. LDAP administrators should be aware that granting identities in this range may conflict with users in the local /etc/passwd file. To avoid these conflicts, min_id should be set to 1000 or higher wherever possible.
    The min_id option determines the minimum acceptable value for both UID and GID numbers. Accounts with either UID or GID values below the min_id value are filtered out and not made available on the client.
  • enumerate (Boolean)
    Specifies whether or not to enumerate (list) the users and groups of a domain.
    Enumeration means that the entire set of available users and groups on the remote source is cached on the local machine. When enumeration is disabled, users and groups are only cached as they are requested.

    Disable enumeration for domains with many users and groups

    If a client has enumeration enabled, reinitialization of the client results in a complete refresh of the entire set of available users and groups from the remote source. Similarly, when SSSD is connected to a new server, the entire set of available users and groups from the remote source is pulled and cached on the local machine. In a domain with a large amount of clients connected to a remote source, both aforementioned cases can affect the network performance due to frequent queries from the clients. If the set of available users and groups is large enough, it will affect the performance of clients as well. For performance reasons, it is recommended that you disable enumeration for domains with many users and groups.
    The default value for this parameter is FALSE. Set this value to TRUE to enable enumeration of users and groups of a domain.
  • timeout (integer)
    Specifies the timeout in seconds for this particular domain.
    This is used to ensure that the back end process is alive and capable of answering requests. The default value for this parameter is 10 seconds. Raising this timeout might prove useful for slower back ends, such as distant LDAP servers.

    Changing the timeout value to 0

    If you set timeout = 0, SSSD reverts to the default value; you cannot force a timeout value of zero, because this would force the sssd daemon into a loop.
  • cache_credentials (Boolean)
    Specifies whether or not to store user credentials in the local SSSD domain database cache.
    The default value for this parameter is FALSE. You should set this value to TRUE for domains other than local if you want to enable offline authentication.
  • id_provider (string)
    Specifies the data provider identity back end to use for this domain. Currently supported identity back ends are:
    • proxy — Support a legacy NSS provider (for example, nss_nis).

      Changing the id_provider value to proxy

      SSSD needs to know which legacy NSS library to load in order to start successfully. If you set id_provider to proxy, ensure that you also specify a value for proxy_lib_name. Refer to 「Configuring a Proxy Domain」 for information on this attribute.
    • local — SSSD internal local provider.
    • ldap — LDAP provider.
  • entry_cache_timeout (integer)
    Specifies for how long the domain's data provider should cache positive cache hits (that is, queries for valid database entries) before asking the database again.
  • use_fully_qualified_names (Boolean)
    Specifies whether or not requests to this domain require fully-qualified domain names.
    If set to TRUE, all requests to this domain must use fully-qualified domain names. It also means that the output from the request displays the fully-qualified name.
    The ability to restrict requests in this way means that if you know you have multiple domains with conflicting usernames, then there is no doubt about which username the query will resolve.
    Consider the following examples, in which the IPA domain database contains a user named ipauser01, and the use_fully_qualified_names attribute is set to TRUE:
    # getent passwd ipauser01
    [no output]
    # getent passwd ipauser01@IPA
    ipauser01@IPA:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    
    In the following examples, using the same IPA domain and user, the use_fully_qualified_names attribute is set to FALSE:
    # getent passwd ipauser01
    ipauser01:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    # getent passwd ipauser01@IPA
    ipauser01:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    

    Changing the use_fully_qualified_names value to FALSE

    If use_fully_qualified_names is set to FALSE, you can continue to use the fully-qualified name in your requests, but only the simplified version is displayed in the output.
    SSSD can only parse name@domain, not name@realm. You can, however, use the same name for both your domain and your realm.
  • auth_provider (string)
    The authentication provider used for the domain. The default value for this option is the value of id_provider if it is set and can handle authentication requests.
    Currently supported authentication providers are:
    • ldap — for native LDAP authentication. Refer to the sssd-ldap(5) manual page for more information on configuring LDAP.
    • krb5 — for Kerberos authentication. Refer to the sssd-krb5(5) manual page for more information on configuring Kerberos.
    • proxy — for relaying authentication to some other PAM target.
    • none — explicitly disables authentication.
8.2.5.1.2. Proxy Configuration Options
  • proxy_pam_target (string)
    This option is only used when the auth_provider option is set to proxy, and specifies the target to which PAM must proxy.
    This option has no default value. If proxy authentication is required, you need to specify your own PAM target. This corresponds to a file containing PAM stack information in the system's default PAM configuration directory. On Fedora-based systems, this is the /etc/pam.d/ directory.

    Avoid recursive inclusion of pam_sss

    Ensure that your proxy PAM stack does not recursively include pam_sss.so.
  • proxy_lib_name (string)
    This option is only used when the id_provider option is set to proxy, and specifies which existing NSS library to proxy identity requests through.
    This option has no default value. You need to manually specify an existing library to take advantage of this option. For example, set this value to nis to use the existing libnss_nis.so file.

8.2.5.2. Configuring an LDAP Domain

An LDAP domain is one where the id_provider option is set to ldap (id_provider = ldap). Such a domain requires a running LDAP server against which to authenticate. This can be an open source LDAP server such as OpenLDAP or Microsoft Active Directory. SSSD currently supports Microsoft Active Directory 2003 (+Services for UNIX) and Active Directory 2008 (+Subsystem for UNIX-based Applications). In all cases, the client configuration is stored in the /etc/sssd/sssd.conf file.
How to Authenticate Against an LDAP Server
SSSD does not support authentication over an unencrypted channel. Consequently, if you want to authenticate against an LDAP server, either TLS/SSL or LDAPS is required. If the LDAP server is used only as an identity provider, an encrypted channel is not needed.
Edit your /etc/sssd/sssd.conf file to include the following settings:
# A native LDAP domain
[domain/LDAP]
enumerate = false
cache_credentials = TRUE

id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
chpass_provider = ldap

ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

Creating a certificate with an IP address instead of the server name

If you wish to use an IP address in the ldap_uri option instead of the server name, for example, if GSSAPI is used to avoid time consuming DNS lookups, the TSL/SSL setup might fail. This is due to the fact that TSL/SSL certificates contain the server name only. However, a special field in the certificate, called Subject Alternative Name (subjectAltName), can be used to additionally set the IP address of the server.
The following steps show how to create a certificate with a Subject Alternative Name being the IP address of your server:
  1. Using your command line, execute the following command to convert an existing certificate (previously signed by the key.pem key) into a certificate request:
    openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey key.pem
    Alternatively, if you are using a self-signed certificate(for example, one created by the Fedora OpenLDAP package in /etc/pki/tls/certs/slapd.pem), execute the following command:
    openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey old_cert.pem
  2. Edit your /etc/pki/tls/openssl.cnf configuration file to include the following line under the [ v3_ca ] section:
    subjectAltName = IP:10.0.0.10
    Replace the IP address with one of your choice.
  3. By executing the following command, use the previously generated certificate request to generate a new self-signed certificate that will contain your desired IP address:
    openssl x509 -req -in req.pem -out new_cert.pem -extfile ./openssl.cnf -extensions v3_ca -signkey old_cert.pem
    where:
    • The openssl x509 command creates the new certificate.
    • The -req option tells the command to expect a certificate request as an input.
    • The -in and -out options specify the input and output files.
    • The -extfile option expects a file containing certificate extensions to use (in our case the subjectAltName extension).
    • The -extensions option specifies the section of the openssl.cnf file to add certificate extensions from (in this case, the [ v3_ca ] section).
    • The -signkey option tells the command to self-sign the input file using the supplied private key.
    For more information on the x509 utility and its parameters, refer to man x509.
  4. Lastly, copy the private key block from the old_cert.pem file into the new_cert.pem file to keep all relevant information in one file.
When creating a certificate through the certutil utility provided by the nss-utils package, note that certutil supports DNS subject alternative names for certificate creation only.
It is advisable to use a Certificate Authority to issue your certificate. Consider using the Red Hat Certificate System; for more information on managing subject names and subject alternative names in your certificate, refer to the Red Hat Certificate System Admin Guide.
Selecting an LDAP Schema
You can set the ldap_schema attribute to either rfc2307 or rfc2307bis. These schema define how groups in LDAP are specified. In RFC 2307, group objects use a multi-valued attribute, memberuid, which lists the names of the users that belong to that group. In RFC 2307bis, instead of the memberuid, group objects use the member attribute. Rather than just the name of the user, this attribute contains the full Distinguished Name (DN) of another object in the LDAP database. This means that groups can have other groups as members. That is, it adds support for nested groups.
SSSD assumes that your LDAP server is using RFC 2307. If your LDAP server is using RFC 2307bis, and you do not update the /etc/sssd/sssd.conf file accordingly, this can impact how your users and groups are displayed. It also means that some groups will not be available and network resources may be inaccessible even though you have permissions to use them.
For example, when using RFC 2307bis and you have configured both primary and secondary groups, or are using nested groups, you can use the id command to display these groups:
[f12server@ipaserver ~]$ id
uid=500(f12server) gid=500(f12server) groups=500(f12server),510(f12tester)
If instead you have configured your client to use RFC 2307 then only the primary group is displayed.
Changes to this setting only affect how SSSD determines the groups to which a user belongs; there is no negative effect on the actual user data. If you do not know the correct value for this attribute, consult your System Administrator.
Specifying Timeout Values
SSSD supports a number of timeout values that apply when configuring an LDAP domain. These are described below.
  • ldap_search_timeout (integer) — Specifies the timeout (in seconds) that LDAP searches are allowed to run before they are canceled and cached results are returned (and offline mode is entered). If not specified:
    Defaults to five when enumerate = False
    Defaults to 30 when enumerate = True. This option is forced to a minimum of 30 in this case.

    The ldap_network_timeout option is going to be changed

    This option is subject to change in future versions of SSSD, where it may be replaced by a series of timeouts for specific look-up types.
  • ldap_network_timeout (integer) — Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.
    If not specified, defaults to five.
  • ldap_opt_timeout (integer) — Specifies the timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. This option also controls the timeout when communicating with the KDC in case of a SASL bind.
    If not specified, defaults to five.

DNS Service Discovery

The DNS service discovery feature allows the LDAP back end to automatically find the appropriate DNS servers to connect to using a special DNS query. For more information on the DNS service discovery feature, refer to 「Using SRV Records with Failover」.

8.2.5.3. Configuring a Microsoft Active Directory Domain

You can configure SSSD to use Microsoft Active Directory as an LDAP back end, providing both identity and authentication services. If you are using Active Directory 2003, SSSD requires that you install Windows Services for UNIX (SFU) on the machine where Active Directory is installed. If instead you are using Active Directory 2008, you need to install the Subsystem for UNIX-based Applications (SUA) on the Active Directory machine.

SFU is not supported on 64-bit systems

SFU is not supported on 64-bit operating systems. Refer to http://support.microsoft.com/kb/920751 for more information about which Windows systems can provide a suitable platform for an SSSD LDAP back end.
8.2.5.3.1. Configuring Active Directory 2003 as an LDAP Back End
The example /etc/sssd/sssd.conf file that ships with SSSD contains the following sample configuration for Active Directory 2003:
# Example LDAP domain where the LDAP server is an Active Directory 2003 server.

[domain/AD]
description = LDAP domain with AD server
enumerate = false
min_id = 1000
;
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://your.ad.server.com
ldap_schema = rfc2307bis
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = YOUR_PASSWORD
ldap_user_object_class = person
ldap_user_name = msSFU30Name
ldap_user_uid_number = msSFU30UidNumber
ldap_user_gid_number = msSFU30GidNumber
ldap_user_home_directory = msSFU30HomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = msSFU30Name
ldap_group_gid_number = msSFU30GidNumber
This configuration is specific to Windows Active Directory 2003. Refer to 「Configuring Active Directory 2003 R2 and 2008 as LDAP Back Ends」 for information on how to configure Active Directory 2003 R2 and Active Directory 2008.
Note that the above configuration assumes that the certificates are stored in the default location (that is, in /etc/openldap/cacerts) and that the c_rehash function has been used to create the appropriate symlinks.
More Information
Refer to the sssd-ldap(5) manual page for a full description of all the options that apply to LDAP domains.
8.2.5.3.2. Configuring Active Directory 2003 R2 and 2008 as LDAP Back Ends
The configuration of /etc/sssd/sssd.conf to support Active Directory 2003 R2 or Active Directory 2008 as a back end is similar to that for AD 2003. The following example configuration highlights the necessary changes.
# Example LDAP domain where the LDAP server is an Active Directory 2003 R2 or an Active Directory 2008 server.

[domain/AD]
description = LDAP domain with AD server
; debug_level = 9
enumerate = false

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldap://your.ad.server.com
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_cacert = /etc/openldap/cacerts/test.cer
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = YOUR_PASSWORD
ldap_pwd_policy = none
ldap_user_object_class = user
ldap_group_object_class = group
Note that the above configuration assumes that the certificates are stored in the default location (that is, in /etc/openldap/cacerts) and that the c_rehash function has been used to create the appropriate symlinks.

8.2.6. Setting Up Kerberos Authentication

In order to set up Kerberos authentication, you need to know the address of your key distribution center (KDC) and the Kerberos domain. The client configuration is then stored in the /etc/sssd/sssd.conf file.
The Kerberos 5 authentication back end does not contain an identity provider and must be paired with one in order to function properly (for example, id_provider = ldap). Some information required by the Kerberos 5 authentication back end must be supplied by the identity provider, such as the user's Kerberos Principal Name (UPN). The identity provider configuration should contain an entry to specify this UPN. Refer to the manual page for the applicable identity provider for details on how to configure the UPN.
If the UPN is not available in the identity back end, SSSD will construct a UPN using the format username@krb5_realm.
SSSD assumes that the Kerberos KDC is also a Kerberos kadmin server. However, it is very common for production environments to have multiple, read-only replicas of the KDC, but only a single kadmin server (because password changes and similar procedures are comparatively rare). To manage this type of configuration, you can use the krb5_kpasswd option to specify where your password changing service is running, or if it is running on a non-default port. If the krb5_kpasswd option is not defined, SSSD tries to use the Kerberos KDC in order to change the password. Refer to the sssd-krb5(5) manual page for more information about this and all Kerberos configuration options.
How to Set Up Kerberos Authentication
Edit your /etc/sssd/sssd.conf file to include the following settings:
# A domain with identities provided by LDAP and authentication by Kerberos
[domain/KRBDOMAIN]
enumerate = false
id_provider = ldap
chpass_provider = krb5
ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

auth_provider = krb5
krb5_server = 192.168.1.1
krb5_realm = EXAMPLE.COM
krb5_changepw_principal = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15
This example describes the minimum options that must be configured when using Kerberos authentication. Refer to the sssd-krb5(5) manual page for a full description of all the options that apply to configuring Kerberos authentication.

DNS Service Discovery

The DNS service discovery feature allows the Kerberos 5 authentication back end to automatically find the appropriate DNS servers to connect to using a special DNS query. For more information on the DNS service discovery feature, refer to 「Using SRV Records with Failover」.

8.2.6.1. Setting up SASL/GSSAPI Authentication

GSSAPI (Generic Security Services Application Programming Interface) is a supported SASL (Simple Authentication and Security Layer) authentication method. Kerberos is currently the only commonly used GSSAPI implementation. An LDAP client and an LDAP server use SASL to take advantage of GSSAPI as the authentication method (an alternative to plain text passwords, etc.). The GSSAPI plug-in for SASL is then invoked on the client and server side to use Kerberos to communicate.
Using GSSAPI protected communication for LDAP is an advanced configuration not supported by the Authentication Configuration tool; the following steps show how to manually configure it.

Setting up the SASL/GSSAPI authentication on Fedora 6.0

The following setup works correctly on all Fedora 6.1 systems and any systems released after it. However, when using Fedora 6.0, you must correctly configure the default_realm option in the [libdefaults] section and kdc option for your realm in the [realms] section in the /etc/krb5.conf configuration file not only on the directory server and the KDC but also on the client running SSSD. For more information on various /etc/krb5.conf options, refer to man krb5.conf
On the KDC
  1. Using kadmin, set up a Kerberos service principal for the directory server. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key:
    kadmin: addprinc -randkey ldap/server.example.com
  2. Use the ktadd command to write the service principal to a file:
    kadmin: ktadd -k /root/ldap.keytab ldap/server.example.com
  3. Using kadmin, set up a Kerberos host principal for the client running SSSD. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key:
    kadmin: addprinc -randkey host/client.example.com
  4. Use the ktadd command to write the host principal to a file:
    kadmin: ktadd -k /root/client.keytab host/client.example.com
On the Directory Server
Complete the following steps for a directory server of your choice:
OpenLDAP
  1. Copy the previously created /root/ldap.keytab file from the KDC to the /etc/openldap/ directory and name it ldap.keytab.
  2. Make the /etc/openldap/ldap.keytab file read-writable for the ldap user and readable for the ldap group only.
Red Hat Directory Server
  1. Copy the previously created /root/ldap.keytab file from the KDC to the /etc/dirsrv/ directory and name it ldap.keytab.
  2. Uncomment the KRB5_KTNAME line in the /etc/sysconfig/dirsrv (or instance-specific) file, and set the keytab location for the KRB5_KTNAME variable. For example:
    # In order to use SASL/GSSAPI the directory
    # server needs to know where to find its keytab
    # file - uncomment the following line and set
    # the path and filename appropriately
    KRB5_KTNAME=/etc/dirsrv/ldap.keytab; export KRB5_KTNAME
On the Client
  1. Copy the previously created /root/client.keytab file from the KDC to the /etc/ directory and name it krb5.keytab. If the /etc/krb5.keytab file exists already, use the ktutil utility to merge both files properly. For more information on the ktutil utility, refer to man ktutil.
  2. Modify your /etc/sssd/sssd.conf file to include the following settings:
    ldap_sasl_mech = gssapi
    ldap_sasl_authid = host/client.example.com@EXAMPLE.COM
    ldap_krb5_keytab = /etc/krb5.keytab (default)
    ldap_krb5_init_creds = true (default)
    ldap_krb5_ticket_lifetime = 86400 (default)
    krb5_realm = EXAMPLE.COM
    

8.2.7. Configuring a Proxy Domain

SSSD currently only supports LDAP and Kerberos as authentication providers. If you prefer to use SSSD (for example, to take advantage of its caching functionality), but SSSD does not support your authentication method, you can set up a proxy authentication provider. This could be the case if you use fingerprint scanners or smart cards as part of your authentication process. Similarly, you can set up proxy to serve as an identity provider.
The following sections cover combinations of identity and authentication providers in which the proxy server takes the role of one.

8.2.7.1. proxy/KRB5

The following configuration is an example of a combination of a proxy identity provider used with Kerberos authentication:
Edit the /etc/sssd/sssd.conf configuration file to include the following settings:
[domain/PROXY_KRB5]
auth_provider = krb5
krb5_server = 192.168.1.1
krb5_realm = EXAMPLE.COM

id_provider = proxy
proxy_lib_name = nis
enumerate = true
cache_credentials = true
For more information on various Kerberos configuration options, refer to 「Setting Up Kerberos Authentication」.

8.2.7.2. LDAP/proxy

An example of a combination of an LDAP identity provider and a proxy authentication provider is the use of the LDAP with a custom PAM stack. To enable authentication via the PAM stack, complete the following steps:
  1. Edit the /etc/sssd/sssd.conf configuration file to include the following settings:
    [domain/LDAP_PROXY]
    id_provider = ldap
    ldap_uri = ldap://example.com
    ldap_search_base = dc=example,dc=com
    
    auth_provider = proxy
    proxy_pam_target = sssdpamproxy
    enumerate = true
    cache_credentials = true
    
    By specifying the options above, authentication requests will be proxied via the /etc/pam.d/sssdpamproxy file which provides the needed module interfaces. Note that the pam_ldap.so file can be substituted with a PAM module of your choice.
    For more information on various LDAP configuration options, refer to 「Configuring an LDAP Domain」.
  2. Create a /etc/pam.d/sssdpamproxy file (if not already created) and specify the following settings in it:
    auth          required      pam_ldap.so
    account       required      pam_ldap.so
    password      required      pam_ldap.so
    session       required      pam_ldap.so

8.2.7.3. proxy/proxy

An example of a combination of an proxy identity provider and a proxy authentication provider is the use of the proxy identity provider with a custom PAM stack. To enable authentication via the PAM stack, complete the following steps:

Make sure the nss-pam-ldapd package is installed

In order to use the proxy identity provider, you must have the nss-pam-ldapd package installed.
  1. Edit the /etc/sssd/sssd.conf configuration file to include the following settings:
    [domain/PROXY_PROXY]
    auth_provider = proxy
    id_provider = proxy
    proxy_lib_name = ldap
    proxy_pam_target = sssdproxyldap
    enumerate = true 
    cache_credentials = true
    
    By specifying the options above, authentication requests will be proxied via the /etc/pam.d/sssdproxyldap file which provides the needed module interfaces.
    For more information on the options used in the configuration example above, refer to man sssd.conf
  2. Create a /etc/pam.d/sssdproxyldap file (if not already created) and specify the following settings in it:
    auth          required      pam_ldap.so
    account       required      pam_ldap.so
    password      required      pam_ldap.so
    session       required      pam_ldap.so
  3. Edit the /etc/nslcd.conf file (the default configuration file for the LDAP name service daemon) to include the following settings:
    uid nslcd
    gid ldap
    uri ldaps://ldap.mydomain.org:636
    base dc=mydomain,dc=org
    ssl on
    tls_cacertdir /etc/openldap/cacerts
    For more information on the options used in the configuration example above, refer to man nslcd.conf

8.2.8. Troubleshooting

This section lists some of the issues you may encounter when implementing SSSD, the possible causes of these issues, and how to resolve them. If you find further issues that are not covered here, refer to the We Need Feedback section in the Preface for information on how to file a bug report.

8.2.8.1. Using SSSD Log Files

SSSD uses a number of log files to report information about its operation, and this information can help to resolve issues in the event of SSSD failure or unexpected behavior. The default location for these log files on Fedora—based systems is the /var/log/sssd/ directory.
SSSD produces a log file for each back end (that is, one log file for each domain specified in the /etc/sssd/sssd.conf file), as well as an sssd_pam.log and an sssd_nss.log file. This level of granularity can help you to quickly isolate and resolve any errors or issues you might experience with SSSD.
You should also examine the /var/log/secure file, which logs authentication failures and the reason for the failure. For example, if you see Reason 4: System Error reported against any failure, you should increase the debug level of the log files.
Producing More Verbose Log Files
If you are unable to identify and resolve any problems with SSSD after inspection of the default log files, you can configure SSSD to produce more verbose files. You can set the debug_level option in the /etc/sssd/sssd.conf for the domain that is causing concern, and then restart SSSD. Refer to the sssd.conf(5) manual page for more information on how to set the debug_level for a specific domain.
All log files include timestamps on debug messages by default. This can make it easier to understand any errors that may occur, why they occurred, and how to address them. If necessary, you can disable these timestamps by setting the appropriate parameter to FALSE in the /etc/sssd/sssd.conf file:
--debug-timestamps=FALSE

8.2.8.2. Problems with SSSD Configuration

  • SSSD fails to start
    • SSSD requires at least one properly configured domain before the service will start. Without such a domain, you might see the following error message when trying to start SSSD with the following command:
      # sssd -d4
      [sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
      
      [sssd] [confdb_get_domains] (0): No domains configured, fatal error!
      [sssd] [get_monitor_config] (0): No domains configured.
      
      You can ignore the "Unable to register control with rootdse!" message, as it is erroneous. The other messages, however, indicate that SSSD is unable to locate any properly configured domains.
      Edit your /etc/sssd/sssd.conf file and ensure you have at least one properly configured domain, and then try to start SSSD.
    • SSSD requires at least one available service provider before it will start. With no available service providers, you might see the following error message when trying to start SSSD with the following command:
      # sssd -d4
      [sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
      
      [sssd] [get_monitor_config] (0): No services configured!
      
      You can ignore the "Unable to register control with rootdse!" message, as it is erroneous. The other message, however, indicates that SSSD is unable to locate any available service providers.
      Edit your /etc/sssd/sssd.conf file and ensure you have at least one available service providers, and then try to start SSSD.

      Configuring the service providers

      SSSD requires that service providers be configured as a comma-separated list in a single services entry in the /etc/sssd/sssd.conf file. If services are listed in multiple entries, only the last entry is recognized by SSSD.
    • Refer to the sssd.conf(5) manual page for more options that might assist in troubleshooting issues with SSSD.

8.2.8.3. Problems with SSSD Service Configuration

8.2.8.3.1. Problems with NSS
This section describes some common problems with NSS, their symptoms, and how to resolve them.
  • NSS fails to return user information
    • Ensure that NSS is running
      # systemctl is-active sssd.service
      This command should return results similar to the following:
      sssd (pid 21762) is running...
      
    • Ensure that you have correctly configured the [nss] section of the /etc/sssd/sssd.conf file. For example, ensure that you have not misconfigured the filter_users or filter_groups attributes. Refer to the NSS configuration options section of the sssd.conf(5) manual page for information on how to configure these attributes.
    • Ensure that you have included nss in the list of services that sssd should start
    • Ensure that you have correctly configured the /etc/nsswitch.conf file. Refer to the section 「Configuring NSS」 for information on how to correctly configure this file.
8.2.8.3.2. Problems with PAM
This section describes some common problems with PAM, their symptoms, and how to resolve them.
  • Setting the password for the local SSSD user prompts twice for the password
    When attempting to change a local SSSD user's password, you might see output similar to the following:
    [root@clientF11 tmp]# passwd user1000
    Changing password for user user1000.
    New password:
    Retype new password:
    New Password:
    Reenter new Password:
    passwd: all authentication tokens updated successfully.
    
    This is the result of an incorrect PAM configuration. Refer to 「Configuring PAM」, and ensure that the use_authtok option is correctly configured in your /etc/pam.d/system-auth file.
8.2.8.3.3. Problems with NFS and NSCD
SSSD is not designed to be used with the nscd daemon, and will likely generate warnings in the SSSD log files. Even though SSSD does not directly conflict with nscd, the use of both at the same time can result in unexpected behavior (specifically with how long entries are being cached).
If you are using Network Manager to manage your network connections, it may take several minutes for the network interface to come up. During this time, various services will attempt to start. If these services start before the network is up (that is, the DNS servers cannot yet be reached) they will fail to identify the forward or reverse DNS entries they might need. These services will be reading an incorrect or possibly empty resolv.conf file. This file is typically only read once, and so any changes made to this file are not automatically applied.
This can result in the failure of some system services, and in particular can cause NFS locking to fail on the machine where the nscd service is running, unless that service is manually restarted.
One method of working around this problem is to enable caching for hosts and services in the /etc/nscd.conf file, and to rely on the SSSD cache for the passwd and group entries. With nscd answering hosts and services requests, these entries would have been cached and returned by nscd during the boot process.

NSCD and later versions of SSSD

Later versions of SSSD should negate any need for NSCD.

8.2.8.4. Problems with SSSD Domain Configuration

  • NSS returns incorrect user information
    • If your search for user information returns incorrect data, ensure that you do not have conflicting usernames in separate domains. If you use multiple domains, it is recommended that you set the use_fully_qualified_domains attribute to TRUE in the /etc/sssd/sssd.conf file.

8.2.8.5. その他のリソース

8.2.8.5.1. Manual Pages
SSSD ships with a number of manual pages, all of which provide additional information about specific aspects of SSSD, such as configuration files, commands, and available options. SSSD currently provides the following manual pages:
  • sssd.conf(5)
  • sssd-ipa(5)
  • sssd-krb5(5)
  • sssd-ldap(5)
  • sssd(8)
  • sssd_krb5_locator_plugin(8)
  • pam_sss(8)
You should refer to these manual pages for detailed information about all aspects of SSSD, its configuration, and associated tools and commands.
8.2.8.5.2. Mailing Lists
You can subscribe to the SSSD mailing list to follow and become involved in the development of SSSD, or to ask questions about any issues you may be experiencing with your SSSD deployment.
Visit https://fedorahosted.org/mailman/listinfo/sssd-devel to subscribe to this mailing list.

8.2.9. SSSD Configuration File Format

The following listing describes the current version (Version 2) of the SSSD configuration file format.
[sssd]
config_file_version = 2
services = nss, pam
domains = mybox.example.com, ldap.example.com, ipa.example.com, nis.example.com
# sbus_timeout = 300

[nss]
nss_filter_groups = root
nss_filter_users = root
nss_entry_cache_timeout = 30
nss_enum_cache_timeout = 30

[domain/mybox.example.com]
domain_type = local
enumerate = true
min_id = 1000
# max_id = 2000

local_default_shell = /bin/bash
local_default_homedir = /home

# Possible overrides
# id_provider = local
# auth_provider = local
# authz_provider = local
# passwd_provider = local

[domain/ldap.example.com]
domain_type = ldap
server = ldap.example.com, ldap3.example.com, 10.0.0.2
# ldap_uri = ldaps://ldap.example.com:9093
# ldap_use_tls = ssl
ldap_search_base = dc=ldap,dc=example,dc=com
enumerate = false

# Possible overrides
# id_provider = ldap
# id_server = ldap2.example.com
# auth_provider = krb5
# auth_server = krb5.example.com
# krb5_realm = KRB5.EXAMPLE.COM

[domain/ipa.example.com]
domain_type = ipa
server = ipa.example.com, ipa2.example.com
enumerate = false

# Possible overrides
# id_provider = ldap
# id_server = ldap2.example.com
# auth_provider = krb5
# auth_server = krb5.example.com
# krb5_realm = KRB5.EXAMPLE.COM

[domain/nis.example.com]
id_provider = proxy
proxy_lib = nis
auth_provider = proxy
proxy_auth_target = nis_pam_proxy

第9章 OpenSSH

SSH (Secure Shell) は、クライアント/サーバー型アーキテクチャーを用いて2つのシステム間でセキュアなコミュニケーションを促進して、ユーザーがサーバー・ホスト・システムにリモートでログインできるようにするプロトコルです。FTPTelnet のような他のリモート・コミュニケーション・プロトコルと違い、SSH はログインセッションを暗号化します。侵入者が暗号化されていないパスワードを収集するのを難しくするコミュニケーションを行います。
ssh プログラムは、telnetrsh のようなリモートホストにログインするために使用される比較的古くて比較的セキュアではないターミナル・アプリケーションを置き換えるよう設計されています。scp という関連コマンドは、rcp のようにホスト間でファイルをコピーするために設計されました。これらの比較的古いアプリケーションは、クライアントとサーバーの間で転送されるパスワードを暗号化しないので、可能な限り避けるべきです。リモートシステムにログインするために安全な方法を使用することで、クライアントシステムとリモートシステムの両方に対するリスクを減らします。
Fedora は一般的な OpenSSH パッケージ (openssh) だけでなく、OpenSSH サーバー (openssh-server) およびクライアント (openssh-clients) パッケージを含みます。OpenSSH パッケージは OpenSSL パッケージ (openssl) を必要なことに注意してください。これは OpenSSH に暗号化されたコミュニケーションを提供できるようにする、いくつかの重要な暗号ライブラリをインストールします。

9.1. SSH プロトコル

9.1.1. なぜ SSH を使うのか?

潜在的な侵入者は、システムへのアクセス権を得ようとして、ネットワークトラフィックを中断、横取り、再転送を可能にするため、自分たちの自由でさまざまなツールを持っています。一般的な言葉で、これらの脅威は以下のように分類できます:
二つのシステム間のコミュニケーションの盗聴
攻撃者は、ネットワークにおいてやりとりされる情報をすべてコピーして、コミュニケーションしている関係者の間のどこかにいることができます。
この攻撃は通常パケットスニファーを用いて実行されます。これは、ネットワークを流れる各パケットをキャプチャーして、その内容を分析する、一般的なネットワークユーティリティです。
特定のホストの詐称
攻撃者のシステムは、転送の意図した受信者のふりをするよう設定されます。この戦略がうまくいくと、ユーザーのシステムは誤ったホストとコミュニケーションしていることに気がつかないままです。
この攻撃は DNS ポイズニング と呼ばれる技術を用いて、もしくはいわゆるIP スプーフィングを経由して実行されます。前者の場合、侵入者はクライアントシステムが悪意を持って複製させたホストに向くようにクラックした DNS サーバーを使用します。後者の場合、攻撃者は信頼されたホストからであるように見える、偽造したネットワークパケットを送ります。
どちらの技術も潜在的に機密情報を傍受します。そして、もし傍受が敵対的な理由でなされるならば、壊滅的な結果になる可能性があります。SSH がリモートシェルのログインやファイルコピーのために使用されていると、これらのセキュリティの脅威を非常に減らすことができます。なぜなら、SSH クライアントとサーバーがアイデンティティを検証するために電子署名を使用するからです。加えて、クライアントとサーバーシステムの間のコミュニケーションはすべて暗号化されます。コミュニケーションのどちらのサイドもアイデンティティを偽装しても、各パケットはローカルシステムとリモートシステムのみが知っているキーを使用して暗号化されているので、うまくいきません。

9.1.2. 主な機能

SSH プロトコルは以下の安全機能を提供します:
誰も意図したサーバーのふりをできません
初期接続の後、クライアントは以前に接続していたのと同じサーバーに接続していることを確認できます。
誰も認証情報をキャプチャーできません
クライアントは、堅牢な 128-bit 暗号化を使用してサーバーへ認証情報を送信します。
誰もコミュニケーションを盗聴できません
セッション中に送信、および受信されたすべてのデータは 128-bit 暗号を使用して送信されるため、盗聴した転送データを復号および読み取ることは非常に困難になります。
加えて、以下のオプションも提供されます:
ネットワーク上でグラフィカルアプリケーションを使用する安全な手段が提供されます
X11 転送という技術を使用することで、クライアントはサーバーから X11 (X Window System) アプリケーションを転送できます。
セキュアではないプロトコルを別な方法でセキュアにする手段を提供します
SSH プロトコルは送受信されるすべてのものを暗号化します。ポート転送という技術を使用すると、SSH サーバーは、POP のようなセキュアではないプロトコルを別な方法でセキュアにして、全体のシステムとデータのセキュリティを向上させる、トンネルになります。
セキュアなチャネルを作成するために使用できます
OpenSSH のサーバーとクライアントは、それらのマシンの間でトラフィックに対して VPN のようなトンネルを作成するよう設定できます。
Kerberos 認証をサポートします
OpenSSH のサーバーおよびクライアントは、Kerberos ネットワーク認証プロトコルの GSSAPI (Generic Security Services Application Program Interface) 実装を用いて認証するよう設定できます。

9.1.3. プロトコル・バージョン

現在 SSH には2種類あります。バージョン1と新しいバージョン2です。Fedora の OpenSSH は SSH バージョン2を使用します。これは、バージョン1において知られていたエクスプロイトに脆弱性がない、改善された鍵交換アルゴリズムを持ちます。しかしながら、互換性のため、OpenSSH はバージョン1の接続も同様にサポートします。

SSH バージョン 1 の使用を避ける

接続に対する最大限のセキュリティを確実にするには、SSH バージョン2対応のサーバーとクライアントのみが可能な限り使用することが推奨されます。

9.1.4. SSH コネクションのイベント・シーケンス

以下の連続したイベントは、2つのホスト間の SSH 通信の統合性を保護するのに役に立ちます。
  1. 暗号方式ハンドシェークが行なわれ、クライアントは正しいサーバーと交信していることを確認します。
  2. クライアントとリモートホスト間接続のトランスポートレイヤーは対象型暗号を使用して暗号化されます。
  3. クライアントはサーバーに対して自身を認証します。
  4. リモートクライアントは、暗号化した接続を通じてリモートホストと交信します。

9.1.4.1. トランスポート層

トランスポートレイヤーの主な役割は認証時とその後の通信期間での2つのホスト間に於ける安全な交信を用意することです。トランスポートレイヤーは、データの暗号化と複合化すること、そして、データが送信と受信される時にデータパケットの統合性を保護することで、この役割を達成します。トランスポートレイヤーはまた、情報を圧縮して送信の高速化もします。
SSH クライアントがサーバーに接続すると、基本情報が交換されて両システムは正しくトランスポートレイヤーを構築することができるようになります。この交換の間に以下のようなステップが起こります:
  • 鍵が交換されます
  • 公開鍵暗号化アルゴリズムが決定されます
  • 対象型暗号化アルゴリズムが決定されます
  • メッセージ認証アルゴリズムが決定されます
  • ハッシュアルゴリズムが決定されます
鍵交換の間、サーバーはそれ自身を独自の ホスト鍵 で、クライアントに対して証明します。クライアントがこの特定のサーバーと過去に通信したことがなければ、サーバーのホスト鍵はクライアントには未知であり、接続は成立しません。 OpenSSH は、サーバーのホスト鍵を承認することでこの問題を回避します。これは、ユーザーが通知を受けて新規のホスト鍵を承認し確証した後に起こります。それ以降の接続では、サーバーのホスト鍵は、クライアント上に保存してある情報と照らし合わせてチェックされ、クライアントが本当に目的のサーバーと通信していることの確証を与えます。時間が経過して、このホスト鍵が一致しない状態が起こると、ユーザーがクライアントに保存してある古い情報を削除することにより、新しい接続が可能になります。

常に新しい SSH サーバーの完全性を検証する

ローカルシステムは本来のサーバーと攻撃者が設定した偽のサーバーとの違いを理解しない為、攻撃者は初期交信の時点で SSH サーバーとして擬装することが可能になります。この防止への手助けとして、最初の接続の前に、又はホスト鍵の不一致が発生した場合にサーバー管理者へ連絡することで、新規の SSH サーバーの統合性を確認すると良いでしょう。
SSH はほとんど全ての公開鍵アルゴリズム、又はエンコード形式で機能するように設計されています。初期の鍵交換が、秘密値の交換と共有に使用されるハッシュ値を作成した後、2つのシステムは迅速に新しい鍵とアルゴリズムを算出してこの接続で送信される認証と将来のデータを保護します。
設定された鍵とアルゴリズムを使用して一定量のデータが送信された後 (この量は SSH の実装によりことなります)、別の鍵交換が発生してもう1つのハッシュ値セットと新しい共有秘密値が生成されます。攻撃者がハッシュ値と共有秘密値を判別できたとしても、その情報はほんの短い時間しか役に立ちません。

9.1.4.2. 認証

トランスポートレイヤーが安全なトンネルを構築して2つのシステム間で情報が渡されると、サーバーはクライアントに対して、秘密鍵のエンコードを持つ署名やパスワード入力の使用などサポートされている別の認証方法を伝えます。クライアントはその後、これらのサポートのある方法でサーバーに対して自身の認証を試みます。
SSH サーバーとクライアントは異なるタイプの認証方法を許可できるように設定されており、これが両側に高水準の制御を与えます。サーバーはそのセキュリティモデルに応じて、サポートする暗号化方法を決定することができ、クライアントは利用できるオプションの中から認証方法の順番を選択することができます。

9.1.4.3. チャネル

SSH 転送層において認証が成功した後、複数のチャネルが多重化[2]という技術により開かれます。これらのチャネルはそれぞれ異なるターミナルセッションとX11転送セッションのコミュニケーションを取り扱います。
クライアントとサーバーの両方は新規のチャンネルを作成することができます。各チャンネルはその後、接続の両端で別々の番号が割り当てられます。クライアントが新規のチャンネルを開こうと試みる時、クライアントは要求と一緒にチャンネル番号を送信します。この情報はサーバーで保存され、そのチャンネルに通信を転送するのに使用されます。これは、異なるタイプのセッションがお互いに干渉しないようにするため、及び、あるセッションが終了した時にそのチャンネルが主要 SSH 接続を妨害せずに閉じることができるようにするためです。
チャンネルは、 flow-control もサポートしており、これはチャンネルが順序良くデータを送信/受信するのを可能にします。この方法では、クライアントがチャンネルが開いていると言うメッセージを受信するまで、データはチャンネルに送信されません。
クライアントが要求するサービスのタイプとユーザーがネットワークに接続されている方法に従って、クライアントとサーバーは、自動的に各チャンネルの構成を折衝します。これにより、プロトコルの基本構成を変更することなく、異なるタイプのリモート接続の処理に多大な柔軟性を得ることができます。

9.2. OpenSSH の設定

このセクションに記載されている作業を実行するためには、スーパーユーザー権限を持たなければいけません。権限を得るには、次を入力することにより root としてログインします:
su -

9.2.1. 設定ファイル

2種類の設定ファイルがあります: クライアント・プログラム用のもの (つまり、sshscp および sftp)、およびサーバー用のもの (sshd デーモン)。
システム全体の SSH 設定ファイルは /etc/ssh/ ディレクトリに保存されてます。詳細は表9.1「システム全体の設定ファイル」を参照してください。
表9.1 システム全体の設定ファイル
設定ファイル 説明
/etc/ssh/moduli セキュアな転送層を構築するために重要となる Diffie-Hellman キー交換のために使用される Diffie-Hellman グループを含みます。キーが SSH セッションの最初に交換されるとき、共有された秘密の値が作成されます。これはどちらか一方により決めることができません。この値はホスト認証を提供するために使用されます。
/etc/ssh/ssh_config デフォルトの SSH クライアント設定ファイルです。~/.ssh/config が存在すると、それにより上書きされることに注意してください。
/etc/ssh/sshd_config sshd デーモンの設定ファイルです。
/etc/ssh/ssh_host_dsa_key sshd デーモンにより使用される DSA 秘密鍵です。
/etc/ssh/ssh_host_dsa_key.pub sshd デーモンにより使用される DSA 公開鍵です。
/etc/ssh/ssh_host_key SSH プロトコルのバージョン1用の sshd デーモンにより使用される RSA 秘密鍵です。
/etc/ssh/ssh_host_key.pub SSH プロトコルのバージョン1用の sshd デーモンにより使用される RSA 公開鍵です。
/etc/ssh/ssh_host_rsa_key SSH プロトコルのバージョン2用の sshd デーモンにより使用される RSA 秘密鍵です。
/etc/ssh/ssh_host_rsa_key.pub SSH プロトコルのバージョン2用の sshd デーモンにより使用される RSA 公開鍵です。

ユーザー固有の SSH 設定ファイルは、ユーザーのホームディレクトリにある ~/.ssh/ ディレクトリに保存されます。詳細は表9.2「ユーザー固有の設定ファイル」を参照してください。
表9.2 ユーザー固有の設定ファイル
設定ファイル 説明
~/.ssh/authorized_keys サーバーに対して認可された公開鍵の一覧を保持します。クライアントがサーバーに接続されるとき、このファイルに保存されている署名済み公開鍵を確認することにより、サーバーがクライアントを認証します。
~/.ssh/id_dsa ユーザーの DSA 秘密鍵を含みます。
~/.ssh/id_dsa.pub ユーザーの DSA 公開鍵です。
~/.ssh/id_rsa SSH プロトコルのバージョン2用の ssh により使用される RSA 秘密鍵です。
~/.ssh/id_rsa.pub SSH プロトコルのバージョン2用の ssh により使用される RSA 鍵です。
~/.ssh/identity SSH プロトコルのバージョン1用の ssh により使用される RSA 秘密鍵です。
~/.ssh/identity.pub SSH プロトコルのバージョン1用の ssh により使用される RSA 公開鍵です。
~/.ssh/known_hosts ユーザーによりアクセスされた SSH サーバーの DSA ホスト・キーを含みます。このファイルは SSH クライアントが正しい SSH サーバーに接続していることを確実にするために非常に重要です。

SSH の設定ファイルにおいて利用可能なさまざまなディレクティブに関する詳細は、ssh_config および sshd_config のマニュアルページを参照してください。

9.2.2. OpenSSH サーバーの起動

関連パッケージがインストールされていることを確実にします。

OpenSSH サーバーを実行するには、openssh-server および openssh パッケージがインストールされていなければいけません。Fedora において新しいパッケージをインストールする方法の詳細は「パッケージのインストール」を参照してください。
sshd デーモンを起動するには、シェルプロンプトにおいて以下のとおり入力します。
systemctl start sshd.service
実行中の sshd デーモンを停止するには、以下のコマンドを使用します:
systemctl stop sshd.service
ブート時にデーモンが自動的に起動するようにしたいならば、以下を入力します:
systemctl enable sshd.service
Fedora において、サービスを設定する方法の詳細は7章サービスおよびデーモンを参照してください。
システムを再インストールすると、新しい識別キーのセットが作成されることに注意してください。結果として、再インストールする前に何らかの OpenSSH ツールを用いてシステムに接続したことのあるおクライアントは、以下のようなメッセージが表示されます:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: 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/ ディレクトリから関連するファイルをバックアップできます (完全な一覧は 表9.1「システム全体の設定ファイル」 を参照してください)、そうするとシステムを再インストールしたときはそれらをリストアできます。

9.2.3. リモート接続に対する SSH の要求

SSH を本当に効果的にするために、セキュアではない接続プロトコルを使用することは禁止されるべきです。そうでなければ、Telnet を使用してログインする間に後から取り込むためにのみ、ユーザーのパスワードはあるセッションに対して SSH を使用することを保護するかもしれません。無効にされるサービスのいくつかは telnet, rsh, rlogin, および vsftpd です。
これらのサービスが実行していないことを確実にするには、シェルプロンプトにおいて以下のコマンドを入力します:
systemctl stop telnet.service
systemctl stop rsh.service
systemctl stop rlogin.service
systemctl stop vsftpd.service
システム起動時にこれらのサービスを無効にするには、以下を入力します:
systemctl disable telnet.service
systemctl disable rsh.service
systemctl disable rlogin.service
systemctl disable vsftpd.service
Fedora において、サービスを設定する方法の詳細は7章サービスおよびデーモンを参照してください。

9.2.4. キー認証の使用

システムのセキュリティをさらに向上させるために、標準的なパスワード認証を無効にすることにより、キーによる認証を強制できます。そうするために、テキストエディターで /etc/ssh/sshd_config ファイルを開いて、PasswordAuthentication オプションを以下のように変更します:
PasswordAuthentication no
サーバーにクライアントから接続するために ssh, scp, や sftp を使用できるようにするには、以下の手順に従って認可キーペアを生成します。キーは各ユーザーがそれぞれ生成しなければいけないことに注意してください。
Fedora 16 はデフォルトで SSH プロトコル 2 および RSA キーを使用します(詳細は 「プロトコル・バージョン」 を参照してください)。

キーペアを root として生成しない

手順を root として完了したならば、root のみがキーを使えるようにします。

~/.ssh/ ディレクトリのバックアップ

システムを再インストールして、前に生成したキーペアを維持したいならば、~/.ssh/ ディレクトリをバックアップします。再インストール後、それをホームディレクトリにコピーして戻します。このプロセスは root を含めてシステムにあるすべてのユーザーに対して行うことができます。

9.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/john/.ssh/id_rsa):
  2. 新しく作成するキーに対するデフォルトの位置(つまり、~/.ssh/id_rsa)を確認するために Enter を押します。
  3. パスフレーズを入力して、プロンプトが出たとき再び入力することにより確認します。セキュリティの理由により、アカウントにログインするために使用するパスワードと同じものを使用することは避けます。
    この後、これと同じようなメッセージが表示されます:
    Your identification has been saved in /home/john/.ssh/id_rsa.
    Your public key has been saved in /home/john/.ssh/id_rsa.pub.
    The key fingerprint is:
    e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 john@penguin.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |             E.  |
    |            . .  |
    |             o . |
    |              . .|
    |        S .    . |
    |         + o o ..|
    |          * * +oo|
    |           O +..=|
    |           o*  o.|
    +-----------------+
  4. ~/.ssh/ ディレクトリのパーミッションを変更します:
    ~]$ chmod 755 ~/.ssh
  5. ~/.ssh/id_rsa.pub の内容を接続したいサーバーの ~/.ssh/authorized_keys の中にコピーします。もしファイルがすでに存在すれば、その最後に追加します。
  6. 以下のコマンドを用いて ~/.ssh/authorized_keys ファイルのパーミッションを変更します:
    ~]$ chmod 644 ~/.ssh/authorized_keys
SSH プロトコルバージョン 2 用の DSA キーペアを生成するには、これらの手順に従います:
  1. シェルプロンプトにおいて以下のとおり入力することにより DSA キーペアを生成します:
    ~]$ ssh-keygen -t dsa
    Generating public/private dsa key pair.
    Enter file in which to save the key (/home/john/.ssh/id_dsa):
  2. 新しく作成するキーに対するデフォルトの位置(つまり、~/.ssh/id_dsa)を確認するために Enter を押します。
  3. パスフレーズを入力して、プロンプトが出たとき再び入力することにより確認します。セキュリティの理由により、アカウントにログインするために使用するパスワードと同じものを使用することは避けます。
    この後、これと同じようなメッセージが表示されます:
    Your identification has been saved in /home/john/.ssh/id_dsa.
    Your public key has been saved in /home/john/.ssh/id_dsa.pub.
    The key fingerprint is:
    81:a1:91:a8:9f:e8:c5:66:0d:54:f5:90:cc:bc:cc:27 john@penguin.example.com
    The key's randomart image is:
    +--[ DSA 1024]----+
    |   .oo*o.        |
    |  ...o Bo        |
    | .. . + o.       |
    |.  .   E o       |
    | o..o   S        |
    |. o= .           |
    |. +              |
    | .               |
    |                 |
    +-----------------+
  4. ~/.ssh/ ディレクトリのパーミッションを変更します:
    ~]$ chmod 775 ~/.ssh
  5. ~/.ssh/id_dsa.pub の内容を接続したいサーバーの ~/.ssh/authorized_keys の中にコピーします。もしファイルがすでに存在すれば、その最後に追加します。
  6. 以下のコマンドを用いて ~/.ssh/authorized_keys ファイルのパーミッションを変更します:
    ~]$ chmod 644 ~/.ssh/authorized_keys
SSH プロトコルバージョン 1 用の R\nSA キーペアを生成するには、これらの手順に従います:
  1. シェルプロンプトにおいて以下のとおり入力することにより RSA キーペアを生成します:
    ~]$ ssh-keygen -t rsa1
    Generating public/private rsa1 key pair.
    Enter file in which to save the key (/home/john/.ssh/identity):
  2. 新しく作成するキーに対するデフォルトの位置(つまり、~/.ssh/identity)を確認するために Enter を押します。
  3. パスフレーズを入力して、そうするようプロンプトが表示されたとき、入力することによりそれを確認します。セキュリティの理由のため、あたなのアカウントにログインするために使用するものと同じパスワードを使用することは避けてください。
    この後、これと同じようなメッセージが表示されます:
    Your identification has been saved in /home/john/.ssh/identity.
    Your public key has been saved in /home/john/.ssh/identity.pub.
    The key fingerprint is:
    cb:f6:d5:cb:6e:5f:2b:28:ac:17:0c:e4:62:e4:6f:59 john@penguin.example.com
    The key's randomart image is:
    +--[RSA1 2048]----+
    |                 |
    |     . .         |
    |    o o          |
    |     + o E       |
    |    . o S        |
    |       = +   .   |
    |      . = . o . .|
    |       . = o o..o|
    |       .o o  o=o.|
    +-----------------+
  4. ~/.ssh/ ディレクトリのパーミッションを変更します:
    ~]$ chmod 755 ~/.ssh
  5. ~/.ssh/identity.pub の内容を接続したいサーバーの ~/.ssh/authorized_keys の中にコピーします。もしファイルがすでに存在すれば、その最後に追加します。
  6. 以下のコマンドを用いて ~/.ssh/authorized_keys ファイルのパーミッションを変更します:
    ~]$ chmod 644 ~/.ssh/authorized_keys
システムにパスフレーズを記憶させる方法については「ssh-agent の設定」を参照してください。

決して秘密鍵を共有しない

秘密鍵は個人利用のためのみにしてください。そして、それを誰にも渡さないことが重要です。

9.2.4.2. ssh-agent の設定

リモートマシンと接続を初期化するたびにパスフレーズを入力しなくてすむようにパスフレーズを保存するには、ssh-agent 認証エージェントを使用できます。特定のシェルプロンプトのためにパスフレーズを保存するには、以下のコマンドを使用します:
~]$ ssh-add
Enter passphrase for /home/john/.ssh/id_rsa:
ログアウトするとき、パスフレーズが忘れられることに注意してください。仮想コンソールやターミナルウィンドウにログインするたびにコマンドを実行しなければいけません。

9.3. OpenSSH クライアント

関連パッケージがインストールされていることを確実にします。

クライアントマシンから OpenSSH サーバーに接続するには、openssh-clients および openssh パッケージをインストールしなければいけません。Fedora に新しいパッケージをインストールする方法は「パッケージのインストール」を参照してください。

9.3.1. ssh ユーティリティの使用方法

ssh はリモートマシンにログインしたり、そこでコマンドを実行したりできます。rlogin, rsh, および telnet プログラムのセキュアな代替品です。
telnet と同じように、penguin.example.com というリモートマシンにログインするには、シェルプロンプトにおいて以下のコマンドを入力します:
~]$ ssh penguin.example.com
これはローカルマシンにおいて使用しているものと同じユーザー名を用いてログインします。異なるものを指定したい場合、ssh username@hostname 形式でコマンドを使用します。たとえば、john としてログインするには、このように入力します:
~]$ ssh john@penguin.example.com
はじめて接続するとき、このようなメッセージが表示されます:
The authenticity of host 'penguin.example.com' can't be established.
RSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)?
確認するために yes と入力します。サーバーが既知のホストのリストに追加されることに注意してください。そして、パスワードを問い合わせるプロンプトが出ます:
Warning: Permanently added 'penguin.example.com' (RSA) to the list of known hosts.
john@penguin.example.com's password:

SSH サーバーのホストキーの更新方法

SSH サーバーのホストキーが変更されると、サーバーのホストキーが ~/.ssh/known_hosts ファイルから削除されるまで接続を進めることができないことを、クライアントがユーザーに通知します。そうするには、テキストエディターでファイルを開いて、先頭にリモートマシン名を含む行を削除します。しかし、これを実行する前に、サーバーが侵入されていないことを確認するために、SSH サーバーのシステム管理者に問い合わせてください。
パスワードを入力した後、リモートマシンのシェルプロンプトを提供されます。
代わりに、ssh プログラムがシェルプロンプトにログインすることなく、リモートマシンにおいてコマンドを実行するためにも使うことができます。そのための構文は ssh [username@]hostname command です。たとえば、penguin.example.comにおいて whoami コマンドを実行したいならば、次のように入力します:
~]$ ssh john@penguin.example.com whoami
john@penguin.example.com's password:
john
正しいパスワードが入力された後、ユーザー名が表示され、ローカルのシェルプロンプトに戻ってきます。

9.3.2. scp ユーティリティの使用方法

scp はセキュアな暗号化されたコネクションにおいてマシン間でファイルを転送するために使用できます。その設計は rcp と非常に似ています。
ローカルファイルをリモートシステムに転送するには、以下の形式のコマンドを使用します:
scp localfile username@hostname:remotefile
たとえば、taglist.vimpenguin.example.com という名前のリモートマシンに転送したいならば、シェルプロンプトにおいて以下のとおり入力します:
~]$ scp taglist.vim john@penguin.example.com:.vim/plugin/taglist.vim
john@penguin.example.com's password:
taglist.vim                                   100%  144KB 144.5KB/s   00:00
複数のファイルを一度に指定できます。.vim/plugin/ の内容をリモートマシン penguin.example.com の同じディレクトリに転送するには、以下のコマンドを入力します:
~]$ scp .vim/plugin/* john@penguin.example.com:.vim/plugin/
john@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 john@penguin.example.com:.vimrc .vimrc
john@penguin.example.com's password:
.vimrc                                        100% 2233     2.2KB/s   00:00

9.3.3. sftp ユーティリティの使用方法

sftp ユーティリティはセキュアな対話式の FTP セッションを開くために使うことができます。これはセキュアな暗号化されたコネクションを使用すること以外は ftp と似ています。
リモートシステムに接続するには、以下の形式でコマンドを使用します:
sftp username@hostname
たとえば、ユーザー名に john を用いて、penguin.example.com という名前のリモートマシンにログインするには、次のとおり入力します:
~]$ sftp john@penguin.example.com
john@penguin.example.com's password:
Connected to penguin.example.com.
sftp>
正しいパスワードを入力した後、プロンプトが表示されます。sftp ユーティリティは ftp により使用されるコマンドと似たようなもののセットが利用可能です(表9.3「利用可能な sftp コマンドの選定品」を参照してください)。
表9.3 利用可能な sftp コマンドの選定品
コマンド 説明
ls [directory] リモートの directory の内容を一覧表示します。何も指定されなければ、デフォルトで現在の作業ディレクトが使われます。
cd directory リモートの作業ディレクトリを directory に変更します。
mkdir directory リモートの directory を作成します。
rmdir path リモートの directory を削除します。
put localfile [remotefile] localfile をリモートマシンに転送します。
get remotefile [localfile] remotefile をリモートマシンから転送します。

利用可能なコマンドの完全な一覧は sftp のマニュアルページを参照してください。

9.4. 安全なシェル以上のもの

安全なコマンドラインインターフェイスは、 SSH が使用できる多くの方法の単なる一部分です。充分なバンド幅があれば、 X11 セッションは 1 つの SSH チャンネル上で方向指定できます。又は、 TCP/IP 転送を使用することで、以前にシステム間で不安全であったポート接続は、特定の SSH チャンネルにマップすることができます。

9.4.1. X11 転送

SSH コネクション上に X11 セッションを開くには、以下の形式でコマンドを使用します:
ssh -Y username@hostname
たとえば、ユーザー名に john を用いて、penguin.example.com という名前のリモートマシンにログインするには、次のとおり入力します:
~]$ ssh -Y john@penguin.example.com
john@penguin.example.com's password:
安全なシェルプロンプトから X プログラムが実行されると、 SSH クライアントとサーバーは新しい安全なチャンネルを作成し、 X プログラムデータはそのチャンネルを通じて透過的にクライアントマシンに送信されます。
X11 転送は非常に有用です。プリンター設定ユーティリティのセキュアな対話式セッションを作成するために使用できます。これをするために、ssh を使用してサーバーに接続して、次のとおり入力します:
~]$ system-config-printer &
プリンター設定ツールが表示され、リモートユーザーがリモートシステムにある印刷環境を安全に設定できるようになります。

9.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 サーバーに送られます。
mail.example.com が SSH サーバーを実行していなくても、同じネットワークにある他のサーバーが実行しているならば、SSH はコネクションの一部をセキュアにするために使用できます。しかしながら、わずかに異なるコマンドが必要になります:
~]$ ssh -L 1100:mail.example.com:110 other.example.com
この例では、クライアントマシンのポート 1100 からの POP3 リクエストは、ポート 22 における SSH コネクションを通して SSH サーバー other.example.com に転送されます。そして、other.example.com は、新しいメールをチェックするために mail.example.com のポート 110 に接続します。この技術を使用するとき、クライアントシステムと other.example.com SSH サーバーの間のコネクションはセキュアです。
ポート転送はネットワークのファイアウォールを経由して情報をセキュアに取得するためにも使用できます。もしファイアウォールが、標準的なポート(つまり、ポート22)を通して SSH 通信を許可するよう設定しているが、他のすべてのポートにアクセスを禁止しているならば、ブロックされているポートを使用する2つのホスト間のコネクションは、確立された SSH コネクション上でコミュニケーションをリダイレクトすることにより可能になります。

コネクションはクライアントシステムと同程度しかセキュアではありません。

この方法でポート転送を使って、接続を転送すると、そのクライアントシステム上のユーザーはいずれもそのサーバーに接続できるようになります。但し、クライアントシステムが侵略された場合、攻撃者は転送サービスにまでもアクセスが出来るようになります。
ポート転送について心配のあるシステム管理者は、/etc/ssh/sshd_config において AllowTcpForwarding 行に No パラメーターを指定して、sshd サービスを再起動するにより、この機能を無効にできます。

9.5. 追加のリソース

OpenSSH と OpenSSL プロジェクトの開発は常に進められているため、これらに関する最新情報は該当する Web サイトを参照してください。 OpenSSH と OpenSSL ツールの man ページでも詳細情報を参照することができます。

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

man ssh
ssh の使用法に関する完全なドキュメントを含むマニュアルページです。
man scp
scp の使用法に関する完全なドキュメントを含むマニュアルページです。
man sftp
sftp の使用法に関する完全なドキュメントを含むマニュアルページです。
man sshd
sshd の使用法に関する完全なドキュメントを含むマニュアルページです。
man ssh-keygen
ssh-keygen の使用法に関する完全なドキュメントを含むマニュアルページです。
man ssh_config
SSH クライアントの利用可能な設定オプションの完全な説明を持つマニュアルページです。
man sshd_config
SSH デーモンの利用可能な設定オプションの完全な説明を持つマニュアルページです。

9.5.2. 役に立つ Web サイト

http://www.openssh.com/
さらなるドキュメント、よくある質問、メーリングリストへのリンク、バグ報告、および他の有用なリソースがある OpenSSH のホームページです。
http://www.openssl.org/
さらなるドキュメント、よくある質問、メーリングリストへのリンク、および他の有用なリソースがある OpenSSL のホームページです。
http://www.freesshd.com/
SSH サーバーのもう一つの実装です。


[2] 多重化された接続は共有された一般的なメディア上で送られる複数の信号から構成されます。SSH では、異なるチャネルが共通のセキュアなコネクション上で送られます。

パート V. サーバー

このパートは、ウェブサーバーを導入する、またはネットワーク上にファイルとディレクトリを共有する方法のようなサーバーに関連したさまざまな話題を説明しています。

目次

10. DHCP サーバー
10.1. DHCP を使用する理由
10.2. DHCP サーバーの設定
10.2.1. 設定ファイル
10.2.2. リースデータベース
10.2.3. サーバーの起動と停止
10.2.4. DHCP リレーエージェント
10.3. DHCP クライアントの設定
10.4. Configuring a Multihomed DHCP Server
10.4.1. ホストの設定
10.5. IPv6 向け DHCP (DHCPv6)
10.6. その他のリソース
10.6.1. インストールされているドキュメント
11. DNS サーバー
11.1. DNS の概要
11.1.1. ネームサーバーゾーン
11.1.2. ネームサーバーのタイプ
11.1.3. ネームサーバーとしての BIND
11.2. BIND
11.2.1. named サービスの設定
11.2.2. ゾーンファイルの編集
11.2.3. rndc ユーティリティの使用法
11.2.4. dig ユーティリティの使用
11.2.5. BIND の高度な機能
11.2.6. よくある間違いを避けるために
11.2.7. その他のリソース
12. ウェブ サーバー
12.1. Apache HTTP サーバー
12.1.1. 新機能
12.1.2. 注目すべき変更
12.1.3. 設定の更新
12.1.4. httpd サービスの実行方法
12.1.5. 設定ファイルの編集
12.1.6. Working with Modules
12.1.7. 仮想ホストのセットアップ
12.1.8. SSL サーバーのセットアップ
12.1.9. その他のリソース
13. メールサーバー
13.1. 電子メールプロトコル
13.1.1. メール トランスポートのプロトコル
13.1.2. メール アクセスのプロトコル
13.2. 電子メールプログラム分類
13.2.1. メール転送エージェント (Mail Transport Agent)
13.2.2. メール配送エージェント (Mail Delivery Agent)
13.2.3. メール ユーザー エージェント
13.3. Mail Transport Agent
13.3.1. Postfix
13.3.2. Sendmail
13.3.3. Fetchmail
13.3.4. Mail Transport Agent (MTA) の設定
13.4. メール配送エージェント
13.4.1. Procmail の設定
13.4.2. Procmail レシピ
13.5. メールユーザーエージェント
13.5.1. 通信のセキュリティ
13.6. その他のリソース
13.6.1. インストールされているドキュメント
13.6.2. 役に立つ Web サイト
13.6.3. 関連書籍
14. ディレクトリー サーバー
14.1. OpenLDAP
14.1.1. Introduction to LDAP
14.1.2. OpenLDAP 製品群のインストール
14.1.3. OpenLDAP サーバーの設定法
14.1.4. Running an OpenLDAP Server
14.1.5. システムが OpenLDAP を使用して認証を実行するように設定する
14.1.6. その他のリソース
15. File and Print Servers
15.1. Samba
15.1.1. Samba の概要
15.1.2. Samba デーモンと関連サービス
15.1.3. Samba シェアへの接続
15.1.4. Samba サーバーの設定
15.1.5. Samba の開始と停止
15.1.6. Samba サーバー形式と smb.conf ファイル
15.1.7. Samba のセキュリティモード
15.1.8. Samba のアカウント情報データベース
15.1.9. Samba ネットワークブラウジング
15.1.10. CUPS 印刷サポートを使った Samba
15.1.11. Samba ディストリビューションプログラム
15.1.12. その他のリソース
15.2. FTP
15.2.1. ファイル伝送プロトコル
15.2.2. FTP サーバー
15.2.3. Files Installed with vsftpd
15.2.4. vsftpd の開始と停止
15.2.5. vsftpd 設定オプション
15.2.6. その他のリソース
15.3. プリンタの設定
15.3.1. Starting the Printer Configuration Tool
15.3.2. Starting Printer Setup
15.3.3. ローカルプリンタの追加
15.3.4. Adding an AppSocket/HP JetDirect printer
15.3.5. IPP プリンタの追加
15.3.6. Adding an LPD/LPR Host or Printer
15.3.7. Adding a Samba (SMB) printer
15.3.8. プリンタモデルの選択と終了
15.3.9. Printing a test page
15.3.10. 既存プリンタの変更
15.3.11. その他のリソース

第10章 DHCP サーバー

DHCP (Dynamic Host Configuration Protocol) は、クライアントマシンに自動的に TCP/IP 情報を割り当てるネットワークプロトコルです。各 DHCP クライアントは、中央に配置された DHCP サーバーに接続し、このサーバーが IP アドレス、ゲートウェイ、 DNS サーバーなどクライアントのネットワーク設定情報 (IP アドレス、ゲートウェイ、 DNS サーバーを含む) を返します。

10.1. DHCP を使用する理由

DHCP はクライアントのネットワークインターフェースを自動で設定するのに便利です。クライアントシステムを設定するとき DHCP を選択すれば、 IP アドレス、ネットマスク、ゲートウェイ、 DNS サーバーを入力する必要がありません。クライアントはこれらの情報を DHCP サーバーから受け取ります。また、管理者が多数のシステムの IP アドレスを変更する場合も DHCP は便利です。すべてのシステムの再設定を行う代わりに、サーバー上の DHCP 設定ファイルを編集することによって、新規の IP アドレスセットを設定できます。組織の DNS サーバーが変更された場合は、 DHCP クライアントで変更を行うのではなく、 DHCP サーバーで変更を行います。クライアントでネットワークが再起動 (またはクライアントがリブート) されると、変更が反映されます。
組織が、機能中の DHCP サーバーをネットワークに正しく接続している場合、ラップトップや他の携帯コンピュータの使用者はそのようなデバイスをオフィスからオフィスへと移動して使用できます。

10.2. DHCP サーバーの設定

dhcp パッケージは ISC DHCP サーバーを含みます。まず、root としてパッケージをインストールします:
yum install dhcp
dhcp パッケージをインストールすることにより、単に空の設定ファイル /etc/dhcp/dhcpd.conf が作成されます:
#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see dhcpd.conf(5) man page
#
サンプル設定ファイルが /usr/share/doc/dhcp-version/dhcpd.conf.sample にあります。以下に説明されている /etc/dhcp/dhcpd.conf を設定する助けにするために、このファイルを使用すべきです。
DHCP はクライアントの払い出しデータベースを保存するために /var/lib/dhcpd/dhcpd.leases ファイルも使用します。詳細は「リースデータベース」を参照してください。

10.2.1. 設定ファイル

DHCP サーバーを設定する第一歩は、クライアントのネットワーク情報を保存する設定ファイルを作成することです。クライアントシステムのオプションや全体オプションを宣言するためにこのファイルを使用します。
設定ファイルはフォーマットがしやすいように余計なタブや空白行を含めることができます。キーワードは大文字小文字を区別しません。また、ハッシュ記号 (#) から始まる行はコメント行と見なされます。
設定ファイルのステートメントには、次の2タイプがあります:
  • パラメーター — タスクがどのように実行されるか、またはクライアントに送られるネットワーク設定オプションを述べます。
  • 宣言 — ネットワークのトポロジーを記述します、クライアントを記述します、クライアントのアドレスを提供します、または宣言のグループにパラメーターのグループを適用します。
キーワードオプションで始まるパラメーターはオプションとして見なされます。これらのオプションは DHCP オプションを制御します。一方、パラメーターはオプションではない値を設定します、または、DHCP サーバーがどのように振る舞うかを制御します。
中かっこ ({ }) で囲まれたセクションの前に宣言されたパラメータとオプションは、グローバルパラメータとみなされます。グローバルパラメータは、それ以降のすべてのセクションに適用されます。

変更を反映するには DHCP デーモンを再起動します

設定ファイルが変更されても、DHCP デーモンを再起動するまで、変更が有効になりません。そうするには、root としてシェルプロンプトにおいて以下を入力します:
systemctl restart dhcpd.service

omshell コマンドを使用する

DHCP 設定ファイルを変更して、毎回サービスを再起動する代わりに、omshell コマンドを使用することにより、DHCP サーバーに接続し、その設定を問い合わせ、変更する非対話式の方法が提供されます。omshell を使用することにより、すべての変更はサーバーが実行中に反映されます。omshell の詳細は omshell マニュアルページを参照してください。
例10.1「サブネット宣言」において、routers, subnet-mask, domain-search, domain-name-servers, および time-offset オプションはその下に宣言されたすべての host ステートメントに対して使用できます。
さらに、subnet が宣言され、subnet 宣言がネットワークにあるすべてのサブネットに対して含めなければいけません。もしなければ、DHCP サーバーが起動に失敗します。
この例では、サブネットと宣言された range においてすべての DHCP クライアントに対する全体オプションがあります。クライアントは range の中にある IP アドレスが割り当てられます。
例10.1 サブネット宣言
subnet 192.168.1.0 netmask 255.255.255.0 {
        option routers                  192.168.1.254;
        option subnet-mask              255.255.255.0;
        option domain-search              "example.com";
        option domain-name-servers       192.168.1.1;
        option time-offset              -18000;     # Eastern Standard Time
	range 192.168.1.10 192.168.1.100;
}

動的 IP アドレスをサブネットにあるシステムに払い出す DHCP サーバーを設定するには、値を持つ例10.2「range パラメーター」を変更します。デフォルトの払い出し期間、最大の払い出し期間、およびクライアントに対するネットワーク設定値を宣言します。この例はクライアントシステムに対して range 192.168.1.10 と 192.168.1.100 にある IP アドレスを割り当てます。
例10.2 range パラメーター
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-search "example.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.100;
}

To assign an IP address to a client based on the MAC address of the network interface card, use the hardware ethernet parameter within a host declaration. As demonstrated in 例10.3「DHCP を用いた静的 IP アドレス」, the host apex declaration specifies that the network interface card with the MAC address 00:A0:78:8E:9E:AA always receives the IP address 192.168.1.4.
オプションのパラメーター host-name はホスト名をクライアントに割り当てるために使用されます。
例10.3 DHCP を用いた静的 IP アドレス
host apex {
   option host-name "apex.example.com";
   hardware ethernet 00:A0:78:8E:9E:AA;
   fixed-address 192.168.1.4;
}

All subnets that share the same physical network should be declared within a shared-network declaration as shown in 例10.4「shared-network 宣言」. Parameters within the shared-network, but outside the enclosed subnet declarations, are considered to be global parameters. The name of the shared-network must be a descriptive title for the network, such as using the title 'test-lab' to describe all the subnets in a test lab environment.
例10.4 shared-network 宣言
shared-network name {
    option domain-search              "test.redhat.com";
    option domain-name-servers      ns1.redhat.com, ns2.redhat.com;
    option routers                  192.168.0.254;
    more parameters for EXAMPLE shared-network
    subnet 192.168.1.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.1.1 192.168.1.254;
    }
    subnet 192.168.2.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.2.1 192.168.2.254;
    }
}

As demonstrated in 例10.5「group 宣言」, the group declaration is used to apply global parameters to a group of declarations. For example, shared networks, subnets, and hosts can be grouped.
例10.5 group 宣言
group {
   option routers                  192.168.1.254;
   option subnet-mask              255.255.255.0;
   option domain-search              "example.com";
   option domain-name-servers       192.168.1.1;
   option time-offset              -18000;     # Eastern Standard Time
   host apex {
      option host-name "apex.example.com";
      hardware ethernet 00:A0:78:8E:9E:AA;
      fixed-address 192.168.1.4;
   }
   host raleigh {
      option host-name "raleigh.example.com";
      hardware ethernet 00:A1:DD:74:C3:F2;
      fixed-address 192.168.1.6;
   }
}

サンプル設定ファイルの使用法

The sample configuration file provided can be used as a starting point and custom configuration options can be added to it. To copy it to the proper location, use the following command:
cp /usr/share/doc/dhcp-version-number/dhcpd.conf.sample /etc/dhcp/dhcpd.conf
... ここで version-number は DHCP バージョン番号です。
For a complete list of option statements and what they do, refer to the dhcp-options man page.

10.2.2. リースデータベース

On the DHCP server, the file /var/lib/dhcpd/dhcpd.leases stores the DHCP client lease database. Do not change this file. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.
リースデータベースにおける時刻はすべて、ローカル時でなく UTC (Coordinated Universal Time) を使用します。
The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~ and the temporary lease database is written to dhcpd.leases.
The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the dhcpd.leases file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

10.2.3. サーバーの起動と停止

DHCP サーバーの始めての起動

When the DHCP server is started for the first time, it fails unless the dhcpd.leases file exists. Use the command touch /var/lib/dhcpd/dhcpd.leases to create the file if it does not exist.
If the same server is also running BIND as a DNS server, this step is not necessary, as starting the named service automatically checks for a dhcpd.leases file.
DHCP サーバーを開始するには、次のとおり入力します:
systemctl start dhcpd.service
DHCP サーバーを停止するには、次のとおり入力します:
systemctl stop dhcpd.service
デフォルトで、DHCP サービスはブート時に開始しません。ブート時に自動的に開始するようデーモンを設定するには、以下を実行します:
systemctl enable dhcpd.service
Fedora においてサービスを設定する方法の詳細は7章サービスおよびデーモンを参照してください。
If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:
# Command line options here
DHCPDARGS=eth0
これは、ネットワークカードが2つあるファイアウォールマシンに便利な機能です。一方のネットワークカードを DHCP クライアントとして設定してインターネット用の IP アドレスを取得します。もう一方のネットワークカードは、ファイアウォール内の内部ネットワーク用の DHCP サーバーとして使用できます。内部ネットワークに接続されたネットワークカードだけを指定することにより、ユーザーがインターネット経由でデーモンに接続できなくなるので、システムがより安全になります。
Other command line options that can be specified in /etc/sysconfig/dhcpd include:
  • -p portnum — Specifies the UDP port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responses to the client on port 68. If a port is specified here and the DHCP relay agent is used, the same port on which the DHCP relay agent should listen must be specified. Refer to 「DHCP リレーエージェント」 for details.
  • -f — Runs the daemon as a foreground process. This is mostly used for debugging.
  • -d — Logs the DHCP server daemon to the standard error descriptor. This is mostly used for debugging. If this is not specified, the log is written to /var/log/messages.
  • -cf filename — Specifies the location of the configuration file. The default location is /etc/dhcp/dhcpd.conf.
  • -lf filename — Specifies the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is /var/lib/dhcpd/dhcpd.leases.
  • -q — デーモンを起動するときに全体の著作権メッセージを表示しません。

10.2.4. DHCP リレーエージェント

DHCP リレーエージェント (dhcrelay) は、DHCP と BOOTP 要求を DHCP サーバーを持つサブネットから他のサブネットにある1つ以上の DHCP サーバーまでリレーできます。
DHCP クライアントが情報を要求すると、 DHCP リレーエージェントは自身の起動時に指定された一覧に含まれる DHCP サーバーに要求を転送します。 DHCP サーバーのいずれかから応答が返されると、その応答はオリジナルの要求を送信したネットワークにブロードキャストされたりユニキャストされたりします。
The DHCP Relay Agent listens for DHCP requests on all interfaces unless the interfaces are specified in /etc/sysconfig/dhcrelay with the INTERFACES directive.
To start the DHCP Relay Agent, use the following command:
systemctl start dhcrelay.service

10.3. DHCP クライアントの設定

DHCP クライアントを手動で設定するには、ネットワークを有効にするために /etc/sysconfig/network ファイルを、また /etc/sysconfig/network-scripts ディレクトリにある各ネットワークデバイス用の設定ファイルを変更します。このディレクトリにおいて、各デバイス ifcfg-eth0 という名前の設定ファイルを持たなければいけません。ここで eth0 はネットワークデバイス名です。
/etc/sysconfig/network-scripts/ifcfg-eth0 ファイルは以下の行を含まなければいけません:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
DHCP を使用するよう設定するデバイスごとに設定ファイルが必要です。
ネットワークスクリプト用に含まれるその他のオプション:
  • DHCP_HOSTNAME — Only use this option if the DHCP server requires the client to specify a hostname before receiving an IP address. (The DHCP server daemon in Fedora does not support this feature.)
  • PEERDNS=answer 、ここでanswer は以下のいずれかです:
    • yes — サーバーからの情報を用いて /etc/resolv.conf を変更します。DHCP を使用しているならば、yes はデフォルトです。
    • no/etc/resolv.conf を変更しません。

高度な設定

For advanced configurations of client DHCP options such as protocol timing, lease requirements and requests, dynamic DNS support, aliases, as well as a wide variety of values to override, prepend, or append to client-side configurations, refer to the dhclient and dhclient.conf man pages.

10.4. Configuring a Multihomed DHCP Server

A multihomed DHCP server serves multiple networks, that is, multiple subnets. The examples in these sections detail how to configure a DHCP server to serve multiple networks, select which network interfaces to listen on, and how to define network settings for systems that move networks.
Before making any changes, back up the existing /etc/sysconfig/dhcpd and /etc/dhcp/dhcpd.conf files.
The DHCP daemon listens on all network interfaces unless otherwise specified. Use the /etc/sysconfig/dhcpd file to specify which network interfaces the DHCP daemon listens on. The following /etc/sysconfig/dhcpd example specifies that the DHCP daemon listens on the eth0 and eth1 interfaces:
DHCPDARGS="eth0 eth1";
If a system has three network interfaces cards -- eth0, eth1, and eth2 -- and it is only desired that the DHCP daemon listens on eth0, then only specify eth0 in /etc/sysconfig/dhcpd:
DHCPDARGS="eth0";
The following is a basic /etc/dhcp/dhcpd.conf file, for a server that has two network interfaces, eth0 in a 10.0.0.0/24 network, and eth1 in a 172.16.0.0/24 network. Multiple subnet declarations allow different settings to be defined for multiple networks:
default-lease-time 600;
max-lease-time 7200;
subnet 10.0.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 10.0.0.1;
	range 10.0.0.5 10.0.0.15;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 172.16.0.1;
	range 172.16.0.5 172.16.0.15;
}
subnet 10.0.0.0 netmask 255.255.255.0;
A subnet declaration is required for every network your DHCP server is serving. Multiple subnets require multiple subnet declarations. If the DHCP server does not have a network interface in a range of a subnet declaration, the DHCP server does not serve that network.
If there is only one subnet declaration, and no network interfaces are in the range of that subnet, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
dhcpd: No subnet declaration for eth0 (0.0.0.0).
dhcpd: ** Ignoring requests on eth0.  If this is not what
dhcpd:    you want, please write a subnet declaration
dhcpd:    in your dhcpd.conf file for the network segment
dhcpd:    to which interface eth1 is attached. **
dhcpd:
dhcpd:
dhcpd: Not configured to listen on any interfaces!
option subnet-mask 255.255.255.0;
option subnet-mask オプションはサブネットマスクを定義します。subnet 宣言における netmask 値を上書きします。簡単な例では、サブネットとネットマスクの値は同じです。
option routers 10.0.0.1;
The option routers option defines the default gateway for the subnet. This is required for systems to reach internal networks on a different subnet, as well as external networks.
range 10.0.0.5 10.0.0.15;
range オプションは利用可能な IP アドレスのプールを指定します。システムは指定された IP アドレスの範囲からアドレスを割り当てられます。
詳細は dhcpd.conf(5) マニュアルページを参照してください。

エイリアス・インターフェースを使用しないでください

エイリアス・インターフェースは DHCP によりサポートされません。エイリアス・インターフェースが /etc/dhcp/dhcpd.conf において指定されている唯一のサブネットにおける唯一のインターフェースならば、DHCP デーモンは開始に失敗します。

10.4.1. ホストの設定

Before making any changes, back up the existing /etc/sysconfig/dhcpd and /etc/dhcp/dhcpd.conf files.
Configuring a single system for multiple networks
以下の /etc/dhcp/dhcpd.conf の例は2つのサブネットを作成し、接続しているネットワークに応じて同じシステムに対する IP アドレスを設定します。
default-lease-time 600;
max-lease-time 7200;
subnet 10.0.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 10.0.0.1;
	range 10.0.0.5 10.0.0.15;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 172.16.0.1;
	range 172.16.0.5 172.16.0.15;
}
host example0 {
	hardware ethernet 00:1A:6B:6A:2E:0B;
	fixed-address 10.0.0.20;
}
host example1 {
	hardware ethernet 00:1A:6B:6A:2E:0B;
	fixed-address 172.16.0.20;
}
host example0
The host declaration defines specific parameters for a single system, such as an IP address. To configure specific parameters for multiple hosts, use multiple host declarations.
Most DHCP clients ignore the name in host declarations, and as such, this name can anything, as long as it is unique to other host declarations. To configure the same system for multiple networks, use a different name for each host declaration, otherwise the DHCP daemon fails to start. Systems are identified by the hardware ethernet option, not the name in the host declaration.
hardware ethernet 00:1A:6B:6A:2E:0B;
The hardware ethernet option identifies the system. To find this address, run the ip link command.
fixed-address 10.0.0.20;
The fixed-address option assigns a valid IP address to the system specified by the hardware ethernet option. This address must be outside the IP address pool specified with the range option.
If option statements do not end with a semicolon, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
/etc/dhcp/dhcpd.conf line 20: semicolon expected.
dhcpd: }
dhcpd: ^
dhcpd: /etc/dhcp/dhcpd.conf line 38: unexpected end of file
dhcpd:
dhcpd: ^
dhcpd: Configuration file errors encountered -- exiting
複数のネットワークインターフェースを持つシステムの設定
The following host declarations configure a single system, that has multiple network interfaces, so that each interface receives the same IP address. This configuration will not work if both network interfaces are connected to the same network at the same time:
host interface0 {
	hardware ethernet 00:1a:6b:6a:2e:0b;
	fixed-address 10.0.0.18;
}
host interface1 {
	hardware ethernet 00:1A:6B:6A:27:3A;
	fixed-address 10.0.0.18;
}
For this example, interface0 is the first network interface, and interface1 is the second interface. The different hardware ethernet options identify each interface.
If such a system connects to another network, add more host declarations, remembering to:
  • assign a valid fixed-address for the network the host is connecting to.
  • make the name in the host declaration unique.
When a name given in a host declaration is not unique, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
dhcpd: /etc/dhcp/dhcpd.conf line 31: host interface0: already exists
dhcpd: }
dhcpd: ^
dhcpd: Configuration file errors encountered -- exiting
This error was caused by having multiple host interface0 declarations defined in /etc/dhcp/dhcpd.conf.

10.5. IPv6 向け DHCP (DHCPv6)

The ISC DHCP includes support for IPv6 (DHCPv6) since the 4.x release with a DHCPv6 server, client and relay agent functionality. The server, client and relay agents support both IPv4 and IPv6. However, the client and the server can only manage one protocol at a time — for dual support they must be started separately for IPv4 and IPv6.
The DHCPv6 server configuration file can be found at /etc/dhcp/dhcpd6.conf.
The sample server configuration file can be found at /usr/share/doc/dhcp-version/dhcpd6.conf.sample.
To start the DHCPv6 service, use the following command:
systemctl start dhcpd6.service
A simple DHCPv6 server configuration file can look like this:
subnet6 2001:db8:0:1::/64 {
        range6 2001:db8:0:1::129 2001:db8:0:1::254;
        option dhcp6.name-servers fec0:0:0:1::1;
        option dhcp6.domain-search "domain.example";
}

10.6. その他のリソース

For additional information, refer to The DHCP Handbook; Ralph Droms and Ted Lemon; 2003 or the following resources.

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

  • dhcpd マニュアルページ — DHCP デーモンがどうように動作するかを説明します。
  • dhcpd.conf man page — Explains how to configure the DHCP configuration file; includes some examples.
  • dhcpd.leases man page — Describes a persistent database of leases.
  • dhcp-options man page — Explains the syntax for declaring DHCP options in dhcpd.conf; includes some examples.
  • dhcrelay man page — Explains the DHCP Relay Agent and its configuration options.
  • /usr/share/doc/dhcp-version/ — Contains sample files, README files, and release notes for current versions of the DHCP service.

第11章 DNS サーバー

DNS (Domain Name System) は、ネームサーバーとしても知られ、ホスト名とそれぞれの IP アドレスを関連づけるネットワークシステムです。ユーザーにとって、ネットワークにあるマシンを名前で参照できるという利便性があります。通常これは数値のネットワークアドレスよりも記憶しやすいです。システム管理者にとって、ネームサーバーを使用することにより、名前に基づいた問い合わせに影響を与えることなくホストの IP アドレスを変更したり、どのマシンがこれらの問い合わせを処理するかを決めたりできるようになります。

11.1. DNS の概要

DNS は、集中化されたドメインに対して権威のある、1つか複数の集中化されたサーバーを使用して実装されます。クライアントホストがネームサーバーから情報を要求するとき、通常ポート 53 に接続します。そして、ネームサーバーは要求された名前を解決しようとします。権威のある回答を持たなければ、または以前の問い合わせからキャッシュされた回答をすでに持っていなければ、どのネームサーバーが問い合わせにある名前に対して権威があるかを決めるために、ルートネームサーバーと呼ばれる他のネームサーバーに問い合わせます。そして、要求された名前を取得するためにそのサーバーに問い合わせます。

11.1.1. ネームサーバーゾーン

BIND のような DNS サーバーにおいて、すべての情報はリソースレコード (RR) と呼ばれる基本的なデータ要素に保存されます。リソースレコードは通常ホストの fully qualified domain name (FQDN) です。そして、ツリー構造の階層の中に整理された複数のセクションに分解されます。この階層は、主幹、一次分岐、二次分岐などから構成されます。以下はリソースレコードの例です:
bob.sales.example.com
階層の各レベルはピリオド(つまり、.)により分割されます。上の例では、comトップレベルドメイン、そのサブドメイン exampleexample のサブドメイン sales を定義します。この場合、bobsales.example.com ドメインの一部であるリソースレコードを識別します。最も左にある部分(つまり、bob)を除き、これらのセクションの各部はゾーンと呼ばれ、具体的な名前空間を定義します。
ゾーンはゾーンファイルの使用により権威ネームサーバーにおいて定義されます。これは、各ゾーンにおけるリソースレコードの定義を含みます。ゾーンファイルはプライマリネームサーバーマスターネームサーバーとも呼ばれます)において(変更はファイルに対して行われます)、および、セカンダリネームサーバースレーブネームサーバーとも呼ばれます)において(プライマリネームサーバーからゾーン定義を受信します)保存されます。プライマリとセカンダリどちらのネームサーバーもゾーンに対する権威であり、クライアントに同じように見えます。設定によっては、すべてのネームサーバーが複数のゾーンに対して同時にプライマリまたはセカンダリサーバーとしても処理できます。

11.1.2. ネームサーバーのタイプ

ネームサーバーの設定種別が2つあります:
権威
権威ネームサーバーはそれらのゾーンのみの一部であるリソースレコードに回答します。この分類はプライマリ(マスター)およびセカンダリ(スレーブ)ネームサーバーを含みます。
再帰
再帰ネームサーバーは解決サービスを提供しますが、あらゆるゾーンに対して権威的ではありません。すべての解決に対する回答は、取り出したリソースレコードにより指定された、一定期間メモリーにキャッシュされます。
ネームサーバーは同時に権威および再帰になれますが、設定の種別を組み合わせることは推奨されません。これらの機能を実行できるようにするには、権威サーバーがいつでもすべてのクライアントに利用可能であるべきです。一方、再帰問い合わせは権威のある応答よりも時間がかかるので、再帰サーバーは制限された数のクライアントのみに利用可能であるべきです。そうしなければ、分散サービス妨害(DDoS)攻撃を受けやすくなります。

11.1.3. ネームサーバーとしての BIND

BIND は DNS 関連のプログラム群から構成されています。named という画一的なネームサーバー、rndc という管理ユーティリティ、および dig というデバッグツールを含みます。Fedora においてサービスを設定する方法に関する詳細は7章サービスおよびデーモンを参照してください。

11.2. BIND

本章は Fedora に含まれる DNS サーバーである BIND (Berkeley Internet Name Domain) を取り扱います。その設定ファイルの構造に焦点を当て、ローカルおよびリモートで管理する方法について説明しています。

11.2.1. named サービスの設定

named サービスが起動するとき、表11.1「named サービス設定ファイル」において説明されているように、ファイルから設定が読み込まれます。
表11.1 named サービス設定ファイル
パス 説明
/etc/named.conf 主要な設定ファイル。
/etc/named/ 主要な設定ファイルから取り込まれる設定ファイルのための補助ディレクトリ。

The configuration file consists of a collection of statements with nested options surrounded by opening and closing curly brackets (that is, { and }). Note that when editing the file, you have to be careful not to make any syntax error, otherwise the named service will not start. A typical /etc/named.conf file is organized as follows:
statement-1 ["statement-1-name"] [statement-1-class] {
  option-1;
  option-2;
  option-N;
};
statement-2 ["statement-2-name"] [statement-2-class] {
  option-1;
  option-2;
  option-N;
};
statement-N ["statement-N-name"] [statement-N-class] {
  option-1;
  option-2;
  option-N;
};

chroot 環境における BIND の実行

If you have installed the bind-chroot package, the BIND service will run in the /var/named/chroot environment. In that case, the initialization script will mount the above configuration files using the mount --bind command, so that you can manage the configuration outside this environment.

11.2.1.1. 一般的なステートメントのタイプ

The following types of statements are commonly used in /etc/named.conf:
acl
acl (Access Control List) ステートメントによりホストのグループを定義できます。それにより、ネームサーバーへのアクセスを許可および拒否できます。これは以下の形式をとります:
acl acl-name {
  match-element;
  ...
};
The acl-name statement name is the name of the access control list, and the match-element option is usually an individual IP address (such as 10.0.1.1) or a CIDR network notation (for example, 10.0.1.0/24). For a list of already defined keywords, see 表11.2「事前定義済みアクセス制御リスト」.
表11.2 事前定義済みアクセス制御リスト
キーワード 説明
any すべての IP アドレスに一致します。
localhost ローカルシステムにおいて使用中のすべての IP アドレスに一致します。
localnets ローカルシステムが接続されているすべてのネットワークにある IP アドレスに一致します。
none どの IP アドレスにも一致しません。

The acl statement can be especially useful with conjunction with other statements such as options. 例11.1「オプションと併用した ACL の使用」 defines two access control lists, black-hats and red-hats, and adds black-hats on the blacklist while granting red-hats a normal access.
例11.1 オプションと併用した ACL の使用
acl black-hats {
  10.0.2.0/24;
  192.168.0.0/24;
  1234:5678::9abc/24;
};
acl red-hats {
  10.0.1.0/24;
};
options {
  blackhole { black-hats; };
  allow-query { red-hats; };
  allow-query-cache { red-hats; };
};

include
The include statement allows you to include files in the /etc/named.conf, so that potentially sensitive data can be placed in a separate file with restricted permissions. It takes the following form:
include "file-name"
The file-name statement name is an absolute path to a file.
例11.2 /etc/named.conf へのファイルの取り込み
include "/etc/named.rfc1912.zones";

options
The options statement allows you to define global server configuration options as well as to set defaults for other statements. It can be used to specify the location of the named working directory, the types of queries allowed, and much more. It takes the following form:
options {
  option;
  ...
};
For a list of frequently used option directives, see 表11.3「一般的に使用されるオプション」 below.
表11.3 一般的に使用されるオプション
オプション 説明
allow-query ネームサーバーに権威リソースレコードを問い合わせできるホストを指定します。アクセス制御リスト、IP アドレスの組、または CIDR 表記のネットワークを受け付けます。すべてのホストがデフォルトで許可されます。
allow-query-cache ネームサーバーに再帰問い合わせのような権威のないデータを問い合わせできるホストを指定します。localhost および localnets のみがデフォルトで許可されます。
blackhole ネームサーバーに問い合わせを許可されないホストを指定します。このオプションは特定のホストやネットワークがサーバーをリクエストであふれさせるときに使われるべきです。デフォルトのオプションは none です。
directory named サービスの作業ディレクトリを指定します。デフォルトオプションは /var/named/ です。
dnssec-enable DNSSEC 関連リソースレコードを返すかどうかを指定します。デフォルトオプションは yes です。
dnssec-validation Specifies whether to prove that resource records are authentic via DNSSEC. The default option is yes.
forwarders Specifies a list of valid IP addresses for nameservers to which the requests should be forwarded for resolution.
forward
Specifies the behavior of the forwarders directive. It accepts the following options:
  • first — The server will query the nameservers listed in the forwarders directive before attempting to resolve the name on its own.
  • only — When unable to query the nameservers listed in the forwarders directive, the server will not attempt to resolve the name on its own.
listen-on 問い合わせを受け付ける IPv4 ネットワークインターフェースを指定します。ゲートウェイとしても動作する DNS サーバーにおいて、単一のネットワークのみから問い合わせを受け付けるために、このオプションを使用できます。すべての IPv4 インターフェースがデフォルトで使用されます。
listen-on-v6 問い合わせを受け付ける IPv6 ネットワークインターフェースを指定します。ゲートウェイとしても動作する DNS サーバーにおいて、単一のネットワークのみから問い合わせを受け付けるために、このオプションを使用できます。すべての IPv6 インターフェースがデフォルトで使用されます。
max-cache-size サーバーキャッシュのために使用されるメモリーの最大量を指定します。制限に達するとき、制限を越えないように、サーバーはレコードを早めに期限切れさせます。複数のビューを持つサーバーにおいては、制限は各ビューのキャッシュにそれぞれ適用されます。デフォルトのオプションは 32M です。
notify
Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options:
  • yes — The server will notify all secondary nameservers.
  • no — The server will not notify any secondary nameserver.
  • master-only — The server will notify primary server for the zone only.
  • explicit — The server will notify only the secondary servers that are specified in the also-notify list within a zone statement.
pid-file Specifies the location of the process ID file created by the named service.
recursion Specifies whether to act as a recursive server. The default option is yes.
statistics-file Specifies an alternate location for statistics files. The /var/named/named.stats file is used by default.

Restrict recursive servers to selected clients only

To prevent distributed denial of service (DDoS) attacks, it is recommended that you use the allow-query-cache option to restrict recursive DNS services for a particular subset of clients only.
Refer to the BIND 9 Administrator Reference Manual referenced in 「インストールされているドキュメント」, and the named.conf manual page for a complete list of available options.
例11.3 Using the options statement
options {
  allow-query       { localhost; };
  listen-on port    53 { 127.0.0.1; };
  listen-on-v6 port 53 { ::1; };
  max-cache-size    256M;
  directory         "/var/named";
  statistics-file   "/var/named/data/named_stats.txt";

  recursion         yes;
  dnssec-enable     yes;
  dnssec-validation yes;
};

zone
The zone statement allows you to define the characteristics of a zone, such as the location of its configuration file and zone-specific options, and can be used to override the global options statements. It takes the following form:
zone zone-name [zone-class] {
  option;
  ...
};
The zone-name attribute is the name of the zone, zone-class is the optional class of the zone, and option is a zone statement option as described in 表11.4「一般的に使用されるオプション」.
The zone-name attribute is particularly important, as it is the default value assigned for the $ORIGIN directive used within the corresponding zone file located in the /var/named/ directory. The named daemon appends the name of the zone to any non-fully qualified domain name listed in the zone file. For example, if a zone statement defines the namespace for example.com, use example.com as the zone-name so that it is placed at the end of hostnames within the example.com zone file.
For more information about zone files, refer to 「ゾーンファイルの編集」.
表11.4 一般的に使用されるオプション
オプション 説明
allow-query Specifies which clients are allowed to request information about this zone. This option overrides global allow-query option. All query requests are allowed by default.
allow-transfer Specifies which secondary servers are allowed to request a transfer of the zone's information. All transfer requests are allowed by default.
allow-update
Specifies which hosts are allowed to dynamically update information in their zone. The default option is to deny all dynamic update requests.
Note that you should be careful when allowing hosts to update information about their zone. Do not set IP addresses in this option unless the server is in the trusted network. Instead, use TSIG key as described in 「Transaction SIGnatures (TSIG)」.
file Specifies the name of the file in the named working directory that contains the zone's configuration data.
masters Specifies from which IP addresses to request authoritative zone information. This option is used only if the zone is defined as type slave.
notify
Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options:
  • yes — The server will notify all secondary nameservers.
  • no — The server will not notify any secondary nameserver.
  • master-only — The server will notify primary server for the zone only.
  • explicit — The server will notify only the secondary servers that are specified in the also-notify list within a zone statement.
type
Specifies the zone type. It accepts the following options:
  • delegation-only — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as NXDOMAIN. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.
  • forward — Forwards all requests for information about this zone to other nameservers.
  • hint — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a hint zone.
  • master — Designates the nameserver as authoritative for this zone. A zone should be set as the master if the zone's configuration files reside on the system.
  • slave — Designates the nameserver as a slave server for this zone. Master server is specified in masters directive.

Most changes to the /etc/named.conf file of a primary or secondary nameserver involve adding, modifying, or deleting zone statements, and only a small subset of zone statement options is usually needed for a nameserver to work efficiently.
In 例11.4「A zone statement for a primary nameserver」, the zone is identified as example.com, the type is set to master, and the named service is instructed to read the /var/named/example.com.zone file. It also allows only a secondary nameserver (192.168.0.2) to transfer the zone.
例11.4 A zone statement for a primary nameserver
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-transfer { 192.168.0.2; };
};

A secondary server's zone statement is slightly different. The type is set to slave, and the masters directive is telling named the IP address of the master server.
In 例11.5「A zone statement for a secondary nameserver」, the named service is configured to query the primary server at the 192.168.0.1 IP address for information about the example.com zone. The received information is then saved to the /var/named/slaves/example.com.zone file. Note that you have to put all slave zones to /var/named/slaves directory, otherwise the service will fail to transfer the zone.
例11.5 A zone statement for a secondary nameserver
zone "example.com" {
  type slave;
  file "slaves/example.com.zone";
  masters { 192.168.0.1; };
};

11.2.1.2. 他のステートメント形式

The following types of statements are less commonly used in /etc/named.conf:
controls
The controls statement allows you to configure various security requirements necessary to use the rndc command to administer the named service.
rndc ユーティリティとその使用法の詳細は「rndc ユーティリティの使用法」を参照してください。
key
The key statement allows you to define a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the rndc command. Two options are used with key:
  • algorithm algorithm-name — The type of algorithm to be used (for example, hmac-md5).
  • secret "key-value" — The encrypted key.
rndc ユーティリティとその使用法の詳細は「rndc ユーティリティの使用法」を参照してください。
logging
The logging statement allows you to use multiple types of logs, so called channels. By using the channel option within the statement, you can construct a customized type of log with its own file name (file), size limit (size), versioning (version), and level of importance (severity). Once a customized channel is defined, a category option is used to categorize the channel and begin logging when the named service is restarted.
By default, named sends standard messages to the rsyslog daemon, which places them in /var/log/messages. Several standard channels are built into BIND with various severity levels, such as default_syslog (which handles informational logging messages) and default_debug (which specifically handles debugging messages). A default category, called default, uses the built-in channels to do normal logging without any special configuration.
Customizing the logging process can be a very detailed process and is beyond the scope of this chapter. For information on creating custom BIND logs, refer to the BIND 9 Administrator Reference Manual referenced in 「インストールされているドキュメント」.
server
The server statement allows you to specify options that affect how the named service should respond to remote nameservers, especially with regard to notifications and zone transfers.
The transfer-format option controls the number of resource records that are sent with each message. It can be either one-answer (only one resource record), or many-answers (multiple resource records). Note that while the many-answers option is more efficient, it is not supported by older versions of BIND.
trusted-keys
The trusted-keys statement allows you to specify assorted public keys used for secure DNS (DNSSEC). Refer to 「DNS Security Extensions (DNSSEC)」 for more information on this topic.
view
The view statement allows you to create special views depending upon which network the host querying the nameserver is on. This allows some hosts to receive one answer regarding a zone while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.
Multiple views can be used as long as their names are unique. The match-clients option allows you to specify the IP addresses that apply to a particular view. If the options statement is used within a view, it overrides the already configured global options. Finally, most view statements contain multiple zone statements that apply to the match-clients list.
Note that the order in which the view statements are listed is important, as the first statement that matches a particular client's IP address is used. For more information on this topic, refer to 「複数ビュー」.

11.2.1.3. コメントタグ

Additionally to statements, the /etc/named.conf file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to a user. The following are valid comment tags:
//
// 文字列の後ろにあるテキストは行末までがコメントとみなされます。たとえば:
notify yes;  // notify all secondary nameservers
#
# 記号の後ろにあるテキストは行末までがコメントとみなされます。たとえば:
notify yes;  # notify all secondary nameservers
/**/
/**/ に囲まれたテキストのブロックはコメントとみなされます。たとえば:
notify yes;  /* notify all secondary nameservers */

11.2.2. ゾーンファイルの編集

As outlined in 「ネームサーバーゾーン」, zone files contain information about a namespace. They are stored in the named working directory located in /var/named/ by default, and each zone file is named according to the file option in the zone statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone.
表11.5 The named service zone files
パス 説明
/var/named/ named サービスの作業ディレクトリです。ネームサーバーはこのディレクトリに書き込みが許可されません
/var/named/slaves/ セカンダリ・ゾーン向けのディレクトリです。このディレクトリは named サービスにより書き込み可能です。
/var/named/dynamic/ The directory for other files, such as dynamic DNS (DDNS) zones or managed DNSSEC keys. This directory is writable by the named service.
/var/named/data/ The directory for various statistics and debugging files. This directory is writable by the named service.

A zone file consists of directives and resource records. Directives tell the nameserver to perform tasks or apply special settings to the zone, resource records define the parameters of the zone and assign identities to individual hosts. While the directives are optional, the resource records are required in order to provide name service to a zone.
すべてのディレクティブとリソースレコードは、個々の行に記載する必要があります。

11.2.2.1. Common Directives

Directives begin with the dollar sign character (that is, $) followed by the name of the directive, and usually appear at the top of the file. The following directives are commonly used in zone files:
$INCLUDE
The $INCLUDE directive allows you to include another file at the place where it appears, so that other zone settings can be stored in a separate zone file.
例11.6 Using the $INCLUDE directive
$INCLUDE /var/named/penguin.example.com

$ORIGIN
The $ORIGIN directive allows you to append the domain name to unqualified records, such as those with the hostname only. Note that the use of this directive is not necessary if the zone is specified in /etc/named.conf, since the zone name is used by default.
In 例11.7「$ORIGIN ディレクティブの使用法」, any names used in resource records that do not end in a trailing period (that is, the . character) are appended with example.com.
例11.7 $ORIGIN ディレクティブの使用法
$ORIGIN example.com.

$TTL
The $TTL directive allows you to set the default Time to Live (TTL) value for the zone, that is, how long is a zone record valid. Each resource record can contain its own TTL value, which overrides this directive.
この値を増加させると、リモートネームサーバーは、このゾーンの情報をより長時間キャッシュします。こうすると、このゾーンについて行われるクエリの数は減りますが、リソースレコード変更を伝えるのに要する時間は長くなります。
例11.8 $TTL ディレクティブの使用
$TTL 1D

11.2.2.2. Common Resource Records

The following resource records are commonly used in zone files:
A
The Address record specifies an IP address to be assigned to a name. It takes the following form:
hostname IN A IP-address
If the hostname value is omitted, the record will point to the last specified hostname.
In 例11.9「A リソースレコードの使用法」, the requests for server1.example.com are pointed to 10.0.1.3 or 10.0.1.5.
例11.9 A リソースレコードの使用法
server1  IN  A  10.0.1.3
         IN  A  10.0.1.5

CNAME
The Canonical Name record maps one name to another. Because of this, this type of record is sometimes referred to as an alias record. It takes the following form:
alias-name IN CNAME real-name
CNAME records are most commonly used to point to services that use a common naming scheme, such as www for Web servers. However, there are multiple restrictions for their usage:
  • CNAME records should not point to other CNAME records. This is mainly to avoid possible infinite loops.
  • CNAME records should not contain other resource record types (such as A, NS, MX, etc.). The only exception are DNSSEC related records (that is, RRSIG, NSEC, etc.) when the zone is signed.
  • Other resource record that point to the fully qualified domain name (FQDN) of a host (that is, NS, MX, PTR) should not point to a CNAME record.
In 例11.10「CNAME リソースレコードの使用法」, the A record binds a hostname to an IP address, while the CNAME record points the commonly used www hostname to it.
例11.10 CNAME リソースレコードの使用法
server1  IN  A      10.0.1.5
www      IN  CNAME  server1

MX
The Mail Exchange record specifies where the mail sent to a particular namespace controlled by this zone should go. It takes the following form:
IN MX preference-value email-server-name
The email-server-name is a fully qualified domain name (FQDN). The preference-value allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The MX resource record with the lowest preference-value is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.
In 例11.11「MX リソースレコードの使用法」, the first mail.example.com email server is preferred to the mail2.example.com email server when receiving email destined for the example.com domain.
例11.11 MX リソースレコードの使用法
example.com.  IN  MX  10  mail.example.com.
              IN  MX  20  mail2.example.com.

NS
ネームサーバーレコードは、他のゾーンに対する権威ネームサーバーを知らせます。以下の形式をとります:
IN NS nameserver-name
The nameserver-name should be a fully qualified domain name (FQDN). Note that when two nameservers are listed as authoritative for the domain, it is not important whether these nameservers are secondary nameservers, or if one of them is a primary server. They are both still considered authoritative.
例11.12 NS リソースレコードの使用法
IN  NS  dns1.example.com.
IN  NS  dns2.example.com.

PTR
ポインター レコードは、名前空間の他の場所を示します。以下の形式をとります:
last-IP-digit IN PTR FQDN-of-system
The last-IP-digit directive is the last number in an IP address, and the FQDN-of-system is a fully qualified domain name (FQDN).
PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to 「逆引き名前解決ゾーンファイル」 for more examples of PTR records in use.
SOA
The Start of Authority record announces important authoritative information about a namespace to the nameserver. Located after the directives, it is the first resource record in a zone file. It takes the following form:
@  IN  SOA  primary-name-server hostmaster-email (
       serial-number
       time-to-refresh
       time-to-retry
       time-to-expire
       minimum-TTL )
ディレクティブは以下のとおりです:
  • The @ symbol places the $ORIGIN directive (or the zone's name if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record.
  • The primary-name-server directive is the hostname of the primary nameserver that is authoritative for this domain.
  • The hostmaster-email directive is the email of the person to contact about the namespace.
  • The serial-number directive is a numerical value incremented every time the zone file is altered to indicate it is time for the named service to reload the zone.
  • The time-to-refresh directive is the numerical value secondary nameservers use to determine how long to wait before asking the primary nameserver if any changes have been made to the zone.
  • The time-to-retry directive is a numerical value used by secondary nameservers to determine the length of time to wait before issuing a refresh request in the event that the primary nameserver is not answering. If the primary server has not replied to a refresh request before the amount of time specified in the time-to-expire directive elapses, the secondary servers stop responding as an authority for requests concerning that namespace.
  • In BIND 4 and 8, the minimum-TTL directive is the amount of time other nameservers cache the zone's information. In BIND 9, it defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (that is, 3H).
When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (M), hours (H), days (D), and weeks (W). 表11.6「他の時間単位と比較した秒数」 shows an amount of time in seconds and the equivalent time in another format.
表11.6 他の時間単位と比較した秒数
他の時間単位
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D

例11.13 SOA リソースレコードの使用法
@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day

11.2.2.3. コメントタグ

Additionally to resource records and directives, a zone file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to the user. Any text after the semicolon character (that is, ;) to the end of the line is considered a comment. For example:
   604800  ; 1 週間後に期限切れ

11.2.2.4. 使用例

以下の例はゾーンファイルの基本的な使用法を示しています。
11.2.2.4.1. 簡単なゾーンファイル
例11.14「簡単なゾーンファイル」は標準的なディレクティブと SOA 値の使用法を説明します。
例11.14 簡単なゾーンファイル
$ORIGIN example.com.
$TTL 86400
@         IN  SOA  dns1.example.com.  hostmaster.example.com. (
              2001062501  ; serial
              21600       ; refresh after 6 hours
              3600        ; retry after 1 hour
              604800      ; expire after 1 week
              86400 )     ; minimum TTL of 1 day
;
;
          IN  NS     dns1.example.com.
          IN  NS     dns2.example.com.
dns1      IN  A      10.0.1.1
          IN  AAAA   aaaa:bbbb::1
dns2      IN  A      10.0.1.2
          IN  AAAA   aaaa:bbbb::2
;
;
@         IN  MX     10  mail.example.com.
          IN  MX     20  mail2.example.com.
mail      IN  A      10.0.1.5
          IN  AAAA   aaaa:bbbb::5
mail2     IN  A      10.0.1.6
          IN  AAAA   aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses
; for multiple services:
;
services  IN  A      10.0.1.10
          IN  AAAA   aaaa:bbbb::10
          IN  A      10.0.1.11
          IN  AAAA   aaaa:bbbb::11

ftp       IN  CNAME  services.example.com.
www       IN  CNAME  services.example.com.
;
;

In this example, the authoritative nameservers are set as dns1.example.com and dns2.example.com, and are tied to the 10.0.1.1 and 10.0.1.2 IP addresses respectively using the A record.
The email servers configured with the MX records point to mail and mail2 via A records. Since these names do not end in a trailing period (that is, the . character), the $ORIGIN domain is placed after them, expanding them to mail.example.com and mail2.example.com.
Services available at the standard names, such as www.example.com (WWW), are pointed at the appropriate servers using the CNAME record.
このゾーンファイルは、/etc/named.conf ファイルにおいて、以下のような zone ステートメントを用いたサービスの中に呼び出されます:
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-update { none; };
};
11.2.2.4.2. 逆引き名前解決ゾーンファイル
逆引き名前解決ゾーンファイルは、特定の名前空間にある IP アドレスを完全修飾ドメイン名(FQDN)に変換するために使用されます。これは、例11.15「逆引き名前解決ゾーンファイル」にあるよように、PTR リソースレコードが IP アドレスを完全修飾ドメイン名にリンクするために使用されることを除いて、標準的なゾーンファイルによく似ています。
例11.15 逆引き名前解決ゾーンファイル
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day
;
@  IN  NS   dns1.example.com.
;
1  IN  PTR  dns1.example.com.
2  IN  PTR  dns2.example.com.
;
5  IN  PTR  server1.example.com.
6  IN  PTR  server2.example.com.
;
3  IN  PTR  ftp.example.com.
4  IN  PTR  ftp.example.com.

この例において、IP アドレス 10.0.1.1 から 10.0.1.6 は対応する完全修飾ドメイン名に対応づけられます。
このゾーンファイルは、/etc/named.conf ファイルにおいて、以下のような zone ステートメントを用いたサービスの中に呼び出されます:
zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "example.com.rr.zone";
  allow-update { none; };
};
There is very little difference between this example and a standard zone statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by .in-addr.arpa. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.

11.2.3. rndc ユーティリティの使用法

rndc ユーティリティは、named サービスをローカルおよびリモートマシンから管理できるコマンドラインツールです。以下のように使用します:
rndc [option...] command [command-option]

11.2.3.1. ユーティリティの設定法

To prevent unauthorized access to the service, named must be configured to listen on the selected port (that is, 953 by default), and an identical key must be used by both the service and the rndc utility.
表11.7 関連ファイル
パス 説明
/etc/named.conf named サービスのデフォルトの設定ファイルです。
/etc/rndc.conf rndc ユーティリティのデフォルトの設定ファイルです。
/etc/rndc.key キーのデフォルトの場所です。

The rndc configuration is located in /etc/rndc.conf. If the file does not exist, the utility will use the key located in /etc/rndc.key, which was generated automatically during the installation process using the rndc-confgen -a command.
The named service is configured using the controls statement in the /etc/named.conf configuration file as described in 「他のステートメント形式」. Unless this statement is present, only the connections from the loopback address (that is, 127.0.0.1) will be allowed, and the key located in /etc/rndc.key will be used.
For more information on this topic, refer to manual pages and the BIND 9 Administrator Reference Manual listed in 「その他のリソース」.

正しいパーミッションを設定します

権限のないユーザーがサービスに制御コマンドを送るのを防ぐには、確実に root のみが /etc/rndc.key ファイルを読み込めるようにします。
~]# chmod o-rwx /etc/rndc.key

11.2.3.2. サービスの状態の確認法

To check the current status of the named service, use the following command:
~]# rndc status
version: 9.7.0-P2-RedHat-9.7.0-5.P2.el6
CPUs found: 1
worker threads: 1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

11.2.3.3. Reloading the Configuration and Zones

To reload both the configuration file and zones, type the following at a shell prompt:
~]# rndc reload
server reload successful
This will reload the zones while keeping all previously cached responses, so that you can make changes to the zone files without losing all stored name resolutions.
To reload a single zone, specify its name after the reload command, for example:
~]# rndc reload localhost
zone reload up-to-date
Finally, to reload the configuration file and newly added zones only, type:
~]# rndc reconfig

ダイナミック DNS を用いたゾーンの編集

ダイナミック DNS (DDNS: Dynamic DNS) を使用するゾーンを手動で編集したければ、まず freeze コマンドを必ず実行してください:
~]# rndc freeze localhost
完了すると、再び DDNS を許可するために thaw コマンドを実行して、ゾーンを再読み込みします:
~]# rndc thaw localhost
The zone reload and thaw was successful.

11.2.3.4. ゾーンキーの更新

DNSSEC キーを更新して、ゾーンを署名するには、sign コマンドを使用します。たとえば:
~]# rndc sign localhost
上のコマンドを用いてゾーンを署名するには、auto-dnssec オプションが zone ステートメントにおいて maintain に設定されていなければいけないことに注意してください。たとえば:
zone "localhost" IN {
  type master;
  file "named.localhost";
  allow-update { none; };
  auto-dnssec maintain;
};

11.2.3.5. DNSSEC 検証の有効化

DNSSEC 検証を有効にするには、シェルプロンプトにおいて以下のように入力します:
~]# rndc validation on
同様に、このオプションを無効にするには、次のように入力します:
~]# rndc validation off
/etc/named.conf においてこのオプションを設定する方法についてはoptions statement described in 「一般的なステートメントのタイプ」を参照してください。

11.2.3.6. クエリーロギングの有効化

クエリーロギングを有効(または現在有効な場合に無効)にするには、以下のコマンドを実行します:
~]# rndc querylog
現在の設定を確認するには、「サービスの状態の確認法」 で説明されているように status コマンドを使用します。

11.2.4. dig ユーティリティの使用

dig ユーティリティは、DNS 検索の実行およびネームサーバーの設定のデバッグを実行できるようにするコマンドラインツールです。その典型的な使用方法は以下のとおりです:
dig [@server] [option...] name type
一般的な type の一覧は「Common Resource Records」を参照してください。

11.2.4.1. ネームサーバーの検索

特定のドメインに対するネームサーバーを検索するには、以下の形式でコマンドを使用します:
dig name NS
例11.16「ネームサーバーの検索例」において、dig ユーティリティが example.com のネームサーバーを表示するために使用されます。
例11.16 ネームサーバーの検索例
~]$ dig example.com NS

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57883
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            99374   IN      NS      a.iana-servers.net.
example.com.            99374   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:04:06 2010
;; MSG SIZE  rcvd: 77

11.2.4.2. IP アドレスの検索

特定のドメインに割り当てられた IP アドレスを検索するには、以下の形式でコマンドを使用します:
dig name A
例11.17「IP アドレスの検索例」において、dig ユーティリティが example.com の IP アドレスを表示するために使用されます。
例11.17 IP アドレスの検索例
~]$ dig example.com A

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4849
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            155606  IN      A       192.0.32.10

;; AUTHORITY SECTION:
example.com.            99175   IN      NS      a.iana-servers.net.
example.com.            99175   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:07:25 2010
;; MSG SIZE  rcvd: 93

11.2.4.3. ホスト名の検索

特定の IP アドレスに対するホスト名を検索するには、以下の形式でコマンドを使用します:
dig -x address
例11.18「ホスト名の検索例」において、dig ユーティリティが 192.0.32.10 に割り当てられたホスト名を表示するために使用されます。
例11.18 ホスト名の検索例
~]$ dig -x 192.0.32.10

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> -x 192.0.32.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29683
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6

;; QUESTION SECTION:
;10.32.0.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
10.32.0.192.in-addr.arpa. 21600 IN      PTR     www.example.com.

;; AUTHORITY SECTION:
32.0.192.in-addr.arpa.  21600   IN      NS      b.iana-servers.org.
32.0.192.in-addr.arpa.  21600   IN      NS      c.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      d.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      ns.icann.org.
32.0.192.in-addr.arpa.  21600   IN      NS      a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     13688   IN      A       192.0.34.43
b.iana-servers.org.     5844    IN      A       193.0.0.236
b.iana-servers.org.     5844    IN      AAAA    2001:610:240:2::c100:ec
c.iana-servers.net.     12173   IN      A       139.91.1.10
c.iana-servers.net.     12173   IN      AAAA    2001:648:2c30::1:10
ns.icann.org.           12884   IN      A       192.0.34.126

;; Query time: 156 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:25:15 2010
;; MSG SIZE  rcvd: 310

11.2.5. BIND の高度な機能

Most BIND implementations only use the named service to provide name resolution services or to act as an authority for a particular domain. However, BIND version 9 has a number of advanced features that allow for a more secure and efficient DNS service.

Make sure the feature is supported

Before attempting to use advanced features like DNSSEC, TSIG, or IXFR, make sure that the particular feature is supported by all nameservers in the network environment, especially when you use older versions of BIND or non-BIND servers.
All of the features mentioned are discussed in greater detail in the BIND 9 Administrator Reference Manual referenced in 「インストールされているドキュメント」.

11.2.5.1. 複数ビュー

Optionally, different information can be presented to a client depending on the network a request originates from. This is primarily used to deny sensitive DNS entries from clients outside of the local network, while allowing queries from clients inside the local network.
To configure multiple views, add the view statement to the /etc/named.conf configuration file. Use the match-clients option to match IP addresses or entire networks and give them special options and zone data.

11.2.5.2. Incremental Zone Transfers (IXFR)

Incremental Zone Transfers (IXFR) allow a secondary nameserver to only download the updated portions of a zone modified on a primary nameserver. Compared to the standard transfer process, this makes the notification and update process much more efficient.
Note that IXFR is only available when using dynamic updating to make changes to master zone records. If manually editing zone files to make changes, Automatic Zone Transfer (AXFR) is used.

11.2.5.3. Transaction SIGnatures (TSIG)

Transaction SIGnatures (TSIG) ensure that a shared secret key exists on both primary and secondary nameserver before allowing a transfer. This strengthens the standard IP address-based method of transfer authorization, since attackers would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.
Since version 9, BIND also supports TKEY, which is another shared secret key method of authorizing zone transfers.

Secure the transfer

When communicating over an insecure network, do not rely on IP address-based authentication only.

11.2.5.4. DNS Security Extensions (DNSSEC)

Domain Name System Security Extensions (DNSSEC) provide origin authentication of DNS data, authenticated denial of existence, and data integrity. When a particular domain is marked as secure, the SERFVAIL response is returned for each resource record that fails the validation.
Note that to debug a DNSSEC-signed domain or a DNSSEC-aware resolver, you can use the dig utility as described in 「dig ユーティリティの使用」. Useful options are +dnssec (requests DNSSEC-related resource records by setting the DNSSEC OK bit), +cd (tells recursive nameserver not to validate the response), and +bufsize=512 (changes the packet size to 512B to get through some firewalls).

11.2.5.5. Internet Protocol version 6 (IPv6)

Internet Protocol version 6 (IPv6) is supported through the use of AAAA resource records, and the listen-on-v6 directive as described in 表11.3「一般的に使用されるオプション」.

11.2.6. よくある間違いを避けるために

The following is a list of advices how to avoid common mistakes users make when configuring a nameserver:
Use semicolons and curly brackets correctly
An omitted semicolon or unmatched curly bracket in the /etc/named.conf file can prevent the named service from starting.
Use period (that is, the . character) correctly
In zone files, a period at the end of a domain name denotes a fully qualified domain name. If omitted, the named service will append the name of the zone or the value of $ORIGIN to complete it.
Increment the serial number when editing a zone file
If the serial number is not incremented, the primary nameserver will have the correct, new information, but the secondary nameservers will never be notified of the change, and will not attempt to refresh their data of that zone.
Configure the firewall
If a firewall is blocking connections from the named service to other nameservers, the recommended best practice is to change the firewall settings whenever possible.

Avoid using fixed UDP source ports

According to the recent research in DNS security, using a fixed UDP source port for DNS queries is a potential security vulnerability that could allow an attacker to conduct cache-poisoning attacks more easily. To prevent this, configure your firewall to allow queries from a random UDP source port.

11.2.7. その他のリソース

以下の情報源は、 BIND に関する追加情報を提供します。

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

BIND features a full range of installed documentation covering many different topics, each placed in its own subject directory. For each item below, replace version with the version of the bind package installed on the system:
/usr/share/doc/bind-version/
メインディレクトリに最新のドキュメントがあります。
/usr/share/doc/bind-version/arm/
The directory containing the BIND 9 Administrator Reference Manual in HTML and SGML formats, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start.
/usr/share/doc/bind-version/draft/
The directory containing assorted technical documents that review issues related to the DNS service, and propose some methods to address them.
/usr/share/doc/bind-version/misc/
The directory designed to address specific advanced issues. Users of BIND version 8 should consult the migration document for specific changes they must make when moving to BIND 9. The options file lists all of the options implemented in BIND 9 that are used in /etc/named.conf.
/usr/share/doc/bind-version/rfc/
The directory providing every RFC document related to BIND.
There is also a number of man pages for the various applications and configuration files involved with BIND:
man rndc
The manual page for rndc containing the full documentation on its usage.
man named
The manual page for named containing the documentation on assorted arguments that can be used to control the BIND nameserver daemon.
man lwresd
The manual page for lwresd containing the full documentation on the lightweight resolver daemon and its usage.
man named.conf
The manual page with a comprehensive list of options available within the named configuration file.
man rndc.conf
The manual page with a comprehensive list of options available within the rndc configuration file.

11.2.7.2. 役に立つ Web サイト

http://www.isc.org/software/bind
The home page of the BIND project containing information about current releases as well as a PDF version of the BIND 9 Administrator Reference Manual.

第12章 ウェブ サーバー

HTTP (ハイパーテキスト転送プロトコル)サーバー、あるいはウェブサーバーは、ウェブ経由でクライアントにコンテンツを提供するネットワークサービスです。これは通常ウェブページを意味しますが、他の文書も同様に提供することができます。

12.1. Apache HTTP サーバー

This section focuses on the Apache HTTP Server 2.2, a robust, full-featured open source web server developed by the Apache Software Foundation, that is included in Fedora 16. It describes the basic configuration of the httpd service, and covers advanced topics such as adding server modules, setting up virtual hosts, or configuring the secure HTTP server.
There are important differences between the Apache HTTP Server 2.2 and version 2.0, and if you are upgrading from a previous release of Fedora, you will need to update the httpd service configuration accordingly. This section reviews some of the newly added features, outlines important changes, and guides you through the update of older configuration files.

12.1.1. 新機能

Apache HTTP Server バージョン 2.2 は以下の機能拡張をしています:
  • つまり、改良されたキャッシュモジュール mod_cache および mod_disk_cache
  • つまり、プロキシ負荷分散のサポート mod_proxy_balancer モジュール。
  • 32ビットアーキテクチャーにおける大容量ファイルのサポート、ウェブサーバーが2GBより大きなファイルを取り扱えます。
  • 認証モジュールを置き換える、認証と認可のサポートの新しい構成は、前のバージョンで提供されました。

12.1.2. 注目すべき変更

2.0 以降、デフォルトの httpd サービス設定にいくつかの変更がありました:
  • 以下のモジュールはもはやデフォルトで読み込まれません: mod_cern_meta および mod_asis
  • 以下のモジュールは新しくデフォルトで読み込まれます: mod_ext_filter

12.1.3. 設定の更新

To update the configuration files from the Apache HTTP Server version 2.0, take the following steps:
  1. Make sure all module names are correct, since they may have changed. Adjust the LoadModule directive for each module that has been renamed.
  2. Recompile all third party modules before attempting to load them. This typically means authentication and authorization modules.
  3. もし mod_userdir モジュールを使用するならば、ディレクトリ名(一般的に public_html)を指示する UserDir ディレクティブを確実に提供してください。
  4. If you use the Apache HTTP Secure Server, edit the /etc/httpd/conf.d/ssl.conf to enable the Secure Sockets Layer (SSL) protocol.
Note that you can check the configuration for possible errors by using the following command:
service httpd configtest
For more information on upgrading the Apache HTTP Server configuration from version 2.0 to 2.2, refer to http://httpd.apache.org/docs/2.2/upgrading.html.

12.1.4. httpd サービスの実行方法

This section describes how to start, stop, restart, and check the current status of the Apache HTTP Server. To be able to use the httpd service, make sure you have the httpd installed. You can do so by using the following command as root:
yum install httpd
For more information on the concept of runlevels and how to manage system services in Fedora in general, refer to 7章サービスおよびデーモン.

12.1.4.1. サービスの開始

To run the httpd service, type the following at a shell prompt as root:
systemctl start httpd.service
If you want the service to start automatically at the boot time, use the following command:
systemctl enable httpd.service
Refer to 7章サービスおよびデーモン for more information on how to configure services in Fedora.

Using the secure server

If running the Apache HTTP Server as a secure server, a password may be required after the machine boots if using an encrypted private SSL key.

12.1.4.2. さービスの停止

To stop the running httpd service, type the following at a shell prompt as root:
systemctl stop httpd.service
To prevent the service from starting automatically at the boot time, type:
systemctl disable httpd.service
Refer to 7章サービスおよびデーモン for more information on how to configure services in Fedora.

12.1.4.3. サービスの再開

There are two different ways to restart the running httpd service:
  1. To restart the service completely, type the following at a shell prompt as root:
    systemctl restart httpd.service
    This will stop the running httpd service, and then start it again. Use this command after installing or removing a dynamically loaded module such as PHP.
  2. To only reload the configuration, as root, type:
    systemctl reload httpd.service
    This will cause the running httpd service to reload the configuration file. Note that any requests being currently processed will be interrupted, which may cause a client browser to display an error message or render a partial page.
  3. To reload the configuration without affecting active requests, run the following command as root:
    service httpd graceful
    This will cause the running httpd service to reload the configuration file. Note that any requests being currently processed will use the old configuration.
Refer to 7章サービスおよびデーモン for more information on how to configure services in Fedora.

12.1.4.4. サービスの状態確認

To check whether the service is running, type the following at a shell prompt:
systemctl is-active httpd.service
Refer to 7章サービスおよびデーモン for more information on how to configure services in Fedora.

12.1.5. 設定ファイルの編集

When the httpd service is started, by default, it reads the configuration from locations that are listed in 表12.1「httpd サービス設定ファイル」.
表12.1 httpd サービス設定ファイル
パス 説明
/etc/httpd/conf/httpd.conf 中心となる設定ファイルです。
/etc/httpd/conf.d/ An auxiliary directory for configuration files that are included in the main configuration file.

Although the default configuration should be suitable for most situations, it is a good idea to become at least familiar with some of the more important configuration options. Note that for any changes to take effect, the web server has to be restarted first. Refer to 「サービスの再開」 for more information on how to restart the httpd service.
To check the configuration for possible errors, type the following at a shell prompt:
service httpd configtest
To make the recovery from mistakes easier, it is recommended that you make a copy of the original file before editing it.

12.1.5.1. 一般的な httpd.conf ディレクティブ

The following directives are commonly used in the /etc/httpd/conf/httpd.conf configuration file:
<Directory>
The <Directory> directive allows you to apply certain directives to a particular directory only. It takes the following form:
<Directory directory>
  directive
  …
</Directory>
directory は、ローカルファイルシステムにある既存のディレクトリへの完全パス、またはワイルドカード表現のどちらかです。
This directive can be used to configure additional cgi-bin directories for server-side scripts located outside the directory that is specified by ScriptAlias. In this case, the ExecCGI and AddHandler directives must be supplied, and the permissions on the target directory must be set correctly (that is, 0755).
例12.1 <Directory> ディレクティブの使用法
<Directory /var/www/html>
  Options Indexes FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

<IfDefine>
IfDefine ディレクティブは特定のディレクティブを特定のパラメーターがコマンドラインにおいて与えられているときのみ適用します。以下の形式を使用します:
<IfDefine [!]parameter>
  directive
  …
</IfDefine>
The parameter can be supplied at a shell prompt using the -Dparameter command line option (for example, httpd -DEnableHome). If the optional exclamation mark (that is, !) is present, the enclosed directives are used only when the parameter is not specified.
例12.2 <IfDefine> ディレクティブの使用法
<IfDefine EnableHome>
  UserDir public_html
</IfDefine>

<IfModule>
<IfModule> ディレクティブは特定のディレクティブを特定のモジュールがロードされているときのみ適用できます。以下の形式を使用します:
<IfModule [!]module>
  directive
  …
</IfModule>
The module can be identified either by its name, or by the file name. If the optional exclamation mark (that is, !) is present, the enclosed directives are used only when the module is not loaded.
例12.3 <IfModule> ディレクティブの使用法
<IfModule mod_disk_cache.c>
  CacheEnable disk /
  CacheRoot /var/cache/mod_proxy
</IfModule>

<Location>
<Location> ディレクティブは特定のディレクティブを特定の URL のみに適用できます。以下の形式を使用します:
<Location url>
  directive
  …
</Location>
url は、DocumentRoot ディレクティブに指定されたディレクトリの相対パス(たとえば、/server-info)、または http://example.com/server-info のような外部 URL が使用できます。
例12.4 <Location> ディレクティブの使用法
<Location /server-info>
  SetHandler server-info
  Order deny,allow
  Deny from all
  Allow from .example.com
</Location>

<Proxy>
<Proxy> ディレクティブは特定のディレクティブをプロキシサーバーのみに適用できます。以下の形式を使用します:
<Proxy pattern>
  directive
  …
</Proxy>
pattern は外部 URL またはワイルドカード表現(たとえば、http://example.com/*)を使用できます。
例12.5 <Proxy> ディレクティブの使用法
<Proxy *>
  Order deny,allow
  Deny from all
  Allow from .example.com
</Proxy>

<VirtualHost>
<VirtualHost> ディレクティブは特定のディレクティブを特定の仮想ホストのみに適用できます。以下の形式を使用します:
<VirtualHost address[:port]…>
  directive
  …
</VirtualHost>
address は IP アドレス、完全修飾ドメイン名、および表12.2「利用可能な <VirtualHost> オプション」に記載されている特別な形式を使用できます。
表12.2 利用可能な <VirtualHost> オプション
オプション 説明
* すべての IP アドレスを表します。
_default_ 一致しない IP アドレスを表します。

例12.6 <VirtualHost> ディレクティブの使用法
<VirtualHost *:80>
  ServerAdmin webmaster@penguin.example.com
  DocumentRoot /www/docs/penguin.example.com
  ServerName penguin.example.com
  ErrorLog logs/penguin.example.com-error_log
  CustomLog logs/penguin.example.com-access_log common
</VirtualHost>

AccessFileName
The AccessFileName directive allows you to specify the file to be used to customize access control information for each directory. It takes the following form:
AccessFileName filename
filename は要求されたディレクトリにおいて探すファイルの名前です。デフォルトで、サーバーは .htaccess を探します。
セキュリティの理由から、.ht から始まるファイルはウェブクライアントによりアクセスできないよう、ディレクティブが一般的に Files タグにより制限されます。これには、.htaccess および .htpasswd ファイルが含まれます。
例12.7 AccessFileName ディレクティブの使用法
AccessFileName .htaccess

<Files ~ "^\.ht">
  Order allow,deny
  Deny from all
  Satisfy All
</Files>

Action
Action ディレクティブは、特定のメディア形式が要求されたときに実行される CGI スクリプトを指定できます。これは以下の形式をとります:
Action content-type path
The content-type has to be a valid MIME type such as text/html, image/png, or application/pdf. The path refers to an existing CGI script, and must be relative to the directory specified by the DocumentRoot directive (for example, /cgi-bin/process-image.cgi).
例12.8 Action ディレクティブの使用法
Action image/png /cgi-bin/process-image.cgi

AddDescription
The AddDescription directive allows you to specify a short description to be displayed in server-generated directory listings for a given file. It takes the following form:
AddDescription "description" filename
The description should be a short text enclosed in double quotes (that is, "). The filename can be a full file name, a file extension, or a wildcard expression.
例12.9 AddDescription ディレクティブの使用法
AddDescription "GZIP compressed tar archive" .tgz

AddEncoding
The AddEncoding directive allows you to specify an encoding type for a particular file extension. It takes the following form:
AddEncoding encoding extension
The encoding has to be a valid MIME encoding such as x-compress, x-gzip, etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .gz).
This directive is typically used to instruct web browsers to decompress certain file types as they are downloaded.
例12.10 AddEncoding ディレクティブの使用法
AddEncoding x-gzip .gz .tgz

AddHandler
The AddHandler directive allows you to map certain file extensions to a selected handler. It takes the following form:
AddHandler handler extension
The handler has to be a name of previously defined handler. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cgi).
This directive is typically used to treat files with the .cgi extension as CGI scripts regardless of the directory they are in. Additionally, it is also commonly used to process server-parsed HTML and image-map files.
例12.11 AddHandler オプションの使用法
AddHandler cgi-script .cgi

AddIcon
The AddIcon directive allows you to specify an icon to be displayed for a particular file in server-generated directory listings. It takes the following form:
AddIcon path pattern
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/folder.png). The pattern can be a file name, a file extension, a wildcard expression, or a special form as described in the following table:
表12.3 利用可能な AddIcon オプション
オプション 説明
^^DIRECTORY^^ ディレクトリを意味します。
^^BLANKICON^^ 空行を意味します。

例12.12 AddIcon ディレクティブの使用法
AddIcon /icons/text.png .txt README

AddIconByEncoding
The AddIconByEncoding directive allows you to specify an icon to be displayed for a particular encoding type in server-generated directory listings. It takes the following form:
AddIconByEncoding path encoding
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/compressed.png). The encoding has to be a valid MIME encoding such as x-compress, x-gzip, etc.
例12.13 AddIconByEncoding ディレクティブの使用法
AddIconByEncoding /icons/compressed.png x-compress x-gzip

AddIconByType
The AddIconByType directive allows you to specify an icon to be displayed for a particular media type in server-generated directory listings. It takes the following form:
AddIconByType path content-type
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/text.png). The content-type has to be either a valid MIME type (for example, text/html or image/png), or a wildcard expression such as text/*, image/*, etc.
例12.14 AddIconByType ディレクティブの使用法
AddIconByType /icons/video.png video/*

AddLanguage
The AddLanguage directive allows you to associate a file extension with a specific language. It takes the following form:
AddLanguage language extension
The language has to be a valid MIME language such as cs, en, or fr. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs).
This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings.
例12.15 AddLanguage ディレクティブの使用法
AddLanguage cs .cs .cz

AddType
The AddType directive allows you to define or override the media type for a particular file extension. It takes the following form:
AddType content-type extension
The content-type has to be a valid MIME type such as text/html, image/png, etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs).
例12.16 AddType ディレクティブの使用法
AddType application/x-gzip .gz .tgz

Alias
The Alias directive allows you to refer to files and directories outside the default directory specified by the DocumentRoot directive. It takes the following form:
Alias url-path real-path
The url-path must be relative to the directory specified by the DocumentRoot directive (for example, /images/). The real-path is a full path to a file or directory in the local file system.
This directive is typically followed by the Directory tag with additional permissions to access the target directory. By default, the /icons/ alias is created so that the icons from /var/www/icons/ are displayed in server-generated directory listings.
例12.17 Alias ディレクティブの使用法
Alias /icons/ /var/www/icons/

<Directory "/var/www/icons">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
<Directory>

Allow
The Allow directive allows you to specify which clients have permission to access a given directory. It takes the following form:
Allow from client
The client can be a domain name, an IP address (both full and partial), a network/netmask pair, or all for all clients.
例12.18 Allow ディレクティブの使用法
Allow from 192.168.1.0/255.255.255.0

AllowOverride
The AllowOverride directive allows you to specify which directives in a .htaccess file can override the default configuration. It takes the following form:
AllowOverride type
The type has to be one of the available grouping options as described in 表12.4「利用可能な AllowOverride オプション」.
表12.4 利用可能な AllowOverride オプション
オプション 説明
All .htaccess にあるすべてのディレクティブが前の設定を上書きできます。
None .htaccess にあるすべてのディレクティブが前の設定を上書きできません。
AuthConfig AuthName, AuthType, または Require のような認可のディレクティブの使用を許可します。
FileInfo Allows the use of file type, metadata, and mod_rewrite directives such as DefaultType, RequestHeader, or RewriteEngine, as well as the Action directive.
Indexes Allows the use of directory indexing directives such as AddDescription, AddIcon, or FancyIndexing.
Limit Allows the use of host access directives, that is, Allow, Deny, and Order.
Options[=option,…] Allows the use of the Options directive. Additionally, you can provide a comma-separated list of options to customize which options can be set using this directive.

例12.19 AllowOverride ディレクティブの使用法
AllowOverride FileInfo AuthConfig Limit

BrowserMatch
The BrowserMatch directive allows you to modify the server behavior based on the client's web browser type. It takes the following form:
BrowserMatch pattern variable
The pattern is a regular expression to match the User-Agent HTTP header field. The variable is an environment variable that is set when the header field matches the pattern.
By default, this directive is used to deny connections to specific browsers with known issues, and to disable keepalives and HTTP header flushes for browsers that are known to have problems with these actions.
例12.20 BrowserMatch ディレクティブの使用法
BrowserMatch "Mozilla/2" nokeepalive

CacheDefaultExpire
The CacheDefaultExpire option allows you to set how long to cache a document that does not have any expiration date or the date of its last modification specified. It takes the following form:
CacheDefaultExpire time
The time is specified in seconds. The default option is 3600 (that is, one hour).
例12.21 CacheDefaultExpire ディレクティブの使用法
CacheDefaultExpire 3600

CacheDisable
The CacheDisable directive allows you to disable caching of certain URLs. It takes the following form:
CacheDisable path
The path must be relative to the directory specified by the DocumentRoot directive (for example, /files/).
例12.22 CacheDisable ディレクティブの使用法
CacheDisable /temporary

CacheEnable
The CacheEnable directive allows you to specify a cache type to be used for certain URLs. It takes the following form:
CacheEnable type url
The type has to be a valid cache type as described in 表12.5「利用できるキャッシュの種類」. The url can be a path relative to the directory specified by the DocumentRoot directive (for example, /images/), a protocol (for example, ftp://), or an external URL such as http://example.com/.
表12.5 利用できるキャッシュの種類
形式 説明
mem メモリーベースのストレージマネージャーです。
disk ディスクベースのストレージマネージャーです。
fd ファイル記述子のキャッシュです。

例12.23 CacheEnable ディレクティブの使用法
CacheEnable disk /

CacheLastModifiedFactor
The CacheLastModifiedFactor directive allows you to customize how long to cache a document that does not have any expiration date specified, but that provides information about the date of its last modification. It takes the following form:
CacheLastModifiedFactor number
The number is a coefficient to be used to multiply the time that passed since the last modification of the document. The default option is 0.1 (that is, one tenth).
例12.24 CacheLastModifiedFactor ディレクティブの使用法
CacheLastModifiedFactor 0.1

CacheMaxExpire
The CacheMaxExpire directive allows you to specify the maximum amount of time to cache a document. It takes the following form:
CacheMaxExpire time
The time is specified in seconds. The default option is 86400 (that is, one day).
例12.25 CacheMaxExpire ディレクティブの使用法
CacheMaxExpire 86400

CacheNegotiatedDocs
The CacheNegotiatedDocs directive allows you to enable caching of the documents that were negotiated on the basis of content. It takes the following form:
CacheNegotiatedDocs option
The option has to be a valid keyword as described in 表12.6「利用可能な CacheNegotiatedDocs オプション」. Since the content-negotiated documents may change over time or because of the input from the requester, the default option is Off.
表12.6 利用可能な CacheNegotiatedDocs オプション
オプション 説明
On Enables caching the content-negotiated documents.
Off Disables caching the content-negotiated documents.

例12.26 CacheNegotiatedDocs ディレクティブの使用法
CacheNegotiatedDocs On

CacheRoot
The CacheRoot directive allows you to specify the directory to store cache files in. It takes the following form:
CacheRoot directory
The directory must be a full path to an existing directory in the local file system. The default option is /var/cache/mod_proxy/.
例12.27 CacheRoot ディレクティブの使用法
CacheRoot /var/cache/mod_proxy

CustomLog
The CustomLog directive allows you to specify the log file name and the log file format. It takes the following form:
CustomLog path format
The path refers to a log file, and must be relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The format has to be either an explicit format string, or a format name that was previously defined using the LogFormat directive.
例12.28 CustomLog ディレクティブの使用法
CustomLog logs/access_log combined

DefaultIcon
The DefaultIcon directive allows you to specify an icon to be displayed for a file in server-generated directory listings when no other icon is associated with it. It takes the following form:
DefaultIcon path
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/unknown.png).
例12.29 DefaultIcon ディレクティブの使用法
DefaultIcon /icons/unknown.png

DefaultType
The DefaultType directive allows you to specify a media type to be used in case the proper MIME type cannot be determined by the server. It takes the following form:
DefaultType content-type
The content-type has to be a valid MIME type such as text/html, image/png, application/pdf, etc.
例12.30 DefaultType ディレクティブの使用法
DefaultType text/plain

Deny
The Deny directive allows you to specify which clients are denied access to a given directory. It takes the following form:
Deny from client
The client can be a domain name, an IP address (both full and partial), a network/netmask pair, or all for all clients.
例12.31 Deny ディレクティブの使用法
Deny from 192.168.1.1

DirectoryIndex
The DirectoryIndex directive allows you to specify a document to be served to a client when a directory is requested (that is, when the URL ends with the / character). It takes the following form:
DirectoryIndex filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for index.html, and index.html.var.
例12.32 DirectoryIndex ディレクティブの使用法
DirectoryIndex index.html index.html.var

DocumentRoot
The DocumentRoot directive allows you to specify the main directory from which the content is served. It takes the following form:
DocumentRoot directory
directory はローカルのファイルシステムに存在するディレクトリーへのフルパスでなければなりません。オプションの初期値は /var/www/html/ です。
例12.33 DocumentRoot ディレクティブの使用法
DocumentRoot /var/www/html

ErrorDocument
The ErrorDocument directive allows you to specify a document or a message to be displayed as a response to a particular error. It takes the following form:
ErrorDocument error-code action
The error-code has to be a valid code such as 403 (Forbidden), 404 (Not Found), or 500 (Internal Server Error). The action can be either a URL (both local and external), or a message string enclosed in double quotes (that is, ").
例12.34 ErrorDocument ディレクティブの使用法
ErrorDocument 403 "Access Denied"
ErrorDocument 404 /404-not_found.html

ErrorLog
The ErrorLog directive allows you to specify a file to which the server errors are logged. It takes the following form:
ErrorLog path
The path refers to a log file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is logs/error_log
例12.35 ErrorLog ディレクティブの使用法
ErrorLog logs/error_log

ExtendedStatus
The ExtendedStatus directive allows you to enable detailed server status information. It takes the following form:
ExtendedStatus option
The option has to be a valid keyword as described in 表12.7「利用可能な ExtendedStatus オプション」. The default option is Off.
表12.7 利用可能な ExtendedStatus オプション
オプション 説明
On Enables generating the detailed server status.
Off Disables generating the detailed server status.

例12.36 ExtendedStatus ディレクティブの使用法
ExtendedStatus On

Group
The Group directive allows you to specify the group under which the httpd service will run. It takes the following form:
Group group
The group has to be an existing UNIX group. The default option is apache.
Note that Group is no longer supported inside <VirtualHost>, and has been replaced by the SuexecUserGroup directive.
例12.37 Group ディレクティブの使用法
Group apache

HeaderName
The HeaderName directive allows you to specify a file to be prepended to the beginning of the server-generated directory listing. It takes the following form:
HeaderName filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for HEADER.html.
例12.38 HeaderName ディレクティブの使用法
HeaderName HEADER.html

HostnameLookups
The HostnameLookups directive allows you to enable automatic resolving of IP addresses. It takes the following form:
HostnameLookups option
The option has to be a valid keyword as described in 表12.8「利用可能な HostnameLookups オプション」. To conserve resources on the server, the default option is Off.
表12.8 利用可能な HostnameLookups オプション
オプション 説明
On Enables resolving the IP address for each connection so that the hostname can be logged. However, this also adds a significant processing overhead.
Double Enables performing the double-reverse DNS lookup. In comparison to the above option, this adds even more processing overhead.
Off Disables resolving the IP address for each connection.

Note that when the presence of hostnames is required in server log files, it is often possible to use one of the many log analyzer tools that perform the DNS lookups more efficiently.
例12.39 HostnameLookups ディレクティブの使用法
HostnameLookups Off

Include
The Include directive allows you to include other configuration files. It takes the following form:
Include filename
The filename can be an absolute path, a path relative to the directory specified by the ServerRoot directive, or a wildcard expression. All configuration files from the /etc/httpd/conf.d/ directory are loaded by default.
例12.40 Include ディレクティブの使用法
Include conf.d/*.conf

IndexIgnore
The IndexIgnore directive allows you to specify a list of file names to be omitted from the server-generated directory listings. It takes the following form:
IndexIgnore filename
The filename option can be either a full file name, or a wildcard expression.
例12.41 IndexIgnore ディレクティブの使用法
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

IndexOptions
The IndexOptions directive allows you to customize the behavior of server-generated directory listings. It takes the following form:
IndexOptions option
The option has to be a valid keyword as described in 表12.9「利用できるディレクトリー一覧のオプション」. The default options are Charset=UTF-8, FancyIndexing, HTMLTable, NameWidth=*, and VersionSort.
表12.9 利用できるディレクトリー一覧のオプション
オプション 説明
Charset=encoding Specifies the character set of a generated web page. The encoding has to be a valid character set such as UTF-8 or ISO-8859-2.
Type=content-type Specifies the media type of a generated web page. The content-type has to be a valid MIME type such as text/html or text/plain.
DescriptionWidth=value Specifies the width of the description column. The value can be either a number of characters, or an asterisk (that is, *) to adjust the width automatically.
FancyIndexing Enables advanced features such as different icons for certain files or possibility to re-sort a directory listing by clicking on a column header.
FolderFirst Enables listing directories first, always placing them above files.
HTMLTable ディレクトリーの一覧に HTML テーブルを使います。
IconsAreLinks リンクの代わりにアイコンを使います。
IconHeight=value Specifies an icon height. The value is a number of pixels.
IconWidth=value Specifies an icon width. The value is a number of pixels.
IgnoreCase Enables sorting files and directories in a case-sensitive manner.
IgnoreClient Disables accepting query variables from a client.
NameWidth=value Specifies the width of the file name column. The value can be either a number of characters, or an asterisk (that is, *) to adjust the width automatically.
ScanHTMLTitles Enables parsing the file for a description (that is, the title element) in case it is not provided by the AddDescription directive.
ShowForbidden Enables listing the files with otherwise restricted access.
SuppressColumnSorting 列ヘッダーをクリックすることでディレクトリーの一覧の並び替えをさせません。
SuppressDescription ファイルの説明の領域を確保しません。
SuppressHTMLPreamble Disables the use of standard HTML preamble when a file specified by the HeaderName directive is present.
SuppressIcon ディレクトリーの一覧でアイコンを使いません。
SuppressLastModified ディレクトリーの一覧で最終変更日時の項目を表示しません。
SuppressRules ディレクトリーの一覧で水平線を使いません。
SuppressSize ディレクトリーの一覧でファイル サイズを表示しません。
TrackModified Enables returning the Last-Modified and ETag values in the HTTP header.
VersionSort Enables sorting files that contain a version number in the expected manner.
XHTML 標準の HTML 3.2 の代わりに XHTML 1.0 を使います。

例12.42 IndexOptions ディレクティブの使用法
IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable Charset=UTF-8

KeepAlive
The KeepAlive directive allows you to enable persistent connections. It takes the following form:
KeepAlive option
The option has to be a valid keyword as described in 表12.10「利用可能な KeepAlive オプション」. The default option is Off.
表12.10 利用可能な KeepAlive オプション
オプション 説明
On Enables the persistent connections. In this case, the server will accept more than one request per connection.
Off キープアライブ接続を無効にします。

Note that when the persistent connections are enabled, on a busy server, the number of child processes can increase rapidly and eventually reach the maximum limit, slowing down the server significantly. To reduce the risk, it is recommended that you set KeepAliveTimeout to a low number, and monitor the /var/log/httpd/logs/error_log log file carefully.
例12.43 KeepAlive ディレクティブの使用法
KeepAlive Off

KeepAliveTimeout
The KeepAliveTimeout directive allows you to specify the amount of time to wait for another request before closing the connection. It takes the following form:
KeepAliveTimeout time
time を秒で指定します。オプションの初期値は 15 です。
例12.44 KeepAliveTimeout ディレクティブの使用法
KeepAliveTimeout 15

LanguagePriority
The LanguagePriority directive allows you to customize the precedence of languages. It takes the following form:
LanguagePriority language
languagecs, en, または fr のような有効な MIME 言語でなければいけません。
This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings.
例12.45 LanguagePriority ディレクティブの使用法
LanguagePriority sk cs en

Listen
The Listen directive allows you to specify IP addresses or ports to listen to. It takes the following form:
Listen [ip-address:]port [protocol]
The ip-address is optional and unless supplied, the server will accept incoming requests on a given port from all IP addresses. Since the protocol is determined automatically from the port number, it can be usually omitted. The default option is to listen to port 80.
Note that if the server is configured to listen to a port under 1024, only superuser will be able to start the httpd service.
例12.46 Listen ディレクティブの使用法
Listen 80

LoadModule
The LoadModule directive allows you to load a Dynamic Shared Object (DSO) module. It takes the following form:
LoadModule name path
The name has to be a valid identifier of the required module. The path refers to an existing module file, and must be relative to the directory in which the libraries are placed (that is, /usr/lib/httpd/ on 32-bit and /usr/lib64/httpd/ on 64-bit systems by default).
Apache HTTP Server の DSO サポートの詳細は「Working with Modules」を参照してください。
例12.47 LoadModule ディレクティブの使用法
LoadModule php5_module modules/libphp5.so

LogFormat
The LogFormat directive allows you to specify a log file format. It takes the following form:
LogFormat format name
The format is a string consisting of options as described in 表12.11「一般的な LogFormat オプション」. The name can be used instead of the format string in the CustomLog directive.
表12.11 一般的な LogFormat オプション
オプション 説明
%b Represents the size of the response in bytes.
%h Represents the IP address or hostname of a remote client.
%l Represents the remote log name if supplied. If not, a hyphen (that is, -) is used instead.
%r Represents the first line of the request string as it came from the browser or client.
%s Represents the status code.
%t Represents the date and time of the request.
%u If the authentication is required, it represents the remote user. If not, a hyphen (that is, -) is used instead.
%{field} Represents the content of the HTTP header field. The common options include %{Referer} (the URL of the web page that referred the client to the server) and %{User-Agent} (the type of the web browser making the request).

例12.48 LogFormat ディレクティブの使用法
LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogLevel
The LogLevel directive allows you to customize the verbosity level of the error log. It takes the following form:
LogLevel option
The option has to be a valid keyword as described in 表12.12「利用可能な LogLevel オプション」. The default option is warn.
表12.12 利用可能な LogLevel オプション
オプション 説明
emerg Only the emergency situations when the server cannot perform its work are logged.
alert All situations when an immediate action is required are logged.
crit All critical conditions are logged.
error 全エラーメッセージを記録します。
warn All warning messages are logged.
notice Even normal, but still significant situations are logged.
info Various informational messages are logged.
debug Various debugging messages are logged.

例12.49 LogLevel ディレクティブの使用法
LogLevel warn

MaxKeepAliveRequests
The MaxKeepAliveRequests directive allows you to specify the maximum number of requests for a persistent connection. It takes the following form:
MaxKeepAliveRequests number
A high number can improve the performance of the server. Note that using 0 allows unlimited number of requests. The default option is 100.
例12.50 MaxKeepAliveRequests オプションの使用法
MaxKeepAliveRequests 100

NameVirtualHost
The NameVirtualHost directive allows you to specify the IP address and port number for a name-based virtual host. It takes the following form:
NameVirtualHost ip-address[:port]
The ip-address can be either a full IP address, or an asterisk (that is, *) representing all interfaces. Note that IPv6 addresses have to be enclosed in square brackets (that is, [ and ]). The port is optional.
Name-based virtual hosting allows one Apache HTTP Server to serve different domains without using multiple IP addresses.

セキュアな HTTP 接続の使用法

名前ベースの仮想ホストは非セキュアな HTTP 接続で のみ 機能します。セキュアサーバーで仮想ホストを使用している場合は、代わりに、 IP アドレスベースの仮想ホストを使用します。
例12.51 NameVirtualHost ディレクティブの使用法
NameVirtualHost *:80

Options
The Options directive allows you to specify which server features are available in a particular directory. It takes the following form:
Options option
option表12.13「利用できるサーバーの機能」に説明されている有効なキーワードでなければいけません。
表12.13 利用できるサーバーの機能
オプション 説明
ExecCGI CGI スクリプトの実行を有効にします。
FollowSymLinks ディレクトリー内のシンボリックリンク追跡を有効にします。
Includes サーバー サイド インクルード(SSI)を有効にします。
IncludesNOEXEC サーバー サイド インクルード(SSI)を有効にしますが、コマンドの実行は許可しません。
Indexes サーバーによるディレクトリーの一覧生成を有効にします。
MultiViews Enables content-negotiated MultiViews.
SymLinksIfOwnerMatch Enables following symbolic links in the directory when both the link and the target file have the same owner.
All Enables all of the features above with the exception of MultiViews.
None 上の機能をすべて無効にします。

例12.52 Options ディレクティブの使用法
Options Indexes FollowSymLinks

Order
The Order directive allows you to specify the order in which the Allow and Deny directives are evaluated. It takes the following form:
Order option
The option has to be a valid keyword as described in 表12.14「利用可能な Order オプション」. The default option is allow,deny.
表12.14 利用可能な Order オプション
オプション 説明
allow,deny Allow ディレクティブをはじめに評価します。
deny,allow Deny ディレクティブをはじめに評価します。

例12.53 Order ディレクティブの使用法
Order allow,deny

PidFile
The PidFile directive allows you to specify a file to which the process ID (PID) of the server is stored. It takes the following form:
PidFile path
The path refers to a pid file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is run/httpd.pid.
例12.54 PidFile ディレクティブの使用法
PidFile run/httpd.pid

ProxyRequests
The ProxyRequests directive allows you to enable forward proxy requests. It takes the following form:
ProxyRequests option
The option has to be a valid keyword as described in 表12.15「利用可能な ProxyRequests オプション」. The default option is Off.
表12.15 利用可能な ProxyRequests オプション
オプション 説明
On Enables forward proxy requests.
Off Disables forward proxy requests.

例12.55 ProxyRequests ディレクティブの使用法
ProxyRequests On

ReadmeName
The ReadmeName directive allows you to specify a file to be appended to the end of the server-generated directory listing. It takes the following form:
ReadmeName filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for README.html.
例12.56 ReadmeName ディレクティブの使用法
ReadmeName README.html

Redirect
The Redirect directive allows you to redirect a client to another URL. It takes the following form:
Redirect [status] path url
The status is optional, and if provided, it has to be a valid keyword as described in 表12.16「利用可能な status オプション」. The path refers to the old location, and must be relative to the directory specified by the DocumentRoot directive (for example, /docs). The url refers to the current location of the content (for example, http://docs.example.com).
表12.16 利用可能な status オプション
Status 説明
permanent Indicates that the requested resource has been moved permanently. The 301 (Moved Permanently) status code is returned to a client.
temp Indicates that the requested resource has been moved only temporarily. The 302 (Found) status code is returned to a client.
seeother Indicates that the requested resource has been replaced. The 303 (See Other) status code is returned to a client.
gone Indicates that the requested resource has been removed permanently. The 410 (Gone) status is returned to a client.

Note that for more advanced redirection techniques, you can use the mod_rewrite module that is part of the Apache HTTP Server installation.
例12.57 Redirect ディレクティブの使用法
Redirect permanent /docs http://docs.example.com

ScriptAlias
The ScriptAlias directive allows you to specify the location of CGI scripts. It takes the following form:
ScriptAlias url-path real-path
The url-path must be relative to the directory specified by the DocumentRoot directive (for example, /cgi-bin/). The real-path is a full path to a file or directory in the local file system.
This directive is typically followed by the Directory tag with additional permissions to access the target directory. By default, the /cgi-bin/ alias is created so that the scripts located in the /var/www/cgi-bin/ are accessible.
The ScriptAlias directive is used for security reasons to prevent CGI scripts from being viewed as ordinary text documents.
例12.58 ScriptAlias ディレクティブの使用法
ScriptAlias /cgi-bin/ /var/www/cgi-bin/

<Directory "/var/www/cgi-bin">
  AllowOverride None
  Options None
  Order allow,deny
  Allow from all
</Directory>

ServerAdmin
The ServerAdmin directive allows you to specify the email address of the server administrator to be displayed in server-generated web pages. It takes the following form:
ServerAdmin email
デフォルトのオプションは root@localhost です。
This directive is commonly set to webmaster@hostname, where hostname is the address of the server. Once set, alias webmaster to the person responsible for the web server in /etc/aliases, and as superuser, run the newaliases command.
例12.59 ServerAdmin ディレクティブの使用法
ServerAdmin webmaster@penguin.example.com

ServerName
The ServerName directive allows you to specify the hostname and the port number of a web server. It takes the following form:
ServerName hostname[:port]
The hostname has to be a fully qualified domain name (FQDN) of the server. The port is optional, but when supplied, it has to match the number specified by the Listen directive.
When using this directive, make sure that the IP address and server name pair are included in the /etc/hosts file.
例12.60 ServerName ディレクティブの使用法
ServerName penguin.example.com:80

ServerRoot
The ServerRoot directive allows you to specify the directory in which the server operates. It takes the following form:
ServerRoot directory
The directory must be a full path to an existing directory in the local file system. The default option is /etc/httpd/.
例12.61 ServerRoot ディレクティブの使用法
ServerRoot /etc/httpd

ServerSignature
The ServerSignature directive allows you to enable displaying information about the server on server-generated documents. It takes the following form:
ServerSignature option
The option has to be a valid keyword as described in 表12.17「利用可能な ServerSignature オプション」. The default option is On.
表12.17 利用可能な ServerSignature オプション
オプション 説明
On Enables appending the server name and version to server-generated pages.
Off Disables appending the server name and version to server-generated pages.
EMail Enables appending the server name, version, and the email address of the system administrator as specified by the ServerAdmin directive to server-generated pages.

例12.62 ServerSignature ディレクティブの使用法
ServerSignature On

ServerTokens
The ServerTokens directive allows you to customize what information are included in the Server response header. It takes the following form:
ServerTokens option
The option has to be a valid keyword as described in 表12.18「利用可能な ServerTokens オプション」. The default option is OS.
表12.18 利用可能な ServerTokens オプション
オプション 説明
Prod 製品名のみ(つまり、Apache)を含みます。
Major 製品名およびサーバーのメジャーバージョン(たとえば、2)を含みます。
Minor 製品名およびサーバーのマイナーバージョン(たとえば、2.2)を含みます。
Min 製品名およびサーバーの最小バージョン(たとえば、2.2.15)を含みます。
OS 製品名、サーバーの最小バージョンおよび実行しているオペレーティングシステムの種類(たとえば、Red Hat)を含みます。
Full 読み込まれているモジュールと合わせて上述の情報をすべて含みます。

Note that for security reasons, it is recommended to reveal as little information about the server as possible.
例12.63 ServerTokens ディレクティブの使用法
ServerTokens Prod

SuexecUserGroup
The SuexecUserGroup directive allows you to specify the user and group under which the CGI scripts will be run. It takes the following form:
SuexecUserGroup user group
The user has to be an existing user, and the group must be a valid UNIX group.
For security reasons, the CGI scripts should not be run with root privileges. Note that in <VirtualHost>, SuexecUserGroup replaces the User and Group directives.
例12.64 SuexecUserGroup ディレクティブの使用法
SuexecUserGroup apache apache

Timeout
The Timeout directive allows you to specify the amount of time to wait for an event before closing a connection. It takes the following form:
Timeout time
The time is specified in seconds. The default option is 60.
例12.65 Timeout ディレクティブの使用法
Timeout 60

TypesConfig
The TypesConfig allows you to specify the location of the MIME types configuration file. It takes the following form:
TypesConfig path
The path refers to an existing MIME types configuration file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is /etc/mime.types.
Note that instead of editing /etc/mime.types, the recommended way to add MIME type mapping to the Apache HTTP Server is to use the AddType directive.
例12.66 TypesConfig ディレクティブの使用法
TypesConfig /etc/mime.types

UseCanonicalName
The UseCanonicalName allows you to specify the way the server refers to itself. It takes the following form:
UseCanonicalName option
The option has to be a valid keyword as described in 表12.19「利用可能な UseCanonicalName オプション」. The default option is Off.
表12.19 利用可能な UseCanonicalName オプション
オプション 説明
On Enables the use of the name that is specified by the ServerName directive.
Off Disables the use of the name that is specified by the ServerName directive. The hostname and port number provided by the requesting client are used instead.
DNS Disables the use of the name that is specified by the ServerName directive. The hostname determined by a reverse DNS lookup is used instead.

例12.67 UseCanonicalName ディレクティブの使用法
UseCanonicalName Off

User
The User directive allows you to specify the user under which the httpd service will run. It takes the following form:
User user
user は既存の UNIX ユーザーでなければいけません。デフォルトのオプションは apache です。
For security reasons, the httpd service should not be run with root privileges. Note that User is no longer supported inside <VirtualHost>, and has been replaced by the SuexecUserGroup directive.
例12.68 User ディレクティブの使用法
User apache

UserDir
UserDir ディレクティブは、ユーザーのホームディレクトリからコンテンツの公開を取り扱えるようにします。以下の形式を利用します:
UserDir option
The option can be either a name of the directory to look for in user's home directory (typically public_html), or a valid keyword as described in 表12.20「利用可能な UserDir オプション」. The default option is disabled.
表12.20 利用可能な UserDir オプション
オプション 説明
enabled user Enables serving content from home directories of given users.
disabled [user] Disables serving content from home directories, either for all users, or, if a space separated list of users is supplied, for given users only.

Set the correct permissions

In order for the web server to access the content, the permissions on relevant directories and files must be set correctly. Make sure that all users are able to access the home directories, and that they can access and read the content of the directory specified by the UserDir directive. For example, to allow access to public_html/ in the home directory of user joe, type the following at a shell prompt as root:
~]# chmod a+x /home/joe/
~]# chmod a+rx /home/joe/public_html/
All files in this directory must be set accordingly.
例12.69 UserDir ディレクティブの使用法
UserDir public_html

12.1.5.2. 一般的な ssl.conf ディレクティブ

The Secure Sockets Layer (SSL) directives allow you to customize the behavior of the Apache HTTP Secure Server, and in most cases, they are configured appropriately during the installation. Be careful when changing these settings, as incorrect configuration can lead to security vulnerabilities.
The following directive is commonly used in /etc/httpd/conf.d/ssl.conf:
SetEnvIf
The SetEnvIf directive allows you to set environment variables based on the headers of incoming connections. It takes the following form:
SetEnvIf option pattern [!]variable[=value]…
The option can be either a HTTP header field, a previously defined environment variable name, or a valid keyword as described in 表12.21「利用可能な SetEnvIf オプション」. The pattern is a regular expression. The variable is an environment variable that is set when the option matches the pattern. If the optional exclamation mark (that is, !) is present, the variable is removed instead of being set.
表12.21 利用可能な SetEnvIf オプション
オプション 説明
Remote_Host クライアントのホスト名を参照します。
Remote_Addr クライアントの IP アドレスを参照します。
Server_Addr サーバーの IP アドレスを参照します。
Request_Method リクエストメソッドを参照します(たとえば、GET)。
Request_Protocol Refers to the protocol name and version (for example, HTTP/1.1).
Request_URI Refers to the requested resource.

The SetEnvIf directive is used to disable HTTP keepalives, and to allow SSL to close the connection without a closing notification from the client browser. This is necessary for certain web browsers that do not reliably shut down the SSL connection.
例12.70 SetEnvIf ディレクティブの使用法
SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

/etc/httpd/conf.d/ssl.conf ファイルが存在するには、mod_ssl がインストールされている必要があることに注意してください。SSL サーバーのインストールと設定に関する詳細は「SSL サーバーのセットアップ」を参照してください。

12.1.5.3. Common Multi-Processing Module Directives

The Multi-Processing Module (MPM) directives allow you to customize the behavior of a particular MPM specific server-pool. Since its characteristics differ depending on which MPM is used, the directives are embedded in IfModule. By default, the server-pool is defined for both the prefork and worker MPMs.
The following MPM directives are commonly used in /etc/httpd/conf/httpd.conf:
MaxClients
The MaxClients directive allows you to specify the maximum number of simultaneously connected clients to process at one time. It takes the following form:
MaxClients number
A high number can improve the performance of the server, although it is not recommended to exceed 256 when using the prefork MPM.
例12.71 MaxClients ディレクティブの使用法
MaxClients 256

MaxRequestsPerChild
The MaxRequestsPerChild directive allows you to specify the maximum number of request a child process can serve before it dies. It takes the following form:
MaxRequestsPerChild number
Setting the number to 0 allows unlimited number of requests.
The MaxRequestsPerChild directive is used to prevent long-lived processes from causing memory leaks.
例12.72 MaxRequestsPerChild ディレクティブの使用法
MaxRequestsPerChild 4000

MaxSpareServers
The MaxSpareServers directive allows you to specify the maximum number of spare child processes. It takes the following form:
MaxSpareServers number
This directive is used by the prefork MPM only.
例12.73 MaxSpareServers ディレクティブの使用法
MaxSpareServers 20

MaxSpareThreads
The MaxSpareThreads directive allows you to specify the maximum number of spare server threads. It takes the following form:
MaxSpareThreads number
The number must be greater than or equal to the sum of MinSpareThreads and ThreadsPerChild. This directive is used by the worker MPM only.
例12.74 MaxSpareThreads ディレクティブの使用法
MaxSpareThreads 75

MinSpareServers
The MinSpareServers directive allows you to specify the minimum number of spare child processes. It takes the following form:
MinSpareServers number
Note that a high number can create a heavy processing load on the server. This directive is used by the prefork MPM only.
例12.75 MinSpareServers ディレクティブの使用法
MinSpareServers 5

MinSpareThreads
The MinSpareThreads directive allows you to specify the minimum number of spare server threads. It takes the following form:
MinSpareThreads number
This directive is used by the worker MPM only.
例12.76 MinSpareThreads ディレクティブの使用法
MinSpareThreads 75

StartServers
The StartServers directive allows you to specify the number of child processes to create when the service is started. It takes the following form:
StartServers number
Since the child processes are dynamically created and terminated according to the current traffic load, it is usually not necessary to change this value.
例12.77 StartServers ディレクティブの使用法
StartServers 8

ThreadsPerChild
The ThreadsPerChild directive allows you to specify the number of threads a child process can create. It takes the following form:
ThreadsPerChild number
This directive is used by the worker MPM only.
例12.78 ThreadsPerChild ディレクティブの使用法
ThreadsPerChild 25

12.1.6. Working with Modules

Being a modular application, the httpd service is distributed along with a number of Dynamic Shared Objects (DSOs), which can be dynamically loaded or unloaded at runtime as necessary. By default, these modules are located in /usr/lib/httpd/modules/ on 32-bit and in /usr/lib64/httpd/modules/ on 64-bit systems.

12.1.6.1. モジュールの読み込み方法

To load a particular DSO module, use the LoadModule directive as described in 「一般的な httpd.conf ディレクティブ」. Note that modules provided by a separate package often have their own configuration file in the /etc/httpd/conf.d/ directory.
例12.79 mod_ssl DSO の読み込み方法
LoadModule ssl_module modules/mod_ssl.so

Once you are finished, restart the web server to reload the configuration. Refer to 「サービスの再開」 for more information on how to restart the httpd</