isLandcenter 非番中

ブログトップ | ログイン

Windows Update にノストラダムスの大予言のような帯域を食わせたくない。

何だかネットワークが遅い、エラーがでる。クラウドサービスに接続できない、などのトラブルをよく聞くようになりました。

そんな時はWindows update が帯域を食いまくっている場合があります。

Microsoft、「Windows 10」のデルタ更新を終了へ ~エクスプレス更新に一本化


何しろ ISP の回線容量をも破壊する、Windows Update はインターネット業界でのサイバーテポドン。毎月やってくるノストラダムスの大予言

空から恐怖の大王が来るだろう
アンゴルモアの大王を蘇らせ、
マルスの前後に首尾よく支配するために。

Windows Update はインターネット業界の恐怖の大魔王、諸悪の根源になりつつあります。だからWindows Update の帯域制限をしたい。

NTTコムの「OCN」が輻輳状態、Windows Updateが原因か

「なんでもクラウド」の反省すべき点で、ソフトウェアのクラウドサービスを検討する時に、真っ先に

「反省」

すべき事の一つです。

何しろ Windows10 の update は、サイズが半端ない。

で、ついにやっちまったのが、Windows update を P2P 配信するという荒業。

Windows10の Windows Update はデフォルトで使ってはいけない

しかし、結局はアップデートがキャッシュされるのはデフォルト3日が最大で、インターネット経由の P2P は結局ルータに負荷がかかる。つまり得をするのは配信の大元である Microsoft のサーバーだけなんですね。ルーター越しの回線負荷が下がるわけでなし。

しかも年に二度ほどある「大型アップデート」は3~4Gのダウンロードがあります。これで社内数百台のPCがアップデートするとどうなるのか。

もう想像がつきます。社内でみんなで Netflix やってる状態。グループポリシー(GPO)で帯域制限できないものか。



--
ま、大型アップデートはヘルプデスクチームが代表して、ISOファイルをダウンロードして共有 NAS なんかに置いておき、みんながそれをツツけば、ダウンロード自体は一回で済みます。

Windows10 手動で ISOファイル からアップデートする




- まずは Windows update の帯域制限をする -

という事で Windows Update の帯域制限をやってしまおうという事。

田 > 歯 >「更新とセキュリティ」>Windows Update の中の "詳細オプション" > 「詳細オプション」の中の "配信の最適化" > 「配信の最適化」の中の "詳細オプション" >「ダウンロード設定」「アップロード設定」

というイスタンブールのトプカピ宮殿のハーレムのタンスの奥にしまったようなところに、「ヒミツの設定」が隠されており、ここのスライダーをポチっとやると、バックグラウンドでのアップデートの帯域制限ができます(きっと)。

リモートワーク時代のサイバーテポドン Windows Update の回線帯域を確保:GPO_a0056607_11505631.png


一般的に ISP の回線設定はダウンロードよりアップロードの方が帯域が制限されているので、アップロードは極力少なくすべきでしょう。

アクティビティモニタもあるので、どれくらい「貢献」したかも確認できます。

リモートワーク時代のサイバーテポドン Windows Update の回線帯域を確保:GPO_a0056607_11520851.png

それにしても、”マイクロソフトからのダウンロード量12Gb”っていったい何をダウンロードしてるんでしょうね。一発 Windows Update すると格安 SIM をギガ爆死させる強力な破壊力



- グループポリシーで帯域制限:GPO -

GPO グループポリシーで Windows Update の帯域制限をすることもできます。こちらの方が細かな制御ができそうです。

> gpedit

ローカルポリシー > コンピューターの構成 > 管理用テンプレート > ネットワーク > バックグラウンドインテリジェンス転送サービス(BITS) を「有効」にセットし「転送レート」をkb 単位で設定します。


リモートワーク時代のサイバーテポドン Windows Update の回線帯域を確保:GPO_a0056607_11523616.png

「配信の最適化」では、帯域の「何%にするか」を設定するわけですが、これでは、1Gbps のローカルネットワークが 100Mbps のインターネット回線に繋がっているかどうかの判断はできないわけです。仮に "10%" で設定すると、1Gbpsの10%、つまり100 Mbps で通信しちゃうのですんね(たぶん)。

一方 GPO で設定する BITS は具体的に「転送速度」を指定できるので、LANの状態やインターネット回線の「太さ」に合わせて細かな設定ができるので、グループポリシーを使った方に分がありそうです。という事で細い回線なら数十Kbps、早い回線でも、社内LANにどれ位の台数の端末があるかにもよりますが、100Kbps 程度(多分)に控えておくのが良いと思います。

> gpupdate を実行してポリシーを適用します。

C:\>gpupdate
ポリシーを最新の情報に更新しています...

コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。


C:\>

まぁ台数が多いなら、WSUSを入れる方がよほど効果がありそうなんですが、WSUSも最近はどうも動作が妖しい。

- BITS って何だ? -

