URL変更のお知らせ

2018/12/20 4:29 雑多なトピック
はんかくさい日報のURLを https://www.basekernel.jp/cgi-bin/adiary/adiary.cgi/basekrnl/ 配下に変更しました。
旧URLからは、上記の新URL配下へ自動転送されます。

ブックマークやリンクされている場合は、お手数おかけしますが上記URLへの変更をお願いします。
尚、サブドメイン hankakusai.basekernel.co.jp は、 2019/07/15 に廃止します。

2019/02/13(水)perl にて IPv4 と IPv6 のデュアルスタックサーバを作る

Perl において、この用途には IO::Socket::INET というコアモジュールが広く使われていて、
ちまたにはこれを、IO::Socket::IP に変えるだけで IPv4/IPv6 デュアルスタックが実現するかのような話が広く知られているようだが、実際はどうも違う模様。。

今まで IPv4 で動作していたこのコード:
#!/usr/local/bin/perl
#
use utf8 ; binmode(STDOUT, ":utf8") ;
use IO::Socket::INET ;                     # ソケットインタフェース使用宣言

$comm_queue  = 5 ;                         # コネクション待ち受けキューの数
$port        = 9999 ;                      # port no.

### 通信ソケット生成
# ソケットオープン
$reqsock = IO::Socket::INET->new (LocalPort => $port,
                                  Listen    => $comm_queue,
                                  Proto     => 'tcp',
                                  Reuse     => 1,
                                 ) ;
if (not $reqsock) {
  err_trap("通信ソケットが作成できません。",$!) ;
  exit ;
}

### サーバメインルーチン
for (;;) {
  $sock = $reqsock->accept() ;
  if (not $sock) {
    err_trap("クライアントの要求受け付けに失敗しました。(accept error)",$!) ;
    exit ;
  }

  if ($child = fork()) {
  # 親プロセスの実行コード
    $sock->close() ;
    waitpid($child,0) ;
    next ;                                 # 次のコネクション要求を待つ

  } elsif (defined($child)) {
  # 子プロセスの実行コード(メインルーチン)
    $reqsock->close() ;
    select($sock) ; $| = 1;                # 常に flash するようにする
    select(STDOUT) ;
    binmode $sock ,':encoding(UTF-8)' ;

  以下、サーバの処理プログラム・・・・
  }
}
IO::Socket:INET の部分を、IO::Socket::IP に書き換えても、IPv6 しか受け付けない状態になります。
もしかしたら、IPv4射影アドレスを使えばいいのかもしれないですが、現状環境には全く合わない。

試行錯誤の結果、以下で動作する模様:
#!/usr/local/bin/perl
#
use utf8 ; binmode(STDOUT, ":utf8") ;
use IO::Socket::INET ;                     # IPv4 Socket インタフェースライブラリ使用宣言
use IO::Socket::INET6 ;                    # IPv6 Socket インタフェースライブラリ使用宣言
use IO::Select ;

$comm_queue  = 5 ;                         # コネクション待ち受けキューの数
$port        = 9999 ;                      # port no.

### 通信ソケット生成
$select = IO::Select->new ;

# ソケットオープン[IPv6]
$psock6 = IO::Socket::INET6->new (LocalPort => $port,
                                  Listen    => $comm_queue,
                                  Type      => SOCK_STREAM,
                                  Reuse     => 1,
                                  Proto     => "tcp"
                                 ) ;
if (not $psock6) {
  err_trap("通信ソケットが作成できません。[IPv6]",$!) ;
  exit ;
} else {
  $select->add($psock6) ;
}

# ソケットオープン[IPv4]
$psock4 = IO::Socket::INET->new (LocalPort => $port,
                                 Listen    => $comm_queue,
                                 Type      => SOCK_STREAM,
                                 Reuse     => 1,
                                 Proto     => "tcp"
                                ) ;
if (not $psock4) {
  err_trap("通信ソケットが作成できません。[IPv4]",$!) ;
  exit ;
} else {
  $select->add($psock4) ;
}

### サーバメインルーチン
for (;;) {
  while (my @ready = $select->can_read) {
    foreach my $reqsock (@ready) {
      $sock = $reqsock->accept() ;
      if (not $sock) {
        err_trap("クライアントの要求受け付けに失敗しました。(accept error)",$!) ;
        exit ;
      }

      if ($child = fork()) {
      # 親プロセスの実行コード
        $sock->close() ;
        waitpid($child,0) ;
        next ;                                 # 次のコネクション要求を待つ

      } elsif (defined($child)) {
      # 子プロセスの実行コード(メインルーチン)
        select($sock) ; $| = 1;                # 常に flash するようにする
        select(STDOUT) ;
        binmode $sock ,':encoding(UTF-8)' ;

      以下、サーバの処理プログラム・・・・
      }
    }
  }
}
参考になったのは、これ → How best to support IPv4/v6 in Perl server

