2018/06/02(土)IPv6の基礎(5) - 機器設定時に必要と思われる知識

前回は、IPv6のアドレス種別について簡単に示してみましたが、
今回はもうちょっと細かい部分を示します。理解しておかないと、この先益々チンプンカンプンになる可能性がありますので、是非一度眺めてください。
20180605_1.png


・ユニキャストアドレス
 一言で「ユニキャストアドレス」と言っても主なものだけでもこれだけの種類があります。
 このうち、3) と 4) は、2018年6月現在では既に廃止されているため、古い機器の設定や古い文献を参照する場合は注意です。
 廃止時点で既にこの世に出回っている機器で廃止された機能を使うことは妨げないことになっていますが、結局、近い将来に新しい機器との相性問題になるため、廃止された機能等は使わないようにするべきです。

 このうち、ユニークローカルユニキャストアドレスは、IPv4における「プライベートIPアドレス」と同じように使用できるアドレス領域として規定されています。
 以前は、似たような目的で「サイトローカルユニキャストアドレス」というのが規定されていたのですが、これは「ユニークローカルユニキャストアドレス」に置き換えることとなっています。

・エニーキャストアドレス
 エニーキャストアドレスは専用のアドレス領域が割り当てられておらず、プレフィックス以外の部分のアドレス表現で、ユニキャストアドレスと区別されるようになっています。
 例示は、よく使われるプレフィックス長 /64 の場合ですが、インタフェースIDの部分(IPv6 アドレスの後ろ半分)が fdff:ffff:ffff:ff80 ~ fdff:ffff:ffff:ffff のアドレスと、0000:0000:0000:0000 はエニーキャストアドレスとして解釈されるので、ユニキャストアドレスとして使用することができません。こういった部分に注意する必要があります。

・マルチキャストアドレス
 IPv6においては、先頭が ff~ で始まるIPアドレスは、マルチキャストアドレスと規定されており、仕様で定められているマルチキャストアドレス以外は、ユーザが自由に割り当てることもできます。
 IPv6は、IPv4にあった「ブロードキャスト」が仕様として存在しないため、代わりに「マルチキャストアドレス」を使うように置き換えされています。
 例示は、必要不可欠で必須的に使われている2つのマルチキャストアドレスを示しています。
 

2018/06/01(金)IPv6の基礎(4) - 機器設定時に必要と思われる知識

久々になります。
今回は、今後の説明の理解に必要な基礎的内容になります。
20180326_3.png


実は、これらは IPv4 にも存在する概念ではありますが、IPv4 には明確に示している既存資料があまり見当たりません。
そう大きな相違は無いのですが、明示してみることにします。

・ユニキャストアドレス
 ネットワーク通信の大半がこの形態です。「ユニキャスト」とは「単一の相手」という意味で、一対一で対向通信を行う目的で、通信端点(通信装置)毎に異なるアドレスを付与します。
「IPアドレス」と単に示す場合、殆どの場合この「ユニキャストアドレス」を指します。

・エニーキャストアドレス
 あまり見慣れないと思いますが、IPv4 では、192.88.99.0/24 が 6to4 と言われるIPv6ネットワークとの相互接続において主に利用されています。
 技術的には IPv4 でも IPv6 でもエニーキャスト自体は可能です。(「IPv4 ではエニーキャストはできない」と書いている諸氏が散見されるが、それは間違い)

 エニーキャストとは、複数のサーバに同じIPアドレスを予め付与しておき、そのアドレスに向けて発信した際に、最も早く応答した相手(通常は対応可能で最も近い相手)と一対一で対向通信を行います。

・マルチキャストアドレス
 「複数相手への同報通信」がマルチキャストです。
 エニーキャストアドレスとマルチキャストアドレスが発信元IPアドレスには絶対になりません。返信が必要な場合、各ホストやルータに割り当てられている本来のユニキャストアドレスを発信元として返信を行います。
 IPv4では後から追加された仕様ということで、あまり普及していませんが、
 IPv6では「ブロードキャスト」の概念に代わり、「マルチキャスト」に置き換わっています。

2018/05/15(火)FreeBSD で大量のファイルを一度に消去する

2018/05/15 24:25 サーバ運営・管理
いつもの自分メモ・・・
今般、サーバのHDD使用残量が変に圧迫していて、不要なファイルを削除する、というメンテナンスを行う必要性が出たのですが、削除対象ファイルがざっと 200万 ~ 300万個あり(計算上)、普通に削除しようとすると、下記のようになります:
20180515_1.png