BITS(Background Intelligent Transfer Service)は、ネットワークがアイドリングしている時にバックグラウンド通信を行うように制御することです。これで必要な通信量を確保するのですが、所詮、OSが認識できるのは NIC の通信量、つまり LAN の通信量が制御できるだけ。ルーターにどれだけトラフィックがかかっているかは判断できないでしょうね。「配信の最適化」機能で使われる技術です。


- WSUS と併用する -

WSUSと併用する場合、次の文書が役に立ちそうです。

配信の最適化について #2 グループポリシー篇
https://blogs.technet.microsoft.com/jpwsus/2018/11/02/aboutdo_2/

Windows 10 の更新プログラムの配信の最適化
https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-optimize-windows-10-updates

グループポリシーを使います。

> gpedit

ローカルコンピュータポリシー > コンピュータの構成 > 管理用テンプレート > "Windows コンポーネント" にある "配信の最適化" の中にローカルネットワークでの Windows Update の配信の最適化のパラメータがいくつかあります。「歯」(設定)にある P2P 配信の抑制よりもよほど細かな制御ができそうです。

リモートワーク時代のサイバーテポドン Windows Update の回線帯域を確保:GPO_a0056607_11531824.png
> gpupdate を実行してポリシーを適用します。

C:\>gpupdate
ポリシーを最新の情報に更新しています...

コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。


C:\>

もっとも、Windows Update の配信をLAN内で最適化すると言っても、「持つべき者が持たざる者に施す」ことは、「持つべき者」に余計な負荷がかかるわけで、エンドユーザさんには決して好ましい機能ではありません。そのための Windows Update Service (WSUS) なのだから、やはり、構内であってもクライアントに負荷がかかる P2P 配信は、おすすめできるものではありません。



また Windows の AD では OU 単位にポリシー掛けまくるので、エライさんのPCは快適に、そうでないパートさんのPCの配信率を上げる、と言った制御ができません。ま、OUを分ければいいのでしょうが、そうなるとまた管理が煩雑になる。Novell の ZENworks の様な、サードパーティ製のクライアントPC管理ツールを検討した方が速そうです。

「配信の最適化」については上の、Microsoft のドキュメントの中に、エンタープライズでの「お勧め」パラメータの記述があるので、参考にしてみましょう。

上の文書の「配信の最適化」の”ダウンロードモード”には次の6つの設定があります。

  • 0: HTTPのみ -- P2P は使わず、Microsoft の Update サーバーとのみ通信、台数が少ない時はこれですかね。
  • 1: LAN -- Microsoft のアップデートサーバーや WSUS からダウンロードしたものを、同じパブリックアドレス内でBITSを使って P2P 通信。VPN で同じパブリックアドレスを使っている場合はWAN越しの通信もあり。Pro 版はこれらしい。
  • 2: グループ -- AD ドメイン内で P2P 通信をする。同じドメインなら WAN越しの通信も発生するので注意が必要。グループ ID との組み合わせ推奨
  • 3: インターネット -- HOME エディションの標準、同一プライベートLAN、パブリック WAN 間で P2P 通信、見ず知らずの他人と妖しい通信がある。
  • 99: 簡易 -- P2P を使わず WSUS からのみ HTTPダウンロード、急いで配布したいならこれか?
  • 100: バイパス -- P2P を使わず BITS を使って WSUS からのみダウンロード



Windows10 1607 から以前のバージョンにはこの機能がないようなので、下の文書から、管理テンプレート admx をダウンロードして使える様です。

グループ ポリシーを使用して Windows 10 で Windows Update の配信の最適化を構成する方法

まだ Windows update だけなら手段はあるのですが、iPhone の iOS のアップデートなんかも、自宅でやるとアレなので、カイシャの Wifi 経由でやっちゃう輩もいるわけですね。これもバカにならない。

また Windows の OneDrive も、ネットワーク回線に異常なトラフィックをかける極悪機能です。

社内ネットワークは「便利だから使う共有リソース」であって、個人の我儘を満たすものであってはならない。何らかのルールが必要なんですね。

極悪 Windows10 の OneDrive を無効にする

--
グループポリシー:GPO で設定する BITS と、歯(設定)にある「配信の最適化」のどちらが優先されるかは資料が見つかりませんでした。コメントいただけるとありがたいです。






by islandcenter | 2019-11-21 12:04 | Windows | Comments(0)

今回説明するのは SUSE Linux (SLES12sp3) で動作する Bind9 です。

「ネットワークの調子が悪い」

とか言われると真っ先に疑われるのが DNS serviceです。ここでは SUSE Linux Enterprise 11/12 Bind の再起動dig での調査方法について説明します。




- SUSE Linux SLES12 での Bind DNS のサービスの再起動 -

SLE12 以降は、従来の initd の代わりに systemd が使われています。

rcnamed は /etc/init.d/named スクリプトのシンボリックリンクです。

