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

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

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

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

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

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

# "false" という値には混乱させられますが、実際のところ正しいものです。
$ echo 'openssh-server openssh-server/permit-root-login boolean false' | debconf-set-selections

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" を参照してください。

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

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

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

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

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

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

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

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

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

sysvinit-core や upstart などの他の 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-core と systemd-shim の両方を手動でインストールすることで手助けができるかもしれません。

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 ファイルについての詳細は、以下の資料を参照してください。

• How Do I Convert A SysV Init Script Into A systemd Service File? (SysV Init スクリプトを sysmted Service ファイルにどうやって置き換えるか)

• systemd.special — Special systemd units

• My Service Can't Get Realtime! (unit ファイルから init スクリプトを呼び出す方法についても非常に短い言及があります)

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

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

5.6.7. systemd: SIGKILL が早すぎる問題 [8.1 で修正済み]

	注記
	この問題は 8.1 Jessie ポイントリリースで修正されました。

Jessie のリリース後、systemd についてリグレッションが報告されました。このバグは、シャットダウンあるいは再起動時、systemd がプロセスに SIGKILL を発行する前に十分な時間を与えていないために発生します。これにより、再起動の時点で全てのデータを保存してないプロセスでデータの損失を招く可能性があります (例: データベースの稼働)。

この問題は Debian Bug#784720 で扱われています。

	注記
	この項は、カーネルをコンパイルしている人たちだけに向けたものです。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" という項を参照してください。

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

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

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

lxc.autodev = 1
lxc.kmsg = 0

	注記
	この項は、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 をアップグレードした後の初めての再起動より前に移行を実施しておく必要があります。

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

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

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

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

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

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

ローカルの設定がこれらのユーザーがシェルを持つようにしておく必要がある場合、移行についての質問に「いいえ」と答えるか、移行を実施してから必要となるユーザーのシェルを変更する必要があります。よくある例としてはローカルへのバックアップを "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

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

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

	注記
	この問題は Jessie で修正されたと現在報告されています。まだ再現できる場合は、Debian Bug#766462 に追加報告して下さい。その場合、この問題をまず unarchive する必要があるかもしれないことにご注意下さい (バグの unarchive のやり方については、Debian BTS コントロールサーバー のドキュメントを辿ってみて下さい)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	注記
	この章は squid ウェブプロキシをインストールしてある人にだけ適用されます。

squid の設定は、互換性のない形で変更されました。特にいくつかの squid "ヘルパー" は名前が変更されています。もし、あなたの設定が既に存在しない過去の機能やヘルパーの以前の名前機能に依存していた場合、アップグレード後に squid サービスは起動に失敗するでしょう。

詳細については upstream のリリースノートを参照してください。以下が参考になります: