Бүлэг 30. Сүлжээний орчны Серверүүд | FreeBSD Documentation Portal

# Бүлэг 30. Сүлжээний орчны Серверүүд

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

## 30.1. Ерөнхий агуулга

Энэ бүлэгт UNIX® системүүдэд өргөн хэрэглэгддэг, сүлжээний орчинд ажилладаг зарим нэг үйлчилгээнүүдийн талаар авч үзнэ. Бид тэдгээр үйлчилгээнүүдийг хэрхэн суулгах, тохируулах, турших болон үйлчилгээг хариуцах талаар үзэх болно. Танд зориулж жишээ тохиргооны файлуудыг мөн оруулж өгсөн байгаа.

Энэ бүлгийг уншсаны дараа, та дараах зүйлсийг мэдэх болно:

- inetd дэмоныг хэрхэн удирдах.

- Сүлжээний орчны файл системийг хэрхэн зохион байгуулах.

- Хэрэглэгчийн бүртгэлийг хуваалцах сүлжээний орчны мэдээллийн серверийг хэрхэн зохион байгуулах.

- DHCP ашиглан автоматаар сүлжээний тохиргоог хэрхэн хийх.

- Домэйн нэрийн серверийг хэрхэн зохион байгуулах.

- Apache HTTP Серверийг хэрхэн зохион байгуулах.

- File Transfer Protocol буюу Файл Дамжуулах Протокол(FTP) Серверийг хэрхэн зохион байгуулах.

- Samba ашиглан Windows® хэрэглэгчдэд зориулсан файл болон хэвлэгч серверийг хэрхэн зохион байгуулах.

- NTP протокол ашиглан цаг болон өдрийг тохируулах хийгээд цагийн серверийг хэрхэн зохион байгуулах.

- How to configure the standard logging daemon, `syslogd`, to accept logs from remote hosts.

Энэ бүлгийг уншихаасаа өмнө, та дараах шаардлагыг хангасан байх хэрэгтэй:

- /etc/rc скриптүүдийн үндсийг ойлгосон байх.

- Сүлжээний үндсэн нэр томъёоллыг мэддэг байх.

- Гуравдагч этгээдийн програмыг(Програм суулгах. Багцууд болон портууд) хэрхэн нэмж суулгахыг мэддэг байх.

## 30.2. inetd"Супер-Сервер"

### 30.2.1. Ерөнхий агуулга

inetd(8) нь олон тооны үйлчилгээний сүлжээний холболтыг удирддаг тул заримдаа түүнийг "Интернэт Супер-Сервер" гэж нэрлэх нь бий. Гаднаас үүсч буй холболтыг inetd хүлээн авч, аль програмтай холбогдохыг тодорхойлон, тухайн процессийг салаалуулж, сокетийг түүн рүү чиглүүлнэ (програмын стандарт оролт, гаралт болон алдааны дескриптороор үйлчилгээний сокетийг өгнө). Байнга ашиглагддаггүй үйлчилгээний хувьд inetd-г ажиллуулах нь бүх дэмонг дангаар бие-даах горимд ажиллуулсантай харьцуулахад системийн нийт ачааллыг бууруулж өгдөг.

Голчлон, inetd нь бусад дэмонуудыг салаалуулахад хэрэглэгддэг боловч chargen, auth, ба daytime гэх мэт нилээд олон ердийн протоколуудыг шууд зохицуулан ажиллуулж чадна.

Энэ хэсэгт inetd-н үндсэн тохиргоог тушаалын мөрний тохируулгаар, мөн /etc/inetd.conf тохиргооны файлаар хэрхэн хийхийг үзэх болно.

### 30.2.2. Тохиргоо

inetd нь rc(8) системээр эхлүүлэгдэнэ. `inetd_enable` тохируулгын анхдагч утга нь `NO` бөгөөд, системийг суулгах явцад хэрэглэгчийн зааж өгсний дагуу sysinstall програмын тусламжтай идэвхжүүлж болно.

    inetd_enable="YES"

эсвэл

    inetd_enable="NO"

гэсэн мөрийг /etc/rc.conf файл дотор байрлуулснаар inetd-г систем ачаалахад эхэлдэг болгож болно. Доор дурдсан:

    service inetd rcvar

тушаалыг өгөн одоо идэвхтэй байгаа тохиргоог харж болно.

Дээр нь, `inetd_flags` тохируулгаар дамжуулан inetd програмд тушаалын мөрнөөс өөр бусад тохируулгуудыг зааж өгч болно.

### 30.2.3. Тушаалын мөрний тохируулгууд

Ихэнх сервер дэмоны нэгэн адил, inetd нь түүнийг өөрчлөн тохируулахад зориулагдсан олон тооны тохируулгуудын хамт ирдэг. Сонголтуудын бүрэн жагсаалтыг inetd(8) гарын авлагын хуудаснаас үзнэ үү.

/etc/rc.conf файл доторх `inetd_flags` тохируулгыг ашиглан эдгээр тохируулгуудыг inetd-д дамжуулна. Анхдагч байдлаар, `inetd_flags` нь `-wW -C 60` гэсэн утгыг авсан байх ба энэ нь inetd-ны үйлчилгээнүүдийн хувьд TCP wrapping буюу TCP-ийн дундын хяналтыг идэвхжүүлэх ба нэг IP хаягнаас аль нэг үйлчилгээнд нэг минутанд 60-аас дээш удаа хүсэлт тавих боломжгүй болгоно.

Хэдийгээр бид хурдыг хэрхэн хязгаарлахыг доор үзүүлж байгаа ч, анхлан суралцагчдын хувьд эдгээр параметрүүдийг ихэвчлэн өөрчлөх шаардлагагүй байдаг. Эдгээр тохируулга нь гаднаас хэтэрхий олон тооны хандалт хийгдэж байгаа үед тустай байдаг Тохируулгуудын бүрэн жагсаалтыг inetd(8) заавар хуудаснаас үзнэ үү.

-c maximum

  Үйлчилгээг нэгэн зэрэг хамгийн ихдээ хэдэн удаа дуудаж болохыг заана; Анхдагч утга нь хязгааргүй. Үйлчилгээ тус бүрээр `max-child` параметрийн тусламжтай утгыг дарж өөрчилж болно.

-C rate

  Үйлчилгээг нэг IP хаягнаас нэг минутын дотор хамгийн ихдээ хэдэн удаа дуудаж болохыг заана; Анхдагч утга нь хязгааргүй. Үйлчилгээ тус бүрээр `max-connections-per-ip-per-minute` параметрийн тусламжтай утгыг дарж өөрчилж болно.

-R rate

  Үйлчилгээг нэг минутын дотор хамгийн ихдээ хэдэн удаа дуудаж болохыг заана; Анхдагч утга нь 256. 0-г тавьснаар хязгааргүй болгоно.

-s maximum

  Үйлчилгээг нэг IP хаягнаас хамгийн ихдээ хэдэн удаа дуудаж болохыг заана; Анхдагч утга нь хязгааргүй. Үйлчилгээ тус бүрээр `max-child-per-ip` параметрийн тусламжтай утгыг дарж өөрчилж болно.

### 30.2.4. inetd.conf

inetd-г /etc/inetd.conf файлын тусламжтай тохируулна.

/etc/inetd.conf файлд өөрчлөлт хийсний дараа, inetd-р тохиргооны файлыг дахин уншуулахдаа дараах тушаалыг өгнө:

Жишээ 1. inetd-н тохиргооны файлыг дахин ачаалах нь

    # service inetd reload

Тохиргооны файлын мөр бүр тусдаа дэмонг заана. Файл доторх тайлбарууд нь мөрийн эхэнд "#" тэмдэгтэй байна. /etc/inetd.conf файл доторх бичлэгүүдийн формат дараах байдалтай байна:

    service-name
    socket-type
    protocol
    {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]
    user[:group][/login-class]
    server-program
    server-program-arguments

IPv4 ашигладаг ftpd(8) дэмоны хувьд жишээ бичлэг дараах байдалтай байж болно:

    ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l

service-name

  Тухайн дэмоны үйлчилгээний нэрийг заана. Энэ нь /etc/services файл дотор бичигдсэн үйлчилгээнүүдийн нэг байх ёстой бөгөөд аль портон дээр сонсохыг inetd-д хэлж өгнө. Хэрэв шинэ үйлчилгээ үүсгэсэн бол түүнийг заавал /etc/services файл дотор нэмсэн байх ёстой.

socket-type

  `stream`, `dgram`, `raw`, эсвэл `seqpacket` эдгээрийн нэг байна. `stream`-г холболтон дээр үндэслэсэн TCP дэмонуудын хувьд хэрэглэдэг бол, `dgram`-г UDP протоколоор ажилладаг дэмонуудын хувьд хэрэглэнэ.

protocol

  Доор дурдсанаас нэг нь байна:

  Протокол | Тайлбар
  --- | ---
  tcp, tcp4 | TCP IPv4
  udp, udp4 | UDP IPv4
  tcp6 | TCP IPv6
  udp6 | UDP IPv6
  tcp46 | TCP IPv4 ба v6 хоёул
  udp46 | UDP IPv4 ба v6 хоёул

{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]

  `wait|nowait` нь inetd-р дуудагдсан дэмон өөрийн сокетийг удирдаж чадах эсэхийг заана. `dgram` төрлийн сокет дэмоны хувьд `wait` тохируулгыг хэрэглэх ёстой байдаг бол, ихэвчлэн олон урсгалтай байдаг `stream` сокет дэмоны хувьд `nowait` тохируулгыг хэрэглэх хэрэгтэй байдаг. `wait` нь ихэвчлэн олон сокетийг нэг дэмонд шилжүүлэн өгдөг бол, `nowait` нь шинээр үүссэн сокет тус бүрт харгалзуулан хүүхэд дэмонг салаалуулан үүсгэдэг.

  inetd-ийн салаалуулан үүсгэж болох хамгийн их хүүхэд дэмоны тоог `max-child` тохируулгын тусламжтай зааж өгч болно. Хэрэв тухайн дэмоны ажиллаж болох тохиолдлыг 10-р хязгаарлах бол, `nowait`-н ард `/10` гэж бичнэ. `/0` нь хүүхдийн тоог хязгаарлахгүй гэсэн утгатай.

  `max-child`-с гадна, нэг газраас тухайн дэмонтой үүсгэж байгаа холболтын тоог хязгаарладаг өөр хоёр тохируулгыг хэрэглэж болно. `max-connections-per-ip-per-minute` нь тухайн ямар нэг IP хаягнаас нэг минутанд үүсгэж болох холболтын тоог хязгаарлана, жишээлбэл: 10 гэсэн утга нь тухайн ямар нэг IP хаягнаас нэг минутын дотор тухайн үйлчилгээнд холбогдохоор оролдох оролдлогын тоог 10-р хязгаарлана. `max-child-per-ip` нь Тухайн ямар нэг IP хаяг дээр үүсгэгдсэн хүүхдийн тоог хязгаарлана. Эдгээр тохируулгууд нь санаатай болон санамсаргүйгээр нөөцийг хэтрүүлэн хэрэглэх, мөн Үйлчилгээг Зогсоох (DoS) халдлагаас хамгаалахад хэрэгтэй байдаг.

  Хэрэглэхдээ, `wait` ба `nowait` хоёрын аль нэгийг заавал хэрэглэх ёстой. Харин `max-child`, `max-connections-per-ip-per-minute` ба `max-child-per-ip` тохируулгуудыг сонгон хэрэглэж болно.

  Stream төрлийн олон урсгалтай дэмоны хувьд, `max-child`, `max-connections-per-ip-per-minute` эсвэл `max-child-per-ip` хязгаарлалтуудын алийг ч хэрэглэхгүй тохиолдолд ердөө: `nowait` байна.

  Дээрхтэй адил дэмон, 10 хүүхэд дэмоны хязгаарлалттай бол: `nowait/10` байна.

  Мөн адил дэмон, 10 хүүхэд дэмоны хязгаарлалттай, минутанд нэг IP хаягнаас үүсгэх холболтын тоог 20-р хязгаарлах бол: `nowait/10/20` болно.

  Эдгээр тохируулгуудыг fingerd(8) дэмоны анхдагч тохиргоон дээр жишээ болгон харвал:

      finger stream  tcp     nowait/3/10 nobody /usr/libexec/fingerd fingerd -s

  Эцэст нь, 100 хүүхдийн хязгаарлалттай, нэг IP хаягнаас үүсэх холболтын тоог 5-р хязгаарласан дэмоны жишээг авбал: `nowait/100/0/5` байх юм.

user

  Энд тухайн дэмон ямар хэрэглэгчийн нэрээр ажиллахыг зааж өгнө. Ихэвчлэн дэмонууд `root` хэрэглэгчийн нэр дээр ажилладаг. Аюулгүй байдлын үүднээс, зарим серверүүд `daemon`, эсвэл хамгийн бага эрхтэй `nobody` хэрэглэгчийн нэр дээр ажиллах нь элбэг байдаг.

server-program

  Энд гаднаас холболт хүлээн авахад ажиллуулах дэмоны бүрэн замыг зааж өгнө. Хэрэв энэ дэмон inetd-р удирдагдсан дотоод үйлчилгээ бол `internal` тохируулгыг хэрэглэх хэрэгтэй.

server-program-arguments

  Үүнийг `server-program`-тай хамт, `argv[0]`-с эхлэн програмын аргументыг зааж өгөх байдлаар хэрэглэнэ. Хэрэв командын мөрөнд `mydaemon -d` гэсэн байдлаар хэрэглэдэг бол, `server-program-arguments`-н утга `mydaemon -d` байна. Дахин хэлэхэд, хэрэв тухайн дэмон дотоод үйлчилгээний нэг бол `internal`-г энд мөн хэрэглэнэ үү.

### 30.2.5. Аюулгүй байдал

Үйлдлийн системийг суулгах үед хийсэн сонголтуудаас хамааран inetd-н үйлчилгээнүүдийн ихэнх нь идэвхтэй болсон байдаг. Хэрэв хэрэглэх онцын шаардлага байхгүй бол тэдгээрийг идэвхгүй болгоно уу. /etc/inetd.conf файл дотор, идэвхгүй болгох гэж байгаа демоныхоо харгалзах мөрийн урд "#" тэмдгийг тавьж өгнө. Дараа нь inetd-н тохиргоог дахин ачаална. fingerd зэрэг зарим дэмонууд гадны халдагчид хэрэгтэй мэдээллийг түгээж байдаг тул тэдгээр үйлчилгээг бүрмөсөн хааж болох юм.

Зарим дэмонууд аюулгүй байдлыг бодолцолгүйгээр бүтээгдсэн байдаг ба холболт тогтоох харьцангуй урт болзоот хугацаатай, эсвэл болзоот хугацааг огт зааж өгөөгүй байдаг. Энэ нь халдагчид тодорхой дэмон уруу холболт тогтоох хүсэлтийг олон дахин илгээж, нөөцийг дуусгах замаар системд халдах боломжийг олгодог. Хэрэв ямар нэг дэмоны хувьд үүссэн холболтын тоо хэтэрхий олон байвал `max-connections-per-ip-per-minute`, `max-child` эсвэл `max-child-per-ip` тохиргооны тусламжтайгаар хязгаарлалт хийх нь оновчтой байдаг.

Анхдагч байдлаар TCP-ийн дундын хяналт (гүйцэтгэл хялбаршуулалт) идэвхтэй байдаг. inetd-р дуудагдсан дэмонуудын хувьд TCP хязгаарлалтыг хэрхэн тавих талаар дэлгэрэнгүй мэдээллийг hosts_access(5) заавар хуудаснаас үзнэ үү.

### 30.2.6. Элдэв зүйлс

daytime, time, echo, discard, chargen, ба auth бүгд inetd-н дотоод үйлчилгээнүүд юм.

auth үйлчилгээ нь сүлжээний орчинд, тодорхойлолт өгөх үйлчилгээ үзүүлдэг бөгөөд тодорхой түвшинд тохиргоо хийх боломжтой байдаг бол бусад үйлчилгээнүүдийг зөвхөн идэвхтэй эсвэл идэвхгүй болгох боломжтой.

Дээрх үйлчилгээнүүдийн талаар бүрэн дүүрэн мэдээллийг inetd(8) заавар хуудаснаас үзнэ үү.

## 30.3. Сүлжээний Файлын Систем (NFS)

FreeBSD дээр дэмжигддэг олон файлын системүүдийн нэг бол Network File System буюу Сүлжээний Файлын Систем юм, мөн NFS гэж нэрлэнэ. NFS нь сүлжээний орчинд файл болон санг бусадтай хуваалцах боломжийг олгодог. NFS-г хэрэглэн, хэрэглэгчид болон програмууд алслагдсан систем рүү дотоод файл руу хандаж байгаатай адилаар хандах боломжтой.

NFS-н тэмдэглүүштэй давуу талуудаас дурдвал:

- Өргөн хэрэглэгддэг өгөгдлийг нэгтгэн нэг машин дээр байрлуулж, түүнд алсаас хандах боломжтой болсноор дотоод машинууд илүү бага диск хэрэглэх болно.

- Хэрэглэгчийн хувьд сүлжээнд байгаа машин бүр дээр тус тусдаа гэрийн сантай байх шаардлагагүй болно. Гэрийн санг нэг удаа NFS сервер дээр үүсгээд түүнийгээ сүлжээгээр дамжин хэрэглэх боломжтой.

- Уян диск, CDROM болон Zip® төхөөрөмжүүдийг сүлжээний бусад машинууд хэрэглэх боломжтой болно. Ингэснээр сүлжээнд хэрэглэгдэх зөөвөрлөх боломжтой хадгалах төхөөрөмжүүдийн тоог багасгана.

### 30.3.1. NFS хэрхэн ажилладаг вэ

NFS нь үндсэн хоёр хэсгээс бүрдэнэ: сервер болон нэг ба түүнээс дээш тооны харилцагч. Сервер машин дээр хадгалагдаж байгаа өгөгдөл рүү харилцагч алсаас хандана. Дээрх үйлдлийг зөв гүйцэтгэхийн тулд нилээд хэдэн процессийн тохиргоог хийж, ажиллуулсан байх ёстой.

Сервер дээр дараах дэмонууд ажиллаж байх ёстой:

Дэмон | Тайлбар
--- | ---
nfsd | NFS харилцагчдаас ирэх хүсэлтийг хүлээн авах NFS дэмон.
mountd | nfsd(8)-с дамжиж ирсэн хүсэлтийг гүйцэтгэгч NFS холбох дэмон.
rpcbind | Энэ дэмоны тусламжтай NFS харилцагчид NFS сервер аль портон дээр ажиллаж байгааг олж мэднэ.

Харилцагч nfsiod гэсэн дэмонг мөн ажиллуулж болно. nfsiod дэмон NFS серверээс ирэх хүсэлтийг гүйцэтгэнэ. Ингэх нь системийг хэвийн, алдаагүй ажиллуулахад зайлшгүй шаардлагагүй боловч зарим үзүүлэлтүүдийг сайжруулдаг тул нэмэлт байдлаар хэрэглэж болно. Дэлгэрэнгүй мэдээллийг nfsiod(8) хуудаснаас үзнэ үү.

### 30.3.2. NFS-н тохиргоог хийх

NFS-н тохиргоог хийх нь харьцангуй амархан. Ажиллах ёстой процессуудыг системтэй хамт автоматаар асдаг болгохын тулд /etc/rc.conf файлыг бага зэрэг өөрчлөхөд хангалттай.

NFS сервер дээрх /etc/rc.conf файл дотор дараах тохируулгууд идэвхжсэн байгаа эсэхийг шалгана уу:

    rpcbind_enable="YES"
    nfs_server_enable="YES"
    mountd_flags="-r"

mountd нь NFS серверийг идэвхжүүлсэн тохиолдолд өөрөө автоматаар ажиллана.

Харилцагч талд, /etc/rc.conf файл дотор дараах тохируулга идэвхтэй байгаа эсэхийг шалгана уу:

    nfs_client_enable="YES"

/etc/exports файл дотор NFS ямар файл системүүдийг экспорт хийхийг (заримдаа "хуваалцах" гэж мөн нэрлэнэ) зааж өгнө. /etc/exports файлын мөр бүр нь нэг файл системд харгалзана. Энэ файл системд хандах эрхтэй машинуудыг заахаас гадна, ямар тохируулгаар хандахыг мөн зааж өгч болно. Энэ файл дотор бичигдэж болох нилээд олон ийм тохируулгууд байгаа хэдий ч, бид тэдгээрээс зөвхөн заримыг нь энд авч үзэх болно. Та бусад тохируулгуудын талаар exports(5) заавар хуудаснаас уншиж мэднэ үү.

Доор /etc/exports файлаас хэдэн жишээ мөрийг үзүүлэв:

Дараах жишээн дээрээс файл системийг хэрхэн экспортлох санааг олж авах болно. Тохируулгууд нь таны сүлжээний тохиргоо, нөхцөл байдлаас шалтгаалан өөр байхыг анхаарна уу. Жишээ нь, /cdrom гэсэн санг 3 машин руу экспортлохын тулд дараах байдалтай бичнэ. Жишээн дээрх 3 машин сервертэй адил домэйн нэртэй, эсвэл таны /etc/hosts файл дотор тодорхойлогдсон гэж үзсэн болно. `-ro` туг нь экспортлогдож буй файл системийг зөвхөн унших боломжтой болохыг заана. Энэ тугийг тавьснаар алсаас хандаж буй машин энэ файл систем дээр ямар нэг өөрчлөлт хийх боломжгүй болно.

    /cdrom -ro host1 host2 host3

Дараах жишээн дээр /home санг IP хаягаар нь зааж өгсөн 3 машин руу экспортолж байна. Ингэж IP хаягаар нь зааж өгөх нь дотоод сүлжээндээ DNS сервер ажиллуулаагүй үед их хэрэгтэй байдаг. Эсвэл /etc/hosts файл дотор дотоод хостуудын нэрийг тохируулж болно; hosts(5) хэсгийг дахин үзнэ үү. `-alldirs` гэсэн туг нь дэд сангуудыг холболтын цэг байхыг зөвшөөрч өгдөг. Өөрөөр хэлбэл, дэд сангуудыг холболгүй орхиж, харилцагч зөвхөн өөрийн хэрэгцээтэй байгаа сангаа холбохыг зөвшөөрнө гэсэн үг юм.

    /home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

Дараах жишээн дээр /a санг хоёр өөр домэйноос 2 харилцагч хандаж болохоор экспортолж байна. `-maproot=root` гэсэн туг нь алслагдсан систем дээрх `root` хэрэглэгч экспортлогдсон файл систем дээр `root` эрхээр бичихийг зөвшөөрнө. Хэрэв `-maproot=root` тугийг тусгайлан зааж өгөөгүй бол, хэдий алслагдсан систем дээрх хэрэглэгч `root` эрхтэй ч экспортлогдсон файл систем дээр бичих эрхгүй болно.

    /a  -maproot=root  host.example.com box.example.org

Харилцагч экспортлогдсон файл систем рүү хандахын тулд эрх нь байх ёстой. Тухайн харилцагч /etc/exports файл дотор бүртгэлтэй эсэхийг шалгаарай.

/etc/exports файл дотор мөр болгон нь нэг файл системийг нэг хост руу экспортлох мэдээллийг төлөөлнө. Алслагдсан хост аль нэг файл системийн хувьд зөвхөн ганц удаа л тодорхойлогдсон байх ёстой ба үүнд харгалзах ганцхан анхдагч бичлэг байж болно. Жишээ нь, /usr нь нэг файл систем гэж бодъё. /etc/exports файл доторх дараах бичлэгүүд нь буруу юм:

    # Invalid when /usr is one file system
    /usr/src   client
    /usr/ports client

Учир нь /usr гэсэн файл системийг `client` гэсэн хост руу экспортолсон хоёр бичлэг байна. Энэ тохиолдолд дараах форматаар бичвэл зөв болно:

    /usr/src /usr/ports  client

Нэг хост руу экспортлогдож байгаа файл системийн хувьд шинжүүдийг бүгдийг нэг мөрөнд жагсаан бичих ёстой. Харилцагчийг зааж өгөөгүй мөрүүдийг энгийн хост гэж үзнэ. Энэ нь файл системийг экспортлох боломжийг хязгаарлана, гэвч энэ нь ихэнх хүмүүст хүнд асуудал биш байдаг.

Дараагийн жишээн дээр /usr ба /exports гэсэн дотоод файл системийг экспортолсон байна:

    # Export src and ports to client01 and client02, but only
    # client01 has root privileges on it
    /usr/src /usr/ports -maproot=root    client01
    /usr/src /usr/ports               client02
    # The client machines have root and can mount anywhere
    # on /exports. Anyone in the world can mount /exports/obj read-only
    /exports -alldirs -maproot=root      client01 client02
    /exports/obj -ro

/etc/exports файл дотор гарсан өөрчлөлтүүдийг хүчинтэй болгохын тулд, өөрчлөлт орсон тухай бүрд mountd дэмонг албадан /etc/exports-г дахин уншуулах хэрэгтэй болдог. Үүний тулд эсвэл HUP дохиог ажиллаж байгаа дэмонд өгөх хэрэгтэй:

    # kill -HUP `cat /var/run/mountd.pid`

эсвэл `mountd` rc(8) скриптийг зохих параметрийн хамт ажиллуулах хэрэгтэй:

    # service mountd onereload

rc скриптийг хэрэглэх зааврыг FreeBSD дээр rc(8) ашиглах нь хэсгээс үзнэ үү.

Бас нэг боломж нь, FreeBSD-г эхнээс нь ачаалж, бүх процессийг дахин эхлүүлэх юм. Гэвч үүний тулд заавал системийг дахин ачаалах шаардлага байхгүй. `root` эрхээр дараах тушаалуудыг өгснөөр зөвхөн хэрэгтэй процессуудаа дахин эхлүүлэх боломжтой.

NFS сервер дээр:

    # rpcbind
    # nfsd -u -t -n 4
    # mountd -r

NFS харилцагч дээр:

    # nfsiod -n 4

Одоо алсын файл системийг холбоход бэлэн боллоо. Доорх жишээнүүд дээр серверийн нэрийг `server`, харилцагчийн нэрийг `client` гэж авсан болно. Хэрэв та алсын файл системийг зөвхөн түр хугацаагаар холбох гэж байгаа эсвэл тохиргоогоо шалгах гэж байгаа бол, харилцагч талд `root` эрхээр дараах тушаалыг өгөхөд хангалттай:

    # mount server:/home /mnt

Энэ тушаалыг өгснөөр та сервер талд байгаа /home гэсэн санг харилцагч талд байгаа /mnt сантай холбох болно. Хэрэв бүх зүйл зөв тохируулагдсан бол, та харилцагч талын /mnt сан дотор орж сервер дээр байгаа файлуудыг харж чадах ёстой.

Хэрэв систем шинээр ачаалах бүрд ямар нэг алсын файл системийг холбох хүсэлтэй байгаа бол, түүнийгээ /etc/fstab файл дотор нэмж бичих хэрэгтэй. Жишээ нь:

    server:/home	/mnt	nfs	rw	0	0

Боломжит бүх сонголтуудын талаар fstab(5) заавар хуудаснаас үзнэ үү.

### 30.3.3. Цоожлолт

Зарим програмууд (ж.н. mutt) зөв ажиллахын тулд файл цоожлолтыг шаарддаг. NFS-н хувьд, rpc.lockd-г файл цоожлолтонд хэрэглэж болно. Түүнийг идэвхжүүлэхийн тулд, сервер болон харилцагч талд хоёуланд нь /etc/rc.conf файл дотор дараах мөрүүдийг нэмж өгөх хэрэгтэй (NFS сервер болон харилцагч талуудыг аль хэдийн тохируулчихсан гэж үзэв):

    rpc_lockd_enable="YES"
    rpc_statd_enable="YES"

Програмыг дараах байдалтай эхлүүлнэ:

    # service lockd start
    # service statd start

Хэрэв NFS харилцагч болон NFS сервер талуудын хооронд жинхэнэ файл цоожлолт хийгдэх шаардлагагүй бол, NFS харилцагч талд mount_nfs(8)-д `-L` тохируулгыг өгөн дотоод цоожлолт хийлгэж болно. Дэлгэрэнгүй мэдээллийг mount_nfs(8) заавар хуудаснаас үзнэ үү.

### 30.3.4. Практик хэрэглээ

NFS нь олон практик хэрэглээтэй. Хамгийн элбэг тохиолддог хэрэглээг доор жагсаав:

- Олон машиныг нэг CDROM эсвэл төхөөрөмжийг дундаа хэрэглэдэг байхаар зохион байгуулах. Энэ нь нэг програмыг олон машин дээр суулгах хамгийн хямд, хялбар арга юм.

- Том сүлжээний хувьд, бүх хэрэглэгчдийн гэрийн санг хадгалдаг төвлөрсөн NFS серверийг тохируулах. Эдгээр гэрийн сангуудыг дараа нь сүлжээний орчинд экспортолсноор хэрэглэгчид аль машин дээр ажиллаж буйгаас үл хамааран өөрийн нэг л сан дотор ажиллах боломжтой болно.

- Олон машин дундаа нэг /usr/ports/distfiles сантай байх. Ийм замаар, нэг портыг олон машин дээр суулгах хэрэгтэй үед машин бүр дээр эх файлыг татаж авалгүйгээр хурдан суулгах боломжтой болно.

### 30.3.5. amd-р автоматаар холбох нь

amd(8) (автоматаар холбогч дэмон) нь алсын файл системийн файл эсвэл санд хэрэглэгч хандах тухай бүрт уг файл системийг автоматаар холбодог. Хэсэг хугацааны туршид идэвхгүй байгаа файл системийг amd мөн автоматаар салгана. amd-г хэрэглэснээр /etc/fstab дотор бичигддэг байнгын холболтоос гадна, холболт хийх боломжийг олгодог.

amd нь өөрийгөө, /host ба /net сангууд дээр NFS сервер байдлаар холбож ажиллах бөгөөд эдгээр сангууд доторх файлд хандах үед, amd харгалзах алсын холболтыг хайж олоод автоматаар холбох болно. /net нь экспортлогдсон файл системийг IP хаягаар нь холбоход, харин /host нь хост нэрээр нь холбоход хэрэглэгдэнэ.

/host/foobar/usr сан доторх файлд хандана гэдэг нь amd-г `foobar` гэсэн хост дээр экспортлогдсон /usr санг холбохын зааж өгнө.

Жишээ 2. Экспортыг amd-р холбох

Алсын хост дээр байгаа боломжит холболтуудын жагсаалтыг `showmount` тушаалын тусламжтай харж болно. Жишээлбэл, `foobar` нэртэй хостын экспортыг харахын тулд:

    % showmount -e foobar
    Exports list on foobar:
    /usr                               10.10.10.0
    /a                                 10.10.10.0
    % cd /host/foobar/usr

Жишээн дээр үзүүлснээр `showmount` нь /usr-г экспортлогдсон болохыг харуулж байна. /host/foobar/usr сан дотор ороход, amd нь `foobar` гэсэн хост нэрийг тайлахыг оролдох ба заасан санг холбоно.

amd-г эхлэл скриптүүдээр эхлүүлж болох ба үүний тулд /etc/rc.conf файл дотор дараах мөрийг нэмэх хэрэгтэй:

    amd_enable="YES"

Мөн, amd програмд `amd_flags` тохируулгын тусламжтай тугуудыг өгч болно. `amd_flags`-н анхдагч утга нь:

    amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"

/etc/amd.map файл дотор экспортуудыг холбох анхдагч тохируулгуудыг зааж өгсөн байна. /etc/amd.conf файл дотор amd-н илүү дээд түвшний чанаруудыг тодорхойлж өгнө.

Дэлгэрэнгүй мэдээллийг amd(8) ба amd.conf(8) заавар хуудаснаас үзнэ үү.

### 30.3.6. Бусад системтэй нэгтгэхэд тохиолдох асуудлууд

ISA PC системд зориулсан зарим Ethernet адаптерууд учир дутагдалтай байдгаас сүлжээний орчинд ажиллахад, тэр дундаа NFS-тэй ажиллахад нилээд асуудалтай байдаг. Энэ асуудал зөвхөн FreeBSD-д тохиолддоггүй боловч FreeBSD систем үүнд нилээд өртөмтгий байдаг.

Энэ асуудал нь (FreeBSD) PC системийг өндөр үзүүлэлттэй машинуудтай (жишээлбэл, Silicon Graphics, Inc., ба Sun Microsystems, Inc компаниудын хийсэн) сүлжээнд холбох үед бараг үргэлж тохиолддог. NFS холболт хийхэд асуудалгүй, зарим үйлдлүүдийг хийхэд амжилттай байх боловч, гаднаас ирж явж байгаа хүсэлтүүдийг боловсруулж чадаж байгаа хэдий ч сервер гэнэт харилцагчид хариу өгөхгүй болдог. Энэ асуудал мөн харилцагчийн хувьд, харилцагч FreeBSD систем эсвэл ажлын машин байхаас үл шалтгаалан тохиолдоно. Ихэнх системийн хувьд, нэгэнт ийм асуудалд орсон бол харилцагч талыг ном ёсных нь дагуу унтраах боломжгүй болдог. Ганц авдаг арга хэмжээ бол системийг хүчээр унтрааж асаах юм. Учир нь, NFS-н энэ асуудал одоо хир нь шийдэгдээгүй байна.

Хэдийгээр "зөв" шийдэл бол FreeBSD системд тохирох илүү өндөр үзүүлэлттэй, илүү багтаамжтай Ethernet адаптерийг олж авах боловч, боломжит ажиллагааг хангахын тулд нэг арга байна. Хэрэв FreeBSD систем нь сервер бол, харилцагч талаас холболт хийхдээ `-w=1024` тохируулгыг оруулж өгөх явдал юм. Хэрэв FreeBSD систем нь харилцагч бол, NFS файл системтэй холбогдохдоо `-r=1024` тохируулгыг хэрэглэх юм. Эдгээр тохируулгуудыг автомат холболтын хувьд fstab бичлэгийн дөрөв дэх талбарыг ашиглан, гар аргаар холболт хийх бол mount(8) тушаалын `-o` параметрыг ашиглан зааж өгч болно.

NFS сервер болон харилцагчид өөр өөр сүлжээнд байхад гардаг өөр нэг асуудлыг энэ асуудалтай хольж хутгах тохиолдол байдгийг энд дурдах нь зүйтэй болов уу. Хэрэв тийм бол, чиглүүлэгчид шаардлагатай UDP мэдээллийг дамжуулж чадаж байгаа эсэхийг нягталж үзээрэй. Үгүй бол, өөр юу ч хийлээ гээд та үр дүнд хүрч чадахгүй.

Дараах жишээн дээр, `fastws` нь өндөр үзүүлэлттэй ажлын машины хост (интерфэйс) нэр, `freebox` нь бага үзүүлэлттэй Ethernet адаптертай FreeBSD системийн нэр юм. Мөн, /sharedfs нь экспортлогдох гэж байгаа NFS файл систем (exports(5)-г үз), ба /project нь харилцагч талын экспортлогдсон файл системийг холбох цэг байх болно. Аль ч тохиолдолд, `hard` эсвэл `soft` ба `bg` зэрэг нэмэлт тохируулгууд таны хувьд хэрэгтэй байж болох юм.

FreeBSD системийг (`freebox`) `freebox` дээр /etc/fstab дотор харилцагч байдлаар зааж өгөх жишээ:

    fastws:/sharedfs /project nfs rw,-r=1024 0 0

`freebox` дээр гараар холбохдоо:

    # mount -t nfs -o -r=1024 fastws:/sharedfs /project

FreeBSD системийг (`freebox`) `fastws` дээр /etc/fstab дотор сервер байдлаар зааж өгөх жишээ:

    freebox:/sharedfs /project nfs rw,-w=1024 0 0

`fastws` дээр гараар холбохдоо:

    # mount -t nfs -o -w=1024 freebox:/sharedfs /project

Бараг бүх 16-битийн Ethernet адаптерийн хувьд унших ба бичих хэмжээн дээр дээрх байдлаар хязгаарлалт хийлгүйгээр ажиллах боломжтой байдаг.

Сонирхсон улсуудад толилуулахад, дээрх алдаа гарахад чухам юу тохиолддог, яагаад засагдах боломжгүй болох талаар дор тайлбарлав. NFS нь голчлон 8 K (хэдийгээр илүү бага хэмжээтэй хэсэг дээр ажиллаж чадах боловч) хэмжээтэй "блок"ууд дээр ажилладаг. Хамгийн урт Ethernet пакет 1500 байт орчим байх ба, NFS "блок" нь хэд хэдэн Ethernet пакетуудад хуваагдах хэрэгтэй болдог. Дээд түвшний програмын хувьд энэ нь нэг нэгж хэвээр байх ба хүлээж аваад, нийлүүлээд, бататгал хийхэд ч мөн нэг нэгж хэвээр байдаг. Өндөр үзүүлэлттэй ажлын машинууд NFS нэгжийг бүрдүүлж байгаа тэдгээр пакетуудыг стандартад заасны дагуу аль болох ойрхон ойрхон, нэг нэгээр нь цувуулж гаргана. Жижиг, бага багтаамжтай картууд дээр, дээд түвшний програмд дамжуулахаас өмнө сүүлийн пакет нь өмнөх пакетаа дарснаар тухайн нэгжийг буцааж нийлүүлж, бататгах боломжгүй болно. Үүнээс болж, ажлын машины болзоот хугацаа дуусаж бүхэл бүтэн 8 K нэгжийг дахин дамжуулах болно. Энэ үйл ажиллагаа дахин дахин хязгааргүй давтагдах болно.

Нэгжийн хэмжээг Ethernet пакетийн хэмжээнээс бага байлгаснаар, бид Ethernet пакет тус бүрийг бататгаж мухардалд орохоос сэргийлж чадна.

Өндөр үзүүлэлттэй ажлын машинууд PC систем рүү өгөгдлийг цацсаар байх үед давхцал үүссээр байх боловч, илүү сайн карт ашигласнаар NFS "нэгж"ийн хувьд заавал тийм давхцал үүсэх албагүй болно. Давхцал үүссэн тохиолдолд, түүнд өртсөн нэгжийг дахин дамжуулах ба түүнийг хүлээн авч, нийлүүлж, бататгах боломж өндөртэй.

## 30.4. Сүлжээний Мэдээллийн Систем (NIS/YP)

### 30.4.1. Энэ юу вэ?

NIS, нь Network Information Services буюу Сүлжээний Мэдээллийн Үйлчилгээнүүд гэсэн үгийн товчлол бөгөөд UNIX® (анхандаа SunOS™) системүүдийн удирдлагыг төвлөрүүлэх зорилгоор Sun Microsystems анх хөгжүүлсэн. Одоо энэ салбарын үндсэн стандарт болжээ; бүх гол UNIX® төрлийн системүүд (Solaris™, HP-UX, AIX®, Линукс, NetBSD, OpenBSD, FreeBSD, гэх мэт) NIS-г дэмждэг.

NIS анх Yellow Pages буюу Шар Хуудас гэсэн нэртэй байсан боловч худалдааны тэмдгийн асуудлаас болж Sun нэрийг нь сольсон. Хуучин нэр (ба yp) нь одоо хир нь хэрэглэгдсээр байдаг.

Энэ нь RPC дээр үндэслэсэн, нэг NIS домэйнд байгаа бүлэг машинууд дундаа адилхан тохиргооны файлтай боломжийг олгодог харилцагч/сервер систем юм. Үүний тусламжтай системийн администратор NIS харилцагч системийг зайлшгүй байх үндсэн тохиргоотойгоор үүсгэх, тохиргооны өгөгдлийг нэг дор нэмэх, хасах, өөрчлөх зэрэг үйлдлүүдийг хийх боломжтой болдог.

Энэ нь Windows NT®-н домэйн системтэй төстэй. Хэдийгээр тэдгээрийн дотоод ажиллагаа нь ердөө ч адилхан биш боловч үндсэн үүргийг нь адилтгаж болох юм.

### 30.4.2. Таны мэдэж байх ёстой Нэр томъёо/Процессууд

NIS сервер эсвэл NIS харилцагч байдлаар ажилладаг NIS-г FreeBSD дээр зохион байгуулахын тулд нилээд хэдэн нэр томъёо, чухал хэрэглэгчийн процессуудтай та тааралдах болно:

Нэр томъёо | Тайлбар
--- | ---
NIS домэйн нэр | NIS мастер сервер болон түүний бүх харилцагчид (түүний зарц серверийг оруулаад) бүгд NIS домэйн нэртэй байна. Windows NT®-н домэйн нэртэй адилаар, NIS домэйн нэр DNS-тэй ямар ч хамаагүй.
rpcbind | RPC-г (Remote Procedure Call буюу Алсын Процедур Дуудах, NIS-н ашигладаг сүлжээний протокол) идэвхтэй байлгахын тулд заавал ажиллаж байх ёстой. Хэрэв rpcbind ажиллахгүй бол, NIS сервер ажиллуулах, NIS харилцагч болох боломжгүй.
ypbind | NIS харилцагчийг NIS сервертэй "холбоно". NIS домэйн нэрийг системээс авч, RPC ашиглан сервертэй холбоно. ypbind нь NIS орчны харилцагч-серверийн харилцааны цөм нь болж өгдөг; Хэрэв харилцагчийн машин дээр ypbind үхвэл, NIS сервер рүү хандах боломжгүй болно.
ypserv | Зөвхөн NIS сервер дээр ажиллаж байх ёстой; энэ бол NIS сервер процесс өөрөө юм. Хэрэв ypserv(8) үхвэл, сервер NIS хүсэлтэд хариу өгөх боломжгүй болно (магадгүй, түүний үүргийг үргэлжлүүлэх зарц сервер байгаа байх). Зарим NIS-н хувьд (FreeBSD-гийх биш), анх холбогдож байсан сервер байхгүй болбол өөр сервертэй холбоо тогтоохыг оролддоггүй хувилбарууд байдаг. Ихэнхдээ, ийм үед ганц тус болох зүйл бол сервер процессийг дахин эхлүүлэх (эсвэл серверийг бүхлээр нь), эсвэл харилцагч талын ypbind процессийг дахин эхлүүлэх юм.
rpc.yppasswdd | Зөвхөн NIS эзэн сервер дээр ажиллаж байх ёстой өөр нэг процесс; Энэ дэмон NIS харилцагч нарыг өөрсдийн нэвтрэх үгийг солих боломжийг олгоно. Хэрэв энэ дэмон ажиллахгүй бол, хэрэглэгчид NIS эзэн сервер рүү нэвтэрч орон тэнд нэвтрэх үгээ солих хэрэгтэй болно.

### 30.4.3. Хэрхэн ажилладаг вэ?

NIS орчинд гурван төрлийн хост байна: эзэн сервер, зарц сервер, ба харилцагч. Серверүүд нь хостуудын тохиргооны мэдээллийг хадгалсан агуулахын үүргийг гүйцэтгэнэ. Эзэн сервер энэ мэдээллийн бүрэн эрхтэй хуулбарыг хадгалж байдаг бол, зарц сервер нь энэ мэдээллийн хуулбарыг нөөцөнд хадгалж байдаг. Серверүүд харилцагчдыг эдгээр мэдээллээр хангана.

Олон файлд байгаа мэдээллийг энэ маягаар хуваалцаж хэрэглэнэ. master.passwd, group, ба hosts гэсэн файлуудыг ихэвчлэн NIS тусламжтай хуваалцана. Эдгээр файлд байдаг мэдээлэл харилцагч талын нэг процессод хэрэгтэй боллоо гэхэд түүнийг өөрийн дотоодоос хайхын оронд түүнд оноогдсон NIS серверээс асуулга хийнэ.

#### 30.4.3.1. Машины төрөл

- NIS эзэн сервер. Энэ сервер, Windows NT®-н анхдагч домэйн сервер хянагчийн нэг адил, NIS харилцагчдын хэрэгцээний бүх файлуудыг агуулсан байна. passwd, group ба NIS харилцагчийн хэрэглэх бусад олон файлууд эзэн сервер дээр байна.

  | Нэг машин нэгээс олон NIS домэйны хувьд NIS эзэн сервер байж болно. Гэхдээ, энд бид бага хэмжээний NIS орчны талаар ярилцах тул энэ талаар энд үзэхгүй.

- NIS зарц сервер. Windows NT®-н нөөц домэйн хянагчтай адилаар, NIS зарц сервер нь NIS эзэн серверийн өгөгдлийн файлын хуулбарыг хадгална. NIS зарц серверүүд нь нөөцөнд байдаг. Тэдгээр нь мөн эзэн серверийн ачааллыг хуваалцаж байдаг: NIS Харилцагчид нь хамгийн түрүүнд хариу өгсөн серверт холбогдох ба үүний тоонд зарц серверүүд ч бас орно.

- NIS харилцагч. NIS харилцагч нь ихэнх Windows NT® ажлын машины адилаар, NIS серверт шалгуулж (эсвэл Windows NT® ажлын машины хувьд Windows NT® домэйн хянагчид) нэвтэрнэ.

### 30.4.4. NIS/YP-г хэрэглэх нь

Энэ хэсэгт жишээ NIS орчныг үүсгэх болно.

#### 30.4.4.1. Төлөвлөх

Та өөрийгөө нэгэн их сургуулийн жижигхэн лабораторын администратор гэж бод. Энэ лаб 15 FreeBSD машинаас бүрдэх ба одоогоор төвлөрсөн удирдлага байхгүй; машин бүр өөрийн /etc/passwd ба /etc/master.passwd файлуудтай. Эдгээр файлуудыг адилхан байлгахын тулд гараараа зөөж тавьдаг; одоогийн байдлаар лабораторид шинэ хэрэглэгч нэмэхийн тулд, бүх 15 машин дээр нэг бүрчлэн `adduser` тушаалыг оруулах хэрэгтэй байгаа. Мэдээж үүнийг өөрчлөх хэрэгтэй, иймээс та лабораторидоо NIS хэрэглэхээр боллоо. Машинуудаасаа хоёрыг нь сервер болгохоор сонгож авлаа.

Тиймээс, лабораторын тохиргоо дараах байдалтай байна:

Машины нэр | IP хаяг | Машины үүрэг
--- | --- | ---
`ellington` | `10.0.0.2` | NIS эзэн
`coltrane` | `10.0.0.3` | NIS зарц
`basie` | `10.0.0.4` | Факультетийн ажлын машин
`bird` | `10.0.0.5` | Харилцагч машин
`cli[1-11]` | `10.0.0.[6-17]` | Бусад харилцагч машинууд

Хэрэв та NIS зураглалыг анх удаа хийж байгаа бол, хаанаас эхлэхээ эхлээд сайн бодох хэрэгтэй. Сүлжээ чинь ямар ч хэмжээтэй байж болно, гол нь хэд хэдэн сонголт хийх хэрэгтэй.

##### NIS Домэйн Нэрийг сонгох нь

Өөрийн тань байнга хэрэглэдэг "домэйн нэр" байж болохгүй. Залруулж хэлбэл "NIS домэйн нэр" байх ёстой. Харилцагч мэдээлэл олж авахын тулд хүсэлтээ цацах үед NIS домэйн нэрийг хэрэглэнэ. Үүгээр нэг сүлжээнд байгаа олон серверүүд хэн нь хэний асуултанд хариулах ёстойгоо мэдэж авна. NIS домэйн нэрийг хоорондоо ямар нэг байдлаар хамаатай бүлэг хостын нэр гэж ойлгож болно.

Зарим байгууллагууд өөрийн Интернэтийн домэйн нэрийг NIS домэйн нэрээр хэрэглэх нь байдаг. Энэ нь сүлжээний ямар нэг асуудлыг задлан шинжлэх явцад түвэг удах тул энэ аргыг зөвлөдөггүй. NIS домэйн нэр нь сүлжээний орчинд цор ганц байх ёстой бөгөөд төлөөлж байгаа бүлэг машинаа онцолсон нэр байвал дөхөм байдаг. Жишээлбэл, Acme Inc. компаний Урлагийн хэлтэс "acme-art" гэсэн NIS домэйнтой байж болох юм. Бид өөрсдийн жишээндээ `test-domain` гэсэн домэйн нэрийг авлаа.

Гэвч, зарим үйлдлийн системүүд (цохон дурдвал SunOS™) өөрийн NIS домэйн нэрийг Интернэт домэйн нэрээр хэрэглэдэг. Хэрэв таны сүлжээний нэг болон түүнээс дээш тооны машин ийм асуудалтай бол, та Интернэт домэйн нэрээ NIS домэйндоо хэрэглэх ёстой.

##### Серверт тавигдах шаардлагууд

NIS серверт зориулсан машин сонгон авахдаа анхаарах хэд хэдэн зүйлс бий. NIS-тэй холбоотой нэг учир дутагдалтай зүйл бол харилцагчдын серверээс хамаарах хамаарал юм. Хэрэв харилцагч өөрийн NIS домэйныг асуухаар сервертэй холбогдож чадахгүй бол, тэр машин ашиглагдах боломжгүй болдог. Хэрэглэгч болон бүлгийн мэдээлэл дутуугаас ихэнх системүүд түр хугацаанд зогсдог. Тиймээс, дахин дахин асааж унтраалгаад байхааргүй, эсвэл туршилтад хэрэглэгдэхээр машиныг сонгох хэрэгтэй. NIS сервер нь тусдаа, зөвхөн NIS серверт зориулагдсан машин байх ёстой. Хэрэв ачаалал багатай сүлжээнд ажиллаж байгаа бол, NIS серверийг өөр үйлчилгээ ажиллаж байгаа машин дээр тавьж болох талтай. Хамгийн гол нь NIS сервер чинь ажиллахгүй болбол, бүх NIS харилцагчид чинь мөн ажиллахгүй болохыг санаарай.

#### 30.4.4.2. NIS Серверүүд

Бүх NIS мэдээлэл он цагийн дарааллаараа NIS эзэн сервер дээр хадгалагдаж байдаг. Энэ мэдээллийг хадгалж байгаа өгөгдлийн санг NIS буулгалт гэж нэрлэнэ. FreeBSD-д, эдгээр буулгалтууд /var/yp/[domainname] файл дотор байрлана. [domainname] нь NIS домэйн нэр болно. Нэг NIS сервер хэд хэдэн домэйныг зэрэг агуулж чадах тул домэйн тус бүрт зориулсан хэд хэдэн ийм сан байж болно. Домэйн бүр өөрийн гэсэн буулгалтуудтай байна.

NIS эзэн болон зарц серверүүд бүх NIS хүсэлтийг `ypserv` дэмоны тусламжтай удирдаж явуулна. `ypserv` нь NIS харилцагч нараас ирж буй хүсэлтийг хүлээн авч, домэйныг хөрвүүлэн, уг домэйн нэрд харгалзах өгөгдлийн файлын замыг хайж олоод, өгөгдлийг буцаан харилцагчид дамжуулах үүрэгтэй.

##### NIS Эзэн Серверийг зохион байгуулах нь

Эзэн NIS серверийг зохион байгуулах нь харьцангуй ойлгомжтой. FreeBSD нь бэлэн NIS суучихсан ирдэг. Зөвхөн /etc/rc.conf файл дотор дараах мөрүүдийг нэмэхэд л хангалттай, үлдсэнийг нь FreeBSD таны өмнөөс хийгээд өгөх болно.

    nisdomainname="test-domain"

1. Энэ мөр сүлжээ асахад (жишээ нь, систем дахин ачаалсны дараа) NIS домэйн нэрийг `test-domain` болгоно.

       nis_server_enable="YES"

2. Энэ мөр нь сүлжээ асахад NIS сервер процессуудыг асаахыг хэлж өгнө.

       nis_yppasswdd_enable="YES"

3. Энэ мөр нь `rpc.yppasswdd` дэмонг идэвхжүүлнэ. Дээр хэлсэнчлэн, энэ дэмон нь харилцагч машин дээрээс хэрэглэгч өөрийн NIS нэвтрэх үгийг солих боломжтой болгодог.

| Таны NIS тохиргооноос хамааран, нэмэлт мөрүүдийг оруулах хэрэгтэй болж магадгүй. NIS сервер мөртлөө давхар NIS харилцагч серверийн тухай хэсгээс, доор, дэлгэрэнгүй мэдээллийг авна уу.

Дээрхийг тохируулсны дараа супер хэрэглэгчийн эрхээр `/etc/netstart` тушаалыг ажиллуулна. Энэ нь таны /etc/rc.conf файл дотор тодорхойлж өгсөн утгуудыг ашиглан бүх зүйлсийг таны өмнөөс хийх болно. Хамгийн сүүлд нь NIS буулгалтуудыг эхлүүлэхээс өмнө ypserv демоныг гараар ажиллуулах хэрэгтэй.

    # service ypserv start

##### NIS Буулгалтуудыг эхлүүлэх нь

NIS буулгалтууд нь өгөгдлийн сангийн файлууд бөгөөд /var/yp сан дотор хадгалагдана. Тэдгээрийг NIS эзэн серверийн /etc сан дотор байгаа /etc/master.passwd файлаас бусад тохиргооны файлуудаас үүсгэдэг. Энэ нь их учиртай. Мэдээж та өөрийн `root` болон удирдах эрхтэй дансуудынхаа нэвтрэх үгийг NIS домэйн дахь бүх сервер дээр тарааж тавих хүсэлгүй байгаа биз дээ. Тиймээс, NIS буулгалтуудыг эхлүүлэхийн өмнө, дараах зүйлсийг хийх хэрэгтэй:

    # cp /etc/master.passwd /var/yp/master.passwd
    # cd /var/yp
    # vi master.passwd

Системийн дансуудад хамаарах мөрүүдийг (`bin`, `tty`, `kmem`, `games`, гэх мэт), мөн NIS харилцагч дээр тарааж тавих хүсэлгүй байгаа дансуудад хамаарах мөрүүдийг (жишээлбэл `root` ба бусад UID 0 (супер хэрэглэгчийн) дансууд) бүгдийг устгах хэрэгтэй.

| /var/yp/master.passwd файл бүлгийн болон нийтийн хувьд унших эрхгүй (600 төлөв) байгааг нягтална уу! Шаардлагатай бол `chmod` тушаалыг хэрэглээрэй.

Дээр дурдсаныг гүйцэтгэж дууссаны дараа, сая NIS буулгалтуудыг эхлүүлнэ! FreeBSD нь танд үүнийг хийж өгөх `ypinit` нэртэй скриптийг (холбогдох заавар хуудаснаас дэлгэрэнгүй мэдээллийг авна уу) агуулж байдаг. Энэ скрипт ихэнх UNIX® үйлдлийн системд байдаг боловч, заримд нь байхгүй байх тохиолдол бий. Digital UNIX/Compaq Tru64 UNIX дээр энэ скрипт `ypsetup` гэсэн нэртэй байдаг. Бид NIS эзэн серверийн хувьд буулгалтуудыг үүсгэж байгаа тул `ypinit` тушаалыг `-m` тохируулгын хамт өгнө. Дээрх алхмуудыг бүгдийг хийсний дараа, NIS буулгалтуудыг үүсгэхдээ дараах тушаалыг өгнө:

    ellington# ypinit -m test-domain
    Server Type: MASTER Domain: test-domain
    Creating an YP server will require that you answer a few questions.
    Questions will all be asked at the beginning of the procedure.
    Do you want this procedure to quit on non-fatal errors? [y/n: n] n
    Ok, please remember to go back and redo manually whatever fails.
    If you don't, something might not work.
    At this point, we have to construct a list of this domains YP servers.
    rod.darktech.org is already known as master server.
    Please continue to add any slave servers, one per line. When you are
    done with the list, type a <control D>.
    master server   :  ellington
    next host to add:  coltrane
    next host to add:  ^D
    The current list of NIS servers looks like this:
    ellington
    coltrane
    Is this correct?  [y/n: y] y

    [..output from map generation..]

    NIS Map update completed.
    ellington has been setup as an YP master server without any errors.

`ypinit` нь /var/yp/Makefile.dist-с /var/yp/Makefile-г үүсгэсэн байх ёстой. Үүсэхдээ, энэ файл таныг ганц NIS сервертэй орчинд зөвхөн FreeBSD машинуудтай ажиллаж байна гэж үзнэ. `test-domain` нь зарц сервертэй тул, та /var/yp/Makefile файлыг засах хэрэгтэй:

    ellington# vi /var/yp/Makefile

Доорх мөрийг далдлах хэрэгтэй

    NOPUSH = "True"

(хэрэв далдлагдаагүй бол).

##### NIS Зарц Серверийг зохион байгуулах нь

NIS зарц серверийг зохион байгуулах нь эзэн серверийг зохион байгуулахаас ч хялбар байдаг. Зарц сервер рүү нэвтэрч ороод түрүүн хийсэн шигээ /etc/rc.conf файлыг засах хэрэгтэй. Ганц ялгаа нь `ypinit` тушаалыг өгөхдөө `-s` тохируулгыг өгнө. `-s` тохируулга нь NIS эзэн серверийн нэрийг хамт оруулахыг шаардах тул бидний тушаалын мөр дараах байдалтай байна:

    coltrane# ypinit -s ellington test-domain

    Server Type: SLAVE Domain: test-domain Master: ellington

    Creating an YP server will require that you answer a few questions.
    Questions will all be asked at the beginning of the procedure.

    Do you want this procedure to quit on non-fatal errors? [y/n: n]  n

    Ok, please remember to go back and redo manually whatever fails.
    If you don't, something might not work.
    There will be no further questions. The remainder of the procedure
    should take a few minutes, to copy the databases from ellington.
    Transferring netgroup...
    ypxfr: Exiting: Map successfully transferred
    Transferring netgroup.byuser...
    ypxfr: Exiting: Map successfully transferred
    Transferring netgroup.byhost...
    ypxfr: Exiting: Map successfully transferred
    Transferring master.passwd.byuid...
    ypxfr: Exiting: Map successfully transferred
    Transferring passwd.byuid...
    ypxfr: Exiting: Map successfully transferred
    Transferring passwd.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring group.bygid...
    ypxfr: Exiting: Map successfully transferred
    Transferring group.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring services.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring rpc.bynumber...
    ypxfr: Exiting: Map successfully transferred
    Transferring rpc.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring protocols.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring master.passwd.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring networks.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring networks.byaddr...
    ypxfr: Exiting: Map successfully transferred
    Transferring netid.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring hosts.byaddr...
    ypxfr: Exiting: Map successfully transferred
    Transferring protocols.bynumber...
    ypxfr: Exiting: Map successfully transferred
    Transferring ypservers...
    ypxfr: Exiting: Map successfully transferred
    Transferring hosts.byname...
    ypxfr: Exiting: Map successfully transferred

    coltrane has been setup as an YP slave server without any errors.
    Don't forget to update map ypservers on ellington.

Одоо /var/yp/test-domain нэртэй сан үүссэн байх ёстой. NIS эзэн серверийн буулгалтуудын хуулбарууд энэ сан дотор байх ёстой. Эдгээр файлууд шинэчлэгдэж байгаа эсэхийг нягтлаж байх хэрэгтэй. Таны зарц серверийн /etc/crontab доторх дараах мөрүүд үүнийг хийх болно:

    20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
    21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

Энэ хоёр мөр нь зарц сервер өөрийн буулгалтуудыг эзэн сервертэй ижилхэн байлгахыг шаарддаг. Эзэн сервер буулгалтын өөрчлөлтийг өөрийн зарц нарт автоматаар оруулж өгөхийг оролддог болохоор эдгээр мөрүүдийг заавал хэрэглэх шаардлагагүй юм. Гэхдээ зарц серверээс хамааралтай бусад клиентүүд дээрх зөв нууц үгийн мэдээллийн чухлаас хамаараад нууц үгийн буулгалтын шинэчлэлтийг давтамжтайгаар хийхийг зөвлөдөг. Буулгалтын шинэчлэлт үргэлж гүйцэд биш байж болох ачаалал их сүлжээний хувьд энэ нь илүүтэй чухал юм.

Одоо, зарц сервер талд мөн `/etc/netstart` тушаалыг өгч NIS серверийг ажиллуулна.

#### 30.4.4.3. NIS Харилцагчид

NIS харилцагч нь `ypbind` дэмоны тусламжтай тодорхой нэг NIS сервертэй холбоо тогтооно. `ypbind` системийн анхдагч домэйныг шалгах ба (`domainname` тушаалаар өгөгдсөн), дотоод сүлжээнд RPC хүсэлтийг цацаж эхлэнэ. Эдгээр хүсэлтүүд нь `ypbind`-н холбоо тогтоох гэж байгаа домэйн нэрийг зааж өгнө. Хэрэв тухайн домэйнд үйлчлэхээр тохируулагдсан сервер дээрх хүсэлтийг хүлээн авбал, `ypbind`-д хариу өгөх ба хариуг хүлээж авсан тал серверийн хаягийг тэмдэглэж авна. Хэрэв хэд хэдэн сервер хариу өгсөн бол (нэг эзэн ба хэд хэдэн зарц), `ypbind` хамгийн түрүүнд хариу өгсөн серверийг сонгон авна. Түүнээс хойш, харилцагч өөрийн бүх NIS хүсэлтүүдээ тэр сервер рүү явуулна. `ypbind` нь хааяа сервер амьд байгаа эсэхийг нягтлахын тулд "ping" хийж үзнэ. Хэрэв хангалттай хугацааны дотор хариу хүлээж аваагүй бол, `ypbind` энэ домэйнтой холбоо тасарлаа гэж үзээд өөр сервер олохын тулд хүсэлтээ цацаж эхэлнэ.

##### NIS Харилцагчийг зохион байгуулах

FreeBSD машин дээр NIS харилцагчийг зохион байгуулах нь нилээд хялбар байдаг.

1. /etc/rc.conf файлыг нээгээд, NIS домэйн нэрийг зааж өгөх ба сүлжээ асах үед `ypbind`-г ажиллуулдаг болгохын тулд дараах мөрүүдийг нэмж бичнэ:

       nisdomainname="test-domain"
       nis_client_enable="YES"

2. NIS серверээс хэрэгтэй нэвтрэх үгүүдийг импортолж авахын тулд /etc/master.passwd файл дотор байгаа бүх хэрэглэгчийн дансыг устгаад, файлын төгсгөлд дараах мөрийг нэмэхийн тулд `vipw` тушаалыг ашиглана:

       +:::::::::

   | Энэ мөр нь NIS серверийн нэвтрэх үгийн буулгалтад байгаа хүчинтэй хэрэглэгчид данс олгоно. Энэ мөрийг өөрчлөх замаар NIS харилцагчийг хэд хэдэн янзаар тохируулж болно. Дэлгэрэнгүй мэдээллийг доорх netgroups section хэсгээс үзнэ үү. Цааш гүнзгийрүүлэн судлах хүсэлтэй бол `NFS ба NIS-г удирдах нь` тухай O’Reilly-н номыг үзнэ үү.

   | Дор хаяж нэг дотоод эрхийг (өөрөөр хэлбэл NIS-с импортолж аваагүй) /etc/master.passwd файл дотор авч үлдэх хэрэгтэй. Энэ данс `wheel` бүлгийн гишүүн байх ёстой. Хэрэв NIS дээр ямар нэг асуудал гарлаа гэхэд энэ эрхээр алсаас нэвтрэн орж, `root` болоод асуудлыг шийдвэрлэх болно.

3. NIS серверээс бүх бүлгүүдийг импортолж авахын тулд дараах мөрийг /etc/group файлд нэмнэ:

       +:*::

NIS клиентийг нэн даруй эхлүүлэхийн тулд дараах тушаалыг супер хэрэглэгчийн эрхээр ажиллуулах хэрэгтэй:

    # /etc/netstart
    # service ypbind start

Үүний дараа, `ypcat passwd` тушаалыг өгч NIS серверийн passwd буулгалтыг харж чадаж байх ёстой.

### 30.4.5. NIS-н Аюулгүй байдал

Ер нь ямар ч алсын хэрэглэгчийн хувьд өөрийн чинь домэйн нэрийг мэдэж байвал RPC хүсэлтийг ypserv(8)-д явуулж NIS буулгалтыг харах боломжтой. Ийм төрлийн зөвшөөрөгдөөгүй үйлдлээс сэргийлэхийн тулд ypserv(8) нь зөвхөн зааж өгсөн хостуудаас ирсэн хандалтыг зөвшөөрдөг "securenets" гэсэн функцыг агуулж байдаг. Систем анх ачаалахад, ypserv(8) нь securenets-н мэдээллийг /var/yp/securenets гэсэн файлаас ачаална.

| Энэ замыг `-p` тохируулгаар зааж өгөх ба янз бүр байж болно. Энэ файлд сүлжээг сүлжээний багийн хамт зайгаар тусгаарлан оруулж өгсөн байна. "#" тэмдгээр эхэлсэн мөрүүд нь тайлбар болно. Жишээ securenets файл дараах байдалтай байна:

    # allow connections from local host -- mandatory
    127.0.0.1     255.255.255.255
    # allow connections from any host
    # on the 192.168.128.0 network
    192.168.128.0 255.255.255.0
    # allow connections from any host
    # between 10.0.0.0 to 10.0.15.255
    # this includes the machines in the testlab
    10.0.0.0      255.255.240.0

Хэрэв ypserv(8)-н хүсэлт хүлээж авсан хаяг эдгээр дүрмүүдийн аль нэгэнд тохирч байвал хүсэлтийг ердийн байдлаар боловсруулна. Хэрэв энэ хаяг ямар ч дүрмэнд тохирохгүй байвал, хүсэлтийг үл анхаарах бөгөөд анхааруулах бичлэгийг бүртгэлд нэмнэ. Хэрэв /var/yp/securenets гэсэн файл байхгүй бол, `ypserv` нь гаднаас ирсэн бүх хүсэлтийг хүлээн авна.

`ypserv` програм нь Wietse Venema-н TCP Wrapper багцыг дэмждэг. Энэ нь администраторуудын хувьд /var/yp/securenets-ны оронд TCP Wrapper-н тохиргооны файлыг хандалтыг хянахад хэрэглэх боломжтой болгодог.

| Хэдийгээр эдгээр хандалтыг хянах механизмууд нь аюулгүй байдлыг адил түвшинд хангах боловч, хоёул "IP залилах" халдлагад өртөмтгий байдаг. NIS-тэй холбоотой бүх урсгалыг галт хана дээрээ хааж өгөх хэрэгтэй. /var/yp/securenets хэрэглэж байгаа серверүүд хуучин TCP/IP дээр ажиллаж байгаа зүй ёсны NIS харилцагчид үйлчилж чадахгүй байж магадгүй. Учир нь, тэдгээр нь өргөн цацалт хийхдээ хост битүүдийг бүгдийг тэглэдэг ба өргөн цацалтын хаягийг тооцоолохдоо дэд сүлжээний багийг таньж чаддаггүй болно. Хэдийгээр эдгээр асуудлуудыг харилцагчийн тохиргоог өөрчилснөөр шийдэж болох боловч, бусад асуудлууд нь харилцагчийн системийг цааш ашиглах боломжгүй эсвэл /var/yp/securenets-г болиулах шаардлагатай болдог. Ийм хуучин TCP/IP дээр ажилладаг сервер дээр /var/yp/securenets-г хэрэглэх нь үнэхээр хэрэггүй бөгөөд сүлжээний ихэнх хэсэгт NIS-г ашиглах боломжгүй байдаг. TCP Wrapper багцыг ашиглах нь NIS серверийн хоцролтыг ихэсгэдэг. Энэ нэмэлт саатал нь харилцагчийн програм дээр ялангуяа ачаалал ихтэй сүлжээнд, эсвэл удаан NIS сервертэй бол хүлээх хугацаа дуусахад хүргэх талтай. Хэрэв таны харилцагч систем чинь дээрх шинж тэмдгүүдийн аль нэгийг агуулж байгаа бол та энэ харилцагч системээ NIS зарц сервер болгож өөрчлөн хүчээр өөрөөсөө өөртөө холбогдохоор тохируулах хэрэгтэй.

### 30.4.6. Зарим хэрэглэгчдийн нэвтрэхийг хаах

Манай лабораторын жишээн дээр, `basie` нэртэй нэг машин байгаа. Энэ машиныг зөвхөн багш нар хэрэглэх ёстой. Бид энэ машиныг NIS домэйн дотроос гаргахыг хүсэхгүй байгаа, дээр нь эзэн NIS сервер дээр байгаа passwd файл нь багш нар болон оюутнуудын дансыг хоёуланг агуулж байгаа. Бид одоо яах ёстой вэ?

NIS өгөгдлийн сан дотор бүртгэл нь байгаа ч, зарим хэрэглэгчдийг тухайн машин руу нэвтрэхийг хаах нэг арга байна. Үүний тулд `-username` гэсэн мөрийг бусад мөрүүдийн адил форматаар харилцагч машин дээр /etc/master.passwd файлын төгсгөлд нэмэх хэрэгтэй. Энд username гэдэг нь нэвтрэхийг нь хаах гэж байгаа хэрэглэгчийн нэр юм. Хаасан хэрэглэгчийн мөр `+` гэж нээсэн NIS хэрэглэгчийн мөрөөс дээр байх ёстой. Дээрх үйлдлийг хийхдээ `vipw`-г ашиглахыг зөвлөж байна. `vipw` нь /etc/master.passwd файл дотор хийгдсэн өөрчлөлтийг хянах бөгөөд өөрчлөлт хийж дууссаны дараа нэвтрэх үгийн санг автоматаар дахин үүсгэж өгдөг. Жишээ нь, хэрэв бид `bill` гэсэн хэрэглэгчийг `basie` хост дээр нэвтрэхийг хаахыг хүсэж байгаа бол:

    basie# vipw
    [add -bill::::::::: to the end, exit]
    vipw: rebuilding the database...
    vipw: done

    basie# cat /etc/master.passwd

    root:[password]:0:0::0:0:The super-user:/root:/bin/csh
    toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
    daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
    operator:*:2:5::0:0:System &:/:/sbin/nologin
    bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
    tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
    kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
    games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
    news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
    man:*:9:9::0:0:Mister Man Pages:/usr/shared/man:/sbin/nologin
    bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
    uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
    xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
    pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
    nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
    -bill
    +:::::::::

    basie#

### 30.4.7. Netgroups-г Хэрэглэх нь

Цөөхөн тооны машин эсвэл хэрэглэгчийн хувьд тусгай дүрэм хэрэгтэй үед өмнөх хэсэгт дурдсан аргыг хэрэглэх нь илүү тохиромжтой. Харин том сүлжээний хувьд зарим хэрэглэгчийн чухал машин руу нэвтрэх эрхийг хаахаа мартах, эсвэл бүх машиныг нэг бүрчлэн гараараа тохируулж өгөх, өөрөөр хэлбэл NIS-н төвлөрсөн удирдлага гэсэн гол санааг ашиглаж чадахгүй байх тохиолдлууд гарах болно.

NIS-г хөгжүүлэгчид энэ асуудлыг шийдэхийн тулд netgroups буюу сүлжээний бүлгүүд гэсэн шинэ зүйлийг бий болгожээ. Түүний зорилго болон семантикийг UNIX® файл системийн жирийн бүлэгтэй дүйцүүлж болох юм. Гол ялгаанууд нь гэвэл тоон дугаар байхгүй, мөн сүлжээний бүлгийг тодорхойлж өгөхдөө хэрэглэгч болон өөр сүлжээний бүлгийг оруулж болдог.

Сүлжээний бүлэг нь хэдэн зуун хэрэглэгч болон машинтай том, төвөгтэй сүлжээтэй ажиллахад зориулж бүтээгдсэн юм. Нэг талаар, хэрэв та үнэхээр тийм том сүлжээнд ажиллаж байгаа бол энэ нь Сайн Зүйл юм. Харин нөгөө талаас, энэ байдал нь жижигхэн сүлжээнд хялбар жишээн дээр сүлжээний бүлгийг тайлбарлах бараг боломжгүй болгож байна. Энэ хэсгийн үлдсэн хэсэгт хэрэглэж байгаа жишээн дээр энэ асуудлыг харуулахыг оролдлоо.

NIS-г лабораторидоо нэвтрүүлсэн тань танай удирдлагуудын анхаарлыг татсан гэж бодьё. Одоо оюутны хотхон дотор байгаа бусад машиныг NIS домэйнд оруулж өргөтгөх ажлыг хийхийг танд даалгажээ. Дараах хоёр хүснэгтэнд шинээр нэмэх хэрэглэгч болон машины нэрийг товч тайлбарын хамт үзүүллээ.

Хэрэглэгчийн нэр | Тайлбар
--- | ---
`alpha`, `beta` | IT хэлтсийн ердийн ажилчид
`charlie`, `delta` | IT хэлтсийн шинэ дагалдан
`echo`, `foxtrott`, `golf`, …​ | бусад ердийн ажилчид
`able`, `baker`, …​ | дадлагажигчид

Машины нэр | Тайлбар
--- | ---
`war`, `death`, `famine`, `pollution` | Таны хамгийн чухал серверүүд. Зөвхөн IT хэлтсийн ажилчид л нэвтрэх эрхтэй.
`pride`, `greed`, `envy`, `wrath`, `lust`, `sloth` | Харьцангуй чухал биш серверүүд. IT хэлтэст харъяалагддаг бүх хүмүүс нэвтрэх эрхтэй.
`one`, `two`, `three`, `four`, …​ | Ердийн ажлын машинууд. Зөвхөн үндсэн ажилчид нэвтрэх эрхтэй.
`trashcan` | Чухал зүйл байхгүй маш хуучин машин. Дадлагажигчид хүртэл нэвтрэх эрхтэй.

Хэрэв та дээрх хязгаарлалтуудыг тус бүрд нь хэрэглэгчийг хаах замаар хийх гэж оролдвол бүх машин дээр хаах хэрэглэгч тус бүрийн хувьд `-user` мөрийг passwd файл дотор нэмж өгөх ёстой болно. Хэрэв нэг л мөрийг нэмэхээ мартвал асуудалд орно гэсэн үг.

Энэ байдалд сүлжээний бүлгийг ашиглах нь нилээд олон давуу талтай. Хэрэглэгч бүрийг тус тусад нь авч үзнэ; нэг хэрэглэгчийг нэг болон түүнээс дээш тооны сүлжээний бүлэгт оноож, тухайн сүлжээний бүлгийн бүх гишүүдийн хувьд нэвтрэхийг эсвэл зөвшөөрч эсвэл хаана. Хэрэв та шинэ машин нэмбэл, зөвхөн сүлжээний бүлгүүдийн хувьд л нэвтрэх эрхийг зааж өгнө. Хэрэв шинэ хэрэглэгч нэмбэл, тухайн хэрэглэгчийг нэг болон түүнээс дээш тооны сүлжээний бүлэгт нэмэхэд л хангалттай. Эдгээр өөрчлөлтүүд нь нэг нэгнээсээ хамааралгүй: "хэрэглэгч ба машины бүх хувилбарт нэмэх…​" шаардлагагүй болно. Хэрэв та NIS-г анхнаас нь бодлоготой хийх юм бол, машинууд руу нэвтрэх эрхийг хянахдаа зөвхөн ганцхан тохиргооны файлыг өөрчлөхөд хангалттай.

Хамгийн эхний алхам бол NIS сүлжээний бүлгийн буулгалтыг эхлүүлэх юм. FreeBSD-н ypinit(8) нь энэ буулгалтыг анхдагч байдлаар үүсгэдэггүй, гэвч хэрэв нэгэнт үүсгэчихвэл түүний NIS-тэй ажиллах хэсэг нь энэ буулгалт дээр ажиллах чадвартай. Хоосон буулгалт үүсгэхийн тулд:

    ellington# vi /var/yp/netgroup

гэж бичээд дараах зүйлсийг нэмж бичнэ. Манай жишээний хувьд, бидэнд дор хаяж дөрвөн сүлжээний бүлэг хэрэгтэй: IT ажилчид, IT дагалдангууд, ердийн ажилчид болон дадлагажигчид.

    IT_EMP  (,alpha,test-domain)    (,beta,test-domain)
    IT_APP  (,charlie,test-domain)  (,delta,test-domain)
    USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
            (,golf,test-domain)
    INTERNS (,able,test-domain)     (,baker,test-domain)

`IT_EMP`, `IT_APP` гэх мэт нь сүлжээний бүлгийн нэр. Хаалтан дотор байгаа бүлэг нь хэрэглэгч нэмж байгаа нь. Бүлэг доторх гурван талбар нь:

1. Дараах зүйлүүд хүчинтэй байх хостын нэр. Хэрэв хостын нэр зааж өгөхгүй бол, бүх хостын хувьд хүчинтэй гэсэн үг. Хэрэв хостын нэр зааж өгвөл, та үл ойлгогдох, толгой эргүүлсэн хачин зүйлстэй тулгарах болно.

2. Энэ сүлжээний бүлэгт хамаарах дансны нэр.

3. Тухайн дансны NIS домэйн. Хэрэв та нэгээс олон NIS домэйнд харъяалагддаг азгүй залуусын нэг бол, өөрийн сүлжээний бүлэгт өөр NIS домэйноос данс импортолж болно.

Эдгээр талбаруудын алинд ч орлуулагддаг тэмдэгт ашиглаж болно. Дэлгэрэнгүй мэдээллийг netgroup(5) заавар хуудаснаас үзнэ үү.

| Сүлжээний бүлгүүдийн нэр 8-с дээш тэмдэгт байж болохгүй, ялангуяа тухайн NIS домэйнд өөр үйлдлийн системтэй машинууд ажиллаж байгаа бол. Нэрүүд нь том жижиг үсгийн ялгаатай; сүлжээний бүлгийн нэрийг том үсгээр бичих нь хэрэглэгчийн нэр, машины нэр болон сүлжээний бүлгийн нэрийг хооронд нь ялгахад хялбар болгодог. Зарим NIS харилцагчид (FreeBSD-с бусад) олон тооны гишүүдтэй сүлжээний бүлэгтэй ажиллаж чаддаггүй. Жишээлбэл, SunOS™-н зарим хуучин хувилбарууд сүлжээний бүлэг 15-с дээш тооны гишүүн-тэй бол асуудалтай байдаг. Энэ хязгаарыг давахын тулд 15 ба түүнээс доош тооны хэрэглэгчтэй дэд сүлжээний бүлгүүд үүсгээд, дараа нь эдгээр дэд сүлжээний бүлгүүдээс тогтсон жинхэнэ сүлжээний бүлэг үүсгэх замаар үүсгэж болно:
    BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
    BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
    BIGGRP3  (,joe31,domain)  (,joe32,domain)
    BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3
Хэрэв танд нэг сүлжээний бүлэгт 225-с дээш хэрэглэгч хэрэгтэй бол, дээрх үйлдлийг давтах маягаар цааш үргэлжлүүлж болно.

Шинээр үүсгэсэн NIS буулгалтаа идэвхжүүлэх болон тараах нь амархан:

    ellington# cd /var/yp
    ellington# make

Ингэснээр netgroup, netgroup.byhost ба netgroup.byuser гэсэн гурван NIS буулгалт үүсэх болно. Дээрх шинэ буулгалтууд идэвхтэй болсон эсэхийг ypcat(1) ашиглан шалгаарай:

    ellington% ypcat -k netgroup
    ellington% ypcat -k netgroup.byhost
    ellington% ypcat -k netgroup.byuser

Эхний тушаалын үр дүн /var/yp/netgroup файл доторхтой төстэй байх ёстой. Хэрэв та хостоор тусгайлан сүлжээний бүлэг үүсгээгүй бол хоёр дахь тушаалын үр дүнд юу ч гарах ёсгүй. Гурав дахь тушаалын тусламжтай тухайн хэрэглэгчийн сүлжээний бүлгүүдийн жагсаалтыг харахад хэрэглэгдэнэ.

Харилцагчийг тохируулахад нилээд хялбар. `war` нэртэй серверийг тохируулахын тулд, vipw(8)-г ажиллуулаад

    +:::::::::

гэсэн мөрийг

    +@IT_EMP:::::::::

