Product SiteDocumentation Site

Fedora 17

システム管理者ガイド

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

エディッション 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

Wadeley Stephen [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

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 © 2012 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 17 の導入、設定および管理に関連する情報をドキュメント化しています。システムの基本的な理解をしているシステム管理者向けになっています。

序文
1. 対象の読者
2. この本の読み方
3. 表記方法
3.1. 印刷における表記方法
3.2. 引用における表記方法
3.3. 注記および警告
4. フィードバック
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. NetworkManager
6.1. The NetworkManager Daemon
6.2. Interacting with NetworkManager
6.2.1. Connecting to a Network
6.2.2. Configuring New and Editing Existing Connections
6.2.3. Connecting to a Network Automatically
6.2.4. User and System Connections
6.3. Establishing Connections
6.3.1. Establishing a Wired (Ethernet) Connection
6.3.2. Establishing a Wireless Connection
6.3.3. Establishing a Mobile Broadband Connection
6.3.4. Establishing a VPN Connection
6.3.5. Establishing a DSL Connection
6.3.6. Establishing Routes
6.4. Configuring Connection Settings
6.4.1. Configuring 802.1x Security
6.4.2. Configuring Wireless Security
6.4.3. Configuring PPP (Point-to-Point) Settings
6.4.4. Configuring IPv4 Settings
6.4.5. Configuring IPv6 Settings
6.5. NetworkManager Architecture
7. ネットワーク・インターフェース
7.1. ネットワーク設定ファイル
7.2. インターフェース設定ファイル
7.2.1. イーサネット インターフェース
7.2.2. チャンネル・ボンディング・インターフェース
7.2.3. ネットワークブリッジ
7.2.4. Setting up 802.1q VLAN tagging
7.2.5. エイリアス ファイルとクローン ファイル
7.2.6. ダイヤルアップ インターフェース
7.2.7. 他のインターフェース
7.3. インターフェース制御スクリプト
7.4. スタティック ルートの設定
7.5. ネットワーク機能ファイル
7.6. その他のリソース
7.6.1. インストールされているドキュメント
IV. インフラストラクチャーサービス
8. サービスおよびデーモン
8.1. サービスの設定
8.1.1. サービスの有効化
8.1.2. サービスの無効化
8.2. サービスの実行
8.2.1. サービスの状態の確認
8.2.2. サービスの実行
8.2.3. サービスの停止
8.2.4. サービスの再起動
8.3. その他のリソース
8.3.1. インストールされているドキュメント
8.3.2. 関連書籍
9. 認証の設定
9.1. 認証の設定ツール
9.1.1. 識別と認証
9.1.2. 高度なオプション
9.1.3. コマンドライン版
9.2. The System Security Services Daemon (SSSD)
9.2.1. SSIDとは?
9.2.2. SSIDの特徴
9.2.3. Setting Up SSSD
9.2.4. サービスの設定
9.2.5. Configuring Domains
9.2.6. Setting Up Kerberos Authentication
9.2.7. Configuring a Proxy Domain
9.2.8. トラブルシューティング
9.2.9. SSSD Configuration File Format
10. OpenSSH
10.1. SSH プロトコル
10.1.1. なぜ SSH を使うのか?
10.1.2. 主な機能
10.1.3. プロトコル・バージョン
10.1.4. SSH コネクションのイベント・シーケンス
10.2. OpenSSH の設定
10.2.1. 設定ファイル
10.2.2. OpenSSH サーバーの起動
10.2.3. リモート接続に対する SSH の要求
10.2.4. キー認証の使用
10.3. OpenSSH クライアント
10.3.1. ssh ユーティリティの使用方法
10.3.2. scp ユーティリティの使用方法
10.3.3. sftp ユーティリティの使用方法
10.4. 安全なシェル以上のもの
10.4.1. X11 転送
10.4.2. ポート転送
10.5. 追加のリソース
10.5.1. インストールされているドキュメント
10.5.2. 役に立つ Web サイト
V. サーバー
11. DHCP サーバー
11.1. DHCP を使用する理由
11.2. DHCP サーバーの設定
11.2.1. 設定ファイル
11.2.2. リースデータベース
11.2.3. サーバーの起動と停止
11.2.4. DHCP リレーエージェント
11.3. DHCP クライアントの設定
11.4. Configuring a Multihomed DHCP Server
11.4.1. ホストの設定
11.5. IPv6 向け DHCP (DHCPv6)
11.6. その他のリソース
11.6.1. インストールされているドキュメント
12. DNS サーバー
12.1. DNS の概要
12.1.1. ネームサーバーゾーン
12.1.2. ネームサーバーのタイプ
12.1.3. ネームサーバーとしての BIND
12.2. BIND
12.2.1. named サービスの設定
12.2.2. ゾーンファイルの編集
12.2.3. rndc ユーティリティの使用法
12.2.4. dig ユーティリティの使用
12.2.5. BIND の高度な機能
12.2.6. よくある間違いを避けるために
12.2.7. その他のリソース
13. ウェブ サーバー
13.1. Apache HTTP サーバー
13.1.1. 新機能
13.1.2. 注目すべき変更
13.1.3. 設定の更新
13.1.4. httpd サービスの実行方法
13.1.5. 設定ファイルの編集
13.1.6. Working with Modules
13.1.7. 仮想ホストのセットアップ
13.1.8. SSL サーバーのセットアップ
13.1.9. その他のリソース
14. メールサーバー
14.1. 電子メールプロトコル
14.1.1. メール トランスポートのプロトコル
14.1.2. メール アクセスのプロトコル
14.2. 電子メールプログラム分類
14.2.1. メール転送エージェント (Mail Transport Agent)
14.2.2. メール配送エージェント (Mail Delivery Agent)
14.2.3. メール ユーザー エージェント
14.3. Mail Transport Agent
14.3.1. Postfix
14.3.2. Sendmail
14.3.3. Fetchmail
14.3.4. Mail Transport Agent (MTA) の設定
14.4. メール配送エージェント
14.4.1. Procmail の設定
14.4.2. Procmail レシピ
14.5. メールユーザーエージェント
14.5.1. 通信のセキュリティ
14.6. その他のリソース
14.6.1. インストールされているドキュメント
14.6.2. 役に立つ Web サイト
14.6.3. 関連書籍
15. ディレクトリー サーバー
15.1. OpenLDAP
15.1.1. Introduction to LDAP
15.1.2. OpenLDAP 製品群のインストール
15.1.3. OpenLDAP サーバーの設定法
15.1.4. Running an OpenLDAP Server
15.1.5. システムが OpenLDAP を使用して認証を実行するように設定する
15.1.6. その他のリソース
16. ファイルサーバーおよびプリントサーバー
16.1. Samba
16.1.1. Samba の概要
16.1.2. Samba デーモンと関連サービス
16.1.3. Samba シェアへの接続
16.1.4. Samba サーバーの設定
16.1.5. Samba の開始と停止
16.1.6. Samba サーバー形式と smb.conf ファイル
16.1.7. Samba のセキュリティモード
16.1.8. Samba のアカウント情報データベース
16.1.9. Samba ネットワークブラウジング
16.1.10. CUPS 印刷サポートを使った Samba
16.1.11. Samba ディストリビューションプログラム
16.1.12. その他のリソース
16.2. FTP
16.2.1. ファイル伝送プロトコル
16.2.2. FTP サーバー
16.2.3. Files Installed with vsftpd
16.2.4. vsftpd の開始と停止
16.2.5. vsftpd 設定オプション
16.2.6. その他のリソース
16.3. プリンタの設定
16.3.1. Starting the Printer Configuration Tool
16.3.2. Starting Printer Setup
16.3.3. ローカルプリンタの追加
16.3.4. Adding an AppSocket/HP JetDirect printer
16.3.5. IPP プリンタの追加
16.3.6. Adding an LPD/LPR Host or Printer
16.3.7. Adding a Samba (SMB) printer
16.3.8. プリンタモデルの選択と終了
16.3.9. Printing a test page
16.3.10. 既存プリンタの変更
16.3.11. その他のリソース
VI. 監視および自動化
17. システム監視ツール
17.1. Viewing System Processes
17.1.1. Using the ps Command
17.1.2. Using the top Command
17.1.3. Using the System Monitor Tool
17.2. Viewing Memory Usage
17.2.1. Using the free Command
17.2.2. Using the System Monitor Tool
17.3. Viewing CPU Usage
17.3.1. Using the System Monitor Tool
17.4. Viewing Block Devices and File Systems
17.4.1. Using the lsblk Command
17.4.2. Using the blkid Command
17.4.3. Using the partx Command
17.4.4. Using the findmnt Command
17.4.5. Using the df Command
17.4.6. Using the du Command
17.4.7. Using the System Monitor Tool
17.5. Viewing Hardware Information
17.5.1. Using the lspci Command
17.5.2. Using the lsusb Command
17.5.3. Using the lspcmcia Command
17.5.4. Using the lscpu Command
17.6. Monitoring Performance with Net-SNMP
17.6.1. Installing Net-SNMP
17.6.2. Running the Net-SNMP Daemon
17.6.3. Configuring Net-SNMP
17.6.4. Retrieving Performance Data over SNMP
17.6.5. Extending Net-SNMP
17.7. その他のリソース
17.7.1. インストールされているドキュメント
18. ログファイルの表示および管理
18.1. rsyslog の設定法
18.1.1. 全体ディレクティブ
18.1.2. モジュール
18.1.3. ルール
18.1.4. rsyslog コマンドライン設定
18.2. ログファイルを探す
18.2.1. logrotate の設定法
18.3. ログファイルの表示
18.4. ログファイルの追加
18.5. ログファイルを監視する
18.6. その他のリソース
18.6.1. インストールされているドキュメント
18.6.2. 役に立つ Web サイト
19. システムタスクの自動化
19.1. Cron および Anacron
19.1.1. サービスの起動と停止
19.1.2. Configuring Anacron Jobs
19.1.3. Configuring Cron Jobs
19.1.4. Cron へのアクセスの制御
19.1.5. Black/White Listing of Cron Jobs
19.2. at コマンドと batch コマンド
19.2.1. At ジョブの設定
19.2.2. batch ジョブの設定
19.2.3. 保留ジョブの表示
19.2.4. その他のコマンドラインオプション
19.2.5. at と batch へのアクセスの制御
19.2.6. サービスの起動と停止
19.3. その他のリソース
19.3.1. インストールされているドキュメント
20. OProfile
20.1. Overview of Tools
20.2. Configuring OProfile
20.2.1. Specifying the Kernel
20.2.2. Setting Events to Monitor
20.2.3. Separating Kernel and User-space Profiles
20.3. Starting and Stopping OProfile
20.4. Saving Data
20.5. Analyzing the Data
20.5.1. Using opreport
20.5.2. Using opreport on a Single Executable
20.5.3. Getting more detailed output on the modules
20.5.4. Using opannotate
20.6. Understanding /dev/oprofile/
20.7. 使用法の例
20.8. OProfile Support for Java
20.8.1. Profiling Java Code
20.9. Graphical Interface
20.10. OProfile and SystemTap
20.11. 追加のリソース
20.11.1. Installed Docs
20.11.2. 役に立つ Web サイト
VII. カーネル、モジュールおよびドライバーの設定
21. カーネルをアップグレードする
21.1. カーネルパッケージの概要
21.2. アップグレードの準備
21.3. アップグレードされたカーネルをダウンロードする
21.4. アップグレードの実行
21.5. 初期RAMディスクイメージの確認
21.6. ブートローダの確認
21.6.1. Configuring the GRUB 2 Boot Loader
21.6.2. Configuring the OS/400 Boot Loader
21.6.3. Configuring the YABOOT Boot Loader
22. Working with Kernel Modules
22.1. Listing Currently-Loaded Modules
22.2. Displaying Information About a Module
22.3. モジュールの読み込み方法
22.4. Unloading a Module
22.5. Setting Module Parameters
22.6. Persistent Module Loading
22.7. Specific Kernel Module Capabilities
22.7.1. 複数のイーサネットカードの使用
22.7.2. Using Channel Bonding
22.8. その他のリソース
22.8.1. インストールされているドキュメント
22.8.2. 役に立つ Web サイト
23. The kdump Crash Recovery Service
23.1. Installing the kdump Service
23.2. Configuring the kdump Service
23.2.1. Configuring the kdump at First Boot
23.2.2. Using the Kernel Dump Configuration Utility
23.2.3. Configuring kdump on the Command Line
23.2.4. Testing the Configuration
23.3. Analyzing the Core Dump
23.3.1. Running the crash Utility
23.3.2. Displaying the Message Buffer
23.3.3. Displaying a Backtrace
23.3.4. Displaying a Process Status
23.3.5. Displaying Virtual Memory Information
23.3.6. Displaying Open Files
23.3.7. Exiting the Utility
23.4. その他のリソース
23.4.1. インストールされているドキュメント
23.4.2. 役に立つ Web サイト
A. Consistent Network Device Naming
A.1. Affected Systems
A.2. システム要求
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. 設定ファイルの変更
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. sysconfig ディレクトリー
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 17 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 17 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 のネットワーク設定の仕方について記述しています。
7章ネットワーク・インターフェース 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 やサービスの設定方法についての情報を提供します。
8章サービスおよびデーモン 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.
9章認証の設定 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.
10章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「サーバー」
このパートは、ウェブサーバーを導入する、またはネットワーク上にファイルとディレクトリを共有する方法のようなサーバーに関連したさまざまな話題を説明しています。
11章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.
12章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.
13章ウェブ サーバー 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.
14章メールサーバー 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.
15章ディレクトリー サーバー 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.
16章ファイルサーバーおよびプリントサーバー 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「監視および自動化」
このパートは、システム管理者がシステムのパフォーマンスを監視する、システムタスクを自動化する、およびバグを報告することができる、さまざまなツールを説明しています。
17章システム監視ツール 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.
18章ログファイルの表示および管理 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.
19章システムタスクの自動化 provides an overview of the cron, at, and batch utilities. Read this chapter to learn how to use these utilities to perform automated tasks.
20章OProfile covers OProfile, a low overhead, system-wide performance monitoring tool. Read this chapter for information how to use OProfile on your system.
パートVII「カーネル、モジュールおよびドライバーの設定」
このパートはカーネルのカスタマイズと管理を支援するさまざまなツールをカバーします。
21章カーネルをアップグレードする 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.
22章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.
23章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 sysconfig ディレクトリー
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. フィードバック

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.
バグリポートの送信時は、必ず以下の情報を確認してください:
  • Manual's identifier: system-administrator's-guide
  • バージョン番号: 17
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 17 は地域と言語設定ツールを同梱しています。これは、キーボード配置、デスクトップ環境の言語、および他の地域の設定をできます。ツールを開始するには、アクティビティメニューからアプリケーションシステムツールシステム設定を選択することによりシステム設定ウィンドウを開き、地域と言語をクリックします。

1.1. 言語の変更

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

デフォルトで、このリストはいくつかの利用可能な言語のみを含みます。他の言語を追加するには、リストの下にある + (プラス記号) ボタンをクリックします。ダイアログウィンドウが表示され、希望する言語を選択できます。ダイアログウィンドウの下部にある入力フィールドを使用して、そこに言語名の最初の数文字を入力すると表示される言語を減らすことができるようになります(たとえば、スロバキア語には slov です)。言語を選択すると、選んだものを確認するために選択ボタンをクリックします。
他の言語の追加
Adding a language
図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 17 は日付と時刻設定ツールを同梱しています。これは、システムの日付と時刻を変更する、システムにより使用されるタイムゾーンを設定する、および時刻サーバーとシステムクロックを同期するために NTP (Network Time Protocol) デーモンをセットアップすることができます。ツールを起動するには、アクティビティメニューからアプリケーションシステムツールシステム設定を選択して日付と時刻アイコンを選択するか、ドロップダウンメニューから日付と時刻の設定を選択します。
日付と時刻の設定ツール
日付と時刻の設定ツール
図2.1 日付と時刻の設定ツール

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

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

Fedora 17 は、手動または 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
    システムサービスとそのセットアップに関する詳細は、8章サービスおよびデーモンを参照してください。

    注記

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

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

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

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

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

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

既存のグループのプロパティを表示するには、グループの一覧からグループを選択して、メニューからプロパティをクリックします(または、プルダウンメニューからファイルプロパティを選びます)。図3.9「グループのプロパティ」のようなウィンドウが表示されます。
グループのプロパティ
Modifying group properties
図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 "Fedora" > /etc/yum/vars/os名
Fedora 17 の代わりに、.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
This creates the necessary metadata for your Yum repository, as well as the sqlite database for speeding up yum operations.

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
論理ボリューム管理、Btrfs、およびファイルシステムスナップショットの詳細は Fedora 17 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 アーキテクチャーを含みます)、パッケージの概要、および一般的に更新が提供する変更の概要とともに一覧表示します。インストールしたくないすべての更新は、更新に対応するチェックボックスをチェック解除することにより、ここで選択解除できます。
ソフトウェアの更新を用いたアップデートのインストール
installing 56 updates with PackageKit's software update window
図5.1 ソフトウェアの更新を用いたアップデートのインストール

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

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

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

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

