A Day In The Boy's Life -56ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

一昔前ならシステム構築の手間って膨大な時間と労力をつぎ込んで作るものってイメージがありました。

例えちょっとした機能変更でさえも、開発側の担当者は「それは多くの機能に影響を与えるからかなり時間がかかる」とか何かと理由を付けて拒む姿勢もよく見かけました。

まぁ、これは担当者が面倒くさがっていたり、品質や納期の観点からこの時期にその要求を受け入れるリスクを嫌っていってたのかもしれません。


しかし、今ではその労力というのはだいぶ軽減されてきています。

もちろん要件の規模によりますけど、その一部の機能を構築するのにも昔に比べたらはるかに楽になっているでしょう。

技術の標準化や多様なライブラリ、ネット上に発信される多くのノウハウ、IDEなど開発環境の進化などその理由は多々ありますが、そういった開発コストの低下の中で思うのは、システムを構築する手間っていうのはもはや構築をする側より仕様を決める側の方が大きく、ボトルネックってむしろ提案側になってしまっているのではないかと感じたりもします。



開発プロセスとボトルネックが発生する場所の変化


この話はもちろん「一般的な」って枕詞が付くので、世の中にない先進的なサービスを作ろうとした場合は、その限りではありません。

まぁ、世の中にない先進的なサービスってのは多くは、それを生み出す技術が根幹にあったりして、そういうのって提案側と構築側が一緒になってたりもするのですが、ボトルネックが発生する場所としては同じかもしれませんけど。


要は、こういった問題を解決するためのサービスを提供し、その仕様としてこういうシステムを作りたいってのがあった場合に、その要求を取りまとめる側の方が今や多くの時間がかかったりします。

これは、別に今に始まったことではありません。

ただ、昔のようにウォータフォールモデルのシステム開発手法を主としていた頃には、要件定義に多くの時間を割くものの、それが終わってしまえば後は製作をスケジュールどおりに進めていくというスタイルのため、要件定義の遅れは製作全体がシフトするということで済みましたが(プロジェクトとしては済みませんけど)、今や製作にかかる時間が短縮され、機能構築をスパイラルに進めていくようなやり方を取ることが多くなってきた中で、要求が出てこないというのは、個々の製作が始まっているため、問題が大きくなりがちです。


機能ごとに要件決めとその構築を短い期間でまわしていくことになると、そのイテレーションの中では、都度提案側から要求を貰うことになりますが、提案側から出てくる要求というのは、構築期間より長く時間がかかることが多くあります。

元々、要件定義自体は開発プロセスに関わらず多くの時間が費やされます。

要求そのものを取りまとめることになるので当然なのですが、開発プロセスの変化に要求をまとめるプロセスが追いつけてない事は多いのではないでしょうか。


この要求をまとめるプロセスというのは、業務プロセスをモデル化するということもそうですし、具体的にITを頼って何をしたいのかという目的設定もそうですし、じゃあそのシステムっていうのはどういったもので、誰がどんなシーンで利用するものなのかっていうのもそうです。

業務プロセスをモデル化するってのは、過大や要求からシステム部門が作業を請け負うことも出来るでしょうが、もっと根本的な目的設定とかどんなシステムやサービスを作りたいのかってイメージが頭の中に思い描けてなかったりするのは、開発プロセス上では結構大きな問題だったりします。



提案要求をまとめるときに気をつけたいこと


IT自体がコモディティ化した今は、それを取り扱う人は専門家だけではありません。

人事や総務などの管理部門にいる人や、そのサービスを望んでいるが技術には全く詳しくないという人まで、「こういったものを作りたい」という漠然としたイメージしか持ってない人が提案側のメンバーとして入っています。


提案書の中には、たどたどしい感じで画面設計や状態遷移や機能要件などが盛り込まれていますが、実際それを具体的に頭の中でイメージできているのは、あまりいないのではないでしょうか。

要は、実際に動かしてみないとわからない、という人が多いということです。

あとは、体制の話で「取り合えずチームで検討します」と言って決定までに1週間かかるとか。


こういった状況に追い込まれないためにも、提案側との要件決めには幾つか留意しておくことがあります。