гэсэн мөрөөр сольж бичих хэрэгтэй. Ингэснээр, зөвхөн `IT_EMP` сүлжээний бүлэгт заагдсан хэрэглэгчдийн мэдээлэл `war`-н нэвтрэх үгийн санд импортлогдож, зөвхөн эдгээр хэрэглэгчид л энэ машин руу нэвтрэх эрхтэй боллоо.

Харамсалтай нь, энэ хязгаарлалт нь бүрхүүлийн `~` функцад, мөн хэрэглэгчийн нэр ба тоон дугаарыг хооронд нь хөрвүүлдэг бүх дэд програмуудад хамаатай. Өөрөөр хэлбэл, `cd ~user` тушаал ажиллахгүй, `ls -l` тушаал хэрэглэгчийн нэрийн оронд түүний тоон дугаарыг харуулах ба `find . -user joe -print` тушаал `Тийм хэрэглэгч байхгүй` гэсэн алдааны мэдээлэл өгч амжилтгүй болох болно. Үүнийг засахын тулд, бүх хэрэглэгчдийн бүртгэлийг сервер рүү нэвтрэх эрхгүйгээр импортлох хэрэгтэй болно.

Үүний тулд өөр нэг мөрийг /etc/master.passwd файлд нэмж өгөх хэрэгтэй. Энэ мөр нь:

`+:::::::::/sbin/nologin` гэсэн бичлэгийг агуулж байх ёстой бөгөөд, энэ нь "бүх бүртгэлийг импортол, гэхдээ импортлогдож байгаа бүртгэлүүдийн бүрхүүлийг /sbin/nologin-р соль" гэсэн утгатай. Үүнтэй адилаар `passwd` файлын ямар ч талбарыг /etc/master.passwd файл дахь анхдагч утгыг сольж бичсэнээр өөрчилж болно.

| `:::::::::/sbin/nologin` гэсэн мөр `@IT_EMP:::::::::` гэсэн мөрийн дараа бичигдсэн эсэхийг сайтар нягтлаарай. Үгүй бол, NIS-с импортлогдсон бүх хэрэглэгчдийн бүрхүүл /sbin/nologin болчихно шүү.

Дээрх өөрчлөлтийг хийсний дараа, хэрэв IT хэлтэст шинэ ажилчин орвол, зөвхөн ганцхан NIS буулгалтыг өөрчлөх боллоо. Чухал бус бусад серверийн хувьд ижилхэн арга хэрэглэж, тэдгээрийн өөрийн /etc/master.passwd файл дотор байгаа хуучин `+:::::::::` мөрийг:

    +@IT_EMP:::::::::
    +@IT_APP:::::::::
    +:::::::::/sbin/nologin

гэсэн мөрөөр сольж бичих хэрэгтэй. Ердийн ажлын машины хувьд:

    +@IT_EMP:::::::::
    +@USERS:::::::::
    +:::::::::/sbin/nologin

байх ёстой. Ингээд бүх зүйл асуудалгүй ажиллах болно. Гэтэл хэдэн долоо хоногийн дараа дүрэм, журманд өөрчлөлт орлоо: IT хэлтэс дадлагажигч авч эхэллээ. IT хэлтсийн дадлагажигчид ердийн ажлын машин болон чухал бус серверүүдэд нэвтрэх эрхтэй; IT дагалдангууд гол сервер рүү нэвтрэх эрхтэй болжээ. Одоо `IT_INTERN` гэсэн шинэ сүлжээний бүлэг нэмж, энэ бүлэгт шинэ IT дадлагажигчдийг нэмээд, энэ өөрчлөлтийг бүх машины тохиргоонд оруулж эхлэх хэрэгтэй…​ Бидний хэлж заншсанаар: "Төвлөрсөн төлөвлөгөөн дээрх алдаа, бүх юмыг орвонгоор нь эргүүлнэ".

Энэ мэт тохиолдолуудад NIS-н өөр сүлжээний бүлгээс шинэ сүлжээний бүлэг үүсгэх боломж нь тус болно. Нэг боломж нь үүрэг дээр үндэслэсэн сүлжээний бүлэг юм. Жишээ нь, чухал серверүүд рүү нэвтрэх эрхийг хянахын тулд `BIGSRV` гэсэн нэртэй сүлжээний бүлэг үүсгэж болох ба, чухал бус серверүүдийн хувьд өөр `SMALLSRV` гэсэн бүрэг үүсгэж, `USERBOX` гэсэн гурав дахь бүлгийг ердийн ажлын машинуудад зориулж үүсгэж болох юм. Эдгээр сүлжээний бүлэг тус бүр дээрх гурван төрлийн машинд нэвтрэх эрхтэй сүлжээний бүлгүүдийг агуулна. NIS сүлжээний бүлгийн буулгалт дараах байдалтай байна:

    BIGSRV    IT_EMP  IT_APP
    SMALLSRV  IT_EMP  IT_APP  ITINTERN
    USERBOX   IT_EMP  ITINTERN USERS

Нэвтрэх эрхийг хязгаарлах энэ арга нь ижил төрлийн хязгаарлалттай машинуудыг нэг бүлэг болговол илүү үр дүнтэй ажиллана. Харамсалтай нь, заавал тийм байх албагүй. Ихэнх тохиолдолд, машин тус бүрээр нэвтрэх эрхийг хязгаарлах боломжтой байх шаардлага зайлшгүй тулгардаг.

Машин дээр үндэслэсэн сүлжээний бүлэг тодорхойлох нь дээрх мэтийн дүрэм журамд өөрчлөлт ороход хэрэглэж болох хоёр дахь боломж юм. Энэ тохиолдолд, машин бүрийн /etc/master.passwd файл дотор "+"-р эхэлсэн хоёр мөр бичлэг байна. Эхнийх нь энэ машин руу нэвтрэх эрхтэй дансуудаас бүрдсэн сүлжээний бүлгийг нэмж өгнө, хоёр дахь нь бусад дансуудыг /sbin/nologin бүрхүүлтэйгээр нэмнэ. Сүлжээний бүлгийн нэрийг машины нэрийг "БҮХ ҮСГИЙГ ТОМООР" байхаар сонгож авах нь тохиромжтой. Өөрөөр хэлбэл, мөрүүд дараах байдалтай харагдах ёстой:

    +@BOXNAME:::::::::
    +:::::::::/sbin/nologin

Бүх машины хувьд дээрх үйлдлийг хийж дууссаны дараа, өөрийн /etc/master.passwd файлыг дахин өөрчлөх шаардлагагүй болно. Бусад бүх өөрчлөлтүүдийг NIS буулгалтыг өөрчилснөөр шийдэх болно. Дээрх асуудалд тохирох сүлжээний бүлгийн буулгалтыг зарим нэмэлт өөрчлөлтүүдийн хамт дор жишээ болгож үзүүлэв:

    # Define groups of users first
    IT_EMP    (,alpha,test-domain)    (,beta,test-domain)
    IT_APP    (,charlie,test-domain)  (,delta,test-domain)
    DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
    DEPT2     (,golf,test-domain)     (,hotel,test-domain)
    DEPT3     (,india,test-domain)    (,juliet,test-domain)
    ITINTERN  (,kilo,test-domain)     (,lima,test-domain)
    D_INTERNS (,able,test-domain)     (,baker,test-domain)
    #
    # Now, define some groups based on roles
    USERS     DEPT1   DEPT2     DEPT3
    BIGSRV    IT_EMP  IT_APP
    SMALLSRV  IT_EMP  IT_APP    ITINTERN
    USERBOX   IT_EMP  ITINTERN  USERS
    #
    # And a groups for a special tasks
    # Allow echo and golf to access our anti-virus-machine
    SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
    #
    # machine-based netgroups
    # Our main servers
    WAR       BIGSRV
    FAMINE    BIGSRV
    # User india needs access to this server
    POLLUTION  BIGSRV  (,india,test-domain)
    #
    # This one is really important and needs more access restrictions
    DEATH     IT_EMP
    #
    # The anti-virus-machine mentioned above
    ONE       SECURITY
    #
    # Restrict a machine to a single user
    TWO       (,hotel,test-domain)
    # [...more groups to follow]

Хэрэв та хэрэглэгчдийнхээ дансыг удирдахын тулд ямар нэг өгөгдлийн санг ашигладаг бол, дээрх буулгалтын эхний хэсгийг өгөгдлийн сангийнхаа тайлан бэлтгэх багажуудыг ашиглах үүсгэх боломжтой. Энэ замаар, шинэ хэрэглэгчид машинуудад хандах эрхийг автоматаар олж авах болно.

Эцэст нь анхааруулж хэлэх нэг зүйл байна: Машин дээр үндэслэсэн сүлжээний бүлгийг хэрэглэхийг байнга зөвлөхгүй. Хэрэв оюутны лабораторид зориулсан, хэдэн арван эсвэл хэдэн зуун нэг ижил машинтай ажиллаж байгаа бол, NIS буулгалтыг тодорхой хэмжээнд барьж байхын тулд машин дээр үндэслэсэн сүлжээний бүлгийн оронд үүрэг дээр үндэслэсэн сүлжээний бүлгийг хэрэглэх хэрэгтэй.

### 30.4.8. Санаж явах чухал зүйлс

NIS орчинд ороод, өөрөөр хийх ёстой хэд хэдэн зүйлс байна.

- Лабораторид шинэ хэрэглэгч нэмэх бүрдээ зөвхөн эзэн NIS серверт нэмэх ёстой, ба NIS буулгалтыг заавал дахин үүсгэх ёстой. Хэрэв ингэхээ мартвал, шинэ хэрэглэгч эзэн NIS серверээс өөр хаашаа ч нэвтэрч чадахгүй болно. Жишээ нь, бид `jsmith` гэсэн шинэ хэрэглэгчийг лабораторид нэмэх боллоо:

      # pw useradd jsmith
      # cd /var/yp
      # make test-domain

  `pw useradd jsmith`-н оронд `adduser jsmith`-г мөн хэрэглэж болно.

- Администратор эрхтэй дансуудыг NIS буулгалтад оруулах ёсгүй. Администратор эрхээр орох ёсгүй хэрэглэгчдийн машин дээр администратор эрхтэй дансууд болон нэвтрэх үгүүдийг тараах хүсэлгүй байгаа биз дээ.

- NIS эзэн болон зарц серверийн аюулгүй байдлыг хангаж, ажиллахгүй байх хугацааг багасгах хэрэгтэй. Хэрэв хэн нэг нь серверт нууцаар нэвтэрч, эсвэл унтрааж орхивол хүмүүсийг лабораторын машинууд руу нэвтрэх боломжгүй болгож, саад болох болно.

  Энэ нь ямар ч төвлөрсөн удирдах системийн гол сул тал юм. Хэрэв та өөрийн NIS серверийг хамгаалахгүй бол, та маш олон ууртай хэрэглэгчидтэй таарах болно шүү!

### 30.4.9. NIS v1 нийцтэй байдал

FreeBSD-н ypserv нь NIS v1 харилцагчдад үйлчлэх зарим дэмжигчтэй ирдэг. FreeBSD-н NIS нь зөвхөн NIS v2 протоколыг хэрэглэдэг, гэхдээ бусад нь хуучин системүүдтэй нийцтэй ажиллахын тулд v1 протоколыг дэмждэг байхаар бүтээгдсэн байдаг. Эдгээр системтэй хамт ирсэн ypbind дэмонууд хэдийгээр үнэн хэрэг дээрээ хэзээ ч хэрэглэхгүй боловч NIS v1 сервертэй холболт үүсгэхийг оролддог (ба v2 серверээс хариу хүлээж авсан ч өргөн цацалт хийж хайлтаа үргэлжлүүлдэг талтай). Хэдийгээр ердийн харилцагчийн хүсэлтийг дэмждэг боловч, ypserv-н энэ хувилбар v1 буулгалтыг зөөх хүсэлттэй ажиллаж чадахгүй; иймээс, зөвхөн v1 протоколыг дэмждэг хуучин NIS серверүүдтэй холбоотойгоор эзэн эсвэл зарц байдлаар ажиллаж чадахгүй. Аз болоход, ийм серверийг одоо хэрэглэж байгаа газар байхгүй.

### 30.4.10. NIS Сервер мөртлөө NIS Харилцагч

Сервер машин нь мөн NIS харилцагч байдлаар ажилладаг олон сервертэй домэйнд ypserv-г ажиллуулахдаа анхааралтай байх хэрэгтэй. Ийм серверийг өргөн цацалт хийлгэж, өөр нэг сервертэй холбоо тогтоохыг зөвшөөрөхийн оронд өөрөө өөртэй нь хүчээр холбох нь ихэвчлэн дээр байдаг. Хэрэв нэг сервер унтарч, бусад серверүүд түүнээс хамааралтай байх юм бол хачин алдаанууд гарч болзошгүй. Эцэст нь бүх харилцагчдын хүлээх хугацаа дуусаж, бүгд өөр сервертэй холбогдохыг оролдох болно. Хэдийгээр бүх серверүүд холболтуудаа сэргээж буцаад хэвийн байдалдаа орсон ч, саатлаас болж харилцагчид холбогдож чадахгүй хэвээр байх болно.

Хостыг ямар нэг сервертэй холбогдохыг `ypbind` тушаалыг `-S` тугийн хамт ажиллуулж, урдаас зааж өгч болно. Хэрэв NIS серверийг дахин ачаалах тоолонд энэ тушаалыг гараар оруулах хүсэлгүй байгаа бол, дараах мөрүүдийг өөрийн /etc/rc.conf файл дотор нэмээрэй:

    nis_client_enable="YES"	# run client stuff as well
    nis_client_flags="-S NIS domain,server"

Дэлгэрэнгүй мэдээллийг ypbind(8) заавар хуудаснаас үзнэ үү.

### 30.4.11. Нэвтрэх үгийн хэлбэр

NIS-г зохион байгуулах явцад ихэвчлэн тохиолддог асуудлуудын нэг бол нэвтрэх үгийн хэлбэрийн нийцгүй байдал юм. Хэрэв таны NIS сервер DES хувиргалттай нэвтрэх үгийг хэрэглэдэг бол, зөвхөн DES хэрэглэдэг харилцагчид үйлчлэх чадвартай. Жишээлбэл, хэрэв сүлжээнд чинь Solaris™ NIS харилцагчид байгаа бол, та бараг л DES хувиргалттай нэвтрэх үг хэрэглэх шаардлагатай гэсэн үг.

Таны сервер болон харилцагчид ямар хэлбэрийн нэвтрэх үг хэрэглэдгийг шалгахдаа /etc/login.conf файлыг үзээрэй. Хэрэв тухайн хост DES хувиргалттай нэвтрэх үг хэрэглэдэг бол, `default` буюу анхдагч ангилал нь дараах мөрүүдийг агуулсан байх болно:

    default:\
    	:passwd_format=des:\
    	[Further entries elided]

`passwd_format` нь өөр `blf` ба `md5` гэсэн утгуудыг авч болно (Blowfish болон MD5 хувиргалттай нэвтрэх үгийн хувьд).

Хэрэв та /etc/login.conf файлд өөрчлөлт хийсэн бол, нэвтрэх чадварын санг дахин үүсгэх шаардлагатай. Үүний тулд дараах тушаалыг `root` эрхээр өгөх хэрэгтэй:

    # cap_mkdb /etc/login.conf

| /etc/master.passwd файл дотор аль хэдийн үүссэн нэвтрэх үгийн хэлбэр нь хэрэглэгч нэвтрэх чадварын сан дахин үүссэнээс хойш анх удаа нэвтрэх үгээ солих хүртэл өөрчлөгдөхгүй.

Мөн, таны сонгосон хэлбэрээр нэвтрэх үгүүдэд хувиргалт хийгддэг болгохын тулд, /etc/auth.conf файл доторх `crypt_default` утга таны сонгосон хэлбэрийг хамгийн түрүүнд оруулсан байгаа эсэхийг шалгах хэрэгтэй. Жишээ нь, DES хувиргалттай нэвтрэх үгийг хэрэглэх үед:

    crypt_default	=	des blf md5

FreeBSD дээр тулгуурласан NIS сервер болон харилцагч бүр дээр дээрх үйлдлүүдийг хийснээр, нэвтрэх үгийн хэлбэр бүгд таарч байгаа гэдэгт санаа амар байж болно. Хэрэв NIS харилцагч дээр нэвтэрч ороход асуудал гарвал, асуудлыг тодруулах нэг газар байна. Хэрэв та холимог сүлжээний хувьд NIS сервер босгох гэж байгаа бол, ихэнх систем дээр зайлшгүй байх хамгийн бага стандарт тул, бүх системүүд дээрээ DES ашиглах хэрэгтэйг санаарай.

## 30.5. Автомат Сүлжээний Тохиргоо (DHCP)

### 30.5.1. DHCP гэж юу вэ?

DHCP, Dynamic Host Configuration Protocol буюу Динамик Хостын Тохиргооны Протокол нь систем ямар байдлаар сүлжээнд холбогдох, тухайн сүлжээнд харилцаанд орохын тулд шаардагдах мэдээллийг хэрхэн олж авахыг зааж өгдөг. FreeBSD нь OpenBSD 3.7-с авсан OpenBSD-н `dhclient`-г хэрэглэдэг. Энэ бүлэгт гарах `dhclient`-р ISC ба OpenBSD DHCP харилцагчийг хоёуланг нь төлөөлүүлсэн болно. DHCP серверийн хувьд ISC тархацын серверийг авч үзэх болно.

### 30.5.2. Энэ хэсэгт авч үзэх зүйлс

Энэ хэсэгт ISC ба OpenBSD DHCP харилцагчийн харилцагч талыг бүтээж байгаа элементүүд, болон ISC DHCP системийн сервер талыг бүтээж байгаа элементүүдийг хоёуланг нь авч үзэх болно. Харилцагч талын програм, `dhclient`, нь FreeBSD-тэй нэгдмэл байдлаар ирдэг бол, сервер талын хэсэг нь net/isc-dhcp42-server портоос суулгах боломжтой байдлаар ирдэг. dhclient(8), dhcp-options(5), ба dhclient.conf(5) заавар хуудсууд болон доор өгөгдсөн зөвлөмжүүд нь хэрэг болно.

### 30.5.3. Хэрхэн ажилладаг вэ?

Харилцагч машин дээр `dhclient` DHCP харилцагчийг ажиллуулахад, тохиргооны мэдээллийг хүссэн хүсэлтийг цацаж эхэлнэ. Анхдагч байдлаар, эдгээр хүсэлтүүд нь UDP 68-р портоос гарч, серверийн UDP 67 порт руу илгээгдэнэ. Сервер харилцагчид IP хаяг болон сүлжээний баг, чиглүүлэгч, DNS серверийн хаяг зэрэг хэрэгтэй мэдээллийг хариу илгээнэ. Энэ бүх мэдээллийг DHCP "түрээслэх" хэлбэрээр өгөх ба зөвхөн тодорхой хугацааны туршид хүчинтэй байна (DHCP серверийг хариуцагч тохируулж өгсөн байна). Ийм байдлаар, сүлжээнд холбогдохоо больсон харилцагчийн ашиглагдаагүй IP хаягуудыг автоматаар буцааж авах боломжтой болно.

DHCP харилцагч серверээс өргөн мэдээллийг авч чадна. Бүрэн жагсаалтыг dhcp-options(5)-с олж үзэж болно.

### 30.5.4. FreeBSD-тэй нэгдмэл байдал

FreeBSD нь OpenBSD DHCP харилцагч, `dhclient`-г өөртэйгөө бүрэн нэгтгэсэн байдаг. DHCP сервер ажиллаж байгаа сүлжээнд сүлжээний тохиргоог хийх нарийн чимхлүүр ажлаас хөнгөвчлөх үүднээс, DHCP харилцагчийг систем суулгагч болон үндсэн системийн аль алинд хамт оруулж өгсөн байдаг.

sysinstall нь DHCP-г дэмждэг. sysinstall-р сүлжээний интерфэйсийг тохируулахад асуудаг хоёр дахь асуулт бол: "Та энэ интерфэйсийг DHCP-р тохируулахыг хүсэж байна уу?". Зөвшөөрсөн хариулт өгсөн тохиолдолд `dhclient`-г ажиллуулах бөгөөд, хэрэв амжилттай бол сүлжээний тохиргоо автоматаар хийгдэнэ.

Систем ачаалах үед DHCP ашигладаг болгохын тулд, хоёр зүйлийг хийх хэрэгтэй:

- bpf төхөөрөмж цөмтэй хамт эмхэтгэгдсэн байх ёстой. Үүний тулд, `device bpf` мөрийг цөмийн тохиргооны файлд нэмж бичээд цөмийг дахин бүтээх хэрэгтэй. Цөмийг бүтээх талаар дэлгэрэнгүй мэдээллийг FreeBSD цөмийг тохируулах нь хэсгээс авна уу.

  bpf төхөөрөмж нь FreeBSD-н GENERAL цөмийн нэг хэсэг бөгөөд, DHCP-г ажиллуулахын тулд тусгайлан шинээр цөм бүтээх шаардлагагүй.

  | Аюулгүй байдлын талаар сэтгэл зовнидог хүмүүст зөвлөхөд, bpf нь пакет шиншлэгчдийг зөв ажиллах боломжийг олгодог төхөөрөмж болохыг анхааралдаа авна уу (хэдийгээр тэдгээр програм ажиллахын тулд `root` эрх хэрэгтэй боловч). DHCP-г ашиглахын тулд bpfзаавал хэрэгтэй, гэвч хэрэв та аюулгүй байдлыг маш ихээр анхааралдаа авдаг бол, зөвхөн хэзээ нэгэн цагт DHCP-г ашиглахын тулд bpf-г цөмд нэмэх хэрэггүй.

- Анхдагчаар FreeBSD-н DHCP тохиргоо ар талд буюу асинхрон (asynchronously) горимд хийгддэг. DHCP дуустал бусад скриптүүд ажилладаг бөгөөд ингэснээр системийн эхлүүлэлтийг хурдасгадаг.

  Ард ажиллах DHCP нь DHCP сервер хүсэлтүүдэд хурдан хариу өгч DHCP тохиргооны процесс түргэн хийгдэх үед сайн ажилладаг. Гэхдээ DHCP зарим системүүд дээр хийгдэж дуустлаа удаан ажиллаж болно. DHCP дуусахаас өмнө сүлжээний үйлчилгээнүүд ажиллахаар оролдвол амжилтгүй болно. DHCP-г синхрон (synchronous) горимд ашиглах нь DHCP тохиргоог дуустал эхлүүлэлтийг түр зогсоож асуудал гарахаас сэргийлдэг.

  Бусад эхлүүлэлтүүд үргэлжилж байх үед ар талд DHCP сервер рүү холбогдохын тулд (асинхрон горим) /etc/rc.conf файлд “DHCP” гэсэн утгыг ашиглана:

      ifconfig_fxp0="DHCP"

  DHCP дуустал эхлэлийг түр зогсоохын тулд синхрон горимыг “SYNCDHCP” утгатайгаар хэрэглэнэ:

      ifconfig_fxp0="SYNCDHCP"

  | Сүлжээний интерфэйс картууд суулгах нь-д тайлбарласан ёсоор, эдгээр жишээн дээр байгаа `fxp0`-г динамикаар тохируулах гэж байгаа интерфэйсийн нэрээр сольж бичнэ.

  Хэрэв таны `dhclient` өөр газар байгаа бол, эсвэл хэрэв та `dhclient`-г нэмэлт тугуудын хамт ажиллуулах хүсэлтэй бол, дараах мөрүүдийг нэмж бичнэ үү (шаардлагатай бол засаж бичнэ үү):

      dhclient_program="/sbin/dhclient"
      dhclient_flags=""

DHCP сервер dhcpd нь портуудын цуглуулгад байгаа net/isc-dhcp42-server портын нэг хэсэг байдлаар ирдэг. Энэ порт нь ISC DHCP сервер болон түүний баримтуудыг агуулсан байдаг.

### 30.5.5. Файлууд

- /etc/dhclient.conf

  `dhclient` нь /etc/dhclient.conf гэсэн тохиргооны файлыг шаарддаг. Ихэвчлэн энэ файл зөвхөн тайлбаруудаас бүрдэх ба анхдагч утгууд нь харьцангуй өөрчлөх шаардлагагүйгээр өгөгдсөн байдаг. Энэ тохиргооны файлыг dhclient.conf(5) заавар хуудсанд тайлбарласан байгаа.

- /sbin/dhclient

  `dhclient` нь статикаар холбогдсон байх ба /sbin дотор байрлана. dhclient(8) хуудаснаас `dhclient`-н талаар дэлгэрэнгүй мэдээллийг авна уу.

- /sbin/dhclient-script

  `dhclient-script` нь зөвхөн FreeBSD-д байдаг, DHCP харилцагчийг тохируулах зориулалттай тусгай скрипт юм. Энэ скриптийг dhclient-script(8) заавар хуудсанд тайлбарласан байх ба, ажиллуулахын тулд хэрэглэгч ямар нэг засвар хийх шаардлагагүй.

- /var/db/dhclient.leases.interface

  DHCP харилцагч нь түрээсэлж авсан хаягуудаа агуулсан өгөгдлийн санг энэ файлд хадгалах бөгөөд бүртгэл маягаар бичдэг. dhclient.leases(5) хэсэгт илүү дэлгэрэнгүй тайлбар бий.

### 30.5.6. Гүнзгийрүүлэн унших

DHCP протокол нь бүрэн хэмжээгээр RFC 2131-д тодорхойлогдсон байдаг. Нэмэлт эх үүсвэрүүд http://www.dhcp.org/-д мөн бий.

### 30.5.7. DHCP Серверийг Суулгах болон Тохируулах

#### 30.5.7.1. Энэ хэсэгт авч үзэх зүйлс

Энэ хэсэгт ISC (Internet Systems Consortium) DHCP серверийг ашиглан FreeBSD системийг хэрхэн DHCP сервер байдлаар ажиллуулах талаар авч үзэх болно.

Сервер нь FreeBSD-н нэг хэсэг байдлаар ирдэггүй бөгөөд ийм үйлчилгээ үзүүлэхийн тулд net/isc-dhcp42-server портыг суулгах хэрэгтэй болдог. Портуудын цуглуулгын хэрхэн ашиглах талаар Програм суулгах. Багцууд болон портууд хэсгээс дэлгэрэнгүй мэдээллийг авна уу.

#### 30.5.7.2. DHCP Серверийг суулгах нь

FreeBSD системийг DHCP сервер байдлаар тохируулахын тулд, bpf(4) төхөөрөмж цөмд эмхэтгэгдсэн байх ёстой. Үүний тулд, цөмийн тохиргооны файл дотор `bpf төхөөрөмж`ийг нэмээд цөмийг дахин бүтээх хэрэгтэй. Цөмийг бүтээх талаар дэлгэрэнгүй мэдээллийг FreeBSD цөмийг тохируулах нь хэсгээс үзнэ үү.

