9月 152019
 

わけあって ansible を触るようになりました。ネットワーク機器の設定を自動更新できたら良い感じー。みたいな雰囲気で。

で、話のテンポはサササっと行くのですが、Cisco スイッチとかにアクセスする場合、 ssh ではなく今でも telnet を利用している人(会社)は多いかな?
エッジスイッチなんてのはグローバルアドレスが付いてないので外部から攻撃される心配ないし、パケットをキャプチャされることもないので『telnet でじゅーぶん。』みたいな。

そうなるといつまで経っても telnet を利用してしまうわけですが、 ansible が Cisco のネットワーク機器にアクセスするときには ios_command というモジュールを利用すると便利なのですが、こいつは ssh にしか対応してないので、それを使わず telnet モジュールでシコシコ tasks: を並べていく必要があるんですけども。

以下は telnet モジュールを利用した場合の標準的な playbooks の書き方です。

- name: send configuration commands to IOS
  telnet:
    user: admin
    password: cisco
    login_prompt: "Username: "
    prompts:
      - "[>|#]"
    command:
      - show running-config
      - terminal length 0
      - configure terminal
      - hostname ios01
    register: result

  - name: debug
    debug:
      msg: "{{ result }}"

 
この通りにやっても動かないことが多々ある。debug: を指定して output の中を見てももーぐちゃぐちゃ。初めて ansible をテスト的に利用してみると

『ansible ってこんなダサいの? perl の Net::Telnet 使ったほうがよっぽどいーじゃん。』

とかになってしまうのであります。

 
ansible の telnet モジュールがまともに動かない。答えを先に書くと、その原因は “#” にあります。

以下、Cisco 機器のネットワークインターフェースの設定だとします。

interface GigabitEthernet4
  description # VLAN1 Network #
 no ip address
!

 
description に “#” を使っていると telnet モジュールはプロンプトだと勘違いして処理がそこで止まります。
show interfaces status や show interfaces description ・ show running-config など何一つまともに動きません。

telnet モジュールの prompts: はプロンプトの “#” のみを見ているのでは無く Cisco ルータから出力された全ての “#” を見て動作しています。ヘボ過ぎる・・。 orz

telnet モジュールを利用した場合、出力された内容に “#” があるとまともに動作しません。ではどうやって対応するか? 以下は Cisco ルータの場合の対応策です。

- name: send configuration commands to IOS
  telnet:
    user: admin
    password: cisco
    login_prompt: "Username: "
    prompts:
      - "[o|)][>|#]"
    command:
      - show running-config
      - terminal length 0
      - configure terminal
      - hostname ios01
    register: result

  - name: debug
    debug:
      msg: "{{ result }}"

 
prompts: に指定する文字が一文字だからダメで、二文字にマッチさせると何とか無事に動作するようになります。二文字でマッチできない場合はもう一文字追加で;-)。

上記の prompts: の設定では、本スト名が cisco の場合、プロンプトは以下になります。

cisco>
cisco>enable
cisco#
cisco#configure terminal
cisco(coinfig)#interface gigabitEthernet4
cisco(config-if)#

 
つまり、ホスト名の最後の一文字と “#” を組み合わせた “o#” と、いう prompts: 、あと configure terminal 時にはプロンプトの前に “)” がつくので “)#” にマッチするように prompts: を記述します。

これで show running-config したときに設定中に “#” があっても無事に動作するようになります。

 
ansible で telnet モジュールを利用する場合には prompts: に設定した文字列に十分に注意しましょう。 prompts: に指定する文字は register: に出力される前に吸収されてしまいます。

3月 152019
 

このサイトはさくらのレンタルサーバ上にあるので自分の力で apache の設定を変えられはしないので、さくらの VPS 上で運用している icmpv6.orgmotsuyaki.org を HTTP/2+TLSv1.3 に対応させてみました。

どちらのサイトも基本的に写真掲載付きのブログ(とわ言いつつ、最近バッタリ更新が止まりましたが・・)なので、写真とかドドドとあり、一回アクセスで大体 40 個くらいファイルを持っていくんではないかなぁ。と、思います。そんな感じなので HTTP/2+TLSv1.3 は非常に効果的ではないかと思われるわけであります。

HTTP/2+TLSv1.3 に対応するためには色々と準備が必要です。ここでは FreeBSD/amd64 12.0-RELEASE 上で動作している環境を HTTP/2+TLSv1.3 にしてみたいと思います。

1. FreeBSD の準備
手間を掛けたくないのであれば FreeBSD 12.0-RELEASE を用意しましょう。なぜかと言うと、それは OpenSSL のバージョンに関係するからです。
11.2-RELEASE の openssl は以下のバージョンで HTTP/2+TLSv1.3 に対応していないんですね。

$ openssl version
OpenSSL 1.0.2o-freebsd  27 Mar 2018

 
対して 12.0-RELEASE は以下のように表示されます。

$ openssl version
OpenSSL 1.1.1a-freebsd  20 Nov 2018

 
HTTP/2+TLSv1.3 に対応するためには OpenSSL は 1.1.0 以上のバージョンが必要です。

しかし、FreeBSD/amd64 12.0-RELEASE もまだまだ問題があってサーバとしては中々利用しづらいですよねぇ・・。
12.0-RELEASE の問題点はパッと思いつくだけで、

・NTT フレッツ回線を利用、IPv6 での通信時に ssh が利用できない
・shutdown -p now で、電源が落ちない PC がある
・drm-fbsd12.0-kmod はカーネルパニックするときがある(割と頻繁)

僕が直接的に感じたのはこれくらいでしょうか。まぁ、最後のは X が必要なのでサーバにはあまり関係ないですが・・。

 
FreeBSD 11.2-RELEASE を利用する場合には個別に OpenSSL をバージョンアップする必要があります。 ports に security/openssl111/ があるのでそれをインストールするのが良いかも知れませんが、僕は試していません。

 
2. apache24 の環境
FreeBSD の準備が整ったのでいよいよ apache24 の設定を見ていきます。

ports で www/apache24/ をインストールしますが、make config のときに [X] HTTP/2 と [X] SSL は当然として、さらにもう一個設定してあげる必要があります。

「Build enabled SESSION modules」のところで (*) MPM_EVENT を指定してあげる必要があります。

MPM_EVENT を指定すると httpd はマルチスレッドで動作することになるので WordPress などを利用している場合、php (僕は lang/php73/ を利用している) は [X] ZTS 付きでコンパイルし直す必要があります。

以上で準備 apache24 のが整いました。

 
3. apache24 の設定
HTTP/2+TLSv1.3 の設定をします。あちこちにファイルが散りばめられておりますな。

o. /usr/local/etc/apache24/httpd.conf

