Fedora研究室の最近のブログ記事
もうじきFedora 10が出るので、Fedora 8 を使っていたLinux機を Fedora 9 に移行した(Fedora 8 から Fedora 10 への飛び級はシンドイと予想されるので)。歴代の移行方法はここに簡単に説明されているが、今回はハマった。
pythonに関して、Fedora 8のほうがFedora 9よりバージョンが上なので、python関連のdependencyでyumがこけてしまう。通常は、エラーをだすモジュールを一度削除して再インストールすればいいのだけど、yumがpythonで動くのでpythonを削除すると、今度はyumが動かなくなってしまう。
しかたないのでrpmを使って、pythonを手動で更新(正確にはバージョンダウン)した。また、原因不明の更新エラーを出していたopensslもrpmで更新した。今回の件でyumが万能でなはないことと、rpmでyumの弱点をカバーできることを勉強した。

FC5 にはsmbmountが入っていない。単純に「忘れた」だけだそうだ。
smbmount missing in FC5 Test 3.
代わりに、mount.cifsが使えるそうなので、やってみたらちゃんと機能した。まずは一安心。
UNIXとWindowsのファイルシェアは、UNIXにsmbボリュームを作ってWindowsからマウントする方法と、WindowsのsmbボリュームをUNIX側からマウントする方法がある。後者のほうが断然楽チンなのだが、上記の「忘れた」のおかげで、ちょっとトラぶった。
freshrpmで配布されているffmpegは32bit版だし、AACやAMRに対応してない。ということでソースコード集めてきてmakeした。ちゃんと64bit版になっているようだし、コアを2つ使ってくれているようだ。性能は上がっているのかな?あまり期待してないけど。
と書いているうちにクラッシュした。あららら。映画丸1本のトランスコードは辛かったかな?
VMware 5.5ではマルチCPUにも対応している。ここが微妙で、ゲストOSにマルチCPUに見えるようCPUのエミュレーションをしているのか?マルチCPUのハードウェアでちゃんと(性能がでるように)動くのか?
早速試してみると、前者はあたりまえとして、後者もちゃん実現されている。
性能もちゃんと出ているようだ…
おっと、それ言うのは早計だ。あぶないあぶない。VMwareはCrystalMark(今回の性能計測ツール)をも騙している※のかもしれない(どこやらのベンチマーク対策のように悪意はないと思うが)。自分てストップウオッチもって自分の目で確認すべきだな。今度やってみよう。
※計測の基準となる信号(具体的に何かしらない)を遅らせてしまば、ソフト上では早く動いているように見える。特殊相対性理論に似ているな。
CPUを64bitに換装したので、64bit対応を謳っているVMwareとFedoraCore4を動かしてみた。これが結構大変だった。
FedoraCore4がリリースされてからずいぶん経っていて、パッチが600個以上出ていているが、一度にすべてのパッチを当てようとすると、パッチをインストールするツール(yum -y update)がフリーズしてしまう。このフリーズは致命的で各パッチ間の関係(dependency)がズタズタに壊れてしまう。VMwareで仮想ディスクを丸ごとバックアップをとっているので、復活が楽だが、リアルなマシンだったらと思うとぞっとする。WindowsXPみたく、サービスパックのCD(isoイメージ)を出してくれるとありがたいのだが…
しかたがないので、パッチをひとつずつあてるスクリプトを作って、ようやく全部のパッチを当てることができた。
「お~これが64bit Linux」という実感はまだできていない。
アパッチの長年(と言ってもここ1~2年)の謎が解けた。HTMLファイルを直接/var/www/htmlより下のディレクトリで作る場合はちゃんと表示されるのに、/tmp下などで作ったHTMLファイルをmvした場合、403エラーが起きて表示できないという摩訶不思議な現象。
原因はSELinuxの「コンテンツにセキュリティをかける」という機能。SELinixに許しを得たコンテンツ(HTMLファイル)でないとアパッチがはじいてしまうのであった。
SELinuxに許しを頂くおまじないは…
chcon -t httpd_sys_content_t <ファイル名>