dns2:~ # whereis rcnamed
rcnamed: /usr/sbin/rcnamed
dns2:~ # ls /usr/sbin/rcnamed -al
lrwxrwxrwx 1 root root 17 Jun 18 2018 /usr/sbin/rcnamed -> /etc/init.d/named
dns2:~ #
dns2:~ # ls /etc/init.d/named -l
-rwxr-xr-- 1 root root 10590 Jun 29 2017 /etc/init.d/named
dns2:~ #


SLES12より init から systemd に置き換わりました。

dns2:~ # rcnamed restart
redirecting to systemctl restart named.service

dns2:~ # tail -n10 /var/log/messages
2019-11-08T14:19:33.172180+09:00 dns2 named[10386]: couldn't add command channel ::1#953: address not available
2019-11-08T14:19:33.172264+09:00 dns2 named[10386]: managed-keys-zone: loaded serial 0
2019-11-08T14:19:33.172348+09:00 dns2 named[10386]: zone intra/IN: loaded serial 2018061800
2019-11-08T14:19:33.172521+09:00 dns2 named[10386]: zone i.islandcenter.jp/IN: loaded serial 2019072503
2019-11-08T14:19:33.172606+09:00 dns2 named[10386]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 42
2019-11-08T14:19:33.172689+09:00 dns2 named[10386]: zone localhost/IN: loaded serial 42
2019-11-08T14:19:33.172773+09:00 dns2 named[10386]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42
2019-11-08T14:19:33.172857+09:00 dns2 named[10386]: all zones loaded
2019-11-08T14:19:33.172940+09:00 dns2 named[10386]: running
2019-11-08T14:19:33.173030+09:00 dns2 named[10333]: Starting name server BIND ..done
dns2:~ #


YaST(yast2) では System > Service Manager より "named"自動起動停止再起動ログの確認がマウス操作だけでできます。キーボードをほとんど使わないので、どうしても SUSE Linux 管理者はモノグサになります。

SUSE Linux DNS の動作チェック、ゾーンのメンテナンス_a0056607_15395446.png

- SUSE Linux SLES11 での Bind DNS のサービスの再起動 -

SLE11までは、古い initd で制御されています。

dns3:~ # rcnamed restart
Shutting down name server BIND waiting for named to shut down (28s) done
Starting name server BIND done
dns3:~ #
dns3:~ # ↓ 正しく動いているかどうか、エラーがないか /var/log/messages の tail を確認
dns3:~ #
dns3:~ # tail /var/log/messages
Nov 8 16:09:41 dns3 named[27596]: automatic empty zone: A.E.F.IP6.ARPA
Nov 8 16:09:41 dns3 named[27596]: automatic empty zone: B.E.F.IP6.ARPA
Nov 8 16:09:41 dns3 named[27596]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Nov 8 16:09:41 dns3 named[27596]: command channel listening on 127.0.0.1#953
Nov 8 16:09:41 dns3 named[27596]: the working directory is not writable
Nov 8 16:09:41 dns3 named[27596]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42
Nov 8 16:09:41 dns3 named[27596]: zone intra/IN: loaded serial 2016051901
Nov 8 16:09:41 dns3 named[27596]: zone i.islandcenter.jp/IN: loaded serial 2019072503
Nov 8 16:09:41 dns3 named[27596]: zone localhost/IN: loaded serial 42
Nov 8 16:09:41 dns3 named[27596]: running
dns3:~ #



- dig の基本的な使い方 -

dig は bind の推奨標準ツールです。 Windows で使う場合、dig コマンドは https://www.isc.org/ よりパッケージのバイナリがダウンロードできます。

Windowsでnslookupの代わりにdigコマンドでDNSを調べる(BIND編)


- デフォルトで指定しているDNSがインターネットの host.another.com の名前解決をしているか -

[構文]# dig host.another.com

サンプル

sle15:~ # dig www.google.com
; <<>> DiG 9.11.2 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35459
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:  <---- 問い合わせ内容
;www.google.com. IN A
;; ANSWER SECTION: <---- 回答内容
www.google.com. 25 IN A 172.217.27.68
;; AUTHORITY SECTION:
google.com. 167592 IN NS ns2.google.com.
google.com. 167592 IN NS ns4.google.com.
google.com. 167592 IN NS ns3.google.com.
google.com. 167592 IN NS ns1.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 167592 IN A 216.239.32.10
ns2.google.com. 167592 IN A 216.239.34.10
ns3.google.com. 167592 IN A 216.239.36.10
ns4.google.com. 167592 IN A 216.239.38.10
ns1.google.com. 167592 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 167592 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 167592 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 167592 IN AAAA 2001:4860:4802:38::a
;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Fri Nov 08 15:47:17 JST 2019
;; MSG SIZE rcvd: 307
sle15:~ #

- 明示的にDNSを指定してそのDNSサーバーが正しく動いているか -

原因が、自LANのDNSではなく、大元の ISP の DNS の場合もあります。

[構文]# dig @MyISPsDNS host.another.com

サンプル