LoadModule ssl_module libexec/apache24/mod_ssl.so
LoadModule http2_module libexec/apache24/mod_http2.so
LoadModule mpm_event_module libexec/apache24/mod_mpm_event.so

 
上記モジュールの設定が必要です。他に SSL を有効にするとか色々あるのですが、その辺りは割愛します。

あと、既に ports から www/apache24/ をインストールしていて httpd.conf を編集している状態の場合、MPM_EVENT を有効にして make && make deinstall && make reinstall した場合は mpm_event_module の設定が httpd.conf に現れません。
『あれ? MPM の設定はどこでしているのだ?』となるのですが、そのときは /usr/local/etc/apache24/modules.d/ の下の 000_mpm_prefork_fallback.conf を見ましょう。ここで mpm_prefork_module をロードしているので、その部分を mpm_event_module に書き換えてあげる必要があります。

o. /usr/local/etc/apache24/modules.d/000_mpm_prefork_fallback.conf

#LoadModule mpm_prefork_module libexec/apache24/mod_mpm_prefork.so
LoadModule mpm_event_module libexec/apache24/mod_mpm_event.so

 
ports からインストールし直した apache24 の設定の場合、これで大丈夫;-)。

o. /usr/local/etc/apache24/extra/httpd-ssl.conf

  :
その他の SSL の設定は略
  :
SSLProtocol -ALL +TLSv1.2 +TLSv1.3

<VirtualHost *:443>
      :
    その他の SSL の設定は略
      :
    SSLEngine on
    SSLCertificateFile    "/usr/local/etc/apache24/SSL/CRT.crt"
    SSLCertificateKeyFile "/usr/local/etc/apache24/SSL/KEY.key"

    ErrorLog  "/var/log/ssl_error.log"
    CustomLog "/var/log/ssl_access.log" common
    CustomLog "/var/log/ssl_request.log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

    Protocols h2 http/1.1
</VirtualHost>

 
HTTP/2+TLSv1.3 にするので SSLProtocol で +TLSv1.3 してあげるのは当然でしょうかね。あとは VirtualHost ディレクティブの中で、最後に書いてある Protocols h2 http/1.1 を記述します。

これで良いのですが、SSL でアクセスがあったときに本当に TLSv1.3 でアクセスしているのかログを残したいためエラーログ・アクセスログの他に ssl_request.log というのを出力するように設定しました。
自分のブラウザからアクセスして TLSv1.3 でアクセスできているか、確認することができます。

 
とまぁ、設定はだいたいこんな感じでしょうか。 SSLCipherSuite をより強固にしてみる。なんてチューニングも良いかもですね。僕の場合は以下のように設定しています。あ、設定する場合は改行なしで一行で書いてください。

SSLCipherSuite \
ECDHE-RSA-AES128-GCM-SHA256:\
ECDHE-RSA-AES128-GCM-SHA:\
ECDHE-RSA-AES128-SHA256:\
ECDHE-RSA-AES128-SHA:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-ECDSA-AES256-GCM-SHA:\
!LOW:!MD5:!aNULL:!eNULL:!3DES:!EXP:!PSK:!SRP:!DSS:!ADH:!DH

 

 
と、まぁ、こんな感じで準備が整いました。あとは apache24 を restart してアクセスしてみて ssl_request.log を覗いてみると TLSv1.3 で、どの暗号スイートを利用していて HTTP/2 でアクセスしている。と、いう情報が確認できるかと思います。

