FreeBSD の ports に asterisk 1.8.15.0 から 1.8.15.1 へのアップデートが到着していました。いつものように portupgrade で更新しておきました。
動作上、特に問題は見当たらないようです。
2012年8月31日金曜日
2012年8月29日水曜日
PHP 5.4.6 へアップグレード
FreeBSD の ports へ php 5.4.6 が到着していました。
いつものように extensions と一緒に portupgrade で更新しました。
先日復活させた pukiwiki や rep2 もちゃんと動作しているようです。
php の更新は何だかハラハラしてしまいます（笑）
いつものように extensions と一緒に portupgrade で更新しました。
先日復活させた pukiwiki や rep2 もちゃんと動作しているようです。
php の更新は何だかハラハラしてしまいます（笑）
2012年8月23日木曜日
FreeBSD 8.3 へアップグレード
以前から FreeBSD 8.2 から FreeBSD 8.3 へアップグレードしたいと思っていました。なかなか機会に恵まれず、延び延びとなっていました。
今日は一念発起して、このアップグレードを行ってみましました。
以下はいつものように、私の備忘録を兼ねての記述です。
手順などはいつも通りなのですが、cvsup の supfile を修正することから始めました。
これで csup (cvsup) を使ってソースファイルの入れ替えを行います。
ソースファイルが入れ替わったところで、いよいよビルドに取りかかります。
world と kernel を一気にビルドするときにはコマンドをアンパサンドを使って連結しておきます。
私のサーバー環境でのビルド時間は次の通りでした。
なおカーネル用の設定ファイル(MYKERNEL)は、FreeBSD 8.2 のものをそのまま流用しました。マイナーアップグレードなどで大きな違いはないと思ったためです。本当は新しい FreeBSD 8.3 の GENERIC から書き直す方がよいのですが。
world と kernel のビルドが完了したら、インストールです。
インストールが終了したら再起動させて動作確認をしてみます。
問題が無さそうでしたら /etc ディレクトリにある各種の設定ファイルを mergemaster を使って更新します。
/etc の設定ファイルの更新の前に必ずバックアップを録っておきましょう。
次に mergemaster を使っての設定ファイルの更新です。いつも次のコマンド・オプションを使って更新しておきます。更新のコツとしては、更新するかどうか？の問い合わせがあったときには、確信を持って新しい設定ファイルに置き換えてもよいもの意外は、更新拒否の「d」キーを選択して、古い設定ファイルを残すようにしましょう。これで mergemaster の後に FreeBSD のシステムが起動しなくなったり、変な動作や、ログイン出来ないなどの被害に遭う確率が下がるはずです。
# mergamaster Ui
mergemaster が終了したところで、再びマシンを再起動させて動作に問題がないか確認をします。
これでシステム部分の更新が終了しました。これで一応動作していますが、私は念のために各種の ports でインストールしたソフトウェアの更新も行っておきました。
せっかくのアップグレードした機会に、依存関係などが更新につぐ更新のために壊れかけているかもしない ports ソフトウェアも綺麗に再ビルドしておきました。
コマンドは困ったときの非常手段としても使用される（笑）あの portupgrade のコマンドです。
portupgrade でインストール済みの全ての ports ソフトウェアの強制再インストールを行いました。私の環境では概ね5時間ほどの時間が必要でした。
もちろん portupgrade が終了しましたら、システムの再起動を行います。
これで動作に問題がなけれな、アップグレードは終了となります。
今日は一念発起して、このアップグレードを行ってみましました。
以下はいつものように、私の備忘録を兼ねての記述です。
手順などはいつも通りなのですが、cvsup の supfile を修正することから始めました。
*default release=cvs tag=RELENG_8_3
これで csup (cvsup) を使ってソースファイルの入れ替えを行います。
# csup -g -L 2 standard-supfile
ソースファイルが入れ替わったところで、いよいよビルドに取りかかります。
# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=MYKERNEL
world と kernel を一気にビルドするときにはコマンドをアンパサンドを使って連結しておきます。
# make buildworld && make buildkernel KERNCONF=MYKERNEL
私のサーバー環境でのビルド時間は次の通りでした。
make buildworld の時間 1時間27分29秒
make buildkernel の時間 26分04秒
なおカーネル用の設定ファイル(MYKERNEL)は、FreeBSD 8.2 のものをそのまま流用しました。マイナーアップグレードなどで大きな違いはないと思ったためです。本当は新しい FreeBSD 8.3 の GENERIC から書き直す方がよいのですが。
world と kernel のビルドが完了したら、インストールです。
# make installkernel
# make installworld
インストールが終了したら再起動させて動作確認をしてみます。
# reboot
問題が無さそうでしたら /etc ディレクトリにある各種の設定ファイルを mergemaster を使って更新します。
/etc の設定ファイルの更新の前に必ずバックアップを録っておきましょう。
# cp -Rp /etc /etc_backup
次に mergemaster を使っての設定ファイルの更新です。いつも次のコマンド・オプションを使って更新しておきます。更新のコツとしては、更新するかどうか？の問い合わせがあったときには、確信を持って新しい設定ファイルに置き換えてもよいもの意外は、更新拒否の「d」キーを選択して、古い設定ファイルを残すようにしましょう。これで mergemaster の後に FreeBSD のシステムが起動しなくなったり、変な動作や、ログイン出来ないなどの被害に遭う確率が下がるはずです。
# mergamaster Ui
mergemaster が終了したところで、再びマシンを再起動させて動作に問題がないか確認をします。
# reboot
これでシステム部分の更新が終了しました。これで一応動作していますが、私は念のために各種の ports でインストールしたソフトウェアの更新も行っておきました。
せっかくのアップグレードした機会に、依存関係などが更新につぐ更新のために壊れかけているかもしない ports ソフトウェアも綺麗に再ビルドしておきました。
コマンドは困ったときの非常手段としても使用される（笑）あの portupgrade のコマンドです。
# portupgrade -af
portupgrade でインストール済みの全ての ports ソフトウェアの強制再インストールを行いました。私の環境では概ね5時間ほどの時間が必要でした。
もちろん portupgrade が終了しましたら、システムの再起動を行います。
# reboot
これで動作に問題がなけれな、アップグレードは終了となります。
2012年8月22日水曜日
pukiwiki の php5.4 対応へ
[ 注意 ] 2016-02-16
この記事の内容は古くなっています。
この記事にあるように pukiwiki 1.4.7 を改変して PHP5.4 〜 5.6 へ適用するのではなく、pukiwiki 1.5.0 へアップグレードすることをお奨めします。
この記事の内容は古くなっています。
この記事にあるように pukiwiki 1.4.7 を改変して PHP5.4 〜 5.6 へ適用するのではなく、pukiwiki 1.5.0 へアップグレードすることをお奨めします。
PukiWiki 1.5.0 へアップグレード
http://near-unix.blogspot.jp/2016/02/pukiwiki.html
以前サーバーの php を php5.3 から php5.4 へアップグレードしたところ、pukiwiki で作ったページが真っ白になってしまう症状になってしまいました。
ネット上を検索すると php の仕様変更によるものだそうです。しかし pukiwiki は長くメンテナンスが行われた形跡もなく、他の pukiwiki ユーザーは手動で pukiwiki のコードを修正して対応していることが判明しました。
私は、コードを修正するのも面倒くさいので、アップグレードした php をダウングレードして対応するという超ネガティブな方法を採りました。しかし FreeBSD なサーバーで毎日のようにある ports のアップグレードやアップデートに対応するには大変面倒になってきました。時々間違って php もアップグレードしてしまって、pukiwiki のページが真っ白になってしまうことが度々ありました。
そしてもう諦めて、pukiwiki で最低限必要なページだけはブラウザで保存をして、php5.3 から php5.4 へアップグレードしてしまいました。
しばらくブラウザで保管したページを使って日頃の仕事をこなしていましたが、さすがに無理が来たようで、何らかの対応を正式にしなければならない状況となってしまいました。
方法としては、ports にある php5.3 の ports の lang.php53 をインストールして、もう新しい php へ対応しない方法か、pukiwiki のコードを修正して php5.4 へ対応させるかの選択となってしまいました。
今回私が採った方法は pukiwiki のコードを修正する方法としました。ネット上でいくつかの対応策が紹介されることもあり、私にも対応できると判断したからです。
以下は実際に私が行った作業を備忘録として記述しておきます。
まず pukiwiki の公式サイトから utf-8 コードに対応したソースコードをダウンロードしてきました。
pukiwiki-1.4.7.notb_utf8.zip
ダウンロードしたソースコードを解凍した後、以下の URL の内容を参照しながらソースコードを修正してゆきました。当該ブロガー様、大切な情報ありがとうございます。
[PHP] PHP5.4でpukiwikiを動かす
http://digape.com/201205/php-php5-4%E3%81%A7pukiwiki%E3%82%92%E5%8B%95%E3%81%8B%E3%81%99/
martianの日記： PHP5.4 と PukiWiki
http://slashdot.jp/journal/548548/PHP5.4-%E3%81%A8-PukiWiki
具体的には次の通りです。
(1) lib/func.php
「hex2bin」をコメントアウトして削除しました。
// Inversion of bin2hex()
/* 以下コメントアウト
function hex2bin($hex_string)
{
// preg_match : Avoid warning : pack(): Type H: illegal hex digit ...
// (string) : Always treat as string (not int etc). See BugTrack2/31
return preg_match('/^[0-9a-f]+$/i', $hex_string) ?
pack('H*', (string)$hex_string) : $hex_string;
}
*/
(2) plugin/ls2.inc.php
s2プラグインの関数呼び出し時の参照渡しを修正しました。
array_walk($args, 'plugin_ls2_check_arg', & $params);
↓
array_walk($args, 'plugin_ls2_check_arg', $params);
(3)
lib/convert_html.php
lib/link.php
lib/init.php
new の返り値のキャストの変更しました。「& new」を「new」へ変更
以上を修正したものを、従来からある pukiwiki のディレクトリへ上書きインストールしました。
これで pukiwiki のヘルプなどが日本語表示となりましたが、肝心の本体の中身は英文などは表示されますが、日本語が表示されてしまい状況です。これは今まで EUC-JP コードで本文を記述しているためで、この EUC-JP コードを UTF-8 コードへ変換する必要があります。
FreeBSD ではユーザー領域のウェブサイトも apache で管理されている場合、ファイルは www ユーザーで管理されています。一般のユーザーではファイルの修正や上書きが出来ないことをに注意して作業が必要です。
私の場合、pukiwiki の記述データの入ったディレクトリの wiki を丸ごとダウンロードして作業用デスクトップパソコン (debian/squeezw) で EUC-JP から UTF-8 コードへファイルを変換して、元のサーバーに戻す方法としました。
データファイルを EUC-JP から UTF-8 コードへ変換するのは nkf を使用しました。
端末でデータの入った wiki ディレクトリへ入った後、次のコマンドで一括変換しました。
nkf -w --overwrite *.txt
この UTF-8 コードへ置き換えたファイルをアップロードして、ようやく pukiwiki は以前のように表示をするようになりました。
これで pukiwiki は何らかのエラーを吐きながらも動作している状況となりました。しかし今後のことを考えるとあたらしい wiki システムへ乗り換える必要があるように感じました。
2012年8月18日土曜日
asterisk 1.8.15.0 へアップグレード
前回 pkg-config のコンフリクト（衝突）でビルドが出来なかった asterisk 1.8.15.0 ですが、 pkg-config の置き換え方法が /usr/ports/UPDATING に記載があったので、これを適用して asterisk 1.8.15.0 のビルド／インストールに成功しました。
pkg-config から pkgconf への置き換え方法は次の通りでした。
この pkg-config から pkgconf への置き換えが終わった後、portupgrade -a で一気に関連する ports も含めてアップグレードをしました。
この画像は asterisk 1.8.15.0 の設定画面です。
pkg-config から pkgconf への置き換え方法は次の通りでした。
# cd /usr/ports
# portupgrade -fo devel/pkgconf pkg-config-\*
# rehash
この pkg-config から pkgconf への置き換えが終わった後、portupgrade -a で一気に関連する ports も含めてアップグレードをしました。
この画像は asterisk 1.8.15.0 の設定画面です。
2012年8月4日土曜日
apache 2.2.22_6 へアップデートとasterisk のアップグレード
久しぶりにウェブサーバの apache がアップデートとなりました。
いつものように portupgrade で更新しておきました。画像はビルドの設定画面です。
そして asterisk にもアップグレード(asterisk 1.8.15.0)が着ていましたが、こちらはpkgconfig のエラーでビルドが中止となってしまいました。
asterisk 1.8.15.0 が pkgconf-0.8.5 を要求しているのですが、従来からインストール済みの pkg-config-0.25_1 と衝突（コンフリクト）してしまっている様子です。とりあえず対策を考えるとして、今回は無理やりインストールを強行するのは止めておきました。
いつものように portupgrade で更新しておきました。画像はビルドの設定画面です。
そして asterisk にもアップグレード(asterisk 1.8.15.0)が着ていましたが、こちらはpkgconfig のエラーでビルドが中止となってしまいました。
asterisk 1.8.15.0 が pkgconf-0.8.5 を要求しているのですが、従来からインストール済みの pkg-config-0.25_1 と衝突（コンフリクト）してしまっている様子です。とりあえず対策を考えるとして、今回は無理やりインストールを強行するのは止めておきました。