Product SiteDocumentation Site

2. Fedora の変更点 - システム管理者向け

2.1. カーネル

Fedora 18 はカーネル 3.6.0 を特徴とします。

2.2. インストール

2.2.1. Windows 8 とのデュアルブート

Windows 8 Fast Restart

Windows 8 の機能である fast restart を使って Fedora を再起動する場合、データ損失に繋がる可能性があります。Windows 8 を再起動する場合に Fedora によって Windows パーティションに書き込まれたデータは削除されることがあります。この問題は Windows 8fast restart 機能を無効にすることで回避できます。
Fedora 18 で NTFS ファイルシステムのために使われる ntfs-3g ドライバーは、危険な状況を検出して、データ喪失を防ぐためにマウントを拒絶しようとします。これは、以前の Fedora リリースでは、行われていません。正常な動作とデータ喪失を防ぐために、fast restart は無効にされるべきです

2.2.2. インストーラーの新しいユーザーインタフェース

Fedora 18 では、 anaconda インストーラーが、完全に再設計されました。ユーザーは、自分のインストールの設定をより柔軟にできるようになりました。いくつかのタスクは、バックグラウンドで実行され、インストール処理を高速にします。詳しくは、https://docs.fedoraproject.org にある、Fedora 18 インストールガイド を参照下さい。

2.2.3. パッケージグループ名を変更

kickstart インストールをする方へ。Fedora 18 では、多くのパッケージグループ名が変更されました。特に、Base グループは、 Standard になりました。このグループをインストールするためには、 明示的にkickstart ファイルに書く必要があります。

2.2.4. --nobase フラグ

Base パッケージグループのインストールを抑制する --nobase フラグは廃止されました。

2.2.5. fedUP でアップグレード

2.2.5.1. fedUP とは何ですか?
Fedup は、Fedora インストールをアップグレードするための新しいツールで、以前の Fedora リリースで使われてきた、preupgrade や、DVD によるアップグレード操作を置き換えるものです。それは、アップグレード処理の多くに systemd を活用し、最終的には、DVD からパッケージを読み込んで、特別に作られるサイドレポジトリではなく、通常のインストールリポジトリを使ってインストールが可能となる予定です。
2.2.5.2. アップグレードの仕方
以下は、 fedup を使い、F17 から F18 へアップグレードする現在の手順です。以下の記述は、手順が進化するにつれて、変化することがあります。

sudo または root

以下にあげるコマンドは、 sudo を使いますが、 root として実行されてもかまいません。
Fedora 17 システムに、yum を使って、fedup をインストールできます。
yum install fedup
2.2.5.3. fedUP の使い方
fedup-cli コマンドで、アップグレードを準備するには、以下のコマンドを使います。

正しい URL を使う

Fedora 18 ベータにアップグレードするためのパブリックな Fedora リソースを使うには、以下の [insert-arch-here] をあなたがアップグレードしようとしているアーキテクチャ、x86_64 あるいは i386 に変えます。最終リリースでは、--instrepo を明示的に宣言する必要はなくなるはずです。
sudo fedup-cli --network 18 --debuglog fedupdebug.log --instrepo=http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/[insert-arch-here]/os/
この時点で、 Fedora 17 システムは、アップグレードの準備ができました。
2.2.5.4. アップグレードの実行中
リブートすると、「System Upgrade」ブートオプションが、 grub のプロンプトに現れます。これは、デフォルトではなく、アップグレード処理を続行するためには、手で選択しないといけないことに注意下さい。ベータのときには、ブート引数に、plymouth.splash=fedup を追加すると、アップグレードの間、グラフィカルな処理スクリーンが表示されます。最終リリースでは、これがデフォルトになります。すべてがうまくいったら、いくつかのブートメッセージが見えるかもしれませんが、最終的に、 fedup plymouth テーマが見えるはずです。

ここでコーヒータイム

アップグレード処理は、通常、しばらくかかります。(システムによりますが、45から90分の間)辛抱強く、それが終わるまで待って下さい。アップグレードが完了すると、システムは新しいバージョンの Fedora へとブートします。
2.2.5.5. アップグレードシェルの有効化
アップグレードのデバッグシェルを有効にするには、System Upgrade ブートオプションを選択して、カーネルブート引数の最後に、 rd.upgrade.debugshell を追加します。