それにしても、ウェブページの表示は速くなったのか? と、聞かれると、実測はしてないですが、感覚的に『多少速くなったかな?』みたいな雰囲気ではありますf(^^;;。

9月 102017
 

Amazon で USB Wi-Fi の子機が安く売っているのを発見し、購入しました。 AUKEY の AC1200 というヤツです。似たようなのを出しているメーカ名は色々あって Wavlink だとか、型番が WF-R6 というものだったりします。きっと OEM なんでしょうね。フツーの価格が 2,980yen で、クーポン利用で 999yen だったのでラッキーです。もう一個買おうかなぁ。

届いたのはこんな感じ。壁掛けパッケージです。そして、実物はこんな感じ。ずいぶんと大きいです。

USB の子機は 802.11 b/g/n/a/ac に対応しています。僕が購入した USB Wi-Fi 子機では初めての a (5GHz 帯) 対応です(僕は ac な AP は持ってない)。親機にもなれるようですが WindowsOS の場合はユーティリティをインストールしないとダメなようです。なので、自分的には子機専用で使う予定です。

利用しているチップは REALTEK の RTL8812AU というモノらしいです。 Windows10 Creators Update ではドライバなしでサクっと認識され 5GHz 帯のアクセスポイントにすんなり接続できました。
Cisco の EAP などに接続するためにはメーカサイトからドライバをダウンロードする必要があります。
ドライバはこの辺りのが使えるかな。 WN688A2–CD_WLAN_V6.85 のドライバをダウンロードすると良い感じです。

WindowsOS で 801.11a で接続して速度の検証してみたところ 802.11n の FreeBSD で言うところの if_run (Ralink のチップ) の機器の倍以上の 100Mbps 程度で通信することを確認しました。

 
さてと。これが FreeBSD で動作するのか、早速試してみました。

REALTEK の RTL8812AU は FreeBSD では対応していないようでドライバがありません。 REALTEK チップのカーネルモジュールとしては if_urtwn.ko がありますが、これでは動作しません。
で、ウェブで調べていると GitHub にカーネルモジュールがあったので、今回はそれを試してみました。

GitHub から urtwm-master.zip をダウンロードして適当なディレクトリに展開します。そしてその中にあるパッチを適用します。 usbdevs に適用するパッチになります。あとは、同梱の README.md を読んでその通りにやるとコンパイルが通り、インストールも無事に完了です。

インストール後は /boot/modules/ に urtwm-rtl8812aufw.ko urtwm-rtl8821aufw.ko if_urtwm.ko が配置されます。そして、それらを kldload すると利用可能な状態となります。
僕は普段から if_urtwn.ko を利用しているので、以下の設定が /boot/loader.conf に書いてあります。今回も必要かもしれません。

legal.realtek.license_ack="1"

 
さてと。カーネルモジュールのコンパイル時のとこをはしょりすぎているのでちょっと書きますが GitHub からダウンロードしたソースコードは 11.0-RELEASE 以降のカーネルソースが必要になります。

僕は FreeBSD/amd64 では環境が整わず FreeBSD/i386 と FreeBSD/arm で検証しました。

それにしても FreeBSD の 10 系 RELEASE と 11 系 RELEASE では USB 周りのソースの配置がガラっと変わりましたね。 10 系までは /usr/src/sys/dev/usb/wlan/ などにモジュールのソースがあったのに 11 系では /usr/src/sys/dev/ 配置されるようになりました。他にもカーネルのコードが変わっているので 10 系 RELEASE では if_urtwm はコンパイルできません。是非とも 11 系 RELEASE を用意しましょう。

 
と、いうことで if_urtwm* のコンパイルが通ったので使ってみることにします。一番最初に試したのはなんと Raspberry Pi 2 Model B の FreeBSD 11.0-RELEASE-p1 です。 USB Wi-Fi の子機は USB3 に対応しているのですが Ras Pi2 は USB2 にしか対応していないので性能が出ないんですが・・f(^^;;。

ザクっと USB ポートにさしてみると ugen に落ちて認識しません。あらら。僕が購入した AUKEY の AC1200 の情報を usbdevs に書いてあげる必要があります。

と、いうことで以下の行を /usr/src/sys/dev/usb/usbdevs に記述してあげます。 VendorID は既に登録済みだったので ProductID のみ記載します。

product REALTEK RTL8812AU      0x8812  RTL8812AU

 
あと、ソースコード中にも記載してあげる必要があります。 urtwm-master/sys/dev/urtwm/if_urtwm.c に対して以下のパッチを適用します。

--- sys/dev/urtwm/if_urtwm.c.orig       2017-09-07 18:59:06.031051000 +0900
+++ sys/dev/urtwm/if_urtwm.c    2017-09-06 20:51:41.749003000 +0900
@@ -128,6 +128,7 @@
        URTWM_RTL8812A_DEV(SENAO,               EUB1200AC),
        URTWM_RTL8812A_DEV(SITECOMEU,           WLA7100),
        URTWM_RTL8812A_DEV(TRENDNET,            TEW805UB),
+       URTWM_RTL8812A_DEV(REALTEK,             RTL8812AU),
        URTWM_RTL8812A_DEV(ZYXEL,               NWD6605),
        URTWM_DEV(DLINK,        DWA171A1),
        URTWM_DEV(DLINK,        DWA172A1),

 
これで、再度コンパイルしてインストールします。今回購入した USB Wi-Fi 子機は REALTEK の RTL8812AU というデバイスとして認識されるようになります。

kernel: urtwm0 on uhub0
kernel: urtwm0:  on usbus4
kernel: urtwm0: MAC/BB RTL8812AU, RF 6052 2T2R

 
で、 FreeBSD/arm 11.0-RELEASE-p1 と FreeBSD/i386 11.1-RELEASE-p1 で試してみましたが、残念ながら 802.11a では接続できませんでした・・。orz

ただし、 802.11n では動作しました。こちらのほうはかなりの速さで、一応 30Mbps くらい出ました。 USB 子機が大きくてアンテナがちゃんとしているからでしょうかね。
WindowsOS では 802.11a で利用できるのですが、残念ながら FreeBSD では 802.11n だったですが、速度が出るのでヨシとしておくかぁ。と、いう感じでしょうか。 NotePC には大きくて常用は厳しいですが Ras Pi2 には良いかもしれんです。

USB3 へ接続すると 802.11a で通信できるのかなぁ? 今回はその環境がありませんでした。

あ。 /etc/wpa_supplicant.conf とか /etc/rc.conf の記述方法は今回ここでは書きませんが、大丈夫ですよね?

 
自宅の ThinkPade145 は USB3 が動作するのですが、この NotePC はカーネルのみが 10.1-RELEASE のままなので今回のカーネルモジュールはコンパイルできません。 syspend/resume を取るか、最新の FreeBSD を取るか悩ましいところではありますが、僕の場合は suspend/resume のほうが重要。なのでバージョンアップはしていません。

 
と、いうことで GitHub から拾ってきた if_urtwm のカーネルモジュールですが、一応は動いている。ということになります。if_run も if_rum も if_urtwn も、今までは 802.11n 対応だったので今回 FreeBSD で初めての 802.11a のドライバ。と、いうことになるかと思われます (僕の試した環境では接続できなかったけど・・)。

if_urtwm はどんなデバイスがあるのか? というのは上のパッチを適用したソースコードである sys/dev/urtwm/if_urtwm.c の中に書いてあるので、試してみたい方は一回覗いてみると良いかも知れません;-)。

9月 092017
 

手頃な値段の Cisco ルータが欲しいなぁ。と、思っていて Cisco C841M-4X-JSEC/K9/START でも良いかなぁ。とか、色々考えたのですが Amazon で CISCO892J-K9 が 2,900yen (当然中古) で売っていたので飛びついてしまいました・・f(^^;;。

まぁ、仕事柄 Cisco のスイッチやルータは触っていて IOS については多少の知識があるので特に問題は無いです。

が、しかし、 CISCO892J-K9 は GigabitEthernet ポートが一個しかなくて、しかもルーテッドポート。スイッチポートが 8 個の FastEthernet ポートなので、自宅が既に Giga 化している環境においては役不足です。『やっぱり 841 のほうが良かったかなぁ・・。』などと悩むのですが、考えてみると 841 はポートが 4 個しかないのでどのみちスイッチを購入する必要があります。

と、いうことで、今回は CISCO892J-K9 と NETGEAR の GS108E-300JPS を購入しました。前者が 2,900yen に対して後者が 4,830yen でした。うむむ。

二つ並べるとこんな感じ。

NETGEAR GS108E-300JPS はアンマネージプラスなスイッチです。シリアルコンソールではアクセスできないし telnet もできないけど、ウェブブラウザでアクセスすることにより VLAN の設定が行えます。
今回は CISCO892J-K9 で VLAN を設定し、タグを GS108E-300JPS に通して、GS108E-300JPS から L3 ルータに伸ばす(こういうふうに書くとかっちょ良いのですが “L3 ルータ” とは VyOS のことです;-)。と、いう構成にしました。

物理構成図はこんな感じ。

GigabitEthernet0 はルーテッドポートなので VLAN が指定できないのですが bridge で VLAN1 に入れました。アップリンクの Fa0 (ルーテッドポート) は PPPoE なので 100Mbps でも大丈夫ですが、下に行くポートは 1Gbps で落としたい。と、いう雰囲気ですね。

CISCO892J-K9 の Gi0 をスイッチポートとして利用する config は以下のようにしました。
bridge 設定の抜粋です。

bridge irb
!
interface GigabitEthernet0
 description # VLAN 1 LAN-Zone #
 no ip address
 duplex auto
 speed auto
 ipv6 enable
 bridge-group 1
!
interface Vlan1
 no ip address
 ip virtual-reassembly in
 ipv6 enable
 bridge-group 1
!
interface BVI1
 description # VLAN1 bridge Interface #
 ip address 192.168.1.254 255.255.255.0
 ipv6 address 3ffe:6580:AA40::254:1/64
 ipv6 address 3ffe:6580:AA40::/64 eui-64
 ipv6 enable
!
bridge 1 protocol ieee
bridge 1 route ip

 
今回利用している IOS は 15.6(3)M2 です。 bridge には interface BVI1 を利用します。BVI1 に IPv4・IPv6 アドレスを付加しています。あ。 IPv6 の設定についてはここでは書きません;-)。

上記設定 GigabitEthernet0 がスイッチポートの仲間入りです。しかし、 GigabitEthernet0 で VLAN を Trunk で利用できないので Fa4 と GS108E-300JPS を物理接続している。と、いうような感じです・・。

CISCO892J-K9 の スイッチポートに接続した機器は GigabitEthernet0 を通って 1Gbps で自宅のサーバ群にアクセスする。と、いうような感じになっています。
あと、 CISCO892J-K9 には Wi-Fi AP も接続しているので 100Mbps の帯域でも十分な場合もあります。なので、これで良いかなぁ。と、いう気がしないでもないです。

 
そーそー。最後に一点。 CISCO892J-K9 には USB ポートがあるのですが『わーい。USB で電源供給できるぞぉ。』などと思い喜んで Raspberry Pi2 と Pi3 の二台の給電をしていたら、あれま・・。 CISCO892J-K9 が夜中に再起動を繰り返すようになってしまいました。

二台の RasPi を USB から引っこ抜き、 CISCO892J-K9 は一日電通しないでほったらかしにして再度起動したらその後は安定稼働しているので、多分電源不足で CISCO892J-K9 が安定しなかったんだろう。と考えています。
今回は中古で購入し、動作不安定でハラハラドキドキしました。一応一ヶ月の保証がある機器だったので購入先に連絡を入れました。が、基本的には USB ポートに RasPi (しかも二台っ!!)を接続しないほうが良さそうですf(^^;;。

 
この CISCO892J-K9 のネタは今後続いていくかな? 変わった設定とか、へんなことが起きた時に書いていきたいと思います;-)。

8月 202017
 

自宅のネットワーク内で mDNS を流していたら LLDP 流す必要ないやんかー。などと思うんですけども。
mDNS は網内というかルータを超えないセグメント内でマルチキャストを流し、 LLDP も同様に L2 レベルでマルチキャストを流します。

LLDP (Link Layer Discovery Protocol) は接続しているマルチベンダーの機器に対して自分の情報をお知らせするためのプロトコルです。
CDP (Cisco Discovery Protocol) は CIsco 機器だけでしか機器の情報を交換することができませんが、 LLDP は様々なネットワーク機器・サーバが流すことができます。

例えば Cisco ルータ(スイッチでも良いけど;-) で CDP を利用しているとき、VMware ESXi などのハイパーバイザーの NIC は CDP を吸収します。そして、仮想マシンでは LLDP を流すことにより、どのスイッチに、どんな物理サーバ (ESXi が動作している物理サーバ) が接続していて、その物理サーバ上でなんという仮想マシンが乗っているか、 CDP+LLDP で一目瞭然把握できるのであります。

なので、サーバ上で LLDP を流すのはネットワーク機器にとっては良い感じなのですね。

サーバ運用者主体で機器情報を収集するのであれば mDNS を起動しておくだけでも全然問題はないのですが、スイッチのどのポートに何が接続しているか? と、いう情報まで収集したいのであれば ESXi で CDP を、仮想マシンでは LLDP を動作させるのがグーです。

 
FreeBSD には ports として net-mgmt/cdpd/ もあるし net-mgmt/lldpd/ もあるのでどっちも動作することができます;-)。