ソフトウェアの更新をインストールするために使用するパッケージリポジトリを選択するには、Activities メニューからアプリケーションその他ソフトウェアの更新を選択し、ソフトウェアの更新の設定ソフトウェアのソースをクリックします。
PackageKit のソフトウェアソースの設定
Setting the software sources for 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 のソフトウェアの追加/削除ウィンドウ
Viewing PackageKit's Add/Remove Software window
図5.4 PackageKit のソフトウェアの追加/削除ウィンドウ

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

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

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

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

また、C ヘッダーファイルのように開発版が必要でなければ、エンドユーザーのファイルのみのためにフィルターできます。そして、そうするとき、興味がない package_name-devel をすべてフィルターで消します。
検索結果の一覧からの開発パッケージのフィルター
filtering out development packages from our results
図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 のソフトウェアの追加/削除を用いたパッケージの削除
Removing the htop package with PackageKit's Add/Remove Software window
図5.8 PackageKit のソフトウェアの追加/削除を用いたパッケージの削除

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

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

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

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

PackageKit は実行したトランザクションのログ を維持します。ログを表示するには、ソフトウェアの追加/削除ウィンドウからシステムソフトウェアのログをクリックします、またはシェルプロンプトにおいて gpk-log コマンドを実行します。
ソフトウェア更新履歴ビューアーは、更新されたパッケージインストール済みパッケージ、アクションが実行された日付、アクションを実行したユーザー名、およびユーザーが使用したフロントエンドのアプリケーション(たとえば、ソフトウェアの追加/削除システムの更新)のようなアクションを表示します。詳細の列は、トランザクションが実行されたパッケージの一覧と同じように、更新インストール、または削除のような、トランザクションの種類を提供します。
ソフトウェアログビューアーを用いたパッケージ管理トランザクションのログの表示
Viewing the log of package management transactions with PackageKit's Software Log Viewer window
図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 を付け加えることにより認識できます。システムサービスに関する詳細は8章サービスおよびデーモンを参照してください。

パート III. ネットワーク

このパートは Fedora においてネットワークを設定する方法を説明しています。

第6章 NetworkManager

NetworkManager is a dynamic network control and configuration system that attempts to keep network devices and connections up and active when they are available. NetworkManager consists of a core daemon, a GNOME Notification Area applet that provides network status information, and graphical configuration tools that can create, edit and remove connections and interfaces. NetworkManager can be used to configure the following types of connections: Ethernet, wireless, mobile broadband (such as cellular 3G), and DSL and PPPoE (Point-to-Point over Ethernet). In addition, NetworkManager allows for the configuration of network aliases, static routes, DNS information and VPN connections, as well as many connection-specific parameters. Finally, NetworkManager provides a rich API via D-Bus which allows applications to query and control network configuration and state.
Previous versions of Fedora included the Network Administration Tool, which was commonly known as system-config-network after its command line invocation. In Fedora 17, NetworkManager replaces the former Network Administration Tool while providing enhanced functionality, such as user-specific and mobile broadband configuration. It is also possible to configure the network in Fedora 17 by editing interface configuration files; refer to 7章ネットワーク・インターフェース for more information.
NetworkManager may be installed by default on Fedora. To ensure that it is, first run the following command as the root user:
~]# yum install NetworkManager

6.1. The NetworkManager Daemon

The NetworkManager daemon runs with root privileges and is usually configured to start up at boot time. You can determine whether the NetworkManager daemon is running by entering this command as root:
~]# service NetworkManager status
NetworkManager (pid  1527) is running...
The service command will report NetworkManager is stopped if the NetworkManager service is not running. To start it for the current session:
~]# service NetworkManager start
Run the chkconfig command to ensure that NetworkManager starts up every time the system boots:
~]# chkconfig NetworkManager on
For more information on starting, stopping and managing services and runlevels, refer to 8章サービスおよびデーモン.

6.2. Interacting with NetworkManager

Users do not interact with the NetworkManager system service directly. Instead, you can perform network configuration tasks via NetworkManager's Notification Area applet. The applet has multiple states that serve as visual indicators for the type of connection you are currently using.
NetworkManager applet states
A row of four icons representing NetworkManager applet states
図6.1 NetworkManager applet states

If you do not see the NetworkManager applet in the GNOME panel, and assuming that the NetworkManager package is installed on your system, you can start the applet by running the following command as a normal user (not root):
~]$ nm-applet &
After running this command, the applet appears in your Notification Area.

6.2.1. Connecting to a Network

When you click on the applet icon, you are presented with:
  • a list of categorized networks you are currently connected to (such as Wired and Wireless);
  • a list of all Available Networks that NetworkManager has detected;
  • options for connecting to any configured Virtual Private Networks (VPNs); and,
  • options for connecting to hidden or new wireless networks.
If you are connected to a network, its name is presented first under its network type, such as Wired or Wireless with a bulletpoint to the left. When many networks are available, such as wireless access points, the More networks expandable menu entry appears.
The NetworkManager applet's drop-down menu, showing all available and connected-to networks
A screen shot of the NetworkManager applet's drop-down menu, showing all available and connected-to networks
図6.2 The NetworkManager applet's drop-down menu, showing all available and connected-to networks

6.2.2. Configuring New and Editing Existing Connections

Click on the NetworkManager applet to open the drop-down menu, this is the main point of entry for interacting with NetworkManager to configure connections.
If the system has detected a wired connection, the Wired menu entry will appear. If the system has detected a wireless card, then you will also see a Wireless menu entry. Clicking the Wired and Wireless labels or the associated ON OFF indicator to the right will toggle the status between ON and OFF.
Finally, clicking on the Network Settings menu entry opens the Network window, from where you can view some basic network configuration information and initiate configuration tasks.
Configure networks using the Network window
A screen shot of NetworkManager's Network window.
図6.3 Configure networks using the Network window

Then, to configure:

6.2.3. Connecting to a Network Automatically

For any connection type you add or configure, you can choose whether you want NetworkManager to try to connect to that network automatically when it is available.
手順6.1 Configuring NetworkManager to Connect to a Network Automatically When Detected
  1. Click on the NetworkManager applet icon in the Notification Area.
  2. Click Network Settings.
    The Network window appears.
  3. Select the type of connection from the left-hand-side menu.
  4. Click on Configure
  5. Select Connect automatically to cause NetworkManager to auto-connect to the connection whenever NetworkManager detects that it is available. Unselect the checkbox if you do not want NetworkManager to connect automatically. If the box is unchecked, you will have to select that connection manually in the NetworkManager applet's initial menu to cause it to connect.

6.2.4. User and System Connections

NetworkManager connections are always either user connections or system connections. Depending on the system-specific policy that the administrator has configured, users may need root privileges to create and modify system connections. NetworkManager's default policy enables users to create and modify user connections, but requires them to have root privileges to add, modify or delete system connections.
User connections are so-called because they are specific to the user who creates them. In contrast to system connections, whose configurations are stored under the /etc/sysconfig/network-scripts/ directory (mainly in ifcfg-<network_type> interface configuration files), user connection settings are stored in the GConf configuration database and the GNOME keyring, and are only available during login sessions for the user who created them. Thus, logging out of the desktop session causes user-specific connections to become unavailable.

Increase security by making VPN connections user-specific

Because NetworkManager uses the GConf and GNOME keyring applications to store user connection settings, and because these settings are specific to your desktop session, it is highly recommended to configure your personal VPN connections as user connections. If you do so, other non-root users on the system cannot view or access these connections in any way.
System connections, on the other hand, become available at boot time and can be used by other users on the system without first logging in to a desktop session.
NetworkManager can quickly and conveniently convert user to system connections and vice versa. Converting a user connection to a system connection causes NetworkManager to create the relevant interface configuration files under the /etc/sysconfig/network-scripts/ directory, and to delete the GConf settings from the user's session. Conversely, converting a system to a user-specific connection causes NetworkManager to remove the system-wide configuration files and create the corresponding GConf/GNOME keyring settings.
The Available to all users checkbox controls whether connections are user-specific or system-wide
A screen shot of the Available to all users checkbox
図6.4 The Available to all users checkbox controls whether connections are user-specific or system-wide

手順6.2 Changing a Connection to be User-Specific instead of System-Wide, or Vice-Versa

Root privileges may be required

Depending on the system's policy, you may need root privileges on the system in order to change whether a connection is user-specific or system-wide.
  1. Click on the NetworkManager applet icon in the Notification Area and click Network Settings. The Network window appears.
  2. Select the menu entry for the type of network connection you want to configure.
  3. Select the Configure button.
  4. Check the Available to all users checkbox to ask NetworkManager to make the connection a system-wide connection. Depending on system policy, you may then be prompted for the root password by the PolicyKit application. If so, enter the root password to finalize the change.
    Conversely, uncheck the Available to all users checkbox to make the connection user-specific.

6.3. Establishing Connections

6.3.1. Establishing a Wired (Ethernet) Connection

To establish a wired network connection, click on the NetworkManager applet to open its menu, then click on Network Settings. This opens the Network window.
Select the Wired menu entry and then click Configure.
Editing the newly-created Wired connection 1
A screen shot of Network Manager's Wired tab
図6.5 Editing the newly-created Wired connection 1

The system startup scripts create and configure a single wired connection called System eth0 by default on all systems. Although you can edit System eth0, creating a new wired connection for your custom settings is recommended. You can create a new wired connection by selecting the Wired tab and clicking the Add button.

The dialog for adding and editing connections is the same

When you add a new connection by clicking the Add button, NetworkManager creates a new configuration file for that connection and then opens the same dialog that is used for editing an existing connection. There is no difference between these dialogs. In effect, you are always editing a connection; the difference only lies in whether that connection previously existed or was just created by NetworkManager when you clicked Add.

Configuring the Connection Name, Auto-Connect Behavior, and Availability Settings

Three settings in the Editing dialog are common to all connection types:
  • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the Wired tab of the Network Connections window.
  • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to 「Connecting to a Network Automatically」 for more information.
  • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to 「User and System Connections」 for details.

Configuring the Wired Tab

The final two configurable settings are located within the Wired tab itself: the first is a text-entry field where you can specify a MAC (Media Access Control) address, and the second allows you to specify the MTU (Maximum Transmission Unit) value. Normally, you can leave the MAC address field blank and the MTU set to automatic. These defaults will suffice unless you are associating a wired connection with a second or specific NIC, or performing advanced networking. In such cases, refer to the following descriptions:
MAC Address
Network hardware such as a Network Interface Card (NIC) has a unique MAC address (Media Access Control; also known as a hardware address) that identifies it to the system. Running the ip addr command will show the MAC address associated with each interface. For example, in the following ip addr output, the MAC address for the eth0 interface (which is 52:54:00:26:9e:f1) immediately follows the link/ether keyword:
~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 52:54:00:26:9e:f1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.251/24 brd 192.168.122.255 scope global eth0
    inet6 fe80::5054:ff:fe26:9ef1/64 scope link
       valid_lft forever preferred_lft forever