sle15~ # dig @192.168.1.3 www.google.com
; <<>> DiG 9.11.2 <<>> @192.168.1.3 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18969
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:  <---- 問い合わせ内容
;www.google.com. IN A
;; ANSWER SECTION: <---- 回答内容
www.google.com. 80 IN A 172.217.25.196
;; AUTHORITY SECTION: <----- ゾーンのマスターは?
com. 172795 IN NS h.gtld-servers.net.
com. 172795 IN NS k.gtld-servers.net.
com. 172795 IN NS m.gtld-servers.net.
com. 172795 IN NS a.gtld-servers.net.
com. 172795 IN NS i.gtld-servers.net.
com. 172795 IN NS c.gtld-servers.net.
com. 172795 IN NS j.gtld-servers.net.
com. 172795 IN NS g.gtld-servers.net.
com. 172795 IN NS d.gtld-servers.net.
com. 172795 IN NS b.gtld-servers.net.
com. 172795 IN NS e.gtld-servers.net.
com. 172795 IN NS l.gtld-servers.net.
com. 172795 IN NS f.gtld-servers.net.
;; ADDITIONAL SECTION:   <---- ゾーンマスターの IP アドレス
a.gtld-servers.net. 172795 IN A 192.5.6.30 <-- A は IpV4
a.gtld-servers.net. 172795 IN AAAA 2001:503:a83e::2:30 <--- AAAA はIpV6
b.gtld-servers.net. 172795 IN A 192.33.14.30
b.gtld-servers.net. 172795 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172795 IN A 192.26.92.30
c.gtld-servers.net. 172795 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172795 IN A 192.31.80.30
d.gtld-servers.net. 172795 IN AAAA 2001:500:856e::30
e.gtld-servers.net. 172795 IN A 192.12.94.30
e.gtld-servers.net. 172795 IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 172795 IN A 192.35.51.30
f.gtld-servers.net. 172795 IN AAAA 2001:503:d414::30
g.gtld-servers.net. 172795 IN A 192.42.93.30
g.gtld-servers.net. 172795 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172795 IN A 192.54.112.30
h.gtld-servers.net. 172795 IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 172795 IN A 192.43.172.30
i.gtld-servers.net. 172795 IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 172795 IN A 192.48.79.30
j.gtld-servers.net. 172795 IN AAAA 2001:502:7094::30
k.gtld-servers.net. 172795 IN A 192.52.178.30
k.gtld-servers.net. 172795 IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 172795 IN A 192.41.162.30
l.gtld-servers.net. 172795 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172795 IN A 192.55.83.30
m.gtld-servers.net. 172795 IN AAAA 2001:501:b1f9::30
;; Query time: 381 msec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Fri Nov 08 15:56:02 JST 2019
;; MSG SIZE rcvd: 855
sle15:~ #



- イントラネット向けDNSは正しく LAN 機器のIPアドレスを返すか -

[構文] # dig @DnsIPorDnsHostName myhost.mynet.com

サンプル

sle15:~ # dig @dns2 quanbe.i.islandcenter.jp

; <<>> DiG 9.11.2 <<>> @dns2 quanbe.i.islandcenter.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20621
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;quanbe.i.islandcenter.jp. IN A

;; ANSWER SECTION:         <---- 回答 ↓
quanbe.i.islandcenter.jp. 172800 IN A 192.168.1.237

;; AUTHORITY SECTION: <--- ゾーンマスター↓
i.islandcenter.jp. 172800 IN NS dns3.i.islandcenter.jp.
i.islandcenter.jp. 172800 IN NS dns2.i.islandcenter.jp.

;; ADDITIONAL SECTION:
dns2.i.islandcenter.jp. 172800 IN A 192.168.1.2
dns3.i.islandcenter.jp. 172800 IN A 192.168.1.3

;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Fri Nov 08 16:18:35 JST 2019
;; MSG SIZE rcvd: 139

sle15:~ #

- DNS のバージョンがバレていないか -

外部にむき出しのDNSは、バージョン固有のバグで悪さをされない様、バージョンを隠しておきます。

[構文] # dig @dns  CHAOS VERSION.BIND TXT

サンプル


sle15:~ # dig @dns2.i.islandcenter.jp CHAOS VERSION.BIND TXT

; <<>> DiG 9.11.2 <<>> @dns2.i.islandcenter.jp CHAOS VERSION.BIND TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46470
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;VERSION.BIND. CH TXT

;; ANSWER SECTION:       <---- バレバレ ↓
VERSION.BIND. 0 CH TXT "9.9.9-P1"

;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Mon Nov 18 14:14:53 JST 2019
;; MSG SIZE rcvd: 88

sle15:~ #

この様にバージョンがバレバレにならない様、yast > Network Services > DNS Server の ”Basic Options” の Option の項目に "Version" を空欄にするか、"unknown" の様な ”任意の文字列” を追加(Add)しておきます。あまり過激な文字列を書いておくと、ある種の「ヤル気」を起こす輩がいますから、穏当にしておくのが無難です。

SUSE Linux DNS の動作チェック、ゾーンのメンテナンス_a0056607_14380201.png
※ SUSE Linux で DNS を YaST で設定した場合、named.conf は /var/lib/named/etc の下に作られます。細かなパラメータの設定は必ず YaST を使う事をお勧めします。

