第5章 jessie で知っておくべき問題点

目次

5.1. セキュリティサポートにおける制限事項
5.1.1. ウェブブラウザにおけるセキュリティ更新の状態
5.1.2. libv8 および Node.js 界隈のエコシステムに対するセキュリティサポートの欠落
5.1.3. MediaWiki へのセキュリティサポートの早期終了について
5.2. OpenSSH サーバーのデフォルトが "PermitRootLogin without-password" になりました
5.3. Puppet 2.7 / 3.7 の互換性
5.4. PHP 5.6 へのアップグレードは挙動の変更があります
5.5. Apache HTTPD 2.4 における互換性の無い変更
5.6. Jessie での既存 init システムから新しい標準 init システムへのアップグレードについて
5.6.1. systemd 配下での起動時のマウント失敗に対する、より厳格な取り扱い
5.6.2. 不要になった init スクリプトは完全に削除してください
5.6.3. ローカルで変更を加えた init スクリプトは systemd に移植しなければいけない可能性があります
5.6.4. plymouth は systemd 配下での起動時にブートプロンプトを必要とします
5.6.5. logind と acpid 間でのやり取り
5.6.6. systemd 配下でサポートされない crypttab 機能 (例: "keyscript=...")
5.6.7. systemd: issues SIGKILL too early [fixed in 8.1]
5.6.8. systemd: behavior of 'halt' command
5.7. Jessie で必要とされるカーネル設定オプション
5.8. LXC ホストおよびコンテナのアップグレードについての検討
5.8.1. Wheezy ホスト上で動作している LXC ゲストのアップグレード
5.8.2. Jessie ホスト上で動作している LXC ゲストのアップグレード
5.8.3. 追加情報について
5.9. LUKS whirlpool で暗号化されたディスクの手動での移行作業 (非標準設定)
5.10. GNOME デスクトップは基礎的な 3D グラフィック機能を必要とします
5.11. GNOME デスクトップは AMD のプロプライエタリな FGLRX ドライバーでは動作しません
5.12. GNOME の標準キーボードショートカットでの変更
5.13. base-passwd によって追加されているシステムユーザーの標準シェルの変更
5.14. 新しい KDE E メール・カレンダー・連絡帳 (Kontact) に移行する
5.15. 複数のデスクトップ環境で仮想コンソール ("getty") が消失する
5.16. "VGA signal out of range" / grub-pc で起動中、何も画面に表示されない
5.17. crontab 中の cron ファイルのより厳重なチェック
5.18. perl による読み込みできないモジュールパスの扱いの変更
5.19. Ganeti クラスタをアップグレードする際の検討
5.19.1. Problem upgrading Ganeti clusters with DRBD-backed instances [fixed in 8.1]
5.19.2. Ganeti クラスタのアップグレードに関する一般的な注意事項
5.20. Samba4 でのファイル実行についての新たな必要事項
5.21. cryptsetup は BUSYBOX=n では起動できなくなる可能性があります

新しいリリースに導入された変化には当然のように副作用がつきもので、どこか他の場所でバグを出してしまうこともあります。この章では、現時点で私たちが知っている問題点を記載しています。正誤表・関連パッケージの付属文書・バグ報告や、「もっと読みたい」で触れられているその他の情報も読んでください。

5.1. セキュリティサポートにおける制限事項

Debian がセキュリティ問題に対する最小限のバックポートを約束できないパッケージがいくつか存在しています。これらについては以下の項で触れられています。

Jessie で導入された debian-security-support パッケージが、インストールされたパッケージのセキュリティサポート状況を確認するのに役立ちます。

5.1.1. ウェブブラウザにおけるセキュリティ更新の状態

Debian 8 は複数のブラウザエンジンを含んでおり、これらは一定の割合でセキュリティ脆弱性の影響を受けます。高い脆弱性率と一部開発元での長期間サポートブランチの欠落によって、セキュリティ修正をバックポートしてこれらのブラウザをサポートする事が難しくなっています。さらに、ライブラリへの内部依存性のため、開発元の新しいリリースバージョンへの更新を不可能にしています。そのようなものとしては、Jessie に含まれている webkit・qtwebkit・khtml エンジンを使ったブラウザがありますが、これらは完全なセキュリティサポートはされません。一般的にこれらのブラウザを信用できないウェブサイトを閲覧するのに使うべきではありません。

