Hướng dẫn sử dụng BIND (DNS) trên Linux

1. Cấu hình của Bind
Bind được cấu hình dựa trên 3 thành phần chính, đầu tiên là named, đây là tiến trình chạy trên phía server của DNS. Thành phần thứ 2 là thư viện phân giải địa chỉ ( resolver library) gọi là Resolver. Resolver sẽ chuyển tên domain sang dạng địa chỉ IP. Nó sử dụng resolv.conf làm file cấu hình.
Phần thứ 3 cung cấp các công cụ để test hệ thống DNS.
2. Vai trò DNS của tôi trong hệ thống DNS là gì?
DNS là một hệ thống cơ sở dữ liệu phân tán, khi bạn mua một tên miền (domain) bạn cần phải trả lời trong bản đăng ký là làm việc với DNS nào. Bạn phải liệt kê hai DNS và chúng phải được đăng ký trong hệ thống DNS.
Hệ thống cơ sở dữ liệu tên miền gồm có 3 mức. Nhóm đầu tiên được gọi là Root server, nhóm thứ hai được gọi là Top Level Domains hay TLD. Khi một resolver muốn tìm địa chỉ website, TLD sẽ tạo quy vấn. Giả sử bạn muốn tìm hiephoa.net, Resolver của bạn sẽ hỏi Root server địa chỉ IP của hiephoa.net, Root sẽ trả lời tôi không biết nhưng tôi biết chỗ mà bạn có thể tìm thấy hiephoa.net, đó là hãy bắt đầu với TLD cho .net. TLD .net trả lời OK, tôi không có thông tin về hiephoa.net nhưng tôi biết một máy chủ chứa thông tin về hiephoa.net, nó có địa chỉ 210.245.87.194 và có tên là ns1.sic-corp.com.vn, hãy đến đó tìm địa chỉ của hiephoa.net.

ISPConfig, Phần mềm miễn phí dành cho ISP

Nếu bạn đang tìm hiểu đến các phần mềm quản lý hệ thống ISP chắc sẽ biết CPanel, Plesk ... là các phần mềm thương mại được sử dụng rất nhiều cho các nhà cung cấp dịch vụ domain và hosting. Tuy nhiên chi phí để mua các phần mềm này không phải là rẻ. Đây là trở ngại rất lớn dành cho các công ty nhỏ khi tìm kiếm giải pháp cho việc quản lý ISP.
Trong bài viết này tôi giới thiệu một phần mềm mã nguồn mở có tính năng tương tự CPanel,Plesk. Đó là ISPConfig.
ISConfig có thể chạy được trên nhiều bản distro của Linux như Debian, Fedora, SuSE ... ISPconfig có các tính năng sau:

• Httpd (virtual hosts, domain and IP based)
• FTP
• Bind (A, CNAME, MX and SPF Records)
• POP3 Auto-Responder
• MySQL client-databases
• Webalizer statistics
• Harddisk quota
• Mail-Quota
• Traffic limits
• IP-addresses
• SSL
• SSI
• Shell-access
• Mailscanner (Antivirus)
• Firewall

Sau khi download ISOConfig về bạn có thể cài đặt dễ dàng trong khoảng 30 phút nếu bạn đã cài đủ các phần mềm hỗ trợ và có đường net ADSL, việc sử dụng ISPConfig thì không thể dễ hơn, toàn bộ các giao diện đồ họa giúp người dùng sử dụng nhanh được hệ thống.

Clip.vn plugin cho SMF

Khi sử dụng diễn đàn dùng SMF, nếu bạn muốn post clip từ clip.vn thì phải copy đường link thật trong đoạn mã mà clip.vn cung cấp rồi chèn vào mã BBC của diễn đàn, rất rắc rối cho người sử dụng.
Để thuận tiện hơn khi nhúng clip từ clip.vn vào SMF tôi có viết một plugin nhỏ để convert từ link trên trình duyệt thành flash object.

Download tại đây

Sau khi download bạn vào phần Admin/Package của SMF và cài đặt như một package bình thường.

