いますぐ実践! Linuxシステム管理

[バックナンバーのトップへ] [Linux システム管理のトップへ]


いますぐ実践! Linux システム管理 / Vol.149 / 読者数:1280名

こんばんは、うすだです。

前回の冒頭で、レンタルサーバを切替える云々というお話を書きました。

11月いっぱいで契約が切れてしまうので、大慌てで作業を進めたところ、 思ったより早く移行できました。(もちろん、間に合いました!)

いまのところ、サーバがダウンしたとか、 サービスが変だといった現象は発生していません。 どことなしかスパムが減ったような気すらします。

スパムといえば、今、会社のメールサーバが、スパムの処理に大変忙しいようで、 メールがすごく遅延して届きます。ひどいときは1日遅れます。

先日も、お客さまから、打合せの時間の変更依頼のメールが送られていたのですが、 ぜんぜん届かず、変更前の時間に行ってしまいました。

幸い、遅いほうの変更だったため、すっぽかすことはなかったのですが、 逆だったら、社会人として、ちとまずい結果になっていたところです。

こんなとき、小手先的な対応を試す絶好の機会だ! …という気が、 個人的にはするのですが、残念ながらといいますか幸いといいますか、 わたしは管理者ではないので、手を出すことができません。

しかし、備えあれば憂いなしです。自分のサーバで問題が起こったらなにを試せるか、 今のうちからリストアップしておこうと思います。

それが杞憂に終わることを期待しつつ、今回も、はりきってまいります!

今回のお題 - NSD でセカンダリサーバを構築する

前回、NSD というネームサーバ(コンテンツサーバ)を、 インストールして設定して動かすところまでを、ご紹介しました。

Vol.148 - BIND じゃないネームサーバ - NSD を使ってみる
http://www.usupi.org/sysad/148.html

今回はその続きで、セカンダリサーバの役割を担わせたいと思います。

ネームサーバが1台だけですと、その1台がとち狂ってしまった際に、 情報を提供できなくなってしまいます。そう考えますと、 セカンダリサーバを構築して、複数のサーバで運営するという方法は、 しごくまっとうな考えではないかと思います。

…言い訳と当り前感が交錯した前振りですが、気にせずに進みましょう。


すでに、kuri.info のプライマリサーバが、BIND によって稼働していると仮定して、 NSD にセカンダリサーバをやらせてみようと思います。

以降では、プライマリサーバの IPアドレスを 192.168.1.1、 セカンダリサーバの IPアドレスを 192.168.1.2 として、設定例を示していきます。

まず、プライマリサーバ側で、セカンダリサーバからのゾーン転送の許可を追加します。 たとえば、以下のように named.conf を変更します。

  zone "kuri.info" {
      type master;
      file "kuri.info.zone";
      allow-transfer { 192.168.1.2; };  // ←追加(変更)はこれです
  };

そして、named を再起動します。

  # /etc/init.d/named restart

次に、セカンダリサーバの設定を行います。
NSD がインストールされていなければ、前回の手順通りに入れます。
そして、以下の内容の nsd.conf を作成します。

  zone:
      name: "kuri.info"
      zonefile: "kuri.info.zone"
      allow-notify: 192.168.1.1 NOKEY
      allow-notify: 127.0.0.1 NOKEY
      request-xfr: 192.168.1.1 NOKEY

セカンダリサーバですので、kuri.info.zone ファイルは不要です。
allow-notify: で、192.168.1.1 からの NOTIFY を受け入れます。
ちなみに、次の行で 127.0.0.1 からの NOTIFY も受け入れるのは、 自ら nsdc update を実行して、更新を通知できるようにするためです。
そして、ゾーン転送を用いて 192.168.1.1 から情報を入手することを、 request-xfr: で指定しています。

nsd.conf を記述したら、NSD を起動します。

  # /etc/init.d/nsd start

問題なければ、以下のように、 プライマリサーバから情報を入手しました的なメッセージが、syslog に出力されます。

  # tail /var/log/messages
  ...中略...
  年月日 マシン名 nsd[PID]: Zone kuri.info serial 0 is updated to \
  2008111601.

さて、それでは、プライマリサーバ上で情報を更新したとき、 セカンダリサーバが気づくかどうか、確かめてみましょう。

