ディレクトリごと削除したい場合は
# rm -rf dir/ で良いはずですが、ディレクトリ内のファイル数が
多すぎると削除に失敗することがあります。
こんな時の解決方法をいくつか紹介しましょう。
●rmにxargs経由でファイル名を渡す。
# echo dir/* | xargs rm
●rmのまえに\(バックスラッシュ)をつける
# \rm -rf dir/
●リダイレクトとxargsを使う。
# ls > hoge.dat
# xargs rm < hoge.dat
これでOK^^
会社でお客さんにレンタルしている共用サーバの
apacheに新しいヴァーチャルホストの設定を追加することになったのだが、
思わぬ落とし穴が。。。。
●vi で開いて前回追加したヴァーチャルホストの設定をコピペして
ドメインの部分だけ変更し、apacheを再起動すればいいはず・・・・
[root@s1 conf]#vi httpd.conf
省略・・・
●apache2 -S での構文チェックは問題なし・・・
[root@s1 conf]# apache2 -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
_default_:443 new.host.name (/etc/apache2/conf.d/ssl.conf:90)
*:80 is a NameVirtualHost
default server sabakan.org (/etc/apache2/conf/apache2.conf:1028)
port 80 namevhost xxxxxx.co.jp (/etc/apache2/conf/apache2.conf:1028)
port 80 namevhost hoge.xxxxxx.com (/etc/apache2/conf/apache2.conf:1068)
port 80 namevhost hoge2.xxxxxx.com (/etc/apache2/conf/apache2.conf:1091)
Syntax OK
●apacheの再起動
[root@s1 conf]# service apache2 restart
httpdを停止中: [ OK ]
httpdを起動中: [ 失敗 ]
あれれ？
失敗したぞ？？？
●エラーログを見てみよう
[root@s1 conf]# tail /var/log/apache2/error_log
[Tue Jun 02 01:12:43 2009] [notice] caught SIGTERM, shutting down
Unable to open logs
ログがオープンできない？
・
・
あ、そうか！！
新しいドメイン用のログディレクトリを作成してなかったのが原因か。
httpd.confのログの出力先に存在してないディレクトリを指定すると
apache2 -S ではSyntax OKになるけどapacheの起動はエラーになるのか・・・・
●ログディレクトリを作成してapacheの再起動・・
[root@s1 conf]# mkdir /var/log/apache2/hoge2.xxxxxx.com
[root@s1 conf]# service apache2 start
httpdを起動中: [ OK ]
[root@s1 conf]# ps -ef | grep apache2
root 9142 1 8 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9145 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9146 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9147 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9148 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9149 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9150 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9151 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
apache 9152 9142 0 01:15 ? 00:00:00 /usr/sbin/apache2
root 9158 8994 0 01:15 pts/0 00:00:00 grep apache2
これでOK。
マジで心臓が止まるかと思ったです・・・ﾊｧﾊｧ
データセンターでハードディスクの予備のチェック中に会社から電話が・・
ディレクター「○○サーバのマウントが外れている。サイトの画像が表示されてない。」
自分 「マジですか・・・(’A`)」
とりあえず、ログインして確認してみる。
# mount
あれ？ 確かにNFSサーバ側のディスクが表示されてない。
どのサーバのディスクをマウントすればいいのかは/etc/fstabをみれば分かるはず。
# cat /etc/fstab
10.212.212.10:/home/httpd/hoge/photo /home/httpd/hoge/photo nfs rsize=32768,wsize=32768,hard 0 0
なるほど、OS起動時に10.212.212.10のディスクをマウントする設定になっているのか・・・
とりあえず、手動で再マウントしてみるか。
# mount -t nfs 10.212.212.10:/home/httpd/hoge/photo /home/httpd/hoge/photo
これで、ちゃんとサイトの画像も表示されるようになった。
でも、なんで勝手にマウントがはずれたんだろう？
原因が分からず気持ち悪い。
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
おめでとうございます！！
ちゃんと、障害が発生する直前の状態までリカバリできましたよね？
これで無事にリカバリが完了しました！！
今日はMySQLのバックアップ＆リストア＆リカバリのお勉強をしたので
メモ。
テスト環境：
Redhat系Linux/MySQL : 5.0.27-0vl6。
シチュエーション:
ある日、突然データベースがぶっとんでしまった(’A`)、ので、
数日前に取っておいた全体バックアップとリアルタイムで更新される
バイナリログを使用してデータベースを復旧させる。
●まず、定期的にデータベースの全体バックアップ（権限テーブル含む。
# mysqldump --user=root --password=rootpass --socket=/var/lib/mysql/mysql.sock
--single-transaction --master-data=2 --flush-logs --hex-blob
--default-character-set=binary --add-drop-table --all-databases > mysql-all.dump
（InnoDB以外のテーブルが含まれている場合は、共有ロックをかけるために
--single-transactionをはずしましょう。
（--flush-logsでバックアップと同時にbin-logもスイッチされる。
（/var/lib/mysqlにmysql-bin.000009が生成された
データベースが飛んだ・・・・・(’A`)
●Webアプリがデータベースを更新しないようにapacheをストップ
# service apache2 stop
●MySQLをストップ
# service mysql stop
●リストア、リカバリ時にバイナリログを生成しないように
my.cnfのlog-bin=mysql-binをコメントアウト
#log-bin=mysql-bin
●リモートから接続できなくするため--skip-networkingオプションでmysql起動
# /usr/bin/mysqld_safe --defaults-file=/etc/my.cnf --skip-networking --skip-grant-tables &
[1] 28450
# Starting mysqld-max daemon with databases from /var/lib/mysql
●全体バックアップからリストア
# mysql --user=root --socket=/var/lib/mysql/mysql.sock
--default-character-set=binary < mysql-all.dump
●バイナリログでリカバリ
（全体バックアップ時に新たに生成されたmysql-bin.000009～を使う。
# mysqlbinlog --disable-log-bin /var/lib/mysql/mysql-bin.000009 > recover.sql
# mysql --user=root --password=rootpass --socket=/var/lib/mysql/mysql.sock
--default-character-set=binary < recover.sql
●my.cnfのlog-bin=mysql-binを有効にする
log-bin=mysql-bin
●MySQL再起動
# service mysql stop
# service mysql start
これでＯＫ＾＾
かな？
Powered by WordPress