我が家の Asterisk の意外な問題を発見しました（涙）。
事情があって大手銀行のコールセンターのフリーダイヤルへ NTT のひかり電話回線で電話をかけてみました。しかし呼び出し音が続くまま一向に接続しません。以前は他のフリーダイヤルへ電話した時には繋がりました。
なんとなく不安を感じて、ホームゲートウェイの PR-400NE に直接接続してあるアナログ電話からフリーダイヤルへ電話をかけてみました。するとすぐに繋がりました。いったいどうしたものでしょうか？
PR-400NE の内線設定で「IP端末（音声専用）」の設定にしてあったものを「IP端末（通常）」に設定をし直してみましたが、やはり呼び出し中のまま繋がりません。
アナログ電話で接続したときには、呼出音がなく、いきなり繋がる状態でした。
もしかして呼び出し音が聞こえない相手先では上手く動作しないものなのでしょうか？
ネット上を検索してみましたが、該当するような情報も見当たらず、ちょっと困ってしまいました。もう少し情報を収集して対応してみたいと思っています。
なお今回のフリーダイヤルでの用件はアナログ電話で済ませてしまいました。なんだかんだで念の為にアナログ電話機を接続しておくことは必要のようです。
2014年3月12日水曜日
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」として、認証方式を「通常のパスワード認証」に切り替えてアクセスしてみました。以前のようにアクセスすることができました。もちろんメールもちゃんと読むことができるようになりました。
登録:
投稿 (Atom)