2019/02/07(木)FreeBSD の portupgrade

2019/02/07 18:47 サーバ運営・管理
FreeBSDを10 から11にしたあと、portupgrade で ports 導入の各ソフトウェアを更新したりすると、
===>  Cleaning for ImageMagick7-nox11-7.0.8.22
--->  Cleaning out obsolete shared libraries
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
のようなメッセージが毎回出るようにになります。実害は無いのでほったらかし状態だったが、気になるものは気になるので、対策を。。
# cd /usr/local/lib/compat/pkg
# ls -al
lrwxr-xr-x  1 root  wheel        22  7月  4  2018 libdb_cxx-5.3.so.0@ -> db5/libdb_cxx-5.3.so.0
lrwxr-xr-x  1 root  wheel        18  7月  4  2018 libdb_cxx-5.so.0@ -> libdb_cxx-5.3.so.0
lrwxr-xr-x  1 root  wheel        22  7月  4  2018 libdb_stl-5.3.so.0@ -> db5/libdb_stl-5.3.so.0
lrwxr-xr-x  1 root  wheel        18  7月  4  2018 libdb_stl-5.so.0@ -> libdb_stl-5.3.so.0
lrwxr-xr-x  1 root  wheel        18  7月  4  2018 libdb-5.3.so.0@ -> db5/libdb-5.3.so.0
lrwxr-xr-x  1 root  wheel        14  7月  4  2018 libdb-5.so.0@ -> libdb-5.3.so.0
実に簡単。上記6つのシンボリックリンクを削除するだけ。これで解決しました。
OSをメジャーバージョンアップデートしたら、依存ライブラリは変更されていることが殆どなので、できるだけ早めに各ソフトウェアは再コンパイルするのが無難。

FreeBSD は、後方互換機能で何事もなく動作することが多いです。
しかしそれに頼り切っていると経験上、ある日突然、不可解な障害に悩むことになるのです。

2019/01/25(金)FreeBSD 12.0 カーネルにバグか

弊社管理サーバ19台の内、5台のサーバを FreeBSD12 に更新したのですが、そのうちの1台だけ、不定期に時折 Panic を起こして再起動を繰り返すサーバが・・・

ログメッセージにこんな感じで現れます:
Jan 25 04:15:46 uranus kernel: Fatal trap 12: page fault while in kernel mode
Jan 25 04:15:46 uranus kernel: cpuid = 1; apic id = 01
Jan 25 04:15:46 uranus kernel: fault virtual address    = 0xd8
Jan 25 04:15:46 uranus kernel: fault code               = supervisor read data, page not present
Jan 25 04:15:46 uranus kernel: instruction pointer      = 0x20:0xffffffff8091527d
Jan 25 04:15:46 uranus kernel: stack pointer            = 0x28:0xfffffe00185b9560
Jan 25 04:15:46 uranus kernel: frame pointer            = 0x28:0xfffffe00185b96b0
Jan 25 04:15:46 uranus kernel: code segment             = base 0x0, limit 0xfffff, type 0x1b
Jan 25 04:15:46 uranus kernel:                  = DPL 0, pres 1, long 1, def32 0, gran 1
Jan 25 04:15:46 uranus kernel: processor eflags = interrupt enabled, resume, IOPL = 0
Jan 25 04:15:46 uranus kernel: current process          = 0 (if_io_tqg_1)
Jan 25 04:15:46 uranus kernel: trap number              = 12
Jan 25 04:15:46 uranus kernel: panic: page fault
Jan 25 04:15:46 uranus kernel: cpuid = 1
Jan 25 04:15:46 uranus kernel: time = 1548357259
Jan 25 04:15:46 uranus kernel: KDB: stack backtrace:
Jan 25 04:15:46 uranus kernel: #0 0xffffffff8077a8c7 at kdb_backtrace+0x67
Jan 25 04:15:46 uranus kernel: #1 0xffffffff8072e4b3 at vpanic+0x1a3
Jan 25 04:15:46 uranus kernel: #2 0xffffffff8072e303 at panic+0x43
Jan 25 04:15:46 uranus kernel: #3 0xffffffff80a6496f at trap_fatal+0x35f
Jan 25 04:15:46 uranus kernel: #4 0xffffffff80a649c9 at trap_pfault+0x49
Jan 25 04:15:46 uranus kernel: #5 0xffffffff80a63fee at trap+0x29e
Jan 25 04:15:46 uranus kernel: #6 0xffffffff80a3f825 at calltrap+0x8
Jan 25 04:15:46 uranus kernel: #7 0xffffffff808feb43 at tcp_input+0x1553
Jan 25 04:15:46 uranus kernel: #8 0xffffffff80876a55 at ip_input+0x145
Jan 25 04:15:46 uranus kernel: #9 0xffffffff8084f496 at netisr_dispatch_src+0xd6
Jan 25 04:15:46 uranus kernel: #10 0xffffffff80833d83 at ether_demux+0x163
Jan 25 04:15:46 uranus kernel: #11 0xffffffff80834ee6 at ether_nh_input+0x346
Jan 25 04:15:46 uranus kernel: #12 0xffffffff8084f496 at netisr_dispatch_src+0xd6
Jan 25 04:15:46 uranus kernel: #13 0xffffffff80834184 at ether_input+0x54
Jan 25 04:15:46 uranus kernel: #14 0xffffffff8084b646 at iflib_rxeof+0xa16
Jan 25 04:15:46 uranus kernel: #15 0xffffffff80846476 at _task_fn_rx+0x76
Jan 25 04:15:46 uranus kernel: #16 0xffffffff80779154 at gtaskqueue_run_locked+0x144
Jan 25 04:15:46 uranus kernel: #17 0xffffffff80778db8 at gtaskqueue_thread_loop+0x98
Jan 25 04:15:46 uranus kernel: Uptime: 4h16m16s
Jan 25 04:15:46 uranus kernel: ---<<BOOT>>---
どうも、これに似ている模様・・・:
Bug 234296 - FreeBSD 12.0-STABLE r342216 Fatal trap 12