アップデート中の高度なロギング

デバッグシェル以外にも、以下のカーネルブートパラメターが、デバッグのために便利です。
rd.debug systemd.log_target=console systemd.jounald.forward_to_console=1 systemd.log_level=debug console=tty0 console=ttyS0,115200n8
デバッグシェルにアクセスするには、 VT2 (ctl-alt-F2) にスイッチします。アップグレード処理が開始してからでないと、デバッグシェルにはアクセスできないため、スイッチするには、2,3分、待つのが良いでしょう。
一度、仮想端末の VT2 に切り替えて、dracut プロンプトを確認します。
dracut#
実際のアップグレードデバッグシェルに入るためには、現在実行中のシェルを終了して、(他のが、すぐに開始します。) initramfs にあるすべてのバイナリーにアクセスできるようにします。
exit
アップグレードの進捗を確認したい場合、次のファイルを確認します。
cat /sysroot/var/log/upgrade.out
もしシステムログを確認したい場合、journalctl コマンドを使います。
journalctl -a -o cat

2.3. ブート

2.3.1. オフラインシステムアップデート

PackageKitsystemd は合同で、クリティカルなシステムアップデートを適用するための安定したオフラインの環境を提供します。特別のターゲットにブートすることで、これらのアップデートは実行中のシステムと競合することなく適用されます。

2.3.2. /etc/sysconfig ファイルのいくつかが廃止

/etc/sysconfig のいくつかのファイルは廃止されました。この変更は、ほとんどのアプリケーションには無関係です。
2.3.2.1. /etc/sysconfig/clock/etc/localtimeに置き換え
タイムゾーンの設定は、正しいタイムゾーンに /etc/localtime をシンボリックリンクすることで行われます。
利用可能なタイムゾーンの一覧を取得するには、次のコマンドを実行します:
timedatectl list-timezone
タイムゾーンを設定するには、以下のコマンドを実行します:
timedatectl set-timezone Atlantic/Reykjavik
システムは、デフォルトでは、ハードウェアクロックに UTC を使います。しかし、ローカルタイムで設定されるシステムもあります。ユーザーは、BIOS で設定を確認できます。システムクロックを直接設定するには、以下のコマンドを、現在時刻と日付を指定して実行します。
set-time "2012-10-27 01:02:03"
クロックが UTC でなく、ローカルタイムを使うようにするには、このコマンドを使います。
timedatectl set-local-rtc 1
systemd と時刻の関係は、 man timedatectlman localtime を参照下さい。
2.3.2.2. /etc/sysconfig/i18n/etc/locale.confに置き換え
環境変数と設定は、/etc/locale.conf にあります。ここで設定されたロケールは、システムワイドであり、すべてのサービスやユーザーに適用されます。ただし、それぞれのプログラムやユーザーによって、再設定されたり、無効にされたりする場合は除きます。詳しくは、man locale.conf を参照下さい。
2.3.2.3. /etc/sysconfig/keyboard/etc/vconsole.confに置き換え
仮想コンソール設定は /etc/vconsole.conf になりました
2.3.2.4. ホスト名の設定は /etc/sysconfig/network から /etc/hostname へ移動
あるシステムで使われるホスト名には、3つの別々の種類があるようになりました。pretty ホスト名は、高レベルのホスト名で、デスクトップ環境やシェルでユーザーに提示されることが多いです。static ホスト名は、ブート時にカーネルが使うもので、普通は、システムの fully qualified domain name です。システムはさらに、 transient ホスト名を DHCP サーバーから与えられて持つことがあります。これらのホスト名を管理するために、hostnamectl が提供されます。
コマンド機能
hostnamectl set-hostname fedorasystem --prettypretty ホスト名を設定します
hostnamectl set-hostname fedorasystem.example.org --static静的 ホスト名を設定します
hostnamectl set-hostname fedora-dhcp-client.example.org --transient一時 ホスト名を設定します
hostnamectl set-hostname fedorasystem.example.org引数がないときは、 hostnamectl はすべてのホスト名タイプに適用されます。
hostnamectl status現在のホスト名の設定を表示します
ホスト名について詳しくは、man hostnameman hostnamectl を参照下さい。