dns2:~ # grep 99 /var/lib/named/etc/named.conf
version "99.99.99";
dns2:~ #


dig を実行するとこんな感じになりました。

sle15:~ # dig @dns2.i.islandcenter.jp CHAOS VERSION.BIND TXT

; <<>> DiG 9.11.2 <<>> @dns2.i.islandcenter.jp CHAOS VERSION.BIND TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18773
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;VERSION.BIND. CH TXT

;; ANSWER SECTION  <---- バージョンを誤魔化した ↓
VERSION.BIND. 0 CH TXT "99.99.99"

;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Mon Nov 18 14:31:52 JST 2019
;; MSG SIZE rcvd: 88

sle15:~ #





- SUSE Linux での DNS ゾーンのレコードメンテナンス -

SUSE Linux (SLES/openSUSE) では yast を使って、ゾーンとレコードのメンテナンスをします。Bind DNSのインストールから初期設定、僅かな変更などのメンテナンスには間違えがなく便利です。

dns2:~ # yast

テキスト版 yast > Network Services > DNS server へ TAB キーで移動し、DNS Zones から、ゾーンファイルを Edit します。

SUSE Linux DNS の動作チェック、ゾーンのメンテナンス_a0056607_17311881.png

GUI版はこのような感じです。

dns2:~ # yast2 &

GUI版 yast2 > Network Services > DNS server

SUSE Linux DNS の動作チェック、ゾーンのメンテナンス_a0056607_17315679.png

OK ボタンを押すと、自動的に named がリスタートします。

ただし、構文や設定、 /etc/resolve.conf に問題があると、保存して再起動は行われません。設定内容を確認して、再設定します。


- メンドクサイのでゾーンファイルをまとめてテキストエディタで書き換える -

yastでイチイチ、レコードのメンテなんてやってられねぇよ、LibreOFfice Calc で作った100 レコード位、csv で一発で追加したいんだ、という時はテキストエディタで、ゾーンファイルを編集すると良いでしょう。

# vi /var/lib/named/master/MYZONE


# gedit /var/lib/named/master/MYZONE &

でまとめて、ゾーンの変更、シリアル番号のメンテナンスを行います。

SUSE Linux DNS の動作チェック、ゾーンのメンテナンス_a0056607_18071518.png

ゾーンファイルを保存したら

# rndc reload

を実行するか、影響が小さい場合 # rcnamed restart します。

dns2:~ # rndc reload
server reload successful
dns2:~ #


- そのIPはキャッシュされてる? -

DNSが正しくホスト情報をキャッシュしているかどうかは rndc dumpdb コマンドでダンプして確認できます。キャッシュをダンプした後、/var/lib/named/log/named_dump.db の内容を確認します。


dns2:~ # rndc dumpdb
dns2:~ # grep suse.com /var/lib/named/log/named_dump.db
3090 PTR suse.com.gr.
3090 PTR suse.com.pl.
3090 PTR suse.com.tr.
suse.com. 552 A 130.57.66.19
dns2:~ #


--
速攻 1分で DNS on SUSE12 by YaST(YaST で DNS のインストール)

SUSE Linux 10 : YaST で イントラネットDNS サーバを設定

SUSE Linux で Dynamic DNS(DDNS) を作る








by islandcenter | 2019-11-09 18:00 | SUSE | Comments(0)

- ホスト名は「花鳥風月」 -

数十年前に初めて、お客さんのネットワークシステムを構築したとき

「コンピューター名どうしましょ」

となった時に

「ま、花鳥風月でいいんじゃないっすか?」

と申し上げた事がありました。コンピュータ、ホスト名の命名規則のお話です。

英国軍艦の装甲艦コルベットには「フラワー級コルベット」というのがあり、「立派な海軍の男がパンジー(三色スミレ、男色者の隠語)なんかぁで戦えるか」というくだりが、よく英国の海洋冒険小説に出てきます。でもこの「花の名前」のフラワー級コルベット。使い勝手の悪さと居住性の悪さにも関わらず、構造が簡素で大量生産できたため、大戦中の大西洋でのドイツの潜水艦との地味で退屈で危険な戦いでは大活躍したんです。

※ちなみに英国海軍の場合は、必ず正式名に HMS が付きます。

そこで戦後に初めてアメリカの GM が作った小型スポーツカーにつけられた名前が「コルベット」。

旧日本海軍では軍艦の命名規則は、律令時代の「国名」が戦艦、「河川名」が巡洋艦。空母は「喜ばしい架空の鳥の名前」駆逐艦は「洋上の自然現象」と決まっていたようです。


ま、余談はここまで。「花」はこんなものですが、「鳥」は何だかメンド臭そう。「月」は moon 以外に見つからず、じゃ「風」の名前はどうなんだろうと調べたら、結構、コンパクトで魅力的な風の名前(地方風)の語には蠱惑的な単語が結構あるんですね。

