Thay thế BIND với djbdns - phần 4

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận hệ điều hành *nix

Thay thế BIND với djbdns - phần 4

[Article] Thay thế BIND với djbdns - phần 4	21/06/2006 15:27:28 (+0700) \| #1 \| 580

tranvanminh
HVA Friend

Joined: 04/06/2003 06:36:35
Messages: 516
Location: West coast
Offline

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.

Go to:

Users currently in here
1 Anonymous