その4 自宅サーバ構築の第一歩

2003.01.31

会社でパソコンを買ったひとがいて、その人に自宅でネットに繋ぐののプロバイダはどこがいいのか相談された。前提はADSL。局舎までは1.5km くらい。いいなぁ(笑)。フレッツとYahoo!BBのエリアらしいんだけど、本人はフレッツ前提でプロバイダを考えているようだ。っていうか、 Yahoo!BBははなから選択肢に入っていないらしい。値段を考えるとYahoo!BBが一番安くあがるだろうなぁとは思ったが、自分のトラブル経験を 考えると、お薦めできないことにたっぷりの自信を持っているわけで、実際、お薦めしなかった(笑)。しかし、今の時代、最初っからADSLでメガクラスの 接続をするんだなぁとある意味感動してしまった。2400bpsのモデムでスタートした身としては3Mbpsの実効速度が出る常時接続回線というのは夢の ような世界に思われるけど、その人にしてみるとそれがいきなりの現実なんだなぁ。

それはさておき、ルータでDMZの設定ができる以上、家庭内ローカルサーバを立てないわけにはいかない(笑)。というわけで、手元にある予備機の ノートPC(AL-N2T515J・MMX Pentium 150MHz・メモリ32MB・ハードディスク1.5GB)にLinuxをインストールすることにする。

この機械、LANカードが付いていないし、CD-ROMも付いていない。とりえる手段はYahoo!BBの力でftp経由のネットワークインストールだけ。というわけで、PCMCIAの無線LANを利用してネットワークインストールできるディストリビューションを探す。

まず、一番使いなれているTurboLinuxだが、これはだめ。というわけで、いろいろと探してみるとRedHatとKondaraが大丈夫らし い。とはいえ、Kondaraはすでに解散しているディストリなわけで、これではお話にならない。というわけで、選択肢はRedHatに絞られる。

そんなわけで、RedHatのftpサイトから起動ディスクイメージ(pcmcia.img)を落としてrawritewinでディスクを作製。そ こからブートしてインストールに。インストールもとのftpサイトには、ftp.kddlabs.co.jpを利用。ディストリのおいてあるところは、 /00/Linux/packages/RedHat/redhat/linux/7.3/en/os/i386/。というわけで、バージョンは7.3な のです。

インストール自体は無事に終了。再起動後、RedHatが起動。とはいえ、Xを入れていないので見た目は普通のCUIのLinuxでしかない。とり あえずいろいろとチェック。ところが、無線LANデバイスがうまく動いていないみたい。で、チェックしてみると、Adhocモードで稼働していた。 /etc/pcmcia/wavelan.optのあたりを修正して問題なく稼動。その後、外部からtelnetなり、sshなり、httpなりで接続し てみるが、問題なくつながるようだ。

ところが、ここに一つ問題がある。というのも、インストール時に使った無線LANカードはメルコのWLI-PCM-L11なのだが、実際に運用するときにはWLI-PCMという2Mのカードを使うつもりでいた。しかし、これがpcmcia-csではサポートされていない。

しらべてみると、linux-wavelan-0.3.4を入れれば使えるらしい。このlinux-wavelan自体はカーネル2.2用なのだ が、カーネル2.4用のパッチも出ているらしい。とはいえ、ここまで結構な時間がかかったので、とりあえずはここまでで今日は終了にする。


2003.02.01

近所の床屋に行く。順番待ちをしていると床屋のあんちゃんとどこかのお客さんの会話が聞こえてくる。Yahoo!BBの話題をしているようだ。どう やら、二人ともこの年末にかけてYahoo!BBを導入したらしい。しかも、二人とも申し込んでから開通まですんなり行っていなかったようだ。

片方は、申し込んでから一ヶ月近い放置をくらったらしい。もう片方は、開通したのはいいけどいつまでたっても仮IDが送られてこないらしい。なんにしても困ったものである(笑)。

この導入記は、最近のYahoo!BBはあまりトラブルがないようなことがいわれているにもかかわらず、実のところマイナートラブルはありうるんだ よみたいなことを書き散らかすつもりで書いているわけなのだが、近所でうち以外に二軒もこの手のマイナートラブルがあったということがわかってしまうと、 なんかなんて言っていいものか困ってしまう。結局、表面に出ないだけで(そして、以前の最悪な状態に比べれば圧倒的にましになったとはいえ)、事務手続き 上の処理でのトラブルは非常に多いんだなぁと思った次第。