A single system can have one or more NICs installed on it. The MAC address field therefore allows you to associate a specific NIC with a specific connection (or connections). As mentioned, you can determine the MAC address using the ip addr command, and then copy and paste that value into the MAC address text-entry field.
MTU
The MTU (Maximum Transmission Unit) value represents the size in bytes of the largest packet that the connection will use to transmit. This value defaults to 1500 when using IPv4, or a variable number 1280 or higher for IPv6, and does not generally need to be specified or changed.

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing your wired connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can connect to your new or customized connection by selecting it from the NetworkManager Notification Area applet. See 「Connecting to a Network」 for information on using your new or altered connection.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

6.3.2. Establishing a Wireless Connection

This section explains how to use NetworkManager to configure a wireless (also known as Wi-Fi or 802.1a/b/g/n) connection to an Access Point.
To configure a mobile broadband (such as 3G) connection, refer to 「Establishing a Mobile Broadband Connection」.

Quickly Connecting to an Available Access Point

The easiest way to connect to an available access point is to click on the NetworkManager applet, locate the Service Set Identifier (SSID) of the access point in the list of available networks, and click on it. If the access point is secured, a dialog prompts you for authentication.
NetworkManager tries to auto-detect the type of security used by the access point. If there are multiple possibilities, NetworkManager guesses the security type and presents it in the Wireless security dropdown menu. To see if there are multiple choices, click the Wireless security dropdown menu and select the type of security the access point is using. If you are unsure, try connecting to each type in turn. Finally, enter the key or passphrase in the Password field. Certain password types, such as a 40-bit WEP or 128-bit WPA key, are invalid unless they are of a requisite length. The Connect button will remain inactive until you enter a key of the length required for the selected security type. To learn more about wireless security, refer to 「Configuring Wireless Security」.
If NetworkManager connects to the access point successfully, its applet icon will change into a graphical indicator of the wireless connection's signal strength.
Applet icon indicating wireless connection signal strength
A screen shot of the Signal Strength Applet icon indicating wireless connection signal strength
図6.6 Applet icon indicating wireless connection signal strength

Connecting to a Hidden Wireless Network

All access points have a Service Set Identifier (SSID) to identify them. However, an access point may be configured not to broadcast its SSID, in which case it is hidden, and will not show up in NetworkManager's list of Available networks. You can still connect to a wireless access point that is hiding its SSID as long as you know its SSID, authentication method, and secrets.
To connect to a hidden wireless network, click NetworkManager's applet icon and then click Network Settings. The Network window appears. Select the Wireless menu entry and then click to the right of the Network Name to activate the drop-down list. Select Other. The Hidden wireless network dialog window appears.
Hidden wireless network dialog window
A screen shot of NetworkManager's Hidden wireless network dialog window
図6.7 Hidden wireless network dialog window

If you have connected to the hidden network before, use the Connection drop-down list to select it, and click Connect. If you have not, leave the Connection dropdown as New..., enter the SSID of the hidden network, select its Wireless security method, enter the correct authentication secrets, and click Connect.
For more information on wireless security settings, refer to 「Configuring Wireless Security」.

Editing a Connection, or Creating a Completely New One

You can create a new connection by clicking on the NetworkManager applet to open its menu.
  1. Click on the NetworkManager applet icon in the Notification Area and click Network Settings. The Network window appears.
  2. Select the Wireless menu entry.
  3. Click to the right of the Network Name to activate the drop-down list.
  4. Select the SSID you want to connect to.
  5. Click the Configure button. The editing a wireless connection window appears.
Editing the newly-created Wireless connection
A screen shot of the NetworkManager's editing a wireless connection window. The Wireless tab has been selected on the left.
図6.8 Editing the newly-created Wireless connection

Configuring the Connection Name, Auto-Connect Behavior, and Availability Settings

Three settings in the Editing dialog are common to all connection types:
  • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the Wireless tab of the Network Connections window. By default, wireless connections are named the same as the SSID of the wireless access point. You can rename the wireless connection without affecting its ability to connect, as in the example above, but it is recommended to retain the SSID name.
  • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to 「Connecting to a Network Automatically」 for more information.
  • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to 「User and System Connections」 for details.

Configuring the Wireless Tab

SSID
All access points have a Service Set identifier to identify them. However, an access point may be configured not to broadcast its SSID, in which case it is hidden, and will not show up in NetworkManager's list of Available networks. You can still connect to a wireless access point that is hiding its SSID as long as you know its SSID (and authentication secrets).
For information on connecting to a hidden wireless network, refer to 6.3.2項「Connecting to a Hidden Wireless Network」.
Mode
Infrastructure — Set Mode to Infrastructure if you are connecting to a dedicated wireless access point or one built into a network device such as a router or a switch.
Ad-hoc — Set Mode to Ad-hoc if you are creating a peer-to-peer network for two or more mobile devices to communicate directly with each other. If you use Ad-hoc mode, referred to as Independent Basic Service Set (IBSS) in the 802.11 standard, you must ensure that the same SSID is set for all participating wireless devices, and that they are all communicating over the same channel.
BSSID
The Basic Service Set Identifier (BSSID) is the MAC address of the specific wireless access point you are connecting to when in Infrastructure mode. This field is blank by default, and you are able to connect to a wireless access point by SSID without having to specify its BSSID. If the BSSID is specified, it will force the system to associate to a specific access point only.
For ad-hoc networks, the BSSID is generated randomly by the mac80211 subsystem when the ad-hoc network is created. It is not displayed by NetworkManager
MAC address
Like an Ethernet Network Interface Card (NIC), a wireless adapter has a unique MAC address (Media Access Control; also known as a hardware address) that identifies it to the system. Running the ip addr command will show the MAC address associated with each interface. For example, in the following ip addr output, the MAC address for the wlan0 interface (which is 00:1c:bf:02:f8:70) immediately follows the link/ether keyword:
~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 52:54:00:26:9e:f1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.251/24 brd 192.168.122.255 scope global eth0
    inet6 fe80::5054:ff:fe26:9ef1/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:02:f8:70 brd ff:ff:ff:ff:ff:ff
    inet 10.200.130.67/24 brd 10.200.130.255 scope global wlan0
    inet6 fe80::21c:bfff:fe02:f870/64 scope link
       valid_lft forever preferred_lft forever
A single system could have one or more wireless network adapters connected to it. The MAC address field therefore allows you to associate a specific wireless adapter with a specific connection (or connections). As mentioned, you can determine the MAC address using the ip addr command, and then copy and paste that value into the MAC address text-entry field.
MTU
The MTU (Maximum Transmission Unit) value represents the size in bytes of the largest packet that the connection will use to transmit. If set to a non-zero number, only packets of the specified size or smaller will be transmitted. Larger packets are broken up into multiple Ethernet frames. It is recommended to leave this setting on automatic.

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing the wireless connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can successfully connect to your the modified connection by selecting it from the NetworkManager Notification Area applet. See 「Connecting to a Network」 for details on selecting and connecting to a network.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

6.3.3. Establishing a Mobile Broadband Connection

You can use NetworkManager's mobile broadband connection abilities to connect to the following 2G and 3G services:
  • 2G — GPRS (General Packet Radio Service) or EDGE (Enhanced Data Rates for GSM Evolution)
  • 3G — UMTS (Universal Mobile Telecommunications System) or HSPA (High Speed Packet Access)
Your computer must have a mobile broadband device (modem), which the system has discovered and recognized, in order to create the connection. Such a device may be built into your computer (as is the case on many notebooks and netbooks), or may be provided separately as internal or external hardware. Examples include PC card, USB Modem or Dongle, mobile or cellular telephone capable of acting as a modem.
手順6.3 Adding a New Mobile Broadband Connection
You can configure a mobile broadband connection by opening the Network Connections window and selecting the Mobile Broadband tab.
  1. Open the Network Connections window by running, as a normal user:
    ~]$ nm-connection-editor &
    
    The Network Connections window appears.
  2. Select the Mobile Broadband tab.
  3. Click the Add button to open the Set up a Mobile Broadband Connection assistant.
  4. Under Create a connection for this mobile broadband device, choose the 2G- or 3G-capable device you want to use with the connection. If the dropdown menu is inactive, this indicates that the system was unable to detect a device capable of mobile broadband. In this case, click Cancel, ensure that you do have a mobile broadband-capable device attached and recognized by the computer and then retry this procedure. Click the Forward button.
  5. Select the country where your service provider is located from the list and click the Forward button.
  6. Select your provider from the list or enter it manually. Click the Forward button.
  7. Select your payment plan from the dropdown menu and confirm the Access Point Name (APN) is correct. Click the Forward button.
  8. Review and confirm the settings and then click the Apply button.
  9. Edit the mobile broadband-specific settings by referring to the Configuring the Mobile Broadband Tab description below .
手順6.4 Editing an Existing Mobile Broadband Connection
Follow these steps to edit an existing mobile broadband connection.
  1. Open the Network Connections window by running, as a normal user:
    ~]$ nm-connection-editor &
    
    The Network Connections window appears.
  2. Select the Mobile Broadband tab.
  3. Select the connection you wish to edit and click the Edit button.
  4. Configure the connection name, auto-connect behavior, and availability settings.
    Three settings in the Editing dialog are common to all connection types:
    • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the Mobile Broadband tab of the Network Connections window.
    • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to 「Connecting to a Network Automatically」 for more information.
    • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to 「User and System Connections」 for details.
  5. Edit the mobile broadband-specific settings by referring to the Configuring the Mobile Broadband Tab description below .

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing your mobile broadband connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can connect to your new or customized connection by selecting it from the NetworkManager Notification Area applet. See 「Connecting to a Network」 for information on using your new or altered connection.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

Configuring the Mobile Broadband Tab

If you have already added a new mobile broadband connection using the assistant (refer to 手順6.3「Adding a New Mobile Broadband Connection」 for instructions), you can edit the Mobile Broadband tab to disable roaming if home network is not available, assign a network ID, or instruct NetworkManager to prefer a certain technology (such as 3G or 2G) when using the connection.
Number
The number that is dialed to establish a PPP connection with the GSM-based mobile broadband network. This field may be automatically populated during the initial installation of the broadband device. You can usually leave this field blank and enter the APN instead.
Username
Enter the username used to authenticate with the network. Some providers do not provide a username, or accept any username when connecting to the network.
Password
Enter the password used to authenticate with the network. Some providers do not provide a password, or accept any password.
APN
Enter the Access Point Name (APN) used to establish a connection with the GSM-based network. Entering the correct APN for a connection is important because it often determines:
  • how the user is billed for their network usage; and/or
  • whether the user has access to the Internet, an intranet, or a subnetwork.
Network ID
Entering a Network ID causes NetworkManager to force the device to register only to a specific network. This can be used to ensure the connection does not roam when it is not possible to control roaming directly.
Type
Any — The default value of Any leaves the modem to select the fastest network.
3G (UMTS/HSPA) — Force the connection to use only 3G network technologies.
2G (GPRS/EDGE) — Force the connection to use only 2G network technologies.
Prefer 3G (UMTS/HSPA) — First attempt to connect using a 3G technology such as HSPA or UMTS, and fall back to GPRS or EDGE only upon failure.
Prefer 2G (GPRS/EDGE) — First attempt to connect using a 2G technology such as GPRS or EDGE, and fall back to HSPA or UMTS only upon failure.
Allow roaming if home network is not available
Uncheck this box if you want NetworkManager to terminate the connection rather than transition from the home network to a roaming one, thereby avoiding possible roaming charges. If the box is checked, NetworkManager will attempt to maintain a good connection by transitioning from the home network to a roaming one, and vice versa.
PIN
If your device's SIM (Subscriber Identity Module) is locked with a PIN (Personal Identification Number), enter the PIN so that NetworkManager can unlock the device. NetworkManager must unlock the SIM if a PIN is required in order to use the device for any purpose.

6.3.4. Establishing a VPN Connection

Establishing an encrypted Virtual Private Network (VPN) enables you to communicate securely between your Local Area Network (LAN), and another, remote LAN. After successfully establishing a VPN connection, a VPN router or gateway performs the following actions upon the packets you transmit:
  1. it adds an Authentication Header for routing and authentication purposes;
  2. it encrypts the packet data; and,
  3. it encloses the data with an Encapsulating Security Payload (ESP), which constitutes the decryption and handling instructions.
The receiving VPN router strips the header information, decrypts the data, and routes it to its intended destination (either a workstation or other node on a network). Using a network-to-network connection, the receiving node on the local network receives the packets already decrypted and ready for processing. The encryption/decryption process in a network-to-network VPN connection is therefore transparent to clients.
Because they employ several layers of authentication and encryption, VPNs are a secure and effective means of connecting multiple remote nodes to act as a unified intranet.
手順6.5 Adding a New VPN Connection
  1. You can configure a new VPN connection by opening the Network window and selecting the VPN menu entry.
  2. Click on the NetworkManager applet icon in the Notification Area. Clicking on the Network Settings menu entry opens the Network window, from where you can view some basic network configuration information and initiate configuration tasks.
  3. Click on the VPN menu entry followed by Configure and proceed to 「Establishing a VPN Connection」. If there is no VPN menu entry click on the plus sign at the bottom. A dialog box appears. Ensure the interface is set to VPN.

    A VPN plug-in is required

    The appropriate NetworkManager VPN plug-in for the VPN type you want to configure must be installed. (refer to 「パッケージのインストール」 for more information on how to install new packages in Fedora 17).
  4. Click the Create button to open the Choose a VPN Connection Type assistant.
  5. Select the VPN protocol for the gateway you are connecting to from the dropdown menu. The VPN protocols available for selection in the dropdown menu corresponds to the NetworkManager VPN plug-ins installed. For example, if the NetworkManager VPN plug-in for openswanis installed then the IPsec based VPN will be selectable from the dropdown menu.
    After selecting the correct one, press the Create... button.
  6. The Editing VPN Connection 1 window then appears. This window presents settings customized for the type of VPN connection you selected in ステップ 5.
You can configure an existing VPN connection by opening the Network window and selecting the VPN menu entry.
  1. Click on the NetworkManager applet icon in the Notification Area and click Network Settings. The Network window appears.
  2. Select the VPN menu entry.
  3. Select the connection you wish to edit and click the Configure button.
Editing the newly-created VPN connection 1.
A screenshot of the Editing VPN connection 1 window. The VPN tab is on the left and in the foreground
図6.9 Editing the newly-created VPN connection 1.

Configuring the Connection Name, Auto-Connect Behavior, and Availability Settings

