UDS-Q（2）

先週に引き続き、今週もUDS-Qで話し合われたアイデア（のうち、筆者が気になったもの）を見ていきましょう[1]⁠。今週は「Cloud」「⁠Server」「⁠Security」カテゴリに属する話題です。

• servercloud-q-apt-improvements：システムの自動運用やJuju・MaaSによるデプロイにおいて、aptを人間の手を煩わせずに使えるようにしよう。proxy経由で利用した時の信頼性を向上させよう。たとえば、アーカイブサーバーでインデックスとコンテンツが別々に更新されてしまった場合に「Hash sum mismatch」が返されないようにしよう。これはDebianのアーカイブ構成の問題でもあるので、Debianと連携して解決するべきだ。ファイル単位でハッシュを取ることで、「⁠まとめて署名」するやり方から脱却した方がいい。
• servercloud-q-juju-resource-map：Jujuの利用において、「⁠特定の仮想マシンでしか機能しない」という状態は使い勝手が悪い。いろいろなマシンで利用できるようになるべきだ。しかし、マシンがどのようなスペックを持っているのかを知るための統一された方法がない。リソース問い合わせのためのAPIを作って解決するべきだ。
• servercloud-q-openstack-ha：OpenStackを冗長構成にできるように、足回りを含めて準備をすべきだ。SPoFが存在する仮想化基盤はナンセンスだ。
• servercloud-q-eucalyptus：Eucalyptus 3.1（オープンソース版）の取り込みと、3.0（商用版）へのコマンドラインツール（euca2ools）の対応を行おう。
• servercloud-q-xen：Xen 4.2の対応と、ドキュメントの整備（特にネットワーク周り）と、Jujuとの連携を行おう。XCPのサポートも強化しよう。
• servercloud-q-openstack-deployment-on-arm：OpenStackをARM上で利用できるようにしよう。
• servercloud-q-mysql-roundtable：MySQLのリリース方針の変化への追従方法を考えよう。DebianやUbuntuの「最低限のセキュリティ修正だけを提供する」モデルは、Oracleがパッチに関する情報を提供してくれないので困難になってしまった。MySQLの今後のリリース方針と、MariaDBの現状をあわせて考え、よいアプローチを考えよう。10.04の5.1もまだまだサポートしなくてはならない。
• servercloud-q-juju-release-process：JujuのCharmのリリース方針を検討しよう。2ヶ月に一度リリースしていくことを目標にプランを立ててみよう。
• servercloud-q-maas-next-steps：MAASの新バージョンについて検討しよう。電源管理の自動化・自動的なハードウェアのバーンインテスト・インストールの高速化などなど、やることはたくさんある。
• servercloud-q-apport-enhancements：サーバーベンダー向けにApportを拡張しよう。たとえばメモリ障害が起きた時に、ベンダーのサポート窓口が必要なログはたくさんある。それらを簡単に取得できるようにApportを拡張し、ログをやりとりしやすくしよう。
• servercloud-q-powernap-opencompute-integration：PowerNapが特定のプロセスだけでなく、各種負荷状態のモニタリングをもとにトリガできるようにしよう。
• servercloud-q-openflow-controller：Ubuntu環境で利用できるOpenFlow Controllerを選定しよう。
• security-q-openjdk：OpenJDKをメンテナンスしていく方法を検討しよう。コードベースそのものをメンテナンスするにも、Red HatやSUSEと共同で作業していくべきだ。連携できないか確認し、より適切な方式で作業しよう。

12.04の注意点（3）

先々週から引き続き、12.04の利用上の注意をお届けします。今回は「アップグレードに伴う注意」です。

10.04からのアップグレードは検討が必要

現時点（2012年5月）において、10.04から12.04へのアップグレードは「12.04.1まで待つことを推奨」というステータスです。リリースノートを確認すると分かりますが[2]⁠、10.04からのアップグレードには実際に複数の問題が残っており[3]⁠、現状ではまだ「待ち」のステータスです。特に、SSH越しのリモート操作でのアップグレードは再起動後に致命的な結果をもたらす可能性があるため、十分に注意して行うべきです。

12.04にはEucalyptusが含まれていません

サーバー関連の最大のポイントがこれです。12.04にはEucalyptusと、EucalyptusをベースにするUEC（Ubuntu Enterprise Cloud）が含まれていません。UECベースのプライベートクラウド環境を構築していた場合、OpenStackベースのUbuntu Cloud Infrastructureへ移行する必要があります。基本的な操作性はAWSOMEによって「EC2互換」として近似していますが、ノード設計は異なるものであり、相当な考慮が必要です。UEC環境が存在する場合は10.04に留まり、12.10以降の状況を確認していくのが安全です。

PPA等の非公式リポジトリを導入している場合の注意

非公式なリポジトリからパッケージを導入した11.10、あるいは10.04環境をアップグレードする場合、「⁠導入したパッケージ」のバージョン文字列によっては、「⁠非公式リポジトリ由来のパッケージを一度削除し、公式なパッケージに置き換える」「⁠アップグレード後に非公式リポジトリを追加しなおす」といった対処が必要になる可能性があります。

代表的な問題は、次のようなメカニズムで生じます。

まず、非公式リポジトリから提供されるパッケージAのバージョン文字列に、「⁠2.0」というものが入っている一方で、公式なリポジトリからは「1.1」が提供されている、という状態を仮定します。ここからアップグレードにより、公式なリポジトリから「1.2」が提供されるとします。

このような状態でアップグレードを行った場合、通常のアップグレードで提供される「1.2」は「2.0」よりも古いとみなされるので、アップグレード後も「2.0」の非公式パッケージが残留します。これそのものは問題ありません。しかし、ライブラリの依存関係やビルド時にリンクされるライブラリによっては、公式リポジトリの「1.2」は新しい環境でビルドされたものなので正常に動作することが期待されますが、「⁠2.0（ただし古いバージョンのUbuntuでビルドされたもの⁠）⁠」は、アップグレード後には正常に動作しない可能性があります。これにより、『⁠「⁠2.0」を一旦削除する』か、あるいは『⁠「⁠2.0（の新しいバージョンのUbuntuでビルドされたもの⁠）⁠」を導入する』必要がある、という状態に陥ります。12.04へのアップグレード後、奇妙な挙動に悩まされている場合は、アップグレード前に非公式リポジトリを追加していないか確認する必要があるでしょう。

UWN#265

Ubuntu Weekly Newsletter #265がリリースされています。

その他のニュース

• Launchpadの登録バグが七桁に達しました。記念すべき[4]1,000,000個目のバグは、「⁠For every bug on Launchpad, 67 iPads are sold.」（⁠内容を含めた意訳は、「⁠教育現場で、費用が高めな上にすぐに古くなってしまうiPadがたくさん使われてしまっている⁠」⁠）と、Bug No.1に類似したものになっています。
• GoogleにおけるUbuntuの使われ方。
• 過去に紹介したスティック型ARMデバイス『Cotton Candy』の現在の状況について。日本への出荷は夏以降になりそうですが、北欧市場にはそろそろ出まわるようです。
• Ubuntu 12.04ベースのシンクライアント/キオスク端末用Linuxデバイス、Romula 12.04がリリースされています。FAQはこちら。
• Ubuntu Business Desktopの12.04版がリリースされています。
• 12.04環境でのXまわりのちょっとしたトラブルシューティング。
• Linux向けSkypeがアップデートされた話題。
• Wine環境でDiablo3を動かす話題と概要にあたるblog記事。インストーラーに問題があるものの、「⁠一応動く」という状態ではあります[5]⁠。