・ 何を解決したい(作りたい)のかということを双方ちゃんと理解する


提案側から出された要求書は大体システムありきで書かれていて、それがなんの役に立つのかってことが頭の中から飛んでたりもします。

一昔前なら開発側で偏った思考によって起きる問題が今や提案側で起きてたりもします。


・ 最低限作りたいものは何なのかを理解しておく


提案側は、色んな機能を詰め込みたがりますが、それによって何時までもリリースできないプロジェクトを続けたり、時間がかかることで当初の目的がずれてくることもあるので、最低限何を実現してそのためにどんな機能が必要なのかをちゃんとヒアリングしておいた方がよいです。

もしそれが出来たなら、その時点で一旦リリースしてしまうということで、運用を開始することで得るものも数多くあったりします。


・ 提案された設計はゼロベースで考え直す


一旦向こうから提案された画面イメージとかは忘れて考え直すのも視野に入れてた方が良かったりします。

目的設定がずれていたら、何も解決しないシステムを作るだけになってしまいますので。


・ 共有イメージを持っておく


今や似たようなサービスというのは数多く存在するので、事前に「このサイトみたいなレイアウトですかね?」とか、この機能というのは「このサイトのこの部分のようなイメージですか?」ってことを共有しておくと楽になります。


・ なるべく早く動くものを共有しておく


提案側にある漠然としたイメージをより具体化するためにも、早めに動くものを見せておいた方がよいでしょう。

これは、裏側が張りぼての機能がない状態でも問題ありません。

気にされるのはだいたい画面上のUIであり、裏側の状態遷移やロジックというのは気にされません。(というか「そこは良いようにやってよ」ってまかせっきりになってたりもしますので)


・ 決定権を持つ人を巻き込んでおく


ボトルネックになるのが偉い人へのお伺いだったりするので、予めそういった決定権を持つ人も巻き込んでシステムレビューを進めた方が話が早かったりします。

仕様の決定、製作、確認(確定)と製作の過程で間に2つの確認事項が含まれるのでそれに割かれる時間というのは馬鹿になりません。


・ システム構築には時間がかかるという概念を払拭しておく

もちろん、全体を通しては長い時間がかかるプロジェクトにはなりますけど、先に書いたように機能一つ一つにかかる時間はそれほど多くはなくなってきています。

ボトルネックが提案側に移ってきているので、さっさと作って見せたところで仕様確認に時間がかかり、先に進めなくなる事態に陥ることも多々あります。

ある程度の目処を早めに伝え、提案側にタスク期限を明確にしておくことでボトルネックの解消につなげることもできるかもしれません。



まとめ


開発の主導者が変遷していく中で、それに適した開発プロセスというものも求められてきていますし、問題が発生するポイントも変化してきています。

サービスの構築は、システム担当者だけでということも行かない時代になってきていますし、それは別に面倒なことが増えたというよりは、より多くの可能性を広げているとも捉えられます。


ただ、構築が楽になったとは言っても話が二転三転されたりすると、納期だけでなく開発側にも大きなストレスとなりますので、提案側と構築側のギャップを埋めてうまく進めていく仕組みづくりというものにも気を使わないといけないと感じたりします。




[お名前.com] サービスを構築するまでに行ったサーバー設定作業もろもろ 」の続き。

次は、メール関係の設定です。

Postfixを使ってSMTP-Authによるメール送信とメール転送設定を行います。

メールサーバーの設定作業


・ 必要なパッケージのインストール


メール送信には、Postfixを使います。

また、SMTP-Authに対応するためにcyrus系のパッケージを追加インストールします。


# yum install postfix.x86_64
# yum install cyrus-sasl-devel.x86_64
# yum install cyrus-sasl-plain.x86_64
# yum install cyrus-sasl-md5.x86_64

・ main.cfファイル編集


メールを送信するためのPostfix設定作業を行います。

なお、メールのリレー先のサーバーなど、お名前.com用の設定が混じってます。

下記、詰めて編集箇所のみを書いてますので、実際の設定ファイル(/etc/postfix/main.cf)内から、適宜該当箇所を修正してください。

また、設定箇所が無い場合は追記します。