が、今回は LLDP について書いてみます。

まぁ、 ports から net-mgmt/lldpd/ を make install しておしまい。って感じですが、 make config のオプションが悩ましい。 BASH も ZSH もインストールしたくないので [ ] として、 SNMP を [X] にすると net-mgmt/net-snmp/ をインストールしてしまい大げさになるし・・。まぁ、お好みで;-)。
JOSN や READLINE 、 XML などは lldpctl -f で出力フォーマットを指定できるのですが、そのときに利用します。

そして、インストール後ですが、設定フアイルは sample さえもインストールされないので自力で用意する必要があります。設定ファイルは /usr/local/etc/lldpd.conf になります。 man lldpcli すると書式が解ります。
僕の場合は以下の書式を作りました。

#configure system hostname "wanchan"
#configure system description "FreeBSD-10.3-RELEASE"
configure system interface pattern em*,bge*,re*,wlan*,ue*,vmx*
configure system ip management pattern 192.168.*,*:*
#configure med fast-start enable
#configure med location address floor "32F"

 
最後の “configure med location address” な設定はどえりゃー複雑で、ちゃんと形式に沿って記述されてないとエラーになります。イヤになって、書く必要ねぇやぁ。みたいな感じですf(^^;;。
設定は上から順に

  • ホスト名
  • OS とバージョン
  • LLDP で流す NIC の情報 “,” で区切って複数指定できます
    IP アドレスの情報は勝手に取ってきて流してくれます
    実は wlan* は not an ethernet device なので動作してくれません
  • IP アドレスのレンジの情報
    IPv4・IPv6共に指定できます
  • Enable LLDP-MED extension の指定
    FreeBSDの ports の場合 configure 時に –enable-lldpmed が付いてないので不要っぽい
  • 上にも書いた通り設置場所情報
    snmpd が動作していれば不要だよねぇ。ふつーは・・

準備ができたら service lldpd onestart して、起動を確認します。

 
続いて確認方法ですが、僕の家には Cisco ルータもしくはスイッチが無いので VyOS で確認してみました。

まず VyOS で LLDP を有効にします。

set service lldp interface eth0

 
FreeBSD 側から LLDP が届いているか確認するには以下のコマンドを打ちます。

takachan@vyos:~$ show lldp neighbors 
Capability Codes: R - Router, B - Bridge, W - Wlan r - Repeater, S - Station
                  D - Docsis, T - Telephone, O - Other

Device ID                 Local  Proto  Cap   Platform             Port ID 
---------                 -----  -----  ---   --------             ------- 
wanchan.running-dog.net   eth0   LLDP   RS     FreeBSD 10.3-RELEAS em0     

 
VyOS には LLDP の確認コマンドに対しては show lldp neighbors しかないので貧弱です。Cisco スイッチのように show lldp entry HOGE みたいなのがあっても良いのですけどねぇ。そーいうのはないようです。

 
lldpd を起動した FreeBSD 側での確認するには lldpcli コマンドを利用します。
ウダウダ出るので詳細は書きませんが以下のコマンドを打つと『なるほどね。』となると思います。
あ。 root でコマンドを実行する必要があります。

  • lldpcli show chassis
  • lldpcli show neighbors
  • lldpcli show neighbors summary
  • lldpcli show neighbors ports vmx0
  • lldpcli show statistics

lldpcli コマンドは UI が貧弱なのでとんなオプションがるのかちぃーとも分かりません。しょーがないのでソースコードで確認です。 src/client/show.c を眺めてオプションを把握しますX-|。

なお、 lldpcli が面倒な場合は素直に lldpctl コマンドでオプション無しが良いでしょう。 -h でパラメータも表示してくれます。

 
ただ、 FreeBSD で動作する lldpd は多少問題があるようです。

1). ports の Makefile があやすぃ・・。
net-mgmt/lldpd/Mkaefile の中の CONFIGURE_ARGS で –with-privsep-chroot=/var/empty という行があるのですが、 /var/empty って Read Only やんけ。 lldpd は起動時に /var/empty/etc/timezone を生成しますがそれができないので WARNING なメッセージが出力されます。
僕は Makefile をいじって –with-privsep-chroot=/var/run/lldpd にしてしまいました。