Hướng dẫn cài đặt replication cho MySQL.

Sao lưu dữ liệu là yêu cầu với bất cứ hệ thống lưu trữ nào để đảm bảo trong trường hợp mất dữ liệu do hỏng hóc gây ra.

MySQL có sẵn cơ chế sao lưu dữ liệu (replication) để tạo một bản sao của dữ liệu. Bài này sẽ hướng dẫn bạn cài đặt và cấu hình replication cho MySQL.

Giả sử bạn có hai máy Master và Slave với hai IP tương ứng là: 192.168.1.3 và 192.168.1.4
Trên master và slave đều đã cài đặt MySQL server.

1. Cấu hình master
Tạo user trên mysql để cho slave có thể kết nối vào được
mysql> GRANT REPLICATION,RELOAD,SUPER SLAVE ON *.* TO ‘repl’@’192.168.1.4’ IDENTIFIED BY ‘user_password’;
Cấu hình /etc/mysql/my.cnf

[mysqld]

log_bin = /var/log/mysql/mysql-bin.log
server-id=1
# ten database
binlog_do_db = database_name

Khởi động lại mysql
/etc/init.d/mysql restart

Khóa database cần đồng bộ để lấy trạng thái
mysql> use database_name
mysql> FLUSH TABLES WITH READ LOCK;
mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000195 | 7332719 | web10_db2 | |
+------------------+----------+--------------+------------------+
Backup database
mysqldump -u root -p --opt database_name> database_name.sql
Mở khóa database
mysql> UNLOCK TABLES;
2.Cấu hình slave
Tạo database, database_name.sql được lấy từ master
mysql> CREATE DATABASE database_name;
mysql -u root -p database_name< /path/to/database_name.sql


#Configuration MySql Replication Slave /etc/mysql/my.cnf
server-id=2
master-host=192.168.1.3
master-user=repl
master-password=user_password
replicate-do-db=database_name
report-host=slave-on-192.168.1.4

Khởi động lại mysql
/etc/init.d/mysql restart
mysql> SLAVE STOP;

mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.3', MASTER_USER='repl', MASTER_PASSWORD='', MASTER_LOG_FILE='mysql-bin.000195', MASTER_LOG_POS=7332719 ;

mysql>START SLAVE;

Done.

Hướng dẫn tạo bản sao lưu (image) của hệ thống Linux
Bạn đang có một hệ thống chạy ổn định và muốn backup trước khi thay đổi. Để trường hợp có lỗi khi thay đổi hệ thống bạn có thể khôi phục lại.

Quyền truy cập file trên Linux

Có 3 loại user tồn tại trên Linux:
1) user
2) groups
3) Others

User: Là tên owner file. Mặc định người tạo file sẽ là owner của file.

Group: Là nhóm user là owner của file.

Có 3 loại quyền:

• Quyền đọc (read)
  
• Quyền ghi(write)
  
• Quyền thực thi (execute)
  

Xem quyền truy cập của file

ls -l

Ví dụ:

me@mytux: /home/writers$ ls -l
total 17
drwxr-xr-x 3 nana writers 80 2005-09-20 21:37 dir
-rw-r----- 1 nana writers 8187 2005-09-19 13:35 file
-rwxr-xr-x 1 nana writers 10348 2005-07-17 20:31 otherfile

Ký hiệu:

d = directory
- = regular file
l = symbolic link
s = Unix domain socket
p = named pipe
c = character device file
b = block device file
r = read permission
w = write permission
x = execute permission
- = no permission
4 = read (r)
2 = write (w)
1 = execute (x)
0 = no permission (-)

Permission numbers
0	---
1	--x
2	-w-
3	-wx
4	r--
5	r-x
6	rw-
7	rwx

Cải thiện tốc độ khi cài đặt Google analytics trên Website của bạn