Three settings in the Editing dialog are common to all connection types:
  • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the VPN tab of the Network Connections window.
  • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to 「Connecting to a Network Automatically」 for more information.
  • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to 「User and System Connections」 for details.

Configuring the VPN Tab

Gateway
The name or IP address of the remote VPN gateway.
Group name
The name of a VPN group configured on the remote gateway.
User password
If required, enter the password used to authenticate with the VPN.
Group password
If required, enter the password used to authenticate with the VPN.
User name
If required, enter the username used to authenticate with the VPN.
Phase1 Algorithms
If required, enter the algorithms to be used to authenticate and set up an encrypted channel.
Phase2 Algorithms
If required, enter the algorithms to be used for the IPsec negotiations.
Domain
If required, enter the Domain Name.
NAT traversal
Cisco UDP (default) — IPsec over UDP.
NAT-T — ESP encapsulation and IKE extensions are used to handle NAT Traversal.
Disabled — No special NAT measures required.
Disable Dead Peer Detection — Disable the sending of probes to the remote gateway or endpoint.

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing your new VPN connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can connect to your new or customized connection by selecting it from the NetworkManager Notification Area applet. See 「Connecting to a Network」 for information on using your new or altered connection.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

6.3.5. Establishing a DSL Connection

Open the Network Connections window by running, as a normal user:
~]$ nm-connection-editor &
Select the DSL tab and click Add.
Username
Enter the username used to authenticate with the service provider.
Service
Leave blank unless otherwise directed.
Password
Enter the password supplied by the service provider.

6.3.6. Establishing Routes

Configuring static network routes
A screen shot of the static routes window
図6.10 Configuring static network routes

Addresses
Address — The IP address of a network, sub-net or host.
Netmask — The netmask or prefix length of the IP address just entered.
Gateway — The IP address of the gateway leading to the network, sub-net or host.
Metric — A network cost, that is to say a preference value to give to this route. Lower values will be preferred over higher values.
Ignore automatically obtained routes
Select this check box to only use manually entered routes for the VPN tunnel.
Use this connection only for resources on its network
Select this checkbox to prevent the VPN from becoming the default route. Then only the specific routes sent by the VPN server (or routes entered here manually) will be routed over the VPN tunnel.

6.4. Configuring Connection Settings

6.4.1. Configuring 802.1x Security

802.1x security is the name of the IEEE standard for port-based Network Access Control (PNAC). Simply put, 802.1x security is a way of defining a logical network out of a physical one. All clients who want to join the logical network must authenticate with the server (a router, for example) using the correct 802.1x authentication method.
802.1x security is most often associated with securing wireless networks (WLANs), but can also be used to prevent intruders with physical access to the network (LAN) from gaining entry. In the past, DHCP servers were configured not to lease IP addresses to unauthorized users, but for various reasons this practice is both impractical and insecure, and thus is no longer recommended. Instead, 802.1x security is used to ensure a logically-secure network through port-based authentication.
802.1x provides a framework for WLAN and LAN access control and serves as an envelope for carrying one of the Extensible Authentication Protocol (EAP) types. An EAP type is a protocol that defines how WLAN security is achieved on the network.
You can configure 802.1x security for a wired or wireless connection type by opening the Network Connections window (refer to 「Configuring New and Editing Existing Connections」) and following the applicable procedure:
手順6.6 For a wired connection...
  1. Select the Wired tab.
  2. Either click on Add to add a new network connection for which you want to configure 802.1x security, or select an existing connection and click Edit.
  3. Then select the 802.1x Security tab and check the Use 802.1x security for this connection checkbox to enable settings configuration.
手順6.7 For a wireless connection...
  1. Select the Wireless tab.
  2. Either click on Add to add a new network connection for which you want to configure 802.1x security, or select an existing connection and click Edit.
  3. Then click the Security dropdown and choose one of the following security methods: LEAP, Dynamic WEP (802.1x), or WPA & WPA2 Enterprise.
  4. Refer to 「Configuring TLS (Transport Layer Security) Settings」 for descriptions of which EAP types correspond to your selection in the Security dropdown.

6.4.1.1. Configuring TLS (Transport Layer Security) Settings

With Transport Layer Security, the client and server mutually authenticate using the TLS protocol. The server demonstrates that it holds a digital certificate, the client proves its own identity using its client-side certificate, and key information is exchanged. Once authentication is complete, the TLS tunnel is no longer used. Instead, the client and server use the exchanged keys to encrypt data using AES, TKIP or WEP.
The fact that certificates must be distributed to all clients who want to authenticate means that the EAP-TLS authentication method is very strong, but also more complicated to set up. Using TLS security requires the overhead of a public key infrastructure (PKI) to manage certificates. The benefit of using TLS security is that a compromised password does not allow access to the (W)LAN: an intruder must also have access to the authenticating client's private key.
Network Manger does not determine the version of TLS supported. Network Manager gathers the parameters entered by the user and passes them to the daemon, wpa_supplicant, that handles the procedure. It, in turn, uses OpenSSL to establish the TLS tunnel. OpenSSL itself negotiates the SSL/TLS protocol version. It uses the highest version both ends support.
Identity
Identity string for EAP authentication methods, such as a username or login name.
User certificate
Click to browse for, and select, a user's certificate.
CA certificate
Click to browse for, and select, a Certificate Authority's certificate.
Private key
Click to browse for, and select, a user's private key file.
Private key password
Enter the user password corresponding to the user's private key.

6.4.1.2. Configuring Tunneled TLS Settings

Anonymous identity
This value is used as the unencrypted identity.
CA certificate
Click to browse for, and select, a Certificate Authority's certificate.
Inner authentication
PAP — Password Authentication Protocol.
MSCHAP — Challenge Handshake Authentication Protocol.
MSCHAPv2 — Microsoft Challenge Handshake Authentication Protocol version 2.
CHAP — Challenge Handshake Authentication Protocol.
Username
Enter the username to be used in the authentication process.
Password
Enter the password to be used in the authentication process.

6.4.1.3. Configuring Protected EAP (PEAP) Settings

Anonymous Identity
This value is used as the unencrypted identity.
CA certificate
Click to browse for, and select, a Certificate Authority's certificate.
PEAP version
The version of Protected EAP to use. Automatic, 0 or 1.
Inner authentication
MSCHAPv2 — Microsoft Challenge Handshake Authentication Protocol version 2.
MD5 — Message Digest 5, a cryptographic hash function.
GTC — Generic Token Card.
Username
Enter the username to be used in the authentication process.
Password
Enter the password to be used in the authentication process.

6.4.2. Configuring Wireless Security

Security
None — Do not encrypt the Wi-Fi connection.
WEP 40/128-bit Key — Wired Equivalent Privacy (WEP), from the IEEE 802.11 standard. Uses a single pre-shared key (PSK).
WEP 128-bit Passphrase — An MD5 hash of the passphrase will be used to derive a WEP key.
LEAP — Lightweight Extensible Authentication Protocol, from Cisco Systems.
Dynamic WEP (802.1x) — WEP keys are changed dynamically.
WPA & WPA2 Personal — Wi-Fi Protected Access (WPA), from the draft IEEE 802.11i standard. A replacement for WEP. Wi-Fi Protected Access II (WPA2), from the 802.11i-2004 standard. Personal mode uses a pre-shared key (WPA-PSK).
WPA & WPA2 Enterprise — WPA for use with a RADUIS authentication server to provide IEEE 802.1x network access control.
Password
Enter the password to be used in the authentication process.

6.4.3. Configuring PPP (Point-to-Point) Settings

Configure Methods
Use point-to-point encryption (MPPE)
Microsoft Point-To-Point Encryption protocol (RFC 3078).
Allow BSD data compression
PPP BSD Compression Protocol (RFC 1977).
Allow Deflate data compression
PPP Deflate Protocol (RFC 1979).
Use TCP header compression
Compressing TCP/IP Headers for Low-Speed Serial Links (RFC 1144).
Send PPP echo packets
LCP Echo-Request and Echo-Reply Codes for loopback tests (RFC 1661).

6.4.4. Configuring IPv4 Settings

Editing the IPv4 Settings Tab
A screen shot of NetworkManager's IPv4 Settings Tab
図6.11 Editing the IPv4 Settings Tab

The IPv4 Settings tab allows you to configure the method by which you connect to the Internet and enter IP address, route, and DNS information as required. The IPv4 Settings tab is available when you create and modify one of the following connection types: wired, wireless, mobile broadband, VPN or DSL.
If you are using DHCP to obtain a dynamic IP address from a DHCP server, you can simply set Method to Automatic (DHCP).

Setting the Method

Available IPv4 Methods by Connection Type
When you click the Method dropdown menu, depending on the type of connection you are configuring, you are able to select one of the following IPv4 connection methods. All of the methods are listed here according to which connection type or types they are associated with.
Method
Automatic (DHCP) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses. You do not need to fill in the DHCP client ID field.
Automatic (DHCP) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
Link-Local Only — Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be selected as per RFC 3927.
Shared to other computers — Choose this option if the interface you are configuring is for sharing an Internet or WAN connection.
Wired, Wireless and DSL Connection Methods
Manual — Choose this option if the network you are connecting to does not have a DHCP server and you want to assign IP addresses manually.
Mobile Broadband Connection Methods
Automatic (PPP) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic (PPP) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
VPN Connection Methods
Automatic (VPN) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic (VPN) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
DSL Connection Methods
Automatic (PPPoE) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic (PPPoE) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.

6.4.5. Configuring IPv6 Settings

Method
Ignore — Choose this option if you want to disable IPv6 settings.
Automatic — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic, addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
Manual — Choose this option if the network you are connecting to does not have a DHCP server and you want to assign IP addresses manually.
Link-Local Only — Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be selected as per RFC 4862.
Shared to other computers — Choose this option if the interface you are configuring is for sharing an Internet or WAN connection.
Addresses
DNS servers — Enter a comma separated list of DNS servers.
Search domains — Enter a comma separated list of domain controllers.

6.5. NetworkManager Architecture

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

Fedora においては、すべてのネットワーク通信はシステムに接続された設定済みソフトウェアインターフェース物理ネットワークデバイスの間で発生します。
The configuration files for network interfaces are located in the /etc/sysconfig/network-scripts/ directory. The scripts used to activate and deactivate these network interfaces are also located here. Although the number and type of interface files can differ from system to system, there are three categories of files that exist in this directory:
  1. インターフェースの設定ファイル
  2. インターフェースの制御スクリプト
  3. ネットワークの関数ファイル
これらの各カテゴリーのファイルは、合同で機能し各種ネットワークデバイスを動作させます。
この章では、これらファイル間の関係とファイルの使用方法について説明していきます。

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

インターフェース設定ファイルを調べる前に、まずネットワーク設定において使用される主要な設定ファイルを項目別にあげましょう。Fedora システムをカスタマイズするときに役に立つネットワークスタックをセットアップすることに役立ちます。
主要なネットワーク設定ファイルは、次のようになります:
/etc/hosts
The main purpose of this file is to resolve hostnames that cannot be resolved any other way. It can also be used to resolve hostnames on small networks with no DNS server. Regardless of the type of network the computer is on, this file should contain a line specifying the IP address of the loopback device (127.0.0.1) as localhost.localdomain. For more information, refer to the hosts(5) manual page.
/etc/resolv.conf
This file specifies the IP addresses of DNS servers and the search domain. Unless configured to do otherwise, the network initialization scripts populate this file. For more information about this file, refer to the resolv.conf(5) manual page.
/etc/sysconfig/network
このファイルはすべてのネットワークインターフェースに対するルーティングとホスト情報を指定します。このファイルと利用可能なディレクティブの詳細は、「/etc/sysconfig/network」を参照してください。
/etc/sysconfig/network-scripts/ifcfg-interface-name
各ネットワークインターフェースに対して、対応するインターフェース設定ファイルがあります。これらのファイルはそれぞれ、特定のネットワークインターフェースに固有の情報を提供します。この種のファイルと利用可能なディレクティブに関する詳細は「インターフェース設定ファイル」を参照してください。

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

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

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

The /etc/sysconfig/networking/ directory is used by the now deprecated Network Administration Tool (system-config-network). Its contents should not be edited manually. Using only one method for network configuration is strongly encouraged, due to the risk of configuration deletion. For more information about configuring network interfaces using graphical configuration tools, refer to 6章NetworkManager.

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

インターフェース設定ファイルは、それぞれのネットワークデバイスに対するソフトウェアインターフェースを制御します。システムが起動するとき、どのインターフェースを起動して、それらをどのように設定するのかを決めるために、これらのファイルを使用します。これらのファイルは通常 ifcfg-name という名前です、ここで name は設定ファイルが制御するデバイスの名前を参照します。

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

One of the most common interface files is /etc/sysconfig/network-scripts/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
NetworkManager is graphical configuration tool which provides an easy way to make changes to the various network interface configuration files (refer to 6章NetworkManager for detailed instructions on using this tool).
但し、任意のネットワーク インターフェースの設定ファイルは、手動で編集することもできます。
以下にイーサネット インターフェースの設定ファイル内の設定パラメーターを一覧で示します。
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
where name is the name of the physical device (except for dynamically-allocated PPP devices where it is the logical name).
DHCP_HOSTNAME=name
ここで name は DHCP サーバーに送信される短縮ホスト名です。DHCP サーバーがクライアントに IP アドレスを受信する前にホスト名を指定するよう要求するときのみ、このオプションを使用してください。
DNS{1,2}=address
where address is a name server address to be placed in /etc/resolv.conf if the PEERDNS directive is set to yes.
ETHTOOL_OPTS=options
where options are any device-specific options supported by ethtool. For example, if you wanted to force 100Mb, full duplex:
ETHTOOL_OPTS="autoneg off speed 100 duplex full"
Instead of a custom initscript, use ETHTOOL_OPTS to set the interface speed and duplex settings. Custom initscripts run outside of the network init script lead to unpredictable results during a post-boot network service restart.

Set autoneg off before changing speed or duplex settings