2.4. セキュリティ

2.4.1. Active Directory はより簡単に

Fedora は Active Directory ドメイン (または IPA のような他の Kerberos レルム) において、ただちに使用できます。Fedora マシンでドメインログインを設定することは簡単で、それらのクレデンシャルを用いてログインすることも、直観的でごく自然にできるはずです。
これらの改善により、Active Directory だけではなく、すべての Kerberos レルムに対する、信頼性および使いやすさを改善します。ログインと認証のスタックにおける改善がなされてきました。これには realmdadcli が含まれます。
GNOME ユーザーアカウント 設定 GUI 機能がエンタープライズログインをサポートします。
Fedora 18 を用いると、ユーザーがあるドメインから他のドメインのリソースにアクセスできるよう、IPA と Active Directory のドメインの間に信頼関係を作成することができます。FreeIPA プロジェクトが機能を http://freeipa.org/page/IPAv3_testing_AD_trust にドキュメント化しています。

2.4.2. セキュアブート

UEFI セキュアブートが Fedora 18 においてサポートされます。これにより、セキュアブートが有効化されているシステムにおいて Fedora をブートできます。管理者が GRUB またはカーネルへのローカルな変更を署名するための、独自の証明書を作成するツールを利用可能です。

2.4.3. rngd

乱数生成が標準で rngd を有効化することにより改善されました。

2.4.4. セキュアーコンテナー

SELinux および virt-sandbox を使用すると、サービスがセキュアなサンドボックスにおいて実行できます。virt-sandbox-service パッケージがマウントポイントおよび libvirt コンテナーを作成します。

2.4.5. SELinux のブーリアンの名前変更

SELinux 論理値の目的を明確にするために、allow から始まるすべての設定がそれらのドメインを反映する名前に変更されます。既存のポリシー論理値は引き続きサポートされます。

2.4.6. SELinux Systemd アクセスコントロール

プロセスがサービスを起動または停止することを許可する前に、ユニットファイルから SELinux の設定を確認するためのサポートが、systemd に追加されました。

2.4.7. システムコールに制限

libseccomp ライブラリーが利用可能になりました。これはカーネルのシステムコールのフィルターを使用することにより、潜在的なエクスプロイトの被害を抑える簡単な方法をアプリケーションに提供します。QEMU/KVMlibseccomp を使用するので、仮想マシンがこれの恩恵を受けられます。

2.4.8. ユーザーモード

非特権ユーザーにスーパーユーザー特権を付与するラッパー usermode はpolkit に代替され、段階的に廃止されていきます。

2.4.9. Kerberos クレデンシャルの場所が移動

Fedora 18 は、セキュリティを向上し、NFSv4 のキャッシュの位置を簡単に決めるために、Kerberos クレデンシャルキャッシュの標準的な位置を /run/user/$UID に変更します。Fedora の Kerberos サポートでは、ユーザーが複数の主体についてのクレデンシャルを保持したり、GSSAPI クライアントコードが対象サービスとホスト名に基づいてクレデンシャルを自動的に選択することができるようになりました。

2.4.10. halt, poweroff, や reboot 設定が移動

非特権ユーザーにより halt(8), poweroff(8) および reboot(8) コマンドを使用する能力は polkit を使用して制御されます。/usr/share/polkit-1/actions/org.freedesktop.login1.policy にあるアクションを参照してください。もはや /etc/pam.d/{halt,poweroff,reboot} にある PAM 設定ファイルは使用されません。あったとしても、無視されます。

2.5. ファイルシステム

2.5.1. FedFS