2). bsnmpd と相性が悪い?
lldpd を起動すると以下のメッセージが出力されます。

snmpd[810]: RTM_NEWMADDR for unknown interface 0

 
/usr/lib/snmp_mibII.so の handle_rtmsg() で出ているんだけど、原因がイマイチ分からん。bsnmpd と lldpd を同時に起動すると上記のメッセージが出力される場合があります。

気付いたのはこの二点かな。

 
これで一応、FreeBSD も LLDP を投げるようになり lldpcli で確認することもできます。 lldpcli は mDNS でいうところの avahi-browse と似たようなモンんでしょうかね。

上にも書いた通り mDNS を利用するか LLDP を利用するかについてはネットワーク運用部門の人と綿密に計画を立てて行うのが良いかと思われます。 Cisco 機器の場合 LLDP をサポートしている機器や ISO のバージョンがあまり多くはないような気がしないでもないですし。

まぁ、それにしても、自宅のネットワークの場合は全て僕一人で行うんですけどもね;-)。

8月 122017
 

自宅の環境に Windows Server 2012 R2 で動作する Active Directory を導入しました。たくさんの FreeBSD (サーバ・デスクトップ含む) と二台の Linux と、ほどほどの Windows10 があるのですが、アカウントを利用している人は二人のみ。どうして Active Directory が必要なんじゃい? と、なるのですが、実はほとんど利用していない。

と、いうか、諸々な件で検証しなければならず、本当は必要ないんだけど、ショウガなく Active Directory の設定を行い、ユーザ情報を登録してみた。と、いう感じで、現在は色々動作確認している最中です。

 
そもそも、既存の Windows 環境はワークグループで管理していたのにドメインに入るとデスクトップ環境が一から作られるので、ドメインには参加したくはないわなぁ・・。

 
と、いうことで Windows Server 2012 R2 で Active Directory が動作するようになったんだけど、 Active Directory のインストール段階では、自宅のネットワークには既に FreeBSD 上で 二つの DNS サーバが動作しているのであえて Windows Server 上で DNS を起動する必要は全くない。

Windows Server 2012 R2 では Active Directory のみを動作させ、 DNS は継続して FreeBSD で動作させるように構成したのでありました。

さてと。 Windows Server 2012 R2 を再起動して Active Directory で設定したドメインに組み込むと DOMAIN\takachan でログインできるようになりました。

他の Windows マシンもドメインに参加させようと思ったのですが、例えば Windows10 でコントロールパネルの「システム」から「所属するグループ」でドメインをチェックしてドメイン名を指定しても「それは見つからない。」とエラーになりました。

以下のようなエラーコードとなり、Windows10 がドメインに参加できません。このエラーコードは [詳細 >>] を開くと表示されています。

エラー コード 0x0000232B RCODE_NAME_ERROR

 
この事象は Windows Server 2012 R2 で Active Directory を構成して、DNS は他の OS で持たせた場合に発生するようです。
Windows Server 2012 R2 で Active Directory と DNS を同時に構成すると問題ないらしいです。

 
僕は DNS は FreeBSD で bind9 の named で設定していますが、ドメインで利用した ドメイン名のゾーンファイルに SRV レコードを追加してあげる必要があるようです。

 
以下は SRV レコードについてまとめた情報です。条件は以下のときに効果的です。

  • Windows Server 2012 R2 で Active Directory は構成したが DNS は構成していない
  • DNS は FreeBSD や Linux など UNIX 系 OS で named などを利用し既に動作している
  • 上記のような環境で Windows OS がドメインに参加しようとすると参加できない
  • ちなみに Active Directory に設定したドメインは running-dog.net
  • DNS のゾーンファイル名は running-dog.net.zone

ここでは bind9 の named.conf や zone ファイルの基本的な記述方法・内容については書かないです。知っているモノとして話を進めます。

と、いうことで上記のような環境の場合、 UNIX 系 OS で動作している named のゾーンファイルに以下の設定を加筆してあげる必要があります。

今回は bind-9.10.6 のゾーンファイルの記載例です。

今回、Active Directory のドメインは runniong-dog.net なので、 bind9 の running-dog.net.zone のゾーンファイルに以下の行を追加してあげます。

_kerberos._tcp           IN      SRV 0 0   88 ad-server
_kerberos._tcp.dc._msdcs IN      SRV 0 0   88 ad-server
_ldap._tcp               IN      SRV 0 0  389 ad-server
_ldap._tcp.dc._msdcs     IN      SRV 0 0  389 ad-server
gc._msdcs                IN      SRV 0 0 3268 ad-server

 
雰囲気的には mDNS のようですね。 TCP ポート 88・389 と 3268 に対して SRV レコードを追加してあげる。と、いうことですね。
ゾーンファイルの SRV レコードとはなんぞや? となるのですが、 RFC2782 で定義されていて、DNS でホスト名や IP アドレスの他にサービスについても広報してしまう。と、いうノリのようです。

TCP ポート 88・389・3268 は ad-server.running-dog.net でサービスを提供しているよ。と、いう記述です。

 
通常 Active Directory を構成した場合は Windows Server 2012 R2 で合わせて DNS も構成するので上記の SRV レコードが記載されるのでしょうな(僕はやったことが無いので解らない;-)。しかし、これを bind9 などで構築した場合にはゾーンファイルに SRV レコードを記載してあげないと他の Windows OS が Active Directory を見つけられない。と、いうことなのでしょうなぁ。

 
では、SRV レコードの他にもっと簡単に見つける方法あるんでないの? と思うと、パッとひらめくのは『 mDNS で流したらえーやん。』と、なるのですが、考えてみると mDNS ってのはルータを超えられないのでデータセンタなどにある AD の場合はまるで役に立たないんですね。
なので、きっと DNS で SRV レコードを記載してそれを利用するのが一番手っ取り早い。と、なったのでしょうなぁ。

