このサーバーはdebianで10年以上運用しておりますが、ちょこちょこ作ったWebアプリがapt-get upgradeで動かなくなるということを繰り返しています。apt-get upgradeって打ちたくなっちゃうんですよね…。

個人で適当に運用しているサーバーなので、特にテスト等もせずいきなり実行します。一応万が一の時のためのバックアップはありますけどね。今回も色々と動かなくなってしまって個別に対応して直したのですが、一番困ったのはrubyで書いたWebアプリが動かなくなったことでした。出ていたエラーは以下。

undefined method `mappings' for Tilt:Module

sinatraの内部でテンプレートを呼び出した時にこのエラーが出てました。ぐぐっても情報が無く、結構困りました。でも、結局アップグレードで挙動が変わっているわけでバージョンに依存していることはわかっているのですが。

結局きちんと色々なモノのバージョンを揃えてあげないといけないわけで、観念してきちんと全部bundleを適用するだけで解決しました。sinatraとtiltのバージョンの組み合わせが変なことになっていたのだと思います(予想)。やってしまえば簡単で安定的に運用できるのですが、動いているものをいじるのって意思の力が必要で、どうしても後回しになっちゃうんですよね…。今回はトラブルでそもそも動かなくなったので重い腰を上げました。

以下のブログが大変参考になりました。ありがたや。

毎日cronで日記にtwitterでのつぶやきを収集して投稿するスクリプトを実行しています。cronから実行しているのはシェルスクリプトで、その中からrubyスクリプトを呼んでいます。

(/etc/cron.d/twitter2diary)
1 0 * * * ebi /home/ebi/twitter2tdiary/twitter2tdiary.sh

(/home/ebi/twitter2tdiary/twitter2tdiary.sh)
#!/bin/sh
cd /home/ebi/twitter2tdiary
ruby /home/ebi/twitter2tdiary/twitter2tdiary.rb

以前はこれできちんと動いていたのですが、apt-get upgradeでwheezyにしてからきちんと動かなくなってしまいました。直接の原因は内部で使用していたtwitter gemで、これの最新版をgem install twitterでインストールし、最新版のgemで動くようにスクリプトを修正することで、普通にシェルからtwitter2tdiary.shを呼べば正常に動作するようになりました。

でも、それでもcronから実行すると失敗してしまいます。

/usr/lib/ruby/1.9.1/rubygems/dependency.rb:247:in `to_specs': Could not find twitter (>= 0) amongst [] (Gem::LoadError)
       from /usr/lib/ruby/1.9.1/rubygems/dependency.rb:256:in `to_spec'
       from /usr/lib/ruby/1.9.1/rubygems.rb:1231:in `gem'
       from /home/ebi/twitter2tdiary/twitter2tdiary.rb:4:in `
'

きっと環境変数とかその辺りがおかしいんだろうと思いつつ、そもそも仕組みがわかっていないのでその辺を確認してみたい。

とりあえずdebianでは/var/lib/gems以下にgemが置かれるらしい。確かにあった。

/var/lib/gems/1.8/gems$ ls | grep twitter
twitter-2.0.2/
twitter-3.1.1/
twitter-3.2.0/
twitter-3.3.1/

では、普通に実行するとこれが使われているという事なのだろう。rubyのバージョンは?

 $ ruby -v
 ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

1.9。upgradeまえは1.8だったはずで、ruby1.8だから/var/lib/gems/1.8を使う…という訳じゃないのだろうか?「”/var/lib/gems/1.8″ “/var/lib/gems/1.9″」でググってみる。

  • Linux で Ruby のインストール http://www.kkaneko.com/rinkou/ruby/rubyinstalllinux.html

ここによるとやっぱりruby1.8とruby1.9が共存している環境では/var/lib/gems/1.8と/var/lib/gems/1.9が両方存在しているようだ。よくわからないけど以下のコマンドを打ってみる

gem install rubygems-update
/var/lib/gems/1.8/bin/update_rubygems

RubyGems 1.8.24 installed

に加えて

RubyGems installed the following executables:      /usr/bin/gem1.9.1

なんてのも表示された。

gem1.9.1 install rubygems-update

としてみる。

Successfully installed rubygems-update-1.8.24
1 gem installed
Installing ri documentation for rubygems-update-1.8.24...
Installing RDoc documentation for rubygems-update-1.8.24...

となった。gem1.9.1を実行しているのにrubygems-update-1.8.24がインストールされるって、これは正しいのだろうか?

この段階で/var/lib/gems/1.9.1は存在しないこの段階ですでに何かおかしいのかな。

よくわからないけどこの段階でgem1.9.1ってコマンドがあるのなら……思って以下のコマンドを打ってみた

gem1.9.1 install twitter

するとなにやらインストールされた。

Fetching: twitter-3.4.0.gem (100%)
Successfully installed twitter-3.4.0
1 gem installed
Installing ri documentation for twitter-3.4.0...
Installing RDoc documentation for twitter-3.4.0…

でも、/var/lib/gems/1.9.1はできてない……。

echo $GEM_HOME
/var/lib/gems/1.8/

むむ。これが原因なのか?これはどこで設定されてるんだ。

調べたら~/.bash_profileで設定されてた。これは自分で書いたのか?とりあえず消してみる。

gem1.9.3なんてのがあるのにも気がついたので

gem1.9.3 install twitter
Fetching: multipart-post-1.1.5.gem (100%)
Fetching: faraday-0.8.1.gem (100%)
Fetching: multi_json-1.3.6.gem (100%)
Fetching: simple_oauth-0.1.9.gem (100%)
Fetching: twitter-3.4.0.gem (100%)
Successfully installed multipart-post-1.1.5
Successfully installed faraday-0.8.1
Successfully installed multi_json-1.3.6
Successfully installed simple_oauth-0.1.9
Successfully installed twitter-3.4.0
5 gems installed
Installing ri documentation for multipart-post-1.1.5...
Installing ri documentation for faraday-0.8.1...
Installing ri documentation for multi_json-1.3.6...
Installing ri documentation for simple_oauth-0.1.9...
Installing ri documentation for twitter-3.4.0...
Installing RDoc documentation for multipart-post-1.1.5...
Installing RDoc documentation for faraday-0.8.1...
Installing RDoc documentation for multi_json-1.3.6...
Installing RDoc documentation for simple_oauth-0.1.9...
Installing RDoc documentation for twitter-3.4.0…

なにやらうまく行ってる予感。でも、/var/lib/gems/1.9.3なんてのはできてない。

$gem1.9.3 which twitter
/usr/lib/ruby/1.9.1/twitter.rb

おや、そんなところにインストールされたんですか。

$gem1.8 which twitter
/var/lib/gems/1.8/gems/twitter-3.4.0/lib/twitter.rb

ってことで別の場所に入ってるのでこれでいいのかもしれない。これで様子をみてみよう……。

先日debianをwheezyにアップグレードしたらWordpressサイトがおかしくなってしまいました。

今日は金曜日なので気分的に余裕があり、ちょっと気合いを入れて再度wordpressをアップグレードして対処してみました。index.phpから順番に処理の流れを追って行って、どこでwp-config.phpを読み込んでいるのかを見てみました。結局以前は/etc/wordpress/wp-config.phpが私のシステムでは読み込まれていたのですが、今回のパッケージでは/usr/share/wordpress/wp-config.phpが読み込まれていました。

本来ならwp-config.phpの場所が変わっても大丈夫なはずなのですが、wp-config.phpを直接書き換えて複数サイトを保持できるようにしていたことの弊害が出ちゃった形です。

結局以下のように書き換えて対応。

26a27,29
> } elseif (file_exists('/etc/wordpress/config-'.$debian_server.str_replace("/", "_", dirname($_SERVER['PHP_SELF'])).'.php')) {
>     require_once('/etc/wordpress/config-'.$debian_server.str_replace("/", "_", dirname($_SERVER['PHP_SELF'])).'.php');
>     define('DEBIAN_FILE', '/etc/wordpress/config-'.$debian_server.str_replace("/", "_", dirname($_SERVER['PHP_SELF'])).'.php');

変数化しろよ!とかあると思いますが。php知らないので文法調べるのすらめんどくさい…。

その後もpluginやthemeが/usr/share/wordpress/wp-contentから/var/lib/wordpress/wp-contentに場所が変更になった影響で色々と動かないサイトがあったり動かないプラグインがあったりでかなり時間取られちゃいました。やっぱり勝手に改造してるとこういうときに大変ですねぇ……。

wordpressが標準でマルチサイト対応になったようなのでそちらに乗り換えてもいいかもしれないですが…、しばらくはいいかなぁ……。

apt-get upgradeの結果sinatraで作成してあったWebアプリ系が全滅してました。別にsinatraのせいな訳ではないですが。

歴代はてブ多い順は単独で実行すると以下のエラーが。

ArgumentError - comparison of Symbol with Date failed:
         hateburanking.rb:54:in `>='