Fedora 18 では、 複数のファイルサーバーにまたがる同期したネームスペースを提供する機能である、FedFS が加わりました。
このパッケージで提供されるコードは、テクノロジープレビューです。その意図は、完全で、サポートされる Linux での FedFS クライアントとサーバー実装を提供することです。プログラムとユーザーインタフェースは次のいくつかのリリースの間に大きく変わる可能性があります。
このパッケージのコンポーネントは、グローバルなネットワークファイルシステムのネームスペースを作るための、ファイルシステムの紹介を管理するために使われます。インストールされるコンポーネントは:
  • FedFS が有効なクライアント上で、FedFS ドメインネームスペースを管理するための、automounter プログラムマップ
  • FedFS ドメインネームスペースの一部をマウントするための mount コマンド
  • FedFS 以外のプログラムがローカルファイルシステムにおけるジャンクションを解決するための、プラグインライブラリー
  • ファイルサーバーで動作し、リモートの FedFS 管理クライアントが FedFS ジャンクションを管理できるようにする、ONC RPC サービスデーモン
  • fedfsd がなくても、ローカルジャンクションを管理できる、nfsref というツール
  • リモートのファイルサーバーでの、fedfsd 実行をアクセスできる、コマンドラインクライアントのセット
  • FedFS NSDB として動作している LDAP サーバー上の、FedFS のエントリーを管理するための、コマンドラインクライアントのセット
  • ローカルホストの NSDB コネクションパラメーターを管理するツール
  • LDAP サーバーが FedFS オブジェクトをサポートするための、 LDIF 形式のスキーマ
より詳しい情報は FedFS project の公式ページ および FedFS ドキュメント をご覧ください。

2.5.2. /tmp は、tmpfs にあります

デフォルトでは、 Fedora 18 の /tmp は、 tmpfs にあります。大きな一時的ファイルを置くのは、 /var/tmp にして下さい。そうすることで、ディスクへの I/O が削減され、SSD の寿命が伸び、電力が節約され、/tmp ファイルシステムの性能が向上します。

2.6. 仮想化

2.6.1. 仮想マシンのライブスナップショット

Fedoraの仮想化スタックは仮想マシン上のスナップショット機能を多くのリリースで搭載してきました。しかしながらその機能は、ストレージスナップショットが作成されるまで仮想マシンを一時停止・停止しなければなりませんでした。最近のアップデートが含まれるFedora 17はqemulibvirtにおいてダウンタイムなしで仮想マシンのスナップショットを作成することができます。
ライブスナップショットの作成機能は、RAW 形式のディスクイメージを利用する仮想マシンに対しても機能します。この場合、libvirt は外部の QCOW2 形式のディスクイメージを使用してスナップショットを作成します。- 新しく作成された外部のイメージ上で実行するように仮想マシンを透過的に切り替えます。

2.6.2. KVM はゲストのハイバーネートとサスペンドをサポート

サスペンドとハイバーネートは KVM 仮想マシンでも動作するようになりました。 virshを使い、ホスト上でそれらを実行することもできます。

2.6.3. oVirt 3.1 で仮想環境の管理

Fedora 17 には統合仮想化管理プラットフォーム oVirt のインストールに最小限必要なパッケージが含まれていました。この最初の提供が Fedora 18 では大幅に拡張されました。既存の機能に加えて Fedora 18では本格的な oVirt "Engine" として使用することが可能になります。oVirt "Engine" は統合仮想化環境に対してグラフィカルな管理コンソールを提供します。
プロジェクトのホームページ: http://ovirt.org.
2.6.3.1. oVirt Engine インストール
oVirt Engine は Web ブラウザーでアクセスできる管理コンソールを提供します。管理コンソールから、仮想マシンを作成したり、プロビジョニングしたり、それを利用することができます。また、仮想化環境において必要となるネットワークとストレージの管理をするための機能も提供します。oVirt の管理コンソールを体感してみたいが、仮想化ホストを動かすための予備マシンを持っていない人のために、'all in one' プラグインが提供されます。'all in one' プラグインをインストールすると oVirt Engine と仮想化ホストを同一のマシンで構成することが許可されます。
oVirt Engine をインストールする方法:
  1. oVirt Engine を稼働させたい Fedora のシステムに root ユーザーとしてログインします。
  2. yum install ovirt-engine を用いて ovirt-engine をインストールします。
  3. engine-setupスクリプトを実行し、画面の指示に従いoVirtEngineのインストールを完了します。
  4. Engine が正常にインストールできたら、スクリプトの最後で oVirt Engine Web 管理ポータルにアクセスする手順が提供されます。