7月 222017
 

一台の PC で IPv6 が使えている状況で、他の PC にも IPv6 がほしいなぁ。と、いうことが、最近、多々あります。
NIC やスイッチのポートが限られていて他の PC を同一セグメントに接続できないじゃーん。みたいな・・。

と、いうことで構成図を一枚。

・緑色のルータは FreeBSD のルータで PC1 と gif トンネルで接続しています。

今までは PC1 で IPv6 を使えれば良かったんだけど、PC2 や PC3 でも IPv6 を利用したい。ぱっと思い浮かぶのが PC2 や PC3 でも個別に gif トンネル掘って緑色のルータと接続すれば良いしゃん。と、いう案です。

他にないの?というと、例えば

PC1 の gif0 と em1 を bridge にして PC2 と PC3 を接続して 2001:470:fe36:11::/64 のセグメントを利用できるようにしてあげる。

って案ですね。が、しかし、 FreeBSD では (if_gif を利用すると?) bridge がまともに動かないですなぁ・・。
と、いうか、最近まで知らなかったのですが、bridge するインターフェースは MTU を揃えないとエラーになるんですね。

# ifconfig em0 mtu 1500 up
# ifconfig gif0 mtu 1280 up
# ifconfig bridge0 create
# ifconfig bridge0 addm gif0 addm em0  up
ifconfig: BRDGADD em0: Invalid argument
# ifconfig bridge0 destroy
# ifconfig em0 mtu 1280 up
# ifconfig bridge0 addm gif0 addm em0  up

 
上記のエラーが出たときにどうして Invalid argument なのか /var/log/messages にメッセージが出力されますね。知らんかった・・。

 
とまぁ、仮に無事に bridge0 が生成されたとしても IPv6 の通信ができないので諦めました。 bridge0 に addm gif0 した段階で通信が途絶えます。 ifconfig bridge0 destroy すると復活します。原因はどこにあるのだろう?

 
以前、 VyOS を二台用意して IPv4 の別セグメントに IPv6 を L2 抜けする設定を一回掲載していますが、そんな大げさなネットワークを構築するのはイヤです;-)。

まぁ、今回は PC1 から PC3 までが同一セグメントに入っている必要はなく、とりあえず三台の PC が IPv6 で外部にアクセスできると嬉しいなぁ。と、いう感じなので、何かワザはないのか?と思い、考えたら『あぁ。NAT すりしゃ良いじゃん。』となったのであります。

 
と、いうことで IPv6 で NAT を有効にするにはどうしたら良いのだぁ? 調べてみると NAT66 という技術を利用するようですね。 IPv6 で IPv6 の NAT をするので NAT66。

と、いうことで前回同様、今回も pf を利用します。

今回は上の構成図に合わせると PC1 で pf を利用して NAT66 が動作するようにします。 PC1 の pf で設定は以下のような感じ。

nat on gif0 inet6 from 2001:470:fe36:100::/64 to any -> 2001:470:fe36:11::2

 
一行でできました;-)。これを /etc/pf.conf に書けば完了。

PC2 と PC3 は NAT のアドレスなので fd00::/8 のユニークローカル IPv6 ユニキャストアドレスを /64 で任意のセグメントを定義して利用しても問題は無いです。
僕の場合は 2001:470:fe36::/48 を持っているのでその中から NAT 用に 2001:470:fe36:100::/64 を切り出て利用しました。

NAT で利用する 2001:470:fe36:100::/64 は gif0 に付加されている 2001:470:fe36:11::2/64 を抜けて通信するので pf でその設定をしてあげると上のようになります。

簡単ですね。あとは service pf onestart して sudo pfctl -sa で確認すれば良いと思われます。

PC2 と PC3 はスタティックに IPv6 を ifconfig で設定してあげてください。PC1 で rtadvd の設定するの面倒なのでf(^^;;。

PC2 と PC3 では default gateway を指定する必要があるので、そのために PC1 の em1 に IPv6 アドレスを付加してあげる必要があります。

# ifconfig em1 inet6 2001:470:fe36:100::1 alias

 
PC2 と PC3 はこの IPv6 アドレスを default gateway に指定してあげます。

 
ちなみに 緑色のルータと PC1 の gif トンネルの説明はないですが、大丈夫ですよね? 以前のエントリで「IPv6 Over IPv4 トンネルを dtcp から VyOSへ。」と、いうのを書いているのですが、「2. dtcpclient 側の設定」の設定をサーバ側・クライアント側として逆に打つとトンネルを掘ってくれます。

 
と、いうことで、今回は NAT66 の設定を pf で行い、簡単に IPv6 を利用する方法を書きましたが、IPv6 が欲しい場合には比較的容易に gif トンネル + NAT66 っていうのが良いかもしれないです。

グローバルアドレスが付いている FreeBSD があれば、網内のどこにでもある FreeBSD から gif トンネル掘って、その下で NAT66 すれば良いだけですねぇ。

簡単だぁ;-)。

7月 182017
 

最近 Asahi-Net で PoE じゃなかった。 IPoE で IPv6 が利用可能になった。僕は他にも hi.net で IPv6 を /48 ほど借りているので二つのセグメントが利用可能なのであります。贅沢だぁ;-)。

と、いうことで自宅のネットワーク環境を見直してみました。

IPv4/IPv6 のセグメントをそれぞれ表側・裏側と二つ用意したんですね。