通常、ウェブブラウザを利用するには、Iceweasel および Chromium をお勧めします。

Chromium は Webkit のコードベース上に構築されていますが、リーフパッケージ (他から依存されていないパッケージ) であり、安定版向けに最新の Chromium のリリースを再ビルドして更新し続けられる予定です。Iceweasel および Icedove についても、安定版向けに最新の ESR (延長サポート版) を再ビルドすることで更新を行う予定です。

5.1.2. libv8 および Node.js 界隈のエコシステムに対するセキュリティサポートの欠落

Node.js プラットフォームは、大量のセキュリティ問題が発生した libv8-3.14 上に構成されていますが、現状ではプロジェクト内およびセキュリティチーム内には、これから発生するであろう問題に対処するのに必要な大量の時間を費やすのに十分な興味と意思を持った作業者が存在していません。

残念なことに、これは libv8-3.14, nodejs, そして node-* 関連パッケージのエコシステムは、インターネットから取得した無毒化していないデータのような信頼できないコンテンツと共には現状利用しないようにすべきだということです。

追記しておくと、これらのパッケージは Jessie リリース期間中に一切のセキュリティ更新を受けることはありません。

5.1.3. MediaWiki へのセキュリティサポートの早期終了について

mediawiki 1.19 シリーズへの開発元へのセキュリティサポートは、Jessie の予想されているライフサイクル中に終わります。mediawiki パッケージは、他のパッケージでの依存関係を満たすために含まれています。

mediawiki へのセキュリティサポートは、Wheezy へのサポートと併せて 2016 年 4 月に終了します。

5.2. OpenSSH サーバーのデフォルトが "PermitRootLogin without-password" になりました

標準設定をより強化する目的で、openssh-server 設定は "PermitRootLogin without-password" になりました。root ユーザーに対してパスワード認証を使っている場合、この変更の影響を受ける可能性があります。

openssh-server はこのようなケースの検知を試み、 debconf の質問優先度を上げようとでしょう。

root ユーザーに対してパスワード認証を使い続けたい場合、以下のようにすればこの質問に対して先行設定が可能です:

$ echo 'openssh-server openssh-server/permit-root-login boolean true' | debconf-set-selections

5.3. Puppet 2.7 / 3.7 の互換性

Puppet を利用している場合は、Puppet 3.7 は Puppet 2.7 と後方互換性がないことに注意してください。他の事柄同様に、指定ルールが変更されており、大量の利用されなくなった記法が削除されています。変更点については Puppet 3.x リリースノート を参照していただきたいのですが、3.7 ではさらに変更が行われていることにも気をつけてください。

アップグレードを進める前に、非推奨設定の警告について現在の puppetmaster のログファイルを確認してこれらを修正することは、アップグレードを完了するのをより楽にしてくれることでしょう。別のやり方として、さらにマニフェストを Puppet catalog test のようなツールでテストするとアップグレード前に潜在的な問題を発見できるかもしれません。

Puppet により管理されているシステムを Wheezy から Jessie にアップグレードする場合、その puppetmaster は確実に Puppet バージョン 3.7 以降である必要があります。Wheezy の puppetmaster がマスターとして動作している場合、管理する Jessie システムに接続することができません。

互換性の無い変更についての詳細は、Telly upgrade issues および "The Angry Guide to Puppet 3" を参照してください。

5.4. PHP 5.6 へのアップグレードは挙動の変更があります