Changing speed or duplex settings almost always requires disabling autonegotiation with the autoneg off option. This option needs to be stated first, as the option entries are order-dependent.
GATEWAY=address
ここで address はネットワークのルーターまたはゲートウェイデバイスの IP アドレスです(あれば)。
HOTPLUG=answer
ここで answer は次のいずれかです:
  • yes — このデバイスはホットプラグされたときに有効化されます (これが初期状態です)。
  • no — このデバイスがホットプラグされたときに有効化されません
HOTPLUG=no オプションは、bonding カーネルモジュールが読み込まれているときに、チャネルボンディングインターフェースが有効化するのを防げます。
ボンディング・インターフェースの詳細は「チャンネル・ボンディング・インターフェース」を参照してください。
HWADDR=MAC-address
ここで MAC-addressAA:BB:CC:DD:EE:FF の形式であるイーサネットデバイスのハードウェアアドレスです。このディレクティブは、インターフェースが各 NIC モジュールに対して設定された読み込み順序にかかわりなく正しいデバイス名を確実に割り当てるために、複数の NIC を持つマシンにおいて使用する必要があります。このディレクティブは MACADDR と同時に使用できません

注記

永続的なデバイス名は /etc/udev/rules.d/70-persistent-net.rules により処理されています。
IPADDR=address
ここで address は IP アドレスです。
LINKDELAY=time
ここで time は、デバイスを設定する前にリンクネゴシエーションを待つ秒数です。
MACADDR=MAC-address
ここで MAC-addressAA:BB:CC:DD:EE:FF の形式であるイーサネットデバイスのハードウェアアドレスです。
このディレクティブは、物理 NIC に割り当てられた MAC アドレスを上書きして、インターフェースに MAC アドレスを割り当てるために使用されます。このディレクティブは HWADDR ディレクティブと一緒に使用できません
MASTER=bond-interface
ここで bond-interface は、イーサネットインターフェースが連結されたチャネルボンディングインターフェースです。
このディレクティブは SLAVE ディレクティブと一緒に使用されます。
ボンディング・インターフェースの詳細は「チャンネル・ボンディング・インターフェース」を参照してください。
NETMASK=mask
ここで mask はネットマスクの値です。
NETWORK=address
ここで address はネットワークアドレスです。この値は ipcalc を用いて自動的に計算されるので、このディレクティブは推奨されません。
NM_CONTROLLED=answer
ここで answer は次のいずれかです:
  • yes — NetworkManager がこのデバイスを設定することを許可します。これは初期状態の動作のため、省略できます。
  • no — NetworkManager がこのデバイスを設定することを許可しません。
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 は次のいずれかです:
  • yes — 非 root ユーザーがこのデバイスを制御できます。
  • no — 非 root ユーザーがこのデバイスを制御できません。

7.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 is bondN, replacing N with the number for the interface.
以下は、チャンネル ボンディング設定ファイルの例です。
例7.1 ifcfg-bond0 インターフェース設定ファイルの例
DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
BONDING_OPTS="スペースで区切ってボンディングのパラメーター"

After the channel bonding interface is created, the network interfaces to be bound together must be configured by adding the MASTER and SLAVE directives to their configuration files. The configuration files for each of the channel-bonded interfaces can be nearly identical.
For example, if two Ethernet interfaces are being channel bonded, both eth0 and eth1 may look like the following example:
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.

ifcfg-bondN ファイルにすべてのボンディングモジュールパラメーターを書きます

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

7.2.3. ネットワークブリッジ

A network bridge is a Link Layer device which forwards traffic between networks based on MAC addresses and is therefore also referred to as a Layer 2 device. It makes forwarding decisions based on tables of MAC addresses which it builds by learning what hosts are connected to each network. A software bridge can be used within a Linux host in order to emulate a hardware bridge, for example in virtualization applications for sharing a NIC with one or more virtual NICs. This case will be illustrated here as an example.
To create a network bridge, create a file in the /etc/sysconfig/network-scripts/ directory called ifcfg-brN, replacing N with the number for the interface, such as 0.
The contents of the file is similar to whatever type of interface is getting bridged to, such as an Ethernet interface. The differences in this example are as follows:
  • The DEVICE directive is given an interface name as its argument in the format brN, where N is replaced with the number of the interface.
  • The TYPE directive is given an argument Bridge or Ethernet. This directive determines the device type and the argument is case sensitive.
  • The bridge interface configuration file now has the IP address and the physical interface has only a MAC address.
  • An extra directive, DELAY=0, is added to prevent the bridge from waiting while it monitors traffic, learns where hosts are located, and builds a table of MAC addresses on which to base its filtering decisions. The default delay of 30 seconds is not needed if no routing loops are possible.
  • The NM_CONTROLLED=no should be added to the Ethernet interface to prevent NetworkManager from altering the file. It can also be added to the bridge configuration file in case future versions of NetworkManager support bridge configuration.
The following is a sample bridge interface configuration file using a static IP address:
例7.2 ifcfg-br0 インターフェース設定ファイルの例
DEVICE=br0
TYPE=Bridge
IPADDR=192.168.1.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=static
NM_CONTROLLED=no
DELAY=0

To complete the bridge another interface is created, or an existing interface is modified, and pointed to the bridge interface. The following is a sample Ethernet interface configuration file pointing to a bridge interface. Configure your physical interface in /etc/sysconfig/network-scripts/ifcfg-ethX, where X is a unique number corresponding to a specific interface, as follows:
例7.3 ifcfg-ethX インターフェース設定ファイルの例
DEVICE=ethX
TYPE=Ethernet
HWADDR=AA:BB:CC:DD:EE:FF
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
BRIDGE=br0

注記

For the DEVICE directive, almost any interface name could be used as it does not determine the device type. Other commonly used names include tap, dummy and bond for example. TYPE=Ethernet is not strictly required. If the TYPE directive is not set, the device is treated as an Ethernet device (unless it's name explicitly matches a different interface configuration file.)
You can refer to 「インターフェース設定ファイル」 for a review of the directives and options used in network interface config files.

警告

If you are configuring bridging on a remote host, and you are connected to that host over the physical NIC you are configuring, please consider the implications of losing connectivity before proceeding. You will lose connectivity when restarting the service and may not be able to regain connectivity if any errors have been made. Console, or out-of-band access is advised.
Restart the networking service, in order for the changes to take effect by running as root:
 systemctl restart network.service 
An example of a network bridge formed from two or more bonded Ethernet interfaces will now be given as this is another common application in a virtualization environment. If you are not very familiar with the configuration files for bonded interfaces then please refer to 「チャンネル・ボンディング・インターフェース」
Create or edit two or more Ethernet interface configuration files, which are to be bonded, as follows:
DEVICE=ethX
TYPE=Ethernet
USERCTL=no
SLAVE=yes
MASTER=bond0
BOOTPROTO=none
HWADDR=AA:BB:CC:DD:EE:FF
NM_CONTROLLED=no

注記

Using ethX as the interface name is common practice but almost any name could be used. Names such as tap, dummy and bond are commonly used.
Create or edit one interface configuration file, /etc/sysconfig/network-scripts/ifcfg-bond0, as follows:
DEVICE=bond0
ONBOOT=yes
BONDING_OPTS='mode=1 miimon=100'
BRIDGE=brbond0
NM_CONTROLLED=no
For further instructions and advice on configuring the bonding module and to view the list of bonding parameters, refer to 「Using Channel Bonding」.
Create or edit one interface configuration file, /etc/sysconfig/network-scripts/ifcfg-brbond0, as follows:
DEVICE=brbond0
ONBOOT=yes
TYPE=Bridge
IPADDR=192.168.1.1
NETMASK=255.255.255.0
NM_CONTROLLED=no
A network bridge consisting of two bonded Ethernet interfaces.
A diagram of two Ethernet interfaces on the left feeding into a virtual interface labeled bond 0. This in turn leads to a virtual interface called BR Bond 0 on the right. From there a path leads to a virtual network below.
図7.1 A network bridge consisting of two bonded Ethernet interfaces.

We now have two or more interface configuration files with the MASTER=bond0 directive. These point to the configuration file named /etc/sysconfig/network-scripts/ifcfg-bond0, which contains the DEVICE=bond0 directive. This ifcfg-bond0 in turn points to the /etc/sysconfig/network-scripts/ifcfg-brbond0 configuration file, which contains the IP address, and acts as an interface to the virtual networks inside the host.
Restart the networking service, in order for the changes to take effect by running as root:
 systemctl restart network.service 

7.2.4. Setting up 802.1q VLAN tagging

  1. Ensure that the module is loaded by entering the following command:
     lsmod | grep 8021q
  2. If the module is not loaded, load it with the following command:
    modprobe 8021q
  3. Configure your physical interface in /etc/sysconfig/network-scripts/ifcfg-ethX, where X is a unique number corresponding to a specific interface, as follows:
    DEVICE=ethX
    TYPE=Ethernet
    BOOTPROTO=none
    ONBOOT=yes
  4. Configure the VLAN interface configuration in /etc/sysconfig/network-scripts. The configuration filename should be the physical interface plus a . character plus the VLAN ID number. For example, if the VLAN ID is 192, and the physical interface is eth0, then the configuration filename should be ifcfg-eth0.192:
    DEVICE=ethX.192
    BOOTPROTO=static
    ONBOOT=yes
    IPADDR=192.168.1.1
    NETMASK=255.255.255.0
    USERCTL=no
    NETWORK=192.168.1.0
    VLAN=yes
    If there is a need to configure a second VLAN, with for example, VLAN ID 193, on the same interface, eth0 , add a new file with the name eth0.193 with the VLAN configuration details.
  5. Restart the networking service, in order for the changes to take effect by running as root:
     systemctl restart network.service 

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

Two lesser-used types of interface configuration files are alias and clone files. As the ip command of the iproute package now supports assigning multiple address to the same interface it is no longer necessary to use this method of binding multiple addresses to the same interface.

注記

At the time of writing, NetworkManager does not detect IP aliases in ifcfg files. For example, if ifcfg-eth0 and ifcfg-eth0:1 files are present, NetworkManager creates two connections, which will cause confusion.
For new installations, users should select the Manual method on the IPv4 or IPv6 tab in NetworkManager to assign multiple IP address to the same interface. For more information on using this tool, refer to 6章NetworkManager.
Alias interface configuration files, which are used to bind multiple addresses to a single interface, use the ifcfg-if-name:alias-value naming scheme.
For example, an ifcfg-eth0:0 file could be configured to specify DEVICE=eth0:0 and a static IP address of 10.0.0.2, serving as an alias of an Ethernet interface already configured to receive its IP information via DHCP in ifcfg-eth0. Under this configuration, eth0 is bound to a dynamic IP address, but the same physical network card can receive requests via the fixed, 10.0.0.2 IP address.

警告

エイリアス インターフェースは 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
Since the default value for the USERCTL directive is no if it is not specified, users cannot bring this interface up and down. To give users the ability to control the interface, create a clone by copying ifcfg-eth0 to ifcfg-eth0-user and add the following line to ifcfg-eth0-user:
USERCTL=yes
This way a user can bring up the eth0 interface using the /sbin/ifup eth0-user command because the configuration options from ifcfg-eth0 and ifcfg-eth0-user are combined. While this is a very basic example, this method can be used with a variety of options and interfaces.
It is no longer possible to create alias and clone interface configuration files using a graphical tool. However, as explained at the beginning of this section, it is no longer necessary to use this method as it is now possible to directly assign multiple IP address to the same interface. For new installations, users should select the Manual method on the IPv4 or IPv6 tab in NetworkManager to assign multiple IP address to the same interface. For more information on using this tool, refer to 6章NetworkManager.

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

ダイヤルアップ接続を通してインターネットに接続する場合、インターフェース用に設定ファイルが必要です。
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) is another dialup interface, although it is used less frequently. SLIP files have interface configuration file names such as ifcfg-sl0.
これらのファイルで使用できる他のオプションを以下に示します:
DEFROUTE=answer
ここで answer は次のいずれかです:
  • yes — このインターフェースをデフォルトルートとして設定します。
  • no — このインターフェースをデフォルトルートとして設定しません。
DEMAND=answer
ここで answer は次のいずれかです:
  • yes — このインターフェースは pppd が使用しようとするときに接続を初期化できます。
  • no — 接続はこのインターフェースに対して手動で確立する必要があります。
IDLETIMEOUT=value
where value is the number of seconds of idle activity before the interface disconnects itself.
INITSTRING=string
where string is the initialization string passed to the modem device. This option is primarily used in conjunction with SLIP interfaces.
LINESPEED=value
where value is the baud rate of the device. Possible standard values include 57600, 38400, 19200, and 9600.
MODEMPORT=device
where device is the name of the serial device that is used to establish the connection for the interface.
MTU=value
where value is the Maximum Transfer Unit (MTU) setting for the interface. The MTU refers to the largest number of bytes of data a frame can carry, not counting its header information. In some dialup situations, setting this to a value of 576 results in fewer packets dropped and a slight improvement to the throughput for a connection.
NAME=name
where name is the reference to the title given to a collection of dialup connection configurations.
PAPNAME=name
where name is the username given during the Password Authentication Protocol (PAP) exchange that occurs to allow connections to a remote system.
PERSIST=answer
ここで answer は次のいずれかです:
  • yes — This interface should be kept active at all times, even if deactivated after a modem hang up.
  • no — This interface should not be kept active at all times.
REMIP=address
where address is the IP address of the remote system. This is usually left unspecified.
WVDIALSECT=name
where name associates this interface with a dialer configuration in /etc/wvdial.conf. This file contains the phone number to be dialed and other important information for the interface.

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

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

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

ループバックインターフェースのスクリプト /etc/sysconfig/network-scripts/ifcfg-lo は、手動で編集すべきではありません。そうすると、システムが正しく動作しなくなる可能性がありません。
ifcfg-irlan0
赤外線インターフェース によって、ラップトップとプリンタなどデバイス間の情報を赤外線リンク上で流すことができます。これは、通常ピアツーピア接続で可能という事以外はイーサネットと同じような方法で動作します。
ifcfg-plip0
A Parallel Line Interface Protocol (PLIP) connection works much the same way as an Ethernet device, except that it utilizes a parallel port.

7.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 です。詳細は「ネットワーク機能ファイル」を参照してください。
インターフェースが指定され、要求を実行しているユーザーがインターフェースを制御することが許可された後、適切なスクリプトがインターフェースを起動または停止します。以下は、/etc/sysconfig/network-scripts/ ディレクトリーの中にある一般的なインターフェース制御スクリプトです:
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
ワイヤレスインターフェースをアップする為に使用します。

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