bpf төхөөрөмж нь FreeBSD-н GENERAL цөмийн нэг хэсэг бөгөөд, DHCP-г ажиллуулахын тулд тусгайлан шинээр цөм бүтээх шаардлагагүй.

| Аюулгүй байдлын талаар сэтгэл зовнидог хүмүүст зөвлөхөд, bpf нь пакет шиншлэгчдийг зөв ажиллах боломжийг олгодог төхөөрөмж болохыг анхааралдаа авна уу (хэдийгээр тэдгээр програм ажиллахын тулд `root` эрх хэрэгтэй боловч). DHCP-г ашиглахын тулд bpfзаавал хэрэгтэй, гэвч хэрэв та аюулгүй байдлыг маш ихээр анхааралдаа авдаг бол, зөвхөн хэзээ нэгэн цагт DHCP-г ашиглахын тулд bpf-г цөмд нэмэх хэрэггүй.

Үүний дараа net/isc-dhcp42-server порттой хамт ирсэн жишээ dhcpd.conf файлыг засах хэрэгтэй. Анхдагч байдлаар, /usr/local/etc/dhcpd.conf.sample гэсэн файл байх ба өөрчлөлт хийхийнхээ өмнө энэ файлыг /usr/local/etc/dhcpd.conf нэртэйгээр хуулж тавих хэрэгтэй.

#### 30.5.7.3. DHCP Серверийг тохируулах

dhcpd.conf нь дэд сүлжээ болон хостуудтай холбоотой өгөгдөл зарлалтаас бүрдэх ба жишээн дээр тайлбарлавал илүү амархан байх болов уу:

    option domain-name "example.com";(1)
    option domain-name-servers 192.168.4.100;(2)
    option subnet-mask 255.255.255.0;(3)

    default-lease-time 3600;(4)
    max-lease-time 86400;(5)
    ddns-update-style none;(6)

    subnet 192.168.4.0 netmask 255.255.255.0 {
      range 192.168.4.129 192.168.4.254;(7)
      option routers 192.168.4.1;(8)
    }

    host mailhost {
      hardware ethernet 02:03:04:05:06:07;(9)
      fixed-address mailhost.example.com;(10)
    }

1 | Энэ тохируулга нь анхдагч хайлтын домэйн байдлаар харилцагчид өгөх домэйныг заана. Энэ талаар дэлгэрэнгүй мэдээллийг resolv.conf(5) хэсгээс үзнэ үү.
2 | Энэ тохируулга нь харилцагчийн хэрэглэх ёстой DNS серверүүдийг таслалаар холбосон жагсаалт байна.
3 | Хэрэглэгчид өгөх сүлжээний багийг заана.
4 | Түрээслэлт (lease) хүчинтэй байх тийм тусгай хугацааг харилцагч хүсэж болох юм. Хэрэв харилцагч хүсээгүй бол сервер энд заасан дуусах хугацаагаар (секундээр) түрээс хийх болно.
5 | Серверийн түрээслүүлэх хамгийн дээд хугацааг заана. Харилцагч үүнээс урт хугацаагаар түрээслэх хүсэлт тавибал хүсэлтийг хүлээж авах боловч зөвхөн `max-lease-time` секундын туршид хүчинтэй байна.
6 | Түрээслэх болон эргүүлж авахад DHCP сервер DNS-г шинэчлэхийг оролдох шаардлагатай эсэхийг зааж өгнө. ISC шийдлийн хувьд, энэ тохируулга заавал байх ёстой.
7 | Харилцагчид оноох IP хаягуудын хүрээг заана. Энэ хүрээнд багтах IP хаягуудыг харилцагчид өгөх болно.
8 | Харилцагчид өгөх анхдагч гарцыг заана.
9 | Хостын MAC хаягийг заана (ингэснээр DHCP сервер тухайн хостыг хүсэлт тавихад таньж чадна).
10 | Хостод тогтмол IP хаяг оноохыг заана. Энд хостын нэрийг хэрэглэж болохыг тэмдэглэх хэрэгтэй. DHCP сервер IP хаяг түрээслүүлэх хариуг өгөхөөс өмнө хост нэрийг тайлах болно.

dhcpd.conf файлыг бичиж дууссаны дараа, /etc/rc.conf файл дотор DHCP серверийг идэвхжүүлэх хэрэгтэй, өөрөөр хэлбэл доорх мөрүүдийг нэмж бичих хэрэгтэй:

    dhcpd_enable="YES"
    dhcpd_ifaces="dc0"

`dc0`-г өөрийн тань DHCP сервер DHCP харилцагчдын хүсэлтийг хүлээж авах ёстой интерфэйсийн нэрээр (эсвэл интерфэйсүүдийг зайгаар тусгаарлан) сольж бичих хэрэгтэй.

Дараа нь, доорх тушаалыг өгөн серверийг ажиллуулах хэрэгтэй:

    # service isc-dhcpd start

Серверийнхээ тохиргооны файлд өөрчлөлт оруулах бүрдээ, `SIGHUP` дохиог dhcpd-д өгөх нь бусад дэмонуудын хувьд тохиргоог дахин дууддаг шиг биш харин тохиргоог дахин ачаалах_гүй_ болохыг анхаарах хэрэгтэй. Процессийг зогсоохын тулд `SIGTERM` дохиог өгөх хэрэгтэй ба дээрх тушаалыг өгөн дахин эхлүүлэх хэрэгтэй.

#### 30.5.7.4. Файлууд

- /usr/local/sbin/dhcpd

  dhcpd нь статикаар холбогдсон байх ба /usr/local/sbin дотор байрлана. Порттой хамт суусан dhcpd(8) заавар хуудаснаас dhcpd-н талаар дэлгэрэнгүй мэдээллийг авна уу.

- /usr/local/etc/dhcpd.conf

  dhcpd нь /usr/local/etc/dhcpd.conf гэсэн тохиргооны файлыг шаарддаг. Энэ файл дотор харилцагчид өгөх бүх мэдээллээс гадна серверийн өөрийн үйл ажиллагаатай холбоотой мэдээлэл байх ёстой. Энэ тохиргооны файлыг портоос суусан dhcpd.conf(5) заавар хуудсанд тайлбарласан байгаа.

- /var/db/dhcpd.leases

  DHCP сервер нь түрээслүүлсэн хаягуудаа агуулсан өгөгдлийн санг энэ файлд хадгалах бөгөөд бүртгэл маягаар бичдэг. Портоос суусан dhcpd.leases(5) заавар хуудсанд илүү дэлгэрэнгүй тайлбар бий.

- /usr/local/sbin/dhcrelay

  dhcrelay-г нэг DHCP сервер харилцагчаас хүлээн авсан хүсэлтийг өөр сүлжээнд байгаа нөгөө DHCP сервер рүү дамжуулдаг, нарийн бүтэцтэй орчинд хэрэглэнэ. Хэрэв энэ функцыг ашиглах шаардлагатай бол, net/isc-dhcp42-relay портыг суулгаарай. Порттой хамт ирэх dhcrelay(8) заавар хуудаснаас дэлгэрэнгүй мэдээллийг авна уу.

## 30.6. Домэйн Нэрийн Систем (DNS)

### 30.6.1. Удиртгал

FreeBSD анхдагч байдлаар DNS протоколын хамгийн өргөн хэрэглэгддэг хэрэгжүүлэлт болох BIND (Berkeley Internet Name Domain)-н аль нэг хувилбарыг агуулсан байдаг. DNS нь нэрүүдийг IP хаягууд руу, мөн эсрэгээр нь буулгахад хэрэглэгддэг протокол юм. Жишээ нь, `www.FreeBSD.org`-г асуусан DNS асуулга явуулахад, хариуд нь FreeBSD Төсөлийн вэб серверийн IP хаяг ирэх бол, `ftp.FreeBSD.org`-н хувьд асуулга явуулахад, хариуд нь харгалзах FTP машины IP хаяг ирэх болно. Яг үүнтэй адилаар эсрэгээр нь хийж болно. Ямар нэг IP-р асуулга явуулахад түүний хост нэрийг олж болно. DNS хайлт хийхийн тулд тухайн системд домэйн нэрийн сервер ажиллаж байх ёстой.

FreeBSD нь одоо BIND9 DNS сервер програмын хамт ирдэг болсон. Бидний суулгац нь файл системийн шинэчилсэн зохион байгуулалт, автомат chroot(8) тохиргоо зэрэг аюулгүй байдлыг дээд зэргээр хангах функцүүдтэй ирдэг.

DNS бол Интернэт дээр тулгуурласан, бүрэн эрхт root буюу эх сервер, Top Level Domain буюу Дээд Түвшний Домэйн (TLD) сервер, болон домэйн тус бүрийн мэдээллийг агуулж байдаг бусад жижиг нэрийн серверүүдээс бүтсэн нарийн төвөгтэй систем юм.

BIND одоо Internet Systems Consortium http://www.isc.org/-н мэдэлд байдаг.

### 30.6.2. Нэр Томъёо

Энэ баримтыг ойлгохын тулд, DNS-тэй холбоотой зарим нэр томъёог ойлгосон байх шаардлагатай.

Нэр | Тайлбар
--- | ---
Forward буюу Ердийн DNS | Хост нэрийг IP хаяг руу буулгана.
Origin буюу Үүсэл | Тухайн бүсийн файлд хамрагдаж байгаа домэйныг заана.
named, BIND | FreeBSD-н BIND нэрийн серверийг нэрлэх түгээмэл нэршил.
Resolver буюу Тайлагч | Машин, бүсийн мэдээллийн талаар нэрийн серверээс асуулга явуулахын тулд ашигладаг системийн процесс.
Reverse буюу Урвуу DNS | IP хаягийг хост нэр рүү буулгана.
Root zone буюу Эх бүс | Интернэт бүсийн шатлалын эхлэл. Файл системийн бүх файлууд эх санд харъяалагддаг шиг, бүх бүсүүд эх бүсэд харъяалагдана.
Zone буюу Бүс | Нэг бүрэн эрхт газраар удирдуулж байгаа домэйн, дэд домэйн, эсвэл DNS-н нэг хэсэг.

Бүсүүдийн жишээ:

- `.` нь баримтад ихэвчлэн эх бүс гэж заагддаг.

- `org.` бол эх бүсийн доорх Top Level Domain буюу Дээд Түвшний Домэйн (TLD).

- `example.org.` бол `org.` TLD-н доорх бүс.

- `1.168.192.in-addr.arpa` бол `192.168.1.*` IP хаягийн хүрээнд багтаж байгаа бүх IP хаягуудыг агуулсан бүс.

Хост нэр зүүн тал руугаа явах тусам илүү тодорхой болж байгааг та бүхэн анзаарсан байх. Жишээлбэл, `example.org.` нь `org.`-с илүү тодорхой, харин `org.` нь эх бүсээс илүү тодорхой байна. Хост нэрийн зохион байгуулалт нь файл системийнхтэй төстэй: /dev директор нь эх директорт харъяалагдана, гэх мэт.

### 30.6.3. Нэрийн Сервер ажиллуулах Шалтгаанууд

Нэрийн Серверүүд ерөнхийдөө хоёр янз байна: authoritative буюу бүрэн эрхт нэрийн сервер, ба caching буюу түр тогтоогч нэрийн сервер.

Бүрэн эрхт нэрийн сервер нь дараах тохиолдлуудад хэрэгтэй:

- DNS мэдээллийг өөртөө агуулж, энэ мэдээллийг нийтэд зарлан, ирсэн асуулгуудад бүрэн эрхтэйгээр хариулах хүсэлтэй үед.

- Бүртгэлтэй домэйны хувьд, жишээлбэл `example.org`, түүний дор орших хост нэрүүдэд IP хаяг оноож өгөх хэрэгтэй үед.

- Бүлэг IP хаягуудад урвуу DNS мэдээлэл хэрэгтэй үед (IP-с хост нэр рүү).

- Нөөц эсвэл хоёрдогч нэрийн сервер, зарц гэж нэрлэнэ, асуулгуудад хариулуулах шаардлагатай үед.

Түр тогтоогч нэрийн сервер дараах тохиолдлуудад хэрэгтэй:

- Дотоод DNS сервер нь асуулгын хариуг түр тогтоосноор гадаад нэрийн серверээс илүү хурдан хариу өгч байгаа үед.

`www.FreeBSD.org`-р асуулга явуулсан үед, тайлагч ихэвчлэн үйлчилгээ авдаг ISP-нхаа нэрийн серверээс асуугаад хариуг олж авна. Дотоод, түр тогтоогч DNS сервер ажиллуулснаар, асуулгыг гадаад интернэтээс зөвхөн ганц удаа явуулах бөгөөд, хариуг тогтоож авна. Нэмэлт асуулгуудад түр тогтоогч нэрийн сервер хариулах ба гадагшаа дахин асуулга явуулах шаардлага байхгүй.

### 30.6.4. Хэрхэн ажилладаг вэ?

FreeBSD-д BIND дэмонг named гэж нэрлэнэ.

Файл | Тайлбар
--- | ---
named(8) | BIND дэмон.
rndc(8) | Нэрийн серверийг хянах хэрэгсэл.
/etc/namedb | BIND-н бүсийн мэдээлэл хадгалагдаж байгаа сан.
/etc/namedb/named.conf | дэмоны тохиргооны файл.

Тухайн бүс сервер дээр хэрхэн тохируулагдсанаас хамаарч энэ бүстэй хамааралтай файлууд /etc/namedb директорын master, slave, эсвэл dynamic гэсэн дэд сангуудад байрлана. Эдгээр файлуудад гадны асуулгад хариу болгон өгөх DNS мэдээллүүд байрлана.

### 30.6.5. BIND-г ажиллуулах нь

BIND нь анхдагч байдлаар суучихсан ирдэг тул тохируулахад хялбар байдаг.

named-н анхдагч тохиргоо нь chroot(8) орчинд ажиллах, тайлагч нэрийн сервер байдлаар хийгдсэн байдаг бөгөөд локал IPv4 loopback хаяг (127.0.0.1) дээр ажиллахаар хязгаарлагдсан байдаг. Энэ тохиргоогоор серверийг ажиллуулахын тулд дараах тушаалыг өгөх хэрэгтэй:

    # service named onestart

named дэмонг систем ачаалах үед ажиллуулдаг болгохын тулд /etc/rc.conf дотор дараах мөрүүдийг нэмэх хэрэгтэй:

    named_enable="YES"

Мэдээж /etc/namedb/named.conf файл дотор өөр олон тохируулгууд байгаа боловч энэ баримтын мэдлээс халих тул энд дурдсангүй. Хэрэв FreeBSD дээрх named-н эхлэл тохируулгуудын талаар сонирхож байгаа бол /etc/defaults/rc.conf дотор байгаа `named_*` тугуудыг нэг ороод үзээрэй. Мөн rc.conf(5) заавар хуудаснаас тусламж авч болно. FreeBSD дээр rc(8) ашиглах нь хэсгийг уншихад илүүдэхгүй.

### 30.6.6. Тохиргооны файлууд

named-н тохиргооны файлууд нь /etc/namedb директор дотор байрлах ба хэрэв хялбар тайлагчаас өөр түвшинд ажиллах хэрэгтэй бол ажиллуулахаасаа өмнө тохиргооны файлд засвар хийх хэрэгтэй. Ихэнх тохиргоог энэ сан дотор гүйцэтгэнэ.

#### 30.6.6.1. /etc/namedb/named.conf

    // $FreeBSD$
    //
    // Refer to the named.conf(5) and named(8) man pages, and the documentation
    // in /usr/shared/doc/bind9 for more details.
    //
    // If you are going to set up an authoritative server, make sure you
    // understand the hairy details of how DNS works.  Even with
    // simple mistakes, you can break connectivity for affected parties,
    // or cause huge amounts of useless Internet traffic.

    options {
    	// All file and path names are relative to the chroot directory,
    	// if any, and should be fully qualified.
    	directory	"/etc/namedb/working";
    	pid-file	"/var/run/named/pid";
    	dump-file	"/var/dump/named_dump.db";
    	statistics-file	"/var/stats/named.stats";

    // If named is being used only as a local resolver, this is a safe default.
    // For named to be accessible to the network, comment this option, specify
    // the proper IP address, or delete this option.
    	listen-on	{ 127.0.0.1; };

    // If you have IPv6 enabled on this system, uncomment this option for
    // use as a local resolver.  To give access to the network, specify
    // an IPv6 address, or the keyword "any".
    //	listen-on-v6	{ ::1; };

    // These zones are already covered by the empty zones listed below.
    // If you remove the related empty zones below, comment these lines out.
    	disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
    	disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
    	disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

    // If you've got a DNS server around at your upstream provider, enter
    // its IP address here, and enable the line below.  This will make you
    // benefit from its cache, thus reduce overall DNS traffic in the Internet.
    /*
    	forwarders {
    		127.0.0.1;
    	};
    */

    // If the 'forwarders' clause is not empty the default is to 'forward first'
    // which will fall back to sending a query from your local server if the name
    // servers in 'forwarders' do not have the answer.  Alternatively you can
    // force your name server to never initiate queries of its own by enabling the
    // following line:
    //	forward only;

    // If you wish to have forwarding configured automatically based on
    // the entries in /etc/resolv.conf, uncomment the following line and
    // set named_auto_forward=yes in /etc/rc.conf.  You can also enable
    // named_auto_forward_only (the effect of which is described above).
    //	include "/etc/namedb/auto_forward.conf";

Тайлбар дээр хэлсэнчлэн дээд гарцын түр тогтоогчоос хүртэхийн тулд `forwarders`-г идэвхжүүлж болох юм. Энгийн үед, нэрийн сервер нь хариултыг олтлоо давталттай байдлаар хэд хэдэн нэрийн серверүүдээр дамжин асууна. Энэ тохируулгыг идэвхжүүлснээр, дээд гарцынхаа нэрийн серверээс (эсвэл зааж өгсөн нэрийн сервер) хамгийн түрүүнд асууж, энэ серверийн түр санах ойд байгаа мэдээллээс хүртэхийг эрмэлзэнэ. Хэрэв дээд гарцын нэрийн сервер нь олон асуулгад хариулдаг, хурдан үйлчилдэг сервер байвал дээрх тохируулгыг идэвхжүүлсний үр ашиг гарна.

| `127.0.0.1` энд ажиллах_гүй_. Энэ IP хаягийг өөрийн дээд гарцын нэрийн серверээр сольж бичнэ үү.

    	/*
    	   Modern versions of BIND use a random UDP port for each outgoing
    	   query by default in order to dramatically reduce the possibility
    	   of cache poisoning.  All users are strongly encouraged to utilize
    	   this feature, and to configure their firewalls to accommodate it.

    	   AS A LAST RESORT in order to get around a restrictive firewall
    	   policy you can try enabling the option below.  Use of this option
    	   will significantly reduce your ability to withstand cache poisoning
    	   attacks, and should be avoided if at all possible.

    	   Replace NNNNN in the example with a number between 49160 and 65530.
    	*/
    	// query-source address * port NNNNN;
    };

    // If you enable a local name server, don't forget to enter 127.0.0.1
    // first in your /etc/resolv.conf so this server will be queried.
    // Also, make sure to enable it in /etc/rc.conf.

    // The traditional root hints mechanism. Use this, OR the slave zones below.
    zone "." { type hint; file "/etc/namedb/named.root"; };

    /*	Slaving the following zones from the root name servers has some
    	significant advantages:
    	1. Faster local resolution for your users
    	2. No spurious traffic will be sent from your network to the roots
    	3. Greater resilience to any potential root server failure/DDoS

    	On the other hand, this method requires more monitoring than the
    	hints file to be sure that an unexpected failure mode has not
    	incapacitated your server.  Name servers that are serving a lot
    	of clients will benefit more from this approach than individual
    	hosts.  Use with caution.

    	To use this mechanism, uncomment the entries below, and comment
    	the hint zone above.

    	As documented at http://dns.icann.org/services/axfr/ these zones:
    	"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
    	are availble for AXFR from these servers on IPv4 and IPv6:
    	xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
    */
    /*
    zone "." {
    	type slave;
    	file "/etc/namedb/slave/root.slave";
    	masters {
    		192.5.5.241;	// F.ROOT-SERVERS.NET.
    	};
    	notify no;
    };
    zone "arpa" {
    	type slave;
    	file "/etc/namedb/slave/arpa.slave";
    	masters {
    		192.5.5.241;	// F.ROOT-SERVERS.NET.
    	};
    	notify no;
    };
    */

    /*	Serving the following zones locally will prevent any queries
    	for these zones leaving your network and going to the root
    	name servers.  This has two significant advantages:
    	1. Faster local resolution for your users
    	2. No spurious traffic will be sent from your network to the roots
    */
    // RFCs 1912 and 5735 (and BCP 32 for localhost)
    zone "localhost"	{ type master; file "/etc/namedb/master/localhost-forward.db"; };
    zone "127.in-addr.arpa"	{ type master; file "/etc/namedb/master/localhost-reverse.db"; };
    zone "255.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

    // RFC 1912-style zone for IPv6 localhost address
    zone "0.ip6.arpa"	{ type master; file "/etc/namedb/master/localhost-reverse.db"; };

    // "This" Network (RFCs 1912 and 5735)
    zone "0.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

    // Private Use Networks (RFCs 1918 and 5735)
    zone "10.in-addr.arpa"	   { type master; file "/etc/namedb/master/empty.db"; };
    zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

    // Link-local/APIPA (RFCs 3927 and 5735)
    zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

    // IETF protocol assignments (RFCs 5735 and 5736)
    zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

    // TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737)
    zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

    // IPv6 Range for Documentation (RFC 3849)
    zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };

    // Domain Names for Documentation and Testing (BCP 32)
    zone "test" { type master; file "/etc/namedb/master/empty.db"; };
    zone "example" { type master; file "/etc/namedb/master/empty.db"; };
    zone "invalid" { type master; file "/etc/namedb/master/empty.db"; };
    zone "example.com" { type master; file "/etc/namedb/master/empty.db"; };
    zone "example.net" { type master; file "/etc/namedb/master/empty.db"; };
    zone "example.org" { type master; file "/etc/namedb/master/empty.db"; };

    // Router Benchmark Testing (RFCs 2544 and 5735)
    zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
    zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

    // IANA Reserved - Old Class E Space (RFC 5735)
    zone "240.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "241.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "242.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "243.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "244.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "245.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "246.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "247.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "248.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "249.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "250.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "251.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "252.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "253.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "254.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

    // IPv6 Unassigned Addresses (RFC 4291)
    zone "1.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "3.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "4.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "5.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "6.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "7.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "8.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "9.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "a.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "b.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "c.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "d.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "e.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "0.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "1.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "2.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "3.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "4.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "5.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "6.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "7.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "8.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "9.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "a.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "b.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "0.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "1.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "2.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "3.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "4.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "5.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "6.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "7.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

    // IPv6 ULA (RFC 4193)
    zone "c.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "d.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

    // IPv6 Link Local (RFC 4291)
    zone "8.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "9.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "a.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "b.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

    // IPv6 Deprecated Site-Local Addresses (RFC 3879)
    zone "c.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "d.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "e.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
    zone "f.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

    // IP6.INT is Deprecated (RFC 4159)
    zone "ip6.int"		{ type master; file "/etc/namedb/master/empty.db"; };

    // NB: Do not use the IP addresses below, they are faked, and only
    // serve demonstration/documentation purposes!
    //
    // Example slave zone config entries.  It can be convenient to become
    // a slave at least for the zone your own domain is in.  Ask
    // your network administrator for the IP address of the responsible
    // master name server.
    //
    // Do not forget to include the reverse lookup zone!
    // This is named after the first bytes of the IP address, in reverse
    // order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6.
    //
    // Before starting to set up a master zone, make sure you fully
    // understand how DNS and BIND work.  There are sometimes
    // non-obvious pitfalls.  Setting up a slave zone is usually simpler.
    //
    // NB: Don't blindly enable the examples below. :-)  Use actual names
    // and addresses instead.

    /* An example dynamic zone
    key "exampleorgkey" {
    	algorithm hmac-md5;
    	secret "sf87HJqjkqh8ac87a02lla==";
    };
    zone "example.org" {
    	type master;
    	allow-update {
    		key "exampleorgkey";
    	};
    	file "/etc/namedb/dynamic/example.org";
    };
    */

    /* Example of a slave reverse zone
    zone "1.168.192.in-addr.arpa" {
    	type slave;
    	file "/etc/namedb/slave/1.168.192.in-addr.arpa";
    	masters {
    		192.168.1.1;
    	};
    };
    */

named.conf доторх эдгээр жишээнүүд нь ердийн болон урвуу бүсийн зарц бүртгэлүүд болно.

Шинэ бүс нэмэхдээ, named.conf файл дотор шинэ бүртгэл оруулах хэрэгтэй.

Жишээ нь, `example.org` домэйны хувьд хамгийн хялбар бүртгэл дараах байдалтай байна:

    zone "example.org" {
    	type master;
    	file "master/example.org";
    };

Энэ бүс нь эзэн бүс болохыг `type` илэрхийллээс харж болно. Мөн бүсийн мэдээллийг /etc/namedb/master/example.org файл дотор агуулж байгааг `file` илэрхийллээс харж болно.

    zone "example.org" {
    	type slave;
    	file "slave/example.org";
    };

Зарц бүсийн хувьд, тухайн бүсийн хувьд бүсийн мэдээлэл эзэн нэрийн серверээс зөөгдөж ирэх ба зааж өгсөн файлд хадгалагдана. Эзэн сервер унтарсан эсвэл холбоо тогтоох боломжгүй болбол, зарц нэрийн серверт бүсийн мэдээлэл байгаа тул асуулгуудад хариулах чадвартай байна.

#### 30.6.6.2. Бүсийн Файлууд

`example.org` домэйны хувьд жишээ эзэн бүсийн файлыг дор үзүүлэв (/etc/namedb/master/example.org файл):

    $TTL 3600        ; 1 hour default TTL
    example.org.    IN      SOA      ns1.example.org. admin.example.org. (
                                    2006051501      ; Serial
                                    10800           ; Refresh
                                    3600            ; Retry
                                    604800          ; Expire
                                    300             ; Negative Response TTL
                            )

    ; DNS Servers
                    IN      NS      ns1.example.org.
                    IN      NS      ns2.example.org.

    ; MX Records
                    IN      MX 10   mx.example.org.
                    IN      MX 20   mail.example.org.

                    IN      A       192.168.1.1

    ; Machine Names
    localhost       IN      A       127.0.0.1
    ns1             IN      A       192.168.1.2
    ns2             IN      A       192.168.1.3
    mx              IN      A       192.168.1.4
    mail            IN      A       192.168.1.5

    ; Aliases
    www             IN      CNAME   example.org.

"." тэмдэгтээр төгссөн хост нэрүүд нь жинхэнэ хост нэрүүд бөгөөд "." тэмдэгтээр төгсөөгүй нэрүүдэд үүсэл залгагдахыг анхаарна уу. Жишээлбэл, `ns1` нь `ns1.example.org.`-руу хөрвүүлэгдэх болно.