構成図はこんな感じ。 (多少、端折っているf(^^;;)

Server-Zone と LAN-Zone があり、管理用 PC2 は両方のセグメントに到達性があるわけなんですが、実際に運用してみると非常に厄介。

例えば管理用 PC2 には LAN-Zone の 192.168.1.100 が、 Server-Zone には 192.168.22.100 が付加されているとして Server1 の Server-Zone 側の IPv4 に ping を打つと元リは LAN-Zone 側から戻ってきてしまう。ぐるっと回ってしまうんですね。

パケットの流れ的には以下のような感じ。PC2 のソースアドレスは 192.168.1.100 で出て行きます。

管理用PC2 の NIC1 -> Server2 の Server-Zone -> Server2 の LAN-Zone -> 管理用 PC2 の NIC2

ぐるっと一周の旅です。これがグローバルアドレスだと、ISP 側では『自分の管理してないアドレスからバケットが届いた。』ということで破棄されます。

あぁ・・。サーバにポリシールーティングの設定入れないと・・。 orz

FreeBSD の場合、 ipfw の fwd でも pf でも、バケットが届いた NIC から出ていく。って設定ができないんですね。
パケットが届いた NIC のゲートウェイアドレスに返す。って設定はできるようなんですけど、その場合はゲートウェイ経由で届いたパケットは送信元に戻っていくけど、同一セグメント上のコネクテッドな送信元には戻っていかない。まいったなぁ・・。

 
上記の構成図のうち Server1 が Linux (CentOS 6.9) の場合、以下のように /etc/rc.local に書くと良いです。

ip route add 192.168.22.0/24         dev eth0 tab 100
ip route add 2001:470:fe36:beef::/64 dev eth0 tab 110
ip route add 192.168.1.0/24          dev eth1 tab 120
ip route add 3ffe:6580:aa40::/64     dev eth1 tab 130

ip route add default via 192.168.22.1           dev eth0 tab 100
ip route add default via 2001:470:fe36:beef::1  dev eth0 tab 110
ip route add default via 192.168.1.1            dev eth1 tab 120
ip route add default via 3ffe:6580:aa40::ffff:1 dev eth1 tab 130

ip    rule add from 192.168.22.10/32           tab 100 priority 1000
ip -6 rule add from 2001:470:fe36:beef::2:1/64 tab 110 priority 1100
ip    rule add from 192.168.1.10/32            tab 120 priority 1200
ip -6 rule add from 3ffe:6580:aa40::2:1/64     tab 130 priority 1300
ip route flush cache

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

route add と rule add を利用してポリシールーティングしてあげるとサクっと動作します。

最近の Linux のシステム管理者は default Gateway の設定はせず、ほとんど上記のようなポリシールーティングで設定を行い、セキュリティを強化しているようですねぇ。

 
FreeBSD の場合 ipfw の fwd では無理でした・・。僕にその知識が無いのかもしれないです・・。
なので、ファイアーウォールは ipfw だけど、ポリシールーティングの設定は pf でやるとこにしました。
以下が pf の設定です。 Server2 のは FreeBSD/amd64 10.3-RELEASE です。
/etc/pf.conf に記載します。記載したあとは service pf onestart したあとに pfctl -sa で確認できます。

pass quick on lo0  all
pass quick on vmx0 all
pass quick on em0  all
#
# NIC vmx0 -> vmx0 (IPv4)
pass out quick on vmx0 from 192.168.22.20 to 192.168.22.1/24
pass in quick on vmx0 reply-to (vmx0 192.168.22.1) from any to 192.168.22.20
pass out on vmx0 route-to vmx0 from 192.168.22.20 to any
#pass  out on vmx0 route-to (vmx0 192.168.22.1) from 192.168.22.20 to any
# NIC vmx0 -> vmx0 (IPv6)
pass out quick on vmx0 from 2001:470:fe36:beef::3:1 to 2001:470:fe36:beef::1/64
pass in quick on vmx0 reply-to (vmx0 2001:470:fe36:beef::1) from any to 2001:470:fe36:beef::3:1
#pass out on vmx0 route-to vmx0 from 2001:470:fe36:beef::3:1 to any
pass out on vmx0 route-to (vmx0 2001:470:fe36:beef::1) from 2001:470:fe36:beef::3:1 to any
#
# NIC em0 -> em0 (IPv4)
pass out quick on em0 from 192.168.1.20 to 192.168.1.1/24
pass in quick on em0 reply-to (em0 192.168.1.1) from any to 192.168.1.20
pass out on em0 route-to em0 from 192.168.1.20 to any
#pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.20 to any
# NIC em0 -> em0 (IPv6)
pass out quick on em0 from 3ffe:6580:aa40::3:1 to 3ffe:6580:aa40::ffff:1/64
pass in quick on em0 reply-to (em0 3ffe:6580:aa40::/64) from any to 3ffe:6580:aa40::3:1
pass out on em0 route-to em0 from 3ffe:6580:aa40::3:1 to any
#pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::3:1 to any

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.20
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::3:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.20
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::3:1

これで FreeBSD の場合は IPv4/IPv6 共にパケットが届いた NIC と出ていく NIC が一緒になるかと思います。グルっと回って反対側の NIC から出ていくことはなくなります。

僕は pf についていまいち解ってないのですが、 pass out on vmx0 route-to のオプションで (NIC Gateway) の設定があるのですが、この場合は vmx0 の 192.168.22.1 なゲートウェイアドレスに転送するよ。って設定ぽいですね。その場合、同一セグメント上の送信元、俗に言う、コネクテッドなホストには届かないんでないの? って気がするので (NIC Gateway) の記述ではなく () をはずして NIC のみを記載しています。

1).コネクテッドなホストと通信ができて、ゲートウェイの先のホストと通信ができない設定

pass out on em0 route-to em0 from 192.168.1.10 to any
pass out on em0 route-to em0 from 2405:6580:aa40::2:1 to any

 

2).ゲートウェイの先のホストと通信ができて、コネクテッドなホストと通信ができない設定

pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.10 to any
pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::2:1 to any

 
IPv4 の LAN-Zone なアドレスは外と通信することが無いので 1). の設定で十分な気がします。
IPv6 アドレスの場合、LAN-Zone は守りたいので 1). のほうが良いかな。

こーいうのを意識せずに、ゲートウェイの先のホストとコネクテッドなホストの両方と通信できる設定ってできるのかしら? その点 Linux は良い感じに動作していると思うんですけども。

ポリシールーティングの設定の場合、入ってきた NIC の先の Gateway に返す。ってのはウェブでまぁ、ほどほど見かけるのですが、僕から言わせてもらうと『入って来た NIC から出ていってくれてるだけで良いよ。』ってのが素直な感想なのだけど、そーは行かないのかな?

 
設定が完了したら pfctl -sa してみたり tcpdump -i vmx0 で確認してみると、パケットは入って来たポートから出ていくし、コネクテッドなホストとも無事に通信ができています。まぁ、この設定でヨシとしておきましょう。

 
あと、今回の検証のために FreeBSD の VRF の技術でもある setfib を試しましたが IPv6 が使えないのね・・。

そして、fib ごとにルーティングテーブルが個別になると思うんだけど、どうして別の fib のルーティング情報も見えるんだろう? fib はインターフェースとリンクしなくて良いのかな? 不思議だ・・。

$ setfib 0 netstat -nr -f inet
Routing tables
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.1.33       link#3             UHS         lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#2             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.22.0/24    link#2             U           ue0

 
(fib: 0) 側に 192.168.1.0/24 のルーティング情報が乗っていたら意味ないし、 (fib: 1) に 192.168.22.0/24 の情報があったら、ダメなような気がするんだけど・・。 ue0 から入ってきたパケットは wlan0 に抜けていってしまうと思われる・・。
setfib って、二つ (fib の数だけ) のルーティングテーブルを持つことができる。って機能ではないのかしら?

 
ルーティングテーブルがこんな具合になってくれていると多分 pf によるポリシールーティングは必要ないのではないか。と思われます。