Removing or modifying any scripts in the /etc/sysconfig/network-scripts/ directory can cause interface connections to act irregularly or fail. Only advanced users should modify scripts related to a network interface.
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 by the following command:
systemctl action network.service
ここで、actionstart, stop, または restart のどれかです。
設定したデバイスと現在アクティブになっているネットワーク インターフェースの一覧を表示するには、次のコマンドを使用します:
 systemctl status network.service

注記

The older SysV service commands, such as service network status are considered deprecated but will still work. The SysV services can define their status in an arbitrary fashion so the output of the status command is not considered predictable over time. The SysV commands are retained for compatibility purposes. The /sbin/service utility will call systemctl when necessary.

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

Static routes are for traffic that must not, or should not, go through the default route. Use the route command to display the IP routing table. If static routes are required, they can be specified by means of the GATEWAY directive, either globally or in interface-specific configuration files. There is also the GATEWAYDEV directive, which is a global option. If multiple devices specify GATEWAY, and one interface is specified using the GATEWAYDEV directive, that directive will take precedence. This option is not recommend. Specifying an exit interface is optional. It can be useful if you want to force traffic out of a specific interface. For example, in the case of a VPN, you can force traffic to a remote network to pass through a tun0 interface even when the interface is in a different sub-net to the destination network.
Global static route configuration is stored in the /etc/sysconfig/network file. This file specifies routing and host information for all network interfaces. For more information about this file and the directives it accepts, refer to 「/etc/sysconfig/network」.
Per-interface static route configuration is stored in a /etc/sysconfig/network-scripts/route-interface file. For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file. The route-interface file has two formats: IP command arguments and network/netmask directives.

IP コマンドの引数形式

最初の行にデフォルトゲートウェイを定義します。デフォルトゲートウェイが DHCP 経由で設定されていないときのみ、これが必要になります:
default via X.X.X.X dev interface
X.X.X.X is the IP address of the default gateway. The interface is the interface that is connected to, or can reach, the default gateway. The dev option can be omitted.
静的ルーティングを定義します。各行はそれぞれルーティングとして構文解析されます:
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
Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 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:
10.10.10.0/24 via 10.10.10.1 dev eth1

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

デフォルトゲートウェイがすでに DHCP から割り当てられていると、IP コマンド引数のフォーマットは、起動中、または ifup コマンドを使用してインターフェースを停止状態から起動するとき、次のエラーのうちどちらかが発生します: "RTNETLINK answers: File exists" または 'Error: either "to" is a duplicate, or "X.X.X.X" is a garbage.'、ここで X.X.X.X はゲートウェイまたは他の IP アドレスです。デフォルトゲートウェイを使用して他のネットワークへの他のルートがあると、これらのエラーが発生する可能性があります。これらのエラーはどちらも無視しても安全です。

ネットワーク/ネットマスク ディレクティブの形式

You can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards:
 ADDRESS0=X.X.X.X NETMASK0=X.X.X.X GATEWAY0=X.X.X.X 
  • ADDRESS0=X.X.X.X is the network number for the static route.
  • NETMASK0=X.X.X.X is the netmask for the network number defined with ADDRESS0=X.X.X.X.
  • GATEWAY0=X.X.X.X is the default gateway, or an IP address that can be used to reach ADDRESS0=X.X.X.X
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
後続の静的ルートが順番に番号がつけられる必要があります。また、すべての値を飛ばすことはできません。たとえば、ADDRESS0, ADDRESS1, ADDRESS2, などです。
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 が使用されていると、これらの設定が自動的に割り当てられることに注意してください。

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

Fedora は、インターフェースを起動および停止するために使用される、重要な一般的な機能を含むいくつかのファイルを使用します。それぞれのインターフェース制御ファイルにこれらの機能を強制的に含めるよりは、必要なときに呼び出されるいくつかのファイルに一緒にグループ化します。
/etc/sysconfig/network-scripts/network-functions ファイルは最も一般的に使用される IPv4 機能が含まれます。これは多くのインターフェース制御スクリプトにとって有用です。これらの機能には、インターフェースの状態の変更、ホスト名の設定、ゲートウェイデバイスの検索、特定のデバイスがダウンしているかどうかの検証、およびデフォルトルートの追加に関して、必要とされる情報を持つ実行中のプログラムにアクセスすることを含みます。
IPv6 インターフェースに対して要求される関数は IPv4 インターフェースとは異なるので、/etc/sysconfig/network-scripts/network-functions-ipv6 ファイルはこの情報を保持するために特別に存在します。このファイルにある関数は、静的 IPv6 ルートを設定および削除、トンネルを作成および削除、インターフェースに IPv6 アドレスを追加および削除、およびインターフェースに IPv6 アドレスの存在を確認します。

7.6. その他のリソース

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

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

/usr/share/doc/initscripts-version/sysconfig.txt
この章では触れていない IPv6 オプションなど、ネットワーク設定ファイル用に利用可能なオプションへの手引きです。
/usr/share/doc/iproute-version/ip-cref.ps
このファイルは ip コマンドに関する豊富な情報を含みます。ここで、他のことがらの間で、ルーティングテーブルを操作するために使用できます。このファイルを表示するには ggv または kghostview アプリケーションを使用します。

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

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

目次

8. サービスおよびデーモン
8.1. サービスの設定
8.1.1. サービスの有効化
8.1.2. サービスの無効化
8.2. サービスの実行
8.2.1. サービスの状態の確認
8.2.2. サービスの実行
8.2.3. サービスの停止
8.2.4. サービスの再起動
8.3. その他のリソース
8.3.1. インストールされているドキュメント
8.3.2. 関連書籍
9. 認証の設定
9.1. 認証の設定ツール
9.1.1. 識別と認証
9.1.2. 高度なオプション
9.1.3. コマンドライン版
9.2. The System Security Services Daemon (SSSD)
9.2.1. SSIDとは?
9.2.2. SSIDの特徴
9.2.3. Setting Up SSSD
9.2.4. サービスの設定
9.2.5. Configuring Domains
9.2.6. Setting Up Kerberos Authentication
9.2.7. Configuring a Proxy Domain
9.2.8. トラブルシューティング
9.2.9. SSSD Configuration File Format
10. OpenSSH
10.1. SSH プロトコル
10.1.1. なぜ SSH を使うのか?
10.1.2. 主な機能
10.1.3. プロトコル・バージョン
10.1.4. SSH コネクションのイベント・シーケンス
10.2. OpenSSH の設定
10.2.1. 設定ファイル
10.2.2. OpenSSH サーバーの起動
10.2.3. リモート接続に対する SSH の要求
10.2.4. キー認証の使用
10.3. OpenSSH クライアント
10.3.1. ssh ユーティリティの使用方法
10.3.2. scp ユーティリティの使用方法
10.3.3. sftp ユーティリティの使用方法
10.4. 安全なシェル以上のもの
10.4.1. X11 転送
10.4.2. ポート転送
10.5. 追加のリソース
10.5.1. インストールされているドキュメント
10.5.2. 役に立つ Web サイト

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

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

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

新規サービスに対してアクセスを許可するとき、必ずファイアウォールと SELinux を同じように設定する必要があります。新規サービスを設定するときに起きる最も一般的な間違いの一つは、必要なファイアウォールの設定および SELinux ポリシーがアクセス許可するよう設定ことを忘れていることです。詳細は Fedora 17 セキュリティガイド を参照してください。

8.1. サービスの設定

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

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

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

irqbalance サービスの有効化

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

8.1.1. サービスの有効化

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

8.1.2. サービスの無効化

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

8.2. サービスの実行

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

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

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

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

特定のサービスの状態を確認するには、systemctl コマンドを以下の形式で使用します:
systemctl status service_name.service
このコマンドはサービスの状態に関する詳しい状態を提供します。しかしながら、ただサービスが実行されているかを確認する必要があるだけならば、代わりに以下の形式で systemctl コマンドを使用することができます:
systemctl is-active service_name.service
例8.3 httpd サービスの状態の確認
例8.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 — ユニットの概要です。
例8.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 サービスが、ロード、有効化、実行されています。また、待機中のジョブは何もありません。

8.2.2. サービスの実行

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

8.2.3. サービスの停止

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

8.2.4. サービスの再起動

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

8.3. その他のリソース

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

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

8.3.2. 関連書籍

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

第9章 認証の設定

9.1. 認証の設定ツール

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

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

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

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

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

9.1.1. 識別と認証

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

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

LDAP

LDAP オプションはシステムが LDAP 経由でユーザー情報を取得するよう指示します。以下の指定を含みます:
  • LDAP 検索のベース DN — ユーザー情報が一覧化された識別名 (DN: Distinguished Name) を使用して取得されるよう指定します。
  • LDAP ServerLDAP サーバーのアドレスを指定します。
  • 暗号化通信のために TLS を使用する — 有効になっているとき、LDAP サーバーに送信されるパスワードを暗号化するために Transport Layer Security (TLS) が使用されます。CA 証明書のダウンロード オプションにより、有効な 認証局の証明書 (CA: Certificate Authority) をダウンロードする URL を指定できます。有効な CA 証明書は Privacy Enhanced Mail (PEM) 形式である必要があります。

    LDAP サーバー項目における ldaps:// の使用法

    ldaps:// サーバーアドレスが LDAP サーバー の項目に指定されていると、暗号化通信のために TLS を使用するオプションをチェックする必要がありません。
    CA 証明書の詳細は「証明書とセキュリティの概要」を参照してください。
openldap-clients パッケージはこのオプションが機能するためにインストールする必要があります。
LDAP の詳細は「OpenLDAP」を参照してください。
LDAP は次の認証方法を提供します。
  • Kerberos パスワード — このオプションは Kerberos 認証を有効にします。以下の指定を含みます:
    • レルム — Kerberos サーバーのレルムを設定します。レルムは Kerberos を使用するネットワークです。一つかそれ以上の KDC および潜在的に大規模なクライアントから構成されます。
    • KDC — 鍵配布センター (KDC: Key Distribution Centers) を定義します、これは Kerberos チケットを発行するサーバーです。
    • 管理サーバーkadmind を実行して管理サーバーを指定します。
    Kerberos 設定 ダイアログにより、ホストをレルムに名前解決するため、およびレルムに対する KDC の位置を決めるために、DNS を使用できます。
    このオプションが動作するためには krb5-libs および krb5-workstation パッケージがインストールされている必要があります。Kerberos の詳細は、Fedora 17 Managing Single Sign-On and Smart Cards ガイドのセクション Using Kerberos を参照してください。
  • LDAP パスワード — このオプションにより、標準的な PAM 対応アプリケーションが LDAP のユーザーアカウント設定において指定されたオプションを用いて LDAP 認証を使用するよう指示します。このオプションを使用するとき、 ldaps:// サーバーアドレスを提供する、または LDAP 認証の TLS をしようする必要があります。

SSSD サービスの設定

SSSD サービスが LDAP および Kerberos サーバーに対するクライアントとして使用されます。このように、オフラインログインが有効化され、標準でサポートされます。ユーザーの対話が 認証設定ツール で SSSD サービスをセットアップする必要がありません。SSSD サービスに関する詳細は「The System Security Services Daemon (SSSD)」を参照してください。

NIS

NIS オプションは、ユーザーとパスワードの認証のために NIS サーバーに (NIS クライアント) として接続するよう、システムを設定します。このオプションを設定するには、NIS ドメインと NIS サーバーを指定します。NIS サーバーが指定されていないと、デーモンがブロードキャストにより発見しようとします。
ypbind パッケージがこのオプションの正常動作のためにインストールされている必要があります。NIS ユーザーアカウントデータベースが使用されていると、portmap および ypbind サービスが起動され、ブート時の起動を有効化する必要があります。
NIS の詳細は、Fedora セキュリティガイド のセクション "NIS のセキュア化" を参照してください。
NIS は次の認証方法を提供します。
  • Kerberos パスワード — このオプションにより Kerberos 認証が有効化されます。Kerberos 認証方法の設定に関する詳細は、LDAP に関する前のセクションを参照してください。
  • NIS パスワード — このオプションは NIS 認証を有効にします。NIS はユーザーを認証するために認証情報を外部のプロセスに提供できます。

Winbind

Winbind オプションはシステムが Windows Active Directory または Windows ドメインコントローラーに接続するよう設定します。指定されたディレクトリーまたはドメインコントローラーからのユーザー情報がアクセスされます。また、サーバー認証オプションが設定できます。以下の仕様が含まれます:
  • Winbind ドメイン — 接続する Windows Active Directory またはドメインコントローラーを指定します。
  • セキュリティモデル — Samba クライアントの動作モードを設定する、セキュリティモデルを選択できます。ドロップダウンリストは、以下のどれかを選択できます:
    • ads — このモードは Active Directory Server (ADS) レルムにおいてドメインメンバーとして動作するよう Samba に指示します。このモードにおいて動作するには、krb5-server パッケージがインストールされている必要があります。また、Kerberos が正しく設定されている必要があります。
    • domain — このモードでは、Windows NT サーバーと同じように、Samba は Windows NT プライマリまたはバックアップドメインコントローラーを通して認証することにより、ユーザー名とパスワードを検証しようとします。
    • server — このモードでは、Samba は他の SMB サーバー (たとえば、Windows NT Server) を通して認証することにより、ユーザー名・パスワードを検証しようとします。これに失敗すると、代わりに user モードが効果を持ちます。
    • user — これが標準のモードです。このレベルのセキュリティを用いると、クライアントはまず有効なユーザー名とパスワードでログインします。暗号化されたパスワードはこのセキュリティモードにおいても使用できます。
  • Winbind ADS Realmads セキュリティモデルが選択されたとき、Samba サーバーがドメインのメンバーとして動作する ADS レルムを指定できます。
  • Winbind Domain Controllerswinbind が使用するドメインコントローラーを指定するために、このオプションを使用します。ドメインコントローラーに関する詳細は、「Domain Controller」を参照してください。
  • テンプレートシェル — Windows NT ユーザーの情報を記入するとき、winbindd デーモンがユーザーのログインシェルを指定するために、ここで選択された値を使用します。
  • オフラインログインを許可する — このオプションをチェックすることにより、認証情報を (SSSD により提供される) ローカルキャッシュに保存できるようになります。オフラインの間にユーザーが認証を試行したときに、この情報が使用されます。
