これまでと同じ方法で、yumコマンドを使ってFedoraを14から15にアップグレードしました。

まず、fedora-release-15-1.noarch.rpmを入れるのですが、fedora-release-rawhide-15-1.noarchと依存関係があると言われるので、そちらも同時に入れました。
あとは今まで通りです。

ここでエラーが出まくったので、エラーが出たプログラムを片っ端から削除。
特に普段使ってるようなものはなかったので……。そろそろ初めからインストールし直した方がいいのかなとも思いますが、面倒くさい。

再度yum -y upgradeを実行して、再起動……起動しない？！
ログインの手前で起動処理が止まってしまいました。

とりあえずデーモン達は動いているようで、HTTP、Samba、SSHなどは繋がり、ほっと一安心。
MySQLはエラーで起動していなかったのですが、/etc/my.conf に書いてある default-character-set=utf8 の書式が変わったのが原因みたいで、character-set-server=utf8 に書き直したらあっさり直りました。

• fedora15 mysql5.5 default-character-setが原因で起動できない - ITとともに生きよう

前回アップグレードしたときもそうだったのですが、Perlのバージョンが上がったことで、CGIが動かなくなってしまっていました。
これはCPANでモジュールのアップデートを行えばだいたい直ります。

しかし今回はそれでもMySQLへのアクセスが上手くいかない。PHPは素直に動いてくれるのに……。

エラーログを見るとこんな感じ。

ググってみるとこれは、libmysqlclient.so.16 が見付からないために mysql.so が読み込めないということのようなのですが、/usr/lib/mysql を見ると、あるのは libmysqlclient.so.18 で数字が16から18になってる。

これを読み込むように指定している場所は、/etc/ld.so.conf なようで、中を見てみると ld.so.conf.d/*.conf をインクルードしている。
そこで /etc/ld.so.conf.d/ 以下を見ると mysql-i386.conf というのがあったので開いてみると、/usr/lib/mysql と書かれていた。
特に間違いはないように思える。
16という数字はどこから出てきたのだろう？

mysql-server や perl-DBD-MySQL をyumで削除して入れ直してみても状況は変わらず。

ホントにOSからインストールし直そうかなあ……。

■ 追記

どこに libmysqlclient.so.16 と書かれているのか探していたら、以下の場所にあったので、DBD::mysqlをインストールし直したらCGIは表示されるようになりました。

（cpanコマンドでmakeとinstallできるみたいだけど）

起動されない問題の方は、SSHでログインして startx すれば起動することがわかりました。
/var/log/boot.log を見ても何が原因で止まってるのかよくわからない。

■ 追記

起動時に途中で止まってGUIが起動しない理由がわかりました。
依存関係で適当に削除したときに、ログイン画面を表示するための gdm を削除してしまっていたようです。
これをインストールし直したらログイン画面が出るようになり、デスクトップが使えるようになりました。

設置していた掲示板に、もの凄い数のスパムコメントがされるようになってしまったため、何ヶ月か前にページを撤去しました。
しかし、掲示板があったURLには未だにたくさんのアクセスがあります。
アクセスログを見てみると、リクエスト元のIPはバラバラで、アクセスの約８割がPOST。１分に４回くらいのアクセスがあります。
もともと流行っていた掲示板でもなかったので、アクセスはほぼ間違いなくスパムコメントを記入するためのBOTでしょう。

これらのアクセスに対し、初めは.htaccessでアクセスを禁止し、403を返すようにしていたのですが、それでもアクセスが止まないため、404を返すようにしてみました。
ところが、なおアクセスは続きます。

このように、明らかにスパムだとわかっているアクセスが続くと、ネットワークやサーバーに負荷がかかるというのは勿論ありますが、特に不便しているのはアクセスログが汚れてしまうことです。
アクセスログはこの掲示板へのアクセスのログで埋め尽くされ、容量が肥大していくだけでなく、現在運営しているページへのアクセスログが確認しづらくなってしまいます。
また、エラーログは、これらのアクセスに対する403や404のログで埋まってしまい、開発中のCGIの動作確認をしようと思っても、すぐにログが流れてしまいます。¹

ということで、この旧掲示板に対するアクセスログとエラーログを、他のログとは分けて保存できないかを考えました。

調べてみたところ、アクセスログは SetEnvIf というディレクティブを使うことで、条件ごとのログが保存できるようでしたので、httpd.confに以下のように設定してみました。

これは、リクエストされたURLに "mybbs" を含む場合に spam というタグを付けて、このタグが付いたアクセスを spam_log に保存し、それ以外を access_log に保存するという意味です。
"mybbs" の部分は正規表現で自由に設定できますので、スパムアクセスがあるアドレスに合わせて設定します。

エラーログの方は分ける方法がわかりませんでした。
なので、旧掲示板に対するアクセスがあった場合、リダイレクトさせてしまうことにしました。
そうすればエラーにならないので、エラーログは残りません。

リダイレクトには、410 Goneを使ってみました。410の場合リダイレクト先を指定しません。

アクセスを無くさせるためには他のステータスを返した方がいいのかもしれませんが……。

1. 開発環境と運用環境が同じサーバーですから。 ↩

OSをアップグレードしてPerlのバージョンが変わったら、CGIが動かなくなってしまったので、CPANモジュールをアップデートしてみることにしました。

ところが、CPANでinstallやupgradeコマンドを使うと、変更がある度にいちいち確認され、その度にyesと答えるためにエンターキーを押さなければなりません。
普段は内容を確認しながら処理を行えるのでいいのですが、今回みたいに一度にアップデートさせたい場合など、とても面倒です。
そこで、常にyesと答える設定を探しました。

yumのように-yオプションでできるかと思いきやダメで、少し覚えにくいコマンドを実行する必要があるようです。

これで自動的に更新してくれるようになります。

元のように確認してくれるようにするには、followをaskに変えて実行します。

Fedoraのバージョンを13から14にアップグレードしてみました。
最近全然サーバーをいじってなかったんですけど、そういえば新しいの出てたなって思い出して。もう15が出るとか出ないとか言ってるから、今更なんですけど……。

さて、アップグレードの方法ですけど、preupgradeというコマンドがあって、これを実行すれば簡単にできるよと言われていたので実行してみました。
表示されたウィザードを進めていくと、再起動するように言われたんですけど、再起動したところで「not driver found」と表示されて、先に進めない……。
幸いカーネルの選択画面でFedora13のカーネルを選べば、今まで通り普通に起動できたので、今度はCUI版のpreupgrade-cliを実行してみたけれど、結果は同じ。

ドライバが見付からないというのは、何のドライバが見付からないのだろう？
HDDを繋いでるSATAのドライバだろうか？
適当に選んでみても先に進めず。

よくわからないので、今度はFedora13にアップグレードしたときと同じ方法でやってみました。

すると、いくつかの依存関係で怒られたので、怒られたの全部削除¹してもう一回アップグレードを実行²。

今度は上手くいった！

最後に再起動。

確認。

ばっちり！

ちなみにpreupgrade-cliはLANG=Cじゃないと動かないらしいので、以下のように実行しました。

1. # yum remove hoge fuga ↩
2. これでいいのか？ ↩