myhostname = smtp.example.jp
mydomain = example.jp
myorigin = $myhostname
inet_interfaces = all
#inet_interfaces = localhost
mydestination = localhost.$mydomain, localhost, $myhostname
mynetworks = 127.0.0.0/8
home_mailbox = Maildir/

#virtualmailbox setting
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:6001
virtual_gid_maps = static:1000
virtual_mailbox_domains = hash:/etc/postfix/virtual_domain_maps
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

#smtpauth setting
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions =
   permit_sasl_authenticated,
   permit_mynetworks,
   reject_unauth_destination,
   reject_invalid_hostname,
   reject_non_fqdn_recipient,
   reject_non_fqdn_sender,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   reject_unauth_pipelining
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd

#ssl
smtpd_use_tls = yes
smtpd_tls_key_file = /etc/pki/tls/certs/mail.pem
smtpd_tls_cert_file= /etc/pki/tls/certs/mail.pem
smtpd_tls_loglevel = 1
smtpd_tls_recived_header = yes
smtpd_tls_session_cache_timeout = 3600s
broken_sasl_auth_clients = yes

relayhost = [mailgw.vps.gmoserver.jp]


・ vmailユーザーの作成


main.cfファイルの「#virtualmailbox setting」の項目で記載しているvmailユーザーを作成します。

なお、ユーザーIDとグループIDは予め指定して作成します。


# groupadd -g 1000 vmail
# useradd -u 6001 -g 1000 -d /var/vmail -s /sbin/nologin vmail

・ virtual_alias_maps、virtual_domain_maps、virtual_mailbox_mapsファイルの作成


main.cfファイルの「#virtualmailbox setting」の項目で記載しているvirtual_alias_maps、virtual_domain_maps、virtual_mailbox_mapsの3ファイルを作成します。

virtual_alias_mapsファイルでは、バーチャルユーザーのメールの転送設定(メールのエイリアス設定)を行います。


##### virtual email alias list #####
webmaster@example.jp itboy.org@gmail.com

上記のように設定することで、webmaster@example.jp 宛のメールを別の個人のメールアドレスへ転送することができます。


virtual_domain_mapsファイルでは、バーチャルドメインのリストを記述しておきます。


##### virtual domain list #####
example.jp OK

最後のvirtual_mailbox_mapsでは、バーチャルユーザーのメールボックスのパスを指定します。


##### virtual email mailbox list #####
webmaster@example.jp example.jp/webmaster/Maildir/


ファイルの作成後は、postmapコマンドを利用してDBファイルを作成します。


# postmap virtual_alias_maps virtual_domain_maps virtual_mailbox_maps

これで、virtual_xxxx_maps.dbファイルが作成されます。


・ 証明書および秘密鍵の作成


main.cfファイルの「#ssl」の項目で設定した独自の証明書と秘密鍵ファイルを作成します。


# cd /etc/pki/tls/certs
# make mail.pem

下記のように証明書に埋め込む情報を幾つか質問されるので、適宜情報を入力します。