winbindd サービスに関する詳細は 「Samba デーモンと関連サービス」 を参照してください。
Winbind は一つの認証方式 Winbind パスワードのみを提供します。この方式の認証は、Windows Active Directory または Windows ドメインコントローラーに接続するために、Winbind のユーザーアカウント設定において指定されたオプションを使用します。

9.1.2. 高度なオプション

このタブにより、以下にあるような高度なオプションを設定できます。
高度なオプション
図9.2 高度なオプション

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

  • 指紋読み取り装置のサポートの有効化 — このオプションをチェックすることにより、指紋読み取り装置を用いて指紋を読み取ることによりログインするために、指紋認証を有効化します。
  • ローカルアクセス制御を有効化する — 有効にされたとき、ユーザーの認証のために /etc/security/access.conf が参照されます。
  • パスワードハッシュ化アルゴリズム — このオプションにより、ローカルに保存されるパスワードを暗号化するために使用されるハッシュ化または暗号化アルゴリズムを指定できます。

その他の認証オプション

初回ログイン時にホームディレクトリーを作成する — 有効にされているとき、ユーザーがログインしたときにホームディレクトリーが存在しないと、自動的に作成されます。

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

スマートカードのサポートの有効化 — このオプションによりスマートカード認証が有効化されます。スマートカード認証により、スマートカードと関連した証明書およびキーを使用してログインできます。
スマートカードのサポートの有効化 オプションがチェックされているとき、以下のオプションが指定できます:
  • カード抜き取り動作 — このオプションは、カードが有効な間にカードリーダーから抜き取られたときに、システムが実行する動作を定義します。2 つの代替が利用可能です:
    • Ignore — カードの取り出しが無視され、システムは通常どおり動作し続けます。
    • Lock — 現在のセッションがただちにロックされます。
  • スマートカードログインの要求 — ユーザーにスマートカードを用いたログインと認証をするよう要求します。本質的に他の種類のパスワード認証を無効化します。このオプションは、スマートカードを使用して正常にログインした後、選択されません。
pam_pkcs11 および coolkey パッケージはこのオプションが機能するためにインストールされている必要があります。スマートカードに関する詳細は Red Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards Guide を参照してください。

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

復元をクリックすることにより、認証設定ツールにおいて指定されたオプションを前に設定した内容にすべて復元できます。

9.1.3. コマンドライン版

認証設定ツールはコマンドラインインターフェースもサポートします。コマンドラインのバージョンは、設定スクリプトまたは kickstart スクリプトにおいて使用できます。認証オプションは表9.1「コマンドラインのオプション」にまとめられています。

サポートされる認証オプションの一覧取得方法

これらのオプションは、authconfig マニュアルページ、またはシェルプロンプトにおいて authconfig --help と入力することにより、参照できます。
表9.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 LDAP ユーザー情報の検索のために RFC-2307bis スキーマの使用を有効にします
--disablerfc2307bis LDAP ユーザー情報の検索のために RFC-2307bis スキーマの使用を無効にします
--enableldapauth 認証の LDAP を有効にする
--disableldapauth 認証の LDAP を無効にする
--ldapserver=server LDAP サーバーを指定する
--ldapbasedn=dn LDAP ベース DN (Distinguished Name) を指定します
--ldaploadcacert=URL 指定された CA 証明書を読み込みます
--enablekrb5 認証のために Kerberos を有効にします
--disablekrb5 認証のために Kerberos を無効にします
--krb5kdc=server Kerberos KDC サーバーを指定します
--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 指定された管理者として winbind ドメインまたは ADS レルムに参加します。
--enablewinbindoffline オフライン ログインを許可する winbind の設定
--disablewinbindoffline オフライン ログインを防ぐ winbind の設定
--smbsecurity=user|server|domain|ads Samba および Winbind サービスに対して使用するセキュリティモードです
--smbrealm=realm securityads に設定されているとき、Samba および Winbind サービスの初期レルムです。
--enablewins ホスト名解決で Wins を有効にする
--disablewins ホスト名解決で Wins を無効にする
--enablesssd ユーザー情報の SSSD を有効にする
--disablesssd ユーザー情報の SSSD を無効にする
--enablecache nscd を有効にする
--disablecache nscd を無効にする
--enablelocauthorize ローカル認証はローカルユーザーに対して十分です。
--disablelocauthorize ローカルユーザーはリモートサービスを用いても認証されます。
--enablesysnetauth ネットワーク サービスでシステム アカウントを認証する
--disablesysnetauth ローカルのファイルのみでシステム アカウントを認証する
--enablepamaccess アカウントの認可中に /etc/security/access.conf をチェックします
--disablepamaccess アカウント認可中に /etc/security/access.conf を確認しません
--enablemkhomedir 初回ログイン時にユーザーのホームディレクトリーを作成します
--disablemkhomedir 初回ログイン時にユーザーのホームディレクトリーを作成しません
--enablesmartcard スマートカードでの認証を有効にする
--disablesmartcard スマートカードでの認証を無効にする
--enablerequiresmartcard 認証にスマートカードを要求する
--disablerequiresmartcard 認証にスマートカードを要求しない
--smartcardmodule=module 標準でスマートカードを使う
--smartcardaction=0=ロック|1=無視 スマートカードの抜き取りを検知したときのアクションです
--enablefingerprint 指紋認証を有効にします
--disablefingerprint 指紋認証を無効にします
--nostart portmap, ypbind, または nscd サービスが設定されているときでも、それらを開始または停止しません
--test 新しい設定の表示のみで設定ファイルの更新をしない
--update, --kickstart --test と反対に、変更された設定で設定ファイルを更新します
--updateall 全設定ファイルを更新する
--probe ネットワークデフォルトを調査して表示する
--savebackup=name 全設定ファイルのバックアップを保存する
--restorebackup=name 全設定ファイルのバックアップを復元する
--restorelastbackup これまでの設定変更の前に保存された設定ファイルのバックアップを復元します

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

9.2.1. SSIDとは?

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.

9.2.2. SSIDの特徴

9.2.2.1. オフライン認証

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.

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

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

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

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

9.2.2.6. 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.
9.2.2.6.1. ダイナミックDNSアップデートのサポート
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.
ダイナミックDNSアップデート設定
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.

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

9.2.3.1. 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.
9.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
9.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

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

9.2.4. サービスの設定

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.

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

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

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

9.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」.

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

9.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」.

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

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

9.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」.

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

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

9.2.8. トラブルシューティング

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.

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

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

9.2.8.3. Problems with SSSD Service Configuration

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

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

9.2.8.5. その他のリソース

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

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

第10章 OpenSSH

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

10.1. SSH プロトコル

10.1.1. なぜ SSH を使うのか?

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

10.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) 実装を用いて認証するよう設定できます。

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

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

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

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

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

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

10.1.4.1. トランスポート層

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

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

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

10.1.4.2. 認証

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

10.1.4.3. チャネル

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

10.2. OpenSSH の設定

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

10.2.1. 設定ファイル

2種類の設定ファイルがあります: クライアント・プログラム用のもの (つまり、sshscp および sftp)、およびサーバー用のもの (sshd デーモン)。
システム全体の SSH 設定ファイルは /etc/ssh/ ディレクトリに保存されてます。詳細は表10.1「システム全体の設定ファイル」を参照してください。
表10.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/ ディレクトリに保存されます。詳細は表10.2「ユーザー固有の設定ファイル」を参照してください。
表10.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 のマニュアルページを参照してください。

10.2.2. OpenSSH サーバーの起動

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

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

10.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 において、サービスを設定する方法の詳細は8章サービスおよびデーモンを参照してください。

10.2.4. キー認証の使用

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

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

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

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

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

10.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 の設定」を参照してください。

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

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

10.2.4.2. ssh-agent の設定

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

10.3. OpenSSH クライアント

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

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

10.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
正しいパスワードが入力された後、ユーザー名が表示され、ローカルのシェルプロンプトに戻ってきます。

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

10.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 により使用されるコマンドと似たようなもののセットが利用可能です(表10.3「利用可能な sftp コマンドの選定品」を参照してください)。
表10.3 利用可能な sftp コマンドの選定品
コマンド 説明
ls [directory] リモートの directory の内容を一覧表示します。何も指定されなければ、デフォルトで現在の作業ディレクトが使われます。
cd directory リモートの作業ディレクトリを directory に変更します。
mkdir directory リモートの directory を作成します。
rmdir path リモートの directory を削除します。
put localfile [remotefile] localfile をリモートマシンに転送します。
get remotefile [localfile] remotefile をリモートマシンから転送します。

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

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

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

10.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 &
プリンター設定ツールが表示され、リモートユーザーがリモートシステムにある印刷環境を安全に設定できるようになります。

10.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 サービスを再起動するにより、この機能を無効にできます。

10.5. 追加のリソース

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

10.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 デーモンの利用可能な設定オプションの完全な説明を持つマニュアルページです。

10.5.2. 役に立つ Web サイト

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


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

パート V. サーバー

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

目次

11. DHCP サーバー
11.1. DHCP を使用する理由
11.2. DHCP サーバーの設定
11.2.1. 設定ファイル
11.2.2. リースデータベース
11.2.3. サーバーの起動と停止
11.2.4. DHCP リレーエージェント
11.3. DHCP クライアントの設定
11.4. Configuring a Multihomed DHCP Server
11.4.1. ホストの設定
11.5. IPv6 向け DHCP (DHCPv6)
11.6. その他のリソース
11.6.1. インストールされているドキュメント
12. DNS サーバー
12.1. DNS の概要
12.1.1. ネームサーバーゾーン
12.1.2. ネームサーバーのタイプ
12.1.3. ネームサーバーとしての BIND
12.2. BIND
12.2.1. named サービスの設定
12.2.2. ゾーンファイルの編集
12.2.3. rndc ユーティリティの使用法
12.2.4. dig ユーティリティの使用
12.2.5. BIND の高度な機能
12.2.6. よくある間違いを避けるために
12.2.7. その他のリソース
13. ウェブ サーバー
13.1. Apache HTTP サーバー
13.1.1. 新機能
13.1.2. 注目すべき変更
13.1.3. 設定の更新
13.1.4. httpd サービスの実行方法
13.1.5. 設定ファイルの編集
13.1.6. Working with Modules
13.1.7. 仮想ホストのセットアップ
13.1.8. SSL サーバーのセットアップ
13.1.9. その他のリソース
14. メールサーバー
14.1. 電子メールプロトコル
14.1.1. メール トランスポートのプロトコル
14.1.2. メール アクセスのプロトコル
14.2. 電子メールプログラム分類
14.2.1. メール転送エージェント (Mail Transport Agent)
14.2.2. メール配送エージェント (Mail Delivery Agent)
14.2.3. メール ユーザー エージェント
14.3. Mail Transport Agent
14.3.1. Postfix
14.3.2. Sendmail
14.3.3. Fetchmail
14.3.4. Mail Transport Agent (MTA) の設定
14.4. メール配送エージェント
14.4.1. Procmail の設定
14.4.2. Procmail レシピ
14.5. メールユーザーエージェント
14.5.1. 通信のセキュリティ
14.6. その他のリソース
14.6.1. インストールされているドキュメント
14.6.2. 役に立つ Web サイト
14.6.3. 関連書籍
15. ディレクトリー サーバー
15.1. OpenLDAP
15.1.1. Introduction to LDAP
15.1.2. OpenLDAP 製品群のインストール
15.1.3. OpenLDAP サーバーの設定法
15.1.4. Running an OpenLDAP Server
15.1.5. システムが OpenLDAP を使用して認証を実行するように設定する
15.1.6. その他のリソース
16. ファイルサーバーおよびプリントサーバー
16.1. Samba
16.1.1. Samba の概要
16.1.2. Samba デーモンと関連サービス
16.1.3. Samba シェアへの接続
16.1.4. Samba サーバーの設定
16.1.5. Samba の開始と停止
16.1.6. Samba サーバー形式と smb.conf ファイル
16.1.7. Samba のセキュリティモード
16.1.8. Samba のアカウント情報データベース
16.1.9. Samba ネットワークブラウジング
16.1.10. CUPS 印刷サポートを使った Samba
16.1.11. Samba ディストリビューションプログラム
16.1.12. その他のリソース
16.2. FTP
16.2.1. ファイル伝送プロトコル
16.2.2. FTP サーバー
16.2.3. Files Installed with vsftpd
16.2.4. vsftpd の開始と停止
16.2.5. vsftpd 設定オプション
16.2.6. その他のリソース
16.3. プリンタの設定
16.3.1. Starting the Printer Configuration Tool
16.3.2. Starting Printer Setup
16.3.3. ローカルプリンタの追加
16.3.4. Adding an AppSocket/HP JetDirect printer
16.3.5. IPP プリンタの追加
16.3.6. Adding an LPD/LPR Host or Printer
16.3.7. Adding a Samba (SMB) printer
16.3.8. プリンタモデルの選択と終了
16.3.9. Printing a test page
16.3.10. 既存プリンタの変更
16.3.11. その他のリソース

第11章 DHCP サーバー

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

11.1. DHCP を使用する理由

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

11.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 ファイルも使用します。詳細は「リースデータベース」を参照してください。

11.2.1. 設定ファイル

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

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

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

omshell コマンドを使用する

DHCP 設定ファイルを変更して、毎回サービスを再起動する代わりに、omshell コマンドを使用することにより、DHCP サーバーに接続し、その設定を問い合わせ、変更する非対話式の方法が提供されます。omshell を使用することにより、すべての変更はサーバーが実行中に反映されます。omshell の詳細は omshell マニュアルページを参照してください。
例11.1「サブネット宣言」において、routers, subnet-mask, domain-search, domain-name-servers, および time-offset オプションはその下に宣言されたすべての host ステートメントに対して使用できます。
さらに、subnet が宣言され、subnet 宣言がネットワークにあるすべてのサブネットに対して含めなければいけません。もしなければ、DHCP サーバーが起動に失敗します。
この例では、サブネットと宣言された range においてすべての DHCP クライアントに対する全体オプションがあります。クライアントは range の中にある IP アドレスが割り当てられます。
例11.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 サーバーを設定するには、値を持つ例11.2「range パラメーター」を変更します。デフォルトの払い出し期間、最大の払い出し期間、およびクライアントに対するネットワーク設定値を宣言します。この例はクライアントシステムに対して range 192.168.1.10 と 192.168.1.100 にある IP アドレスを割り当てます。
例11.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 例11.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 はホスト名をクライアントに割り当てるために使用されます。
例11.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 例11.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.
例11.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 例11.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.
例11.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.

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