2003.02.02

ステータスの開通日は今もって空白のままである。もしかしてこのまま2月まで開通日がずれこんでいくのだろうか、それとも週明けにでも1月末あたりの日付で開通日が設定されるのだろうか。期待というか不安というかが微妙な感じである(笑)。

さて、金曜の夜にセットアップしたサーバ予定機の話の続きだが、linux-wavelanをいざインストールしようとしたら、gccが入っていな いことに気づいた。RedHatは初めてで全然勝手がわからない。こういうとき、Turbolinuxならturobopkgというかzabomというか そのあたりを使うとCUIでパッケージの選択追加インストールができるのだが、RedHatにはトータルでのパッケージ管理ができるCUIツールがなさそ うである。しょうがないから最初からセットアップをしなおす。とはいえ、回線速度があるということはこういうときに躊躇しないですむのでありがたい。

というわけで、1時間ちょっとで再インストール完了。今度はきちんとgccがインストールされている。linux-wlanのインストールにはkernelのソースが必要らしいのでそれもインストール済み。

というわけで、さっそくlinux-wlanのインストールを開始する。

まずは、必要なもののダウンロード。

最初に、配布元からlinux-wlan-0.3.4.tar.gzをダウンロード。次にパッチ配布元からkernel 2.4対応パッチをダウンロード。

ダウンしたものを展開してパッチをあてる。

 

zcat linux-wlan-0.3.4.tar.gz | tar xvf –
patch -p0 < patch2002-12-03.txt

次は、config.mkの編集。とおもったのだが、pcmciaのソースがどこにあるかわからない。srpmで落としてきて入れておけばいいかと思って、redhatのftpサイト(正確にはミラーサイトなんだけど(笑))を探すが発見できず。

検索してみると、こんなサイト見つける。どうやら、pcmcia-csをインストールするほうが早道のようだ。というわけで、pcmcia-cs自体をインストールするところから始める。

まずは、pcmcia-cs-3.1.25.tar.gzをftp.kddlabs.co.jpからダウンロード。展開後、展開先に移動してとりあえずmake allしてみる。

エラーがでてうまくいかない。よく見てみると、Configureスクリプトがある。というわけで、

 

./Configure
make all
make install

どうやらうまくいったようだ。

さて、次はいよいよlinux-wlanのインストール。linux-wlan-0.3.4に移動し、config.mkの編集。編集した内容はこんな感じ。

 

LINUX_SRC=/usr/src/linux-2.4
PCMCIA_SRC=/usr/local/src/pcmcia-cs-3.1.25
MODULES_DIR=/lib/modules/2.4.18-3
INST_EXEDIR=/sbin
DEST_DIR=
MAKE_ISA=n
MAKE_CS=y

で、さっきのサイトに書いてあるとおりに

 

make clean
make all

エラーなしで無事終了。どうやらコンパイルできたようだ。引き続き、先のサイトのインストラクション通りに

 

make install
cd scripts
cp wlan wlan.config wlan.opts /etc/pcmcia
cd /etc/pcmcia
chmod 755 wlan wlan.opts

という感じでインストールしてみる。コンパイルがうまくいっているので問題ないだろうと思っていたけど、一抹の不安はあった(笑)。でも、問題なく終了。

さて、あとは、設定ファイルの変更。

まずは、/etc/pcmcia/configの最後のほうに

 

source ./wlan.config

という一行を追加する。/etc/pcmcia/configが最初read onlyだったのはご愛敬。

次は、wlan.optsの編集。ここに書いてある内容を参考に、

 

DESIRED_SSID=”ESSID”
SCAN_STARTCH=14
SCAN_ENDCH=14

あたりを書き直す。これで設定終了のはず。というわけで、ここまでの作業で使っていたWLI-PCM-L11を引っこ抜き、設定を反映させるためにpcmciaをrestart。

いよいよwli-pcmの差し込み。差し込むとすぐにランプ点灯。どうやら認識はしたようだ。しかし、

 

tx attempt, not joined, frame dropped

