我が家ではとりあえず問題なく動作しているようです。まだ連続して長期に運用していないので、問題点がこれから見つかる可能性はあります。
そして、これもいつものことですが、どこがどのように改良されたのかは全く不明です（笑）。
 |
| apache 2.2.27 のビルドオプションの様子です。 |
2014年3月28日金曜日
FreeBSD apache-2.2.27 へアップグレード
FreeBSD の ports へウェブサーバの apache 2.2 系のアップグレードが到着していました。apache 2.2.26 から apache 2.2.27 へのアップグレードです。いつものように portupgrade で更新しておきました。
我が家ではとりあえず問題なく動作しているようです。まだ連続して長期に運用していないので、問題点がこれから見つかる可能性はあります。
そして、これもいつものことですが、どこがどのように改良されたのかは全く不明です（笑）。
我が家ではとりあえず問題なく動作しているようです。まだ連続して長期に運用していないので、問題点がこれから見つかる可能性はあります。
そして、これもいつものことですが、どこがどのように改良されたのかは全く不明です（笑）。
2014年3月26日水曜日
Windows XP のサポート終了の警告
とうとう我が家の Windows XP マシンにも2014年4月8日のサポート終了の案内が表示されるようになりました。寿命の長かった Windows XP もいよいよ終焉を迎えるようです。このサポートが終了した後には、「終了しました」という案内が表示されるようになるのでしょうか。4月8日が何となく楽しみでもあります。
我が家ではしばらくは Windows XP を限定的に使用し続けてゆく予定です。できることならば、新しい Windows に乗り換えたいのですが、なかなかその余裕もありません。早く対応をしておきたいと思っています。
我が家ではしばらくは Windows XP を限定的に使用し続けてゆく予定です。できることならば、新しい Windows に乗り換えたいのですが、なかなかその余裕もありません。早く対応をしておきたいと思っています。
2014年3月22日土曜日
Thunderbird 24.4.0 へアップグレード
Windows 版のメールクライアント Thunderbird が 24.4.0 へアップグレードしていたので、近く Linux 版もアップグレードするものと期待していました。本日 Ubuntu 版の Thunderbird が 24.4.0 へアップグレードしていました。そこで Puppy Linux Precise-5.7.1 の Thunderbird もアップグレードさせておきました。
更新したファイルは以下の二つです。
更新したファイルは以下の二つです。
thunderbird_24.4.0+build1
thunderbird-locale-ja_24.4.0+build1
2014年3月20日木曜日
Iceweasel 28.0 へアップグレード
Ubuntu の Firefox 28.0 に引き続いて、Debian 用の Iceweasel の最新パッケージを提供している mozilla.debian.net にも最新のパッケージ（28.0）が到着しました。パッケージ・マネージャを使って更新をしておきました。以下のパッケージが更新されました。
Iceweasel 28.0 も とりあえず問題なく動作しています。
iceweasel-28.0-1~bpo70+1
iceweasel-l10n-ja-1:28.0-1~bpo70+1
xulrunner-28-28.0-1~bpo70+1
Iceweasel 28.0 も とりあえず問題なく動作しています。
Firefox 28.0 へアップグレード
Windows 版の Firefox が 28.0 へアップグレードしました。そこで近く Linux 版でもアップグレードがあるのではないかと期待していましたら ubuntu の Firefox が 28.0 へアップグレードしました。
このところ Firefox のアップグレード間隔が短いように感じます。しかしどこが改良されたのかは全く不明です（笑）。
Debian 向けの Iceweasel も 28.0 へアップグレードするのではないかと期待しています。なお Puppy Linux Precise-5.7.1 の Firefox も手動でアップグレードをこれから行う予定です。
このところ Firefox のアップグレード間隔が短いように感じます。しかしどこが改良されたのかは全く不明です（笑）。
Debian 向けの Iceweasel も 28.0 へアップグレードするのではないかと期待しています。なお Puppy Linux Precise-5.7.1 の Firefox も手動でアップグレードをこれから行う予定です。
2014年3月14日金曜日
Puppy Linux Precise-5.7.1 で KeePassX が動作不良
Puppy Linux Precise-5.7.1 の導入時から気になっていたのですが、パスワード・マネージャの KeePassX で自動入力を行うと特定のウェブサイトでログインに失敗してしまうことがありました。ユーザー名とパスワードをそれぞれメニューにあるコピーボタンを使って、コピー＆ペースト（以下コピペ）を行うと正常にログインできます。
同じバージョンの 0.4.3 をインストールしてある Puppy Linux Precise-5.5.0 や Puppy Linux Lucid-5.2.8 においては、自動入力で問題なくログインができます。もちろん同じマシン上での話ですし、他のマシンでも同様の症状が発生します。
そこで原因を探してみました。
とりあえずブラウザ（Firefox）ではなく、テキストエディタの上に KeePassX から自動入力をさせてみました。 するとどうでしょう。自動入力させた文字のうち、英数字は問題ありませんが、記号文字は入力されなかったり、文字化けをするようになっていることに気づきました。
ユーザー名にメールアドレスを使用するウェブサイトの場合、メールアドレスの途中にあるアットマーク「@」が「[」に文字化けしてしまうのです。その他、「_」が消失したりします。特に私の場合には、パスワードは KeePasX に備わっているパスワード・ジェネレータを使って、可能なかぎり記号も含めた乱数を設定するようにしています。そのためパスワード部分も文字化けや文字の消失が発生しているようです。 そのためウェブサイトのログインに失敗しているようです。
KeePassX の自動入力と手動でコピペ入力するのでは動作が異なっているようです。手動でコピペするときには、いわゆるシステムのコピペ機能を使って一気に文字を流し込んでいるようです。このコピペ機能を使用するときには問題ありません。
しかし自動入力のときには、ユーザー名やパスワードを一文字ずつタイプするように入力を行うようです。KeePassX の設定画面で、「詳細設定」の「自動入力の微調整」の項目で「キーストロークの遅延」が初期値 5 ミリ秒であったものを 100 ミリ秒などとぐっと遅くすると、文字入力が一文字ずつゆっくりと入力して行くのが目視できます。しかしゆっくりタイピングする状態にしても、記号文字の時にだけ文字化けや消失が発生するようです。
何かシステムのキーボードからの入力処理に割り込む部分に問題があるのでしょうか？
もしかして日本語キーボードと英語キーボードで違いがあるのか確認してみました。
すると英語キーボード（us）ではちゃんと自動入力ができました。しかし、その後再び日本語キーボード（jp106）へ戻しても正常に自動入力が行われます。どうやらこのキーボード処理へのデータの受け渡しのあたりに問題がありそうです。
（注：メニュー＞セットアップ＞QuickSetup パピーの初期設定でキーボードを設定し直しました。）
現在のところ、これ以上の対応は私には不可能のようです。Puppy Linux Precise-5.7.1 の時にだけ、正常に動作する「手動でコピペ」で対応したいと思います。
2014-03-17 追記
英語キーボード（us）の設定にしておくと、システムの再起動に係わらず 自動入力は正常に行われるようです。我が家には英語キーボードを取り付けてあるデスクトップ・パソコンがありますが、このパソコンでは快調に使用できています。
同じバージョンの 0.4.3 をインストールしてある Puppy Linux Precise-5.5.0 や Puppy Linux Lucid-5.2.8 においては、自動入力で問題なくログインができます。もちろん同じマシン上での話ですし、他のマシンでも同様の症状が発生します。
そこで原因を探してみました。
とりあえずブラウザ（Firefox）ではなく、テキストエディタの上に KeePassX から自動入力をさせてみました。 するとどうでしょう。自動入力させた文字のうち、英数字は問題ありませんが、記号文字は入力されなかったり、文字化けをするようになっていることに気づきました。
ユーザー名にメールアドレスを使用するウェブサイトの場合、メールアドレスの途中にあるアットマーク「@」が「[」に文字化けしてしまうのです。その他、「_」が消失したりします。特に私の場合には、パスワードは KeePasX に備わっているパスワード・ジェネレータを使って、可能なかぎり記号も含めた乱数を設定するようにしています。そのためパスワード部分も文字化けや文字の消失が発生しているようです。 そのためウェブサイトのログインに失敗しているようです。
KeePassX の自動入力と手動でコピペ入力するのでは動作が異なっているようです。手動でコピペするときには、いわゆるシステムのコピペ機能を使って一気に文字を流し込んでいるようです。このコピペ機能を使用するときには問題ありません。
しかし自動入力のときには、ユーザー名やパスワードを一文字ずつタイプするように入力を行うようです。KeePassX の設定画面で、「詳細設定」の「自動入力の微調整」の項目で「キーストロークの遅延」が初期値 5 ミリ秒であったものを 100 ミリ秒などとぐっと遅くすると、文字入力が一文字ずつゆっくりと入力して行くのが目視できます。しかしゆっくりタイピングする状態にしても、記号文字の時にだけ文字化けや消失が発生するようです。
何かシステムのキーボードからの入力処理に割り込む部分に問題があるのでしょうか？
もしかして日本語キーボードと英語キーボードで違いがあるのか確認してみました。
すると英語キーボード（us）ではちゃんと自動入力ができました。しかし、その後再び日本語キーボード（jp106）へ戻しても正常に自動入力が行われます。どうやらこのキーボード処理へのデータの受け渡しのあたりに問題がありそうです。
（注：メニュー＞セットアップ＞QuickSetup パピーの初期設定でキーボードを設定し直しました。）
現在のところ、これ以上の対応は私には不可能のようです。Puppy Linux Precise-5.7.1 の時にだけ、正常に動作する「手動でコピペ」で対応したいと思います。
2014-03-17 追記
英語キーボード（us）の設定にしておくと、システムの再起動に係わらず 自動入力は正常に行われるようです。我が家には英語キーボードを取り付けてあるデスクトップ・パソコンがありますが、このパソコンでは快調に使用できています。
2014年3月13日木曜日
FreeBSD samba 3.6.23 へアップグレード
FreeBSD の ports へ samba 3.6.22 から samba 3.6.23 へのアップグレードが到着していました。
いつものことながら、どのような改良が加えられたのかは不明です（苦笑）。
とりあえず動作確認をしていますが、我が家では一応ネットディスクとして問題なく動作していますが、GUI で設定をする SWAT において、Samba へ接続しているクライアントの表示がされないのが気になるところです。
いつものことながら、どのような改良が加えられたのかは不明です（苦笑）。
とりあえず動作確認をしていますが、我が家では一応ネットディスクとして問題なく動作していますが、GUI で設定をする SWAT において、Samba へ接続しているクライアントの表示がされないのが気になるところです。
 |
| samba 3.6.23 のビルド・オプションです。 |
Microsoft Outlook.com でメール消失
マイクロソフトのウェブサイトの Outlook.com が一周年を迎えたというメールを受信しました。メール・エイリアスなどの設定もできるということで早速いろいろと設定してみました。
ここで思いがけないことを発見しました。
なんと！ 保存してあった hotmail 初期のメールが消失しているのです。表題だけは表示されるのですが、本文が失われているのです。いったいどうしたものなのでしょうか？
私の場合、2003年12月15日の開設日に受信したメールから2004年6月16日までの差出人が 「Hotmail スタッフ」のものがすっぽりの消えてなくなっているのです。
なおメーラーの Thunderbird から imap で接続してメールの様子を観察すると、このメール部分は表題も含めてすっかり見えなくなっています。どうも消去されてしまったようです。
メール消失の原因は不明ですが、なんとも気味の悪い状況です。
おそらくこの失われたメールが復活することは無さそうです（涙）。
近年一部のクラウドサーバなどでもデータ消失事故がニュースになったこともあり、最終的にメールやデータを保管するのは所有者本人の手元で自己責任で保存するのが一番正しい姿のようです。
大手企業のサービスと言っても過信をしてはならないようです。
ここで思いがけないことを発見しました。
なんと！ 保存してあった hotmail 初期のメールが消失しているのです。表題だけは表示されるのですが、本文が失われているのです。いったいどうしたものなのでしょうか？
私の場合、2003年12月15日の開設日に受信したメールから2004年6月16日までの差出人が 「Hotmail スタッフ」のものがすっぽりの消えてなくなっているのです。
なおメーラーの Thunderbird から imap で接続してメールの様子を観察すると、このメール部分は表題も含めてすっかり見えなくなっています。どうも消去されてしまったようです。
メール消失の原因は不明ですが、なんとも気味の悪い状況です。
おそらくこの失われたメールが復活することは無さそうです（涙）。
近年一部のクラウドサーバなどでもデータ消失事故がニュースになったこともあり、最終的にメールやデータを保管するのは所有者本人の手元で自己責任で保存するのが一番正しい姿のようです。
大手企業のサービスと言っても過信をしてはならないようです。
2014年3月12日水曜日
asterisk 1.8.26.1 へアップグレード
今日は Asterisk の話題が続きます。
FreeBSD の ports へ asterisk 1.8.26.1 へのアップグレードが到着していました。いつものように Makefile.local を作って、PR-400NE 用のパッチ（RT-200NE パッチ）を自動適用させてビルドさせました。
このビルドでいつもと違いことがありました。それは gcc-4.7.3 を最初にインストールし始めたことです。どうも現在インストールされている gcc4.6 系ではビルド出来ないようです。
我が家の FreeBSD サーバにて45分ほどの時間をかけて gcc-4.7.3 をビルドしたのち、その後に asterisk 1.8.26.1 をビルドし始めました。
アップグレード完了後、簡単な通話テストを行いました。今日、発見したフリーダイヤルで呼び出し音だけが鳴り続ける現象についてはテストをしておりませんが、その他の簡単なテストでは問題ないようです。
FreeBSD の ports へ asterisk 1.8.26.1 へのアップグレードが到着していました。いつものように Makefile.local を作って、PR-400NE 用のパッチ（RT-200NE パッチ）を自動適用させてビルドさせました。
このビルドでいつもと違いことがありました。それは gcc-4.7.3 を最初にインストールし始めたことです。どうも現在インストールされている gcc4.6 系ではビルド出来ないようです。
我が家の FreeBSD サーバにて45分ほどの時間をかけて gcc-4.7.3 をビルドしたのち、その後に asterisk 1.8.26.1 をビルドし始めました。
アップグレード完了後、簡単な通話テストを行いました。今日、発見したフリーダイヤルで呼び出し音だけが鳴り続ける現象についてはテストをしておりませんが、その他の簡単なテストでは問題ないようです。
 |
| asterisk 1.8.26.1 のビルド・オプションです。 |
Asterisk 経由でフリーダイヤルに接続しない
我が家の Asterisk の意外な問題を発見しました（涙）。
事情があって大手銀行のコールセンターのフリーダイヤルへ NTT のひかり電話回線で電話をかけてみました。しかし呼び出し音が続くまま一向に接続しません。以前は他のフリーダイヤルへ電話した時には繋がりました。
なんとなく不安を感じて、ホームゲートウェイの PR-400NE に直接接続してあるアナログ電話からフリーダイヤルへ電話をかけてみました。するとすぐに繋がりました。いったいどうしたものでしょうか？
PR-400NE の内線設定で「IP端末（音声専用）」の設定にしてあったものを「IP端末（通常）」に設定をし直してみましたが、やはり呼び出し中のまま繋がりません。
アナログ電話で接続したときには、呼出音がなく、いきなり繋がる状態でした。
もしかして呼び出し音が聞こえない相手先では上手く動作しないものなのでしょうか？
ネット上を検索してみましたが、該当するような情報も見当たらず、ちょっと困ってしまいました。もう少し情報を収集して対応してみたいと思っています。
なお今回のフリーダイヤルでの用件はアナログ電話で済ませてしまいました。なんだかんだで念の為にアナログ電話機を接続しておくことは必要のようです。
事情があって大手銀行のコールセンターのフリーダイヤルへ NTT のひかり電話回線で電話をかけてみました。しかし呼び出し音が続くまま一向に接続しません。以前は他のフリーダイヤルへ電話した時には繋がりました。
なんとなく不安を感じて、ホームゲートウェイの PR-400NE に直接接続してあるアナログ電話からフリーダイヤルへ電話をかけてみました。するとすぐに繋がりました。いったいどうしたものでしょうか？
PR-400NE の内線設定で「IP端末（音声専用）」の設定にしてあったものを「IP端末（通常）」に設定をし直してみましたが、やはり呼び出し中のまま繋がりません。
アナログ電話で接続したときには、呼出音がなく、いきなり繋がる状態でした。
もしかして呼び出し音が聞こえない相手先では上手く動作しないものなのでしょうか？
ネット上を検索してみましたが、該当するような情報も見当たらず、ちょっと困ってしまいました。もう少し情報を収集して対応してみたいと思っています。
なお今回のフリーダイヤルでの用件はアナログ電話で済ませてしまいました。なんだかんだで念の為にアナログ電話機を接続しておくことは必要のようです。
2014年3月10日月曜日
FreeBSD の fstab を修正
FreeBSD 9 系となってデバイス名の変更が行われています。今までのデバイス名でもそのまま使えるように新しいデバイス名へリンクが張られていています。しかしトラブル回避のために新しいデバイス名で必要な登録や設定をすることが望ましいこととされています。
そこで早速ハードディスクの設定の変更を行ってみました。
/dev のディレクトリの中からハードディスクに関係する部分を抜き出してみました。
/etc/fstab は次のように設定していました。
それぞれ新しいデバイス名に変更しました。
再起動させて問題なく起動することを確認しました。
これで linux 風のデバイス名がゼロから始まるもの（ada0）となりました。
我が家の自宅サーバのハードディスクのデバイス名が ad6 でしたが、このハードウェアへ今まで使っていた FreeBSD サーバのハードディスクを移植したときにデバイス名が ad0 であったため起動しないという問題が発生していました。今後はこのようなデバイス名の問題が発生し難くなるものと思われます。
そこで早速ハードディスクの設定の変更を行ってみました。
/dev のディレクトリの中からハードディスクに関係する部分を抜き出してみました。
lrwxr-xr-x 1 root wheel 4 Mar 9 20:46 ad6@ -> ada0
lrwxr-xr-x 1 root wheel 6 Mar 9 20:46 ad6s1@ -> ada0s1
lrwxr-xr-x 1 root wheel 7 Mar 9 20:46 ad6s1a@ -> ada0s1a
lrwxr-xr-x 1 root wheel 7 Mar 9 20:46 ad6s1b@ -> ada0s1b
lrwxr-xr-x 1 root wheel 7 Mar 9 20:46 ad6s1d@ -> ada0s1d
lrwxr-xr-x 1 root wheel 7 Mar 9 20:46 ad6s1e@ -> ada0s1e
lrwxr-xr-x 1 root wheel 7 Mar 9 20:46 ad6s1f@ -> ada0s1f
crw-r----- 1 root operator 0x59 Mar 9 20:46 ada0
crw-r----- 1 root operator 0x5b Mar 9 20:46 ada0s1
crw-r----- 1 root operator 0x5d Mar 10 05:46 ada0s1a
crw-r----- 1 root operator 0x5f Mar 9 20:46 ada0s1b
crw-r----- 1 root operator 0x61 Mar 10 05:46 ada0s1d
crw-r----- 1 root operator 0x63 Mar 10 05:46 ada0s1e
crw-r----- 1 root operator 0x65 Mar 10 05:46 ada0s1f
/etc/fstab は次のように設定していました。
# Device Mountpoint FStype Options Dump Pass#
/dev/ad6s1b none swap sw 0 0
/dev/ad6s1a / ufs rw 1 1
/dev/ad6s1e /tmp ufs rw 2 2
/dev/ad6s1f /usr ufs rw 2 2
/dev/ad6s1d /var ufs rw 2 2
それぞれ新しいデバイス名に変更しました。
# Device Mountpoint FStype Options Dump Pass#
/dev/ada0s1b none swap sw 0 0
/dev/ada0s1a / ufs rw 1 1
/dev/ada0s1e /tmp ufs rw 2 2
/dev/ada0s1f /usr ufs rw 2 2
/dev/ada0s1d /var ufs rw 2 2
再起動させて問題なく起動することを確認しました。
これで linux 風のデバイス名がゼロから始まるもの（ada0）となりました。
我が家の自宅サーバのハードディスクのデバイス名が ad6 でしたが、このハードウェアへ今まで使っていた FreeBSD サーバのハードディスクを移植したときにデバイス名が ad0 であったため起動しないという問題が発生していました。今後はこのようなデバイス名の問題が発生し難くなるものと思われます。
FreeBSD で pam トラブル
FreeBSD 8.4 から FreeBSD 9.2 へアップグレードした自宅サーバですが、いろいろとトラブルが発生しています。
今回紹介するのは、おそらく FreeBSD 8.4 のときにも発生したトラブルのようですが、今回のアップグレードでサーバへモニターを接続したときに発見した pam のトラブルです。
モニター上には以下のようなメッセージが大量に発生していました。
このエラーメッセージを読む限り /usr/lib/pam_skey.so が見当たらないということのようでした。
確かに pam_skey.so が存在していないようです。どうしたものなのか pam のマニュアルやネット上の情報などを調査してみましたが、原因がよく解りません。
原因がよく解らなかったのですが、pam_skey.so というモジュールは、どうもかなり以前に廃止になっていたようです。pam_skey.so のキーワードが含まれる情報は、ネット上に2000年代前半までのものしか見当たりませんでした。
そこでこの pam_skey.so のモジュールを指定している設定がどこにあるかを探してみました。すると /etc/pam.conf に記述がありました。
/etc/pam.conf の中には私自身が編集した箇所があり、そこには 2004-08-14 のように編集を行った日付が入っていました。どうも10年近く前に編集したファイルのようです。その後 編集はないようです。
さらに pam について調べると、現在はこの /etc/pam.conf で動作の設定は有効ですが、/etc/pam.d のディレクトリの配下に置かれた各ソフトウェアごとの設定ファイルへ移行していました。結局古い設定ファイルのまま pam を使用していることに問題があったようです。
結局 /etc/pam.conf を削除したところ、上記のエラー表示もなくなりました。またログインや ftpd, pop3, imap の動作も問題ないようでした。
かなり古い時期から FreeBSD サーバを繰り返してアップグレードしながら使用していると、このような古い設定ファイルで異常な動作を引き起こしてしまうようで注意が必要のようです。
今回紹介するのは、おそらく FreeBSD 8.4 のときにも発生したトラブルのようですが、今回のアップグレードでサーバへモニターを接続したときに発見した pam のトラブルです。
モニター上には以下のようなメッセージが大量に発生していました。
**** in openpam_dynamic(): /usr/lib/no pam_skey.so: No such file or directory
**** in openpam_load_module(): no pam_skey.so found
このエラーメッセージを読む限り /usr/lib/pam_skey.so が見当たらないということのようでした。
確かに pam_skey.so が存在していないようです。どうしたものなのか pam のマニュアルやネット上の情報などを調査してみましたが、原因がよく解りません。
原因がよく解らなかったのですが、pam_skey.so というモジュールは、どうもかなり以前に廃止になっていたようです。pam_skey.so のキーワードが含まれる情報は、ネット上に2000年代前半までのものしか見当たりませんでした。
そこでこの pam_skey.so のモジュールを指定している設定がどこにあるかを探してみました。すると /etc/pam.conf に記述がありました。
/etc/pam.conf の中には私自身が編集した箇所があり、そこには 2004-08-14 のように編集を行った日付が入っていました。どうも10年近く前に編集したファイルのようです。その後 編集はないようです。
さらに pam について調べると、現在はこの /etc/pam.conf で動作の設定は有効ですが、/etc/pam.d のディレクトリの配下に置かれた各ソフトウェアごとの設定ファイルへ移行していました。結局古い設定ファイルのまま pam を使用していることに問題があったようです。
結局 /etc/pam.conf を削除したところ、上記のエラー表示もなくなりました。またログインや ftpd, pop3, imap の動作も問題ないようでした。
かなり古い時期から FreeBSD サーバを繰り返してアップグレードしながら使用していると、このような古い設定ファイルで異常な動作を引き起こしてしまうようで注意が必要のようです。
2014年3月9日日曜日
FreeBSD 8.4 から 9.2 へアップグレード
ようやく FreeBSD 8.4 から FreeBSD 9.2 へメジャー・アップグレードしました。
先日の Subversion によるソースコードの取得が完了した後、kernel と world のビルドを開始しました。なお kernel はビルドオプション（/usr/src/sys/i386/conf/GENERIC）を見なおして MYKERNEL の名前で設定しています。
ビルド時間は、Pentium4(prescott,3GHz)のマシンで、buildworld が3時間40分程度でした。buildkernel は40分ほどで終了しました。
出来上がったカーネルをインストールしました。
案内にあるように /usr/src/UPDATING を確認してみました。
どうも必要なユーザーが不足しているようです。「mergemaster -p」のコマンドによってユーザーを追加してくださいということでした。そこで早速 mergemaster を実行してみました。
なお mergmaster のコマンドを実行する前には必ず /etc のファイルをすべて保存しておいてください。/etc のディレクトリの中にある設定ファイルを直接書き換えてしまうからです。
といった感じで現在のファイルと FreeBSD9.2 の標準ファイルの比較を行なってくれます。ここで内容をよく確認した後、「q」キーを押してビューアモードから抜けます。
すると設問が表示されますので「m」を選択します。すると現在のファイル（左側）と FreeBSD9.2 の標準ファイル（右側）の異なっている部分を左右に並べて表示してくれます。ここで左右を選択しながら新しいファイルへ組み立てて行きます。入れ替える部分は右側の FreeBSD9.2 の標準ファイルを「r」キーを押して選択します。そして FreeBSD9.2 の標準ファイルで追加となるものの場合、左側が空白となっているのでそのまま右側を選択する「r」キーを押します。そして現在のファイルに設定のあるものは左側に表示され右側が空白となっています。このときは左側を選択する「l」キーを押します。順次繰り返すと自動的に終了します。これで現在のファイルに不足している FreeBSD9.2 の標準ファイルの内容が追加されたはずです。念の為に「v」キーを押して変更後のファイルの確認を行います。そして変更したファイルをインストールするために「i」キーを押します。これで /etc/group のファイルのマージ（合わせる）作業が終了します。
引き続き /etc/master.passed のマージ作業が開始されます。これも同様に作業を終了します。
マージ作業が終了したらパスワードのファイルの再ビルドを促されますので「y」キーで実行させ、マージ作業を終了します。
これでようやくワールドのインストールが可能になりました。
ワールドのインストールが無事完了しましたら、そのまま /etc のディレクトリにある設定ファイル全体のマージ（合併）作業を行います。比較して問題のないものは自動的に処理してくれるオプションを付けてマージ作業を行いました。
自動的に処理できないファイルは問い合わせがあります。基本的には自分で何か設定を変更したものはそのまま残す「d」キーを押し、そして設定したことのないファイルは新しい FreeBSD9.2 の標準ファイルへ置き換えてしまう「i」キーを押します。これで大抵の場合は、問題ありません。
ただし上記の group と master.passwd はマージ作業「m」を行うか、心配であれば「d」キーで現在のファイルを保存するようにしましょう。決して「i」を押して新しいファイルに置き換えないように注意してください。
全部のファイルの設定が終了するとテンポラリファイルを消去するかなどの設問が三回程度表示されると思いますが、すべて「y」キーで応えて終了します。
以上でアップグレード作業が終了です。再起動させて無事起動できれば、インストール済みのアプリケーション・ソフトウェアを再ビルドの作業となります。執筆時点では、再ビルド中です。すべてのアプリケーション・ソフトウェアの更新するには次のコマンドで実施しました。なお私は、portupgrade 派です。
なお私の場合、再起動させたところ、起動途中で停止してしまいました（涙）。
カーネルのビルドオプションに設定間違いがあり、なんとハードディスクを読み込むことが出来なくなっていました。古い FreeBSD 8.4 のカーネルで再起動させて、とりあえず GENERIC の標準設定でカーネルを再ビルドした上で再起動させたところ、無事起動に成功しました。このマシンは自宅サーバで named や dhcpd などの重要な機能も受け持っていただけに非常に焦りました。無事起動できてホッとしています。
先日の Subversion によるソースコードの取得が完了した後、kernel と world のビルドを開始しました。なお kernel はビルドオプション（/usr/src/sys/i386/conf/GENERIC）を見なおして MYKERNEL の名前で設定しています。
# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=MYKERNEL
ビルド時間は、Pentium4(prescott,3GHz)のマシンで、buildworld が3時間40分程度でした。buildkernel は40分ほどで終了しました。
出来上がったカーネルをインストールしました。
# make installkernel KERNCONF=MYKERNEL次にワールドをインストールしようとしました。しかしエラーが発生してしまいました。
# make installworld
ERROR: Required auditdistd user is missing,see /usr/src/UPDATING.
*** Error code 1
案内にあるように /usr/src/UPDATING を確認してみました。
20121218:
With the addition of auditdistd(8), a new auditdistd user is now depended on during installworld. "mergemaster -p" can be used to add the user prior to installworld, as documented in the handbook.
どうも必要なユーザーが不足しているようです。「mergemaster -p」のコマンドによってユーザーを追加してくださいということでした。そこで早速 mergemaster を実行してみました。
なお mergmaster のコマンドを実行する前には必ず /etc のファイルをすべて保存しておいてください。/etc のディレクトリの中にある設定ファイルを直接書き換えてしまうからです。
# cp -Rp /etc /etc.backup
# mergemaster -p
-# $FreeBSD: src/etc/group,v 1.31 2004/06/23 01:32:28 mlaier Exp $
+# $FreeBSD: releng/9.2/etc/group 218046 2011-01-28 22:28:12Z pjd $
#
wheel:*:0:root
daemon:*:1:
といった感じで現在のファイルと FreeBSD9.2 の標準ファイルの比較を行なってくれます。ここで内容をよく確認した後、「q」キーを押してビューアモードから抜けます。
すると設問が表示されますので「m」を選択します。すると現在のファイル（左側）と FreeBSD9.2 の標準ファイル（右側）の異なっている部分を左右に並べて表示してくれます。ここで左右を選択しながら新しいファイルへ組み立てて行きます。入れ替える部分は右側の FreeBSD9.2 の標準ファイルを「r」キーを押して選択します。そして FreeBSD9.2 の標準ファイルで追加となるものの場合、左側が空白となっているのでそのまま右側を選択する「r」キーを押します。そして現在のファイルに設定のあるものは左側に表示され右側が空白となっています。このときは左側を選択する「l」キーを押します。順次繰り返すと自動的に終了します。これで現在のファイルに不足している FreeBSD9.2 の標準ファイルの内容が追加されたはずです。念の為に「v」キーを押して変更後のファイルの確認を行います。そして変更したファイルをインストールするために「i」キーを押します。これで /etc/group のファイルのマージ（合わせる）作業が終了します。
引き続き /etc/master.passed のマージ作業が開始されます。これも同様に作業を終了します。
マージ作業が終了したらパスワードのファイルの再ビルドを促されますので「y」キーで実行させ、マージ作業を終了します。
*** Comparison complete
*** /var/tmp/temproot is empty, deleting
*** You installed a new master.passwd file, so make sure that you run
'/usr/sbin/pwd_mkdb -p /etc/master.passwd'
to rebuild your password files
Would you like to run it now? y or n [n] y
Running /usr/sbin/pwd_mkdb -p /etc/master.passwd
これでようやくワールドのインストールが可能になりました。
# make installworld
ワールドのインストールが無事完了しましたら、そのまま /etc のディレクトリにある設定ファイル全体のマージ（合併）作業を行います。比較して問題のないものは自動的に処理してくれるオプションを付けてマージ作業を行いました。
# mergemaster -Ui
自動的に処理できないファイルは問い合わせがあります。基本的には自分で何か設定を変更したものはそのまま残す「d」キーを押し、そして設定したことのないファイルは新しい FreeBSD9.2 の標準ファイルへ置き換えてしまう「i」キーを押します。これで大抵の場合は、問題ありません。
ただし上記の group と master.passwd はマージ作業「m」を行うか、心配であれば「d」キーで現在のファイルを保存するようにしましょう。決して「i」を押して新しいファイルに置き換えないように注意してください。
全部のファイルの設定が終了するとテンポラリファイルを消去するかなどの設問が三回程度表示されると思いますが、すべて「y」キーで応えて終了します。
以上でアップグレード作業が終了です。再起動させて無事起動できれば、インストール済みのアプリケーション・ソフトウェアを再ビルドの作業となります。執筆時点では、再ビルド中です。すべてのアプリケーション・ソフトウェアの更新するには次のコマンドで実施しました。なお私は、portupgrade 派です。
# portupgrade -af
なお私の場合、再起動させたところ、起動途中で停止してしまいました（涙）。
カーネルのビルドオプションに設定間違いがあり、なんとハードディスクを読み込むことが出来なくなっていました。古い FreeBSD 8.4 のカーネルで再起動させて、とりあえず GENERIC の標準設定でカーネルを再ビルドした上で再起動させたところ、無事起動に成功しました。このマシンは自宅サーバで named や dhcpd などの重要な機能も受け持っていただけに非常に焦りました。無事起動できてホッとしています。
2014年3月8日土曜日
FreeBSD php5 のアップグレード（5.4.25 から 5.4.26 へ）
FreeBSD の ports へ php5 のアップグレード（5.4.25 から 5.4.26 へ）が到着していました。いつものように portupgrade で更新しました。
ただ今回の更新で気になったのが、ビルド中の以下の警告です！
内容としては --- 「DEFAULT_PHP_VER」が宣言されていますが、「DEFAULT_VERSIONS=php=5」を使うことを検討してください。--- ということであった。
php の定義ファイルの /usr/local/etc/php.ini の中を調査してみましたが、「DEFAULT_PHP_VER」という宣言文はありませんでした。
そこでネット上を検索してみると、これはビルドオプションのようで、/etc/make.conf で宣言（設定）しておくものだと知りました。
そこで /etc/make.conf へ上記の DEFAULT_VERSIONS=php=5 を追加したところ、警告が表示されなくなりました。
そしてついでに 2014-02-19 の当ブログの記事で紹介した「FreeBSD pkg_install の終了予告」の警告を停止させるオプションの設定もしておきました。
これも /etc/make.conf へ NO_WARNING_PKG_INSTALL_EOL=yes を追加するだけです。
この設定で pkg_install の終了予告も表示されなくなりました。
ただ今回の更新で気になったのが、ビルド中の以下の警告です！
/!\ WARNING /!\
DEFAULT_PHP_VER is defined, consider using DEFAULT_VERSIONS=php=5 instead
内容としては --- 「DEFAULT_PHP_VER」が宣言されていますが、「DEFAULT_VERSIONS=php=5」を使うことを検討してください。--- ということであった。
php の定義ファイルの /usr/local/etc/php.ini の中を調査してみましたが、「DEFAULT_PHP_VER」という宣言文はありませんでした。
そこでネット上を検索してみると、これはビルドオプションのようで、/etc/make.conf で宣言（設定）しておくものだと知りました。
そこで /etc/make.conf へ上記の DEFAULT_VERSIONS=php=5 を追加したところ、警告が表示されなくなりました。
そしてついでに 2014-02-19 の当ブログの記事で紹介した「FreeBSD pkg_install の終了予告」の警告を停止させるオプションの設定もしておきました。
これも /etc/make.conf へ NO_WARNING_PKG_INSTALL_EOL=yes を追加するだけです。
この設定で pkg_install の終了予告も表示されなくなりました。
2014年3月7日金曜日
FreeBSD で Subversion を使う
現在使用している FreeBSD のバージョンは 8.4 です。すでにバージョン 10.0 も登場している状況のため、そろそろバージョンを 9.2 （執筆時点の FreeBSD 9 の最新リリース）へ引き上げたいと思っていました。
そこで重い腰を上げて /usr/src のソースツリーの更新をすることとしました。今までどおり CVSup で更新しました。
メジャーアップグレードなのでカーネルのビルドオプションも新規に見なおさなければなりません。そこで /usr/src/sys/i386/conf へ移動して、ビルドオプションを設定する GENERIC の内容を見ようとしました。しかし、そこに GENERIC のファイルが見当たりません。どうしたことでしょうか（汗）。
何度も CVSup（csup コマンド使用）を繰り返しましたが変化がありません。そこで試しに現在の 8.4 を指定して CVSup を行なってみると、たしかに GENERIC のビルドオプション ファイルが存在しています。
それならばと言うことで、いっその事、バージョンを 10.0 へ引き上げてみることとしました。しかし結果は 9.2 の時と同様で、GENERIC のファイルが存在しません。
どうも CVSup による更新が終了してしまっているようです。以前から FreeBSD のリポジトリ（ソースコード類）が CVSup から Subversion に変更したというアナウンスがありましたが、とうとう現実として CVSup による更新が出来なくなったようです。
なお ports のツリーについては、portsnap コマンドを使用しているので問題はありませんでした。
そこでずっと使い続けてきた CVSup を離れて Subversion へ移行することとしました。私はほとんど単独で使用することがありませんでしたので、ここに備忘録として記述をすることとしました。
なお portsnapで subversion を使用しているのか、すでに subversion（執筆時点で subversion-1.8.8）はインストール済みでした。また HTTP プロトコルで必要な neon もインストール済みでした。
そこで /usr/src のカーネルのソースツリーを新規にダウンロードしてみることとしました。なお subversion の動作の特性から subversion によって新規にソースツリーを作り直さなければならないそうです。そこで現状のソースツリーをすべて削除すて新規に作ることとしました。
ネット上で情報を検索してみると、subversion が neon を見つけられないときに、このエラーが発生するようです。
そこで subversion のビルドオプションを確認してみました。やはり http や https プロトコルでの通信を行う設定となっていませんでした。この部分のオプション「SERF」を有効にして再ビルドしました。
再ビルドの結果、無事 /usr/src へカーネルのソースコードをダウンロードすることができました。なおダウンロードの開始前に FreeBSD のサーバのフィンガープリントの確認が行われました。「p」で常に認証するで次回以降の更新で再確認がなくなります。
なお subversion のコマンドを使用するときには、ソースコードが第三者による攻撃を受けないように https プロトコルが推奨されています。しかし上記のように subversion のビルドオプションの見直しでもエラーが発生する場合には、通信プロトコルを svn へ変更して試みてください。
現在ダウンロードしてあるカーネルのソースコードは最新版となっています。今後アップデートが行われた時には、次の二つの方法のいずれかで行うそうです。
そこで重い腰を上げて /usr/src のソースツリーの更新をすることとしました。今までどおり CVSup で更新しました。
メジャーアップグレードなのでカーネルのビルドオプションも新規に見なおさなければなりません。そこで /usr/src/sys/i386/conf へ移動して、ビルドオプションを設定する GENERIC の内容を見ようとしました。しかし、そこに GENERIC のファイルが見当たりません。どうしたことでしょうか（汗）。
何度も CVSup（csup コマンド使用）を繰り返しましたが変化がありません。そこで試しに現在の 8.4 を指定して CVSup を行なってみると、たしかに GENERIC のビルドオプション ファイルが存在しています。
それならばと言うことで、いっその事、バージョンを 10.0 へ引き上げてみることとしました。しかし結果は 9.2 の時と同様で、GENERIC のファイルが存在しません。
どうも CVSup による更新が終了してしまっているようです。以前から FreeBSD のリポジトリ（ソースコード類）が CVSup から Subversion に変更したというアナウンスがありましたが、とうとう現実として CVSup による更新が出来なくなったようです。
なお ports のツリーについては、portsnap コマンドを使用しているので問題はありませんでした。
そこでずっと使い続けてきた CVSup を離れて Subversion へ移行することとしました。私はほとんど単独で使用することがありませんでしたので、ここに備忘録として記述をすることとしました。
なお portsnapで subversion を使用しているのか、すでに subversion（執筆時点で subversion-1.8.8）はインストール済みでした。また HTTP プロトコルで必要な neon もインストール済みでした。
そこで /usr/src のカーネルのソースツリーを新規にダウンロードしてみることとしました。なお subversion の動作の特性から subversion によって新規にソースツリーを作り直さなければならないそうです。そこで現状のソースツリーをすべて削除すて新規に作ることとしました。
# rm -Rf /usr/src新しい /usr/src へ FreeBSD 9.2 のカーネルソースコードをダウンロードします。
# mkdir /usr/src
# svn checkout https://svn0.us-west.FreeBSD.org/base/releng/9.2 /usr/srcしかし動作してくれません。「URL スキームを認識できません」としてエラーが出てきます。
ネット上で情報を検索してみると、subversion が neon を見つけられないときに、このエラーが発生するようです。
そこで subversion のビルドオプションを確認してみました。やはり http や https プロトコルでの通信を行う設定となっていませんでした。この部分のオプション「SERF」を有効にして再ビルドしました。
# cd /usr/ports/devel/subversion
# make config
再ビルドの結果、無事 /usr/src へカーネルのソースコードをダウンロードすることができました。なおダウンロードの開始前に FreeBSD のサーバのフィンガープリントの確認が行われました。「p」で常に認証するで次回以降の更新で再確認がなくなります。
# svn checkout https://svn0.us-west.FreeBSD.org/base/releng/9.2 /usr/src
'https://svn0.us-west.freebsd.org:443' のサーバ証明書の認証中にエラーが発生しました:
- 証明書は信頼のおける機関が発行したものではありません。証明書を手動で認証
するためにフィンガープリントを用いてください!
証明書情報:
- ホスト名: svnmir.ysv.FreeBSD.org
- 有効範囲: Jul 29 22:01:21 2013 GMT から Dec 13 22:01:21 2040 GMT まで
- 発行者: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org)
- フィンガープリント: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
拒否しますか (R)、一時的に承認しますか (t)、常に承認しますか (p)?
なお subversion のコマンドを使用するときには、ソースコードが第三者による攻撃を受けないように https プロトコルが推奨されています。しかし上記のように subversion のビルドオプションの見直しでもエラーが発生する場合には、通信プロトコルを svn へ変更して試みてください。
# svn checkout svn://svn0.us-west.FreeBSD.org/base/releng/9.2 /usr/src
現在ダウンロードしてあるカーネルのソースコードは最新版となっています。今後アップデートが行われた時には、次の二つの方法のいずれかで行うそうです。
その１（標準）
# svn update /usr/src
その２（/usr/src のように Makefile に svn 更新の記述がある場合）
# cd /usr/src# make update SVN_UPDATE=yes
（その２の方法は、ソースツリーの中にある Makefile の中に subversion によるソースツリーの更新方法が記述されているために make コマンドで更新ができるそうです。）
こうして新しくダウンロードした FreeBSD 9.2 のカーネルのソースコードの中のビルドオプションのファイル /usr/src/sys/i386/conf/GENERIC を確認すると確かに存在しました。
これでようやくカーネルビルドが出来そうです。
今日はすでにこの subversion でのダウンロードだけで疲れてしまいましたので、明日にでもカーネルのビルドを開始したいと思っています。
参考URL
FreeBSD マニュアル -- A.5. Subversion を使う
2014年3月4日火曜日
FreeBSD courier-imap のアップデート
courier-imap の前回のアップデートで、バージョンが 1.15,2 になりました。すると自宅のメールサーバへ STARTTLS によるアクセスができなくなってしまいました。自宅サーバへのアクセスなので、通信の保護は特に必要としないことから、接続の保護は「なし」、認証方式は「平文のパスワード」として問題を一時的に回避していました。
もちろん問題解決のため courier-imap のビルドオプションなどの見直しも行いましたが、見直すような項目もなく、何の解決も出来ませんでした。
そして本日 FreeBSD の ports へ courier-imap-4.15_1,2 が到着していました。バージョンの番号からして、何かの問題対策であろうと思われました。courier-imap を再ビルドして、インストールすることとしました。
ビルドオプションを見ると「GNUTLS」という新しい項目が追加されていました。きっとこれが問題対策に違いないと思って、このオプションを有効にして再ビルド・インストールを行いました。
早速 Icedove や Thunderbird で自宅サーバへ接続して、接続の保護を「STARTTLS」として、認証方式を「通常のパスワード認証」に切り替えてアクセスしてみました。以前のようにアクセスすることができました。もちろんメールもちゃんと読むことができるようになりました。
もちろん問題解決のため courier-imap のビルドオプションなどの見直しも行いましたが、見直すような項目もなく、何の解決も出来ませんでした。
そして本日 FreeBSD の ports へ courier-imap-4.15_1,2 が到着していました。バージョンの番号からして、何かの問題対策であろうと思われました。courier-imap を再ビルドして、インストールすることとしました。
ビルドオプションを見ると「GNUTLS」という新しい項目が追加されていました。きっとこれが問題対策に違いないと思って、このオプションを有効にして再ビルド・インストールを行いました。
早速 Icedove や Thunderbird で自宅サーバへ接続して、接続の保護を「STARTTLS」として、認証方式を「通常のパスワード認証」に切り替えてアクセスしてみました。以前のようにアクセスすることができました。もちろんメールもちゃんと読むことができるようになりました。