Ai cũng biết Google analytics là một công cụ để phân tích thống kê số liệu truy cập website nổi tiếng. Khi cài Google analytics vào các website thì mỗi khi người dùng truy cập sẽ phải tải file javascript urchin.js của google, bạn có thể nhìn thấy điều này ở trên thanh status bar của trình duyệt "Transferring data from google-analytics.com". Như vậy sẽ ảnh hưởng đến tốc độ truy cập của người dùng, đặc biệt là các website được host tại Việt Nam.

Bài viết này hướng dẫn cách cải thiện tốc của các trang web cài Google analytics

Đầu tiên sử dụng crontab để tải file urchin.js về

crontab -e

11 12 * * * /home/user/websites/urch.sh >/dev/null 2>&1

Nội dung của urch.sh

#!/bin/sh
rm /home/user/websites/askapache.com/z/j/urchin.js
cd /home/user/websites/askapache.com/z/j/
wget http://www.google-analytics.com/urchin.js
chmod 644 /home/user/websites/askapache.com/z/j/urchin.js
cd ${OLDPWD}
exit 0;

Sau đó bạn thay đổi đường dẫn tới urchin.js trong website của bạn tới file urchin.js ở local

Thiết lập Postfix chuyển email qua một mail server khác ( relay server)

Khi cài đặt postfix trên mạng local kết nối với internet qua ADSL bạn có thể gặp vấn đề khi gửi email thì bị nghi là spam, vì hầu hết các IP động sẽ được đưa vào blacklist. Nếu relay qua một mail server khác có IP tĩnh thì có thể tránh được điều này.

Sau đây tôi xin giới thiệu cách cấu hình Postfix để relay email qua một mail server khác.
Đã cài đặt và chạy thử trên Debian.

Yêu cầu
1. Postfix đã được cài đặt trên hệ thống local của bạn
2. Bạn phải có một tài khoản email trên mail server mà bạn muốn relay
Giả sử tài khoản là test@abc.com, password là xyz, mail server là smtp.abc.com
Thực hiện
Cấu hình Postfix
postconf -e 'relayhost = smtp.exampl.com'
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_sasl_security_options ='

Lưu tài khoản abc vào /etc/postfix/sasl_passwd,
echo "smtp.example.com someuser:howtoforge" > /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd

Chuyển sang định dạng để postfix hiểu được
postmap /etc/postfix/sasl_passwd
/etc/init.d/postfix restart
Sau khi khởi động lại postfix bạn có thể test để kiểm tra kết quả.
Quannv.

Mirror Your Web Site With rsync

Version 1.0
Author: Falko Timme
Last edited 04/20/2006

This tutorial shows how you can mirror your web site from your main web server to a backup server that can take over if the main server fails. We use the tool rsync for this, and we make it run through a cron job that checks every x minutes if there is something to update on the mirror. Thus your backup server should usually be up to date if it has to take over.

rsync updates only files that have changed, so you do not need to transfer 5 GB of data whenever you run rsync. It only mirrors new/changed files, and it can also delete files from the mirror that have been deleted on the main server. In addition to that it can preserve permissions and ownerships of mirrored files and directories; to preserve the ownerships, we need to run rsync as root which is what we do here. If permissions and/or ownerships change on the main server, rsync will also change them on the backup server.

In this tutorial we will tunnel rsync through SSH which is more secure; it also means you do not have to open another port in your firewall for rsync - it is enough if port 22 (SSH) is open. The problem is that SSH requires a password for logging in which is not good if you want to run rsync as a cron job. The need for a password requires human interaction which is not what we want.

But fortunately there is a solution: the use of public keys. We create a pair of keys (on our backup server mirror.example.com), one of which is saved in a file on the remote system (server1.example.com). Afterwards we will not be prompted for a password anymore when we run rsync. This also includes cron jobs which is exactly what we want.

As you might have guessed already from what I have written so far, the concept is that we initiate the mirroring of server1.example.com directly from mirror.example.com; server1.example.com does not have to do anything to get mirrored.

I will use the following setup here:

