2008年09月05日
カーネルバージョンの確認
カーネルバージョンをコマンドで確認する場合は uname コマンドを使用します。
カーネルバージョンに関する情報は /proc/version ファイルに記録されています。
OSバージョンの確認
OSバージョンに関する情報は、Fedora Coreでは、/etc/fedora-release ファイルに、Red Hat Enterprise Linuxでは /etc/redhat-release ファイルに記録されています。
2008年06月02日
mysqlユーザ設定
mysqlのユーザ設定あれこれです。
# mysql -u root -p xxxxxxxx
mysql> grant all privileges on *.* to root@localhost identified by 'xxxxxxxx' with grant option;
mysql> flush privileges;
mysql> grant all privileges on *.* to root@localhost identified by 'xxxxxxxx' with grant option;
mysql> flush privileges;
Movable Type mysqlユーザーの作成
MySQL にログインして、ユーザーを作成します。
たとえば、ユーザー名を mtuser、パスワードを mtpasswd とする場合です。
# mysql -u root -p xxxxxxxx
mysql> grant all on mt.* to mtuser@localhost identified by 'mtpasswd';
mysql> grant all on mt.* to mtuser@localhost identified by 'mtpasswd';
[mysql]rootのパスワード忘れ
rootユーザーで行います。
いったんmysqlを停止し--skip-grant-tablesオプションをつけてmysqlを起動し、パスワードを変更します。
その後mysqlを停止し、通常の方法で起動させます。
# /usr/bin/mysqld_safe -u root --skip-grant-tables &
# mysql -u root
mysql> select user,host,password from mysql.user;
mysql> update mysql.user set password="" where user = "root";
# mysql -u root
mysql> select user,host,password from mysql.user;
mysql> update mysql.user set password="" where user = "root";
2006年12月28日
サーバ接続の冗長化
サーバ接続の冗長化には、NICチーミングと呼ばれる、NICを冗長化させる障害対策手法がとられます。NICチーミングには大別して次の三つがあります。
①NICテイク・オーバー
②イーサネット・チャネル
③スパニング・ツリー・プロトコル（STP）
①NICテイク・オーバー
二つのNICをそれぞれ二つのスイッチに接続する構成。
アクティブのNICが障害を検知するとバックアップ側にネットワーク経路を切り替える仕組みです。ネットワーク経路を二つ設けることができ、経路の冗長化は可能ですが、二つの経路を同時に利用して負荷を二つのリンクに分散することができません。
②イーサネット・チャネル
二つのNICを一つのスイッチに接続する構成。
スイッチとのチャネル・リンクを構成します。一つのリンク、NICが障害となった場合に即時に片チャネル運用が可能であり、またリンクのアグリゲーション機能によりリンクへの負荷を両リンクに分散させることが可能です。しかし、同一のスイッチ内での接続を前提としているため、複数のネットワーク経路を作ることはできず、スイッチが単一障害点になってしまいます。
③スパニング・ツリー・プロトコル（STP）
二つのNICをそれぞれ二つのスイッチに接続する構成。
サーバが１台のスイッチと同様に動作し、バックアップ側のNICポートをブロッキング状態にすることで経路冗長を図る方式です。しかし、スパニング・ツリー・プロトコルを用いるために切替時間に50秒以上かかってしまう上に経路の分散もできません。
以上の三つの方式を簡単に表にまとめてみました。
｜冗長化｜負荷分散｜切替時間｜
①｜ ○ ｜ × ｜ ○ ｜
②｜ × ｜ ○ ｜ ○ ｜
③｜ ○ ｜ × ｜ × ｜
2006年10月13日
サブミッションポート + postfix
postfixでのサブミッションポート(submission port)対応はとても簡単です。
/etc/postfix/master.cfファイルを編集し、コメントアウトされているsubmissionポートを有効にします。
▼/etc/postfix/master.cf
...
submission inet n - n - - smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_etrn_restrictions=reject
...
submission inet n - n - - smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_etrn_restrictions=reject
...
/etc/servicesファイルを編集し、サービス一覧にサブミッションポートを追加しますが、デフォルトですでに追加されています。
▼/etc/services
...
submission 587/tcp msa # mail message submission
submission 587/udp msa # mail message submission
...
submission 587/tcp msa # mail message submission
submission 587/udp msa # mail message submission
...
postfixを再起動します。
# service postfix restart
サブミッションポートの変換
Outbound Port 25 Blocking（OP25B）対策として、外部メールサーバへの接続はサブミッションポート(submission port; Port587)を使用します。メールサーバ側でPort587を受け付けるようにしなければいけませんが、設定をするのが不安という場合には、とりあえず手っ取り早い対策として、iptablesでPort587をPort25に変換します。
# iptables -t nat -A PREROUTING -p tcp --dport 587 -j DNAT --to aaa.bbb.ccc.ddd:25
2006年07月05日
サービス監視
■ サービス監視スクリプト
▼/usr/local/bin/check_active
#!/bin/sh
# service check interval
#!/bin/sh
# service check intervalINTERVAL=10
# service IP address
CVIP=210.230.64.251
# service check interval
INTERVAL=10
# service IP address
CVIP=210.230.64.251
CURL=/usr/bin/curl
GREP=/bin/grep
while true
do
# check vsftpd
${CURL} ftp://127.0.0.1/ 2>&1 | ${GREP} 'pub' > /dev/null
# check httpd${CURL} --retry 4 --retry-delay 15 http://127.0.0.1/ 2>&1 | ${GREP} 'html' > /dev/nullif [ $? -ne 0 ]; then
/usr/lib/heartbeat/heartbeat -k
exit 100
fi
sleep ${INTERVAL}
# service check interval
#!/bin/sh
# service check intervalINTERVAL=10
# service IP address
CVIP=210.230.64.251
# service check interval
INTERVAL=10
# service IP address
CVIP=210.230.64.251
CURL=/usr/bin/curl
GREP=/bin/grep
while true
do
# check vsftpd
${CURL} ftp://127.0.0.1/ 2>&1 | ${GREP} 'pub' > /dev/null
# check httpd${CURL} --retry 4 --retry-delay 15 http://127.0.0.1/ 2>&1 | ${GREP} 'html' > /dev/nullif [ $? -ne 0 ]; then
/usr/lib/heartbeat/heartbeat -k
exit 100
fi
sleep ${INTERVAL}
heartbeatの起動
■ハートビートの起動
稼動系のサーバと待機系のサーバの両方を起動します。
[www1]# /etc/init.d/heartbeat start
Starting High-Availability services: [ OK ]
Starting High-Availability services: [ OK ]
[www2]# /etc/init.d/heartbeat start
Starting High-Availability services: [ OK ]
Starting High-Availability services: [ OK ]
■起動確認
heartbeatを起動するとwww1にVIPの設定が行われます。
[www1]# ifconfig -a eth0:0
...
eth0:0 Link encap:Ethernet HWaddr...
...
...
eth0:0 Link encap:Ethernet HWaddr...
...
また、httpdサービスも自動的に開始されています。
[www1]# ps -C httpd
PID TTY TIME CMD
7980 ? 00:00:18 httpd
4212 ? 00:00:06 httpd
5239 ? 00:00:06 httpd
13190 ? 00:00:04 httpd
13191 ? 00:00:06 httpd
17484 ? 00:00:02 httpd
17485 ? 00:00:01 httpd
21871 ? 00:00:01 httpd
22005 ? 00:00:00 httpd
22007 ? 00:00:00 httpd
22008 ? 00:00:00 httpd
PID TTY TIME CMD
7980 ? 00:00:18 httpd
4212 ? 00:00:06 httpd
5239 ? 00:00:06 httpd
13190 ? 00:00:04 httpd
13191 ? 00:00:06 httpd
17484 ? 00:00:02 httpd
17485 ? 00:00:01 httpd
21871 ? 00:00:01 httpd
22005 ? 00:00:00 httpd
22007 ? 00:00:00 httpd
22008 ? 00:00:00 httpd
www2ではhttpdは起動されません。
[www2]# ps -C httpd
PID TTY TIME CMD
PID TTY TIME CMD
■フェイルオーバーの確認
稼動系サーバを強制的にフェイルオーバーさせて正しく待機系サーバに切り替わるかを確認します。強制的に待機系サーバに切り替えるには、www1でheartbeatサービスを停止します。
[www1]# /etc/init.d/heartbeat stop
Stopping High-Availability services: [ OK ]
Stopping High-Availability services: [ OK ]
正しく設定が行われていれば、VIPとサービスが待機系サーバに引き継がれます。
www2にVIPが設定されていることを確認します。
[www2]# ifconfig -a eth0:0
...
eth0:0 Link encap:Ethernet HWaddr...
...
...
eth0:0 Link encap:Ethernet HWaddr...
...
また、httpdサービスも自動的に開始されています。
[www2]# ps -C httpd
PID TTY TIME CMD
7980 ? 00:00:18 httpd
...
PID TTY TIME CMD
7980 ? 00:00:18 httpd
...
■フェイルバックの確認
今度は稼動系サーバを復活させてフェイルバック動作を確認します。www1のheartbeatサービスと起動します。
[www1]# /etc/init.d/heartbeat start
Starting High-Availability services: [ OK ]
Starting High-Availability services: [ OK ]
www1にVIPが設定されていることと、httpdプロセスが起動していることを確認します。
■heartbeatの自動起動
# chkconfig --add heartbeat
# chkconfig heartbeat on
■サービスの自動起動の停止
/etc/ha.d/haresourcesファイルに登録したサービスのうち、システムの自動起動の設定が行われているサービスがあれば、自動起動の対象から削除する必要があります。ここでは、Webサーバを冗長化するためhttpdをheartbeatの管理にしていますので、httpdの自動起動を停止しておく必要があります。
# chkconfig httpd off
heartbeatの設定
2台のWebサーバのホスト名をwww1, www2とします。どちらのサーバもNICが二つあり、eth0がサービス系、eth1が監視系です。IPアドレスについて、サービス系のIPアドレスは、www1: 192.168.1.1, www2: 192.168.1.2とし、VIPとして192.168.1.3を使用するとします。監視系のIPアドレスは、www1: 10.0.0.1, www2: 10.0.0.2とします。
1. クラスタの設定
それぞれのサーバの/etc/ha.d/ha.cfファイルを編集します。デフォルトではほとんどの行がコメントアウトされていますので、必要に応じてコメントを外し設定します。
▼/etc/ha.d/ha.cf (www1)
# ログ
logfile /var/log/ha-log
# 時間
keepalive 2
deadtime 10
warntime 10
initdead 120
# ハートビート
udpport 694
baud 19200
serial /dev/tty0
ucast eth1 10.0.0.2
# 自動フェイルバック
auto_failback on
# ウォッチドック
watchdog /dev/watchdog
# クラスタノード
node www1 www2
# PING監視
ping 192.168.1.254
# 外部プログラム
respawn hacluster /usr/local/lib/heartbeat/ipfail
# クライアントAPIのアクセス制御
apiauth ipfail gid=haclient uid=hacluster
logfile /var/log/ha-log
# 時間
keepalive 2
deadtime 10
warntime 10
initdead 120
# ハートビート
udpport 694
baud 19200
serial /dev/tty0
ucast eth1 10.0.0.2
# 自動フェイルバック
auto_failback on
# ウォッチドック
watchdog /dev/watchdog
# クラスタノード
node www1 www2
# PING監視
ping 192.168.1.254
# 外部プログラム
respawn hacluster /usr/local/lib/heartbeat/ipfail
# クライアントAPIのアクセス制御
apiauth ipfail gid=haclient uid=hacluster
▼/etc/ha.d/ha.cf (www2)
# ログ
logfile /var/log/ha-log
# 時間
keepalive 2
deadtime 10
warntime 10
initdead 120
# ハートビート
udpport 694
baud 19200
serial /dev/tty0
ucast eth1 10.0.0.1
# 自動フェイルバック
auto_failback on
# ウォッチドック
watchdog /dev/watchdog
# クラスタノード
node www1 www2
# PING監視
ping 192.168.1.254
# 外部プログラム
#respawn hacluster /usr/local/lib/heartbeat/ipfail
# クライアントAPIのアクセス制御
#apiauth ipfail gid=haclient uid=hacluster
logfile /var/log/ha-log
# 時間
keepalive 2
deadtime 10
warntime 10
initdead 120
# ハートビート
udpport 694
baud 19200
serial /dev/tty0
ucast eth1 10.0.0.1
# 自動フェイルバック
auto_failback on
# ウォッチドック
watchdog /dev/watchdog
# クラスタノード
node www1 www2
# PING監視
ping 192.168.1.254
# 外部プログラム
#respawn hacluster /usr/local/lib/heartbeat/ipfail
# クライアントAPIのアクセス制御
#apiauth ipfail gid=haclient uid=hacluster
www2の設定はwww1の設定とほぼ同じですが、ucastの設定と外部プログラムipfailの呼び出しがなくなっている部分が異なります。
2. 共有リソースの設定
それぞれのサーバの/etc/ha.d/haresourcesファイルを編集します。必ず両方のサーバのファイルが同一になるようにします。
▼/etc/ha.d/haresources (www1, www2)
www1 192.168.0.3/24 httpd
これは、www1を稼動系として、httpdサービスを起動したい場合の設定です。VIP: 192.168.0.3を稼動系サーバに付与させる設定です。
heartbeatのインストール
heartbeatによるクラスタシステムを構築するには、稼動系サーバ、待機系サーバの2つのサーバにheartbeatというソフトウェアをインストールします。
1. libnetのコンパイル
まずlibnetをコンパイルします。パッケージを展開し、configureプログラムを実行します。
$ tar xvzf libnet.tar.gz
$ cd linbet
$ ./configure --prefix=/usr/local
$ cd linbet
$ ./configure --prefix=/usr/local
makeを実行しコンパイルを行います。
$ make
$ su
# make install
$ su
# make install
2. heartbeatのコンパイル
2006年03月18日
冗長構成
NW機器を使用せずにLinuxサーバだけでサーバ冗長構成を実現する方法をいくつか紹介します。
1. DNS1を使用した冗長構成
DNSを利用して二台のWebサーバ冗長構成を実現します。
監視サーバより二台のサーバのWebサービスを監視し、現在稼動しているサーバがダウンしたら、DNSのゾーンを更新することでサーバを切り替えます。
設定は簡単ですが、クライアントから見ると、DNSキャッシュの影響ですぐには切り替わらないことが欠点です。
2. ハートビートを利用した冗長構成
ハートビートを利用して二台のWebサーバ冗長構成を実現します。
heartbeatはクラスタリングを実現するためのソフトウェアであり、フリーで入手してRHEL3にインストールすることが可能です。2台のサーバでアクティブ・スタンバイ型のクラスタリングを実現し、サービス停止を防ぎます。
2台のWebサーバのeth0（サービス側）にはそれぞれグローバルIPアドレスが振られており、バーチャルIP（VIP）としてもう一つグローバルIPアドレスを使用します。それぞれのサーバのeth1はハートビート送受信用にします。
通常の状態では、稼動系のWebサーバのeth0にVIPがついており、Webサーバが起動しています。待機系サーバのWebサーバは停止しています。
稼動系サーバについて次のような現象が起こったとき、待機系サーバのeth0にVIPがつけられ、Webサーバが起動します。
・Webサーバ停止
・ネットワークダウン
・サーバ停止
切替時間は1秒程度ですので、サービス断の時間がほとんどなくサービスを継続できる利点があります。
ただし、欠点としては、グローバルIPアドレスをもう一つ使用すること、eth1側も使用すること、設定がやや複雑になることがあげられます。
2006年03月10日
フリー管理ツール
LinuxですとCPU、メモリ、ディスク、プロセス、ネットワークといったシステム情報をコマンドで簡単に取得できますが、Windowsでも同様にコマンドまたはGUIで簡単にシステム情報を閲覧するためのツール群があります。
Sysinternals freeware
http://www.systeminternals.com/
Process Explorerを使用すれば、あるファイルを使用しているプロセスを見つけることもできます。
2006年02月22日
rootkitの検出
攻撃者がコンピュータに侵入した後によく利用するツール類をまとめたrootkitと呼ばれるツールキットがあります。rootkitは攻撃者の足跡を消し去り、バックドアを設置します。また、rootkit自体の存在を隠すために、psコマンドやlsコマンドなどのシステム自体を改ざんします。
rootkitには様々種類が存在するために、それらを手動で検出することは非常に困難ですが、chkrootkit を使うことにより自動的な検出ができます。現在のところ、chkrootkitでは60種類以上のrootkitを検出することができます。
詳細は以下のサイトを参照してください。
chkrootkit -- locally checks for signs of a rootkit
http://www.chkrootkit.org/
1. インストール
上記のサイトより最新のソースをダウンロードしてインストールします。（一般ユーザ権限でもインストール可能です。）
$ tar zxvf chkrootkit.tar.gz
$ cd chkrootkit-0.46a
$ su
# make sense
# cp ./chkrootkit /usr/local/bin/
$ cd chkrootkit-0.46a
$ su
# make sense
# cp ./chkrootkit /usr/local/bin/
chkrootkitプログラムが作業ディレクトリ内に出来上がります。コマンドから実行しやすいように、/usr/local/binディレクトリにコピーしておくとよいでしょう。
2. chkrootkitの実行
root権限で実行します。
# chkrootkit
ROOTDIR is `/'
Checking `amd'... not infected
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
（省略）
...
ROOTDIR is `/'
Checking `amd'... not infected
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
（省略）
...
rootkitが検出された場合は、「INFECTED」と表示されます。
3. cronで実行
chkrootkitをcronに登録して定期的に実行させます。
また、実行結果を記録するとともに、rootあてにメールを送信します。
/etc/cron.dailyディレクトリにchkrootkitを実行するシェルスクリプト /etc/cron.daily/chkrootkitを作成します。
▼/etc/cron.daily/chkrootkit
#!/bin/sh
/usr/local/bin/chkrootkit > /var/log/chkrootkit.log
grep "INFECTED" /var/log/chkrootkit.log | mail -s "chkrootkit log" root
chmod 600 /var/log/chkrootkit.log
/usr/local/bin/chkrootkit > /var/log/chkrootkit.log
grep "INFECTED" /var/log/chkrootkit.log | mail -s "chkrootkit log" root
chmod 600 /var/log/chkrootkit.log
スクリプトに実行権を付加します。
# chmod 755 chkrootkit
注1： "INFECTED"と出力されたら改ざんされている可能性が高いですが、誤って検知される事も多いようですので、必ずしも改ざんされているとは限りません。また、まだ一般的に知られていない新しい rootkit も検知される事はありませんので、検出されなかったら安全というわけではありません。
注2： 攻撃者にrootkitそのものを改ざんされてしまったら意味がありません。chkrootkitをCD-ROMなどの書き込みできないメディアに移しておくとよいでしょう。
また、chkrootkitが呼び出すコマンドは、awk、cut、egrep、find、head、id、ls、netstat、ps、strings、sed、unameですが、これらのコマンドが汚染されている場合もありますので、汚染されていないと想定できるシステム（KNOPPIXなど、CDブートできるディストリビューション）で一時的にブートし、そのシステムのコマンドを使ってchkrootkitを実行するのがより望ましいでしょう。
注2： 攻撃者にrootkitそのものを改ざんされてしまったら意味がありません。chkrootkitをCD-ROMなどの書き込みできないメディアに移しておくとよいでしょう。
また、chkrootkitが呼び出すコマンドは、awk、cut、egrep、find、head、id、ls、netstat、ps、strings、sed、unameですが、これらのコマンドが汚染されている場合もありますので、汚染されていないと想定できるシステム（KNOPPIXなど、CDブートできるディストリビューション）で一時的にブートし、そのシステムのコマンドを使ってchkrootkitを実行するのがより望ましいでしょう。
RPMパッケージの改ざん検出
コンピュータが不正アクセスの被害を受け、システムが改ざんされてしまった場合に、改ざんされたファイルを調査する方法として、RPMパッケージの改ざん検出をする方法があります。
RPMパッケージをインストールする時には、ファイルすべてのMD5チェックサムを保存しています。また、ファイルのサイズ、ユーザー、グループ、モード、更新時刻などについても保存しています。これらの情報を用いて、変更が加えられていないか調べることができます。rpmコマンドで-Vオプションを使用して調査します。
ここでは試しにWEBサーバ(httpd)やメールサーバ(sendmail)など、いくつかのパッケージについて調べてみます。
# rpm -V httpd
S.5....T c /etc/httpd/conf/httpd.conf
.M...UG. /var/log/httpd
# rpm -V sendmail
SM5....T c /etc/aliases
S.5....T c /etc/mail/access
S.5....T c /etc/mail/local-host-names
S.5....T c /etc/mail/sendmail.cf
S.5....T c /etc/mail/sendmail.mc
S.5....T c /etc/mail/statistics
SM5....T c /etc/mail/submit.cf
S.5....T c /etc/httpd/conf/httpd.conf
.M...UG. /var/log/httpd
# rpm -V sendmail
SM5....T c /etc/aliases
S.5....T c /etc/mail/access
S.5....T c /etc/mail/local-host-names
S.5....T c /etc/mail/sendmail.cf
S.5....T c /etc/mail/sendmail.mc
S.5....T c /etc/mail/statistics
SM5....T c /etc/mail/submit.cf
インストール時から変更されているファイルについて、8個の文字と属性マークの形式で変更されている内容が出力されます。
文字の意味
- S ファイルのサイズ (Size) が異なる
- M モード (Mode; 許可属性とファイルの種類) が異なる
- 5 MD5 チェックサムが異なる
- D デバイス (Device) のメジャー/マイナー番号が一致しない
- L readLink(2) したパスが一致しない
- U 所有者 (User) が異なる
- G グループ (Group) が異なる
- T 修正時刻 (mTime) が異なる
属性マークの意味
- c %config 設定ファイル。
- d %doc 文書ファイル。
- g %ghost ファ イル(すなわち、パッケージの内容物としては含まれていないファイル)。
- l %license ライセンスファイル。
- r %readme readme ファイル。
文字の部分で、". "(ピリオド) はテストを通過した こと意味し、"?" (クエスチョンマーク) はテストが実施されなかった (すなわち、ファイルパーミッションにより読み込めなかった) ことを意味しています。
オプションをつけることによって検証結果を絞り込むことができます。設定ファイルなどのように管理者によって変更されたファイルを除外することができます。次はそれらのオプションの一部です。
- --nouser
- --nogroup
- --nomtime
- --nomode
# rpm -V --nouser --nogroup --nomtime --nomode httpd
S.5..... c /etc/httpd/conf/httpd.conf
S.5..... c /etc/httpd/conf/httpd.conf
すべてのパッケージについて検証を行う場合は次のようにします。
# rpm -Va
この出力結果をファイルにリダイレクトして記録しておくとよいでしょう。
2006年02月16日
rsyncでsshを使用
rsyncは、rshやsshを使ったファイル転送をサポートしています。環境によっては、rsyncのプロトコル（TCP873番ポート）を使用した通信ができない場合がありますが、そのような場合でもsshが許可されていればrsyncを利用することができます。
sshを使ってファイル転送を行うには、次のようにrsyncのコマンドを指定します。
(1) rsync --rsh=ssh [オプション] 送信元 [ユーザ@]ホスト:送信先
(2) rsync --rsh=ssh [オプション] 送信元 rsync://[ユーザ@]ホスト[:ポート]/DEST
(3) rsync --rsh=ssh [オプション] [ユーザ@]ホスト:送信元 送信先
(4) rsync --rsh=ssh [オプション] rsync://[ユーザ@]ホスト[:ポート]/送信元 [DEST]
(2) rsync --rsh=ssh [オプション] 送信元 rsync://[ユーザ@]ホスト[:ポート]/DEST
(3) rsync --rsh=ssh [オプション] [ユーザ@]ホスト:送信元 送信先
(4) rsync --rsh=ssh [オプション] rsync://[ユーザ@]ホスト[:ポート]/送信元 [DEST]
(1)と(2)はサーバへファイルをアップロードする場合、(3)と(4)はサーバからファイルをダウンロードする場合で、それぞれどちらの指定方法でも同じです。
サーバ(192.168.0.10)からデータディレクトリをクライアントのbackupディレクトリに同期転送します。
$ rsync --rsh=ssh -av --delete 192.168.0.10:./data/ ./backup/
user@192.168.0.10's password: [パスワードを入力]
receiving file list ... done
...
user@192.168.0.10's password: [パスワードを入力]
receiving file list ... done
...
注1：sshを使った場合には、ログインを行ったユーザの権限でアクセスできるファイルに対してしか処理を行うことができません。
注２：sshでログインするためのパスワードの入力を求められますが、cronなどから自動処理を行うためには、ssh接続認証用の鍵を用意し、そのパスフレーズを空にしておく必要があります。
注２：sshでログインするためのパスワードの入力を求められますが、cronなどから自動処理を行うためには、ssh接続認証用の鍵を用意し、そのパスフレーズを空にしておく必要があります。
rsyncのアクセス制御
rsyncサーバはスーパーサーバ配下で動作するため、tcp_wrapperによるアクセス制御が可能です。rsyncサーバへのアクセス制御設定は、rsyncd.confファイルで行うこともできますが、rsync自体のセキュリティホールが発生した場合などを考慮すると、スーパーサーバでのアクセス制御が望ましいです。
/etc/hosts.allow と /etc/hosts.deny を利用してアクセス制御を行います。
まず、すべての接続を拒否する設定をします。
▼/etc/hosts.deny
...
rsync: ALL
...
rsync: ALL
...
次に、接続を許可するホストのホスト名またはIPアドレスを記述します。
▼/etc/hosts.allow
...
rsync: 192.168.0.20
rsync: rsyncclient
...
rsync: 192.168.0.20
rsync: rsyncclient
...
rsyncによるデータ転送
rsync はネットワーク経由でファイルの同期を取るプログラムです。rsync は独特のアルゴリズムにより、遠隔にあるファイルとの同期を最速で実現する方法を使っています。rcpやscpが必ずファイルやディレクトリ全体を扱うのに対して、rsyncではファイルやディレクトリの差分だけを扱うことができるため、効率よく同期を取ることができます。そのため、ファイルやディレクトリのバックアップや、複数のサーバ間でのデータの同期など、広い用途で使われています。rsyncはTCP873番ポートを使用して独自プロトコルで通信を行いますが、sshやrshなどのセッション上で動作させることも可能です。
RHEL3ではrsyncがデフォルトでインストールされています。
バージョン
- rsync-2.5.7-1 (RHEL3のデフォルトRPM)
接続先サーバA(192.168.0.10)から接続元クライアントB(192.168.0.20)に標準のWEBディレクトリを同期転送することを仮定して設定方法を説明します。
1. 設定ファイル作成
接続先サーバAに /etc/rsyncd.conf ファイルを作成します。
#
# Global
#
uid = apache --- (1)
gid = apache
#
# www file modules
#
[wwwfiles] --- (2)
path = /var/www/html --- (3)
comment = "Web server contents" --- (4)
read only = yes --- (5)
hosts allow = 192.168.0.20 --- (6)
# Global
#
uid = apache --- (1)
gid = apache
#
# www file modules
#
[wwwfiles] --- (2)
path = /var/www/html --- (3)
comment = "Web server contents" --- (4)
read only = yes --- (5)
hosts allow = 192.168.0.20 --- (6)
(1) rsyncサーバ全体に対するグローバル設定と呼ばれる部分です。ここでは、サーバ全体に対してapacheの実行権限と同じ権限で動作するように指定しています。ユーザ権限の設定は以下の各モジュール内で行うこともできます。
(2) "[]"で囲まれた名称をモジュール名と呼び、それ以下にモジュールごとの設定を行います。
(3) 同期対象のディレクトリを指定します。
(4) クライアントがモジュールの一覧を表示したときに指定部分が表示されます。
(5) ここでは、サーバのデータをクライアントに同期しますので、サーバ側へのデータの書き込みを禁止しています。
(6) 指定のIPアドレスのホストからの接続のみを許可しています。ただし、アクセス制御はスーパーサーバで行うほうが望ましいです。
2. 接続先サーバAとネットワーク側のファイアウォール設定
rsyncはTCP873番ポートを使用しますので、接続先サーバAまたはネットワーク側でファイアウォールが存在している場合には、適切な設定変更を行い、クライアントBからサーバAのTCP873番ポートに対するアクセスを可能な状態にします。
3. 接続
rsyncのコマンド使用法です。
rsync [オプション] [ユーザ名@] ホスト名::モジュール名 転送先 （Aからダウンロードの場合）
rsync [オプション] 転送元 [ユーザ名@] ホスト名::モジュール名 （Aにアップロードの場合）
rsync [オプション] 転送元 [ユーザ名@] ホスト名::モジュール名 （Aにアップロードの場合）
オプション（一部）
-a, --archive: アーカイブモードで転送を行います。ファイルのパーミッションや所有者情報、タイムスタンプなどが保存されます。
-v, -verbose: 転送中の情報を詳しく表示します。
--delete: コピー元に存在しないファイルは削除します。
-v, -verbose: 転送中の情報を詳しく表示します。
--delete: コピー元に存在しないファイルは削除します。
サーバAからWEBコンテンツをクライアントBのhtml_contentsディレクトリに同期転送します。ここでは、本記事の差分だけ同期転送されます。
＃ rsync -av --delete 192.168.0.10::wwwfiles ./html_contents/
receiving file list ... done
./
mtdata/senyo/
mtdata/senyo/2006/02/
mtdata/senyo/2006/02/rsync.html
mtdata/senyo/atom.xml
mtdata/senyo/index.html
mtdata/senyo/index.xml
wrote 1328 bytes read 70492 bytes 143640.00 bytes/sec
total size is 16158584 speedup is 224.99
receiving file list ... done
./
mtdata/senyo/
mtdata/senyo/2006/02/
mtdata/senyo/2006/02/rsync.html
mtdata/senyo/atom.xml
mtdata/senyo/index.html
mtdata/senyo/index.xml
wrote 1328 bytes read 70492 bytes 143640.00 bytes/sec
total size is 16158584 speedup is 224.99
POP3 over SSL / IMAP4 over SSL
POP3/IMAP4サーバでもSSLサポートをしており、通常リクエストとは別に、それぞれ995, 993番ポートでリクエストを待ち受けます。
RHEL3ではデフォルトでUW IMAPがインストールされていますが、SSLサポート機能が組み込まれていますので、サービスを有効化するだけで、簡単にSSL対応にさせることができます。
バージョン
- imap-2002d-2 (RHEL3のデフォルトRPM)
1. 証明書の作成
SSL対応のPOP3/IMAP4サーバを使用する場合には証明書が必要です。ただし、HTTPSのように認証局発行のものである必要はなく自己署名の付いたもので十分です。
作成された証明書は /usr/share/ssl/certs/ に置くことになっています。このディレクトリには、すでにダミーファイルが置かれていてこのままでも使用できないことはないですが、念のため自己署名の証明書を作成します。ipop3sd.pemがPOP3のための証明書、imapsd.pemがIMAP4のために証明書です。
# cd /usr/share/ssl/certs
# /usr/bin/openssl req -newkey rsa:1024 -keyout key.pem -nodes -x509 -days 365 -out req.pem
（指示に従って住所や組織情報を入力します。）
# cat key.pem req.pem > ipop3sd.pem
# rm -f key.pem req.pem
# /usr/bin/openssl req -newkey rsa:1024 -keyout key.pem -nodes -x509 -days 365 -out req.pem
（指示に従って住所や組織情報を入力します。）
# cat key.pem req.pem > imapsd.pem
# rm -f key.pem req.pem
# /usr/bin/openssl req -newkey rsa:1024 -keyout key.pem -nodes -x509 -days 365 -out req.pem
（指示に従って住所や組織情報を入力します。）
# cat key.pem req.pem > ipop3sd.pem
# rm -f key.pem req.pem
# /usr/bin/openssl req -newkey rsa:1024 -keyout key.pem -nodes -x509 -days 365 -out req.pem
（指示に従って住所や組織情報を入力します。）
# cat key.pem req.pem > imapsd.pem
# rm -f key.pem req.pem
2. サービスの起動
SSL対応のPOP3/IMAP4サービスを起動します。
# chkconfig pop3s on
# chkconfig imaps on
3. クライアントから接続
クライアントからPOP3の場合はサーバの995番ポートに、IMAP4の場合はサーバの993番ポートに接続します。証明書が公的なものでない場合は、警告が出る場合がありますが無視してください。
なお、サーバおよびネットワークでファイアウォールを導入している場合は、上記のポートへの接続を許可しておいてください。