というメッセージがコンソールにでてきてつながらない。認識はうまくいっているわけで、コンパイルまわりではなさそうだなと当たりをつけ、まずは一番怪しそうなESSIDの設定をチェック。

ESS IDのtypoだった。というわけで、修正してpcmcia再起動。しかしつながらない。これはもしかして結構はまるパターンか?と思いながら、再度wlan.optsをチェック。

ESSIDをさらにtypo(爆笑)

再修正。こんどこそ正確なはず(笑)。念入りに確認した後、pcmciaを再々度restart。

今度はエラーが出ない。ってことは…、つながった!!

というわけで、自宅サーバのベースが完成。とはいえ、このあとネットワークまわりの設定とかいろいろとやらなくてはいけないことがあるので、先は長くなりそうである(笑)。

さて、またぞろYahoo!BBの会員情報関係を見て見ていたりしたら、どうやらウォレットのほうに動きがあったみたいである。というわけで、暗証番号を登録してウォレットを確認したところ、葉書で書いたカード番号が無事に登録されていた。

そんなわけで、あと残っているのは開通日情報の更新だけ。さてさて、どうなることやら。


2003.02.03

帰宅するとYahoo!BBとBBフォンから封書が届いている。さては開通の通知だなと思って開けてみるとそのとおりだった。BBフォンは1月25 日、Yahoo!BBは1月26日に開通ということになっていたらしい。というわけで、我が家の無料期間は当初の予定通り2月いっぱいということになっ た。正直、非常にもったいないような感じになってしまったが、まあこれはこれでしょうがない、っていうか、開通が比較的早い時期にできただけでも上出来と するべきだろう。

さて、自宅サーバの設定の続き。つぎの目標はメールの送受信、なんだけど、これまで試した範囲では、メールの送信は問題なくできるにもかかわらず、外部からのメール受信がうまくいっていない。

当初、送信のほうでも、送信元がfunayama@localhostとかなってしまう問題がでていたのだが、これは/etc/hostsにホスト名をドメインつきで

 

127.0.0.0 localhost.localdomain localhost
192.168.xx.xx fujirushi.hoge.domain fujirushi

とかいうふうに設定することでうまくいくようになった(多分)。

というわけで、次はメールが受信できるようにする番である。

とりあえず、外部から25番ポートにtelnetをかけてみると、connection refusedというメッセージが出てくる。この接続の拒否がルータからのメッセージなのかサーバ機からのメッセージなのかを特定するのが最初になるわけだ。

さて、RedHatのディストリビューションは、そのなかにfirewall機能を含んでいる。「RedHat/sendmail/受信」あたりで Googleで検索をかけてみると、このfirewall機能がsmtpポートを塞いでいる可能性があるらしい。というわけで、確認。しかし、この firewall機能、確かインストール時に無効にしていたはず。実際無効になっている。というわけで、こちらは問題なし。

次にルータがsmtpをサーバまで届けていない可能性を探ってみる。一応、サーバのIPはDMZに設定してあるのだが、念のためsmtpポートを明 示的にサーバにフォワードするように設定して再度外部からメールを送信してみる。しかし、変化なし。ということは、やはりポートはサーバまでフォワードさ れていて、そこで接続が蹴られているようだ。というわけで、ルータの設定を戻した後、再度検索の旅に出る。

すると、こんなページを発見。どうやら、RedHatは、初期設定では、sendmailが外部からの接続を受けつけないような設定になっているらしい。というわけで、sendmailの設定変更。

まず、/etc/mail/sendmail.mcにある、

 

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA’)

という部分を

 

dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA’)

に変更。この設定は、外部からのメールを受けつけなくする(というより、localhostからの接続しか受けつけなくなる)設定らしい。ちなみに、dnlはコメント記号だそうだ。

そのあと、当該ページにあるとおり、

 

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf

として、sendmail.cfを作りなおし、sendmailを再起動する。確認のため外部からメールを送信してみると、今度は問題なく届く。と いうわけで設定変更完了。ちなみに、しばらく放置していたら、これまでうまく届かなくて送信元サーバにとごっていたメールがわらわらと届いたのは内緒であ る(笑)。