特にヨーロッパ古代から中世史に興味があったので、地中海の船乗りに関する「風の名前」「船乗り用語」「船乗りが嫌がるもの」など地中海の船乗りが使う語彙が豊富になりました。という事で、ウチのコンピュータや Wifi の SSID なんかには、いいも悪いも含めて地中海の船乗りになじみのある自然現象などの名詞が使われています。

ちなみにSSIDの文字列の最大長は32バイトだそうです。そういえば、電車の中でスマートフォンのSSIDを変えて、見知らぬ他人と会話する、という話が一時期話題になったように、2バイト文字も使えますが、お勧めはできません。


WifiのSSIDで隣人とコミュニケーションしよう

軍艦の命名規則には、それぞれお国柄があるようです。特に海軍国である英国艦艇の補助艦には、フラワー級だけではなくリバー級とかタウン級なんて命名規則がありました。アメリカ海軍の場合 USS で始まり、州の名前とか政治家とか、頑張って戦死した二等水兵の名前とか。

ま、そのうち風の名前のセンスに苦しんで、コンピューターのホスト名には北欧の物語に出てくる妖精の名前をかたっぱしから付ける様になりました。英国空軍の機種名やエンジンの名前によく使われています。英国人のセンスですね。名前を見るとユニークでインパクトがあるものをよく見ます。


- あわせて読みたい -

ユーザアカウント名は8文字以内にすべきか?ユーザの命名規則の理由


- よくある命名規則 -

社内ネットワークが構築され始めたころ、良く客先で見かけた命名規則が「星の名前」や「ギリシャ神話の神」をルールにしているところが多かった。これは単純に使いやすいのと、ゲームの主人公なんかによく使われるんですね。どうも、「天体名」は人気があるそうです。

でもその名前の由来を調べたら、縁起の悪いものもあるので、気を付けたいところです。こういった命名規則を作った趣味人の命名規則。

例えば、片っ端から「ガンダム名」にしてしまうと、

「シャーが死んだ」とか「ザクにバグがある」「ホワイトベースが堕ちた」

なんていう楽しい会話ができます。私にはそんな趣味ありませんけどね。まぁ”ウルトラマンに出てくる怪獣の名前”とか、ま、やめときましょう。最後には倒されるンですから...

フォネティックコードを使うのも一つのアイディアです。短くて誤読、認識性が高い。さすが軍隊の通信に使われるだけあってよく考えてある。

ですが、欠点はアルファベットの26種類しかない事。


明確で単純ですがあまり人気はありません。

自社の製品名、自社のサービス名を使うケースもあるのですが「xxx(自社製品名)が死んでいる」とか「xxxがおかしい」なんて会話が飛び交うと、社内で変な誤解を生んでしまいます。あまり流行らないようですね。

また、プロジェクト名などを付けると、後でそのプロジェクトがポシャって、プロジェクト名が付いたホストが残ると淋しいものです。

また、いくら花鳥風月でも "chrysanthemum" (菊)なんて言うような、舌を噛むような難読名は命名規則には避けるべきでしょう。私なら「薔薇」って書けません。

- Mnemonic Word listによる命名規則 -


ここでリストアップされた単語は、アクセントや綴りに重複や読み間違えを生みにくい4~7文字の単語のリストです。1626語ありますから選択は自由です。命名規則に関わらず、任意にコンピュータ名に付けたい時には参考になるリストです。

- ガチガチの命名規則 -

これは、どこの現場でも良く見る命名規則です。通し番号は最低2桁、できれば3桁の通し番号を付けます。この方法のメリットは、 # grep | sort した時に見やすい事です。

例えば

  • PRNnnn - プリンタ
  • WPCnnn - Windows 端末
  • DNSnnn - DNS サーバー
  • APSnnn - アプリケーションサーバ
  • FSVnnn - ファイルサーバー

ただ、これだとユーザや管理者から即時認識できないので、[SRV+nnn+PANSY]の様な、機能+機械的な数字+愛称はいいアイディアだと思います。愛称があると判りやすいし、Nattou とか Umeboshi なんてミヤビな名前があれば愛着も沸くものです。でも、自分のPC名が「鶏レバー」だったら愛着は湧きませんが....

実際、意味のない文字列+数字の場合は担当者はさておき、協力会社の担当者さんやエンドユーザは即座に識別できないので、何等かの愛称があると識別性が高いという事になります。

ホスト名は「記号化」してしまうと、認識度が低くなり、伝達性を損ないミスタイプを誘います。一意にするための"記号+理解可能な単語"の組み合わせが良いだろうと思いますけどね。

まぁ Linux の場合、ホスト名が影響するのは Samba の Netbios 名程度(設定でホスト名とは違う名前を付けられる)で、後は DNS 名ですから、 DNS 名の命名規則と異なる機械的な命名方法でも構わないでしょう。

- PC端末の命名規則 -