Jessie へのアップグレードは PHP 5.4 から 5.6 へのアップグレードを含みます。これにより、ローカルにある PHP スクリプトへ何らかの影響があると思われるので、アップグレード前にスクリプトを確認することをお勧めします。以下に問題となる項目の抜粋を挙げます:

  • 暗号化通信に対する中間者攻撃 (man-in-the-middle attack) を防ぐため、クライアントストリームはデフォルトで通信相手の証明書を検証するようになりました。

    この変更の結果、ssl:// または tls:// ストリームラッパー (例: file_get_contents(), fsockopen(), stream_socket_client()) を使う既存のコードは、stream context の "verify_peer" 設定によって peer verification を手動で無効にしなければ接続できなくなっています。

    この問題についての詳細は、こちらのドキュメントを参照してください。

  • PHP での大文字小文字の区別の扱いが、多くの場面で変更されました:

    • 内部でのクラス・関数・定数の大文字小文字の区別の取り扱いは、すべて ASCII で定めるところに従って処理されます。現状のロケール設定は無視されます。

    • "self", "parent", "static" キーワードは常に大文字小文字を区別しなくなりました。

    • json_decode() 関数は、小文字以外を含む "boolean" 関連値を受け付けなくなりました。

  • logo GUID 関数 (例: php_logo_guid()) は削除されました

  • 静的なスカラー配列中のキーを上書きすることができなくなりました。この問題についての例と詳細は、PHP bug 66015 を参照してください。

  • mcrypt_encrypt(), mcrypt_decrypt(), mcrypt_{MODE}() 関数は正しくないサイズのキーや初期化ベクトル (IV) を受け付けないようになりました。さらに、ブロック暗号モードが必要とする場合に初期化ベクトル (IV) が要求されるようになりました。

  • 法的な問題から、PHP にバンドルされていた JSON 実装は "jsonc" PECL モジュールが提供するバージョンに置き換えられました。PHP JSON パーサーの内部的な実装に依存しているコードについては、レビューが必要になるでしょう。

  • The "short_open_tag" setting is now disabled by default. Short tags ("<?" and "?>") are scheduled for removal in PHP7.

詳細や潜在的な問題の一覧については、開発元 (upstream) にある PHP 5.5 ならびに 5.6 についての非互換性一覧を一読ください。

5.5. Apache HTTPD 2.4 における互換性の無い変更

[注記]注記

この章では、Apache HTTPD サーバーがインストールされ、手動で設定されているシステムのみについて取り扱います。

バージョン 2.4 において、Apache HTTPD サーバーの設定には大量の変更点があります。開発元での変更点としては、構文が変更されました。特に注意すべき点として、アクセスコントロールディレクティブがかなり変更されているため、新しいディレクティブへの手動での移行作業が必要になるであろうことが挙げられます。

すぐに移行を行う代わりに、開発元 (usptream) のアップグレードガイド中では mod_access_compat が代替手段になりえると記されています。ですが、これは期待する動作ができるとは限らないという報告があります。

Debian パッケージ中での設定ファイルの取り扱いについても変更が加わっています。特に、全ての設定ファイルとサイト設定ファイルは、標準設定でパースされるためには、必ず ".conf" で終わらねばならなくなりました。この変更は、既存の /etc/apache2/conf.d/ の利用についても置き換えを行います。

[注記]注記

アップグレード中、Debian から提供されたパッケージに含まれている /etc/apache2/conf.d/ に配置された設定ファイルについての警告を見ることになるでしょう。この警告の表示は、不可避ではありますが無害です。影響を受けるパッケージが、アップグレード完了時に設定ファイルを移行してくれます (通常、Apache HTTPD がこの警告を表示した後になります)。

詳細と変更点一覧については、以下を参照ください:

  • Apache の開発者らから、Upgrading to 2.4 from 2.2 というドキュメントが提供されています。

  • apache2 パッケージによって /usr/share/doc/apache2/NEWS.Debian.gz ファイルが提供されています。

5.6. Jessie での既存 init システムから新しい標準 init システムへのアップグレードについて

Jessie は、デフォルト の init システムとして systemd-sysv にてリリースされました。このパッケージはアップグレード時に自動的にインストールされます。

sysvinit-coreupstart などの他の init 用の設定を行っていた場合は、アップグレードより前に APT pinning 設定を行っておくことを推奨します。この作業は、ホストより前に LXC コンテナをアップグレードしている場合にも必要になるかもしれません。このような場合は、「Wheezy ホスト上で動作している LXC ゲストのアップグレード」 を参照してください。

例として、アップグレード中に systemd-sysv がインストールされないようにするには、/etc/apt/preferences.d/local-pin-init というファイルを以下の内容で作成します:

Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
[注意]注意

非標準の init システム配下では、いくつかのパッケージがより劣った動作になるか機能が欠けることになる点については忠告しておきます。

APT pinning をしていたとしても、"systemd" を含む名前のパッケージがインストールされる点にはご注意ください。これらはどれひとつとして init システムを変更しません。systemd を init システムとして利用するには、まず初めに systemd-sysv がインストールされる必要があります。

APT または aptitude が、pin を含む適切なアップグレードパスを計算するのに時間がかかりすぎる場合、sysvinit-coresystemd-shim の両方を手動でインストールすることで手助けができるかもしれません。

5.6.1. systemd 配下での起動時のマウント失敗に対する、より厳格な取り扱い