まずは、プライマリサーバ上の、kuri.info の情報を更新します。
(少なくとも、シリアル番号は必ず更新(大きく)してください。)

  @ IN SOA ns1.kuri.info. postmaster.kuri.info. (
      2008120701 10800 3600 604800 86400)   ; シリアル番号を更新!

  @          IN   NS     ns1.kuri.info.
             IN   NS     ns2.kuri.info.
  ...中略...
  www        IN   A      192.168.1.4
  usohost    IN   A      192.168.1.254      ; てきとうに追加

更新したことを named に伝えます。

  # /etc/init.d/named reload

そうしましたら、セカンダリサーバの syslog を確認します。

  # tail /var/log/messages
  ...中略...
  年月日 マシン名 nsd[PID]: Zone kuri.info serial 2008111601 is \
  updated to 2008120701.

このように、シリアル番号が更新されていたら、成功です。
念のため、dig コマンドでも確認してみましょう。

  $ dig @192.168.1.2 usohost.kuri.info.
  ...前略...

  ;; ANSWER SECTION:
  usohost.kuri.info.      86400   IN      A       192.168.1.254

  ...後略...

てきとうに追加したアドレスの情報が、無事得られました。
SOA を問い合わせて、シリアル番号を確認してもよいと思います。

  $ dig @192.168.1.2 kuri.info. soa
  ...前略...

  ;; ANSWER SECTION:
  kuri.info.              86400   IN      SOA     dns.kuri.info. \
  postmaster.kuri.info. 2008120701 10800 3600 604800 86400

  ...後略...

以上、NSD でセカンダリサーバを仕立てあげる方法を、ご紹介しました。

ところで、なんでプライマリサーバが BIND なんだ? という疑問をお持ちの貴兄がいらっしゃったのではないかと思います。

正直に申し上げますと、プライマリサーバを NSD にしたところ、 更新がうまく伝わらない現象が発生してしまいました。
結局、解決方法がわからなかったため、BIND にご登場いただきました。
けれども、せっかくですので、一部始終をここに記しておきます。

NSD のプライマリサーバの設定を、たとえば以下のようにすれば、 最初はセカンダリサーバが情報をまるっと仕入れてくれます。

  zone:
      name: "kuri.info"
      zonefile: "kuri.info.zone"
      notify: 192.168.1.2 NOKEY
      provide-xfr: 192.168.1.2 NOKEY

しかし、kuri.info.zone を更新し、それを通知してもらおうとすると、 以下のように叱られてしまいます。
(IXFR に対応していないためのようですが、同じ NSD なのになぜ…?)

  # tail /var/log/messages
  ...中略...
  年月日 マシン名 nsd[PID]: xfrd: zone kuri.info received error \
  code NOT IMPL from 192.168.1.1

自動的に更新はされませんが、セカンダリサーバで、 nsd-xfer コマンドを用いてゾーン転送を行い、データベースを再構築すれば、 更新することは可能です。

  # nsd-xfer -z kuri.info -f /etc/nsd/kuri.info.zone 192.168.1.1
  # /etc/init.d/nsd rebuild
  # /etc/init.d/nsd reload

設定か手順を誤っている可能性が高そうです。判明次第ご連絡します。

 

それから、読者のかたから、djbdns だともっと軽いよ、 というご連絡をいただきました。いただいた ps の結果をみますと、たしかに軽いです。

  tinydns コンテンツサーバ
    PID   VSZ  RSS COMMAND
  16997  2408  284 supervise tinydns
  17011  2660  348 tinydns

  dnscache キャッシュサーバ
    PID   VSZ  RSS COMMAND
  16995  2408  284 supervise dnscache
  17012  3944 1364 dnscache

  dnslog ログ出力
    PID   VSZ  RSS COMMAND
  17004  2552  344 multilog t ./main
  17013  2420  272 multilog t ./main

VSZ は仮想メモリのサイズですので、テキストなど他と共有している分も含まれます。 かたや、RSS は実際に使用している実メモリです。
tinydns の RSS の量が、すばらしく小さいですね。

djbdns は、セキュリティの強さだけでなく、 コンパクトさでも他を圧倒しているのだなあと思いました。
使うにはちょっとコツ(?)が必要ですが、興味のあるかたは、一度お試しくださいませ。

djbdns: Domain Name System tools
http://cr.yp.to/djbdns.html
djbdns (日本語)
http://djbdns.qmail.jp/