IPv4,IPv6 を直接扱う部分のようです。どうやら解決をみたらしいのですが、まだリリースバージョンへの反映はなされていません。FreeBSD12 への更新は様子見したほうがよさそう。

〔2019/02/06(Wed)追記〕
 昨日、リリースバージョン向けの対策版(FreeBSD 12.0-p3) が公開されたので、早速、本日未明から午前中にかけてFreeBSD 12 を稼働させている5台のサーバに対し、この不具合対策を行いました。
 数日様子を見て、安定しているようであれば他のサーバも FreeBSD12 に更新予定。

2019/01/17(木)ハードウェア不調によりサーバ1台交換。。

2019/01/17 5:13 サーバ運営・管理
昨年春頃から、動作不全に陥るようになったものの、直接、即サービスダウンに結びつくことは無い役割のサーバなのと、その度にハードウェアリセットで復旧するため、騙し騙し使っていたのですが・・

ついに今年に入ってから、ほぼ毎日動作不全に陥るようになったため、「もう寿命なのだろう」ということで、新品と交換。今回はこれ。
20190117_1.jpg


CPUはこれ(左側。画像クリックで少し大きな画像表示します)。店頭で販売していた最も安価なものを選んだ(要求される仕様からみて充分なので)んですが、4コアの模様。
今まで使っていたハードウェアのCPU(右側。画像クリックで少し大きな画像表示します)は新品で購入して、9年3ヶ月使っていた模様です。
20190117_2.jpg
 
20190117_3.jpg


CPUはまだ使えるのですが、SocketAM2 と称される仕様で、新品でマザーボードを入手するのは不可能。 HDDとかはある程度使い回しが利くのですが、最早、IDEインタフェースタイプの ATA133 とか、そういうものは普通に使えなくなっています。

2019/01/05(土)dovecot 2.3.4 はコンパイルエラーになる

2019/01/05 3:09 サーバ運営・管理
FreeBSD 11.2 または 12.0 にて、dovecot をソースコードから構築しようとすると、
途中で下記のようなエラーが出て、構築が出来なくなります:
test-event-stats.c: In function 'kill_stats_child':
test-event-stats.c:101:2: warning: implicit declaration of function 'kill'
[-Wimplicit-function-declaration]
(void)kill(stats_pid, SIGKILL);
^
test-event-stats.c:101:24: error: 'SIGKILL' undeclared (first use in this
function)
(void)kill(stats_pid, SIGKILL);
^
test-event-stats.c:101:24: note: each undeclared identifier is reported
only once for each function it appears in
gmake[2]: *** [Makefile:656: test-event-stats.o] Error 1
gmake[2]: Leaving directory
'/usr/local/src/dovecot-2.3.4/src/lib-master'
gmake[1]: *** [Makefile:565: install-recursive] Error 1
gmake[1]: Leaving directory
'/usr/local/src/dovecot-2.3.4/src'
gmake: *** [Makefile:683: install-recursive] Error 1
どうやら調査すると、構築環境依存による(?)バグらしく、パッチが出ていました:
https://github.com/dovecot/core/compare/10048229%5E...de42b54a.patch