「NetBiosの都合」というややこしい制限があるので、それぞれエンドユーザさんが使うPC一台一台には工夫が必要でしょうね。クライアントPCはネットワーク上では、将棋の「歩」です。それぞれの足軽は「姓」を名乗らない「歩」なので「貫太郎」とか「強右衛門」の様なユニークな名前を与得る場合もある訳です。私も自分のコンピュータ名を「タマちゃん」と呼んでいた時期がありました。

英米の海軍でもこれらの「歩」の様な哨戒艇などには PT-109 とか MTBnnn の様な、記号+通し番号が正式名称だったのですが、実部隊の現場ではお互いを「愛称」や「コールサイン」で識別していたようです。

所詮「足軽」なので、端末は3~4年で入れ替わってしまいます。永続的にホスト名やIPアドレスが使われる、DNSやメールサーバーの様に厳密にする必要はありません。

端末のホスト名は、アセット管理とヘルプデスク、ワークグループの使い勝手を優先目的とします。

「PC+導入年度下二けた+シリアル番号(SKU)下4けた+数バイトの認識名」とかも良いでしょうか。

認識名としては、3バイトの空港コードのように短くて聞き間違えがなく認識性が高いものが良いでしょう。「WPC+3桁の通し番号+3桁の空港コード(HND-羽田,CTS-千歳,NRT-成田)」などです。桁が揃った一意の綴り3文字なので、応用が利きそうです。


修理でマザーボードを交換したとか、USBドングルアダプタで有線化した場合はMACアドレスが変わります。IP や MACアドレス、利用者名などを使うと何れ破綻します。

ー 数字は16進数を使う ー

例えば通し番号を数字二けたとすると 00から99 までの 100 個の個体を識別できるわけですが、これを16進数にすれば 00 ~ FF まで二けたで 256 個の個体を識別できます。 256 はクラスCのひとセグメントですから、大体の中小組織では十分な数です。

3桁 000 ~ FFF を使うと全部で 4096 の識別個体を作れます。中堅企業以上では、これで十分ですね。

ただし3桁の先頭文字にアルファベットはつかわないのがいいでしょう。000 ~ 9FF までです。 

- OS、機種、機能、設置部署、場所、企業名は使わない -

OS 種別を命名規則に取り入れると、例えばWindows で動いていたサービスを Linux に置き換えた場合はちょっと面倒なことになります。

また機器のベンダー名や型番を命名規則に使うと機器のリプレースの時に面倒な事になります。

設置したオフィスや部門の所在地を使うと、オフィスが移転したときに問題となります。

nnnn の通し番号に IP アドレスを指定している所がありました。リーズナブルなようで、後でハードウェアのリプレースで問題となります。あまり IP や Mac アドレスをコンピュータのホスト名に使うべきではないと思います。仮想化時代なのでいずれ破綻します。

また、「会社名」も避けるべきです。会社名なんてしょっちゅう変わるものなんですね。Windows ドメイン名に「会社名」を付けてすぐに買収されて、泣く泣くドメインを再構築したお客さんがありました。

- 社内向けドメイン名、アクティブディレクトリ(AD)の命名規則 -

「社内向けドメイン?」何ンか変だな。まぁ Microsoft Active Directory を始めとして、イントラネット向けのドメイン名なんですが、

".local" は禁忌ドメイン名です。絶対に使ってはいけません。間違っても AD では ”mycompany.local” で作ると問題がありそうです。Google 大魔神の投票結果なので、探してみてください。

そもそも、"mycompany" という、アナタの所属する組織名は移ろいやすいのですね。ローカルネットワークで使うFQDNに含まれる、ドメイン名、ホスト名はもう少し真面目に考えてもいいのではないのかなと思います。

例えばですよ、あくまでも例えば。

社内向けのDNSのADのローカルドメイン名に local.google.com なんてオレオレドメイン付けてしまって、prn01.local.google.com に印刷してしまった場合、オレオレじゃない本物の Google さんの prn01.local.google.com から極秘文書がジーコジーコとプリントアウトされる可能性があるのですね。ま、考えにくいけど。

だから、社内向けのドメイン名は、インターネットにおいてユニークで唯一無二で、しかも将来においては他人に使われない、変更される可能性がないドメイン名を指定すべきでしょう。会社名.com なんかはよした方がいい。どうせ会社名なんて、いつCIされて変わってしまうかわからないのです。その後 Windows ドメイン名を変えてしまうのは恐ろしく手間がかかる作業になってしまうでしょう。これは社内ドメインの工夫。アクティブディレクトリの命名規則のポイントですね。

だから、Active Directory のドメイン名に組織名はつかうべきではないと思うのですが、唯一無二という事なら、思い切って”花鳥風月”の一般名で公式な名詞をオレオレなインターネットドメインを取ってしまい、そのサブドメインをイントラネット用ドメイン名にしてしまえば、社名が変わっても将来にわたって使えるわけですね。.NET とか .SITE とかはかなり安く取得できるので、例えば pansy.site なんかを1円で取得して fsv001plum.ad01.pansy.site というドメインやFQDNを AD や社内向けサービスの名称にするというのも思い切った手段です。これなら会社名が変わろうが、組織が改変されたり、引っ越しても使い続けられます。
zzzzzzzz.com みたいな単純なドメインでも格安です。



