自宅サーバ構築メモ
このページは、このサイトを構築したときのメモを書いている。なお、作業履歴を
こちらに記載している。
ハード・ソフトの構成
ネットワーク
| 接続回線 | B Flet'sマンションタイプ |
| プロバイダ | Plala |
| ルータ | BUFFALO WER-AM54G54 |
| Dynamic DNS | MyDNS.JP |
| ドメイン名 | kentuck.net |
| レジストラ | お名前.com |
コンピュータ
| CPU | Celeron 2.6GHz |
| Memory | 256MB |
| HDD | 40GB |
ソフトウェア
| O/S | Plamo Linux 4.01(2004.10.8に更新) |
| Webサーバ | Apache 2.0.52(2004.10.8に更新) |
| Mailサーバ | Postfix |
ルータ
使用したI/O DATAのルータ(WN-APG/BBR)では、Virtual Serverという機能で、グローバルアドレスの特定のポートを内部の特定のコンピュータ(プライベートアドレス)に転送することができる。
この機能を使って、今回構築したサーバを外部(インターネット)からアクセスできるようにした。設定したポートは、次の3つである。
私の指定したルータでは、Virtual Serverを設定したポートは、自動的に外部(WAN)からアクセスできるようにアクセス制御の情報も書き換えてくれる。従って、操作は、Virtual Serverだけの設定でOKである。
ドメインとDynamic DNS
将来的には、独自ドメインを取得したいが、とりあえずDynamic DNS(DDNS)を無償で提供しているところのサブドメインを使って運用することにした。
DDNSを探すときには、
ここが役にたった。
選択したDynamic DNSは、
MyDNS.JPである。
ここにした理由は、独自ドメインに対するDDNSも無償で提供しているので、将来的に独自ドメインにしてもここを引き続き利用できる点と、MXレコードをサポートしている点である。
このサーバで本格的なメールサーバを運用するつもりは、当面はないが、やはりメールも運用できたほうが何かと便利なので、MXレコードのサポートも可能であればほしかった。
MyDNS.JPでのグローバルアドレス更新は、メール受信でOKである。
MyDNS.JPのサイトの「実際に使ってみよう」のLinux編を参考にして、biffpopをcronで15分毎に起動して、アドレスを更新している。
MyDNS.JPのサイトの「更新ログ確認」には、1日1回だけログが残るようである。
私の環境(プロバイダPlala)では、ここ1週間(2004.9.30時点)では、グローバルアドレスの更新はないようである。
O/S
Plamo Linux4.0をインストールした。
インストールは、
ここを参考にして指示どおりに実行すると問題なくインストールできる。
ただし、Plamoは、パーティションの設定をfdiskまたはcfdiskを使って手動でやる必要があるので、このあたりの知識がないとちょっときびしいか。
しかし、9月10日にLinux4.01が公開されたので、Linux4.01を再インストールしたいと思っている、いつになることやら。
Webサーバ
Webサーバは、Apache2を使うことにした。Apache2のPackageを
ここから最新のもの(httpd-2.0.50-i386-P1.tgz)をダウンロードし、installpkgコマンドでインストールした。
installpkg httpd-2.0.50-i386-P1.tgz
Apacheは、/opt/httpd/以下にインストールされる。
その後Apacheにセキュリティホールが発見され、9月30日現在で、2.0.52が最新のようである。早めに、インストールしたい。
ホームページ
cssを使った簡単なホームページを作成した。
このページをサーバにアップデートすると、encodingがlatinになってしまって文字化けしてしまう。
いろいろ調べてみたが、設定を変えてもどこかで何かが残っているのか、文字化けがなおったり、文字化けしたりと状況が安定しないので、原因がはっきりしないが、現状では、htdosの直下に.htaccessを置くことで解決したようである。
.htaccessには次の一行を書いた(
参考)。
AddType "text/html; charset=Shift_JIS" .html
また、httpd.confの次の行をコメントにしたり、コメントをはずしたりしたが、結局は、私の環境では、コメントにしないと文字化けを起こすようである。
AddDefaultCharset ISO-8859-1
次の難関は、トップページの画像がWindowsXPではIE、Nescapeとも見れないことである。
ソースを見ると、imgタグの行が空白になっている。どこかで削除されているようである。
いろいろやった結果、犯人(?)はSymantec社のInternet Securityである。
このソフトにはいろいろと苦労させられるが、自分で自分を守るためには、このようなソフトを使わざる終えない。
今回は、次の行が問題となった。
<img src="images/photo01.gif" width="250" height="250" alt="日の出の写真">
なんと、Internet Securityは、「width="250" height="250"」を広告としてはじいていた。
現在は、次のようにしている。
<img src="images/photo01.gif" alt="日の出の写真">
CGI
ネチケットとして、管理者を明確にすることがあるので、連絡用のメールを送ることができるようにした。
mailtoを使うとメールアドレスを探し回るエンジンに捕まり、SMAPメールの対象になる危険性があるとのことなので、CGIをおくことにしった。
利用させてもらったのは、いつもお世話になっている
とほほさんが公開しているwwwmailである。
CGIは、apacheをインストールしたディレクトリ(フォルダ)の下のcgi-binにおくことにした。
いつものとおり一発では、うまくいかなかった。httpd.confの設定かと思いいろいろやったあげく、perlのパスが間違っていた。
何度CGIを設定しても、同じような過ちを繰り返す。
CGIのポイントは、動作しない原因がhttpd.confかCGIのファイルかを切り分けることである。
必ず動作するCGI(apacheの場合は、cgi-bin/namazu.cgiがインストールされているのでこれを使う)が動作することを確認するまでは、httpd.confの設定が?であろう。
これを確認した後、CGIが「Internal Server Error」などで動作しないときは、CGIファイルを疑う。
私の場合は、httpd.confの次の一行のコメントをはずすだけで、CGIをcgi-binで動作させることができた。
#AddHandler cgi-script .cgi
ドキュメントルートへCGIをおく場合は、ドキュメントルートのoptions設定を次のように変更する必要があるようである(
パソコンおやじの
Apacheの設定を参照)。
Options FollowSymLinks Includes ExecCGI MultiViews
公開鍵を使ったSSHの運用
ルータでsshdを開けているということをこのページで書いたのが原因かどうかわからないが、logを見ると、ログにssh経由で不正に侵入しようとしている形跡があった。
プレーンパスワード(コンソールからログインするときに使う普通のパスワード)を使ってsshにログインしていたが、危険性をへらすために、公開鍵方式のkeyを使ったログインに変更することにした。
せっかくだからSSH2プロトコルを使うことにした。
キーの作成は、Linux上でもWindows上でも可能である。
今回は、puttyに同梱されているPuTTY Key Generator(puttygen.exe、以降puttygenと記述)を使って作成した。
私は、
@IT:鍵交換方式のsshでアクセスするにはを参照に、Windowsマシンでputtygenで公開鍵、秘密鍵を作成し、公開鍵をLinuxマシンにコピーし、登録する作業を行った。
ただし、作成した公開鍵をWindowsマシンからLinuxマシンにコピーするのは、すでにssh環境を確立していたので、WinSCP3を使った。
また、Linuxの公開鍵を管理するファイルとして、SSH2用にはauthorized_keys2を使うような記事をいくつか見つけたので、私は、authorixed_keysではなくatuthorized_keys2にopensshフォーマットの公開鍵を保管している。
次に、WinSCP3でも公開鍵を使うように変更する。
WinSCP3を起動して、対象となるセッションを読み込む。
読み込まれたセッション情報の「パスワード」を空白にすると、「秘密鍵」を指定できるようになる。
「秘密鍵」にputtygenで作成した秘密鍵のファイル名を指定する。
「保存」を押して、セッションを保存しておく。
これで、このセッションの接続は、公開鍵方式を使ったものになる。
このままでは、プレーンパスワードによるログインも可能である。
sshdの設定は、/etc/ssh/sshd_configファイルで行う。
ここでは、rootのログインの禁止とプレーンパスワードによるログインの禁止を指定するために、sshd_configファイルの以下の箇所を修正した。
[rootのssh経由でのログインを許可しない]
#PermitRootLogin yes
のコメントを外し、yesをnoに変更
PermitRootLogin no
[プレーンパスワードによるログインを禁止する(1)]
#PasswordAuthentication yes
のコメントを外し、yesをnoに変更
PasswordAuthentication no
上記の設定だけでは、puttyjpで秘密鍵を指定しなくて、プレーンパスワードでログインできてしまう。
どうやら、password認証はしないが、PAM認証されてしまうために、結局プレーンパスワードでのログインが可能となるようである。
プレーンパスワードのログインを一切禁止するためには、次の箇所の修正も必要となる。
[プレーンパスワードによるログインを禁止する(2)]
#ChallengeResponseAuthentication yes
のコメントをを外し、yesをnoに変更
ChallengeResponseAuthentication no
Plamo Linuxの再インストール
Plamoのバージョンが4.01になった。
まだ、アプリケーションをほとんどインストールしていなかったので、今の環境(4.0)をいったん保存して、最新のPlamo4.01をインストールすることにした。
[環境のバックアップ]
現在までにインストールや設定をした、Apache、openssh、postfixの環境背設定ファイルやデータファイルのバックアップファイルを作成する。
以下の操作をroot権限で実施した。
- バックアップファイルを集めるディレクトリを作成
mkdir /opt/tmp
- Apache関連のバックアップを取る
mkdir apache
cp -a /opt/httpd/htdocs /opt/tmp/apache
cp -a /opt/httpd/cgi-bin /opt/tmp/apache
cp -a /opt/httpd/conf /opt/tmp/apache
- openssh関連のバックアップを取る
mkdir /opt/tmp/ssh
mkdir /opt/tmp/etcssh
cp -a /etc/ssh/* /opt/tmp/etcssh
mkdir /opt/tmp/userdotssh
cp -a ~userid/.ssh/* /opt/tmp/userdotssh
- postfix関連のバックアップを取る
cp -a /etc/postfix /opt/tmp
- バックアップのアーカイブファイルを作る
tar zcf /opt/bufiles.tar.gz /opt/tmp/*
[Plamo4.01のインストール]
Plamoのダウンロードサイトの
ISOなイメージから次のファイルをダウンロードする。
- plamo-4.01_01.iso
- plamo-4.01_02.iso
これらのISOイメージからCD-Rライタソフトを使ってインストール用のCD-Rを作成する(2枚)。
私は、B's Recorde GOLD5を使ったが、CD-RライタソフトであればISOイメージのCD-Rを作成する機能はほとんど備えているようである。
[apacheのインストール]
以前イントールしたapacheのパッケージは、httpd-2.0.50-i386-P1.tgzであったが、セキュリティパッチなどが当てられて、最新のパッケージが
ここから入手できる。
私のやり方が悪いのかどうかわからないが、ここからダウンロードすると、ファイル名が「php-5.0.2-i386-P2.tgz.gz」となる。
このファイル名のままinstallpkgするとエラーになるので、名前を「php-5.0.2-i386-P2.tgz」に変更してからinstallpkgすると、前バージョンと同様/opt/httpdの下にインストールされる。
前回はちゃんと書かなかったけど、httpd.confの修正箇所をまとめておく。
#Listen 12.34.56.78:80
のコメントを取り、IPアドレスをこのサーバのローカルアドレスに変更する
Listen xxx.xxx.xxx.xxxx:80
Listen 80
をコメントにする
#Listen 80
AddDefaultCharset ISO-8859-1
をコメントにする
#AddDefaultCharset ISO-8859-1
#AddHandler cgi-script .cgi
のコメントを外す
AddHandler cgi-script .cgi
[Apache関連ファイルの復元]
バックアップしておいたcgi-binディレクトリとhtdocsディレクトリのファイルを復元する。
cgi-binのパーミッションを見直すことを忘れずに。
独自ドメインの取得
MyDNS.JPのサブドメインによる運用で、自宅サーバとして運用できる目処がたったので、独自ドメインを取得することにした。
ドメイン名は、kentuck.xxxとしたい。
海外の格安のレジストラ(この言葉も最近知った、ドメイン取得の代行を行う組織?)から取得することも検討したが、取得するドメイン名はほぼ永久的に使いたいので、安心感がちょっとだけある(あくまで精神的で個人的な感触)日本のレジストラから取得することにした。
最初は、Dynamic DNSサービスを利用しているMyDNS.JPでドメイン名の検索をしてみたが、どうも不安定なので、ここはパスした。
次に、googleで検索して見つけた
お名前.comで、ドメイン名を検索した。kentuck.comは使用済みだったので、kentuck.netかkentuck.jpが候補となった。
kentuck.jp(税込8,337円/年)は割高感があったので、kentuck.net(税込3,990円/年)に決定した(安心感はどうしたの?)。
登録は、Webから簡単(入力量はそれなりだけど、日本語なので難しいところはない)にできた。
Dynamic DNSは、お名前.comでもサービスしていたが、有償(200円/月)だったので、引き続きMyDNS.JPを使うことにした。
まず、MyDNS.JPでユーザIDを取得し(MyDNS.JPは、一つのドメインで一つのIDをとる必要がある)、kentuck.netのDNS登録をした。
登録は、
MyDNS.JPの「どうやって使うの?」を参考にすると問題なくできた。
次に、
MyDNS.JPの「実際に使ってみよう!」のLinux版を参考に、.biffpoprcの内容を変更し、手動でbiffpopを動作させる。
最後は、
お名前.comの「DOM Navi」(行き方がわかりにくいが、メニューの「サービス設定」でいけるが、ときどきURLが見つからないとエラーが出る)の情報変更のネームサーバーで、プライマリDNSとセカンダリDNSをMyDNSの指定のDNSに設定する。
このときに、「技術担当者情報入力画面にすすむ」でこのドメインの技術担当者を入力しないとこの設定が有効にならないので、注意が必要。
これらの作業をしてから、数分後にnslookupで確認したら、kentuck.netがちゃんと認識できて、このサーバ(ルータ)のグローバルアドレスが割り付けられていた。
これで、独自ドメインでの運用を開始する。
ルータの交換
現在、Debian化した玄箱をサブとして利用するための作業をしている。
外部(インターネット)から、メインのサーバと玄箱の両方に、sshで直接接続したい。
利用しているIO DATAのルータは、アドレス変換のときに内部のポート番号を指定できないようなので、これができない。
このため、ルータを変更することにした。選んだルータは、BUFFALOのWER-AM54G54である。
この作業をするときにはまったので、メモを残しておく。
WER-AM54G54は、外部のアドレスとポートを内部のアドレスとポートに割り当てることができるので、アドレス変換を次のように設定した。
| 外部 | 内部 |
| アドレス | ポート | アドレス | ポート |
| WAN側のアドレス | 80 | 192.168.x.11 | 80 |
| WAN側のアドレス | 22 | 192.168.x.11 | 22 |
| WAN側のアドレス | 5022 | 192.168.x.12 | 22 |
5022は適当に振っている。
192.168.x.11がメインサーバの内部のIPアドレスで、192.168.x.12が玄箱の内部にIPアドレスである。
このように設定してから、Dynamic DNSへのアドレス変更(私の場合は、メール受信)を行った後、内部のパソコンから、pingでwwww.kentuck.netにアクセスできることを確認した。
そして、Webブラウザで「http://wwww.kentuck.net/」を開こうとしたら、ルータの設定画面を開こうとする。
どうやら、このルータは、外部のアドレスを指定しても、内部からのアクセスの場合は、内部側のアドレスしかアクセスできないようである。
だから、内部からwwww.kentuck.netをDNSで引いたグローバルIPを指定しても、このグローバルIPの変換先のIPアドレスにしかアクセスできない。
これは、
「Linuxで自宅サーバ」の「Apacheの基本設定」で確認できた。
また、このページの情報によると、このルータで、内部のPCから、「ちゃんと外部からアクセスできる」ことを確認するには、「
Another HTML -lint gateway-」などのホームページチェック用の機能などを使うしか方法がないようである。
これまで使っていたIO DATAのものと違っていたので、はまった。
また、sshの外部側のポートは、22でなくてもよいようになったので、変更しておこうと思う(私が知っていればよいので、気休めだけど、ほんのちょっとは安心)。
この作業中に、誤ってWebRingの登録情報を削除してしまった。再度登録したところ、同じ番号をもらえたようである。
最終更新日:2004.10.14