このパッチでコンパイル自体は通りますが、実際の運用で問題ないかどうかまでは判りません。
dovecot 2.3.3 で特段問題が出ていない場合、2.3.4 へのアップデートは見合わせたほうがいいかもしれません。

2019/01/04(金)FreeBSD 12.0 に更新する際に気づいたこと

2019/01/05 1:38 サーバ運営・管理
20190104.png

FreeBSD11 からは、5年間(2021年9月まで)のサポート期間が明言されている状態なので、
急いでメジャーバージョンアップデート対応する必要性は無いのだが、やはり動作検証・安定運用の実績は必要なので、メジャーバージョンアップデートしてみました。

FreeBSD12 は、少なくとも 2023年末までのサポートになるものと思われます。
OSのメジャーバージョンアップデートは普通に出来ますが、Ports 等で導入したアプリケーションソフトウェアは、基本的に再構築をかけたほうが無難。

まず、portversion -v コマンドを実行すると、下記のようになります:
root[~][2]# portversion -v
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
[Reading data from pkg(8) ... pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
- 245 packages found - done]
Fetching the ports index ... pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
表示されたとおり、pkg-static install -f pkg を実行して対処します。
これだけでは駄目な場合があり、perl モジュール群の更新で、
encode.c: loadable library and perl binaries are mismatched (got handshake key 0xd480080, needed 0xe180080)
のようなエラーが出て更新自体が出来なくなることがあります。
FreeBSD12 アップデート後にこうなった場合は、現状では、
/usr/local/lib/perl5/site_perl 配下を再構築しないと駄目です。

なので、
# cd /var/db/ports
# rm -rf *
# pkg delete perl5-5.26.3
# cd /usr/local/lib/perl5/site_perl
# rm -rf *
のようにして、perl とその依存モジュールを一旦削除し(ports/pakkage 導入の場合)、
再度新規インストールし直す手順を踏む必要があります。

ここで、perl を最新バージョンへ更新する場合は、
# vi /etc/make.conf
として、以下の行を追記 or 変更します;
DEFAULT_VERSIONS+=perl5=5.28
尚、この手順を踏む前に、
# pkg info -r perl5-5.26.3
などのようにして、インストールされている依存モジュールをメモしておき、抜けが生じないようにしましょう。

あと、perl を最新バージョンにすることは必ずしも得策とは言い切れません。
perl の最新バージョンに対応していないモジュールがあって、パッチを入れる必要があるモジュールが少なからずありますので、このあたりは自己責任で対応してください。

2019/01/02(水)FreeBSD13 になると、10BASE-T LANのサポートは一部終了か

2019/01/02 6:04 サーバ運営・管理
2018/12/11 に FreeBSD 12 がリリースされましたが、
リリースノートの「6.3. Deprecated Drivers」(『非推奨デバイスドライバ』という意味)の中でこんな内容がありました。
The following drivers have been deprecated in FreeBSD 12.0, and not present in FreeBSD 13.0: ae(4), de(4), ed(4), ep(4), ex(4), fe(4), pcn(4), sf(4), sn(4), tl(4), tx(4), txp(4), vx(4), wb(4), xe(4)
要するに、FreeBSD 12 では「非推奨扱い」とし、 FreeBSD 13 で「削除する」扱いのデバイスドライバが列挙されており、大半が 10BASE-T をサポートするLANカード等。

弊社だと、ed(4) が1枚だけなので、影響は小さいですが、1~2年後に提供されるであろう FreeBSD 13 にアップデートする際に慌てないようにする上で、今から考慮しておいたほうがよさそう。

あと、FreeBSD でもサポートを打ち切る対象となるような古すぎるLANカードは捨てるしかなさそう。 いまどきの Windows あたりはとっくにサポート打ち切りとなっているので・・・

2018/09/12(水)北海道胆振東部地震の被災状況orz

2018/09/12 14:33 一行放談
・液晶ディスプレイ損傷 1台  → 継続使用困難なので買い替え
・大規模停電によるサービス不能 → 非常用発電機導入(2台必要)