さて、smtpポートを開放するということは、メールの不正中継がおこる可能性があるということを同時に意味している。まあ、最近のディストリビューションではその手の設定はデフォルトでされているはずではあるが、念のため、このサイトで不正中継ができるかどうかをチェック。

 

第三者中継調査(Third Party Relay) – 結果表示

????@fujirushi.hoge.domain を担当するメールサーバーの検査結果は以下の通りです。
※この検査では実際にはメール本体を送信せず、MAIL FROM, RCPT TOの応答から、第三者中継の可否を判定しております。 「受け取ったことにして、管理者には報告する」等特殊な設定がなされたサーバの場合、 実際には中継を行わないにも関わらず、「不正な中継を受け付ける」旨表示される場合がありますが、 ご了承ください。

設定エラー:指定されたメールアドレスのホスト部に対するMXレコードが設定されていません。
相手方の設定によっては、メールを受け取れない場合があります。この問題はSPAMと直接には関係ありませんが、設定を見直すことをおすすめします。
直接配送による試験を続行します。


fujirushi.hoge.domain

<<< 220 fujirushi.hoge.domain ESMTP Sendmail 8.11.6/8.11.6; Mon, 3 Feb 2003 20:32:46 +0900
>>> HELO rlytest.nanet.co.jp
<<< 250 fujirushi.hoge.domain Hello ns.nanet.co.jp [210.164.52.3], pleased to meet you
>>> MAIL FROM:<“3d622c:TPR TEST http://www.nanet.co.jp/rlytest/ requested from [219.40.56.153]”@fujirushi.hoge.domain>
<<< 250 2.1.0 <“3d622c:TPR TEST http://www.nanet.co.jp/rlytest/ requested from [219.40.56.153]”@fujirushi.hoge.domain>… Sender ok
>>> RCPT TO:<rlytest@nanet.co.jp>
<<< 550 5.7.1 <rlytest@nanet.co.jp>… Relaying denied

正常:中継は拒否されました。


合格: あなたがお使いのMXサーバーは、不正な中継を行わないように設定されています。

大丈夫そうである。とはいうものの、DNSにMXレコードの登録がないという警告が出てきてしまった。確かに、DDNSに登録したときにMXレコードは登録していない。というわけで、DDNSレジストラのサイトに行ってMXレコードを登録し、再度確認。

 

第三者中継調査(Third Party Relay) – 結果表示

????@fujirushi.hoge.domain を担当するメールサーバーの検査結果は以下の通りです。
※この検査では実際にはメール本体を送信せず、MAIL FROM, RCPT TOの応答から、第三者中継の可否を判定しております。 「受け取ったことにして、管理者には報告する」等特殊な設定がなされたサーバの場合、 実際には中継を行わないにも関わらず、「不正な中継を受け付ける」旨表示される場合がありますが、 ご了承ください。

指定したメールアドレスへのメールは、以下の1のサーバが担当しています。
全てのサーバの調査が終了するまでしばらくお待ち下さい。
ホスト名の右側に表示される’pri’という表示は、サーバの優先度を示し、 数字が小さいものから優先してメールの処理を担当します。


fujirushi.hoge.domain (pri=10)

<<< 220 fujirushi.hoge.domain ESMTP Sendmail 8.11.6/8.11.6; Mon, 3 Feb 2003 20:44:31 +0900
>>> HELO rlytest.nanet.co.jp
<<< 250 fujirushi.hoge.domain Hello ns.nanet.co.jp [210.164.52.3], pleased to meet you
>>> MAIL FROM:<“efe80c:TPR TEST http://www.nanet.co.jp/rlytest/ requested from [219.40.56.153]”@fujirushi.hoge.domain>
<<< 250 2.1.0 <“efe80c:TPR TEST http://www.nanet.co.jp/rlytest/ requested from [219.40.56.153]”@fujirushi.hoge.domain>… Sender ok
>>> RCPT TO:<rlytest@nanet.co.jp>
<<< 550 5.7.1 <rlytest@nanet.co.jp>… Relaying denied

正常:中継は拒否されました。


合格: あなたがお使いのMXサーバーは、不正な中継を行わないように設定されています。

これで警告も消えてめでたしめでたし。


2003.02.04

本日のお題は「bindの秘密」である。

