ProFTPDの設定ファイルでは、いろいろ細かい設定が
可能なんですね。
DefaultRoot ~ !admin ←adminグループ以外はホームディレクトリより上には移動できない
<Directory /home/hoge/>
ListOptions “-l” ←あたまが.のファイルは表示させない。
Umask 000 ← Umaskを000に
<Limit SITE_CHMOD>
DenyAll
AllowUser admin ←CHMODはadminだけ許可。
</Limit>
<Limit WRITE>
DenyAll
AllowUser admin, hoge ←アップロードはadminとhogeに許可。
</Limit>
<Limit READ>
DenyAll
AllowUser admin, hoge ←ダウンロードはadminとhogeに許可。
</Limit>
<Limit DELE>
DenyAll
AllowUser admin ← 削除はadminだけ許可。
</Limit>
</Directory>
外出先でウェブメールを使えると便利かな～と思って
SquirrelMailを入れてみた。が。
「imapが動いてないとダメ」と怒られました。(‘A`)
じゃぁ とりあえずdovecotでも入れておこうかな。
vpopmailに対応させるためにはSRPMをダウンロードして
リビルドしないとダメらしい。
環境：Red Hat Enterprise Linux 4
（既にサーバにはqmail,vpopmail,SquirrelMailがインストール済みです。
●dovecotのソースRPMをダウンロード。
# wget http://ftp.yz.yamagata-u.ac.jp/pub/linux/centos/4.7/os/SRPMS/dovecot-0.99.11-9.EL4.src.rpm
●ソースRPMを展開。
# rpm -ivh dovecot-0.99.11-9.EL4.src.rpm
●specファイルを編集。
--with-vpopmailを追加。
# vi /usr/src/redhat/SPECS/dovecot.spec
%configure \
--with-vpopmail \
--with-pgsql \
--with-mysql \
--with-ssl=openssl \
--with-ssldir=/usr/share/ssl \
--with-ldap
●リビルド開始。
# rpmbuild --bb --clean /usr/src/redhat/SPECS/dovecot.spec
●できあがったrpmをインストール。
#rpm -ivh /usr/src/redhat/RPMS/i386/dovecot-0.99.11-9.EL4.i386.rpm
●dovecot.confを編集。
# vi /etc/dovecot.conf
protocols = imap ←imapしか使わない。
auth_userdb = vpopmail ←追加
auth_passdb = vpopmail ←追加
first_valid_uid = 89 ←追加
●dovecot スタート。
# service dovecot start
# nmap localhost
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
80/tcp open http
110/tcp open pop3
143/tcp open imap ←ちゃんと動いているっぽい
●dovecot自動起動 on
# chkconfig dovecot on
# chkconfig --list dovecot
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
PostgreSQLはバージョン8.0からPITR(Point In Time Recovery)機能が
追加されたことにより、メディア障害が発生する直前の状態までデータを
リカバリすることが簡単にできるようになったようです。
手順はそれほど難しくはないようです。
テスト環境：
Redhat系Linux/PostgreSQL : 8.1.10-0vl0.40
シチュエーション:
ある日、突然データベースがぶっとんでしまった(’A`)、ので、
数日前に取っておいた全体バックアップとリアルタイムで更新される
トランザクションログを使用してデータベースを復旧させる。
●まず、PITR機能を利用するための下ごしらえ
rootになってPostgreSQLをストップ
# service postgresql stop
ユーザpostgresにチェンジ
# su – postgres
アーカイブログを保存するディレクトリを作成します。
データの保護を考慮して、物理的に別のディスクに作成するのが
良さそうです。
$ mkdir -p /backup/postgres/archive_dir
トランザクションログも別ディスクに移動しちゃいましょう＾＾
$ mv /var/lib/pgsql/data/pg_xlog /backup/postgres
$ ln -s /backup/postgres/pg_xlog /var/lib/pgsql/data/pg_xlog
mvコマンドは失敗するとファイルが消失することがあるらしい(’A`)ので
心配性の人はcpコマンドを使えば良いでしょう。
postgresql.confを書き換えます。
$ vi data/postgresql.conf
archive_command = ‘cp %p /backup/postgres/archive_dir/%f’
ルートになってPostgreSQLをスタートさせましょう。
(再起動しないとpostgresql.confの変更が反映されませんです。
# service postgresql start
これで、PITRを利用するための下ごしらえは完了です！！
●データベースの全体バックアップ
まず、pg_start_backupを実行します。
(”)の中の文字列は何でも良いそうです？（ﾎﾝﾄｶﾅ
バックアップ時にPostgreSQLを停止する必要はありません。
停止させなくても一貫性のあるバックアップを取得
することが可能です。
ユーザpostgresにチェンジ
# su – postgres
$ psql -c “select pg_start_backup(‘Label’)”
tarコマンドでdataディレクトリを丸ごとバックアップします。
$ tar cjvf /backup/postgres/data.tar.bz2 data
pg_stop_backupを実行します。
$ psql -c “select pg_stop_backup()”
この時点で/backup/postgres/archive_dir/に.backupという
ファイルが作成されているはずです。
これで、無事にバックアップを取ることができました。
ちゃんと、最新の状態までリカバリされることを確認するために、
試しに、データベースに対して挿入とか削除とか
いろいろやってみましょう。
●ある日、突然、データがぶっとんだ！！(’A`)
あわてる必要はありません。
数日前に取っておいた全体バックアップと
最新のトランザクションログがあれば、復旧できます。
まず、rootになってPostgreSQLをストップ
# service postgresql stop
ユーザpostgresにチェンジ
# su – postgres
完全バックアップをPostgreSQLのデータディレクトリに
解凍します。
念のため、現在のdataディレクトリは退避させておきましょう。
$ mv data data.back
(心配な人はこｐそいｆ
完全バックアップファイルを解凍します。
$ tar xjvf /backup/postgres/data.tar.bz2
recovery.confファイルを用意します。
$ cp /usr/share/pgsql/recovery.conf.sample data/recovery.conf
$ vi data/recovery.conf
restore_command = ‘cp /backup/postgres/archive_dir/%f %p’
最後に、rootになってPostgreSQLをスタートさせましょう。
# service postgresql start
おめでとうございます！！
ちゃんと、障害が発生する直前の状態までリカバリできましたよね？
これで無事にリカバリが完了しました！！
Powered by WordPress