|
2006,03,30, Thursday
[root@fedoracore4 ~]# wget http://ovh.dl.sourceforge.net/sourceforge/phpmyadmin/phpMyAdmin-2.8.0.2.tar.gz
--16:24:01-- http://ovh.dl.sourceforge.net/sourceforge/phpmyadmin/phpMyAdmin-2.8.0.2.tar.gz => `phpMyAdmin-2.8.0.2.tar.gz.1' ovh.dl.sourceforge.net をDNSに問いあわせています... 213.186.33.91 ovh.dl.sourceforge.net|213.186.33.91|:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 3,453,510 (3.3M) [application/x-gzip] 100%[=========================================================================>] 3,453,510 129.45K/s ETA 00:00 16:24:21 (177.54 KB/s) - `phpMyAdmin-2.8.0.2.tar.gz' を保存しました [3453510/3453510] [root@fedoracore4 ~]# cd /var/www/html [root@fedoracore4 html]# mv phpMyAdmin-2.8.0.2.tar.gz /var/www/html/phpMyAdmin-2.8.0.2.tar.gz [root@fedoracore4 html]# ls |grep phpMyAdmin phpMyAdmin phpMyAdmin-2.8.0.2.tar.gz 古いVerのphpMyAdminがある。 リネーム [root@fedoracore4 html]# mv phpMyAdmin phpMyAdmin-old 解凍 [root@fedoracore4 html]# tar zxvf phpMyAdmin-2.8.0.2.tar.gz 中身を見てみるとまた変わっているようです(^^;; まずはhttp://userdomain/phpMyAdmin/ へアクセスしてみると…  phpMyAdmin 2.7.0 pl2 インストール設定 |
|
2006,03,30, Thursday
LogWatch 6.0.1 からとLogWatch 7.2.1 からメール届いています。
ここ最近fedoracore4core4で立ち上げたサーバーなんで、updateしたタイミングで重複するようになったんでしょう。 cronを確認 [root@fedoracore4 ~]# ls -all /etc/cron.daily/ 合計 72 drwxr-xr-x 2 root root 4096 3月 23 05:29 . drwxr-xr-x 86 root root 12288 3月 30 12:34 .. lrwxrwxrwx 1 root root 28 2月 10 15:23 00-logwatch -> ../log.d/scripts/logwatch.pl -rwxr-xr-x 1 root root 135 3月 4 2005 00webalizer -rwxr-xr-x 1 root root 276 3月 17 2005 0anacron lrwxrwxrwx 1 root root 39 3月 23 05:29 0logwatch -> /usr/share/logwatch/scripts/logwatch.pl -rwxr-xr-x 1 root root 1042 5月 14 2005 certwatch -rwxr-xr-x 1 root root 118 1月 27 00:51 cups -rwxr-xr-x 1 root root 180 4月 1 2005 logrotate -rwxr-xr-x 1 root root 418 2月 13 19:10 makewhatis.cron -rwx------ 1 root root 68 2月 10 15:19 ntpdate -rwxr-xr-x 1 root root 2133 11月 23 2004 prelink -rwxr-xr-x 1 root root 104 7月 14 2005 rpm -rwxr-xr-x 1 root root 246 8月 10 2005 slocate.cron -rwxr-xr-x 1 root root 286 4月 16 2005 tmpwatch -rwxr-xr-x 1 root root 158 12月 6 01:09 yum.cron lrwxrwxrwx 1 root root 39 3月 23 05:29 0logwatch -> /usr/share/logwatch/scripts/logwatch.pl の方が新しい日付なので恐らくこちらである。 [root@fedoracore4 ~]# ./etc/cron.daily/0logwatch メールを受信し、Verを確認。 7.2.1だった。 念のため [root@fedoracore4 ~]# ./etc/cron.daily/00-logwatch 6.0.1だった。 よってこのシンボリックリンクを削除すればOKである。 [root@fedoracore4 ~]# rm -rf /etc/cron.daily/00-logwatch 今度は実体削除 まずは確認 [root@fedoracore4 ~]# ls -all /etc/log.d/ 合計 48 drwxr-xr-x 5 root root 4096 1月 28 21:21 . drwxr-xr-x 86 root root 12288 3月 30 12:34 .. drwxr-xr-x 4 root root 4096 1月 28 21:21 conf drwxr-xr-x 2 root root 4096 1月 28 21:21 lib lrwxrwxrwx 1 root root 19 2月 10 15:23 logwatch -> scripts/logwatch.pl lrwxrwxrwx 1 root root 18 2月 10 15:23 logwatch.conf -> conf/logwatch.conf drwxr-xr-x 5 root root 4096 1月 28 21:21 scripts 6.0.1へのシンボリックリンクが張ってある。 [root@fedoracore4 ~]# rm -rf /etc/log.d/logwatch [root@fedoracore4 ~]# rm -rf /etc/log.d/scripts/logwatch.pl これで実体とシンボリックリンクは削除できました。 logwatch.confも恐らく6.0.1でしょうが念のため… [root@fedoracore4 ~]# whereis logwatch.conf logwatch: /usr/sbin/logwatch /etc/logwatch /usr/share/logwatch /usr/share/man/man8/logwatch.8.gz [root@fedoracore4 ~]# ls -all /usr/sbin/logwatch lrwxrwxrwx 1 root root 39 3月 23 05:29 /usr/sbin/logwatch -> /usr/share/logwatch/scripts/logwatch.pl 7.2.1へのシンボリックリンクでした。 [root@fedoracore4 ~]# ls -all /etc/logwatch 合計 28 drwxr-xr-x 4 root root 4096 3月 22 21:47 . drwxr-xr-x 86 root root 12288 3月 30 12:34 .. drwxr-xr-x 4 root root 4096 3月 23 05:29 conf drwxr-xr-x 2 root root 4096 3月 22 21:47 scripts [root@fedoracore4 ~]# ls -all /etc/logwatch/conf/ ignore.conf logfiles/ logwatch.conf override.conf services/ さらに下の階層へ [root@fedoracore4 ~]# ls -all /etc/logwatch/conf/ 合計 28 drwxr-xr-x 4 root root 4096 3月 23 05:29 . drwxr-xr-x 4 root root 4096 3月 22 21:47 .. -rw-r--r-- 1 root root 81 3月 22 21:47 ignore.conf drwxr-xr-x 2 root root 4096 3月 22 21:47 logfiles -rw-r--r-- 1 root root 91 3月 22 21:47 logwatch.conf -rw-r--r-- 1 root root 77 3月 22 21:47 override.conf drwxr-xr-x 2 root root 4096 3月 22 21:47 services [root@fedoracore4 ~]# [root@fedoracore4 ~]# ls -all /usr/share/logwatch 合計 28 drwxr-xr-x 6 root root 4096 3月 23 05:29 . drwxr-xr-x 170 root root 4096 3月 23 05:29 .. drwxr-xr-x 4 root root 4096 3月 23 05:29 default.conf drwxr-xr-x 4 root root 4096 3月 23 05:29 dist.conf drwxr-xr-x 2 root root 4096 3月 23 05:29 lib drwxr-xr-x 5 root root 4096 3月 23 05:29 scripts [root@fedoracore4 ~]# ls -all /usr/share/logwatch/default.conf/ 合計 24 drwxr-xr-x 4 root root 4096 3月 23 05:29 . drwxr-xr-x 6 root root 4096 3月 23 05:29 .. drwxr-xr-x 2 root root 4096 3月 23 05:29 logfiles -rw-r--r-- 1 root root 4263 3月 22 21:47 logwatch.conf drwxr-xr-x 2 root root 4096 3月 23 05:29 services /usr/sbin/logwatch 7.2.1へのシンボリックリンクでした。 /etc/logwatch /etc/logwatch/conf/logwatch.conf /usr/share/logwatch /usr/share/logwatch/default.conf/logwatch.conf これが6.0.1のconf fileで間違いないでしょう。 って訳でリネーム [root@fedoracore4 ~]# mv /etc/log.d/conf/logwatch.conf /etc/log.d/conf/logwatch.conf.bk [root@fedoracore4 ~]# ./etc/cron.daily/00-logwatch Cannot open file /etc/log.d/conf/logwatch.conf: そのようなファイルやディレクトリはありません リンクを削除したんで当然。 [root@fedoracore4 ~]# ./etc/cron.daily/0logwatch メールを確認。 問題なく動作 削除 [root@fedoracore4 ~]# rm -rf /etc/log.d/conf/logwatch.conf |
|
2006,03,30, Thursday
yumでupgradeしたことによる問題点というのは見つかりませんでしたが、世間ではLAMP(Linux apache MySQL php)エンジニアと呼ばれる私の仕事では以下のようにメジャーVerが変更となると大変なことになる可能性を秘めています。
今回以下の環境から fedoracore3(kernel-2.6.12) apache-2.0.53 mysql-3.23.58 php-4.3.11 次のような環境に変更しました。 fedoracore4(kernel-2.6.15) apache-2.0.54 mysql-4.1.16 php-5.0.4 まずは Kernel これは一番ビビリながらも問題はありませんでした。 続いてapache これもほとんど変わっておらず、httpd.confもそのまま使用できています。 次の問題はPHPでした。 変数を受け取らなかったり、文法がそぐわなくなっていたのかハングしたりしました。 これはメジャーVerが変わっており、php.iniの問題だと思い、original fileは残して、別サーバーのphp.iniを持ってきてover wright。 /etc/init.d/httpd reload で再起動 これで大半のスクリプトはOKになりました。 MySQlこれはデータそのものはコンバートしてくれていましたが、文字コードに関する部分が変更されており、ほとんどのphp sourceに $rtn = mysql_query("SET NAMES ujis" , $con); というおまじないを入れていましたが、これが逆に文字化けの原因になりました。 これをすべてコメントアウトしたら、今のところ問題は発生しておりません。 やっぱり基幹業務動くサーバーのupgradeはいやです  fedoracore4の2006/03/30現在 最終Verは以下の通りですから fedoracore4(kernel-2.6.15) apache-2.0.54 mysql-4.1.16 php-5.0.4 fedoracore5(Kernel 2.6.15) apache-2.2.0 mysql-5.0.18 php-5.1.2 基幹業務動くサーバーについては fedoracore4 → fedoracore5 はしばらく待とうと考えています。 1番怖いのはMySQLのメジャーVerがまた変わったことにより、phpとの連携部分の不具合やソースが異なる可能性があること等々を勘案すると現時点では、fedoracore5で動いているサーバーでconf file等の設定や新たなスクリプト作成等々のノウハウを積み重ねながら、安定するのを待つことにします。 まぁcore1 core2の頃と比べるとかなり信頼しておりますが… |
|
2006,03,29, Wednesday
基幹システムが動いていたFC3もupgradeすることにしました。
これは安全策をとってFC4にupgradeすることにしました。 wget ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/4/i386/os/Fedora/RPMS/fedora-release-4-2.noarch.rpm rpm -Uvh fedora-release-4-2.noarch.rpm yum update kernel 本来ここでリブートするのですが、月末にシステムが止まってはエライことなので(じゃやるなよ)、少しビビリが入ってしまい再起動できませんでした yum check-update は特に問題が出ませんでしたが、 yum -y update ではkernel-utils kernel-smpで依存関係に不具合が生じていたので、グループ毎にupdateしようと決意。 yum grouplist でグループ検索を行うと… すべて2つずつ登場しました(^^;; なんとなく今動いているカーネルと、最新のカーネルの違いを見ているようだったので rpm -qa kernel で入っているカーネルを検索 kernel-2.6.*_FC3 が数個 kernel-2.6.9 (インストール時のもの)がひとつ kernel-2.6.*_FC4 がひとつ ※このServerは古いカーネルも万が一に備えて残していましたので、現在残っているカーネルをFC4以外を削除することにしました。 これを削除 yum remove kernel-2.6.*_FC3 kernel-2.6.9 再度チャレンジ yum -y update 760 packagesのupdateなんでかなりかかりそうですが今のところ順調です。 すべて終われば人のいない時間帯に再起動してみようと考えてます。 あと、パッケージで依存関係にエラーが生じている場合は一旦removeして、update後にinstallするとOKになることが多いです。 それとbuildしたrpm packageなどは/etc/yum.cofを編集してupdateしないようにしておきました。 これで今週横着upgradeは4台目。 慣れてきましたがやっぱりドキドキします(笑) 追記 Xoen 2.8GHz × 2 2048GB 10000rpm SCSI HDD RAID 0 光ファイバー 100Mbps 環境で760 packagesのupdateは2時間弱でした。(そのままお昼休憩に行ったんで詳細不明) apache PHP MySQL Postfix などは何も問題ありませんでしたが、dovecotだけが以下のようなエラーが発生しました。 conf fileも見直しましたし、以下のfileの存在も確認しましたが、問題がわかりませんでした。 [root@fedora ~]# /etc/init.d/dovecot start Dovecot Imap を起動中: Fatal: Can't use SSL certificate /etc/pki/dovecot/certs/dovecot.pem: No such file or directory [失敗] dovecotは設定箇所も少ないですし、remove installすることにしました。 それで一発OKでした。 あとは再起動のみ |
|
2006,03,29, Wednesday
オーストラリアGPはこの10年間シーズン開幕戦を行ってきましたが、今年は4年に1回開催される国際スポーツ大会“コモンウェルズゲーム”がメルボルンで行われた関係で、第3戦となりました。
日本とは逆に秋深まっていく南半球での戦いはこの2戦の高温多湿の激戦から一転する環境となるでしょう。 こんどはいかにタイヤの温度を上げるかに各チームは力を注いでくるでしょう。 またこのGPはモナコ同様、公道を使用してレースが行われますが路面の凹凸が多く低速コーナーほど荒れておりより多くのグリップを必要とされます。 マレーシアGPでフェラーリがフロントウイングの設計(高速時可変)をめぐってクレームがつき、今週末のオーストラリアGPまでにフロントウイングをモディファイすることを約束していますし、空力・タイヤチョイスが今から見ものです。 |