投稿者: panhead

　rpmツールで調べたらphpのモジュールを入れてなかった(^^;

　しかし、問題はCDが使えないこと。fedoraに付いてくるパッケージツールはftpをサポートしていないので、「CD1を入れてOKを押してください」と言ってくる。TurboLinuxならパッケージを選ぶときにどこからインストールするかを選べて、ftpで最新版をインストールすることも簡単だ。

　結局、CDをノートPCに入れて、ftpで取り込みrpmでインストールした。そして、例によって、up2dateで最新版にアップデートしなければならなかった。これがまた時間がかかる。TL8wなら一回のオペレーションで最新版をインストール、しかもCDを入れるよりも高速に行える。fedoraのツールは見た目はいいが、オプションの選択枝が少なすぎる。まるでwindowsのウィザードを使ってるみたいだ。サーバーの負荷が高くてレスポンスが悪いようなら、ミラーを選べるようにするくらいはあってもいいと思うんだが・・・まあ、フリーウェアなのであまり強くは言えないんだが・・・

　とりあえず、カレンダーは動き出した。カテゴリーは相変わらずだが、これは仮サーバーのときと同じ症状なので、Duronの設定ミスというわけではない。まあ、見る人もほとんどいないようだからそのうちに対応しよう。

娘から幾つかクレーム。パーミッションの設定を間違えていて、更新できなくなっていた。

　webalizerというアクセスログ解析ソフトの設定をしようとしたら、既に終わっていた。ただ、このままでは仮想ホスト毎の解析ができないので、設定を分けcronで自動実行されるようにした。コマンドラインで動かしたときはちゃんと動いたのだが…cronの設定をしてちゃんと実行できた試しがないからなあ・・・

　これで忍者ともお別れできるかな。しかし、忍者のメリットは、サーバーが応答しないときに、外からチェックできることだ。サーバーが落ちていたら、そのサーバーでチェックすることはできないから困る。もう少し様子を見て、調子が良ければ外す。

————–

追記：
　カレンダーがおかしくなっている。カテゴリーも・・・・どちらもphpを使って表示している部分だ。
しかし、phpに関しては特に何もしてないんだよなあ・・・というより、Fedoraの場合は最初から入っていたから、設定してないんだよなあ・・・

　設定系は終わっていたので、最新のデータのみコピーするだけ。チェックを含めても1時間程度で完了。肩透かしを食らったような感じだった。こういうときは往々にして、大ポカをやっているのだが、元の環境は消さずにいるので、最悪、金曜の夜の状態まではロールバックできるからいいだろ。

　この機会にMTのアップデートもしてみた。これまで、ちょっと怖くてためらっていたが、今はめちゃ気楽だ。トラックバックが多すぎるようなので、ひそかに感謝して使わせていただいた。

引き続き、MT2.661用の日本語化パッチをリリースしました

　これまで、日本語化してあっても英語のままだったところが日本語になっていて、かえって戸惑うことがあるが、慣れの問題か。

　写真は、サーバー状態のomnibook。劣悪な環境でがんばってます。

　ところで、Fedoraの文字化けについて、EUCからUTF-8に移行したためという情報を読んだ。そうか、macで変換してアップロードしても文字化けが直らなかったのは、そのせいか。そして、cgiで文字化けをしたのはブラウザの宣言と本文の文字コードが矛盾したせい。TL8wで文字化けしなかったのは、コード体系がEUCだったからか。今頃になって、パズルのピースがはまった。

　同じLinuxなのに、文字コード体系が異なるなんて、全く予想できなかった。しかし、こういうことは「ビギナーズ　バイブル」にはしっかりと書いておいて欲しいよな・・・まあ、ちゃんと読んでないのではあるが(^ ^;

追記：
　ところで、Duronサーバーへ環境を移植するとき、スムーズに移せなくて戸惑うことがあった。/var/www/cgi-bin/とか/var/lib/mysql/のディレクトリは、そのままではコピーできない状態になっていた。TL8wからはあっさりとコピーできたので、理由が分からずに焦った。ここらへんで、すぐに所有者とパーミッションが思い浮かばないのが文化の違いだ。

　それと、これは実に間抜けな失敗を一つ報告。パーミッションを設定するのに、ftpでコピーしたファイルはそのままgftpを使うことが多い。gnomeのツール（macでいうfinder）はイマイチ使いにくいからだ。ところが、そこで実につまらないミスを犯してタイムロスをしていたような気がする。それは、パーミッション設定ダイアログのレイアウトがソフトによって違うことに起因する。例えば644だと、下のように食い違ってしまう（本来は左）。

　　　　　　　　　　read　　write　　exe　　　　　owner　　group　　other
　　　　　owner 　　Ｘ　　　Ｘ　　　　　　read　　　Ｘ　　　　Ｘ　　　　　　　　　　
　　　　　group　　　Ｘ　　　　　　　　　write　　　Ｘ　 　　　　　　　　　
　　　　　other　　　Ｘ　　　　　　　　　　exe　　　Ｘ　 　　　　　　　　

　この例では、一般ユーザーは該当ファイルを読み出すことができないからエラー必至だ。俺はfetchのクセで左のようなイメージで、反射的に設定していた。ffftpかコマンドラインのように数字で設定すればいいのだが、gnomeのツールには無い。cgiが動かずに苦労したのはこれが原因のような気がしてきた。情けなや・・・そういえば、ffftpを使ってwinから設定したcgiが問題なく動きやすい気がするのは、パーミッションの設定に数字が使えるからかもしれない。

　さすがに同じ環境で2度目の作業は楽だ。ほとんどのセットアップが終わった。chownとftpでのパーミッション設定で一括設定変更ができるようになったのが大きい。

　/var/www/cgi-bin/以下のファイルをftpでコピーすることができなかった。同じフォルダを別のディレクトリにコピーした上でftpでアクセスしたら難なくコピーできた。Tl8wからは問題なくコピーできたので、apache2が抑えているのか。

　後は、mySQLのユーザー設定とphp（mtプラグイン）の見直しか。

　ただ、fedoraに乗り換えてから、アップデートの負担が激増した。頻繁にアップデートされること自体は喜ばしい。セキュリティパッチを素早く供給してくれるのだから。先日インストールしたノートPCは3日ほど前に全パッチを適用したのに、次の日にはアップデートを促すインジゲーターが赤になった・・・

　問題なのは、サーバーの速度。ダウンロード速度が2kb/sとかでは使い物にならない。カーネルやglibといった大物になると、ダウンロードだけで数時間かかるし、止まることも多い。

　TurboLinuxにはこんな気の効いたユーティリティはなかった。月一程度の頻度で、zabon（だったかな）を使ってアップデートするか、サイトに行ってセキュリティ情報をチェックするしかなかった。しかし、スピードは速かった。比較することが憚られるくらいに差がある。TurboLinuxのサイトからは、100メガクラスでも10分程度でダウンロードが可能だった。１メガや2メガのアップデータなんかは、目の前で終わってしまう。終わった後の確認がないので、ちゃんと終わったのか不安になるほどだった。

　fedoraでは100メガクラスのものをやったことはないが、考えただけでうんざりだ。ダウンロードしている間に次のアップデーターが公開されるだろう。Apt-getというコマンドラインのユーティリティでもできるということでやってみた。確かにレスポンスはいいが、警告ユーティリティが青くはならない。情報が更新されない仕様なのか、俺の使い方が間違っているのかはわからない。

　無償のfedoraと有償のTurboLinuxを同じ土俵で語ることはできないが、こんなことに時間をとられてはいけない業務ユーザーなら、RedHatかSuSEのほうが正解かもしれない。

　ところで、サーバー用のDuronのCDがおかしい。netatalkをインストールしようとしてもCDを認識しない。CDから起動することもできない。システムがCDに読み取り要求を出してもCDが言うことを聞かないようだ・・・・fedoraのインストール時に活きていたからよかったものの、かなり不便だ。CD-RWドライブに換えたろかな・・・

　Duronマシンは、Duron1.2Gを積んでいるので、クロックスピード的には、これが入っているノートPC（P3-700Mhz）よりかなり速い。しかし、デスクトップ環境で使ってみても全然そんな気がしないのは何で？