新しい標準 init システムである systemd-sysv は、起動中の "auto" マウントの失敗について、sysvinit と比べて厳しく取り扱います。("nofail" オプション無しの) "auto" マウントに失敗した場合、systemd は起動を続けるのではなく非常時のシェルに落ちます。

/etc/fstab 中に記載されている全てのリムーバブルドライブまたは "optional" なマウントポイント (例: 必須ではないネットワークドライブ) については、"noauto" または "nofail" いずれかのオプションの付加を推奨します。

5.6.2. 不要になった init スクリプトは完全に削除してください

以前のリリースからアップグレードする場合、システムには (現在) 削除済みのパッケージによって提供されていた、もはや用いられることがない init スクリプトが含まれている可能性があります。このようなスクリプトは、依存関係のメタデータが不完全、あるいは全く含まれてない場合があり、これによって init 設定中に循環依存を引き起こす可能性があります。

これを避けるため、"rc" ("Removed, but Config-files remain"、削除されたが設定ファイルが残っている) 状態のパッケージ一覧を確認し、init スクリプトを含むもの全てを完全に削除することをお勧めします。

削除済みパッケージの検索と完全削除に関する詳細については、「削除したパッケージを完全削除する」 を参照してください。

5.6.3. ローカルで変更を加えた init スクリプトは systemd に移植しなければいけない可能性があります

[注記]注記

この項の内容は、Debian が提供した init スクリプトをローカルで変更しているシステムにのみ、適用されます。

Debian によって提供された init スクリプトのいくつかを変更していた場合、systemd の unit ファイルまたは systemd そのものによって置換されていることにご注意ください。debsums をインストールしている場合、以下のシェルコマンドを使えばローカルで変更した init スクリプトを確認できます。

debsums -c -e | grep ^/etc/init.d

別の方法としては、debsums 無しだと以下のように実行できます。

dpkg-query --show -f'${Conffiles}' | sed 's, /,\n/,g' | \
  grep /etc/init.d | awk 'NF,OFS="  " {print $2, $1}' | \
  md5sum --quiet -c

コマンドがファイルまたは関連するパッケージがあると出力した、あるいはそのサービスに対して systemd が systemd unit ファイルを提供するようになった場合、systemd unit ファイルはローカルで変更した init スクリプトより優先されます。変更の理由によって、移行の実施にはいくつか異なった方法があります。

必要な場合は、systemd の unit ファイルを sysvinit スクリプトを起動するように上書きすることも可能です。systemd unit ファイルについての詳細は、以下の資料を参照してください。

5.6.4. plymouth は systemd 配下での起動時にブートプロンプトを必要とします

起動がインタラクティブな操作を必要とする場合 (例: 暗号化ディスクのためにパスワードが必要)、plymouth がインストールかつ設定済であるように必ずしておいてください。plymouth の設定方法については /usr/share/doc/plymouth/README.Debian を参照してください。

plymouth がない場合、ブートプロンプトの消失を見ることになるかもしれません。報告では、cryptsetup のプロンプトは見えなくなってはいるものの、入力は受け付けているようだと言っています。この問題に遭遇した場合、正しいパスワードを入力すれば動作する可能性があります。

5.6.5. logind と acpid 間でのやり取り

ACPI イベントは、logind または acpid で管理できるようになりました。双方のサービスが異なったやり方でイベントを管理するように設定されている場合、望まない結果をもたらすことがあります。

デフォルトではない設定については logind に移行させ、acpid をアンインストールすることをお勧めします。あるいは、logind に ACPI イベントを無視するよう、以下を /etc/systemd/logind.conf へ追加設定するのも良いでしょう:

HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore

これによって、デスクトップ環境の挙動が logind の動作に応じて変化する可能性があることに注意してください。

5.6.6. systemd 配下でサポートされない crypttab 機能 (例: "keyscript=...")

systemd を init システムとして動作させている場合、残念ながらサポートされない cryptsetup の機能がいくつかあります。以下がその一覧です:

  • precheck

  • check

  • checkargs

  • noearly

  • loud

  • keyscript

システムの起動が成功するためには以上のうちのいずれかが必要になっている場合は、init システムとして sysvinit(sysvinit-core) を使う必要があるでしょう。特定の init システムを利用しないようにするには 「Jessie での既存 init システムから新しい標準 init システムへのアップグレードについて」 を参照してください。

