
Ubuntu日本語フォーラム

ログインしていません。
この件に関しては、何度も取り上げられているのですが、ubuntu初心者のため
理解が困難です。ご教示いただければ幸いです。
使用しているパソコンは、dell inspiron mini 9 ubuntu8.04(dellカスタマイズ版)です。
日経Linux 2008年12月号 p.59 に従って、
debパッケージをインストールし、圧縮アーカイブを解凍しました。
当該ディレクトリに移動して、
sudo dpkg -i * と叩きましたが、以下のようなエラーになります。
------------------------------------------------
SOkadai@SOkada:~/ダウンロード/OOO300_m9_native_packed-1_ja.9358$ sudo dpkg -i *
dpkg-split: DEBS の読み取り中にエラーが発生しました: Is a directory
dpkg: DEBS の処理中にエラーが発生しました (--install):
サブプロセス dpkg-split はエラー終了ステータス 2 を返しました
dpkg-split: licenses の読み取り中にエラーが発生しました: Is a directory
dpkg: licenses の処理中にエラーが発生しました (--install):
サブプロセス dpkg-split はエラー終了ステータス 2 を返しました
dpkg-split: readmes の読み取り中にエラーが発生しました: Is a directory
dpkg: readmes の処理中にエラーが発生しました (--install):
サブプロセス dpkg-split はエラー終了ステータス 2 を返しました
dpkg-deb: `update' は debian 形式のアーカイブではありません
dpkg: update の処理中にエラーが発生しました (--install):
サブプロセス dpkg-deb --control はエラー終了ステータス 2 を返しました
以下のパッケージの処理中にエラーが発生しました:
DEBS
licenses
readmes
update
------------------------------------------------
これは、どういうことなのでしょうか?
さっぱり対処方法がわかりません。
よろしくお願い申し上げます。
オフライン
パッケージのアーキテクチャが異なるため、インストールできないのかと思います。
dellカスタマイズ版Ubuntu:lpia
雑誌等でdellカスタマイズ版と触れられていないパッケージ:(一般的に)i386
対策としてはlpiaとしてビルドされたパッケージを探せば良いかと考えます。
最後の編集者: kk (2009-02-03 00:39:39)
オフライン
kkさん
横から済みません。
アーキテクチャが誤っている場合は、以下のようなエラー文字列が出てくるので、現時点でのエラーは違うと思います。($sの部分はi386, amd64, lpiaとか)
パッケージアーキテクチャ($s)がシステム($s)と一致しません
確かに上手くdpkgのコマンドが通れば、次にアーキテクチャでひっかかるとは思いますが・・・。
SOkada さん
>当該ディレクトリに移動して、
とありますが、
ログを見る限り、正しく DEBSフォルダに移動されてないですよ。
DEBSフォルダより一つ上に移動しただけです。
そのあたりを再度確認されてはどうでしょうか?
最後の編集者: STGSAGWAN (2009-02-03 20:49:08)
kk様、STGSAGWAN様
ありがとうございました。
結局、DEBSフォルダに移動してもエラー発生でインストールできませんでした。
デルのubuntuダメですね。ATOKもインストールできないし、本日、デル テクニカルサポートに電話を入れましたが、中国人の金さんが対応しただけでした。ubuntu担当部署に直接連絡をとるように迫りましたが、答えは、プリインストール以外のソフトについてはサポート外という返事。
それなら、日本語 Remix CDをインストールしたって同じ事だと言うことがよく分かりました。
デルのubuntuならcanonicalのサポートがあるとの情報も得ておりましたが、金が申すにはそのようなことは全くないとの事です。
デルのubuntu最低ですね。windows vistaに劣るとも優らない駄目さです。
ちょっと、日本語Remix CDでインストールし直してみますね。
オフライン
>答えは、プリインストール以外のソフトについてはサポート外という返事。
サポートの範囲については明確な説明があるので、責めるのはお門違いかと。
オフライン
購入条件に書いてある内容をシカトするのはかなりどうかと思うのですが、
https://launchpad.net/~openoffice-pkgs/+archive/ppa
とかある程度ちゃんとした方法があるのに、何故オフィシャルビルドからヘンな方法でインストールしようと苦戦されているのでしょうか……。
オフライン
hito による投稿:
何故オフィシャルビルドからヘンな方法でインストールしようと苦戦されているのでしょうか……。
うーん、「聞いた事もない」リポジトリやサイトから入手するよりも、オフィシャルHPから入手するのは、Ubuntuユーザ(PCユーザ)としては正しいというか推奨される行動だと思うんですが、どうなんでしょう。
# もちろん、正規のリポジトリから手に入るならそこから入手するのが一番ですけど。
私も一番最初にOpenOffice.org 3.0を試した時は、やはりOpenOffice.orgの正規HPから入手したオフィシャルビルドをインストールしました。
SOkadaさんがトライされているのと同じやり方です。(雑誌からの入手ではないですが、ファイル名からしてモノは同じのように思えます)
私は少ししか触ってないですが、普通にインストールできて使えました。
一方、リポジトリからインストールできる方法も候補としてあるのは知っていましたが、内心「PPAって何? 知らないリポジトリは原則やめておこう」と思い躊躇しました。
モデレータの方は、そのリポジトリがどういうものか熟知されていると思いますが、1エンドユーザとしてはそれに一人で初めて出会った際に何なのか判断がつかないのです。
最後の編集者: STGSAGWAN (2009-02-04 07:04:55)
STGSAGWAN による投稿:
hito による投稿:
何故オフィシャルビルドからヘンな方法でインストールしようと苦戦されているのでしょうか……。
うーん、「聞いた事もない」リポジトリやサイトから入手するよりも、オフィシャルHPから入手するのは、Ubuntuユーザ(PCユーザ)としては正しいというか推奨される行動だと思うんですが、どうなんでしょう。
# もちろん、正規のリポジトリから手に入るならそこから入手するのが一番ですけど。
なるほど。だとすると結構困ったことになりそうな気がしてきました。
それなりに手順やリポジトリ管理を理解されている方がオフィシャルなサイトからダウンロードしてインストールするのは構わないのですが、一定の理解なく無理矢理にインストールするとアップデート・アップグレード時にかなり悲惨なことが起きる可能性があります(し、ハッシュなどによる安全性のチェックが行われていないのであれば、PPAから使うよりよほど危険な展開になりかねません)。
セキュリティ的には「野良から入れない」は正しいのですが、システムの整合性の面からは「オフィシャルからであっても入れるべきではない、むしろPPAの方がマシ」なのです。そしてハッシュのチェックといった、セキュリティ的に暗黙で期待されることをしないのであれば、トータルで見るとオフィシャルから落とす方がよほどいろんな意味で危ないと思われます。
STGSAGWANさん的な把握に基づいて教えて頂ければと思うのですが、
・上記の背景を踏まえて、「こうなっているとユーザ的にはありがたい」ということを理想論と現実論に分けて教えてください。
・これがダメだったと思う、とかでも構いません。
ちなみに、自分は8.04でOOo 3系列を使いたいという要望自体がどの程度切実なのかも分かってなかったりします(←それダメだろ)。
オフライン
hitoさん による投稿:
それなりに手順やリポジトリ管理を理解されている方がオフィシャルなサイトからダウンロードしてインストールするのは構わないのですが、一定の理解なく無理矢理にインストールするとアップデート・アップグレード時にかなり悲惨なことが起きる可能性があります(し、ハッシュなどによる安全性のチェックが行われていないのであれば、PPAから使うよりよほど危険な展開になりかねません)。
hito さんが強調したいのは、わたしが太字赤色にしたところ、と理解してよろしいでしょうか?
hitoさん による投稿:
セキュリティ的には「野良から入れない」は正しいのですが、システムの整合性の面からは「オフィシャルからであっても入れるべきではない、むしろPPAの方がマシ」なのです。そしてハッシュのチェックといった、セキュリティ的に暗黙で期待されることをしないのであれば、トータルで見るとオフィシャルから落とす方がよほどいろんな意味で危ないと思われます。
この部分も一般論として理解してよろしいでしょうか?
最後の編集者: avidya (2009-02-04 12:06:41)
hito さんが強調したいのは、わたしが太字赤色にしたところ、と理解してよろしいでしょうか?
いえ、「アップデート・アップグレード時にかなり悲惨なことが起きる可能性があります」の方が差し迫った危機だと思います。ハッシュうんぬんもきっちりチェックして欲しいですが。
hitoさん による投稿:
セキュリティ的には「野良から入れない」は正しいのですが、システムの整合性の面からは「オフィシャルからであっても入れるべきではない、むしろPPAの方がマシ」なのです。そしてハッシュのチェックといった、セキュリティ的に暗黙で期待されることをしないのであれば、トータルで見るとオフィシャルから落とす方がよほどいろんな意味で危ないと思われます。
この部分も一般論として理解してよろしいでしょうか?
この「一般論」という単語が示す範囲が微妙ですが、「Firefoxなどもそうか?」という意味では、はい。ただしDebパッケージで入れないのであれば話は変わってきます。
オフライン
hitoさん による投稿:
いえ、「アップデート・アップグレード時にかなり悲惨なことが起きる可能性があります」の方が差し迫った危機だと思います。
これは OS のアップデート・アップグレード時の話ですか?それとも各アプリケーションのアップデート・アップグレードの時の話ですか?あるいは両方ですか?
hitoさん による投稿:
「Firefoxなどもそうか?」という意味では、はい。ただしDebパッケージで入れないのであれば話は変わってきます。
この部分ですが、本家自体がバイナリパッケージの形で配布しているからリスキーである、という理解でよろしいですか?
たとえば今日 Firefox 3.0.5 がリリースされました。3.0.4 までの Firefox にはバッファーオーバーフロー攻撃が可能な脆弱性があります。0 hour 攻撃が一般的になってきている昨今、やはりリポジトリの Firefox のアップデートを待つべきでしょうか?
また、ソースからビルドするなら話は変わってくるという理解でよろしいですか?
最後の編集者: avidya (2009-02-04 12:28:00)
avidya による投稿:
hitoさん による投稿:
いえ、「アップデート・アップグレード時にかなり悲惨なことが起きる可能性があります」の方が差し迫った危機だと思います。
これは OS のアップデート・アップグレード時の話ですか?それとも各アプリケーションのアップデート・アップグレードの時の話ですか?あるいは両方ですか?
両方です。
顕在化しやすいのはOS(というかディストリビューション。8.04=>8.10など)ですが、日常的なアップデート時にも問題が起こる可能性があります。
複数の軸の話が混じってきているので、リスクを分類させてください。
・パッケージ管理上のリスク
・セキュリティ的な(不正なバイナリを導入される)リスク
前者のリスクは、debパッケージの形で野良インストールした場合は常に発生します(PPAでもリスクはありますが、後述の緩和要素があります)。
これはアップデート等の失敗として顕在化します。
しかしPPAの場合は「バグっていたら直してもらえる可能性があり、リポジトリ管理者の側で対処されればユーザーが何もする必要がない」という緩和要素があります。オフィシャルに近い(そして利用者が多い)PPAであれば、対処してもらえる可能性は増します。膨大なユーザーがいる、あるいはubuntu.comの準公式レベルのチームによって運用されている場合、Main/Universeなどのリポジトリレベルですら対処される可能性があります。
しかし、PPA以外からdebパッケージを直接ダウンロードしてきて利用している場合、ユーザーが能動的に対処するしかありません。
これはソースからビルドし、インストールしているのであれば(chkinstallなどでdeb化しなければ)問題にはなりません。
逆に後者の方は、何をしようとも次の単純な法則に支配されます。
法則a) 配布者が信用できるかどうか
法則b) 配布チャネルが信用できるか
PPAなどでは法則a)に不安があります。これはyour own riskの範疇だと思います。
が、もし「これには悪意あるソフトウェア含まれてる」という報告がLPになされれば、そのPPAはdisableされることが期待できるので、ある程度楽観的に見ることができるのではなかろうかと思います(が、各種ソフトウェアの公式サイトに比べると信頼度は落ちるでしょう)。
b)が問題になるのは各ソフトウェアの公式サイトからのバイナリ配布が該当します。httpsで提供されている、あるいは信頼できるハッシュなどの検証手段が提供されており、利用者が正しく検証できるなら問題ありません。
# でも出来ないよねという感じですが;)
PPAではGPG署名をimportしておけば、aptが自動的に署名を検証することができるので、PPAの使い方のマニュアルに従う限り、ある程度自動的に安全性は担保されます。
で、リスクの話全体に戻ると、
・現実的に問題が起きやすいのは前者(パッケージ管理上の問題)のはず
というのが「ソースからビルドすれば問題ないですか?」ということへの間接的な回答になります。具体的な回答としては、「ソースからビルドし、パッケージ化せずに使っていれば問題ないでしょう」となります。
hitoさん による投稿:
「Firefoxなどもそうか?」という意味では、はい。ただしDebパッケージで入れないのであれば話は変わってきます。
この部分ですが、本家自体がバイナリパッケージの形で配布しているからリスキーである、という理解でよろしいですか?
たとえば今日 Firefox 3.0.5 がリリースされました。3.0.4 までの Firefox にはバッファーオーバーフロー攻撃が可能な脆弱性があります。0 hour 攻撃が一般的になってきている昨今、やはりリポジトリの Firefox のアップデートを待つべきでしょうか?
また、ソースからビルドするなら話は変わってくるという理解でよろしいですか?
そしてこちらですが、「本家自体がバイナリパッケージの形で配布しているからリスキー」という部分は前述の通りです。
でFirefox話になると、これは3.0.6ですよね。
http://www.mozilla-japan.org/security/known-vulnerabilities/firefox30.html#firefox3.0.6
バッファオーバーフローということでこれ(CVE-2009-0352・CVE-2009-0353)の事かと思いますが、
http://www.mozilla-japan.org/security/announce/2009/mfsa2009-01.html
これなら待ってもいいと思います。
一般論としては、
・Mainリポジトリのものであれば2〜3日なので待つ
・本気でどうしようもないパターンの場合は何かしら別の対処
が現状では妥当かと思います。幸いUbuntuの場合はセキュリティアップデートのリリースは「Mainに限る・重要性が高いものに限る」という制約こそあれ、致命的なものについては迅速なので、商用Unixのたぐいと違ってアップデートを待っても問題ないと思います。
一応、ほとんどのヒープバッファオーバーフロー攻撃のためのコードには「"安定した"コードの開発には時間がかかる」という特性があり、現状ではパッチ適用・配布のための時間の方が有意に短いため、リポジトリからの配布を待つで問題なかろうと思います。
ていうかですね、この手の攻撃コードをパッチよりも早くたたき込める攻撃者というか天才さんを仮定した場合、自力で脆弱性見つけてたたき込んでくるので、アドバイザリが出てきてから何か対策を打とうとしても実は「ゼロデイアタックの防止」という点では変わりません。優秀な攻撃者への対策としては、アドバイザリのリリースは「遅い」です。
もちろんアドバイザリが出てきてから数日で攻撃コードが作成される現状には変わりありませんから、
・見つかった脆弱性が、コマンドエグゼキューション/インジェクション・SQLインジェクションなどの攻撃コードの開発が容易なものである
・ヒープバッファオーバーフローなのだが攻撃コードの安定化が容易(アドレスが固定されてる上に上書きできるメモリの範囲・内容に制約がないとか)
・攻撃範囲がきわめて広い
・利用しているシステムの重要性が極端に高い
などといった条件が複合していれば別の対策が必要になりますので、先行してリリースされた本家版バイナリの導入なども「アリ」だとは思います。
ただ、これらは現実的にはパッチマネジメントの問題ではなく、システムレベルでの多層セキュリティ(MACとか、脆弱性のあるモジュールを切り離すとか)で守るべき部分のように思いますし、今回のFirefoxの件であればJavaScriptの無効化+フォームのボタンを押さない、でOKなんではないでしょうか。全部の脆弱性をソースレベルで検討するのはまだ出来てないですけど、たぶん攻撃者にとっては他の脆弱性(MS08-067)とかのがよほど魅力的なので、そっちが狙われてるのではなかろうかと思います。
つまり、
・ケースバイケースで本家のバイナリを「一時的に」利用するのが正しいケースもある。
・でもその場合も「一時的」なので、緊急避難が終わったら元に戻した方が安全。
・今回のFirefoxの脆弱性は緊急避難が必要かというと別にそうでもない。
てな感じです。
最後の編集者: hito (2009-02-04 13:21:48)
オフライン
納得です b(≧∀・)
# ちなに PPA のリポジトリで公開されているバイナリには、私も御世話になってます。
最後の編集者: avidya (2009-02-04 13:55:33)
hito による投稿:
STGSAGWANさん的な把握に基づいて教えて頂ければと思うのですが、
・上記の背景を踏まえて、「こうなっているとユーザ的にはありがたい」ということを理想論と現実論に分けて教えてください。
・これがダメだったと思う、とかでも構いません。
すみません、私には難しい質問で上手く答えられそうにありません。
なので、思いついたことをそのまま書きます。
Windowsでいう処のVector、窓の杜みたいな存在感をもつエンドユーザフレンドリな サードパーティのリポジトリサイトが出現すると嬉しい限りです。(もう既にありますか?)
# GetDebというサイトもありますが、あれはDebファイル配布ですものね。
そういう「有名処」が出てくれば、逆に(言い方は悪いですが)公式HPからダウンロードとかちまちまやってられん!となるのかな、と思います。
なお今のPPAはデベロッパ向けの雰囲気が相当強く感じます。トップページからしてデベロッパ気質を感じます。(批判しているわけではなく、素直にそう思うだけです)
少なくとも SourceForge.net くらいの親しみやすさになるといいな・・・。(単なる理想)
実は、PPAのこと詳しく知らなかったんです。
なんか妙にURLが長いですし、階層も深いので、誰が管理してるんだろ?ってリポジトリに対して妙な場末感を抱いてしまいました。
それなら、かのOpenOffice.orgの方が知名度あるし、そっちがいいんでない?と勝手な思い込みをしてしまいました。
もっと視野を広げて勉強します。
最後の編集者: STGSAGWAN (2009-02-04 21:49:41)
SOkadaさん,はじめまして.
僕もつい先日,mini9を購入しました(Win版ですが).
USBにubuntu-8.10-umpc-i386.imgをインストールし,快適に使ってます.
>使用しているパソコンは、dell inspiron mini 9 ubuntu8.04(dellカスタマイズ版)です。
8.04はイマイチだ,みたいなことが書いてあるので,8.10を入れてみてはいかがですか?
AtokXとかも普通に入るみたいですし(僕は持っていませんが)
Ubuntu Weekly Recipe による投稿:
ubuntu-mobileは8.04から利用することができますが,いくつかの部分で完成度に問題があり,あまり使いやすいものではありませんでした。が,8.10ではデザインを含めたブラッシュアップが行われ,非常に魅力的な環境に仕上がっています。
http://gihyo.jp/admin/serial/01/ubuntu-recipe/0037
オフライン
STGSAGWAN による投稿:
なので、思いついたことをそのまま書きます。
Windowsでいう処のVector、窓の杜みたいな存在感をもつエンドユーザフレンドリな サードパーティのリポジトリサイトが出現すると嬉しい限りです。(もう既にありますか?)
# GetDebというサイトもありますが、あれはDebファイル配布ですものね。
そういう「有名処」が出てくれば、逆に(言い方は悪いですが)公式HPからダウンロードとかちまちまやってられん!となるのかな、と思います。
なお今のPPAはデベロッパ向けの雰囲気が相当強く感じます。トップページからしてデベロッパ気質を感じます。(批判しているわけではなく、素直にそう思うだけです)
少なくとも SourceForge.net くらいの親しみやすさになるといいな・・・。(単なる理想)
なるほど。ということは、
・PPAの存在が広く知られていて
・かつ利用が簡単
という状態ならOKって感じですかね……。(どっちが先なのかは微妙なところですが。簡単に使えないと広まらないかな……)
どうもありがとうございます。ヘタに各ソフトウェアのオフィシャルバイナリdebを導入するのはトータルで見ると嬉しくないので、なにかしら考えてみようかと思います。
オフライン
hitoさん による投稿:
なるほど。ということは、
・PPAの存在が広く知られていて
・かつ利用が簡単
という状態ならOKって感じですかね……。(どっちが先なのかは微妙なところですが。簡単に使えないと広まらないかな……)
どうもありがとうございます。ヘタに各ソフトウェアのオフィシャルバイナリdebを導入するのはトータルで見ると嬉しくないので、なにかしら考えてみようかと思います。
たぶん理想は mizuno さんやその他の方の ppa で公開されているバイナリが、Ubuntu Japanese Team の公式リポジトリに入るのが理想なんでしょうね。
もしそれが難しいなら公式じゃないけど、Ubuntu Japanese Team メンバー、あるいはコミュニティーメンバーの PPA が medibuntu のように簡単にリポジトリ登録できる仕組みができたらいいのかな?
私は PPA の欠点は情報が断片的にしか得られない、偶然にしか知る術がない、というところだと思ってます。「これは OK じゃね?」という PPA は Japanese Team のサイトで紹介してもよさそうな気もします。
# Mozilla の add-on のようにリクエストにレビューが追い付かない、という危惧も感じますが。
最後の編集者: avidya (2009-02-06 21:02:20)
むしろ公式じゃないからこそ好き勝手が許されてる感がありますので、Japanese Teamリポジトリ入りはちょっとなーという気がします。
オフライン
avidya による投稿:
私は PPA の欠点は情報が断片的にしか得られない、偶然にしか知る術がない、というところだと思ってます。「これは OK じゃね?」という PPA は Japanese Team のサイトで紹介してもよさそうな気もします。
# Mozilla の add-on のようにリクエストにレビューが追い付かない、という危惧も感じますが。
はい。PPAは偶然知ってown riskで使う、玉石混淆、使える人は使ってね系の話ではあるので、あんまり完全に準オフィシャルな形にするのもマズい部分が強く、微妙なところです。
ただ問題なのは、
ちゃんとしたPPA >> 公式バイナリ > てけとーなPPA
という図解があることで、まぁちゃんとしたPPAだけは情報を提供した方がいいかなぁとは思うわけですが、それをJapanese Teamのサイトでやるとチャネルとして適正じゃない気がしてならないなぁという感じです。
(実際には「ちゃんとしたPPA」の遙か先にUniverse、さらにその先にMainがあるわけで、オフィシャルなリポジトリで事足りるのがいいなぁという感じではあるわけで……)
正直自分で使う分には困っていないので、まったくと言っていいほど分かっていない(仮定できないので上手く想定出来ていない)のですが、PPAだとか公式バイナリだとかを使う動機になる、
「新しいバージョンのソフトウェアを混在させて使いたい」
という要望はどの程度強いものでしょうか?
&その要望をする方の人物像というか、そういう方に期待していいスキルはどの程度のものでしょう?
公開するのであれば、
・まったくの初心者の方は手を出せない方がいい。
・何か起きたら自力でトラブルシュートできることが前提。
少なくとも、解決に必要な情報は自力で出せないと無謀。
(もしくは再インストール上等とか)
ぐらいの位置づけでならそれなりに安全かなと考えていたりします。
具体的なアクションはまだ全く決めていないので、聞くだけ聞いてやるやる詐欺になりかねなかったりもしますが……orz
最後の編集者: hito (2009-02-06 23:14:02)
オフライン