らくの日記

元同僚と、元同僚の元同僚と表丹沢日帰り登山へ。
　
8:30 大倉バス停スタート
9:50 二俣
12:30 鍋割山
13:40 小丸
15:15 二俣
16:40 大倉バス停ゴール
　
天気にも恵まれ、気持ち良く歩けた。
奥多摩の山と比べてとにかく景色が良い。
ブナの森を歩き、山頂からは海も見える。
ゴールデンウィークだが思っていたより空いていた。
また行きたいな～

メールの検索環境が必要であれば、.forwardを設定してGmailにコピーを送るのが手っ取り早い。とは言っても、既に受信した過去メールが沢山あったり、お仕事のメールなどをフリーのWebmailに転送するのに抵抗感があったりするとその方法は使えない。
と、言う事で、自分は昔ながらのnamazuを使ってる。しかし、etchに切り替えたら以下のエラーでインデックスが作成できなくなってしまった。（etchの障害は聞き飽きた？）
　
*** glibc detected *** free(): invalid pointer: 0x00002b3feeb84b33 ***
　
Google様に聞いてみると、etch環境でワカチ処理にkakasiを使っていると発生するらしい。（同様の問題に苦労している人は結構いた。原因はglibcのバグ？）
要するにkakasiを使わなければ良いので、選択肢はchasenもしくはmecabになる。chasenのワカチは細切れで好みではない。残る選択肢であるmecabを使用する事に。さっそくインストール
aptitude install mecab libmecab-dev
/etc/mknmzrcを修正。
$MECAB = “/usr/bin/mecab -Owakati -b 8192”;
$WAKATI　€ = $MECAB;
その後、実行。。。恐ろしく遅い。
perlモジュールを使用していないのが原因のようだ。しかし、何故かdebianのパッケージにmecab-perlが存在しない。不本意だがソースからコンパイル。
http://mecab.sourceforge.net/ からmecab-perl0.93(etchのmecabが0.93なので)をダウンロード。
tar zxvf mecab-perl-0.93.tar.gz
cd mecab-perl-0.93
perl Makefile.PL
make
make install
/etc/mknmzrcを修正
$WAKATI = “module_mecab”;
無事、高速で動作。

世間様は大型連休だが、自分の職場は暦通り。さらに土曜である本日も出勤。とは言っても半ドンだけど。

コツコツと応募していたリニアの試乗。
当選することなく、試乗会終了。
実用化の目処がたったのは嬉しいけど、試験段階に試乗できなかったのは残念。
　
「超電導リニア試乗会の終了について」
https://linear.jr-central.co.jp/linear.nsf/ordertop
　
「リニア中央新幹線「２０２５年に開業」　ＪＲ東海社長」
http://news.goo.ne.jp/article/asahi/business/K2007042602750.html

仕事を終え、自転車で床屋へ行こうと思ったら寒かったので車に変更。変な気候だね。

次から次へ沸いてくる調整業務。
苦手だ。
　
そう言えば、日記に仕事のカテゴリーを作っていなかった。本日作成。

無事体調も回復して元気にお仕事。
もうすぐ４月も終わる。
１年の３分の１が終わる。
つい先日お正月だったよね？

昨日ゆっくり休んだはずなのだが。。。
早めに寝よう。

ゴールデンウィークに丹沢日帰り登山をする事に。先日神保町で購入した地図でコースを確認。キツイ感じ。まあ、ゆっくり登れば何とかなるかな。どちらかと言えばもゴールデンウィークの混雑が心配。
　
サーバのバージョンアップも一段落。久しぶりにのんびりした週末。外出は犬の散歩２回と夕方の選挙だけ。丹沢大丈夫か？

ぎるの腹水を抜いた。
今回は1.2リットル
　
寒暖の差が激しいと辛いみたい。