以下のコマンドを実行することで、これらのオプションがあなたのシステムで使われているかどうかを確認できます

grep -e precheck -e check -e checkargs -e noearly -e loud -e keyscript /etc/crypttab

何も出力されていなければ、あなたのシステムでは影響を受けるオプションを利用していません。

5.6.7. systemd: issues SIGKILL too early [fixed in 8.1]

[注記]注記

This issue was fixed in the 8.1 Jessie point release.

A regression was reported in systemd after the Jessie release. The bug occurs during shutdown or reboot, where systemd does not give any reasonable delay before issuing SIGKILL to processes. This can lead to data loss in processes that have not saved all data at the time of the reboot (e.g. running databases).

This issue is tracked in the Debian bug #784720

5.6.8. systemd: behavior of 'halt' command

The sysvinit implementation of the halt command powered off the machine as well. The systemd-sysv implementation halts the system, but does not power off the machine. To halt the machine and turn it off, use the poweroff command.

See also Debian bug #760923

5.7. Jessie で必要とされるカーネル設定オプション

[注記]注記

この項は、カーネルをコンパイルしている人たちだけに向けたものです。Debian によってコンパイルされたカーネルを使っている場合は、この項を無視できます。

Jessie では以下のカーネル設定オプション (および以前のリリースからの設定オプション) が必須または推奨となります:

# Required for udev
CONFIG_DEVTMPFS=y
# Required for *some* systemd services
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# Required by "bluez" (GNOME)
CONFIG_BT=y
# Required for cups + systemd.
CONFIG_PPDEV=y

CONFIG_DEVPTS_MULTIPLE_INSTANCES=y を必要とする systemd サービスは、以下のディレクティブのうち少なくとも一つを決まって必要とします:

PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=yes

sysytemd を使っていない、あるいはどの systemd サービスも以上のディレクティブを利用することはないと断言できる場合は、あなたのシステムでは必要ないかもしれません。

要求される事項についての詳細は、systemd パッケージの README ファイル内にある "REQUIREMENTS" という項を参照してください。

5.8. LXC ホストおよびコンテナのアップグレードについての検討

[注記]注記

この項は、LXC コンテナおよびホストシステムにのみ適用されます。通常、一般のエンドユーザーのシステムには存在していません。

Wheezy から Jessie へのアップグレードは、デフォルトの init システムを systemd に移行することになります (「Jessie での既存 init システムから新しい標準 init システムへのアップグレードについて」 参照)。

LXC コンテナあるいは LXC 仮想マシンをアップグレードする際、ホストのシステム が既に Jessie にアップグレードされているか否かによってこれは違った結論となります。

5.8.1. Wheezy ホスト上で動作している LXC ゲストのアップグレード

Wheezy ホスト上で動作している LXC ゲストコンテナをアップグレードしている場合、ゲストが自動的に systemd に移行するのを防ぐ必要があります。「Jessie での既存 init システムから新しい標準 init システムへのアップグレードについて」 で記述したように、pinning によって移行を防ぎます。

これは、Wheezy ホストが systemd で動作するシステムの起動に必要な機能を欠いているために必要になります。

一旦ホストシステムを Jessie にアップグレードしたら、LXC ゲスト内部のシステムを systemd にスイッチできるようになります。Jessie ホストで順応するために必要になる項目については、次の項を参照して下さい。

5.8.2. Jessie ホスト上で動作している LXC ゲストのアップグレード

LXC ゲストを systemd で起動できるようにするためには、LXC コンテナの設定を調整する必要があります。コンテナ設定は、通常は /var/lib/lxc/CONTAINER_NAME/config で確認できます。以下の 2 つの設定の追加が必要です:

lxc.autodev = 1
lxc.kmsg = 0

5.8.3. 追加情報について

Debia での LXC についての追加情報については、Debian wiki 内 で検索できます。

5.9. LUKS whirlpool で暗号化されたディスクの手動での移行作業 (非標準設定)

[注記]注記

この項は、whirlpool ハッシュを使った LUKS 暗号化ディスクを設定している人たちにだけ向けられたものです。debian-installer はこのようなディスクの作成をサポートしていたことはありません

LUKS whirlpool を使った暗号化ディスクを自分で設定していた場合、より強力なハッシュへ手動で移行する必要があります。以下のコマンドを使ってディスクに whirlpool を使っているかどうかを確認できます:

# /sbin/cryptsetup luksDump <disk-device> | grep -i whirlpool