$ setfib 0 netstat -nr -f inet
Routing tables (fib: 0)
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#3             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U         wlan0
192.168.1.33       link#3             UHS         lo0

 

5月 102017
 

一個前のエントリは RPi ZERO で FreeBSD/arm 11.0-RELEASE が動いた。というお話でした。RPi 2/3/ZERO 上で動作する OS はディスプレーが無いので Zeroconf を動かして ssh hoge.local したいと思いますよね。

そして、以前のエントリで「Zeroconf 考察」というのを書いているのですが、デスクトップには Avahi をインストールして、サーバなどはより軽量な mDNSResponder をインストールすれば良いよ。などと書いているのですが、 mDNSResponder は core dump するなど、どうも動作があやすぃ・・。
なので、いっそのこと Avahi で統一したいモノだ。などと思っていたんですけども net/avahi-app/ は、サーバには不要なモノをインストールしすぎる。

そんなこんなで、もっと簡単にインストールできる軽量版の net/avahi-app/ の ports を作成しました。名前を avahi-app-small としていますが・・。
以下の URL にあるので、もし試してみたい。と、いう方がいましたらダウンロードしてみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-avahi-app-small-20170510.tgz

インストールは以下の通り。

# cd /usr/ports/net/
# tar xvzfp ~/ports-avahi-app-small-20170510.tgz
# cd avahi-app-small/
# make install

 
フツーの ports をインストールするのとなんらかわりはありません。が、注意点が一点だけあります。クライアント側の ports である dns/nss_mdns/ を make install するより先に avahi-app-small をインストールしてください。

ではどの辺りが違うのか? 軽量なのか?

標準の net/avahi-app/ の ports は以下をインストールします。

Shared Libs required:
        libintl.so.8
        libglib-2.0.so.0
        libgobject-2.0.so.0
        libexpat.so.1
        libgdbm.so.4
        libdaemon.so.0
        libdbus-1.so.3

 
devel/glib20/ や devel/gobject-introspection/ は関連性でサーバには要らんモノ (cairo とか freetype2 とか python27 とその関連性の ports など)をドドドとインストールしてとてつもないことになるし sysutils/gnome_subr/ なんてのも要らんし・・。

僕が作成した avahi-app-small の ports をインストールすると以下がインストールされます。

Shared Libs required:
        libdbus-1.so.3
        libintl.so.8
        libdaemon.so.0
        libexpat.so.1

 
これだけです。 非常に軽量にインストールできます。 Avahi 自体は dbus を利用しているので dbus は必須になってしまいますが、これはまぁしょーがないか。
ports からインストールするとコンパイルのために色々インストールされますが、あとで pkg autoremove するか、コンパイルの時間がもったいない場合には packages からインストールしてください。

 
ports の Makefile では LIB_DEPENDS は最小限にして CONFIGURE_ARGS では不要なモノを色々 disable にしています。これだけでずいぶんと小さくなりました。
GNOME 必要ねーし。 Makefile の以下の行は何のためにあるんだぁ?

avahi-post-patch:
    :
        @${REINPLACE_CMD} -e 's|%%RC_SUBR%%|/etc/rc.subr| ; \
                s|%%GNOME_SUBR%%|${GNOME_SUBR}|' \
                ${WRKSRC}/initscript/freebsd/avahi-dnsconfd.sh.in \
                ${WRKSRC}/initscript/freebsd/avahi-daemon.sh.in
    :

 
files/patch-initscript_freebsd_avahi-daemon.sh.in には +. %%GNOME_SUBR%% なんて最初から書いてあるし・・。

と、いうことで要らんモノを削ぎ落としていったらすごい軽量な(それはつまりは、余計なモノをインストールしなくて済む。と、いうことで、動作的に軽くなった。と、いう意味ではない;-) Avahi がインストールできるようになりました。
試したのは avahi-daemon avahi-dnsconfd avahi-browse くらいですが、これだけ動けば、一応問題はないでしょ? f(^^;;。

あ。ports 的にはノラです;-)。gnome@freebsd.org (メンテナ) に連絡して「make config で余計なのインストールするのやめるように、選択できるようにしてくれよー。」って、ツッコミ入れるのはアリだと思うのですけどねぇ・・。

今回の ports はサーバと FreeBSD/arm で動作させるために作成した。と、言っても過言ではないですが、これで自宅のデスクトップとサーバは Linux も含めて全て Avahi になった。あ。macOS は別だぁ;-)。

2月 282017
 

多分、全然、誰も知らないと思うのですが、 FreeBSD の ports に net-mgmt/sysmon/ というのがあります。デーモンモードでサーバなどを監視するプログラムです。開発自体はもうずいぶんと前に止まっている。裏を返せば枯れた監視プログラムなのであろうと思われますが。

以下の URL が参考になるでしょうか。

https://puck.nether.net/sysmon/

プロトコル的には SMTP, IMAP, HTTP, TCP, UDP, NNTP の監視に対応しています。また PING に対応しているのと、個別にポート番号を指定しての監視も行えます。

 
今回、このプログラムを改修するバッチを書いたのでここに掲載しておきます。改修内容は以下です。

o.pingv6 で IPv6 アドレスを記載できるようにした
o.監視ホストの最大数が 1,024 個だったので 4,096 個に拡張した

以上二つの patch が含まれた net-mgmt/sysmon/ の ports の tar 玉を以下の URL に置きました。

http://icmpv6.org/Prog/FreeBSD_ports/ports-sysmon-20170227.tgz

新しく files/ というディレクトリを作成し、そこに二つのパッチを入れてあります。

IPv6 のパッチについてちょっと説明すると監視用の設定ファイルに “type pingv6;” と記載して、監視できるのに “ip” のところに IPv6 アドレスを記載できないんですね。なので IPv6 アドレスを記載できるようにしました。

まぁ /etc/hosts に書けばいーじゃーん。って話もあるんですが、一応 IPv6 記載 OK なパッチを書いた。と、いうことです。

 
監視対象ホストを 1,024 -> 4,096 に拡張してどうすんだ? という話もあるんですが、大規模ネットワーク用の監視になるでしょうかねぇf(^^;;。

実は sysmond を一台のサーバで複数プロセス起動する改修を当初考えたのですが、複数のプロセス(スレッド)を立ち上げると、メモリ上に持っている(1,024個の)監視対象ホストの情報テーブルを各プロセスがシェアしてしまい、上書きしつつ値がぐちゃぐちゃになってしまったので、派手な改修は断念してただ単に対象数を増やした。と、いうことですf(^^;;。

もし、必要な人いましたら使ってみてください。多分、誰もいないであろうと思われますがf(^^;;。