宿題の答え

前回の宿題は、

  キャッシュサーバとコンテンツサーバを同じマシンで動かしましょう。

でした。

普通に考えますと、キャッシュサーバもコンテンツサーバも、 同じポート番号(DNS なので 53番ですね)を使いますので、 かち合ってしまいます。
ですので、かち合わないよう、listen するIPアドレスを分ける、 という方法が考えられます。

それでは、前提条件を以下のようにして、設定を試みます。

  キャッシュサーバ: 192.168.1.254 (Unbound)
  コンテンツサーバ: 192.168.1.1   (NSD)

 

まず、複数(上記の2つ)のIPアドレスを扱えるようにします。
もともとが 192.168.1.254 だったら 192.168.1.1 を、逆だったら逆を、 設定します。以下は、前者の場合の実行例です。
(恒久的に設定するには、/etc/sysconfig/network-scripts/ifcfg-eth0:0 を作成してください。詳細は…ごめんなさい略します。)

  # ifconfig eth0:0 192.168.1.1 up

そして、NSD と Unbound を止めておきます。(実際はどちらかですね)

  # /etc/init.d/unbound stop
  # /etc/init.d/nsd stop

 

次に、Unbound の設定です。
現状では、おそらく、以下のように、なんでもウェルカムになっていると思われます。 (記述がなければ localhost のみです。)

  interface: 0.0.0.0

これを、192.168.1.254 に限定します。
たとえば、unbound.conf の該当する行を、以下に変更します。

  interface: 192.168.1.254

そして、unbound を起動します。

  # /etc/init.d/unbound start

以下のように、192.168.1.254 になったことを確認します。

  # netstat -tuan | grep ':53 '
  tcp     0     0 192.168.1.254:53       0.0.0.0:*          LISTEN
  udp     0     0 192.168.1.254:53       0.0.0.0:*

便宜上、localhost もキャッシュサーバが待ち受ける必要があれば、 以下のように interface: を複数設定してください。

  interface: 192.168.1.254
  interface: 127.0.0.1

 

次に、NSD の設定です。
server: の中に ip-address: という設定があれば、そこを変更します。
なければ、なんでもウェルカム状態ですので、追加してください。

  server:
      ip-address: 192.168.1.1

そして、同様に NSD を起動します。

  # /etc/init.d/nsd start

先ほどと同様に、listen している状態を確認します。

  # netstat -tuan | grep ':53 '
  tcp     0     0 192.168.1.1:53         0.0.0.0:*          LISTEN
  tcp     0     0 192.168.1.254:53       0.0.0.0:*          LISTEN
  udp     0     0 192.168.1.1:53         0.0.0.0:*
  udp     0     0 192.168.1.254:53       0.0.0.0:*

めでたく共存できました。

ちなみに、コンテンツサーバの情報を、 キャッシュサーバが問い合わせるようにするには、 以下の設定を Unbound に追加する必要があります。
(コンテンツサーバが公式なネームサーバであれば、不要です。)

  stub-zone:
      name: "kuri.info"
      stub-addr: 192.168.1.1

今回の宿題

今回の宿題は、

  プライマリサーバで、シリアル番号を更新せずに情報を変更した場合、
  セカンダリサーバの情報がどうなるか確認しましょう。

です。

シリアル番号を更新せずに情報を変更したとき、 セカンダリサーバにその変更が伝わるのかどうかなどを、 実際に確認してみてください。
(お試し環境があれば、やってみるだけですよね。あれば…ですが。)

あとがき

あまり大きな声では言えないのですが、いま、Xen にはまっています。

Xen
http://www.xen.org/

「はまっている」と一言で言ってしまいましたが、実際には、 わたしの中では2つの意味を持っています。

ひとつは、お仕事でやっているのですが、 わからないことだらけで途方に暮れて困っている、という悪いほうの意味です。
Xen を使ってなにかを構築するのではなく、 Xen 自体をどうかするという課題をあたえられたのですが、中身の情報があまりなく、 ソースコードとにらめっこしては変な汗(?)をかく、という日々が続いております。

そしてもうひとつは、調べていくといろいろ興味深く、こりゃ面白いぞ、 というよいほうの意味です。