# 発電機については、今までの15年以上も事あるたびに要請続けてきたが、
# なかなか理解得られず、今回も理解を完全に得られていないので、導入実現は不透明。

それ以外の被災は無し。
震度6弱に近い震度5強の揺れだったが、よくもまぁ住宅やモノが壊れなかったものだと。。

近所では、店舗のシャッター損壊と、壁が剥がれた古い建物が1棟でした。

2018/08/20(月)IPv6 6to4 接続を常に優先させる

結構嵌ってしまったので、自分メモ。
ネイティブ IPv6 接続と 6to4 接続、及びローカルLANを1つのサーバに接続している(つまり、3つの回線を接続している)環境で、IPv6 接続が全く出来ない現象に遭遇しました。

どうも
〈サーバからインターネット側への接続〉→ IPv6 接続出来る場合と出来ない場合がある
〈インターネット側からサーバへの接続〉→ IPv6 接続は全く接続出来ない
〈同一ネットワーク又はLANの接続〉 → 問題ない
という現象のようです。

最初、pf のフィルタ設定に問題があるのかと思っていましたが、どうやっても現象は解消せず。
なので、インターネット側から ping6 を流し、tcpdump コマンドでチェックしてみます。
※こんな時に役立つ tcpdump コマンド・・・

すると、なんと! 勝手にNGN回線へパケットが流れている!
ルーティング状態を見てみます....
20180820_1.png


上記で re2 と示すのがNGN回線です。これでは応答を返しても相手に届かないわけです。

何故こうなるのか。。 
どうやら FreeBSD では、OSが立ち上がる時、最後に認識したLANボードで取得したルーティング情報をデフォルトゲートウェイにしてしまうようです。(というか、IPv6的仕様らしい?)
こんな時のために、「ルータアドレスをデフォルトゲートウェイにしない」という指定がネットワークインターフェースに対して出来るようになっています。

具体的には下記のように /etc/rc.conf に指定します(アドレス等は伏せ字にしています):
ipv6_default_interface="re0"
ipv6_defaultrouter="2002:c058:6301::"
ifconfig_re0_ipv6="inet6 2002:xxxx:yyyy:zzzz::qqqq/48 -accept_rtadv"
ifconfig_re1_ipv6="inet6 fdxx:pppp:gggg:hhhh::nnnn/64"
ifconfig_re2_ipv6="inet6 accept_rtadv no_radr"
2行目の、2002:c058:6301:: は、6to4 のリレールータIPアドレス(6to4 においては特に必要で無い限り固定)、
1行目の re0 は、6to4 で接続するネットワークリンクのLANボードを示します。

5行目、 re2 の no_radr というキーワードで、「デフォルトゲートウェイにしない」を指定します。
re0 をデフォルトインターフェースに指定することで、デフォルトゲートウェイが re0 のリンクになります。

/etc/rc.conf を修正後に再起動して、再度ルーティングテーブルを確認します:
20180820_2.png


これで、〈インターネット側からサーバへの接続〉は出来るようになります。
しかし、〈サーバからインターネット側への接続〉で、デフォルトインターフェースに re2 が勝手に選ばれ、NGN回線からインターネット接続しようとします。。

IPv6固有のアドレスポリシーテーブルを変更しないといけないようです。
デフォルトでは、このテーブルは以下のようになっています。
 ::1/128     50   0
 ::/0       40   1
 ::ffff:0:0/96  35   4
 2002::/16    30   2
 2001::/32     5   5
 fc00::/7     3   13
 ::/96       1   3
 fec0::/10     1   11
 3ffe::/16     1   12
2002::/16 の 6to4 エントリは不要です。
自ノードが使うアドレスがある場合、大抵は削除するとよいです。筆者の場合は以下のように変更しました:
 ::1/128     50   0
 ::/0       40   1
 ::ffff:0:0/96  35   4
 2408::/22    10   6
 2001::/32     5   5
 fc00::/7     3   13
 ::/96       1   3
 fec0::/10     1   11
 3ffe::/16     1   12
*1

上記内容を /etc/ip6addrctl.conf に作成し、root ユーザにて
# ip6addrctl flush
# ip6addrctl install /etc/ip6addrctl.conf
を実行することで、即座に反映します。
また、サーバ再起動時に /etc/ip6addrctl.conf を読み込むため、設定内容がその場限りで消えてしまうことはありません。

これで、〈サーバからインターネット側への接続〉も常に 6to4 が優先されるようになりました。

*1 : 2408:://22 の行はたぶん要らないと思う。。(動作は 2018/08/20現在 未確認)

OK キャンセル 確認 その他