オレオレドメインがもたらす当たり前な問題


- ドメイン名の命名規則からの HOSTNAME の制限 -

FQDNではゾーン名を含め1バイトから最大253文字です。FQDN は hostname.mydomain.com となりますが、ドットの間の「ラベル」に使われる最大文字数は63文字です。従って、「コンピュータのホスト名」の公約数は

1から63文字以内で、かつFQDNも含めて253文字に収まること」

がまず条件になります。SUSE Linux では getconf コマンドで確認できます。Linux のホスト名は最大で64バイトですが、最後は Null なので63バイトという事です。

suse15:~ # getconf -a | grep HOST
HOST_NAME_MAX 64
suse15:~ #

ラベルに使われる文字は、英数字とハイフン、ただしハイフンは「ラベルの先頭と末尾」には使えません。基本的には使わないのが無難。 Windows では "_"(アンダースコア)も利用可能ですが、他との公約数として"_"も Windows では使わない方が無難でしょう。

この63文字の文字制限は hostname コマンドのマニュアルには記載がないのですが、 limit.h に定義されているそうです。

63文字以内です。

ドメイン名の構成

ただし、いくら 253 文字使えるとは言え、長すぎる FQDN 名は避けるべきでしょう。解りやすく、短くが原則です。そもそも文字列が長いと、タイプミスしやすいし、メンドクサイものです。


重要なのは、命名規則で使える文字種、最大、最小文字数などは、&&条件で最小公約数で決める事です。Windows や Netbios で許されても、FQDN の条件に合わない命名規則は、好ましいことではありません。Windows から、他のシステムに移行した場合に問題となる可能性があります。逆に 63 文字のホスト名が付いたシステムを Windows に移植したら、これも問題が出てきます。



- Windows におけるコンピュータ名の規則 -

Windows におけるコンピュータ名も同じく63文字の様です。

Enter your computer name

ただし15バイト以上の「コンピュータ名」はトランケート(丸められる)ようなので、15バイト以内が無難なようです。

なぜなら、"Netbios" という20世紀に作られたDOS時代のレガシーなシステムの残骸を引きずっていて、 FQDN での制限である63バイトより、短い「Windows は15バイトのコンピュータ名」をつけた方が良い様ですね。

しかもNetbios では特殊文字のドットも可能。

勿論、ドット(ピリオド)はFQDNのラベルの区切りになるので、NetBiosでは許されてもコンピュータ名で使うべきではありません。だからADの命名規則では禁止されているという矛盾。また RFC では "_" (アンダースコア)は積極的に推奨されていないようなので、Windows では認められても使うべきではないようです。
 
Active Directory におけるコンピューター、ドメイン、サイト、および OU の名前付け規則

この Netbios 名の制限は、当然 Linux/Unix 系OSで使われる Samba にも影響しますから、 Linux で SMB/CIFS を使う場合は Linux のホスト名とは別に Netbios 名も英数字 15 バイトに収めるのが無難である、ということになります。もっとも BIND なんかで名前解決するなら問題ありませんが、Windows ガチガチなネットワークの場合、制限は

「NetBiosに従え」

ということになりそうです。


- 重要なのは文書化しておく事 -

大体、コンピュータのホスト名の命名規則というのは、管理している人間の趣味で作られるものです。まぁほとんどはその場の思い付きなんですね。

例えば、先頭6バイトの文字規則(ナンバリング規)+愛称名の利用可能なリスト

命名規則の原則は、文書化と認証。必ず文書化して、担当マネージャーのハンコをもらっておく事です。

- まとめ -

  • grep | sort したり、正規表現での検索、スプレッドシートでソートしやすい様、先頭 4 ~ 6 バイトには特殊記号のない規則性を持たせる
  • 基本は英数字のみ15バイト以内に抑える。もっとも短い方がいいのは勿論。
  • 特殊文字は "-" ハイフン以外使わない、と言うより正規表現で特殊処理が必要な文字なので "-" , ”_” の利用も控える。
  • 後半部には規則性のある任意のニンゲンが認識可能な文字を付け加えても構わないが、長い文字列は避ける。
  • 数字で始まるホスト名は避ける。
  • オフィスのストリート名、部署名、社名など、将来も使い続ける可能性がない略字、語句は使わない。
  • 恥ずかしい名前や、難読性なもの、「そういう面白い趣味か」といった名前は避ける。
  • IP アドレスや Mac アドレスの様な変化する可能性のある命名規則はそのうち破綻する。
  • 愛称のストックは常にためておく事。空港コード、フォネティックコードの様なリストを決めておく。

まぁ、RFC1178 に、べき論べからず論があるので、一読しておくことです。

Choosing a Name for Your Computer

202x 年 Windows 最期の日






by islandcenter | 2019-11-04 13:16 | プライベートクラウド | Comments(0)