久しぶり、である。
いろいろ、あった。いろいろ、とか、様々、とか、指導生どもには、使ってはいけない言葉、に、指定してある。何も記述していないからだ。
つまり、何もなかった、の、かも、しれない。
とりあえず、サーバどもは、言うことを聞かない。
portコマンドを再実行したり、perl 5.10を再導入したり…portを使うと、perl 5.8.9が導入されちゃう。
TigerからLeoperdにアップグレードしたり…そしたら、メール送信ができなくなったりして。
自宅LeopardサーバにMovable Type 4.23を導入した。
まず、MySQLのソケット問題が浮上して、phpMyAdminが利用できなくなった。
Loepardサーバには、MySQLが導入されているので、とりあえずそのまま利用、DBD::mysqlの導入のためにライブラリを/usr/local/mysqlに置く。
これが、また、悩ましい。
LeopardサーバのMySQLのバージョンに合わせて、
mysql-5.0.67-osx10.5-x86_64.dmg
を置いたところ。DBD::mysqlがmake testで引っかかる。
で、
mysql-5.0.67-osx10.5-x86.dmg
に代えた。
mysql_configの吐き出す情報では、socketが
/var/mysql/mysql.sock
となっている。上述のdmgを元に導入すると、
/tmp/mysql.sock
と、場所が異なるのであった。
/etc/my.cnf
を作成してsocketの位置を確定、するだけで良いのだぁ、と思い込んだところでミス。
/etc/php.ini
にも記述する必要があった、と、気付くまでに１日。
ついでに、phpMyAdminのバージョンを2.11.6から3.12に上げてしまう。
同時に複数の条件を変えると、エラーの原因が突き止められなくなる、のは、当然、知ってる、し、指導生どもには偉そうに言ってはいるけど、ね。
案の定、Movable Typeでつまづく。
アップグレードの途中で、
アップグレード中にエラーが発生しました
failed to execute statement CREATE TABLE mt_log
( log_id integer NOT NULL PRIMARY KEY auto_increment, log_author_id integer DEFAULT 0, log_blog_id integer DEFAULT 0, log_category varchar(255), log_class varchar(255) DEFAULT ‘system’, log_created_by integer, log_created_on datetime, log_ip varchar(16), log_level integer DEFAULT 1, log_message mediumtext, log_metadata varchar(255), log_modified_by integer, log_modified_on datetime ):
Table ‘mt_log’ already exists at lib/MT/Upgrade.pm line 2553.
と、怖いメッセージが出てきてしまって、先に進めない。
ググってみても、Upgrade.pmを覗いても、よくわからない。
要するに、元のデータベースが、ヘン、なのだろう、と、phpMyAdminでmt_logテーブルを表示しようとしたらっ
なんと、壊れていた、らしい。
ログだから、まあ、いいや、と、削除しちまった。
コマンドならば、
drop table mt_log;
だな、多分。
無ければ、作るはず、という予想は当たり、無事にアップグレードが成功。
このような練習を積んで、公式サーバのメンテナンスにかかるのである。
それにしても、TigerからLeopardに代えたサーバは、未だにメールのやり取りができていない。
実は、２度目、である。
アップグレード直後は、Postfixの設定と、clamav, freshclam, amavisdの設定がTigerのままだったのでうまく行かない、ということは、直ぐにわかった。幸い。
２度めは、よくわからない。
それから、TigerからLeopardにアップグレードすると、WebサーバはApache 1.3が動くの、ね。
サーバ管理には、2.2にアップグレードするボタンがあるのだけれども、クリックすると、致命的なエラーが起きちまう。
何でも、translateできないらしい。
で、apachectlを使って、httpd.confをチェック、Tigerサーバの設定で、フォルダ名に空白を使用していたのだが、そこで引っかかることが判明。空白は%20に置き換え、さらに、/etc/apache2/sites/内を空にしてから再挑戦、無事に成功した。
こうゆう仕事って、誰も認めてくれないのだよね〜
担当医は、夜のサーバメンテナンス禁止令を出した。
が、サーバのメンテナンスは、誰も利用していない夜中しかできないのだ、な。
ふん。
いくつか、暗い歌を詠んだ。それも、ぼちぼち、載せてみよう、かな。
Leopard用のclamav, freshcalm, amavisdの設定も、多少変えた、し、な。
既に書いたような設定をしてしまうと、ディスクユーティリティでアクセス権を修復すると元に戻ってしまって、埒が明かない。
ぼちぼち、なんて言っていると、直ぐに、４月が来てしまう、かな。
Comments are closed