• Main server: server1.example.com (server1) - IP address: 192.168.0.100
• Mirror/backup server: mirror.example.com (mirror) - IP address: 192.168.0.175
• The web site that is to be mirrored is in /var/www on server1.example.com.

rsync is for mirroring files and directories only; if you want to mirror your MySQL database, please take a look at these tutorials:

• How To Set Up Database Replication In MySQL
• How To Set Up A Load-Balanced MySQL Cluster

I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Install rsync

First we have to install rsync on both server1.example.com and mirror.example.com. For Debian systems, this looks like this:

server1/mirror:

(We do this as root!)

apt-get install rsync

On other Linux distributions you would use yum (Fedora/CentOS) or yast (SuSE) to install rsync.

2 Create An Unprivileged User On server1.example.com

Now we create an unprivileged user called someuser on server1.example.com that will be used by rsync on mirror.example.com to mirror the directory /var/www (of course, someuser must have read permissions on /var/www on server1.example.com).

server1:

(We do this as root!)

useradd -d /home/someuser -m -s /bin/bash someuser

This will create the user someuser with the home directory /home/someuser and the login shell /bin/bash (it is important that someuser has a valid login shell - something like /bin/false does not work!). Now give someuser a password:

passwd someuser

3 Test rsync

Next we test rsync on mirror.example.com. As root we do this:

mirror:

rsync -avz -e ssh someuser@server1.example.com:/var/www/ /var/www/

You should see something like this. Answer with yes:

The authenticity of host 'server1.example.com (192.168.0.100)' can't be established.
RSA key fingerprint is 32:e5:79:8e:5f:5a:25:a9:f1:0d:ef:be:5b:a6:a6:23.
Are you sure you want to continue connecting (yes/no)?

<-- yes

Then enter someuser's password, and you should see that server1.example.com's /var/www directory is mirrored to /var/www on mirror.example.com.

You can check that like this on both servers:

server1/mirror:

ls -la /var/www

You should see that all files and directories have been mirrored to mirror.example.com, and the files and directories should have the same permissions/ownerships as on server1.example.com.

4 Create The Keys On mirror.example.com

Now we create the private/public key pair on mirror.example.com:

mirror:

(We do this as root!)

mkdir /root/rsync
ssh-keygen -t dsa -b 2048 -f /root/rsync/mirror-rsync-key

You will see something like this:

Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): [press enter here]
Enter same passphrase again: [press enter here]
Your identification has been saved in /root/cron/mirror-rsync-key.
Your public key has been saved in /root/cron/mirror-rsync-key.pub.
The key fingerprint is:
68:95:35:44:91:f1:45:a4:af:3f:69:2a:ea:c5:4e:d7 root@mirror

It is important that you do not enter a passphrase otherwise the mirroring will not work without human interaction so simply hit enter!

Next, we copy our public key to server1.example.com:

mirror:

(Still, we do this as root.)

scp /root/rsync/mirror-rsync-key.pub someuser@server1.example.com:/home/someuser/

The public key mirror-rsync-key.pub should now be available in /home/someuser on server1.example.com.

5 Configure server1.example.com

Now log in through SSH on server1.example.com as someuser (not root!) and do this:

server1:

(Please do this as someuser!)

mkdir ~/.ssh
chmod 700 ~/.ssh
mv ~/mirror-rsync-key.pub ~/.ssh/
cd ~/.ssh
touch authorized_keys
chmod 600 authorized_keys
cat mirror-rsync-key.pub >> authorized_keys

By doing this, we have appended the contents of mirror-rsync-key.pub to the file /home/someuser/.ssh/authorized_keys. /home/someuser/.ssh/authorized_keys should look similar to this:

server1:

(Still as someuser!)

vi /home/someuser/.ssh/authorized_keys

ssh-dss AAAAB3NzaC1kc3MAAA[...]lSUom root@
mirror

Now we want to allow connections only from mirror.example.com, and the connecting user should be allowed to use only rsync, so we add

command="/home/someuser/rsync/checkrsync",from="mirror.example.com",no-port-forwarding,no-X11-forwarding,no-pty