これは、コマンドラインで '*.jpg' のようにワイルドカード指定すると、処理を始める前段階で、全ての対象ファイル名をリストにするからで、そのリストサイズは現行 FreeBSD の場合、262144 バイトに制限されており、数が多いと収まりきらないためです。そのため「引数のリストが長すぎる」というエラーになるのです。

このような時は、標準入出力をパイプで連結する、という手法をとります。
20180515_2.png


xargs コマンドが肝になる部分で、このコマンドは、標準入力に与えられた長いリストをエラーにならない範囲で分割し、所定のコマンドを実行するものです。

これで、削除には15時間ほどかかりましたが、無事に削除完了できました。

2018/04/10(火)IPv6の基礎(3) - 機器設定時に必要と思われる知識

今回は、IPv6 対応の機器に IPv6 アドレスを設定するときの記述方法です。
20180326_2.png
IPv6 アドレスは記述自体が長くなるため、一定の省略記述ルールが決められています。
しかしながら、必ずしも省略記述をする必要はありません。
むしろ、慣れないうちは敢えて省略記述をしない方がよいのです。

ですが、実際には先駆者によって多用されているので、ここでは省略記述ルールを紹介します。
「省略記述」は全て、数字の'0' (ゼロ) を省略するルールが定義されています。

先ず、「各フィールドの上位桁の'0'は省略可能」です。ただし、'0000' だけは全てを省略せずに'0'を記述します。
次に、「'0000' のフィールドが連続する場合は、該当部分を '::'(ダブルコロン)で省略可能」です。
但し、これが使えるのは1回だけです。

また、'::'(ダブルコロン)は、最も長く省略できる部分に適用すべき、と規定されました。
なので、厳密には上記例の3番目も×です。
2番目の 2001:db8:0:3::1 のみが正解となります。

更に、IPv6 表記でしか設定できない環境下で、IPv4を表記する場合の記述法も定義されています。
現在は、「IPv4 射影アドレス」の記法がよく用いられており、「IPv4 組み込みアドレス」は淘汰方向現在は廃止(使用不可)です。[RFC6890] 参照。
ただし、「IPv4 組み込みアドレス」もたまにみかけるので、知っておくとよいです。

2018/03/28(水)IPv6 の基礎(2) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識

不定期掲載のIPv6基礎ネタ第2号です。

今さら誰にも聞けないレベルになりつつある内容ですが、この「備忘録」が役立てば幸いということで。。
今後、従来からのIPプロトコルは、IPv6 と区別するために IPv4 と称することにします。
世の中での表記区別がそうなっているため、それらに倣うことにしました。

今回はIPv6 アドレスの形式です。
20180326_1.png
IPv4 では当初、クラスA,クラスB、クラスC、クラスD、クラスE というカテゴリ分けで、IPアドレスブロックの割り当てがされ、サブネットマスクは固定でした。
以下のような感じです:

クラスA  1 ~ 126 で始まるIPアドレス (サブネットマスク 255.0.0.0)
クラスB 128 ~ 191 で始まるIPアドレス (サブネットマスク 255.255.0.0)
クラスC 192 ~ 223 で始まるIPアドレス (サブネットマスク 255.255.255.0)
クラスD 224 ~ 239 で始まるIPアドレス (サブネットマスク 255.255.255.255)
クラスE 240 ~ 254 で始まるIPアドレス

このうち、クラスDはマルチキャスト通信専用で使われており、クラスEは各種実験・特殊用途向けで一般利用はできないことになっています。
0と255で始まるIPv4 アドレスは仕様的に使用不可、127で始まるIPv4アドレスは、ループバック専用で、これは用途が仕様として強制されています。

クラスDにサブネットマスクの概念そのものがなく、クラスEには、サブネットマスクの規定はありません。
#なので、クラスEの領域は実際は「IPv4 枯渇を無視して割り当てされずに温存されて」います。

クラスA,クラスB、クラスCのサブネットマスクは、1992年6月に RFC1338 で初めて CIDR(「サイダー」と称する模様) と言うクラス分けをバッサリと捨てる概念(=クラスレス化)が提唱され、 1993年9月の RFC1519 を経て、2006年8月に RFC4632 で現行のものになりました。