Бүсийн файл дараах хэлбэртэй байна:

    recordname      IN recordtype   value

Хамгийн өргөн хэрэглэгддэг DNS бичлэгүүд:

SOA

  start of zone authority буюу бүсийн бүрэн эрхт мэдээллийн эхлэл

NS

  бүрэн эрхт нэрийн сервер

A

  хостын хаяг

CNAME

  хуурамч дүрд өгөх хүлээн зөвшөөрөгдсөн нэр

MX

  захидал солилцогч

PTR

  домэйн нэрийг заагч (урвуу DNS-д хэрэглэнэ)

    example.org. IN SOA ns1.example.org. admin.example.org. (
                            2006051501      ; Serial
                            10800           ; Refresh after 3 hours
                            3600            ; Retry after 1 hour
                            604800          ; Expire after 1 week
                            300 )           ; Negative Response TTL

`example.org.`

  домэйн нэр, мөн энэ бүсийн файлын хувьд үүсэл болно.

`ns1.example.org.`

  энэ бүсийн гол/бүрэн эрхт нэрийн сервер.

`admin.example.org.`

  энэ бүсийг хариуцагч хүн, "@" тэмдэгтийг нь орлуулсан цахим захидлын хаяг. (admin@example.org нь `admin.example.org` болно)

`2006051501`

  Файлын сериал дугаар. Бүсийн файлд өөрчлөлт оруулах болгонд энэ дугаарыг нэмэгдүүлэх шаардлагатай. Одоо цагт ихэнх админууд энэ сериал дугаарыг `yyyymmddrr` хэлбэрээр хэрэглэх болсон. `2006051501` гэдэг нь хамгийн сүүлд 05/15/2006-нд засвар хийсэн, хамгийн сүүлийн `01` гэдэг нь энэ өдөр хийгдсэн хамгийн анхны засвар гэдгийг илтгэнэ. Энэ сериал дугаар нь зарц серверүүдэд бүсийн мэдээлэл өөрчлөгдсөн талаар мэдээлэл өгдөг тул их чухал зүйл байгаа юм.

           IN NS           ns1.example.org.

Энэ бол NS бичлэг. Тухайн бүсийн хувьд бүрэн эрхт хариултыг өгч чадах сервер бүрийн хувьд энэ бичлэг байх ёстой.

    localhost       IN      A       127.0.0.1
    ns1             IN      A       192.168.1.2
    ns2             IN      A       192.168.1.3
    mx              IN      A       192.168.1.4
    mail            IN      A       192.168.1.5

A бичлэг нь машины нэрийг заана. Дээр үзүүлсэнчлэн, `ns1.example.org` нь `192.168.1.2`-руу буулгагдана.

                    IN      A       192.168.1.1

Энэ мөр нь `192.168.1.1` гэсэн IP хаягийг үүсэлд оноож байна, бидний жишээн дээр `example.org`.

    www             IN CNAME        @

Хүлээн зөвшөөрөгдсөн нэрийн бичлэг нь машинд хуурамч дүр өгөхөд хэрэглэгдэнэ. Энэ жишээн дээр, `www` нь `example.org` (`192.168.1.1`) гэсэн домэйн нэртэй "master" машины хуурамч дүрийн нэр юм. CNAME-г тухайн хостын нэрийн хувьд өөр төрлийн бичлэгтэй хэзээ ч цуг хэрэглэж болохгүй.

                   IN MX   10      mail.example.org.

MX бичлэг нь аль захидлын серверүүд тухайн бүсийн захидлыг хүлээж авах үүрэгтэй болохыг зааж өгнө. `mail.example.org` нь захидлын серверийн хост нэр бөгөөд 10 нь энэ захидлын серверийн зэрэглэлийг зааж байна.

Нэг бүсэд 10, 20 гэх мэт ялгаатай зэрэглэлтэй хэд хэдэн захидлын сервер байж болно. `example.org` домэйн руу захидал явуулах гэж байгаа сервер эхлээд хамгийн өндөр зэрэглэлтэй MX сервертэй (хамгийн бага зэрэглэлийн дугаартай), дараа нь дараагийн хамгийн өндөр зэрэглэлтэй сервертэй гэх мэтчилэн захидлыг явуулж чадтал дарааллаар нь холбоо тогтооно.

in-addr.arpa бүсийн файл (урвуу DNS) нь ижил хэлбэртэй байна. Ганцхан ялгаа нь A болон CNAME бичлэгийн оронд PTR бичлэгийг хэрэглэнэ.

    $TTL 3600

    1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                            2006051501      ; Serial
                            10800           ; Refresh
                            3600            ; Retry
                            604800          ; Expire
                            300 )           ; Negative Response TTL

            IN      NS      ns1.example.org.
            IN      NS      ns2.example.org.

    1       IN      PTR     example.org.
    2       IN      PTR     ns1.example.org.
    3       IN      PTR     ns2.example.org.
    4       IN      PTR     mx.example.org.
    5       IN      PTR     mail.example.org.

Энэ файлд дээрх домэйны IP-с хост нэр рүү буулгасан зохих шаардлагатай буулгалтуудыг үзүүлсэн байна.

PTR бичлэгийн баруун талын бүх нэрс төгссөн байх ёстой (өөрөөр хэлбэл "."-ээр төгссөн байна).

### 30.6.7. Түр тогтоогч Нэрийн Сервер (Caching Name Server)

Түр тогтоогч нэрийн сервер гэдэг нь рекурсив хүсэлтэд хариу өгөх гол үүрэгтэй нэрийн серверийг хэлнэ. Ийм төрлийн сервер нь зөвхөн асуулга явуулах бөгөөд хариултыг дараа хэрэглэхээр тогтоож авдаг.

### 30.6.8. DNSSEC

Домэйн Нэрийн Системийн Аюулгүй байдлын Өргөтгөлүүд, товчоор DNSSEC, бол нэр тайлагч серверүүдийг залилуулсан DNS бичлэг гэх мэт хуурамч DNS өгөгдлөөс хамгаалах заавруудын иж бүрдэл юм. Электрон гарын үсгийн тусламжтай нэр тайлагч нь бичлэгийн бүрэн бүтэн байдлыг магадлах боломжтой. DNSSEC нь зөвхөн Боломжит Бичлэгүүд дээр (RRs) электрон гарын үсэг зурах замаар өгөгдлийн бүрэн бүтэн байдлыг хангадаг болохыг тэмдэглэн хэлье. Нууцлалыг хангаж, эцсийн хэрэглэгчийн буруу үйлдлээс хамгаалж чадахгүй. Өөрөөр хэлбэл хүмүүсийг `example.com`-н оронд `example.net`-руу орохыг болиулж чадахгүй гэсэн үг юм. DNSSEC-н хийж чадах ганц зүйл бол өгөгдөл замдаа хувиралгүйгээр очсоныг магадлан тогтоох юм. DNS-н аюулгүй байдал бол Интернэтийн аюулгүй байдлыг хангахад чухал алхам болдог. DNSSEC хэрхэн ажилладаг талаар дэлгэрэнгүй мэдээллийг тухайн RFC-үүдээс аваарай. Гүнзгийрүүлэн унших-д байгаа жагсаалтыг үзнэ үү.

Дараах бүлгүүдэд BIND 9 ажиллаж байгаа бүрэн эрхт DNS сервер болон рекурсив (эсвэл түр тогтоогч) DNS сервер дээр DNSSEC-г хэрхэн идэвхжүүлэхийг үзүүлэх болно. BIND 9-н бүх хувилбарууд DNSSEC-г дэмжих боловч, DNS асуулгуудын хүчинтэй эсэхийг шалгахад гарын үсэгтэй эх бүсийг ашиглахын тулд хамгийн багадаа 9.6.2 хувилбарыг суулгах шаардлагатай. Яагаад гэвэл өмнөх хувилбаруудад эх (root) бүсийн түлхүүрийг ашиглах шалгалтыг идэвхжүүлэхэд шаардлагатай алгоритмууд байдаггүй. Эх түлхүүрт зориулж автоматаар түлхүүрийг шинэчлэх боломж болон автоматаар бүсүүдийг гарын үсгээр баталгаажуулж гарын үсгүүдийг байнга шинэ байлгахын тулд BIND-ийн хамгийн сүүлийн хувилбар 9.7 юм уу эсвэл түүний дараагийн хувилбарыг ашиглахыг шаарддаг. 9.6.2 болон 9.7 болон түүнээс хойшхи хувилбаруудын хооронд тохиргооны зөрүү байвал харуулах болно.

#### 30.6.8.1. Рекурсив DNS серверийн тохиргоо

Рекурсив DNS серверийн гүйцэтгэсэн хүсэлтүүдийн DNSSEC шалгалтыг идэвхжүүлэхийн тулд named.conf файлд цөөн өөрчлөлтийг хийх хэрэгтэй. Эдгээр өөрчлөлтүүдийг хийхээс өмнө эх бүсийн түлхүүр эсвэл итгэлцлийн анкорыг (anchor) авсан байх шаардлагатай. Одоогоор эх бүсийн түлхүүр нь BIND ойлгох файлын форматаар байдаггүй бөгөөд зөв хэлбэр рүү гараар хувиргах ёстой байдаг. Түлхүүрийг dig ашиглан эх бүсээс асууж авч болдог. Ингэхийн тулд

    % dig +multi +noall +answer DNSKEY . > root.dnskey

гэж ажиллуулна. Түлхүүр root.dnskey файлд байх болно. Доторх нь иймэрхүү байдалтай харагдана:

    . 93910 IN DNSKEY 257 3 8 (
    	AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
    	bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
    	/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
    	JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
    	oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
    	LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
    	Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
    	LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
    	) ; key id = 19036
    . 93910 IN DNSKEY 256 3 8 (
    	AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf
    	UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE
    	g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V
    	EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt
    ) ; key id = 34525

Олж авсан түлхүүрүүд энэ жишээн дээрхээс өөр байвал сандрах хэрэггүй. Тэдгээр нь энэ зааврыг бичсэнээс хойш өөрчлөгдсөн байж болох юм. Энэ гаралт нь хоёр түлхүүрийг агуулдаг. DNSKEY бичлэгийн төрлийн дараах 257 гэсэн утга бүхий жагсаалтад байгаа эхний түлхүүр нь хэрэгтэй нь юм. Энэ утга нь Аюулгүй Орох Цэг (SEP), түлхүүрийг гарын үсгээр баталгаажуулах түлхүүр гэгддэг (KSK) гэдгийг илэрхийлдэг. 256 гэсэн хоёр дахь түлхүүр нь захирагдагч түлхүүр бөгөөд Бүсийг гарын үсгээр баталгаажуулах түлхүүр (ZSK) гэгддэг. Эдгээр өөр түлхүүрийн төрлүүдийн талаар Бүрэн эрхт DNS серверийн тохиргоо хэсэгт дэлгэрэнгүй байгаа.

Одоо түлхүүрийг шалгаж BIND ашиглаж болох хэлбэрт оруулах ёстой. Түлхүүрийг баталгаажуулахын тулд DSRR-г үүсгэнэ. Эдгээр RR-уудыг агуулсан файлыг дараах тушаалаар үүсгэнэ

    % dnssec-dsfromkey -f root-dnskey . > root.ds

Эдгээр бичлэгүүд нь SHA-1 болон SHA-256-г ашигладаг бөгөөд дараах жишээтэй төстэй харагдах ёстой. Урт нь SHA-256-г ашигладаг.

    . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
    . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

SHA-256 RR-г https://data.iana.org/root-anchors/root-anchors.xml дээр байгаа дайжесттай харьцуулж болно. Түлхүүрийг XML файлын өгөгдлөөр өөрчлөгдөөгүйг жинхэнэ утгаар мэдэхийн тулд https://data.iana.org/root-anchors/root-anchors.asc дахь PGP гарын үсгийг ашиглан шалгаж болно.

Дараа нь түлхүүрийг зөв хэлбэрт оруулсан байх ёстой. Энэ нь BIND 9.6.2 болон 9.7 түүнээс хойшхи хувилбаруудын хооронд жаахан ялгаатай байдаг. 9.7 хувилбарт түлхүүрт хийгдэх өөрчлөлтийг автоматаар хянаж шаардлагатай бол шинэчилдэг дэмжлэг нэмэгдсэн байдаг. Үүнийг доорх жишээн дээр үзүүлсэн шиг `managed-keys` ашиглан хийдэг. Хуучин хувилбар ашиглаж байгаа тохиолдолд түлхүүрийг `trusted-keys` гэдгийг ашиглан нэмдэг бөгөөд шинэчлэлтүүдийг гараар хийх ёстой байдаг. BIND 9.6.2-ийн хувьд формат доорхтой адил хэлбэрийн байна:

    trusted-keys {
    	"." 257 3 8
    	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    	QxA+Uk1ihz0=";
    };

For 9.7 the format will instead be:

    managed-keys {
    	"." initial-key 257 3 8
    	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    	QxA+Uk1ihz0=";
    };

Эх түлхүүрийг named.conf файл руу шууд эсвэл түлхүүр бүхий файлыг оруулан нэмж өгч болно. Эдгээр алхмуудын дараа BIND-г хүсэлтүүд дээр DNSSEC шалгалтыг хийдэг болгохын тулд named.conf файлыг засварлан дараах мөрийг `options` хэсэгт нэмж тохиргоог хийнэ:

    dnssec-enable yes;
    dnssec-validation yes;

Ажиллаж байгааг шалгахын тулд дөнгөж тохируулсан тайлагчийг ашиглан гарын үсгээр баталгаажсан бүсийг асуусан хүсэлтийг dig ашиглан явуулна. Амжилттай хариулт `AD` тэмдэглэгээтэй байх бөгөөд энэ нь өгөгдлийг таньж зөвшөөрсөн гэсэн үг юм. Доорх хүсэлттэй адил хүсэлтийг ажиллуулбал

    % dig @resolver +dnssec se ds

`.se` бүсийн хувьд DSRR-г буцаах ёстой. `flags:` хэсэг дээр `AD` флаг тохируулагдсан байх ёстой бөгөөд доорх байдлаар харагдана:

    ...
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
    ...

Тайлагч одоо DNS хүсэлтүүдийг шалгаж таних чадвартай боллоо.

#### 30.6.8.2. Бүрэн эрхт DNS серверийн тохиргоо

DNSSEC-р баталгаажсан бүсэд үйлчлэх бүрэн эрхт нэрийн сервертэй болохын тулд бага зэргийн зүйлс хийх шаардлагатай. Бүсийг криптограф түлхүүрүүд ашиглан баталгаажуулах ёстой бөгөөд түлхүүрүүдийг үүсгэх ёстой. Энэ зорилгоор зөвхөн нэг түлхүүр ашиглаж болно. Гэхдээ зөвлөдөг арга бол байнга өөрчлөгдөөд байдаггүй, хүчтэй, маш сайн хамгаалагдсан Түлхүүрийг гарын үсгээр баталгаажуулах Түлхүүр (KSK) болон байнга өөрчлөгддөг Бүсийг гарын үсгээр баталгаажуулах Түлхүүртэй (ZSK) байх явдал юм. Үйл ажиллагааны хувьд зөвлөсөн практикуудын талаарх мэдээллийг RFC 4641: DNSSEC үйл ажиллагааны практикууд хаягаас авч болно. Эх бүсийн талаарх практикуудыг Эх бүсийн KSKоператорт зориулсан DNSSEC практик болон Эх бүсийн ZSKоператорт зориулсан DNSSEC практик хаягуудаас олж болно. KSK нь дараалсан бүрэн эрхийг шалгагдах шаардлагатай байгаа өгөгдөлд өгөхөд хэрэглэгддэг бөгөөд бас Secure Entry Point буюу Аюулгүй Орох Цэг (SEP) түлхүүр гэгддэг. Энэ түлхүүрийн зурвасын дайжестийг Delegation Signer буюу Төлөөлөн баталгаажуулагч(DS) бичлэг гэгддэг бөгөөд итгэлцлийн дарааллыг бий болгохын тулд эцэг бүсэд бичигдсэн байх ёстой. Үүнийг хэрхэн хийх нь эцэг бүсийг эзэмшигчээс хамаардаг. ZSK нь бүсийг баталгаажуулахад хэрэглэгддэг бөгөөд тэндээ бичигдсэн байх ёстой байдаг.

Өмнөх жишээн дээр харуулсан `example.com` бүсийн хувьд DNSSEC-г идэвхжүүлэхийн тулд эхний алхам нь KSK болон ZSK түлхүүрийн хослолыг үүсгэх dnssec-keygen-г ашиглах явдал юм. Энэ түлхүүрийн хослол нь өөр өөр криптограф алгоритмуудыг хэрэглэж болно. Түлхүүрүүдийн хувьд RSA/SHA256-г ашиглахыг зөвлөдөг бөгөөд 2048 битийн түлхүүрийн урт хангалттай. `example.com`-н хувьд KSK-г үүсгэхийн тулд дараахийг ажиллуулна

    % dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com

ZSK-г үүсгэхийн тулд

    % dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

dnssec-keygen хоёр файлыг гаргах бөгөөд нийтийн болон хувийн түлхүүрүүд нь Kexample.com.+005+nnnnn.key (нийтийн) болон Kexample.com.+005+nnnnn.private (хувийн) гэсэн файлуудтай төстэй нэртэйгээр байна. Файлын нэрийн `nnnnn` хэсэг нь таван оронтой түлхүүрийн ID юм. Аль түлхүүрийн ID аль түлхүүрт харгалзаж байгааг хянаж байх хэрэгтэй. Энэ нь ялангуяа бүсэд нэгээс илүү түлхүүр ашиглаж байгаа үед чухал юм. Түлхүүрүүдийн нэрийг бас өөрчилж болно. KSK файл бүрийн хувьд дараахийг ажиллуулна:

    % mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key
    % mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private

ZSK файлуудын хувьд `KSK`-г `ZSK`-р солиорой. Одоо файлуудыг `$include` ашиглан бүсийн файлд оруулж болно. Иймэрхүү байдалтай харагдана:

    $include Kexample.com.+005+nnnnn.KSK.key    ; KSK
    $include Kexample.com.+005+nnnnn.ZSK.key    ; ZSK

Төгсгөлд нь бүсийг баталгаажуулж BIND-д баталгаажуулсан бүсийн файлыг ашиглахыг зааж өгнө. Бүсийг баталгаажуулахын тулд dnssec-signzone-г ашиглана. example.com.db-д байрлах `example.com` бүсийг баталгаажуулах тушаал иймэрхүү байна

    % dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key

`-k` аргументад өгөгдсөн түлхүүр нь KSK ба нөгөө нэг түлхүүрийн файл нь ZSK бөгөөд баталгаажуулахад хэрэглэгдэх ёстой. Нэгээс илүү KSK болон ZSK өгч болох бөгөөд ингэсэн тохиолдолд бүс бүх өгөгдсөн түлхүүрээр баталгаажна. Энэ нь бүсийн өгөгдлийг нэгээс илүү алгоритмаар баталгаажуулахын тулд хэрэгтэй байж болно. dnssec-signzone-ий гаралт нь бүх RR нь баталгаажсан бүсийн файл байна. Энэ гаралт нь example.com.db.signed мэтийн `.signed` гэсэн өргөтгөлтэй файлд байх болно. DS бичлэгүүд нь бас тусдаа dsset-example.com файлд бичигддэг. Энэ баталгаажсан бүсийг ашиглахын тулд named.conf файлын бүсийн хэсэгт example.com.db.signed-г ашиглахаар болгож өөрчлөх хэрэгтэй. Анхдагчаар гарын үсгүүд нь 30 хоног хүчинтэй байдаг бөгөөд хүчингүй гарын үсгүүд бүхий бичлэгүүдийг нэр тайлагчдаар хадгалуулахгүй байлгахын тулд бүсийг ядаж ойролцоогоор 15 хоногийн дараа дахин баталгаажуулах хэрэгтэй гэсэн үг юм. Үүнийг хийхийн тулд скрипт бичээд cron-д ажиллуулахаар тохируулж болно. Дэлгэрэнгүйг холбогдох гарын авлагуудаас харна уу.

Бүх криптограф түлхүүрүүдийн адил хувийн түлхүүрүүдийг нууцлан хадгалахыг санаарай. Түлхүүрийг солихдоо шинэ түлхүүрийг бүсэд оруулан хуучнаар эхлээд баталгаажуулах нь зүйтэй бөгөөд дараа нь шинэ түлхүүрийг ашиглан баталгаажуулах хэрэгтэй. Эдгээр алхмуудыг хийсний дараа хуучин түлхүүрийг бүсээс арилгаж болно. Ингэж хийхгүй бол шинэ түлхүүр DNS-н шатлалаар түгээгдэн зарлагдтал DNS-н өгөгдөл нь хүртээмжгүй байх нөхцөлд хүргэж болно. Түлхүүр солих мэдээлэл болон DNSSEC-г ажиллуулахтай холбоотой асуудлуудын талаар дэлгэрэнгүйг RFC 4641: DNSSEC Operational practices хаягаас үзнэ үү.

#### 30.6.8.3. BIND 9.7 болон түүнээс хойшхи хувилбаруудыг ашиглан автоматжуулах

BIND 9.7 хувилбараас эхлээд Smart Signing буюу ухаалгаар баталгаажуулах боломж шинээр нэмэгдсэн. Энэ боломж нь түлхүүрийг удирдах болон баталгаажуулах процессын зарим хэсгийг автоматжуулснаар хялбар болгохыг зорьдог. key repository санд түлхүүрүүдийг байршуулж `auto-dnssec` гэсэн шинэ тохиргоог ашиглан шаардлагатай тохиолдолд дахин баталгаажуулагддаг динамик бүсийг үүсгэх боломжтой байдаг. Энэ бүсийг шинэчлэхийн тулд nsupdate-г шинэ `-l` аргументтай хэрэглэнэ. rndc бас түлхүүр байрлах сан дахь түлхүүрүүдээр бүсүүдийг `sign` гэсэн тохиргоо ашиглан баталгаажуулах боломжтой болсон. `example.com`-н хувьд энэ автоматаар хийх баталгаажуулалт болон бүсийг шинэчлэх боломжийг BIND-д зааж өгөхийн тулд дараахийг named.conf файлд нэмж өгөх хэрэгтэй:

    zone example.com {
    	type master;
    	key-directory "/etc/named/keys";
    	update-policy local;
    	auto-dnssec maintain;
    	file "/etc/named/dynamic/example.com.zone";
    };

Эдгээр өөрчлөлтүүдийг хийсний дараа Бүрэн эрхт DNS серверийн тохиргоо-д тайлбарласны дагуу бүсийн хувьд түлхүүрүүдийг үүсгэж өгнө. Ингэхийн тулд тэр түлхүүрүүдийг түлхүүр байрлах санд хийж бүсийн тохиргооны `key-directory` гэдэгт уг санг өгөх бөгөөд ингэснээр бүс автоматаар баталгаажуулагдах болно. Ийм замаар тохируулсан бүсэд хийх шинэчлэлтийг nsupdate ашиглан хийх ёстой бөгөөд энэ нь бүсэд шинэ өгөгдөл нэмэн дахин баталгаажуулах ажлыг хийдэг байна. Илүү дэлгэрэнгүйг Гүнзгийрүүлэн унших болон BIND-н баримтаас үзнэ үү.

### 30.6.9. Аюулгүй байдал

Хэдийгээр BIND нь хамгийн өргөн хэрэглэгддэг DNS сервер боловч, аюулгүй байдалтай холбоотой асуудлууд байнга тулгардаг. Гадны халдлагад өртөж болзошгүй аюулгүй байдлын цоорхой заримдаа олддог.

Хэдийгээр FreeBSD named-г автоматаар chroot(8) орчинд оруулдаг боловч; DNS халдлагад ашиглаж болохуйц хэд хэдэн механизмууд байсаар байна.

CERT-с гаргадаг аюулгүй байдлын санамжуудыг уншихыг зөвлөж байна. Мөн FreeBSD аюулгүй байдлын мэдэгдлүүд захидлын жагсаалт-д бүртгүүлж, шинээр гарч байгаа Интернэт болон FreeBSD-н аюулгүй байдлын асуудлуудын талаар мэдээлэлтэй байхыг зөвлөе.

| Хэрэв ямар нэгэн асуудал тулгарвал эхийг байнга шинэчилж, named-г шинээр бүтээх нь тусалж болох юм.

### 30.6.10. Гүнзгийрүүлэн унших

BIND/named заавар хуудсууд: rndc(8) named(8) named.conf(8)nsupdate(8) dnssec-signzone(8) dnssec-keygen(8)

- ISC BIND-н Албан ёсны Хуудас

- ISC BIND-н Албан ёсны Хэлэлцүүлэг

- Root DNSSEC

- O’Reilly "DNS ба BIND" 5 дахь Хэвлэлт

- DNSSECЭх бүсэд зориулсан итгэмжит анкор зарлалт (Trust Anchor Publication for the Root Zone)

- RFC1034 - Домэйн Нэрүүд - Зарчмууд болон Боломжууд

- RFC1035 - Домэйн Нэрүүд - Хэрэгжүүлэлт болон Үзүүлэлтүүд

- RFC4033 - DNS-н аюулгүй байдлын танилцуулга ба шаардлагууд

- RFC4034 - DNS-н аюулгүй байдлын өргөтгөлүүдэд зориулсан Resource Records буюу Нөөцийн Бичлэгүүд

- RFC4035 - DNS-н аюулгүй байдлын өргөтгөлүүдэд зориулсан протоколын өөрчлөлтүүд

- RFC4641 - DNSSEC ажиллуулах практикууд