etchに切り替えてからメール送信できなくなったとの連絡有り。今まで通り送信できているユーザも居たのですっかり安心してしまっていたが、調べるとpop-before-smtpの初期設定に問題がある事が判明。
　
courierから使用する場合、/etc/pop-before-smtp/pop-before-smtp.conf の以下のコメントを外せば良いのだが、ここに落とし穴が。。。
　
# For Courier-POP3 and Courier-IMAP:
$pat = ‘^[LOGTIME] (?:\[|\S+ )(?:pop3|imap|couriertcp)(?:d|d-ssl|login)\]?: ‘ .　€　€’LOGIN, user=\S+, ip=\[[:f]*(\d+\.\d+\.\d+\.\d+)\]’;
$out_pat = ‘^[LOGTIME] (?:\[|\S+ )(?:pop3|imap|couriertcp)(?:d|d-ssl|login)\]?: ‘ .　€'(?:LOGOUT|DISCONNECTED), user=\S+, ip=\[[:f]*(\d+\.\d+\.\d+\.\d+)\]’;
　
この状態でpop3認証させても、/var/lib/pop-before-smtp/hosts.db は更新されない。で、syslogを確認すると、pop3loginではなくcourierpop3loginと、なっていた。これじゃ駄目じゃん。。。と、言う事でさっそく修正。
　
# For Courier-POP3 and Courier-IMAP:
$pat = ‘^[LOGTIME] (?:\[|\S+ )(?:courierpop3|imap|couriertcp)(?:d|d-ssl|login)\]?: ‘ .　€’LOGIN, user=\S+, ip=\[[:f]*(\d+\.\d+\.\d+\.\d+)\]’;
$out_pat = ‘^[LOGTIME] (?:\[|\S+ )(?:courierpop3|imap|couriertcp)(?:d|d-ssl|login)\]?: ‘ .　€'(?:LOGOUT|DISCONNECTED), user=\S+, ip=\[[:f]*(\d+\.\d+\.\d+\.\d+)\]’;
　
これで/var/lib/pop-before-smtp/hosts.db は更新されるようになった。でも、まだ他にも落とし穴がありそうなので継続調査。
　
ちなみにpop3sで接続していたユーザはsyslogがcouriertcpdとなっていたので問題無しだった。

先日ショートさせてしまった電源をネット通販。本日到着。さっそく交換。。。しかし、電源は入ったが起動しない。調べていくとハードディスクも壊れたようだ。マザーボードとCPUとメモリが無事だっただけでもラッキーと考えよう。

雪のナッキーから、美人ちゃんにテーマをバトンタッチ。
　
あれ？
過去日記の写真が消えた。。。明日考えよう。

しかし、まだ固定IPを確保できていないので本番サーバの切り替えは先。
しばらくはニューファミリーも並存。

etchに切り替えたらJoomla!のphpshopでアイテムが表示されなくなってしまった。phpのソースを解析するとバグを発見。LEFT JOINしたいテーブルを最初に記述してしまっている。これでは正常に動作しない。さっそく修正したところ、無事動作。しかし、何故sargeの時には動作していたのだろう？　条件分岐でこの行は実行されていなかったのだろうか？？
　
修正箇所
administrator/components/com_phpshop/html/shop.browse.php
　
//2行削除
// $list　€ = “SELECT DISTINCT $fieldnames FROM #__pshop_product, #__pshop_category, #__pshop_product_category_xref,#__pshop_shopper_group “;
// $count　€ = “SELECT $count_name FROM #__pshop_product, #__pshop_category, #__pshop_product_category_xref,#__pshop_shopper_group “;
　
//2行追加
　€$list　€ = “SELECT DISTINCT $fieldnames FROM #__pshop_category, #__pshop_product_category_xref,#__pshop_shopper_group,#__pshop_product “;
　€$count　€ = “SELECT $count_name FROM #__pshop_category, #__pshop_product_category_xref,#__pshop_shopper_group,#__pshop_product “;

予想外の出来事
・本番サーバのHDDを差し替え、ケースを閉める際にDVD電源ケーブルをはさみショートさせてしまった。急遽、スタンバイサーバを本番サーバに切り替え稼動。時間を浪費しただけでなく、スタンバイサーバが無くなってしまった事により、後続の作業に暗い影が。。。

・mysqlのりストアが何故かエラーになってしまう。
ERROR 1071 (42000) at line 129: Specified key was too long; max key length is 1000 bytes
スタンバイサーバでは何の問題も無く出来ていたのだが、スタンバイサーバの状態確認が出来ない。。。
google様に聞いてみると、UTF8を使用するとバイト数が大きくなるためmysqlのキー長の上限に引っかかってしまうらしい。１０あるDBを一つずつ手作業で復元＆エラーが出たDBのSQLを確認し対策を施しながら復元する事６時間。

・マザーボードのNICが数時間で暴走する。ドライバかkernelの問題と思われるが原因が特定できない。とりあえず、状態確認をして暴走したら再起動するスクリプトを3分間隔で実行。

・Joomla!で使用しているphpshopのアイテムが表示されない。これも原因が特定できない。とりあえずソースの解析を始めたのだが苦戦。継続作業中。

と、ここまでは悪い事を書いたが、レスポンスは劇的に改善した。何とかこの状態で安定稼動に持って行きたい。

etchへの切り替えは１～２時間作業と思っていたのだが大苦戦。
利用者の皆様にご迷惑をお掛けして申し訳ありません。。。