移行作業に関する詳細な情報については、cryptsetup FAQ の "8.3 Gcrypt 1.6.x and later break Whirlpool" の項を参照してください。

[注意]注意

このようなディスクがあった場合、cryptsetup はデフォルトでは暗号化の解除を拒否するようになります。root ディスクや他のシステムディスク (例: /usr) が whirlpool で暗号化されていた場合、cryptsetup をアップグレードした後の初めての再起動より前に移行を実施しておく必要があります。

5.10. GNOME デスクトップは基礎的な 3D グラフィック機能を必要とします

Jessie での GNOME 3.14 デスクトップでは、基礎的な 3D グラフィックをサポートしないマシンに対する fallback サポートは存在しなくなりました。ちゃんと動作させるには、十分に新しい PC が必要です (過去 10 年に製造された PC であれば、必要となる SSE2 をサポートしています) 。i386 / amd64 以外のアーキテクチャについては、EGL ドライバを利用する 3D グラフィックアダプタを使ってください。

5.11. GNOME デスクトップは AMD のプロプライエタリな FGLRX ドライバーでは動作しません

他の OpenGL ドライバーと違い、Radeon アダプタ用の AMD FGLRX ドライバーは EGL インターフェイスをサポートしません。その結果、このドライバーが使われている場合に GNOME デスクトップのコアを含む複数の GNOME アプリケーションが起動しません。

代わりに jessie でデフォルトであるフリー (自由) な radeon ドライバを使うのをお勧めします。

5.12. GNOME の標準キーボードショートカットでの変更

GNOME デスクトップの標準キーボードショートカットは、他のオペレーティングシステムのものに近しいものになるように、と変更されました。

以前にユーザーによって変更されていたショートカット設定は、アップグレードの際に保存されてます。この設定は、画面上部右のメニューからアクセスして"設定"アイコンをクリックし、GNOME コントロールセンターから設定できます。

5.13. base-passwd によって追加されているシステムユーザーの標準シェルの変更

base-passwd パッケージのアップグレードは、システムユーザーのシェルを "nologin" シェルにリセットすることになります。これには以下のユーザーが含まれます:

  • daemon

  • bin

  • sys

  • sync

  • games

  • man

  • lp

  • mail

  • news

  • uucp

  • proxy

  • www-data

  • backup

  • list

  • irc

  • gnats

  • nobody

ローカルの設定がこれらのユーザーがシェルを持つようにしておく必要がある場合、移行についての質問に「いいえ」と答えるか、移行を実施してから必要となるユーザーのシェルを変更する必要があります。よくある例としてはローカルへのバックアップを "backup" ユーザーで "ssh-key" 認証を使って実施している場合が含まれます。

[注意]注意

移行は debconf の質問優先度が "高" 以上の場合は自動的に実行されます。

現在のシェルを指定したユーザーについては維持しておきたい場合、以下を実行して先行設定しておくことができます:

echo 'base-passwd base-passwd/system/username/shell/current-shell-mangled/_usr_sbin_nologin boolean false' | debconf-set-selections

username には、対象となるユーザーの名前を、current-shell-mangled は指定したいシェルの名前で置き換えます。置き換えはアルファベット・ダッシュ(-)・連続したアンダースコア(__) 以外のすべての文字の置き換えによって実施されます。例: /bin/bash → _bin_bash

5.14. 新しい KDE E メール・カレンダー・連絡帳 (Kontact) に移行する

Kontact 個人情報管理システムは大きな変更を迎えました。新しいバージョンはより大きなメタデータインデックスを使うようになっており、各ユーザーのデータはこの新しいインデックスへ移行する必要があります。

メール・カレンダーのイベント・連絡先アドレス帳は、ユーザーがログインして関連するコンポーネントが起動した際に自動的に移行されます。メールフィルタやカスタムテンプレートのようなちょっと複雑な設定には、手作業の介在が必要です。より詳細な情報とトラブルシュートについての提案に関しては、Debian Wiki に集約されています。

5.15. 複数のデスクトップ環境で仮想コンソール ("getty") が消失する

[注記]注記

This issue is currently reported as fixed in Jessie. Should you stil be able to reproduce it, then please follow up to Debian Bug#766462. Note that you may have to unarchive the issue first (please refer to the Debian BTS control server documentation on how to unarchive bugs).