ググると全く同じことで困っている人が。

リンクをたどると説明がありました。

 - @dataset = @db[:entry].filter((:date >= month_begin) & (:date <= month_end)).order(:bookmarkcount.desc)
+ @dataset = @db[:entry].filter{(date >= month_begin) & (date <= month_end)}.order(:bookmarkcount.desc)

これで解決しました。

メジャーバージョンが変わっていることもまともにチェックせずに、適当にapt-get update;apt-get upgradeしたらシステムが大きく変わって色々と動かないものがでております(^^;

他にも色々と動いてないものがあるからやらなきゃ。

apt-getを使って簡単に導入!…できるつもりだったのですが、結構はまってしまったので私がはまったポイントを誰かのためにメモ。

  • passenger-install-apache2-moduleは/var/lib/gems/1.8/binにあり、パスは通っていなかった。
  • passenger.loadには以下を記述
LoadModule passenger_module /var/lib/gems/1.8/gems/passenger-3.0.11/ext/apache2/mod_passenger.so
  • passenger.confには以下を記述
 PassengerRoot /var/lib/gems/1.8/gems/passenger-3.0.11
 PassengerRuby /usr/bin/ruby1.8
 RailsBaseURI /redmine

あとはガシガシapt-getしたりgem installしたりすればOKでした。

WindowsServer管理者への道はdebian testing上のWordpressにWindows Live Writerで投稿しているのですが、気がついたらきちんと投稿できず、なにやらタグがおかしくなってしまうようになっていました。

タグだけなら、投稿後にソース表示画面にして、ソースをコピペすることで逃げられるのでそれですませていたのですが(問題先送り)、複数の画像を貼り付けるようになってくると、変数の展開すらなされていないので、簡単に逃げることもできず、非常に困っていました。

結局原因はlibxml2のバグ…ということらしく、こちらのWordpress用のプラグインを有効化することで回避できるようになりました。よかった。

今日は時間があるので会社の勉強会のための資料を作成しよう・・・と思ってデータ取りのために自宅のサーバーにログインしたうえでrootになろうとしたら・・・なれませんでした(泣。

wで確認したらtestというアカウントで89.35.82.169からsshでアクセスが。完全にやられてしまいました。数日前にデータ取りのために仮のアカウントを作成していたのですが以下の点で迂闊でした。

  • アカウント名が安易過ぎた
  • パスワードが安易過ぎた
  • sshの接続元を絞っていなかった
  • sshにパスワード認証を使っていた

もう再インストールすることは覚悟したのですが、データ復旧なり、現在どうなっているかを知りたいのでsudo passwd rootを実行してみたところrootのパスワードの書き換えには成功。

以下の方針で復旧します。

  • USBHDDをつないで現在のシステムから必要な部分のバックアップを取得

まずはUSBHDDの接続

  • 接続。自動認識される。
  • dmesgにて/dev/sdaとして認識されたことを確認
  • fdisk /dev/sdaでパーティション作成
  • mke2fs -j /dev/sda1でext3のファイルシステムを作成
  • mkdir /mnt/usbhdd; mount -t ext3 /dev/sda1 /mnt/usbhddでマウント

必要なものをバックアップ

  • /etc/init.d/mysql stop
  • /etc/init.d/apache2 stop
  • cp -aux 必要なもの /mnt/usbhdd

新規インストール〜リストア

  • netinst CDブート
  • インストール
  • 必要なパッケージのインストール
  • 必要なデータ、設定ファイル等のリストア

というわけで、復旧いたしました。数日間繋がらなくなっていたのはこれが原因です。

それにしても、設定ファイルとか書き戻してあげれば簡単に復旧できちゃうんだから、UNIX系OSはすごいよなぁ。Windowsとは大違いだよなぁ・・・。

sargeまでは何も意識しなくても問題なかったのですが、etchにあげてからutf-8が標準になった関係でemacsで日本語入力ができてませんでした。emacs21 + mule-ucsで設定をがんばっていたんだけれども、どうにもうまくいかないので、あきらめてemacs22を導入したら何も設定しなくてもさくっと日本語入力できました。emacs22自体はtestingなので、sources.listの記述を変更する程度ですね。

これで快適になるわぁ。

サーバー移動前からちょくちょくなのですが、なぜか嫁に提供しているcourier-imapへの接続が微妙にできなくなります。Loginまではできているのに、なぜか接続が完了しない状態。courier-imapだけの再起動では現象は治らないけれども、サーバー全体をリブートするとしばらくはまた使えるようになる…。このような不可解な現象が起きております。

サーバーを取り替えたら治るかと思ったのですが、治らないので、何か根本的におかしいようです。というわけで、もうちょっと深くみてみようかとおもって、まずはwiresharkでパケットキャプチャを実施。

結果、正常に接続できない場合はクライアントからの「0005 STATUS “INBOX” (MESSAGES UNSEEN UIDNEXT)」という要求に対して、imapサーバーが答えを返していないことが原因であることが判明。(おかしい場合には1行目で止まってしまい下2行がない)

0005 STATUS "INBOX" (MESSAGES UNSEEN UIDNEXT)
* STATUS "INBOX" (MESSAGES 122 UIDNEXT 196 UNSEEN 30)
0005 OK STATUS Completed.

とりあえず間違いなく、imapサーバー側の問題なわけだけれども。何が原因だかとなると・・・。どうやって追ったらいいんだろうか。ちょっとこれは本気で追ってみたい。