Country Name (2 letter code) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:Shibuya
Organization Name (eg, company) [My Company Ltd]:Foo
Organizational Unit Name (eg, section) []:Bar
Common Name (eg, your name or your server's hostname) []:example.jp
Email Address []:webmaster@example.jp


・ master.cfファイルの編集


Postfixのもう1つの重要な設定ファイルであるmaster.cfファイルを編集します。

master.cfファイルでは接続方式やデーモンの挙動を定義するファイルになっています。


submission inet n       -       n       -       -       smtpd
  -o smtpd_enforce_tls=no
  -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#cyrus     unix  -       n       n       -       -       pipe
#  user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}


・ smtpd.confファイルの編集


SASLの設定ファイル「/usr/lib64/sasl2/smtpd.conf」を編集して、SASLのパスワードファイルを利用するように設定します。


pwcheck_method: auxprop

・ ユーザーとパスワードの設定


メールアカウントとそのパスワードを設定します。


# saslpasswd2 -u example.jp webmaster

メールアカウントが作成されたか確認しておきます。


# sasldblistusers2
webmaster@example.jp: userPassword

ユーザーリストを作成すると/etc/sasldb2ファイルが出来上がるので、権限を変更しておきます。


# chown root:postfix /etc/sasldb2

・ デーモンの起動


一通り設定が終わったのでPostfixとSASLのデーモンを起動します。


# /etc/init.d/postfix start
# /etc/init.d/saslauthd start

自動起動するように設定するのもお忘れなく。


# chkconfig --level 3 postfix on
# chkconfig --level 3 saslauthd on

・ メールサーバーへの接続確認


最後に、メールサーバーへの接続確認を行います。

まずは、telnetを使った接続・認証テストです。


# telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 smtp.example.jp ESMTP Postfix
EHLO localhost
250-smtp.exapmle.jp
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN CRAM-MD5 LOGIN DIGEST-MD5
250-AUTH=PLAIN CRAM-MD5 LOGIN DIGEST-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH CRAM-MD5
334 PDIxNzY5NTM1MTUuMTM1MjY4MzdAc210cC5pbmRvZy5qcD4=
d2VibWFzdGVyQGV4YW1wbGUuanAgN2FjOGIxNGQ5YzQxZGUzZTI4MDc3ZDYxOTlkYzgzMzI
235 2.0.0 Authentication successful

※ ハイライト箇所は手動で入力した箇所です。


ちゃんと認証が成功しました。

CRAM-MD5による認証方法(MD5ダイジェストの作成)に関しては、下記のサイトを参考にさせていただきました。


telnetでsmtp-auth @ Kung Noi


コードは、「AUTH CRAM-MD5」と入力した後に返ってくる「334 XXXXX」の部分(334以降)を指定します。

なので、2つ端末を開いて一方でtelnet接続し、もう一方で上記サイトで紹介されているPerlスクリプトのコード部分に埋め込んで結果を貼り付けたりすればよいかと思います。


次に、PHPからメール送信テストを行います。

SMTP-AUTHを通して、メールを送信するためPEARパッケージを使います。


# pear install Mail
pear install Net_SMTP


メールを送信するPHPプログラムは、下記のサイトを参考にしました。


How to Send Email from a PHP Script Using SMTP Authentication @ about.com


<?php

require_once "Mail.php";

$from = "webmaster <webmaster@example.jp&>";
$to = "Foo <foo@bar.com>";
$subject = "Hi!";
$body = "hello world";

$host = "smtp.example.jp";
$username = "webmaster@example.jp";
$password = "HogeHoge";
$port = "587";

$headers = array ('From' => $from,
  'To' => $to,
  'Subject' => $subject);
$smtp = Mail::factory('smtp',
  array ('host' => $host,
    'auth' => true,
    'port' => $port,
    'username' => $username,
    'password' => $password));

$mail = $smtp->send($to, $headers, $body);

if (PEAR::isError($mail)) {
  echo("<p>" . $mail->getMessage() . "</p>");
} else {
  echo("<p>Message successfully sent!</p>");
}

長くなってしまいましたが、これで一通り設定完了です。






ひょんなことからお名前.comのVPS環境に触れる機会があったので、その上でシステムを作るまでに行ったサーバー設定作業のメモを残しておきます。

システム自体は、PHPアプリが動くことを想定しています。

お名前.com用の設定を基本としていますが、その他のサーバーでも応用できるかと思います。


なお、記事が長くなってしまったので2回に分割しています。

後半は、メール設定作業 をまとめています。



サーバー周りの設定作業


・ OSを変える


デフォルトはCentOS5.3だったのですが、CentOS5.5へ(最終的にはyum updateで5.7へ)変更しました。

OSが古いというよりは、デフォルトの5.3環境の場合、お名前.comのコントロールパネルが結構権限を握っていて自由度が低かった、というのが変更理由です。


Apacheの設定ファイルも別の場所に用意されていてDocumentRootも変更できないような感じになっていましたので。

まぁその分、iptablesの設定やメール設定とかはコントロールパネルからできなくなるので、運用の手間は増えてしまいますが。

コマンドラインからガリガリと設定ファイル変更するのは苦手という場合は、デフォルトのOSのまま利用していた方がよいかと思います。


OSの変更は、コントロールパネルから行います。


※ 必要があれば、事前にちゃんとバックアップを取っておきましょう。


A Day In The Boy&#39;s Life-お名前.comコントロールパネル-1


・ パッケージのアップデート


取り合えず、


# yum -y update

で、全パッケージをアップデート。

これによりCentOS release 5.7 (Final)へアップグレードされます。


# more /etc/redhat-release
CentOS release 5.7 (Final)

・ 必要なパッケージを追加インストール


PHPやPostgreSQLやvsftpdなど。

この辺は、サービスで利用したいパッケージを適宜インストールします。


# yum install php53.x86_64


あと、PHPでPEARを使いたいので追加インストール。

ただし、x86_64のパッケージが用意されていないみたいなんで、下記のようにnoarchのPEARをインストールした後に強制的にアップグレードしました。


# yum install php-pear.noarch
# pear upgrade --force PEAR

途中でereg系の関数を利用してエラーが出まくりますが、アップグレード自体は完了します。


# pear list
Installed packages, channel pear.php.net:
=========================================
Package          Version State
Archive_Tar      1.3.8   stable
Console_Getopt   1.3.1   stable
PEAR             1.9.4   stable
Structures_Graph 1.0.4   stable
XML_RPC          1.5.0   stable
XML_Util         1.2.1   stable

・ yumのアップデート除外設定


運用開始後は、何でもかんでもパッケージをアップデートしてたらバージョンアップによってトラブルが起きたりするので、アプリに蜜に連携するパッケージを取り合えずアップデート対象外にしおきます。


exclude=kernel* php* httpd* postgresql*

・ yumの自動アップデート設定変更


とはいえ、毎回新しく出たパッケージを1つずつ確認していくのも手間なんで、関係なさそうなパッケージは自動アップデート(実際には、パッケージのダウンロードだけで適用させませんが)を設定しておきます。


まず、yum-updatesdパッケージをインストール。


# yum-updatesd.noarch

次に、設定ファイルを編集します。


# yum updateの実行間隔(秒)
run_interval = 86400
updaterefresh = 6000

# アップデートがあった場合の通知方法(E-Mail)
emit_via = email
email_to=webmaster@example.jp
email_from=yum-updatesd@localhost
smtp_server=localhost:25

# 更新があった場合、関連するパッケージも含めてダウンロード(ただし勝手にアップデートしない)
do_update = no
do_download = yes
do_download_deps = yes

最後に、yum-updatesdのデーモンを起動。


# /etc/init.d/yum-updatesd start

・ logrotate.conf設定変更


デフォルトだと4週分しかログが保存されないので変更(24週分保存へ)


rotate 24

あと、/var/log以下でほっとくと大容量になってしまうログファイルを幾つかローテーションの対象へ追加。


/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron /var/log/btmp /var/log/lastlog /var/log/wtmp {
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
        /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

・ SSH設定変更


お名前.comの場合、デフォルトの状態で作業用ユーザー(vpsXXXXXXXX)が作られてたりしますが、ユーザー名が覚えにくいので、別のユーザーを追加しそのユーザーSSH接続できるようにします。


# useradd -m -d /home/hogeuser -s /bin/bash hogeuser
# passwd hogeuser

続いて、セキュリティを考慮してSSHできるユーザーを限定し、利用するポートを変更しておきます。

(ポートを変えるだけで単調なアタックをかなり防げたりもします)


Port 10022
AllowUsers vpsusername hogeuser

※ iptablesの設定が済んでいないので、この時点でSSHDを再起動するとサーバーへ接続できなくなります。


より、サーバーをセキュアにするなら公開鍵認証方式 を取るのもよいかもしれません。


・ FTP設定変更


標準のCentOS5.3だとProFTPDを利用しているのですが、個人的な好みでvsfptdを利用します。

OSユーザーを使うのではなく、バーチャルユーザーを使ってFTP接続させるように設定を変更します。

設定方法は、以前に書いた「OS上にいないバーチャルユーザーを使ってFTP接続する 」を参照。


なお、FTP接続はパッシブモードで30000番から31999番ポートまでを利用しています。

設定方法は、「FTPのアクティブモードとパッシブモード + vsftpdでの設定方法 」を参照。


・ iptables設定


お名前.comの場合、CentOS5.5へ変更してもデフォルトで幾つかファイアーウォールの設定が既にされていたりもするんですが、SSHのポートを変えたり、FTP用のポート(30000 ~ 31999番ポート)を開放をしておきます。

あと、後述するメール設定のためにサブミッション・ポート(587)も許可しています。


# iptables -A INPUT -m state --state NEW -m multiport -p tcp --dports 20,21 -j ACCEPT
# iptables -A INPUT -m state --state NEW -m multiport -p tcp --dports 30000:31999 -j ACCEPT
# iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 10022 -j ACCEPTiptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPTiptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
# iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT

設定が終わったら確認し、不要なポートを削除しておきます。


# iptables -L --line-number
Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere
2    REJECT     all  --  anywhere             127.0.0.0/8         reject-with icmp-port-unreachable
3    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
4    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
5    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:smtp
6    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http
7    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:pop3
8    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https
9    ACCEPT     tcp  --  anywhere             anywhere            state NEW multiport dports ftp-data,ftp
10   ACCEPT     tcp  --  anywhere             anywhere            state NEW multiport dports 30000:31999
11   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:10022
12   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http
13   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https
14   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:submission

Chain FORWARD (policy DROP)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere

今回、SSHのポートを変更していますので22番ポートを削除しておきます。

iptablesのフィルタ削除は、下記のように左端に表示される番号を指定して削除できます。


# iptables -D INPUT 4

設定が完了したら、iptablesの設定を保存しておきます。


# service iptables save

念のために、iptablesのデーモンを再起動してフィルタが正しいかと、別の端末からSSHやFTPでサーバーへ接続可能かを確認しておきます。

接続できない場合、SSHDやvsftpdの設定かiptablesの設定に誤りがある可能性があります。

全ての端末を閉じてしまうと、二度とサーバーへ接続できないという自体にもなりかねないので注意が必要です。(実際、やってしまいましたし・・・)


・ デーモンの自動起動


追加でインストールしたパッケージや必要なデーモンを自動起動するように設定しておきます。


# chkconfig --level 3 vsftpd on
# chkconfig --level 3 httpd on
# chkconfig --level 3 rsyslog on

・ 不要なデーモンの停止


さっきとは逆に、不要なデーモンが起動しないように停止しておきます。


# chkconfig mcstrans off
# chkconfig lvm2-monitor off
# chkconfig netfs off
# chkconfig rawdevices off
# chkconfig iscsi off
# chkconfig iscsid off

この辺は、環境によって異なると思いますので、chkconfig --listで結果を見て不要なものを適宜停止していきます。


余談にはなりますけど、iscsiとiscsidデーモンを起動していたら/var/log/brcm-iscsi.logに毎秒ごとに下記のようなエラーが吐き出されてかなり大きなファイルとなっていました。


ERR [Sun Nov 20 22:17:08 2011]NIC_NL waiting binding to NETLINK_ISCSI socket
ERR [Sun Nov 20 22:17:09 2011]NIC_NL waiting binding to NETLINK_ISCSI socket

実害は無いと思ってたんですが、上記のような理由から停止しました。


・ sysstatの設定


サーバーに異常があったときにその際の状況を確認したいという場合がありますので、sarコマンドでCPUの統計を取れるようにしておきます。


# yum install sysstat.x86_64

デフォルトだと10分ごとに統計が取られますが、もう少し間隔を短くしたいのでCronで定期実行されている設定を変更します。


# run system activity accounting tool every 5 minutes
*/5 * * * * root /usr/lib64/sa/sa1 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

コマンドの使い方などについては「サーバー管理で知っておきたいコマンドあれこれ。 - sysstat編 - 」を参照。


・ logwatchの設定


サーバー上には大量のログが出力されますが、それを1つずつ確認するのはかなり手間になります。

なので、Logwatchを使って問題のありそうなログのレポートを送ってもらうようにします。


# yum install logwatch.noarch

次に、レポートの詳細やメールの送信先を設定します。


MailTo = webmaster@example.jp
Detail = Med

ログの見方などは、「Logwatchでサーバー上のログを集約する 」を参照。