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/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現在 未確認)

2018/06/25(月)6to4 回線の IPv6 逆引きを公開設定

2018/06/25 5:10 サーバ運営・管理
今は日本人に優しい資料が無い(あってもちょっと古い)ため、いつもの備忘録代わりに作ってみました。
これを使うためには、
・当該サーバ等を 6to4(IPv4 回線における IPv6 トンネル接続) にて IPv6 に接続している。
・使用するIPv4アドレスは、固定IPである
・設定したい 6to4 IPv6 逆引きゾーンを登録する権限がある

といった前提条件があります。ネットワーク管理者中級向けといったところでしょうか。

この設定をするには、予め該当の 6to4 で使用する IPv6 アドレスの逆引きゾーンを登録したい権威DNSに登録しておかなければなりません。
例えば IPv4 アドレスで 192.168.1.50 に対応する 6to4 IPv6 アドレスは、2002:c0a8:0132::/48 となりますので、
逆引きゾーン 2.3.1.0.8.a.0.c.2.0.0.2.ip6.arpa を当該権威DNSへ登録してから以下の申請作業を行います。
#例示のIPv4 アドレスは、プライベートIPアドレス領域なので、逆引き登録は出来ません。

さて、この逆引きゾーン設定は、該当のホストマシン自身から、申請作業をWebブラウザでアクセスしなければなりません。
とはいっても、該当のホストマシン自体にWebブラウザをインストールしていない場合も多いはずです。この申請のために Chrome などわざわざインストールするのも馬鹿げています。

こんなときにさくっと役立つのが、昔から「テキストWebブラウザ」として存在する Lynx というソフトウェアです。前近代的な故、今どきのエンジニアな方々は知らないかもしれません。画像や動画、音声には対応しませんが、それ以外のコンテンツは何とか表示できます。

FreeBSD においては、 Lynx は Ports で簡単にインストールできます。(Portsツリー /usr/ports/www/lynx)
Lynx をインストールした後は、
lynx http://www.basekernel.co.jp/
のようにコマンドラインでURIを指定します。筆者の環境ではこうなります。。。
20180623_1.png
日本語がまともに表示できません。設定変更を行います。
何故かメニュー部分は文字化けしていませんで、o キー押下で設定画面が出ることがわかります。
ここで、o キーを押下すると。。。
20180623_2.png
なんと、設定画面も文字化け。。。
フォーカス部分は色が変わるようなので、下記の青緑色部分で示す部分を変更します。
#リターンキーや矢印キーを使います。
20180623_3.png
ここで、下記のような表示になるように矢印キーを操作し、リターンキー押下で設定が保存されます。
20180623_4.png
一度終了し、再度
lynx http://www.basekernel.co.jp/
とすると、今度は、
20180623_5.png
こんな感じで表示されるはずです。ここからが本題で、再び一度終了させ、
lynx https://6to4.nro.net/
とアクセスします。以下のような感じになるはずです。
幾つかサーバ証明書の警告が出ますが、yで強制的に進みます。
20180623_6.png
ここで、下の方にアクセス元のIPアドレスが表示されます。
どうやら IPv4 でアクセスしているようです。なので、直接IPv6アドレス指定でやってみます。
6to4.nro.net の IPv6 アドレスは、2002:ca0c:1dea::1 のようです。
#drill コマンドでAAAA レコードを正引きしてみただけです。

一度終了させ、
lynx https://[2002:ca0c:1dea::1]/
のようにすると、今度は受付する画面になりました。
20180623_7.png
ここでパスワード(削除の際に必要になる模様)を入力し、
20180623_8.png
更に、連絡先のメールアドレス、ゾーンを登録した権威DNSサーバ名を入力し、
Submit させます。
尚、連絡先のメールアドレスと2つの権威DNSサーバ入力は必須のようです。

受理・逆引き登録が完了すると、
20180623_9.png
のようになります。何らかの問題があると英語でメッセージが表示され、この画面にはなりません。

同時に登録完了で以下のような電子メールが apnic より送信されます。
20180623_a.png
SOAレコードに登録した電子メールアドレスにも同内容の電子メールが行きますので注意してください。

2018/06/11(月)IPv6の基礎(12) -トラブル対処で役立ちそうな知識

今回は、トラブル対処や調査で出くわしてしまうような場面で、知っていれば何のことは無い、という話題です。
20180611_1.png
実は、IPv6には「一時アドレス」という概念があります。(RFC4941 で規定)
これはサーバ管理者泣かせな機能なのですが、一定時間ごとにどんどんIPv6ユニキャストアドレスが新しくなっていくのです。
そうです。これは「発信元を特定しにくくする」ためのものです。
#これも個人的には、セキュリティに過度に煩い層の影響だと思う。。

サーバ攻撃を受けた際に発信元が分かりにくくなり、原因究明に大いに影響ありそうなのです。
これを逆手にとって、ネット犯罪を助長するような一面があり、しかしながらプレフィックス部はどんなに IPv6 アドレスが変わろうが固定なので、どこまで効果があるかは疑問が残ります。

IPv6 ではリンク毎に「リンクローカルユニキャストアドレス」が付与されるという話を何度かしてきました。
早い話、LANカード或いはイーサネットデバイスが同じ機器に複数あると、その数だけ同じ機器にリンクローカルユニキャストアドレスは割り当てられるのです。
リンクローカルユニキャストアドレスはプレフィックスが同じですので、実際に通信する際は、%で始まるインタフェース名を補助的に使用して、リンクを区別します。

2018/06/10(日)IPv6の基礎(11) - 機器設定時に必要と思われる知識・トラブル対処に向けて

ここでは、インタフェースIDの決定方法について簡単にまとめてみました。
やみくもにIDを付与してもトラブルの原因になることがありますので、留意しましょう。
20180610_1.png
基本的にどのような値でも構わないのですが、IPv6 ではユニキャストアドレスの一部がエニーキャストアドレスと定義されているので、エニーキャストアドレスと区別する必要があります。

ユニキャストアドレスとしてインタフェースIDを指定する場合は、上記提示のIDを避けて指定しましょう。
ユニキャストアドレスとして使用できないインタフェースIDのうち、fdff ~ で始まるIDは、「修正EUI-64」形式を踏襲してインタフェースIDを設定する場合を想定しています。

理解の一助として、ICMPv6 などでイーサネット接続環境におけるIPアドレスを自動設定する際のインタフェースID自動生成方法をまとめてみました。知っておくと、トラブル対策の際に案外役立ちます。
尚、アドレス自動生成・手動設定に関係なく、必ず「修正EUI-64」形式で行う必要があるという訳ではありません。あくまでもひとつの方法として推奨されています。

ただ、この「修正EUI-64」も現在は非推奨になっているらしく(RFC7721,2016年3月)、新たにプレフィックスを基にした乱数発生による方式(RFC7217,2014年4月)が推奨されているようです。
#セキュリティに過度に煩い層がいるものだな・・・と個人的には思ってしまいますが。。
#この件は、次の記事で示します。

ですが、「修正EUI-64」は一般的に広く用いられており、ある日突然変更しなければならない、という状況ではありませんので、少なくともあと2~3年は定番の手法として使われ続けると見ています。
OK キャンセル 確認 その他