2.6.3.2. 仮想化ホストのインストール
仮想化ホストとして使用するには、仮想化ホストにしたいシステムに対してそれぞれ次のようにします:
  1. Fedora 18 をインストールします。最小インストールで十分です。root ユーザーに対してパスワードが設定され、SSH が有効化されていることを確認します。
  2. Web ブラウザーを使用して、インストールした oVirt Engine Web 管理ポータルにログインします。
  3. ホストタブから追加を選択します。
  4. Fedora ホストの名前を入力します。
  5. Fedora ホストのホスト名または IP アドレス、および root のパスワードを指定します。
  6. OK をクリックします。
必要なパッケージをダウンロードおよびインストールするので、少しだけ時間がかかります。そして、Fedora ホストが環境に追加されます。
2.6.3.3. 追加情報
oVirt 3.1 のクイックスタートガイドが http://wiki.ovirt.org/wiki/Quick_Start_Guide にあります。

2.7. Web サーバー

2.7.1. httpd

httpd が 2.4.3-1 に更新されました。セキュリティ面と性能面での改善が含まれます。

2.7.2. lighttpd

lighttpd が 1.4.32-2 に更新されました。

2.8. クラウド

2.8.1. Eucalyptus

Eucalyptus により Amazon Web Services と互換性のあるプライベート Infrastructure-as-a-Service (IaaS) クラウドを作成できます。

2.8.2. OpenShift Origin

OpenShift Origin は Fedora 18 に Platform-as-a-Service (PaaS) サポートをもたらします。

2.8.3. OpenStack

Fedora 18 は最新バージョンの OpenStack IaaS クラウドサービス、コードネーム Folsom を含みます。
2.8.3.1. Heat
HeatOpenStackAWS CloudFormation API を提供するために追加されました。HeatOpenStack ユーザーがクラウドアプリケーションを記述するテンプレートファイルから OpenStack クラウドに複数のアプリケーションを起動する標準的な方法を提供します。管理者はプロジェクトの getting started guide あるいは Wiki を参照することが推奨されます。

2.8.4. OwnCloud

owncloud は、モバイルを含む、複数のデバイスでファイルを同期する、サーバーおよびクライアントを提供します。これにより、ユーザーが自分自身のファイル同期サービスを実行できます。

2.9. データベースサーバー

RiakErlang で書かれたスケーラブルかつ高信頼な noSQL データストアです。Fedora 18 において利用可能です。

2.10. ファイルサーバー

2.10.1. vsftpd

Fedora 18 には、最新の vsftpd release, version 3.0 が含まれ、以下の変更があります。
  • 新しい、とても強い制限の seccomp filter sandbox。
  • 高負荷のときの、パッシブモードのコネクションの修正。
  • SSL を使った時を含む、タイムアウトのいくつかの修正。
  • リスンモードをデフォルトとしました。

2.10.2. NFSometer

NFSometer は、多くの NFS プロトコルのバージョン、NFS オプション、 Linux NFS クライアント実装に対して、負荷を実行し、結果を報告するための、性能測定フレームワークです。詳しくは、 http://wiki.linux-nfs.org/wiki/index.php/NFSometer を参照下さい。

2.10.3. ストレージ管理

Fedora 18 には、ユーザーが自分のストレージをプログラムによって管理するためのライブラリーがいくつか含まれます。それらは、libstoragemgmttargetd です。ドキュメントは、パッケージに含まれる man ページと、 README にあります。

2.10.4. ssm: システムストレージマネージャー

Fedora 18 には、 一般的なストレージ管理作業を、統一されたコマンドラインインターフェースによって簡単にするツールである、ssm があります。このユーティリティが提供する新しい機能は、man ssm にあります。

2.11. Samba

Fedora 18 には、Samba4 が含まれます。それは、より良い、クロスプラットフォームのファイルサーバーサポートを提供します。このリリースは、新しい、 SMB2.2SMB3 プロトコルをサポートし、 FreeIPA 信頼関係サポートのための LSA サービスデーモンを含みます。python がお好きな管理者の方々は、Samba4 の新しいスクリプティングインタフェースが気に入ることでしょう。それによって、Samba の内部を、Python プログラムによってアクセスすることができます。

2.12. システムデーモン

2.12.1. SysVinit から systemd