right at the beginning of /home/someuser/.ssh/authorized_keys:

server1:

(Still as someuser!)

vi /home/someuser/.ssh/authorized_keys

command="/home/someuser/rsync/checkrsync",from="mirror.example.com",no-port-forwarding,no-X11-forwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAA[...]lSUom root@
mirror

It is important that you use a FQDN like mirror.example.com instead of an IP address after from=, otherwise the automated mirroring will not work!

Now we create the script /home/someuser/rsync/checkrsync that rejects all commands except rsync.

server1:

(We still do this as someuser!)

mkdir ~/rsync
vi ~/rsync/checkrsync

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
       *\&*)
               echo "Rejected"
               ;;
       *\(*)
               echo "Rejected"
               ;;
       *\{*)
               echo "Rejected"
               ;;
       *\;*)
               echo "Rejected"
               ;;
       *\<*)
               echo "Rejected"
               ;;
       *\`*)
               echo "Rejected"
               ;;
       rsync\ --server*)
               $SSH_ORIGINAL_COMMAND
               ;;
       *)
               echo "Rejected"
               ;;
esac
chmod 700 ~/rsync/checkrsync

6 Test rsync On mirror.example.com

Now we must test on mirror.example.com if we can mirror server1.example.com without being prompted for someuser's password. We do this:

mirror:

(We do this as root!)

rsync -avz --delete --exclude=**/stats --exclude=**/error --exclude=**/files/pictures -e "ssh -i /root/rsync/mirror-rsync-key" someuser@server1.example.com:/var/www/ /var/www/

(The --delete option means that files that have been deleted on server1.example.com should also be deleted on mirror.example.com. The --exclude option means that these files/directories should not be mirrored; e.g. --exclude=**/error means "do not mirror /var/www/error". You can use multiple --exclude options. I have listed these options as examples; you can adjust the command to your needs. Have a look at

man rsync

for more information.)

You should now see that the mirroring takes place:

receiving file list ... done

sent 71 bytes  received 643 bytes  476.00 bytes/sec
total size is 64657  speedup is 90.56

without being prompted for a password! This is what we wanted.

7 Create A Cron Job

We want to automate the mirroring, that is why we create a cron job for it on mirror.example.com. Run crontab -e as root:

mirror:

(We do this as root!)

crontab -e

and create a cron job like this:

*/5 * * * * /usr/bin/rsync -azq --delete --exclude=**/stats --exclude=**/error --exclude=**/files/pictures -e "ssh -i /root/rsync/mirror-rsync-key" someuser@server1.example.com:/var/www/ /var/www/

This would run rsync every 5 minutes; adjust it to your needs (see

man 5 crontab

). I use the full path to rsync here (/usr/bin/rsync) just to go sure that cron knows where to find rsync. Your rsync location might differ. Run

mirror:

(We do this as root!)

which rsync

to find out where yours is.

How To Set Up Database Replication In MySQL

Version 1.1
Author: Falko Timme
Last edited: 01/14/2006

This tutorial describes how to set up database replication in MySQL. MySQL replication allows you to have an exact copy of a database from a master server on another server (slave), and all updates to the database on the master server are immediately replicated to the database on the slave server so that both databases are in sync. This is not a backup policy because an accidentally issued DELETE command will also be carried out on the slave; but replication can help protect against hardware failures though.

In this tutorial I will show how to replicate the database exampledb from the master with the IP address 192.168.0.100 to a slave. Both systems (master and slave) are running Debian Sarge; however, the configuration should apply to almost all distributions with little or no modification.

Both systems have MySQL installed, and the database exampledb with tables and data is already existing on the master, but not on the slave.

I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Configure The Master

First we have to edit /etc/mysql/my.cnf. We have to enable networking for MySQL, and MySQL should listen on all IP addresses, therefore we comment out these lines (if existant):

#skip-networking
#bind-address            = 127.0.0.1

Furthermore we have to tell MySQL for which database it should write logs (these logs are used by the slave to see what has changed on the master), which log file it should use, and we have to specify that this MySQL server is the master. We want to replicate the database exampledb, so we put the following lines into /etc/mysql/my.cnf:

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=exampledb
server-id=1

Then we restart MySQL:

/etc/init.d/mysql restart

Then we log into the MySQL database as root and create a user with replication privileges:

mysql -u root -p
Enter password:

Now we are on the MySQL shell.

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY ''; (Replace with a real password!)
FLUSH PRIVILEGES;

Next (still on the MySQL shell) do this:

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

The last command will show something like this:

+---------------+----------+--------------+------------------+ | File | Position | Binlog_do_db | Binlog_ignore_db | +---------------+----------+--------------+------------------+ | mysql-bin.006 | 183 | exampledb | | +---------------+----------+--------------+------------------+ 1 row in set (0.00 sec)

Write down this information, we will need it later on the slave!

Then leave the MySQL shell:

quit;

---

There are two possibilities to get the existing tables and data from exampledb from the master to the slave. The first one is to make a database dump, the second one is to use the LOAD DATA FROM MASTER; command on the slave. The latter has the disadvantage the the database on the master will be locked during this operation, so if you have a large database on a high-traffic production system, this is not what you want, and I recommend to follow the first method in this case. However, the latter method is very fast, so I will describe both here.

If you want to follow the first method, then do this:

mysqldump -u root -p --opt exampledb > exampledb.sql (Replace with the real password for the MySQL user root! Important: There is no space between -p and !)

This will create an SQL dump of exampledb in the file exampledb.sql. Transfer this file to your slave server!

If you want to go the LOAD DATA FROM MASTER; way then there is nothing you must do right now.

---

Finally we have to unlock the tables in exampledb:

mysql -u root -p
Enter password:
UNLOCK TABLES;
quit;

Now the configuration on the master is finished. On to the slave...

2 Configure The Slave

On the slave we first have to create the database exampledb:

mysql -u root -p
Enter password:
CREATE DATABASE exampledb;
quit;

---

If you have made an SQL dump of exampledb on the master and have transferred it to the slave, then it is time now to import the SQL dump into our newly created exampledb on the slave:

mysql -u root -p exampledb < /path/to/exampledb.sql (Replace with the real password for the MySQL user root! Important: There is no space between -p and !)

If you want to go the LOAD DATA FROM MASTER; way then there is nothing you must do right now.

---

Now we have to tell MySQL on the slave that it is the slave, that the master is 192.168.0.100, and that the master database to watch is exampledb. Therefore we add the following lines to /etc/mysql/my.cnf:

server-id=2
master-host=192.168.0.100
master-user=slave_user
master-password=secret
master-connect-retry=60
replicate-do-db=exampledb

Then we restart MySQL:

/etc/init.d/mysql restart

---

If you have not imported the master exampledb with the help of an SQL dump, but want to go the LOAD DATA FROM MASTER; way, then it is time for you now to get the data from the master exampledb:

mysql -u root -p
Enter password:
LOAD DATA FROM MASTER;
quit;

If you have phpMyAdmin installed on the slave you can now check if all tables/data from the master exampledb is also available on the slave exampledb.

---

Finally, we must do this:

mysql -u root -p
Enter password:
SLAVE STOP;

In the next command (still on the MySQL shell) you have to replace the values appropriately:

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=183;

• MASTER_HOST is the IP address or hostname of the master (in this example it is 192.168.0.100).
• MASTER_USER is the user we granted replication privileges on the master.
• MASTER_PASSWORD is the password of MASTER_USER on the master.
• MASTER_LOG_FILE is the file MySQL gave back when you ran SHOW MASTER STATUS; on the master.
• MASTER_LOG_POS is the position MySQL gave back when you ran SHOW MASTER STATUS; on the master.

Now all that is left to do is start the slave. Still on the MySQL shell we run

START SLAVE;
quit;

That's it! Now whenever exampledb is updated on the master, all changes will be replicated to exampledb on the slave. Test it!