さて、IPv4 は、アドレスが4オクテット(4バイト)固定長で構成されます。
1オクテットずつ、ドット区切りの10進数で表記するのが通例です。
1オクテットで表現できる10進数の整数は0~255 なので、各ドット間の数字は必ず0~255の範囲になります。

これに対して、IPv6 は、アドレスが16オクテット(16バイト)固定長で構成されます。
実にIPv4アドレス総数(約43億)の 232倍 × 232倍 × 232倍 = 2128 個(約340澗 ≒3.4 ×1038) になり、『これだけあればアドレス枯渇問題は将来に亘ってほぼ皆無だろう』ということになっています。

アドレス表記も16進数表記です。これはエンジニアの間では常識ですが、16進数のほうがディジタル機器のあらゆる整数数値において親和性が非常に高いためです。
16進数表記の a ~ f は、基本的に小文字を使うように規定されています。[RFC5952, 2010年8月]

「16進数」がわからない方は、google などを使って各自調べてください。
合わせて「2進数と16進数」の関連を知ることで、何故16進数の方が親和性が非常に高いかが理解できるかもしれません。

IPv6 のアドレスは、2オクテット(2バイト)毎にコロンで区切って表記します。
そして、コロンで区切った各々の部分は「フィールド」と呼称します。
このフィールドは、省略表記(別記事にて後述)しない限り、桁数は4桁固定で必ず8個になります。

IPv6 には「サブネットマスク」という概念がありません。
その代わり、IPv4 のクラスレス化で導入した CIDR の考え方を踏襲して、「プレフィックス」「プレフィックス長」という概念が導入されました。

IPv6 における「プレフィックス」とは IPv4 で言うところの「ネットワークアドレス」、
この長さをビット長で示したものが「プレフィックス長」になります。

2018/02/20(火)IPv6 の基礎(1) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識

今回から不定期にIPv6基礎ネタを備忘録的に残していこうと考えています。
あくまでも「備忘録」です。はい。

筆者がかねてから想像していたとおり、今まで嗜んできたIPv4 とは毛色が違うし、似て似つかないものがあります。なので、初心者から「志を持って」(何のだ・・)猛勉強中です。

そんな中、各種のネットワーク機器を家電量販店やICT機器専門店などで買うときや、買った後で知っておくと、周囲に威張ることができそうな理解がしやすくなるような基礎知識を先ずはまとめていきます。

IPv4 は、軍事・学術研究から行き当たりばったりで進化してきた技術ですが、
IPv6 は最初から民生用途が意図されていて、万人共通の定義づけがいくつかあります。
ここがまず IPv4 と違う世界ですね。
IPv6基礎(1)
IPv6 の世界で先ず使われる用語の基礎用語として、以下があります:
■ ノード
 IPv6 通信機能を持った機器全てを指す。
 具体的には、パソコン、ネットワークプリンタ、ルータ、サーバを指し、ハブやスイッチングハブなどはノードに含みません。
 図示していませんが、スマートフォン、タブレットも「ノード」です。
 ノードは「ルータ」と「ホスト」の2つに区別されます。

■ リンク
 ハブやスイッチングハブ、無線LANアクセスポイントなどを介して、ルータ超えしないで直接イーサネットやWiFiで通信可能な装置間接続を指します。
 ルータ同士の通信も「リンク」です。
 ルータ超えの通信は「リンク」ではありません。

■ サイト
 1つ以上のリンクからなるLANを指します。
 ルータが複数あっても、インターネットに出ていかずに別のリンクと接続するLANは、接続ルータ先のリンクもまとめて「サイト」になります。
 ただ、この概念は古い IPv6 の資料には出てくるのですが、現在は使いません。
 古い IPv6 の資料を読むときに必要となります。

■ ルータ
 ノードのうち、リンク外部との通信中継・リンク内部通信の取りまとめを行う機器を指します。
 インターネット接続には不可欠な装置になります。

■ ホスト
 ノードのうち、ルータ以外の全ての機器を指します。
 受信時、自ホスト宛は処理できるが、他ホストへ転送出来ない機器全てがホストです。
 パソコン、ネットワークプリンタ、サーバ、スマートフォン、タブレットなどは、典型的なホストの一例です。
 リンク内でも他ホストへの送信は、基本的にルータが取りまとめて処理します。