Xen では、自分が仮想化されているという前提で、ゲストOSが動きます。
当然、仮想化されていることを知らずにエミュレート実行されるよりも、 高速に動作します。また、ホストや他のゲストOSと協調したりなど、 Xen に特化した面白いことができるのでは…と勝手に思っています。

というわけで、この2つが、頭の中で常にせめぎあっています。
しかし、やはり、打合せ前になると、前者の悪いほうが強くなり、 精神的に余裕がなくなります。いっぱいいっぱい状態というやつです。

とはいえ、せっぱつまればつまるほど、柔軟に考えられなくなります。
せっかく興味深い課題をあたえてもらったのですから、もう少し気持ちに余裕を持って、 課題を楽しみたいなあと思っております。
(どうすりゃそう思えるのか、という根本的な問題は残ったままだったりしますが…。)

Xen は、意外といろんな環境で動きますし、とてもすぐれたものだと思いますので、 ご紹介したいネタのひとつに昇格しつつあります。
ただ、けっこうなボリュームですし、 いろんなディストリビューションで試す必要もありますので、 まとめきれるかどうか、悩ましいところです。
すごーく気長に待っていただけますと、幸いです。
(是非取り上げて! という興味津々な貴兄、 あるいはせっぱつまった貴兄がいらっしゃいましたら、前向きに検討しますので、 ご連絡を…。)

 

さて、いつのまにかもう12月、2008年ももうすぐ終わりですね。
お察しの通り、お仕事にあっぷあっぷ状態ということもあり、今年の発行は、 今回の149号を最後にしたいと思います。

ということは、次回は、来年の1月4日になるはずですが…。 下記で11日と書いたということは、1月の発行も1回だけにするつもりかよ、 という魂胆がみえみえですね…。(も、申し訳ございません…)

 

今回も、ここまで読んでいただき、ありがとうございました。
次回は、来年の 1月11日(日) 頃に、お会いしましょう!
それでは、みなさま、よいお年を! (ちょっと早いですが…)

 

「いますぐ実践! Linux システム管理」の解除は、以下からできます。
http://www.usupi.org/sysad/ (まぐまぐ ID:149633)

バックナンバーは、こちらにほぼ全部そろっています。
http://www.usupi.org/sysad/backno.html

「栗日記」−シス管は滞っても、栗の絵は描きつづけます。変ですね…。
http://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
http://usupi.org/k/ (モバイル栗日記)


[バックナンバーのトップへ] [Linux システム管理のトップへ]

トップ

バックナンバー
    [日付順] [目的別]

プロフィール

▼ リンク

独学Linux
Linuxデスクトップ環境に関する情報が満載です。 メルマガもありますよ。
Server World
CentOS 6をサーバとしたときの設定例が、これでもかというくらいたくさん載っています。 CentOS以外のディストリビューション(Fedora, Ubuntu)も充実しています。
LINUXで自宅サーバーを構築・導入(Fedora9)
Fedora9のインストールの仕方から管理方法まで、詳しく載っています。 SearchManには情報がもりだくさんです。
マロンくん.NET
〜サーバ管理者への道〜
Linuxをサーバとして使用するための、いろいろな設定方法が載っています。 マロンくんもかわいいです。 なんといっても、マロンくんという名前がいいですね!!
日経Linux
今や数少なくなってしまったLinuxの雑誌。ニュースやガイドもあります。
Linux Square − @IT
@ITが提供する、Linux の情報が満載。 載っていない設定方法はないんじゃないでしょうか。
gihyo.jp…技術評論社
Linuxに限らず様々な技術情報が満載のサイト。 SoftwareDesign誌も、 ソフトウェア技術者は必見です。
SourceForge.JP Magazine
Linux に限らず、オープンソース関連の記事が網羅されています。
ITmediaエンタープライズ:Linux Tips 一覧
Tips というより FAQ 集でしょうか。わからないことがあれば覗きましょう。
IBM developerWorks : Linux
開発者向けですが、勉強になりますよ。
Yahoo!ニュース - Linux
Yahoo!のLinuxに関するニュース一覧です。
栗日記
システム管理とかと全然関係ありませんが、毎日栗の絵を描いています。
システム管理につかれちゃったとき、癒されたいときに、ご覧ください。:-)
WEB RANKING - PC関連
ランキングに参加してみました。押してやってください。

▼ 作ってみました

Add to Google

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本