- RFC 5011 - DNS-н аюулгүй байдлын автомат шинэчлэлтүүд (DNSSEC Trust Anchors

## 30.7. Apache HTTP Сервер

### 30.7.1. Удиртгал

Дэлхийн хамгийн их ачаалалтай ажилладаг зарим вэб сайтууд FreeBSD дээр ажилладаг. Интернэтэд ажиллаж байгаа вэб серверүүдийн олонхи нь Apache HTTP Серверийг ашиглаж байна. Apache програм хангамжийн багц таны FreeBSD суулгах дискэнд орсон байгаа. Хэрэв та FreeBSD-г анх суулгахдаа Apache-г хамт суулгаагүй бол www/apache22 портоос суулгаж болно.

Apache нэгэнт амжилттай суусан бол түүнийг тохируулах шаардлагатай.

| Apache HTTP Server-н 2.2.X хувилбар нь FreeBSD-д хамгийн өргөн хэрэглэгддэг тул бид энэ хэсэгт энэ хувилбарыг үзэх болно. Apache 2.X-н талаар энэ баримтын хүрээнээс хальсан дэлгэрэнгүй мэдээллийг http://httpd.apache.org/ хаягаар орж үзнэ үү.

### 30.7.2. Тохиргоо

FreeBSD дээрх Apache HTTP Серверийн гол тохиргооны файл бол /usr/local/etc/apache22/httpd.conf юм. Энэ файлд, UNIX®-н текст тохиргооны файлын нэгэн адил тайлбар мөрүүдийн өмнө `#` тэмдэгтийг хэрэглэдэг. Бүх боломжит тохируулгуудын талаар дэлгэрүүлж тайлбарлах нь энэ номын хүрээнээс халих тул, хамгийн их өөрчлөлт хийгддэг директивүүдийг энд авч үзье.

`ServerRoot "/usr/local"`

  Энэ директив Apache суулгацын анхдагч директор шатлалын эхийг зааж өгнө. Хоёртын файлууд серверийн эх директорын bin ба sbin дэд директоруудад, тохиргооны файлууд etc/apache дэд директорт байрлана.

`ServerAdmin you@your.address`

  Сервертэй холбоотой асуудлуудын талаар илгээх цахим захидлын хаягийг заана. Энэ хаяг алдааны хуудсууд гэх зэрэг сервер талаас автоматаар үүсгэгддэг зарим хуудсууд дээр бичигдэх болно.

`ServerName www.example.com`

  `ServerName` нь хост дээр тохируулагдсан хост нэрээс өөр нэрийг сервертээ өгөх боломжийг танд олгоно (өөрөөр хэлбэл, хостын жинхэнэ хост нэрийн оронд `www`-г хэрэглэх). Энэ нэрээр таны сервер харилцагч нартай харилцах болно.

`DocumentRoot "/usr/local/www/apache22/data"`

  `DocumentRoot`: Энэ директорт байгаа вэб баримтуудыг харилцагч нарт үзүүлэх болно. Анхдагч байдлаар, бүх хүсэлтүүд энэ директорт өгөгдөнө. Гэвч симбол холбоосууд болон хуурамч дүрүүдийг ашиглан өөр газар руу зааж өгч болно.

Apache-н тохиргооны файлд ямар нэг өөрчлөлт хийхээсээ өмнө нөөц хуулбарыг авч үлдэхээ мартуузай. Тохиргоо хийж дууссан бол одоо Apache-г ажиллуулах хэрэгтэй.

### 30.7.3. Apache-г ажиллуулах нь

www/apache22 порт нь Apache-г эхлүүлэх, зогсоох болон дахин ачаалахад хэрэгтэй rc(8) скриптийг суулгадаг бөгөөд энэ нь /usr/local/etc/rc.d/ санд байрладаг.

Систем ачаалах үед Apache-г эхлүүлэхийн тулд дараах мөрүүдийг /etc/rc.conf файлд нэмж бичнэ:

    apache22_enable="YES"

Хэрэв Apache-г анхдагч биш сонголтуудтай ажиллуулах бол дараах мөрийг /etc/rc.conf файлд нэмж тохируулж болно:

    apache22_flags=""

Apache-н тохиргоог `httpd` демонг анх эхлүүлэхээсээ өмнө юм уу эсвэл `httpd` ажиллаж байгаа үед дараалсан тохиргооны өөрчлөлтүүдиийг хийсний дараа алдаа байгаа эсэхийг тест хийж болно. Үүнийг rc(8) скриптээр шууд хийх юм уу эсвэл service(8) хэрэгслийг ашиглан дараах тушаалуудын аль нэгийг ажиллуулж хийнэ:

    # service apache22 configtest

| `configtest` нь rc(8)-ий хувьд стандарт биш гэдгийг санаарай, бүх rc(8) эхлүүлэх скриптүүдийн хувьд ажиллахгүй байж болно.

Хэрэв Apache тохиргооны алдаа өгөөгүй бол Apache `httpd`-г адил service(8) механизмаар эхлүүлж болно:

    # service apache22 start

`httpd` үйлчилгээг вэб хөтөч дээр `http://localhost` гэж тест хийж болно. Хэрэв энэ нь локал машин биш бол `httpd` ажиллаж байгаа машины бүрэн танигдсан домен нэрээр сольж тестлээрэй. Харуулагдах анхдаг вэб хуудас нь /usr/local/www/apache22/data/index.html байна.

### 30.7.4. Давхар байршуулалт

Apache нь хоёр төрлийн давхар байршуулах үйлчилгээг дэмждэг. Эхнийх нь нэр дээр үндэслэсэн давхар байршуулалт юм. Нэр дээр үндэслэсэн давхар байршуулалт дээр хост нэрийг ялгаж мэдэхдээ харилцагчийн HTTP/1.1 толгойн хэсгийг ашигладаг. Иим байдлаар олон өөр домэйнууд нэг IP хаягийг хуваан хэрэглэх боломжтой болдог.

Apache дээр, нэр дээр үндэслэсэн давхар байршуулалтыг хэрэглэхийн тулд доор дурдсантай төстэй бүртгэлийг httpd.conf файл дотор нэмж бичих хэрэгтэй:

    NameVirtualHost *

Таны вэб серверийн нэр `www.domain.tld` бөгөөд `www.someotherdomain.tld` нэртэй домэйныг давхар байршуулах хүсэлтэй бол, та дараах бүртгэлийг httpd.conf файлд нэмэх хэрэгтэй болно:

    <VirtualHost *>
    ServerName www.domain.tld
    DocumentRoot /www/domain.tld
    </VirtualHost>

    <VirtualHost *>
    ServerName www.someotherdomain.tld
    DocumentRoot /www/someotherdomain.tld
    </VirtualHost>

Дээрх хаягуудын оронд хэрэгтэй хаягуудыг, замуудын оронд баримтууд байгаа зохих замуудыг сольж бичнэ үү.

Давхар хостуудыг зохион байгуулах талаар дэлгэрэнгүй мэдээллийг Apache-н албан ёсны баримтжуулалт: http://httpd.apache.org/docs/vhosts/-с олж үзнэ үү.

### 30.7.5. Apache Модулиуд

Үндсэн серверийн үүрэг функцыг сайжруулахын тулд бүтээгдсэн Apache-н олон модулиуд байдаг. FreeBSD Портуудын Цуглуулга нь Apache-г түүний өргөн хэрэглэгддэг зарим модулиудын хамт хялбар суулгах боломжийг олгодог.

#### 30.7.5.1. mod_ssl

mod_ssl модуль нь Secure Sockets Layer (SSL v2/v3) ба Transport Layer Security (TLS v1) протоколоор дамжуулан өндөр нууцлалыг хангахын тулд OpenSSL санг ашигладаг. Энэ модуль нь батламж олгодог итгэмжлэгдсэн байгууллагаас батламж авахын тулд шаардлагатай бүх зүйлсээр хангадаг тул та үүнийг ашиглан FreeBSD дээр аюулгүй вэб сервер ажиллуулж чадна.

mod_ssl модуль нь анхдагчаар бүтээгдсэн байдаг боловч бүхээх үедээ `-DWITH_SSL` сонголт ашиглан идэвхжүүлж болно.

#### 30.7.5.2. Хэлний холболтууд

Ихэнх гол скрипт хэлнүүдэд зориулсан Apache-ийн модулиуд байдаг. Эдгээр модулиуд нь Apache-ийн модулиудыг бүхэлд нь скрипт хэл дээр бичих боломжийг ихэвчлэн бүрдүүлдэг. Эдгээр нь бас гадаад тайлбарлагчийг эхлүүлэх нэмэлт зардал болон димамик вэб сайтуудын хувьд байдаг эхлүүлэх хугацааны алдагдлыг тойрон гарах, серверт багтааж хийгдсэн байнгын тайлбарлагч болон дараагийн хэсэгт тайлбарлагдсан шигээр ихэвчлэн ашиглагддаг.

### 30.7.6. Динамик вэб сайтууд

Сүүлийн 10 жилд, өөрийн ашиг орлогыг нэмэгдүүлэх, хүмүүст хүрэх зорилгоор илүү олон компаниуд бизнесээ Интернэтээр явуулах болжээ. Энэ нь динамик агуулгатай вэб хуудсууд төрөн гарах хэрэгцээ шаардлагыг улам нэмэгдүүлсэн. Microsoft® гэх мэт зарим компаниуд ч өөрийн бүтээгдэхүүнүүдэд тэдгээрээс оруулах болсон хэдий ч, нээлттэй эхийн нэгдэл энэ асуудалд хариу өгсөн юм. Динамик вэб агуулгыг бий болгох орчин үеийн боломжууд бол Django, Ruby on Rails, mod_perl2 болон mod_php юм.

#### 30.7.6.1. Django

Django нь өндөр ажиллагаатай, гоёмсог вэб програмыг хурдан бичих боломжийг хөгжүүлэгчдэд олгохоор хийгдсэн, BSD лицензтэй тогтолцоо юм. Энэ нь өгөгдлийн төрлүүд Python обьект хэлбэрээр хөгжүүлэгддэг байхаар болгосон обьектийн харилцааг оноогчтой бөгөөд тэдгээр обьектуудад зориулсан хөгжүүлэгчдэд SQL бичих шаардлагагүй болгож өгдөг, баялаг динамик өгөгдлийн сангийн хандалтын API-тай юм. Энэ нь бас програмын логикийг HTML үзүүлбэрээс тусгаарлах боломжийг бүрдүүлэх нэмэлт загварын системтэй байдаг.

Django нь mod_python, Apache, болон таны сонгосон SQL өгөгдлийн сангийн хөдөлгүүрээс хамаардаг. FreeBSD порт нь эдгээр бүх хамаарлуудыг тохирсон сонголтуудтай нь танд суулгаж өгөх болно.

Жишээ 3. Django-г Apache2, mod_python3, болон PostgreSQL суулгах нь

    # cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL

Django болон бусад хамаарлууд суулгагдсаны дараа та Django төслийн санг үүсгэх хэрэгтэй бөгөөд өөрийн сайт дээрх тухайн URL дээр өөрийн програмыг дуудахын тулд суулгагдсан Python тайлбарлагчийг ашиглахаар болгож Apache-г тохируулах хэрэгтэй.

Жишээ 4. Django/mod_python-д зориулсан Apache-ийн тохиргоо

Та өөрийн вэб програм руу тодорхой URL-уудад зориулсан хүсэлтүүдийг дамжуулахаар Apache-г тохируулахын тулд apache-ийн httpd.conf файлд мөр нэмэх шаардлагатай:

    <Location "/">
        SetHandler python-program
        PythonPath "['/dir/to/your/django/packages/'] + sys.path"
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
        PythonAutoReload On
        PythonDebug On
    </Location>

#### 30.7.6.2. Ruby on Rails

Ruby on Rails нь бүрэн гүйцэд хөгжүүлэлтийн стекийн боломжийг олгодог бөгөөд вэб хөгжүүлэгчдийг хүчирхэг програмыг хурдан шуурхай, илүү үр бүтээлтэй бичдэг байхаар оновчлогдсон, нээлттэй эхийн вэб тогтолцоо юм. Үүнийг портын системээс хялбараар суулгаж болно.

    # cd /usr/ports/www/rubygem-rails; make all install clean

#### 30.7.6.3. mod_perl2

Apache/Perl нэгтгэх төсөл Perl програмчлалын хэл ба Apache HTTP Серверийн бүх хүч чадлыг нэгтгэсэн юм. mod_perl2 модулийн тусламжтай Apache модулиудыг тэр чигээр нь Perl дээр бичих боломжтой. Дээр нь, серверт суулгасан шургуу хөрвүүлэгч, гадны хөрвүүлэгч ашиглах илүү ажил болон Perl эхлүүлэх хугацааны алдагдлаас зайлсхийж чадсан юм.

mod_perl2 нь www/mod_perl2 портод байдаг.

#### 30.7.6.4. mod_php

PHP буюу "PHP:Hypertext Preprocessor" бол вэб хөгжүүлэлтэд тусгайлан тохируулсан, энгийн хэрэглээний скрипт хэл юм. HTML дотор суулгах боломжтой түүний синтакс C, Java™, ба Perl-с гаралтай. Энэ нь вэб хөгжүүлэгчдэд динамикаар үүсгэгдэх вэб хуудсыг хурдан бичих боломжтой болгох үүднээс тэгсэн хэрэг.

Apache вэб серверийг PHP5-г дэмждэг болгохын тулд, lang/php5 портыг суулгаж эхлэх хэрэгтэй.

Хэрэв lang/php5 портыг анх удаа суулгаж байгаа бол, боломжит `ТОХИРУУЛГУУД` автоматаар дэлгэцэн дээр гарч ирнэ. Хэрэв цэс гарч ирэхгүй бол, өөрөөр хэлбэл lang/php5 портыг өмнө нь хэзээ нэгэн цагт суулгаж байсан бол, тохируулгуудын харилцах цонхыг гаргаж ирэхийн тулд дараах тушаалыг:

    # make config

порт директор дотор өгөх хэрэгтэй.

Тохируулгуудын харилцах цонхонд, mod_php5-г Apache-н ачаалах боломжтой модуль байдлаар бүтээхийн тулд `APACHE` тохируулгыг идэвхжүүлнэ.

| Олон сайтууд PHP4-г янз бүрийн шалтгааны улмаас (өөрөөр хэлбэл, нийцтэй байдал эсвэл аль хэдийн үйлчилгээнд гаргачихсан вэб програмууд) ашигласаар байна. Хэрэв mod_php4-г mod_php5-н оронд ашиглах шаардлагатай бол, lang/php4 портыг ашиглаарай. lang/php4 порт нь lang/php5 портод байдаг тохиргооны болон бүтээх үеийн олон тохируулгуудыг дэмждэг.

Энэ хэсэг код динамик PHP програмыг дэмждэг болгоход шаардлагатай модулиудыг суулгаж тохируулах болно. Доорх мөрүүд /usr/local/etc/apache22/httpd.conf файл дотор нэмэгдсэн эсэхийг шалгаарай:

    LoadModule php5_module        libexec/apache/libphp5.so

    AddModule mod_php5.c
        <IfModule mod_php5.c>
            DirectoryIndex index.php index.html
        </IfModule>
        <IfModule mod_php5.c>
            AddType application/x-httpd-php .php
            AddType application/x-httpd-php-source .phps
        </IfModule>

Үүний дараа, PHP модулийг ачаалахын тулд, дараах тушаалыг өгч серверийг дахин ачаалах хэрэгтэй:

    # apachectl graceful

Дараа, PHP-н хувилбарыг дээшлүүлэх үедээ, `make config` тушаалыг өгөх шаардлагагүй; идэвхжүүлсэн `ТОХИРУУЛГУУД` FreeBSD Портуудын тогтолцоонд автоматаар хадгалагдсан байгаа.

FreeBSD-н PHP дэмжлэг нь дээд зэргээр модульчлагдсан тул үндсэн суулгац нь маш хязгаарлагдмал байдаг. lang/php5-extensions портыг ашиглан дэмжлэг нэмэх нь үнэхээр амархан асуудал. PHP өргөтгөлийг суулгах явцад, энэ порт танд цэсээс тогтсон интерфэйсийг санал болгоно. Өөрөөр, өргөтгөлүүдийг нэг нэгээр нь харгалзах портуудаас суулгаж болно.

Жишээлбэл, PHP5-д MySQL өгөгдлийн сангийн серверийн дэмжлэгийг нэмэхийн тулд, databases/php5-mysql портыг суулгахад хангалттай.

Ямар нэг өргөтгөл суулгасны дараа, тохиргооны өөрчлөлтийг хүчин төгөлдөр болгохын тулд Apache серверийг дахин ачаалах шаардлагатайг анхаарна уу:

    # apachectl graceful

## 30.8. Файл Дамжуулах Протокол (FTP)

### 30.8.1. Удиртгал

File Transfer Protocol буюу Файл Дамжуулах Протокол (FTP) нь хэрэглэгчдэд FTP серверээс файлыг авах болон тавих хялбар замыг бий болгодог. FreeBSD үндсэн систем дотроо FTP сервер програм ftpd-г агуулж байдаг. Энэ нь FreeBSD дээр FTP серверийг босгох, удирдах ажлыг төвөггүй болгодог.

### 30.8.2. Тохиргоо

Тохиргоо хийхийн өмнөх хамгийн чухал алхам бол ямар дансууд FTP серверт хандах эрхтэй байх вэ гэдгийг шийдэх байдаг. Ердийн FreeBSD систем нь янз бүрийн дэмонуудад хэрэглэгддэг олон тооны системийн дансуудтай байдаг ба гадны хэрэглэгчид эдгээр дансыг ашиглан нэвтрэх ёсгүй. /etc/ftpusers файл дотор FTP хандалт зөвшөөрөгдөөгүй хэрэглэгчдийн жагсаалтыг хадгална. Анхдагч байдлаар, дээр дурдсан системийн дансууд энэ файлд байна. FTP хандалтыг зөвшөөрөх ёсгүй өөр хэрэглэгчдийг ч мөн энэ файлд нэмж болно.

Зарим хэрэглэгчдийн FTP хэрэглэхийг нь бүр болиулчихалгүйгээр, зөвхөн зарим нэг эрхийг нь хязгаарлаж бас болно. Үүнийг /etc/ftpchroot файлын тусламжтай гүйцэтгэж болно. Энэ файл дотор FTP хандалтыг нь хязгаарлах хэрэглэгчид болон бүлгүүдийн жагсаалт байна. ftpchroot(5) заавар хуудсанд бүх мэдээлэл байгаа тул энд дурдсангүй.

Хэрэв сервертээ нийтийн FTP хандалтыг зөвшөөрөх хүсэлтэй байгаа бол, FreeBSD систем дээрээ `ftp` нэртэй хэрэглэгч нэмэх хэрэгтэй. Ингэснээр хэрэглэгчид таны FTP сервер рүү `ftp` эсвэл `anonymous` гэсэн нэрээр ямар ч нэвтрэх үг шаардагдахгүйгээр (тогтсон заншил ёсоор хэрэглэгч цахим шуудангийн хаягаа нэвтрэх үгийн оронд хэрэглэх шаардлагатай) нэвтрэн орох болно. Нийтийн хэрэглэгч системд орж ирэхэд FTP сервер түүний эрхийг зөвхөн `ftp` хэрэглэгчийн гэрийн сан дотор хязгаарлахын тулд chroot(2)-г дуудна.

FTP харилцагчдад зориулсан мэндчилгээний үгнүүдийг агуулсан хоёр текст файл байдаг. /etc/ftpwelcome файл дотор байгааг нэвтрэлт хүлээх мөр гарахаас өмнө хэрэглэгчдэд дэлгэцэн дээр хэвлэнэ. Амжилттай нэвтэрч орсны дараа /etc/ftpmotd файл дотор байгааг дэлгэцэн дээр хэвлэнэ. Энэ файлын зам нь нэвтэрч орсон орчинтой харьцангуйгаар авсан зам гэдгийг анхаарна уу, тиймээс нийтийн хэрэглэгчдийн хувьд ~ftp/etc/ftpmotd файлыг хэвлэх болно.

FTP серверийн тохиргоог зохих ёсоор хийсний дараа, /etc/inetd.conf файл дотор идэвхжүүлэх хэрэгтэй. Үүний тулд, ftpd гэсэн мөрний өмнөх "#" тэмдэгтийг арилгахад хангалттай:

    ftp	stream	tcp	nowait	root	/usr/libexec/ftpd	ftpd -l

inetd-н тохиргооны файлыг дахин ачаалах нь хэсэгт тайлбарласан ёсоор энэ тохиргооны файлд өөрчлөлт оруулсны дараа inetd-г дахин ачаалах шаардлагатай. Өөрийн систем дээр inetd-г идэвхжүүлэх талаар дэлгэрэнгүйг Тохиргоо-с үзнэ үү.

Мөн ftpd-ийг дангаар нь ажиллуулахаар тохируулж болно. Энэ тохиолдолд /etc/rc.conf файлд тохирох хувьсагчийг тохируулахад хангалттай байдаг:

    ftpd_enable="YES"

Дээрх хувьсагчийг тохируулсны дараа сервер дараачийн ачаалалт хийхэд ажиллах боломжтой болох бөгөөд эсвэл дараах тушаалыг `root` эрхээр ажиллуулан эхлүүлж болно:

    # service ftpd start

Одоо та дараах тушаалыг өгөн FTP сервер рүү нэвтрэн орж болно:

    % ftp localhost

### 30.8.3. Арчилгаа

ftpd дэмон бүртгэл хөтлөхдөө syslog(3)-г ашигладаг. Анхдагч байдлаар, системийн бүртгэлийн дэмон FTP-тэй холбоотой зурвасуудыг /var/log/xferlog файлд бичнэ. FTP бүртгэлийн файлын байршлыг өөрчлөхийн тулд /etc/syslog.conf файл дотор, дараах мөрийг засах хэрэгтэй:

    ftp.info      /var/log/xferlog

Нийтийн FTP сервер ажиллуулахад тохиолдох болзошгүй асуудлуудын талаар мэдлэгтэй байгаарай. Ялангуяа, нийтийн хэрэглэгчдэд файл байршуулахыг зөвшөөрөх тухайд сайн бодох хэрэгтэй. Таны FTP сайт лицензгүй програм хангамжуудыг наймаалцдаг талбар болох, эсвэл түүнээс ч муу зүйл тохиолдохыг үгүйсгэхгүй. Хэрэв нийтийн FTP байршуулалтыг зөвшөөрөх шаардлагатай бол, файлуудыг нягталж үзэхээс нааш бусад нийтийн хэрэглэгчид тэдгээр файлыг унших эрхгүй байхаар тохируулж өгөх хэрэгтэй.

## 30.9. Microsoft® Windows® харилцагчдад зориулсан Файл болон Хэвлэх Үйлчилгээ (Samba)

### 30.9.1. Ерөнхий Агуулга

Samba бол Microsoft® Windows® харилцагчдад файл болон хэвлэх үйлчилгээг үзүүлдэг, өргөн хэрэглэгддэг нээлттэй эхийн програм хангамжийн багц юм. Ийм төрлийн харилцагчид FreeBSD файлын орчинд холбогдож, файлуудыг өөрийн дискэн дээр байгаа юм шиг, эсвэл FreeBSD хэвлэгчийг өөрийн дотоод хэвлэгч шиг хэрэглэх боломжтой болдог.

Samba програм хангамжийн багцууд таны FreeBSD суулгах дискэнд орсон байгаа. Хэрэв та анх FreeBSD суулгахдаа Samba-г хамт суулгаагүй бол, net/samba34 порт эсвэл багцаас суулгаж болно.

### 30.9.2. Тохиргоо

Samba-н анхдагч тохиргооны файл /usr/local/shared/examples/samba34/smb.conf.default гэж суугдсан байдаг. Энэ файлыг /usr/local/etc/smb.conf нэртэй хуулаад, Samba-г ашиглаж эхлэхээсээ өмнө өөртөө тааруулан засварлах ёстой.

smb.conf файл нь Windows® харилцагчтай хуваалцах хүсэлтэй "файл системийн хэсэг" ба хэвлэгчийн тодорхойлолт гэх зэрэг Samba-н ажиллах үеийн тохиргооны мэдээллийг агуулж байдаг. Samba багц дотор smb.conf файл дээр ажиллах хялбар арга замыг хангасан swat нэртэй вэб дээр суурилсан хэрэгсэл хамт ирдэг.

#### 30.9.2.1. Samba-г Вэбээр Удирдах Хэрэгсэл (SWAT)

Samba Web Administration Tool буюу Samba-г Вэбээр Удирдах Хэрэгсэл (SWAT) нь inetd-н дэмон хэлбэрээр ажиллана. Тиймээс inetd"Супер-Сервер" дээр харуулсан шиг inetd-г идэвхжүүлж Samba-г swat ашиглан тохируулахын өмнө /etc/inetd.conf доторх дараах мөрийг ил гаргах шаардлагатай:

    swat   stream  tcp     nowait/400      root    /usr/local/sbin/swat    swat

inetd-н тохиргооны файлыг дахин ачаалах нь хэсэгт тайлбарласан ёсоор, энэ тохиргооны файлд өөрчлөлт оруулсны дараа inetd-ийн тохиргоог дахин ачаалах шаардлагатай.

swat-г inetd.conf дотор идэвхжүүлсний дараа, вэб хөтөч ашиглан http://localhost:901 хаяганд холбогдоно. Та эхлээд системийн `root` дансаар нэвтэрч орох ёстой.

Samba-н тохиргооны үндсэн хуудсанд амжилттай нэвтэрч орсон бол, системийн баримтуудаар аялах, эсвэл Globals цэсэн дээр дарж тохиргоог хийх боломжтой болно. Globals хэсэг /usr/local/etc/smb.conf файлын `[global]` хэсэгт байгаа хувьсагчдад харгалзана.

#### 30.9.2.2. Глобал тохиргоо

swat-г хэрэглэж байгаа эсвэл /usr/local/etc/smb.conf-г гараараа засаж байгаа аль нь ч бай, Samba-г тохируулах явцад тааралдах хамгийн эхний директивууд бол:

`workgroup`

  Энэ нь сервер рүү хандах компьютеруудын NT Домэйн-Нэр эсвэл Ажлын бүлгийн-Нэр.

`netbios name`

  Энэ директив Samba серверийн NetBIOS нэрийг заана. Анхдагч байдлаар, хостын DNS нэрийн эхний хэсэгтэй адил байна.

`серверийн мөр`

  Энэ директив `net view` тушаалын хариуд гарч ирэх эсвэл зарим сүлжээний хэрэгслүүд дээр энэ серверийг төлөөлж гарах мөрийг заана.

#### 30.9.2.3. Аюулгүй байдлын Тохиргоо

/usr/local/etc/smb.conf доторх хамгийн чухал хоёр тохиргоо бол аюулгүй байдлын загвар, болон харилцагчдын нэвтрэх үгийн арын шугамны хэлбэр юм. Дараах директивүүд эдгээр тохируулгуудыг хянана:

`security`

  Энд хамгийн элбэг хэрэглэгддэг хоёр сонголт бол `security = share` ба `security = user` юм. Хэрэв танай харилцагч нар FreeBSD машин дээр хэрэглэдэг хэрэглэгчийн нэртэй ижил нэрийг ашигладаг бол, user түвшний аюулгүй байдлыг сонгохыг хүсэж байж магадгүй. Энэ бол аюулгүй байдлын анхдагч бодлого бөгөөд эх үүсвэрт хандахаас өмнө харилцагчийг системд нэвтэрч орохыг шаардана.

  share түвшний аюулгүй байдалд, харилцагчид эх үүсвэрт хандахаас өмнө хүчин төгөлдөр хэрэглэгчийн нэр болон нэвтрэх үгээр сервер рүү нэвтрэн орох шаардлагагүй байдаг. Энэ бол Samba-н хуучин хувилбаруудын хувьд аюулгүй байдлын анхдагч загвар байсан.

`passdb backend`

  + Samba-д хэд хэдэн төрлийн арын шугамны магадлах загварууд байдаг. Харилцагчдыг LDAP, NIS, SQL өгөгдлийн сан, эсвэл хувиргасан нэвтрэх үгийн файлаар магадлаж болно. Анхдагч магадлах арга бол `smbpasswd` бөгөөд бид зөвхөн энэ талаар авч үзэх болно.

Анхдагч `smbpasswd` арын шугамыг хэрэглэж байгаа гэж үзвэл, Samba харилцагчдыг магадлахын тулд /usr/local/etc/samba/smbpasswd файлыг эхлээд үүсгэх ёстой. Хэрэв UNIX® хэрэглэгчийн эрхээр Windows® харилцагчаас ханддаг байх шаардлагатай бол, дараах тушаалыг хэрэглэнэ:

    # smbpasswd -a username

| Энэ үед санал болгодог арын мэдээллийн сан нь `tdbsam` бөгөөд хэрэглэгчийн бүртгэлийг нэмэхийн тулд дараах тушаалыг ашиглах ёстой:
    # pdbedit -a -u username

Тохируулгуудын талаар нэмэлт мэдээллийг Албан ёсны Samba HOWTO-с олж авна уу. Энд цухас дурдсан үндсэн мэдлэгтэйгээр Samba-г ажиллуулж эхлэх чадвартай байх ёстой.

### 30.9.3. Samba-г Эхлүүлэх нь

net/samba34 портод Samba-г удирдахад зориулсан шинэ эхлэл скрипт орсон байгаа. Энэ скриптийг идэвхжүүлэхийн тулд, өөрөөр хэлбэл энэ скриптийг ашиглан Samba-г эхлүүлэх, зогсоох болон дахин эхлүүлдэг болохын тулд, /etc/rc.conf файл дотор дараах мөрийг нэмж бичих хэрэгтэй:

    samba_enable="YES"

Эсвэл илүү нарийнаар доор дурдсан шиг тохируулж болно:

    nmbd_enable="YES"

    smbd_enable="YES"

| Ингэснээр мөн Samba-г систем ачаалах үед автоматаар эхлүүлдэг болгоно.

Үүний дараа хүссэн үедээ Samba-г эхлүүлэхийн тулд дараах тушаалыг өгөхөд хангалттай:

    # service samba start
    Starting SAMBA: removing stale tdbs :
    Starting nmbd.
    Starting smbd.

rc скриптийг ашиглах талаар дэлгэрэнгүй мэдээллийг FreeBSD дээр rc(8) ашиглах нь хэсгээс авна уу.

Samba нь үнэн хэрэгтээ гурван тусдаа дэмоноос тогтоно. nmbd ба smbd дэмонууд samba скриптээр эхлүүлдэг болохыг та анзаарах болно. Хэрэв smb.conf дотор winbind нэр тайлах үйлчилгээг идэвхжүүлсэн бол winbindd дэмон бас ажиллаж эхэлсэн болохыг харж болно.

Samba-г хүссэн үедээ зогсоохын тулд дараах тушаалыг өгөхөд хангалттай:

    # service samba stop

Samba бол Microsoft® Windows® сүлжээтэй өргөн хүрээнд нэгдмэл ажиллах боломжийг олгодог нарийн төвөгтэй програмын цогц юм. Энд тайлбарласан үндсэн суулгацаас хальсан функцуудын талаар дэлгэрэнгүй мэдээллийг http://www.samba.org хаягаар орж авна уу.

## 30.10. ntpd-р Цаг Тааруулах нь

### 30.10.1. Ерөнхий Агуулга

Цаг хугацаа өнгөрөхөд компьютерийн цаг зөрөх хандлагатай байдаг. Network Time Protocol буюу Сүлжээний Цагийн Протоколыг(NTP) цагийг зөв байлгах, зөв ажиллуулахад хэрэглэдэг.

Олон тооны Интернэт үйлчилгээнүүд компьютерийн цагаас хамаарч, эсвэл хүртэж ажилладаг. Жишээлбэл, вэб сервер тодорхой цагаас хойш өөрчлөлт орсон файлуудыг илгээх хүсэлт хүлээн авсан байж болох юм. Дотоод сүлжээний орчинд, нэг файл серверээр үйлчлүүлж байгаа компьютеруудын хувьд файлын цагийн тамга дүйж байхын тулд тэдгээрийн цагууд хоорондоо тохирч байх ёстой. cron(8) зэрэг үйлчилгээнүүд тодорхой цагт тушаалыг гүйцэтгэхийн тулд системийн цагт бүрэн найдаж ажилладаг.

FreeBSD ntpd(8) NTP серверийн хамт ирдэг. ntpd(8) NTP нь таны машины цагийг тааруулахын тулд бусад NTP серверүүдээс асуух эсвэл бусдад цагийн мэдээллийг түгээх үйлчилгээг үзүүлдэг.

### 30.10.2. Зохимжтой NTP Серверийг Сонгох нь

Цагаа тааруулахын тулд, та нэг болон түүнээс дээш тооны NTP серверийг хэрэглэх хэрэгтэй болно. Танай сүлжээний администратор эсвэл ISP үүнд зориулсан NTP сервертэй байж болох юм-тийм эсэхийг тэдний заавраас шалгана уу. нийтэд зориулсан NTP серверүүдийн онлайн жагсаалтыг ашиглан өөртөө ойрхон байгаа NTP серверийг олно уу. Сонгож авсан серверийнхээ ашиглах журмыг судлаарай. Мөн хэрэв шаардлагатай бол зөвшөөрөл аваарай.

Таны сонгосон сервер холбогдох боломжгүй, эсвэл цаг нь бүрэн итгэж болохооргүй үе гарах тул, хоорондоо хамааралгүй хэд хэдэн NTP серверүүдийг сонгох нь хамгийн зөв сонголт болдог. ntpd(8) бусад серверээс хүлээн авсан хариултуудыг маш ухаалгаар хэрэглэдэг-итгэж болох серверүүдийг илүү авч үздэг.

### 30.10.3. Өөрийн Машиныг Тохируулах нь

#### 30.10.3.1. Үндсэн Тохиргоо

Хэрэв та машин асахад цагаа тааруулах хүсэлтэй байгаа бол, ntpdate(8)-г ашиглаж болно. Энэ нь олон дахин тааруулах шаардлагагүй, ойр ойрхон асааж унтраадаг ширээний компьютерийн хувьд зохимжтой байж болох юм. Гэхдээ ихэнх машины хувьд ntpd(8)-г ажиллуулах нь зүйтэй.

Систем ачаалах үед ntpdate(8)-г ашиглах нь ntpd(8) ажиллаж байгаа машинуудын хувьд зөв санаа юм. Учир нь ntpd(8) програм нь цагийг алгуур өөрчилдөг байхад, ntpdate(8) машины одоогийн цаг болон зөв цагын хооронд хир их ялгаа байгааг үл хайхран цагийг тааруулдаг.

ntpdate(8)-г систем ачаалах үед идэвхжүүлэхийн тулд, `ntpdate_enable="YES"` гэсэн мөрийг /etc/rc.conf файлд нэмэх хэрэгтэй. Мөн цаг авах гэж байгаа бүх серверүүд болон ntpdate(8)-д өгөх тугуудыг `ntpdate_flags`-д зааж өгөх хэрэгтэй.

#### 30.10.3.2. Ерөнхий Тохиргоо

NTP-г /etc/ntp.conf файлын тусламжтай, ntp.conf(5)-д заасан хэлбэрээр тохируулна. Доор хялбар жишээг үзүүлэв:

    server ntplocal.example.com prefer
    server timeserver.example.org
    server ntp2a.example.net

    driftfile /var/db/ntp.drift

`server` тохируулгаар ямар серверүүдийг ашиглахыг заана. Нэг мөрөнд нэг серверийг бичнэ. Хэрэв аль нэг серверийг `prefer` гэсэн аргументаар онцолсон бол, `ntplocal.example.com` шиг, тэр серверийг бусдаас илүүд үзнэ. Илүүд үзсэн серверээс ирсэн хариу бусад серверүүдийн хариунаас мэдэгдэхүйцээр зөрж байгаа үед хариуг тоохгүй өнгөрөөнө. Түүнээс бусад тохиолдолд бусад серверийн хариуг үл харгалзан тэр серверийн хариуг хэрэглэх болно. `prefer` аргументийг ер нь өндөр нарийвчлалтай, тусгай цаг хянадаг тоног төхөөрөмж дээр тулгуурласан NTP серверийн хувьд хэрэглэнэ.

`driftfile` тохируулгаар ямар файлд системийн цагийн алдах зөрүү утгыг хадгалж байгааг заана. ntpd(8) програм энэ утгыг ашиглан цагийн алдсан зөрүүг автоматаар нөхнө. Ингэснээр цагийн бүх гадаад эх үүсвэрүүдтэй холбоо тогтоох боломжгүй болсон үед, хэсэг хугацааны туршид ч гэсэн цагийг харьцангуй зөв ажиллуулах боломжийг олгоно.

`driftfile` тохируулгаар ямар файлд таны зааж өгсөн NTP серверүүдийн өмнөх хариунуудын тухай мэдээллийг хадгалж байгааг заана. Энэ файлд NTP-н дотоод үйл ажиллагааны мэдээллийг хадгалдаг. Энэ мэдээллийг өөр ямар ч процесс өөрчлөх ёсгүй.

#### 30.10.3.3. Өөрийн Сервер рүү Хандах Хандалтыг Хянах нь

Анхдагч байдлаар, таны NTP сервер рүү Интернэтэд байгаа бүх хост хандах боломжтой. /etc/ntp.conf файл дотор `restrict` тохируулгаар ямар машинууд таны сервер рүү хандаж болохыг хянаж болно.

Хэрэв та өөрийн NTP сервер рүү хэнийг ч хандуулахыг хүсэхгүй байгаа бол /etc/ntp.conf файл дотор дараах мөрийг нэмэх хэрэгтэй:

    restrict default ignore

| Энэ нь таны серверээс өөрийн чинь локал тохиргоонд жагсаагдсан аль ч сервер үрүү хандах боломжийг бас хаана. Хэрэв та өөрийн NTP серверийг гадаад NTP сервертэй синхрончлох хэрэгтэй бол ямар нэг серверийг зөвшөөрөх ёстой. Дэлгэрэнгүй мэдээллийг ntp.conf(5) гарын авлагаас үзнэ үү.

Хэрэв та зөвхөн өөрийн сүлжээнд байгаа машинуудыг таны сервертэй цагаа тааруулахыг зөвшөөрөөд, гэхдээ таны серверийн тохиргоог өөрчлөх болон тэгш эрхтэй серверүүд шиг цагийн мэдээллийг хуваахыг зөвшөөрөхгүй бол дээр дурдсаны оронд:

    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

гэсэн мөрийг бичнэ үү. Энд `192.168.1.0` нь таны сүлжээний IP хаяг, `255.255.255.0` нь таны сүлжээний баг болно.

/etc/ntp.conf дотор олон тооны `restrict` тохируулгууд байж болно. Илүү дэлгэрэнгүй мэдээллийг ntp.conf(5)-н `Хандалтыг Удирдах Дэмжлэг` дэд хэсгээс үзнэ үү.

### 30.10.4. NTP Серверийг Ажиллуулах нь

NTP серверийг систем ачаалах үед эхлүүлэхийн тулд, `ntpd_enable="YES"` гэсэн мөрийг /etc/rc.conf файлд нэмж бичих хэрэгтэй. Хэрэв ntpd(8)-д нэмэлт тугуудыг өгөх хүсэлтэй бол, /etc/rc.conf файлд байгаа `ntpd_flags` параметрийг засах хэрэгтэй.

Машиныг дахин ачаалалгүйгээр серверийг эхлүүлэхийн тулд, `ntpd` тушаалыг /etc/rc.conf-д заасан `ntpd_flags` нэмэлт параметрүүдийн хамтаар өгөх хэрэгтэй. Жишээлбэл:

    # ntpd -p /var/run/ntpd.pid

### 30.10.5. ntpd-г Түр зуурын Интернэт Холболттой үед Хэрэглэх нь

ntpd(8) програм зөв ажиллахын тулд байнгын Интернэт холболт шаардлагагүй. Гэхдээ, хэрэгцээтэй үедээ гадагшаа залгадаг тийм төрлийн түр зуурын холболттой бол, NTP трафикийг гадагшаа залгах болон холболтыг бариад байхаас сэргийлэх нь чухал. Хэрэв та PPP хэрэглэдэг бол, /etc/ppp/ppp.conf файл дотор байгаа `filter` директивийг ашиглаж болно. Жишээ нь:

     set filter dial 0 deny udp src eq 123
     # Prevent NTP traffic from initiating dial out
     set filter dial 1 permit 0 0
     set filter alive 0 deny udp src eq 123
     # Prevent incoming NTP traffic from keeping the connection open
     set filter alive 1 deny udp dst eq 123
     # Prevent outgoing NTP traffic from keeping the connection open
     set filter alive 2 permit 0/0 0/0

Дэлгэрэнгүй мэдээллийг ppp(8)-н `PACKET FILTERING` хэсгээс болон /usr/shared/examples/ppp/-д байгаа жишээнүүдээс авч болно.

| Зарим Интернэт үйлчилгээ үзүүлэгчид бага дугаартай портуудыг хаасан байдаг бөгөөд ингэснээр хариу нь таны машинд хэзээ ч хүрэхгүй болж NTP ажиллахгүй болдог.

### 30.10.6. Цааших Мэдээлэл

NTP серверийн баримтжуулалтыг HTML хэлбэрээр /usr/shared/doc/ntp/-с олж үзэж болно.

## 30.11. `syslogd` ашиглан алсын хост руу бүртгэх нь

Системийн бүртгэлтэй ажиллах нь аюулгүй байдлын болоод системийг удирдах ажиллагааны чухал асуудал юм. Хостууд дунд зэргийн эсвэл том сүлжээнд тархсан эсвэл тэдгээр нь төрөл бүрийн олон янзын сүлжээний хэсэг болсон байх тохиолдолд эдгээр олон хостын бүртгэлийн файлуудыг монитор хийх нь ихээхэн төвөгтэй болдог. Энэ тохиолдолд алсаас бүртгэхийг тохируулах нь бүх л процессийг илүү тухтай болгодог.

Тусгайлан заасан бүртгэх хост руу төвлөрүүлэн бүртгэх нь бүртгэлийн файлын удирдлагатай холбоотой зарим хүндрэлүүдийг багасгаж чаддаг. syslogd(8) болон newsyslog(8) зэрэг FreeBSD-ийн эх хэрэгслүүдийг ашиглан бүртгэлийн файлын цуглуулга, нийлүүлэлт болон багасгалтыг нэг газар тохируулж болдог. Дараах жишээ тохиргоонд `logserv.example.com` гэж нэрлэгдсэн хост `A` локал сүлжээнээс бүртгэлийн мэдээллийг цуглуулах болно. `logclient.example.com` гэж нэрлэгдсэн хост `B` бүртгэлийн мэдээллийг сервер систем рүү дамжуулах болно. Жинхэнэ тохиргоонд эдгээр хостууд зохих дамжуулах болон буцах DNS эсвэл /etc/hosts файлд оруулгууд шаардана. Тэгэхгүй бол өгөгдлийг сервер хүлээн авахгүй татгалзах болно.

### 30.11.1. Бүртгэлийн серверийн тохиргоо

Бүртгэлийн серверүүд нь алсын хостуудаас бүртгэлийн мэдээллийг хүлээн авахаар тохируулагдсан машинууд юм. Ихэнх тохиолдолд энэ нь тохиргоог хялбар болгох зорилготой бөгөөд зарим тохиолдолд энэ нь удирдлагыг арай сайжруулж байгаа хэлбэр байж болох юм. Аль ч шалтгаан байсан гэсэн үргэлжлүүлэхээсээ өмнө цөөн хэдэн шаардлагыг дурдъя.

Зөв тохируулсан бүртгэлийн сервер дараах хамгийн бага шаардлагыг хангасан байх шаардлагатай:

- Клиент болон сервер дээр 514-р порт руу UDP-г дамжуулах боломжийг бүрдүүлэх галт хананы дүрэм;

- Клиент машинаас алсын мэдэгдлүүдийг хүлээн авахаар syslogd тохируулагдсан байх;

- syslogd сервер болон бүх клиент машинууд нь дамжуулах болон буцах DNS-ийн хувьд зөв оруулгуудтай эсвэл /etc/hosts файлд зөв тохируулсан байх шаардлагатай.

Бүртгэлийн серверийг тохируулахын тулд клиент нь /etc/syslog.conf-д нэмэгдсэн байх ёстой бөгөөд бүртгэх боломжийг зааж өгсөн байх шаардлагатай:

    +logclient.example.com
    *.*     /var/log/logclient.log

| Төрөл бүрийн дэмжигдсэн, байгаа facility буюу боломжуудын талаарх дэлгэрэнгүй мэдээллийг syslog.conf(5) гарын авлагын хуудаснаас олж болно.

Нэмсэний дараа бүх `facility` мэдэгдлүүд өмнө заасан /var/log/logclient.log файл руу бүртгэгдэх болно.

Сервер машин дараах тохиргоог бас /etc/rc.conf файлдаа хийсэн байх шаардлагатай:

    syslogd_enable="YES"
    syslogd_flags="-a logclient.example.com -v -v"

Эхний тохиргоо нь `syslogd` демоныг эхлүүлэхийг заах бөгөөд хоёр дахь нь клиетийн өгөгдлийг энэ сервер дээр хүлээн авахыг зөвшөөрнө. Сүүлийн `-v -v` хэсэг нь бүртгэж байгаа мэдэгдлүүдийн гаралтыг илүү дэлгэрэнгүй болгоно. Энэ нь facility-г тохируулахад ихээхэн ашигтай байдаг. Администраторууд ямар төрлийн мэдэгдлүүд ямар facility-р бүртгэгдэж байгааг хянах боломжийг энэ нь бүрдүүлдэг.

Олон клиентээс бүртгэлийг хүлээн авахын тулд олон `-a` сонголтыг зааж өгч болно. IP хаягууд болон бүхэл сүлжээний блокийг бас зааж өгч болох бөгөөд боломжит сонголтуудын бүх жагсаалтыг syslog(3) гарын авлагын хуудаснаас үзнэ үү.

Төгсгөлд нь бүртгэлийн файлыг үүсгэх хэрэгтэй. Хэрэглэгсэн арга нь хамаагүй боловч touch(1) үүнтэй адил тохиолдлуудад сайн ажилладаг:

    # touch /var/log/logclient.log

Энэ үед `syslogd` демоныг дахин ажиллуулж шалгах ёстой:

    # service syslogd restart
    # pgrep syslog

Хэрэв PID буцаагдвал сервер нь амжилттай дахин эхэлсэн гэсэн үг бөгөөд клиентийн тохиргоо ажиллаж эхэлнэ. Хэрэв сервер дахин эхлээгүй бол ямар нэг зүйл болсон эсэхийг /var/log/messages файл дахь мэдэгдлүүдээс шалгаарай.

### 30.11.2. Клиентийн бүртгэлийн тохиргоо

Бүртгэл илгээгч клиент нь өөр дээрээ хуулбараа үлдээхээс гадна бас бүртгэлийн сервер рүү бүртгэлийн мэдээллийг явуулдаг машин юм.

Бүртгэлийн серверүүдийн нэгэн адил клиентүүд нь бас хамгийн бага шаардлагыг хангасан байх ёстой:

- syslogd(8) нь бүртгэлийн сервер хүлээн авах ёстой заасан төрлийн мэдэгдлүүдийг бүртгэлийн сервер рүү илгээхээр тохируулагдсан байх ёстой;

- Галт хана UDP пакетуудыг 514-р порт руу зөвшөөрөх ёстой;

- Дамжуулах болон буцах DNS тохируулагдсан эсвэл /etc/hosts файл зохих оруулгуудтай байх шаардлагатай.

Клиентийн тохиргоо нь серверийнхтэй харьцуулах юм бол арай зөөлөн байдаг. Клиент машин нь /etc/rc.conf файлдаа дараахийг нэмж өгсөн байх шаардлагатай байдаг:

    syslogd_enable="YES"
    syslogd_flags="-s -v -v"

Өмнө дурдсаны адил эдгээр тохиргоонууд нь `syslogd` демоныг ачаалж эхлэхэд эхлүүлэхийг заах бөгөөд бүртгэх мэдэгдлүүдийг дэлгэрэнгүйгээр харуулах болно. `-s` сонголт нь бусад хостуудаас бүртгэлийг энэ клиент хүлээн авахаас сэргийлдэг.

Facility нь мэдэгдэл үүсгэгдэж байгаа тэр системийн хэсгийг тайлбарладаг. Жишээ нь ftp болон ipfw нь хоёулаа facility юм. Эдгээр хоёр үйлчилгээний хувьд бүртгэлийн мэдэгдлүүд үүсэхэд ихэвчлэн дээрх хоёр хэрэгслийг бүртгэлийн мэдэгдэл бүртээ агуулсан байдаг. Facility нь бүртгэлийн мэдэгдэл ямар чухлыг тэмдэглэхэд хэрэглэгдэх дараалал эсвэл түвшинтэй байдаг. Хамгийн түгээмэл нь `warning` ба `info` юм. Боломжит бүх facilty болон дарааллуудын жагсаалтыг syslog(3) гарын авлагын хуудаснаас үзнэ үү.

Бүртгэлийн серверийг клиентийн /etc/syslog.conf файлд заасан байх шаардлагатай. Энэ жишээн дээр алсын сервер рүү бүртгэлийн өгөгдлийг илгээхийн тулд `@` тэмдгийг ашигласан бөгөөд доор дурдсан мөртэй төстэй харагдана:

    *.*		@logserv.example.com

Нэмсэний дараа өөрчлөлтийг хүчинтэй болгохын тулд `syslogd`-г дахин эхлүүлэх шаардлагатай:

    # service syslogd restart

Сүлжээгээр бүртгэлийн мэдэгдлүүдийг илгээж байгаа эсэхийг тест хийхийн тулд клиент дээр logger(1)-г ашиглаж мэдэгдлийг `syslogd` руу илгээнэ:

    # logger "Test message from logclient"

Энэ мэдэгдэл клиент дээрх /var/log/messages болон сервер дээрх /var/log/logclient.log файлд одоо орсон байх ёстой.

### 30.11.3. Бүртгэлийн серверүүдийг дибаг хийх

Зарим тохиолдолд хэрэв бүртгэлийн сервер дээр мэдэгдлүүд нь хүлээн авагдаагүй бол дибаг хийх шаардлагатай байж болох юм. Хэд хэдэн шалтгаанаас болж ийм байдалд хүрч болох юм. Хамгийн түгээмэл хоёр нь сүлжээний холболтын болон DNS-тэй холбоотой асуудлууд юм. Эдгээр тохиолдлуудыг тест хийхийн тулд хоёр хост хоёулаа /etc/rc.conf файлд заагдсан хостын нэрээрээ нэг нэгэн рүүгээ хүрч чадаж байгааг шалгах хэрэгтэй. Хэрэв энэ зөв ажиллаж байгаа бол /etc/rc.conf файлд `syslogd_flags` тохиргоог өөрчлөх шаардлагатай болно.

Дараах жишээн дээр /var/log/logclient.log нь хоосон бөгөөд /var/log/messages файл нь амжилтгүй болсон шалтгааныг харуулна. Дибаг хийж байгаа гаралтыг илүү дэлгэрэнгүй харуулахын тулд дараах жишээтэй төстэйгөөр `syslogd_flags` тохируулгыг өөрчилж дахин ачаалах хэрэгтэй:

    syslogd_flags="-d -a logclien.example.com -v -v"

    # service syslogd restart

Доор дурдсантай төстэй дибаг өгөгдөл дахин ачаалсны дараа дэлгэц дээр хурдан гарч өнгөрнө:

    logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
    syslogd: restarted
    logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
    Logging to FILE /var/log/messages
    syslogd: kernel boot file is /boot/kernel/kernel
    cvthname(192.168.1.10)
    validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
    rejected in rule 0 due to name mismatch.

Мэдэгдлүүд нэр зөрснөөс болоод дамжихгүй байгааг эндээс харж болно. Тохиргоог алхам алхмаар дахин шалгасны дараа /etc/rc.conf дахь дараах мөр буруу бичигдсэн бөгөөд асуудалтай байгааг олж харна:

    syslogd_flags="-d -a logclien.example.com -v -v"

Энэ мөр `logclien` биш `logclient` гэдгийг агуулсан байх ёстой. Зөв болгож засан дахин ачаалсны дараа хүлээж байсан үр дүнгээ харах болно:

    # service syslogd restart
    logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
    syslogd: restarted
    logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
    syslogd: kernel boot file is /boot/kernel/kernel
    logmsg: pri 166, flags 17, from logserv.example.com,
    msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2
    cvthname(192.168.1.10)
    validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
    accepted in rule 0.
    logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2
    Logging to FILE /var/log/logclient.log
    Logging to FILE /var/log/messages

Энэ үед мэдэгдлүүдийг зөв хүлээн аван зөв файлд бичих болно.

### 30.11.4. Аюулгүй байдлын хувьд бодолцох зүйлс

Сүлжээний аль ч үйлчилгээний нэгэн адил энэ тохиргоог хийхээсээ өмнө аюулгүй байдлын шаардлагуудыг бодолцох ёстой. Заримдаа бүртгэлийн файлууд нь локал хост дээр идэвхжүүлсэн үйлчилгээнүүд, хэрэглэгчдийн бүртгэл болон тохиргооны өгөгдлийн талаарх эмзэг өгөгдлүүдийг агуулсан байж болох юм. Клиентээс сервер рүү илгээсэн сүлжээний өгөгдөл нь шифрлэгдээгүй эсвэл нууц үгээр хамгаалагдаагүй байдаг. Хэрэв шифрлэх шаардлагатай бол өгөгдлийг шифрлэсэн хоолойгоор дамжуулах security/stunnel хэрэгслийг ашиглаж болох юм.

Локал аюулгүй байдал нь бас л асуудал юм. Бүртгэлийн файлууд нь хэрэглэж байхад юм уу эсвэл бүртгэлийн багасгах үед шифрлэгддэггүй. Локал хэрэглэгчид эдгээр файлуудад хандаж системийн тохиргооны талаар нэмэлт мэдээлэл олж авч болох юм. Ийм тохиолдолд эдгээр файлууд дээр зөв зөвшөөрлүүдийг тавих нь чухал юм. newsyslog(8) хэрэгсэл нь шинээр үүсгэгдсэн болон багасгагдсан бүртгэлийн файлууд дээр зөвшөөрөл тавихыг дэмждэг. Бүртгэлийн файлууд дээр `600` горимыг тавьснаар хүсээгүй локал хэрэглэгчид тэдгээрийг шиншлэх боломжийг хаах юм.

Last modified on: 2026 оны зургаадугаар сарын 18 by Alexander Ziaee

Prev
Home
Next