コンソールで存在しないコマンドでタブを押したときなどに、ssh越しにエラーを知らせるビープ音が鳴ってしまいますが、TeraTermでビープ音を鳴らさないようにするには設定ファイルの[Tera Term]セクションに以下の設定を書けばいいようです。
Beep=off
以下のマニュアルを参照してください。
VPSで使用する独自ドメインを自前のDNSサーバで運用する
VPSを使用する場合、多くの場合は独自ドメインを取得して使用することになるかと思いますが、その独自ドメインのDNSサーバの運用方法は大きく以下の3つになると思います。
- ドメインを取得した会社のDNSサーバを使用する
- 外部のDNSサーバを使用する
- VPSサーバでDNSサーバを運用する
ドメインの登録会社は多くの場合DNSサーバのサービスを提供していると思います。そのサービスで問題なければ一番手堅い方法です。今回はムームードメインで取得したドメインを使用しますが、ムームードメインでは関連サービスを使う用途以外のDNSサーバの設定はできません。
世の中にはDNSのサービスのみを提供しているものを多数あると思います。例えばFreeDNSというフリーのDNSサービスなどはフリーにもかかわらず自由度の高い設定が可能なのではないでしょうか。
今回は独自ドメインを使用するVPSサーバ自身で自前のDNSサーバを運用することにします。さくらのVPSとOsukiniサーバの二つのVPSでそれぞれプライマリとセカンダリのDNSを運用します。
ネームサーバはbindのバージョン9.7を使用することにします。CentOS 6.0ではデフォルトです。CenOS 5.6ではデフォルトはbindの9.3なのでbind97シリーズのパッケージをインストールすることにします。yumでbind本体と、chrootで運用するためのbind-chroot、digなどのツールをインストールするためのbind-utilsをインストールします。
bindの設定ファイルは/etc/named.confです。zoneファイルはchrootをしているので/var/named/chroot/var/named/の下におくことになります。今回は次のような方針で設定を行います。
DNSサーバには二つの機能があります。ひとつは自分の管理しているドメインの情報を発信する機能です。これはコンテンツサーバなどと呼ばれます。もうひとつはクライアントのために再帰的に問い合わせて目的のドメインの情報を引く機能です。これはキャッシュサーバなどと呼ばれます。
今回必要なのはコンテンツサーバの機能です。キャッシュサーバの機能はすでに提供されているものをそのまま利用することにします。（つまりresolv.confは変更しません。）
それと、最近のDNSサーバではDNSSECの機能が搭載されています。デフォルトの設定ファイルにもこれらの設定がいくつか見受けられます。しかし、今回はDNSSECの設定は行わないことにします。よく理解していないのでスルーするというのもありますが、まず、デフォルトの設定はキャッシュサーバ用の設定と思われます。今回はキャッシュサーバとしては使用しないのでこれは不要です。コンテンツサーバ用の設定は上位との連携などは必要でさらに難解ですが、ムームードメインにはそういった認証チェーンを連携するインターフェイスは提供されていないようです。
上記の内容で設定したnamed.confは以下のとおりです。実際のドメイン名とIPアドレスは伏字となっています。
options {
listen-on port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
allow-transfer { yy.yy.yy.yy; };
recursion no;
};
logging {
channel "default" {
file "/var/log/named.log";
print-time yes;
};
category "queries" { "default"; };
category "security" { "default"; };
category "default" { "default"; };
};
zone "xxx.net" {
type master;
file "xxx.net";
};
要点を説明すると、まずlisten-onがanyですべてのインターフェイスでポート53でアクセスを受け付けます。IPv6は使用できない環境なので割愛します。allow-querryがanyでどこからでも問い合わせ可能です。allow-transferが可能なのはセカンダリのDNSサーバだけとします。キャッシュサーバには使用しないのでrecursionはnoです。
ログは上記の3つのカテゴリをnamed.logというファイルに取得することにします。 ローテートは他のサーバのログと同様にlogrotatedで行います。そしてゾーンファイルを指定します。ここではドメイン名と同じファイル名にしています。ゾーンファイルの設定については割愛します。
次にセカンダリ側のnamed.confです。基本的にはプライマリと一緒です。ゾーン転送は必要ないのでallow-transferがnoneなのとゾーンの設定が異なります。ゾーン設定はtypeがslaveで、ファイルはプライマリから取得した情報を保存するファイル名を設定します。そしてプライマリのIPアドレスをmastersの項目に設定します。ゾーンファイル自体は不要となります。
allow-transfer { none; };
zone "xxx.net" {
type slave;
file "xxx/euphe.net";
masters { xx.xx.xx.xx; };
};
serviceの開始や、chkconfigおよびiptablesによる通信の許可なども忘れずに行います。
DNSサーバの設定が終わったら、ドメインのDNSの情報を変更します。ムームードメインの場合、コントロールパネルのネームサーバ設定変更のところから、取得したドメインで使用するという上級者向けメニューを選択することで、DNSサーバの設定とそのサーバのIPアドレスの登録が可能です。
設定は以上で完了です。しばらくすると世界中に設定がいきわたるはずです。
以上はDNSの正引きの設定になります。逆引きの設定についてはIPアドレスを管理しているDNSサーバで設定する必要がありますが、さくらのVPSとOsukiniサーバはともに管理画面から逆引きの設定が可能ですので、そこで逆引きの設定を行います。
emacsでUTF-8のファイルを編集する設定
昔とは違い昨今ではLinuxの多言語対応も申し分のない状況だと思います。ssh経由でUTF-8の日本語文字列を入力したときに、特に何も設定しなくてもシェルで日本語のファイル名を扱ったり、viで日本語を編集したりすることが可能です。ただ、emacsはデフォルトのままではUTF-8が文字化けしてしまうようです。設定ファイル.emacsに以下の設定を追加するとUTF-8の日本語がうまく扱えるようになります。
(set-language-environment "Japanese") (set-terminal-coding-system 'utf-8) (prefer-coding-system 'utf-8-unix) (set-keyboard-coding-system 'utf-8)
screenの設定
sshでログインしていろいろ作業をするときにscreenは大変便利です。ひとつの端末の中で複数の端末を切り替えて利用可能です。CLIのマルチウインドウです。詳しくは検索するといろいろ説明があると思います。screenだと一般名詞すぎて検索に引っかからない場合はGNU screenと検索してください。
設定はホームディレクトリの.screenrcに記述します。基本的には初期設定のままでも全然便利に利用できますが、screenの制御コマンドの入力に試用するエスケープキーの設定だけは変更したほうが便利だと思います。デフォルトはCtrl-aです。Ctrl-aを押してから他のキーを押すことでscreenの操作を行います。例えばウインドウの切り替えはCtrl-a Ctrl-a、ウインドウい一覧はCtrl-a wと入力します。
単にCtrl-aを入力したいときはCtrl-a aで入力できますが、Ctrl-aはシェルやemacsで行頭にカーソルを移動するときにわりと頻繁に使用するので、これは結構不便です。そこでお勧めのエスケープキー設定はCtrl-zです。Ctrl-zは通常サスペンドに使用しますが、screenを使って複数ウインドウを切り替えて作業するとサスペンドの使用頻度は低いので、ちょうどよい設定だと思います。
設定ファイル.screenrcでは以下のように設定を記述します。
escape ^zz
設定ファイルを作成せずに一時的に使用したい場合は、コマンドラインから以下のようにオプションを指定してscreenを起動することも可能です。
$ screen -e ^zz
あと、TeraTermなどからログインしてscreenを起動したときに、ウインドウのサイズを勝手に変更されてしまう場合があります。自動で変更されるのを防ぐには以下のような設定を行うようです。
まず、自分がログインしたときの環境変数TERMの値を確認します。printenv TERMなどで確認できます。例えばxtermだったとすると以下のようにxtermのときのtermcapinfoを設定ファイル.screenrcに記述します。
termcapinfo xterm 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'
これで勝手にウインドウサイズが変更されないはずです。
公開鍵認証でsshを行う設定
sshでサーバにログインして作業することはたびたびあると思いますが、そのたびにパスワードを入力するのは非常に面倒です。またスクリプトなどで他のサーバにアクセスする場合にはそもそもパスワードを入力することができません。
公開鍵認証でsshを利用すると、最初の設定が終われば、以後パスワード入力なしでsshが可能となります。秘密鍵はパスフレーズで暗号化することができますが、ここではパスフレーズは設定しないものとします。
準備は非常に簡単です。まず以下のコマンドで公開鍵を作成します。パスフレーズや作成するファイル名を聞かれますが、ここではすべてデフォルトで改行を入力します。
$ ssh-keygen
すると~/.ssh/の下に公開鍵id_rsa.pubと秘密鍵id_rsaが作成されます。このうち公開鍵をid_rsa.pubをサーバに設定すれば設定は完了です。秘密鍵は他の人に見られないように気をつけます。
公開鍵をサーバにコピーした後に、以下のコマンドで認証に使う鍵に追加します。以上で設定は完了です。パスワード入力なしでsshが可能になっていると思います。うまくいかない場合には、.sshディレクトリを手動で作成した場合などは、パーミッションが自分以外から見えるようになっていないかなど確認してください。
$ cat id_rsa.pub >> .ssh/authorized_keys
公開鍵認証のみでログイン可能にする
サーバに不法侵入されるというようなトラブルは、なんらかの方法でアカウント情報が漏洩してしまったか、もしくは認証が破られてしまった場合に発生するわけですが、現実問題として暗号を解析してパスワードを解析されたり、システムがクラックされて情報が盗まれたりすることはほとんどありません。
それではなぜ侵入されてしまうかというと、パスワードが十分に安全ではないので機械的な辞書攻撃などで破られてしまうのです。それを防ぐためには、そのサーバに存在するすべてのユーザが十分に強度のあるパスワードを設定すればよいわけですが、それを徹底するのは簡単でありません。テスト用に作成したアカウントが消し忘れていた場合などもあります。
sshでパスワードによるログインを禁止し、公開鍵認証のみを使うようにするとその問題が一気に解消されます。すべてのユーザが十分に強度のある公開鍵というものを使ってのみ認証するからです。
sshサーバの設定は/etc/ssh/sshd_configにあります。以下のような設定項目があり、デフォルトではyesになっていますが、これをnoに変更することでパスワードによるログインを禁止できます。設定の変更後はsshdの再起動が必要です。
PasswordAuthentication yes
これは非常に簡単です。上記のようにパスフレーズなしの鍵を使用すれば、sshのログインの際のパスワード入力も不要となり手間も削減できるので、セキュリティ対応で面倒になるわけでもありません。
唯一気をつけなければいけない点は、あらかじめ鍵を登録しないとログインできないことです。上記設定を変更する前には既存のユーザは鍵の設定を完了しておく必要があります。また、新しく作成されたユーザはログインできないので管理者に鍵を登録してもらう必要があります。
パスワードなしでsuをする方法
sshでサーバにログインして管理をするときに、一般ユーザでログインをしてからsuでrootになるというのはよくあるパターンだと思います。
通常はそのときにrootのパスワードを入力する必要がありますが、パスワードを入力しなくてよいように設定することも可能です。毎回rootのパスワードを入力するのが面倒という場合にも適していますが、root権限は与えてもよいがrootパスワードは教えたくないユーザがいる場合にも活用できます。
必要な設定は次の二つです。まず該当するユーザをwheelグループに追加します。そのユーザのデフォルトのグループは/etc/passwdに設定されていますが、追加のグループは/etc/groupに設定があります。/etc/groupに以下のような行があると思います。これがwheelグループのメンバーです。最初はrootユーザだけのようです。この後ろにカンマで区切ってユーザ名を追加します。
wheel:x:10:root
次に/etc/pam.d/suを編集します。Linuxでは認証を行うのにPAMというモジュールが利用されていますが、このファイルはそのうちsuを行うときの設定になります。このファイルには以下のような行があると思います。
# Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient pam_wheel.so trust use_uid
コメントにしたがってこの設定を有効にすると、めでたくwheelグループのユーザはパスワード入力なしにsuが可能となります。
CentOSをインストールして最初にする設定
サーバにOSをインストールしたあとで、最初にいろいろと設定が必要になります。サーバ自体の設定もありますが、管理を行うための環境の設定もあるでしょう。備忘のために今回行った設定を記録します。
CentOSは最初構成でインストールしていますので、必要なソフトはその都度yumでインストールします。最初からいろいろいれるより必要最低限にするがシンプルでよいと思います。yumでのインストールは非常に簡単ですし。
CentOS 6.0で驚いたのが最小構成にsshが含まれていないことです。もちろんsshサーバは含まれています。クライアントが含まれていないのでいきなりscpをしようとするとエラーになります。openssh-clientsパッケージをインストールします。
まずは環境を整えます。ログイン用の自分のアカウントを作成します。useradd -m hogeです。個人的なお勧め環境はscreenとzshです。エディタはemacsとvim-enhancedを両方入れておきます。そしてsshの鍵を~/.ssh/authorized_keysに追加します。
そしてネットワークの設定などをします。/etc/sysconfig/networkのHOSTNAMEにホスト名を設定します。/etc/hostsも変更します。/etc/resolv.confもインストール時にはひとつしか指定しないので追加します。IPv6は使えないみたいなので設定しませんが、デフォルトでついてるリンクローカルはそのままにしておきます。/etc/sysconfig/iptablesでiptablesの設定も変更します。最初はsshしか許可されていませんが、同様に他のサービスも許可とします。
selinuxは面倒なので使わないことにします。/etc/sysconfig/selinuxをdisabledに変更します。あとディスク容量は余裕があるので/etc/logrotate.confを変更してログの保存件数を増やします。デフォルトでは4週のローテートですが半年くらいに変更しておきます。
以上はさくらのVPSにインストールしたCentOS 6.0の作業ログですが、SaaSesのCentOS 5.6もほぼ同様にします。そして念のためユーザアカウントのuidをそろえておきます。SaaSesの環境にはデフォルトで作成されているユーザがあるので何も考えずにuseraddするとひとつずれてしまいますが、いったんデフォルトで作成されているユーザを削除してから作業します。
SaaSes Osukiniサーバ
OsukiniサーバというのがSaaSesのVPSです。個人的にこういうネーミングセンスは好きではありませんが。しかし値段が安いと言うのは間違いありません。
VPS比較のときにも書きましたが、コンソールがないのが不安要素です。メニューは起動や終了、再インストールのほかにiptablesなど特定の設定のみ管理ページから実行可能です。
デフォルトのインストール時にWebminおよびEC-CUBEのインストールも選択できますが、どちらも使うつもりはなく、スペックも最低限のものを選んでいるのでインストールしませんでした。ちなみにWebminはウェブ上でUnixの設定など仮が行えるシステムで、EC-CUBEはネットショップなどが作れるフレームワークのようです。
話がそれますが、EC-CUBEについて検索してみると評判はあまりよろしくないようですね。ぱっと見たときよくできてるなと思いましたが、よくできているのは見た目だけで使い勝手はいまいちなようです。また実装もかなり程度の低いもののようです。
さくらのVPSにはCentOS 6.0をインストールしましたが、こちらはコンソールもないのでCentOS 5.6のまま使うことにしました。
Osukiniサーバで特筆すべきはディスク容量です。月450円の格安プランでも50GBもあります。今までサーバ上のデータはローカルのパソコン上にバックアップしていましたが、さっそくサーバ上にバックアップすることにしました。ほぼバックアップのためだけに手元のWIndow上にVirtualBoxをインストールしてLinux環境を維持してきましたが、これでさっぱり削除できます。
仮想マシンモニタは同時にひとつしか起動できないので、XPモードを使おうとするとVirtualBoxは出番が少なかったので、退役させるいい機会になりました。結局仮想化というのはコンピュータの抽象度を一階層追加して、これまでOSがひとつしか動かせないものだったのがモニタがひとつしか動かせないものに変わったということだという話をつらつらとしたいとか思いましたが今回はこの辺で。
さくらのVPSにCentOS 6.0をインストール
さくらのVPSのデフォルトのOSはCentOS 5になってます。VPSコントロールパネルから他のOSのインストールもできるようですが、そもそもコンソール機能があるので普通にいろいろなOSをインストールすることが可能です。
といわけでCentOSの最新版であるCentOS 6.0を使うことにしました。CentOS 6はリリースまでにすごく時間がかかったり、主要な開発者であるDag Wieersが開発から離脱したり（あのDAGですよ？）、先行きが不安なところもあるかもしれませんが、他にこれといった選択肢もないので、ここではとにかくCentOS 6.0をインストールすることにします。
インストール手順については、ずばり以下のサイトにあります。
上のサイトにもありますが、ネットワークの設定はメモって置く必要があります。最悪忘れてしまってもデフォルトのCentOSを再インストールすると確認できます（５分程度です）。共通の設定項目についてはマニュアルにも載っています。DNSサーバの設定が実際と違っていたのが若干気になりますが。
インストールは選択肢も特になくすぐに終了します。普通にインストールしたときにはディスク構成やパッケージなどもう少し選べるところがあった気がしますが、シリアルコンソールからのインストール専用のメニューなのかもしれません。
インストールが終了するとあとは普通に使うことができます。とりあえずアップデートをあてて、あとは必要なパッケージのインストールともろもろの設定を行っていくことになります。
共用サーバから乗り換える格安VPS
独自ドメインで自分のウェブサーバやメールサーバを運用するだけであれば共用サーバでも十分なわけですが、デフォルトで入っていないツールが使いたい時など、できないわけじゃないけど共用サーバなので非常に手間がかかるのであきらめてしまうということが少なからずあったりする。そこで、この機会にVPSに乗り換えようかと思い立ったわけだ。
とはいっても今使っているさくらインターネットの共用サーバは、共用とはいってもマルチドメインが使えて、PHPもMySQLも使えて、sshでログインできて、しかも料金は年5000円という低価格。そこから乗り換えることを考えると価格を重視してVPSを探さなければということになる。
しかし、検索するとすばらしい比較サイトがあり、結論からいうとここを見ればだいたい事足りると言っていいだろう。ここもすばらしい比較サイトで、妥当性はわからないが性能についてのベンチマーク結果もあり非常に参考になる。ただ、さくらの社長が書いているものなので、ここで手放しにほめるのもあれだとは思う。
他にも検索してみたが、格安で選ぶとなると上記サイトの3つの候補、さくらのVPS・SaaSeSのOsukini Server・ServersMan@VPSの3つですべてである。ServerQueenというところもあったが、ServersManと似たような内容なので対象外とする。
ここでServersManと似ているという理由で簡単に切り捨てたのにはわけがあって、OpenVZによる仮想化はVPSとしてはいまいちだからだ。OpenVZではXenやKVMによる仮想化と異なりマシンレベルでは仮想化されていない。そのため集約度が高いという利点はあるが、仮想化は完全ではなく、共用サーバの共用であると言う部分が理由で乗り換えるときに選択肢としては不適切だろう。
というわけで選択肢はさくらとSaaSesの2つとなる。SaaSesは値段が圧倒的に安いが、初期費用がかかるのが欠点である。また、さくらにはコンソールがあるがSaaSesにはコンソールがないというのが圧倒的に心配である。さくらの方が実性能はよいらしいが、SaaSesはディスク容量が圧倒的である。
上記のように一長一短ではあるが、コンソールがないというのは設定ミスなどでネットワークからログインできなくなるとデータをすべて捨てて再インストールしか手段がないということで、メールも含めてドメインを運用するには不安と言うことでメインはさくらにすることにした。ちなみに、普通に考えれば仮想サーバなのでディスクイメージのバックアップとリストアという運用がよいのだが、格安のVPSでそういったものに対応しているのはないようだ。
実はさくらのVPSは以前にも試用したことがあるのだが、同じアカウントで今回契約してみると再度試用期間があった。細かいことだが得した気分である。上で”メインは”と書いたのは実は意味があって、SaaSesのほうも契約したのだ。サーバ2台体制でバックアップなどディザスターリカバリーを考慮して運用していきたい。