11.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 においてサービスを設定する方法の詳細は8章サービスおよびデーモンを参照してください。
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 — デーモンを起動するときに全体の著作権メッセージを表示しません。

11.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.
DHCP リレーエージェントを開始するには、以下のコマンドを使用します:
systemctl start dhcrelay.service

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

11.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 デーモンは開始に失敗します。

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

11.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.
DHCPv6 サーバーの設定ファイルは /etc/dhcp/dhcpd6.conf に見つけられます。
The sample server configuration file can be found at /usr/share/doc/dhcp-version/dhcpd6.conf.sample.
DHCPv6 サービスを開始するには、以下のコマンドを使用します:
systemctl start dhcpd6.service
DHCPv6 サーバーの簡単な設定ファイルはこのように見えます:
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";
}

11.6. その他のリソース

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

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

  • dhcpd マニュアルページ — DHCP デーモンがどうように動作するかを説明します。
  • dhcpd.conf man page — Explains how to configure the DHCP configuration file; includes some examples.
  • dhcpd.leases マニュアルページ — リースの永続的なデータベースを説明しています。
  • dhcp-options man page — Explains the syntax for declaring DHCP options in dhcpd.conf; includes some examples.
  • dhcrelay マニュアルページ — DHCP リレーエージェントおよびその設定オプションを説明しています。
  • /usr/share/doc/dhcp-version/ — 現在のバージョンの DHCP サービスに関するサンプルファイル、README ファイル、およびリリースノートがあります。

第12章 DNS サーバー

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

12.1. DNS の概要

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

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

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

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

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

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

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

12.2. BIND

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

12.2.1. named サービスの設定

named サービスが起動するとき、表12.1「named サービス設定ファイル」において説明されているように、ファイルから設定が読み込まれます。
表12.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.

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

以下の種類の宣言が一般的に /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 表12.2「事前定義済みアクセス制御リスト」.
表12.2 事前定義済みアクセス制御リスト
キーワード 説明
any すべての IP アドレスに一致します。
localhost ローカルシステムにおいて使用中のすべての IP アドレスに一致します。
localnets ローカルシステムが接続されているすべてのネットワークにある IP アドレスに一致します。
none どの IP アドレスにも一致しません。

The acl statement can be especially useful with conjunction with other statements such as options. 例12.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.
例12.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.
例12.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 表12.3「一般的に使用されるオプション」 below.
表12.3 一般的に使用されるオプション
オプション 説明
allow-query ネームサーバーに権威リソースレコードを問い合わせできるホストを指定します。アクセス制御リスト、IP アドレスの組、または CIDR 表記のネットワークを受け付けます。すべてのホストがデフォルトで許可されます。
allow-query-cache ネームサーバーに再帰問い合わせのような権威のないデータを問い合わせできるホストを指定します。localhost および localnets のみがデフォルトで許可されます。
blackhole ネームサーバーに問い合わせを許可されないホストを指定します。このオプションは特定のホストやネットワークがサーバーをリクエストであふれさせるときに使われるべきです。デフォルトのオプションは none です。
directory named サービスの作業ディレクトリを指定します。デフォルトオプションは /var/named/ です。
dnssec-enable DNSSEC 関連リソースレコードを返すかどうかを指定します。デフォルトオプションは yes です。
dnssec-validation リソースレコードが DNSSEC 経由で認証されることを検証するかどうかを指定します。初期オプションは yes です。
forwarders 要求を解決するために転送されるネームサーバーの有効な IP アドレス一覧を指定します。
forward
forwarders ディレクティブの挙動を指定します。以下のオプションを受け取ります:
  • 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
ゾーンが更新されたときに、セカンダリーネームサーバーに通知するかどうかを指定します。以下のオプションを受け付けます:
  • yes — サーバーはすべてのセカンダリーネームサーバーに通知します。
  • no — サーバーはどのセカンダリーネームサーバーにも通知しません
  • master-only — サーバーはゾーンのマスターサーバーのみに通知します。
  • explicit — zone 文の中の also-notify 一覧に指定されているセカンダリーサーバーのみに通知します。
pid-file named サービスにより作成されるプロセス ID ファイルの位置を指定します。
recursion 再帰的サーバーとして動作するかどうかを指定します。オプションの初期値は yes です。
statistics-file 統計ファイルの代替位置を指定します。/var/named/named.stats ファイルが標準で使用されます。

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.
例12.3 options 宣言の使用法
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 表12.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 「ゾーンファイルの編集」.
表12.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
ゾーンが更新されたときに、セカンダリーネームサーバーに通知するかどうかを指定します。以下のオプションを受け付けます:
  • yes — サーバーはすべてのセカンダリーネームサーバーに通知します。
  • no — サーバーはどのセカンダリーネームサーバーにも通知しません
  • master-only — サーバーはゾーンのマスターサーバーのみに通知します。
  • explicit — zone 文の中の also-notify 一覧に指定されているセカンダリーサーバーのみに通知します。
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 例12.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.
例12.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 例12.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.
例12.5 A zone statement for a secondary nameserver
zone "example.com" {
  type slave;
  file "slaves/example.com.zone";
  masters { 192.168.0.1; };
};

12.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 — 使用されるアルゴリズムの種類 (たとえば、hmac-md5)。
  • secret "key-value" — 暗号化キー。
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 「複数ビュー」.

12.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 */

12.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.
表12.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.
すべてのディレクティブとリソースレコードは、個々の行に記載する必要があります。

12.2.2.1. 一般的なディレクティブ

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.
例12.6 $INCLUDE ディレクティブの使用法
$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 例12.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.
例12.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.
この値を増加させると、リモートネームサーバーは、このゾーンの情報をより長時間キャッシュします。こうすると、このゾーンについて行われるクエリの数は減りますが、リソースレコード変更を伝えるのに要する時間は長くなります。
例12.8 $TTL ディレクティブの使用
$TTL 1D

12.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 例12.9「A リソースレコードの使用法」, the requests for server1.example.com are pointed to 10.0.1.3 or 10.0.1.5.
例12.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 例12.10「CNAME リソースレコードの使用法」, the A record binds a hostname to an IP address, while the CNAME record points the commonly used www hostname to it.
例12.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 例12.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.
例12.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.
例12.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). 表12.6「他の時間単位と比較した秒数」 shows an amount of time in seconds and the equivalent time in another format.
表12.6 他の時間単位と比較した秒数
他の時間単位
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D

例12.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

12.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 週間後に期限切れ

12.2.2.4. 使用例

以下の例はゾーンファイルの基本的な使用法を示しています。
12.2.2.4.1. 簡単なゾーンファイル
例12.14「簡単なゾーンファイル」は標準的なディレクティブと SOA 値の使用法を説明します。
例12.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; };
};
12.2.2.4.2. 逆引き名前解決ゾーンファイル
逆引き名前解決ゾーンファイルは、特定の名前空間にある IP アドレスを完全修飾ドメイン名(FQDN)に変換するために使用されます。これは、例12.15「逆引き名前解決ゾーンファイル」にあるよように、PTR リソースレコードが IP アドレスを完全修飾ドメイン名にリンクするために使用されることを除いて、標準的なゾーンファイルによく似ています。
例12.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.

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

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

12.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.
表12.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

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

named サービスの現在の状態を確認するには、以下のコマンドを使用します:
~]# 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

12.2.3.3. 設定およびゾーン情報の再読み込み

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
最後に、設定ファイルを読み込み、新しく追加されたゾーンのみを追加するには、次のように入力します:
~]# rndc reconfig

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

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

12.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;
};

12.2.3.5. DNSSEC 検証の有効化

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

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

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

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

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

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

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

12.2.4.2. IP アドレスの検索

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

12.2.4.3. ホスト名の検索

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

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

機能がサポートされていることを確認します

DNSSEC, TSIG, た IXFR のような高度な機能を使用しようとする前に、とくに古いバージョンの BIND や BIND 以外のサーバーを使用するときに、その機能がネットワーク環境にあるすべてのネームサーバーにおいてサポートされていることを確認してください。
All of the features mentioned are discussed in greater detail in the BIND 9 Administrator Reference Manual referenced in 「インストールされているドキュメント」.

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

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

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

12.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).

12.2.5.5. インターネットプロトコル・バージョン 6 (IPv6: Internet Protocol version 6)

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

12.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.
ファイアウォールを設定します
ファイアウォールが named サービスから他のネームサーバーへの接続をブロックするならば、推奨される最善策はできる限りファイアウォールの設定を変更することです。

固定 UDP ポートの使用を避けます

DNS セキュリティに関する最近の研究によると、DNS の問い合わせに固定 UDP ポートを使用することは、潜在的なセキュリティ脆弱性となります。これは、攻撃者がより簡単にキャッシュポイズニングを引き起こせます。これを防ぐには、ファイアウォールがランダム UDP ソースポートから問い合わせをできるように設定します。

12.2.7. その他のリソース

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

12.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/
BIND に関連するすべての RFC ドキュメントを提供しているディレクトリーです。
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.

12.2.7.2. 役に立つ Web サイト

http://www.isc.org/software/bind
BIND 9 Administrator Reference Manual の PDF バージョンなど現在のリリースに関する情報が含まれている、BIND プロジェクトのホームページです。

第13章 ウェブ サーバー

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

13.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 17. 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.
Apache HTTP Server 2.2 とバージョン 2.0 の間には大きな変更点があります。以前のリリースの Fedora からアップグレードしているならば、必要に応じて httpd サービス設定を更新する必要があります。このセクションは、いくつかの新しく追加された機能、重要な変更点の概要、および古い設定ファイルの更新について詳しく説明しているガイドを概観します。

13.1.1. 新機能

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

13.1.2. 注目すべき変更

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

13.1.3. 設定の更新

Apache HTTP Server バージョン 2.0 から設定ファイルを更新するには、以下の手順に従ってください:
  1. モジュールの名前が変更されているかもしれないので、すべてのモジュールの名前が正しいことを確認してください。名前が変更された各モジュールについて LoadModule ディレクティブを調整してください。
  2. すべてのサードパーティのモジュールは読み込む前に再コンパイルしてください。一般的には認証と認可のモジュールが当てはまります。
  3. もし mod_userdir モジュールを使用するならば、ディレクトリ名(一般的に public_html)を指示する UserDir ディレクティブを確実に提供してください。
  4. Apache HTTP Secure Server を使用するならば、Secure Sockets Layer (SSL) プロトコルを有効にするために /etc/httpd/conf.d/ssl.conf を編集します。
以下のコマンドを使用して、起こりうるエラーについて設定を確認できることに注意してください:
service httpd configtest
Apache HTTP Server のバージョン 2.0 から 2.2 に設定を更新することに関する詳細は http://httpd.apache.org/docs/2.2/upgrading.html を参照してください。

13.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 8章サービスおよびデーモン.

13.1.4.1. サービスの開始

httpd サービスを実行するには、シェルプロンプトにおいて root として次のとおり入力します:
systemctl start httpd.service
ブート時にサービスを自動的に開始したければ、以下のコマンドを使用します:
systemctl enable httpd.service
Fedora においてサービスを設定する方法に関する詳細は8章サービスおよびデーモンを参照してください。

セキュアなサーバーの使用法

セキュアサーバーとして Apache HTTP Server を実行しているならば、暗号化されたプライベート SSL キーを使用していると、マシンが起動した後にパスワードが要求されます。

13.1.4.2. さービスの停止

実行中の httpd サービスを停止するには、シェルプロンプトにおいて root として次のとおり入力します:
systemctl stop httpd.service
起動時にサービスが自動的に開始しないようにするには、次のように入力します:
systemctl disable httpd.service
Fedora においてサービスを設定する方法に関する詳細は8章サービスおよびデーモンを参照してください。

13.1.4.3. サービスの再開

実行中の httpd サービスを再起動するには、二つの異なる方法があります:
  1. サービスを完全に再起動するには、シェルプロンプトにおいて root として以下のとおり入力します:
    systemctl restart httpd.service
    これは実行中の httpd サービスを停止して、その後再び開始します。PHP のように動的に読み込まれるモジュールをインストールまたは削除した後、このコマンドを使用します。
  2. ただ設定を再読み込みするには、root として、次のように入力します:
    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. 処理中の内容に影響を与えることなく設定を再読み込みするには、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.
Fedora においてサービスを設定する方法に関する詳細は8章サービスおよびデーモンを参照してください。

13.1.4.4. サービスの状態確認

サービスが実行中であるかどうかを確認するには、シェルプロンプトにおいて次のとおり入力します:
systemctl is-active httpd.service
Fedora においてサービスを設定する方法に関する詳細は8章サービスおよびデーモンを参照してください。

13.1.5. 設定ファイルの編集

httpd サービスが開始するとき、表13.1「httpd サービス設定ファイル」に一覧化されている位置から設定が読み込まれます。
表13.1 httpd サービス設定ファイル
パス 説明
/etc/httpd/conf/httpd.conf 中心となる設定ファイルです。
/etc/httpd/conf.d/ メインの設定ファイルに含まれる、設定ファイルの任意のディレクトリーです。

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.
起こりえるエラーに対して設定を確認するには、シェルプロンプトにおいて次のとおり入力します:
service httpd configtest
より簡単に誤りから復旧するために、元のファイルを編集する前にコピーしておくことを推奨します。

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

以下のディレクティブは一般的に /etc/httpd/conf/httpd.conf 設定ファイルにおいて使用されます:
<Directory>
<Directory> ディレクティブにより、特定のディレクティブを特定のディレクトリーのみに適用できます。以下の形式をとります:
<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).
例13.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.
例13.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.
例13.3 <IfModule> ディレクティブの使用法