というのも、このところ連日のようにサーバの設定を続けていくことでぼちぼちとサーバが出来上がりつつある。無論、まだまだ設定事項は多いのだが、 実際にサーバを設定する段になるとVGAサイズしか使えないコンソールよりはssh経由でログインしての作業のほうがひろいコンソールを利用できて便利で ある。

しかし、現状、sshで接続をするためには、サーバのIPを直接指定するしかない。というのも、接続先として fujirushi.hoge.domainを指定すると、DDNSで名前解決されて指定されるIPとして、ルータのWAN側IPが指定されるわけで、結 果、ルータに接続されてしまう。これははっきりいって不便である。

解決法としては、

  1. あきらめてIP指定で接続する
  2. hostsファイルを書いてWindowsディレクトリあたりに放り込んでおく
  3. 家庭内専用DNSをサーバ上で動かす

といったものがあげられる。さて、この中から何を選ぶか。結論は決まっている。趣味と道楽を兼ねた自宅サーバ設置という目的を考えると、bindの設定をおこなうの基本である(笑)。

というわけで、bindによるDNS構築を試みることにする。とはいえ、やったことは、基本的には、ここここのコピペ(笑)。

なんだけど、一応順を追って書いていこうかなと思う。

まず最初に/etc/named.confの編集をおこなう。下記のような感じでまず/etc/named.confを設定する。変更したとこには適当に注釈をつけてあるけど、要は、LAN内の名前解決だけ自分でやって、あとはルータに丸投げするという設定である(笑)。

 

// generated by named-bootconf.pl//ローカルネットの範囲定義
acl fujirushinet{
192.168.xxx.0/24;
127.0.0.1;
};

options {
directory “/var/named”;
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;

//ローカルネット以外からの問い合わせ禁止
allow-query { fujirushinet; };

//外にデータを投げない
allow-transfer { none; };

//わからなければルータに聞け(ここ重要(笑))
forwarders { 192.168.xxx.1; };
};

//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone “.” IN {
type hint;
file “named.ca”;
};

//正引きの設定 (lan.zone)
zone “fujirushi.hoge.domain” IN {
type master;
file “lan.zone”;
};

//逆引きの設定 (lan.rev)
zone “xxx.168.192.in-addr.arpa” IN {
type master;
file “lan.rev”;
};

zone “localhost” IN {
type master;
file “localhost.zone”;
allow-update { none; };
};

zone “0.0.127.in-addr.arpa” IN {
type master;
file “named.local”;
allow-update { none; };
};

//loggingセクションの追加
logging{
category lame-servers { null; };
};

include “/etc/rndc.key”;

さて、/etc/named.confの設定で、LAN内の名前解決用にlan.zone(正引き用)とlan.rev(逆引き用)の設定ファイルを用意する。このファイルは、/var/namedに置いておく。

現状の家庭内LANで固定IPを持っているのは、ルータとサーバとプリントサーバの三つだけなので、これらのIPを指定しておく。ちなみに、詳しい設定内容の説明は先にあげたサイトに詳しいのでそちらを参照してください(笑)。

というわけで、まずは正引き用のファイル(lan.zone)。

 

$TTL 86400@ IN SOA fjserv.fujirushi.hoge.domain. root.fjserv.fujirushi.hoge.domain. (
2001102901
3H
1H
1W
1D )

IN NS fjserv.fujirushi.hoge.domain.
IN MX 10 fjserv.fujirushi.hoge.domain.

router IN A 192.168.xxx.1
fjserv IN A 192.168.xxx.2
prtsrv IN A 192.168.xxx.8

dns IN CNAME fjserv
www IN CNAME fjserv
mail IN CNAME fjserv
smtp IN CNAME fjserv
pop IN CNAME fjserv
imap IN CNAME fjserv
ftp IN CNAME fjserv
ns IN CNAME fjserv

こちらは、逆引き設定のファイル(lan.rev)。root.fjserve.fujirushi.hoge.domainというのは非常時連絡先だそうで、なにかあると最初のピリオドが@に置き換えられたアドレスにメールが送られるんだそうな。

 

$TTL 86400@ IN SOA fjserv.fujirushi.hoge.domain. root.fjserv.fujirushi.hoge.domain. (
2001102901
3H
1H
1W
1D )

