]]>
来年から忙しくなりそうですし、いろいろ保守に割く時間を別なところにまわしたいと思っています。
しかし、レンタルサーバを借りるとなると、共用なので、負荷のかかるような自作スクリプトをcronで動かしたりできなくなると、ちょっと不便。
ある組み合わせの最適化を定期実行させているのですが、ちょっとその処理が重い。
激安レンタルサーバのxreaの姉妹サービス、coreserverを試用しているのですが、そのスクリプトをまわすと、負荷制限に引っかかってしまいます。
このcoreserver,月５００円で、１５GBのスペースをもらうことができ、cronやMySQL,PostgleSQLにも対応しています。データベースも無制限に作れます。
さくらやhetemlなど、大手では、1500円で3GBがいいところ。cronも対応してたり、していなかったり。
予算的にもここにしたいと思っている。
自宅サーバを残しておいて、台数を現在の３台から１台にすべて集約してしまい、とりあえず、負荷のかかるプログラムは、すべて自宅サーバから行うようにするのがいいかも。
自宅サーバの現在のドメインをレンタルサーバに移し、自宅サーバは他に持っているドメインに置き換えるなどしようかな。
]]>
カーネルが、2.6.22から2.6.23へあがったのですが、 /sys/class/rtc/rtc0/wakealarm が、なくなり、元の/proc/acpi/alarmに戻っていました・・・・
一体これはどうしたんでしょうか？使い勝手が悪くなって、元に戻したんでしょうか・・・
]]>
/sys/class/rtc/rtc0/wakealarm
を使うようになりました。
で、従来まで"2007-09-23 22:20:00"のようなフォーマットだったのですが、1970年からの秒数(エポック秒）を入力してあげなければならなくなりました。
それまで、うまく動かなかったり、2回日付を入力しなければならなかったりしたのですが、この新しいカーネルになってから、すんなりWAKEUPするようになりました。
MythTVでACPIWakeupを /proc/acpi/alarm で行なっていたので、mythtv側の設定を変更せずに、スクリプトだけを、変更することにしました。
#!/bin/sh
SECS=`date -d "$1" "+%s" -u`
echo $1 > /myth.wakeup.time
echo $SECS > /myth.wakeup.secs
if [ -e /sys/class/rtc/rtc0/wakealarm ]; then
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo $SECS > /sys/class/rtc/rtc0/wakealarm
fi
if [ -e /proc/acpi/alarm ]; then
echo $DATE > /proc/acpi/alarm
fi
]]>
中の液晶の内部のプラスチック部品を少し折ってしまいましたが、支障がない範囲でしたので無事です。
バックライトを組み入れるのが一番大変ですね。ここでプラスチックを折らずにできるのか？という気がします。もっと、スポット！って抜けるように作ってくれるとありがたいですねー。
中のガラス材とバックライトがきちんと接していないと、下だけが明るくなってしまったり、また、白い反射材がずれているとムラの原因になります。何度か電源を入れて調整しました。
で、結果ですが、ムラもなく、かなり明るく、画面がシャープになりました。
あと、ヘッドホン端子が壊れてしまって、内部のスピーカが機能しなくなっていたので、ヘッドホン端子も根元の半田も取れてしまっているし、パターンからはがれているし。なので、ジャンパ線で、内部スピーカとヘッドホンの切り替えスイッチの部分を、半田付けしてショートさせました。
これでスピーカは機能するようになりましたが、ヘッドホンが使えないので、USBのヘッドホン出力を買う予定です。
物を修理すると、達成感があっていいですね。しばらく使えるようになったので、大事にしたいと思います。]]>
< ? php echo -2861207174 ^ 493813264; ? >この値が、1209765738ならOK、-1653670384 だとバグありです。 内部で使用されているunsigned int の演算に問題があるようです。 このOpnePNE付属のPEER Crypt/Blowfish関数は、システムのPHPでMCrypt拡張モジュールが使える状態では、MCryptを使用しています。（新旧のOpenPNEともに） 使えない環境では、付属のライブラリで暗号化しています。 なので、既にMCRyptモジュールが使えるようになっている環境では、新旧ともにMCryptを使うはずなので、問題にならなかったかと思います。 あと、バグなしのBlowfishで、なおかつMCryptが導入されていない環境から、 MCryptがある環境へ移行する際も、文字化けしてしまいました。 その場合は、 define('CRYPT_BLOWFISH_NOMCRYPT', true); をコンフィグに記述してやると新しいOpenPNEではMCryptを使用しない設定にできます。 これによってCrypt/Blowfishを使うので文字化けしません。 とりあえず、メールアドレス文字化け問題が起きる条件を書いてみますと、 移行元 移行先 １ (MCryptなし）旧バグありCrypt/Blowfish （MCryptなし）新バグなしCrypt/Blowfish ２ (MCryptなし）旧バグありCrypt/Blowfish MCrypt拡張モジュールあり ３ MCrypt拡張なし（新OpenPNE状態で） MCrypt拡張モジュールあり 移行ツールを作りましたのでぜひご利用ください。 （データベースを更新するため、mysqldumpやphpMyAdminでバックアップを作ってください） OpenPNE2.6.2でのみ確認済みです。 これらは、文字化けが発生している状態の新バージョンのOpenPNEで実行してください。 １．の条件用 convert_blowfish.phpをpublic_html以下に置く そして、public_htmlに移動して、コマンドで、/usr/bin/php convert_blowfish.php と実行。 2．の条件用 convert_blowfish_NOEXT.phpをpublic_html以下に置く。 BlowfishOldNOEXT.php OPENPNE_DIRのlib/include/Crypt/以下に public_htmlに移動して、/usr/bin/php convert_blowfish_NOEXT.php を実行。 ３．の条件用 convert_blowfish_mcrypt.phpをpublic_html以下に置く。 BlowfishNOEXT.php OPENPNE_DIRのlib/include/Crypt/以下に public_htmlに移動して、/usr/bin/php convert_blowfish_mcrypt.php を実行。 何度もいいますが、データベースのバックアップを取ってください。 それか、別ディレクトリ、別データベースで動かして、その環境で移行してから、確認して元の方へデータベースをそのまま移行するのが良い手だと思います。 本当は、こういう移行ツールを本家で入れておいてくれたら良いと思うのだけど。 なんだか、OpenPNEはドキュメントが足りないと思う。 ]]>