さらに多くの SystemV init スクリプトが、systemd unit ファイルに移行して、可読性とブート時間が改善しました。

2.12.2. procps-ng で管理者ツールキットを拡張

Fedora 18 では、レガシーの procps ツールから、procps-ng への移行をしました。これにより、メンテナンスの改善、機能の拡張、そして他のディストリビューションで動作するスクリプトの互換性が改善しました。詳しくは、/usr/share/doc/procps-* にあるドキュメントを参照下さい。

2.13. サーバー構成ツール

2.13.1. Fedora に dnf が登場

dnf は、有名な yum パッケージマネージャーのフォークです。それは、hawkey を使って作られており、そのライブラリーは、現在の RPMDB の状態と yum リポジトリーに基づいて、クライアントが RPM パッケージについて問い合わせたり、依存関係を解決することができます。
Fedora 18 の dnf は、テクニカルプレビューであり、yum とは別にインストールされます。それはまだ、クリティカルな本番マシンで使うべきではありませんが、アーリーアダプターの皆さんには、より効率的で、高速なパッケージ管理をお約束します。

2.13.2. systemctl は、サービスを対象とすることが前提

サービスと、その他の systemd ターゲットを管理するためのユティリティである、systemctl は、サービスを対象とすることを前提とするようになりました。管理者は、管理したいデーモンの名前の最後に、 .service を加える必要がなくなりました。例えば、systemctl restart dhcpd は、今ではそのまま、動作しますが、以前のリリースでは、 systemctl restart dhcpd.service とする必要がありました。

2.13.3. 端末がよりカラフルに

Fedora は、デフォルトで256色を使う端末エミュレーターを導入しました。新しい環境変数を使い、gnome-terminal, konsole, や screen などのアプリケーションは、自動的に256色サポートが有効になります。他のアプリケーションも256色を表示できますが、設定が必要です。デフォルトでは、無効になっていますが、リモートシステムに接続するときのカラー端末は、環境変数 SEND_256_COLORS_TO_REMOTE によって有効に出来ます。これらの設定は、/etc/profile.d/256color.sh にあります。

2.13.4. Agent-Free Systems Management で、より良いリモート管理

IPMI 互換の Service Processors を有するシステムでは、OS と Service Processors のより緊密な統合が、サードパーティ製のソフトウエアなしに可能となりました。これにより、システムのリモート管理がより改善しました。

2.13.5. CIM 管理ツールの改善

多数のシステムを管理する管理者は、 Fedora 18 の WEBMCIM 関連の改善によって、良いスタートをきることができるでしょう。
ユーザーは、アプリケーションを、新しく、強化された CPMI プロバイダーを使って作成することができます。そして、ネットワークインタフェース、ストレージオブジェクト、サービス、電源状態、ユーザー、そしてソフトウエアパッケージなどをモニターおよび管理することができます。また、システム負荷、利用率、などもモニターできます。ツールキットは、さらに、 yawn を含み、 ウエブブラウザーを使って、CIM オブジェクトモデルをナビゲートし、作業することができます。
以上の機能は、頑強な管理インフラの基礎を提供することによって、多数のシステムを管理する作業をより簡単にするでしょう。経験豊富なユーザーと管理者の方々は、ぜひとも sblim-cmpi-* あるいは openlmi-* パッケージで提供されるサンプルの python スクリプトとドキュメントを参照下さい。

2.14. Xorg

2.14.1. Server Kernel Mode Setting (KMS) Drivers

市場に出荷されているサーバーの多くはベーシックな GPU ハードウェアが搭載されています。Fedora 18 では サーバーでよく使われる GPU 向けの Kernel Mode Setting (KMS) ドライバーが追加で含まれるようになりました。KSM ドライバーによって提供される追加機能を利用することができます。なお、新しい KMS ドライバーでサポートするチップセットとしては、AST と、 MGA ベースの ServerEngines があります。

2.14.2. GPU ホットプラグのサポート

The X.org server は GPU のホットプラグ/アンプラグの実装をリファクタリングしました。特に Fedora がサポートする多くの USB 接続のグラフィックデバイス、ノートPC向けのドッキングステーションで効果があります。このようなデバイスを使う場合に X.org server の設定を変更するために再起動する必要がなくなります。