■ 近隣ノード
 リンク内で通信が直接到達可能なノード全てを指します。

これらは概念として理解しておくと、後々 IPv6 の理解が楽になります。

2018/01/26(金)コントロールパネル改良作業開始

2018/01/26 4:23 サーバ運営・管理
大多数の方々にはどうでもいいことではありますが・・・
弊社コントロールパネル https://ctrl.basekernel.ne.jp/ の改良作業をしています。

改良内容は:
○ 左メニューをボタン化して操作性改善
○ IPv6 対応(DNS AAAA レコード、PTR レコードの追加サポート)
○ サブドメイン、逆引きゾーン対応

といった、DNS絡みが中心です。
逆引きゾーンは弊社の場合、弊社技術者以外は一般には使うことがない機能ですが、
どのようなニーズにでも対応できるように公式提供する予定。
以下は、開発版の画面。提供時には変わるかもしれません。

これが出来ないと、次の段階でLANのIPv6 対応環境が整わない状態で、先に進まないのです。

IPv6は今まであまり必要性が無かったため、特に対応しないままでやってきましたが、
今年あたりからIPv4・IPv6併用の案件が増えてくることが予測できるため、今のうちにシステム構築をある程度やっていこうという状況だったりします。

目下のところ、IPv4 とは毛色が全く違うため、IPv6 の基本的なところから学習中です。

〔2018/02/04 追記〕
システム構築の作業は終わり、これからマニュアルの更新作業ですが、これが大仕事。。。orz

2017/12/09(土)FreeBSD Ports のgnuplot は使い物にならなくなった・・・

2017/12/09 5:34 サーバ運営・管理
gnuplot とは、グラフを描画するための有名なソフトウェアで、かれこれユーザ歴だけは15年ほどになります。

弊社では今まで gnuplot を安直に FreeBSD Ports コレクションからインストールしていたのですが、余計なものが依存関係で入って来るのが悩ましいところでした。

そこへいつものように FreeBSD Ports コレクションからアップデートを図ろうとしたところ・・・
なんと、X11 ライブラリ群がデフォルトで依存関係として入ってしまうようになったのです、、、
X11 サポートを外すことが出来なくなった。。致命的です。

弊社の環境では、単純にグラフが PNG や GIF,JPEG 形式で描画できれば十分で、X11 なんぞ邪魔!!!
ということで、止む無くソースコードから構築することにしたのです。
ちなみに現時点での最新は 5.2.2 です。

多機能な分、構築作業が複雑そうだなという先入観が強かったのですが、結局、
# setenv CPPFLAGS '-I/usr/local/include -I/usr/include'
# setenv LDFLAGS '-L/usr/local/lib -liconv -L/usr/lib'
# ./configure --with-readline=gnu
# gmake
# gmake install
で、済むようです。FreeBSD 11.1R-p5 (amd64) の環境で確認しました。

注意点としては、gnuplot 本体をインストールする前に、libpng 等のグラフィックスライブラリ、readline ライブラリ、IPAやkochi等の日本語フォントを予め Ports などでインストールしておく必要があります。

-liconv オプションは、どういうわけか libiconv がリンク出来ないというエラーを吐いて構築が中断する状態になるので、その回避策として追記したという状態です。

2017/12/07(木)PowerDNS 4.1 リリース(with PostgreSQL)

2017/12/09 5:03 サーバ運営・管理
ということで、弊社のマスターDNSを PowerDNS 4.0.4 から PowerDNS 4.1.0 に更新してみました。

「久しぶりの記事がこれかい」と呆れられると思いますが。。orz
どうやら、今回の『売り』は、「当社比で PowerDNS 4.0.x から 最大で 400% 高速化した」ということらしいです。

単純に「4.0.4 の使用をやめて、セキュリティFIX された 4.0.5 以降にしなさい」という警告メッセージが出ていたのがきっかけなのですが。。orz

さて、PowerDNS 4.1.x に更新するにあたり、PostgreSQL を使用し、且つソースコードから構築する際の configure オプションが変更になっています。

PostgreSQL サポートに関しては、
 --with-pg-config=/usr/local/pgsql/bin/pg_config
これだけでいけるようになったようです。
ちなみに弊社では、ソースコードから
# ./configure --enable-libsodium 
       --with-pg-config=/usr/local/pgsql/bin/pg_config 
       --enable-perl=yes
        --with-modules="bind gpgsql random"