複数のデスクトップ環境をインストールしていた場合、"仮想コンソール"がいずれもログインプロンプトを表示しない可能性があります。

この問題は plymouth, systemd, そして GNOME のすべてがインストールされている場合に起こるようです。これは Debian Bug#766462 として報告されています。

カーネルコマンドラインから "splash" 引数を取り除くのが、この問題の回避策になるという報告がありました。/etc/default/grub を確認してください。ファイルを更新後に update-grub を実行するのも忘れずに。

5.16. "VGA signal out of range" / grub-pc で起動中、何も画面に表示されない

grub-pc と古いグラフィックカード (例: "ATI Rage 128 Pro Ultra TR") には互換性の問題があり、起動中に何も画面に表示されない場合があります。ディスプレイには "VGA signal out of range" (あるいは類似の) メッセージが表示されるでしょう。

シンプルな回避策は /etc/default/grubGRUB_TERMINAL=console を設定することです。

5.17. crontab 中の cron ファイルのより厳重なチェック

crontab プログラムはより厳重になり、正しくない cron ファイルの場合は変更点を保存するのを拒否します。crontab -e で何か問題があった場合には、既存のミスについて crontab を確認してください。

5.18. perl による読み込みできないモジュールパスの扱いの変更

バージョン 5.18 (そして Jessie に含められているのは 5.20) から、Perl は @INC 中で読み込み不可能なモジュールパスに遭遇した場合、致命的なエラーで終了するようになりました。以前の挙動ではそのようなエントリをスキップしていました。自分の環境中の @INC の内容について、world-readable ではないディレクトリを確認して適切な対応をすることをお勧めします。

Perl でのデフォルトの @INC を見るには perl -V を実行してください。

5.19. Ganeti クラスタをアップグレードする際の検討

5.19.1. Problem upgrading Ganeti clusters with DRBD-backed instances [fixed in 8.1]

[注記]注記

This issue was fixed in the 8.1 Jessie point release.

Jessie でリリースされた ganeti (2.12.0-3) は、DRBD ディスクを使ったインスタンスがある場合、 2.5 以前で動作しているインストールからの移行をサポートしていません (これには Wheezy を含みます)。この問題は、ポイントリリースで修正されることが期待されており、現在のところは影響を受ける Ganeti クラスタをアップグレードしないことを推奨します。この問題に関する詳細については、Debian Bug#783186 で得られます。

5.19.2. Ganeti クラスタのアップグレードに関する一般的な注意事項

Ganeti cluster について、Wheezy の ganeti バージョン (2.5.2-1) から Jessie (2.12.0-3) へのアップグレード推奨手順は、一度にすべてのインスタンスを停止してアップグレードし、再起動を行うことです。これによって、すべてのインスタンスが Jessie でのバージョンのハイパーバイザー配下で動作していることと、すべてのノードが同一バージョンの Ganeti と DRBD を走らせていることを保証します。

バージョン 2.5 のノード と 2.12 のノードの混在したクラスタの動作はサポートされていない点にご注意下さい。また、ハイパーバイザーによりますが、Wheezy と Jessie のハイパーバイザーのバージョン間でのライブマイグレーションは動作しないことがあります。

5.20. Samba4 でのファイル実行についての新たな必要事項

クライアントが、ファイルは"opened for execution"であると要求した場合、Samba4 は通常の読み取り権限に加えて実行ビットの設定を要求するようになっています。この実行ビットが欠落している場合、"netlogon" スクリプトが特に警告もなく無視されるようになる原因にもなっています。

5.21. cryptsetup は BUSYBOX=n では起動できなくなる可能性があります

[注記]注記

この項は、手動で /etc/initramfs-tools/initramfs.conf に busybox を使わないよう設定した人たちにのみ向けたものです。

busyboxcryptsetup両方共インストールしていて、さらに initramfs について busybox を使わないように設定している場合、結果としてシステムが起動不可能になるかもしれません。

二つのパッケージがインストールされている場合、/etc/initramfs-tools/initramfs.conf 中のBUSYBOX 設定の値を確認してください。この場合、既知の回避策は busybox のアンインストールか、/etc/initramfs-tools/initramfs.confBUSYBOX=y に設定することです。

[警告]警告

何か変更を行った際、initramfs を更新するために update-initramfs -u の実行を忘れないで下さい。さもなければ起動が壊れたままの羽目になるでしょう。

詳細については Debian Bug#783297 を参照してください。