IN NS fjserv.fujirushi.hoge.domain.

IN PTR fujirushi.hoge.domain.
IN A 255.255.255.0

1 IN PTR router.fujirushi.hoge.domain.
2 IN PTR fjserv.fujirushi.hoge.domain.
8 IN PTR prtsrv.fujirushi.hoge.domain.

というわけで、大枠の設定は完了。さて、後は関連する周辺環境の設定。まずは、/etc/hosts。ここで通常は(っていうはbindを動かさな いときは)自分のホストの名前を書いておくものだが、これが書いてあると名前解決のとき/etc/hostsの設定がbindの設定よりも先に参照されて しまい、将来IP付けなおしたときに設定が反映されないという悲惨なことが起こってしまう。というわけで、/etc/hostsからlocalhost以 外をコメントアウト。

 

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
#192.168.xxx.2 fujirushi.hoge.domain fujirushi

最後に、サーバ自身が使うDNSを設定したbindのものになるように/etc/resolv.confを編集。/etc/resolv.conf はその名の通り名前解決に関する設定をするファイルなのだが、bindを動かさない設定で最初インストールしたのでnameserverとしてルータの IPが変更前には入っていた。これをlocalhostのIPに変更。

 

search fujirushi.hoge.domain
nameserver 127.0.0.1

というわけで、設定は全部完了。さて、起動テストである。/etc/init.d/named startとかしたあと、nslookupでLAN内のホストが名前解決できるかを確認してみる。

できない。起動失敗しているようだ。

起動失敗しているなら、/var/log/messageのなかにbindが吐いたエラーメッセージがあるはずなのでチェック。すると、/etc /named.confの中で、セミコロンが抜けているのでエラーになっている。確認してみると最後のほうでセミコロンをコロンに打ち違えていた。修正 後、再度起動確認。今度は起動に成功。

まずはnslookupでfujirushi.hoge.domain内の正引きがうまくいくことを確認した。しかし、逆引き失敗。どうせ/etc/named.confに原因があるんだろうと決めつけたうえで、設定を再確認。

すると、本来、

 

zone “xxx.168.192.in-addr.arpa” IN {

となっていなくてはいけないはずのところが、

 

zone “168.192.in-addr.arpa” IN {

となっていた。これではうまくいくはずもない。というわけで、修正。named再起動。今度は逆引きもうまくいった。外に関しては、まあ、ルータ丸 投げ方式だから大丈夫だろうと思ってそのままルータのDHCPサーバの再設定。primary DNSを192.168.xxx.2にする。secondaryを192.168.xxx.1にしたら怒られた、っていうか、そりゃそうだ。ふつー secondary DNSは別のサブネットにおいておかないとLANが死んだときのトラブルの原因になる。というわけで、ここは削ってDHCPも設定完了。

で、新しいLANの設定がうまく動くかどうか、PCの無線LANカードをいったん停止してDHCPでIPほか一切合財を取り直した。

Windows2000のコンソールからipconfig /allで取得したDNSアドレスの確認をする。primaryは設定したとおり192.168.xxx.2になっている。secondaryはという と、Yahoo!BBのものと思しきDNSのアドレスが入っていた。

ということは、家庭内サーバが突然死亡しても外部向けの名前解決は問題なく動くはずである。サーバの安定性については現状未知数なので万一サーバがおなくなりになった場合、家庭内LANが麻痺してしまう可能性があるかなと思って心配していたのだが、一安心である。

DHCPの設定がうまくいいたところでウェブブラウザとか立ち上げてみる。まずは家庭内サーバ機に接続。立ち上げてあったapacheが無事に応答 し、テストページが表示される。めでたい(笑)。その後、外部への接続のテスト。これもOK。最後にbindを落としてサーバが死んだ場合を想定したテス ト。LAN内への接続は当然だめ。しかし、WAN側への接続は問題なくおこなわれる。以上で、テスト完了。

最後に、/sbin/chkconfig –level 35 named onとかして、サーバ起動時にbindが自動的に立ち上がるように設定。サーバを再起動してbindが自動起動することを確認し、全部おしまい。

というわけで、本日も野望に一歩近づいたようである。

カテゴリー: 別館, 古いコンテンツ パーマリンク