(実際には改行せず、1行で入力)のようにして構築しています。
環境は、FreeBSD 11.1R-p5 amd64版です。

2017/10/16(月)CGI に Python を利用し、PostgreSQL を使用する

2017/10/16 2:35 サーバ運営・管理
どちらかというと、自分メモ。 CGIというのは、環境変数からパラメータを受け取り、 標準出力へ HTTPヘッダ群とコンテンツを出力する、というのが基本的セオリーで特別なことは必要ないです。 しかし、昨今の Python3系では、WSGIインタフェースというものを意図してCGIを制作するのが普通になっており、これはパフォーマンスの点で有利とされています。 Apache に mod_wsgi 拡張モジュールをインストールする必要があります。 現在のところ、標準モジュールにはなっていないため、別途インストールが必要です。 FreeBSD11 における mod_wsgi インストールは、ソースコードから下記のように行うのが確実。 pip (後述しています) でのインストールは、環境判定を誤認識したり変にエラーを吐いたりすることが環境によっては発生するため、筆者は全くお勧めしません。
# cp mod_wsgi-4.5.20.tar.gz /usr/local/src 
# cd /usr/local/src
# tar xvzf mod_wsgi-4.5.20.tar.gz
# cd mod_wsgi-4.5.20
# ./configure --with-python=/usr/local/bin/python3.5 --with-apxs=/usr/local/apache2/bin/apxs
# make
# make install
--with-apxs を指定することで、お使いのサーバにおける環境に合わせた構築が出来ます。 通常、mod_wsgi は、上記の場合、/usr/local/apache2/modules/ 配下に動的リンクでインストールされます。 Apache への mod_wsgi に対する設定は、以下を参考にどうぞ:
LoadModule wsgi_module modules/mod_wsgi.so

WSGIDaemonProcess cgi-bin user=webadmin group=webuser processes=1 threads=5
WSGIScriptAlias /     /home/webroot/hoge/cgi/app.wsgi

<Directory "/home/webroot/hoge/cgi">
  WSGIProcessGroup cgi-bin
  WSGIApplicationGroup %{GLOBAL}
</Directory>
ちなみに WSGIインタフェース自体は、Python に特化する目的を持つものではありません。 この辺りは勘違いされている諸氏が結構多いようです。 Perl だと mod_perl という Apache に組み込む形での有名な高速化拡張モジュールがありますが、それと同じようなものでしょうか。 Python 以外では導入メリットが見えにくいです。 最近のPerl はそれ自身が高速化してきているので、mod_perl 導入のメリットが見えにくくなってきているのと、mod_perl を組み込んだ状態にてCGIをスレッド動作させると原因不明の不安定な動作になったり、Perl 5.26 にすると、静的モジュールでは何故かインストールできないなど、色々問題があり、筆者のサーバでは mod_perl の利用は見合わせている状況です。 次に、Python から、PostgreSQL インタフェースを扱うモジュールをインストールするのですが、このインストールに先立ち、pip というサポートツール(?)を導入する必要があります。 Perl で言うところの CPAN に該当するものですね。
# python3.5 -m ensurepip
あれ? と思った諸氏も居られるかもしれません。 多くのサイトには「Python 3.4 以降では、pip は同時にインストールされる」と説明されているからですが、FreeBSD11 にて Ports から Python を導入した場合、pip は導入されません。FreeBSD11 にて Ports から Python を導入した場合、pip は手動操作で導入しないと駄目らしいです。 でも、pip は今後のメンテナンスで必須になるものの、今回は使いません。 最後に Python の PostgreSQLインタフェースモジュールをインストールするのですが、これもpip では環境誤認識をするため、ソースコードを持ってきて、下記の手順が確実です。 事前に、PostgreSQL 本体をインストールしておくことは言うまでもありませんね。
# cp psycopg2-2.7.3.1.tar.gz /usr/local/src
# tar xvzf psycopg2-2.7.3.1.tar.gz
# cd psycopg2-2.7.3.1
# setenv PATH '/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/pgsql/bin'
# python3.5 setup.py build
# python3.5 setup.py install
ここで重要なのは、pg_config コマンドのパスを、環境変数 PATH に含めることにあります。 Python の psycopg2 は、Perl における DBI と DBD::Pg の組み合わせに相当します。