Бүлэг 12. Тохиргоо ба Тааруулалт | FreeBSD Documentation Portal

# Бүлэг 12. Тохиргоо ба Тааруулалт

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

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

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

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

- Файлын системүүд болон хуваалтуудтай хэрхэн үр ашигтай ажиллах талаар.

- rc.conf тохиргоо болон /usr/local/etc/rc.d эхлэлийн системүүдийн үндсүүд.

- Сүлжээний картыг хэрхэн тохиргоо болон тест хийх талаар.

- Сүлжээний төхөөрөмж дээрээ виртуал хостууд хэрхэн тохируулах талаар.

- /etc дэх төрөл бүрийн тохиргооны файлыг хэрхэн ашиглах талаар.

- `sysctl` хувьсагчуудыг ашиглан FreeBSD-ийг хэрхэн тааруулах талаар.

- Дискний хурдан ажиллагааг хэрхэн тааруулах болон цөмийн хязгааруудыг хэрхэн өөрчлөх талаар.

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

- UNIX® болон FreeBSD-ийн үндсийг ойлгох (Юниксийн үндэс).

- Цөмийн тохиргоо/хөрвүүлэлтийн үндсүүдийн талаар ойлголттой байх (FreeBSD цөмийг тохируулах нь).

## 12.2. Эхний Тохиргоо

### 12.2.1. Хуваалтын байрлал

#### 12.2.1.1. Үндсэн Хуваалтууд

bsdlabel(8) болон sysinstall(8) ашиглан файлын системүүдийг байрлуулахдаа хатуу хөтлөгчүүд өгөгдлийг дотоод замуудаас илүү гаднах замуудаас хурдан шилжүүлдгийг санаарай. Тиймээс жижиг, байнга ханддаг файлын системүүд хөтлөгчийн гадна тал уруу ойрхон байх ёстой бөгөөд /usr зэрэг том хуваалтууд дискийн дотор тал уруу байх хэрэгтэй. Хуваалтуудыг иймэрхүү дарааллаар байрлуулах нь зөв юм: root, swap, /var, /usr.

/var хуваалтын хэмжээ төлөвлөсөн машины хэрэглээг тусгадаг. /var файлын систем нь шуудангийн хайрцгууд, бүртгэлийн файлууд, болон принтерийн spool агуулдаг. Шуудангийн хайрцгууд болон бүртгэлийн файлууд хичнээн хэрэглэгч байгаа болон ямар хугацаанд бүртгэлийн файлууд байхаас хамаараад төсөөлөшгүй хэмжээнд хүртэл ихсэж болдог. Ихэнх хэрэглэгчдийн хувьд /var-д нэг гигабайт сул зай байхад хангалттай байдаг.

| /var/tmp-д ихээхэн хэмжээний дискийн зай шаардагддаг цөөхөн тохиолдол байдаг. Шинэ програм хангамжийг pkg_add(1) ашиглан суулгахад багцлах хэрэгслүүд багцын түр зуурын хуулбарыг /var/tmp-д задалдаг. /var/tmp-д хангалттай дискийн чөлөөтэй зай байхгүй бол Firefox, OpenOffice эсвэл LibreOffice зэрэг томоохон програм хангамжийн багцуудыг суулгахад төвөгтэй байж болох юм.

/usr хуваалт ports(7) цуглуулга (байлгахыг зөвлөдөг), болон эх код (заавал биш) зэрэг системийг дэмжихэд шаардлагатай ихэнх файлуудыг агуулдаг. Портууд болон үндсэн системийн эхүүдийг суулгалтын үед сонгох боломжтой боловч бид энэ хуваалтад хамгийн багаар бодоход 2 гигабайт байхыг зөвлөдөг.

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

| sysinstall(8)-ийн `Auto-defaults` хуваалтын хэмжээг өгөгч нь заримдаа /var болон / хуваалтуудад боломжоос бага хэмжээг сонгодгийг зарим хэрэглэгчид олсон байна. Хуваалтыг ухаалгаар харамгүй хийгээрэй.

#### 12.2.1.2. Swap Хуваалт

Swap хуваалтын хэмжээ системийн санах ойг (RAM) хоёр дахин авсан хэмжээтэй байх ёстой. Жишээлбэл машин 128 мегабайт санах ойтой бол swap файл 256 мегабайт байх ёстой. Бага санах ойтой системүүд их swap-тай бол илүү хурдан ажиллаж болох юм. 256 мегабайтаас бага swap-ийг хэрэглэхийг зөвлөдөггүй бөгөөд санах ойн өргөтгөл хэрэгтэй. Цөмийн VM хуудаслах алгоритмууд нь багаар бодоход гол санах ойг хоёр дахин авсантай тэнцэх swap хуваалттай байх үед хамгийн хурдан ажиллахаар тааруулагдсан байдаг. Хэтэрхий бага swap тохируулах нь VM хуудас скан хийх кодыг үр ашиггүйтэлд хүргэж илүү санах ой хожим нэмэхэд асуудал үүсгэж болох юм.

Олон SCSI дискнүүд бүхий (эсвэл олон IDE дискнүүд өөр өөр хянагчууд дээр ажиллаж байгаа) томоохон системүүдэд swap-ийг хөтлөгч болгон дээр (4 хөтлөгч хүртэл) тохируулахыг зөвлөдөг. Swap хуваалтууд нь ойролцоогоор адилхан хэмжээний байх шаардлагатай. Цөм дурын хэмжээтэй ажиллаж чадах боловч дотоод өгөгдлийн бүтцүүд хамгийн том swap хуваалтыг 4 дахин авсантай адил хэмжээгээр томрох боломжтой. Swap хуваалтуудыг ойролцоогоор адил хэмжээтэй байлгах нь swap зайг дискнүүдийн дагуу оновчтойгоор судал үүсгэх боломжийг цөмд олгодог. Swap их ашиглагддаггүй байсан ч гэсэн том swap хэмжээ байж болно. Хүчээр дахин ачаалагдах үед дагаж хаагдсан програмаас өгөгдлийг сэргээх нь амархан байж болох юм.

#### 12.2.1.3. Яагаад Хуваах хэрэгтэй гэж?

Зарим хэрэглэгчид ганц том хуваалт байхад болно гэж боддог, гэхдээ энэ нь яагаад буруу болох хэд хэдэн шалтгаан бий. Нэгдүгээрт хуваалт болгон өөр өөр ажиллагааны шинж чанаруудтай бөгөөд тэдгээрийг тусгаарласнаар файлын системийг тэдгээрт тааруулах боломжийг олгодог. Жишээ нь root болон /usr хуваалтууд байнга бичигдэхээсээ илүү ихэвчлэн уншигддаг. Харин уншилт болон бичилт /var болон /var/tmp-д байнга хийгддэг.

Системийг зөв хувааснаар ачаалалтай хуваалтуудад хийсэн жижиг бичилтээр гарсан хэсэглэлт илүүдэж байнга уншигддаг хуваалтууд уруу хальдаггүй. Бичилт-ачаалсан хуваалтуудыг дискний ирмэг уруу байрлуулах нь бичилт ихэвчлэн хийгддэг хуваалтууд дахь I/O ажиллагааг хурдасгадаг. Том хуваалтуудад I/O-н хурдан ажиллагаа хэрэгтэй байж болох ч тэдгээрийг дискний ирмэг уруу илүүтэй ойртуулах нь /var-ийг ирмэг уруу шилжүүлснээс илүү мэдэгдэхүйц хурдан ажиллагаанд хүргэхгүй. Эцэст нь найдвартай байдлыг бодох ёстой. Ихэвчлэн уншигддаг, жижиг, цэвэрхэн root хуваалт хэцүү сүйрэл болоход сэргэх боломж нь хамаагүй илүү байна.

## 12.3. Гол Тохиргоо

Системийн тохиргооны мэдээлэл /etc/rc.conf дотор байдаг. Энэ файл нь өргөн хүрээний, зарчмын хувьд системийг эхлэх үед системийг тохируулахад ашиглагддаг тохиргооны мэдээллүүдээс тогтоно. Үүний нэр нь шууд утгыг тодорхойлно; энэ нь rc* файлуудад зориулсан тохиргооны мэдээлэл юм.

Администратор /etc/defaults/rc.conf-ийн анхдагч утгуудыг rc.conf файлд өөрчилж оруулах хэрэгтэй. Анхдагчуудын файл /etc уруу хуулагдах ёсгүй - энэ нь жишээ биш анхдагч утгуудыг агуулдаг. Бүх системийн холбогдолтой өөрчлөлтүүд rc.conf файлд өөрт нь хийгдэх ёстой.

Удирдлагын нэмэлт ачааллыг байнга бага байлгахын тулд сайт дагуух тохиргоог системийн тусгайлсан тохиргооноос тусгаарлах хэд хэдэн стратеги кластер хийгдсэн програмуудад байж болох юм. Тухайн системийн тохиргоог /etc/rc.conf.local файлд байрлуулах нь зүйтэй. Жишээ нь:

- /etc/rc.conf:

      sshd_enable="YES"
      keyrate="fast"
      defaultrouter="10.1.1.254"

- /etc/rc.conf.local:

      hostname="node1.example.org"
      ifconfig_fxp0="inet 10.1.1.1/8"

Дараа нь rc.conf файл систем болгонд `rsync` эсвэл адил програмаар түгээгдэж болох бөгөөд харин rc.conf.local файл нь өөр өөр хэвээр байх болно.

sysinstall(8) эсвэл `make world` ашиглан системийг шинэчлэхэд rc.conf файлыг дарж бичихгүй, тэгэхээр системийн тохиргооны мэдээлэл хаягдахгүй.

| /etc/rc.conf тохиргооны файлыг sh(1)-р уншуулдаг. Энэ нь системийн операторуудад уг файлд тодорхой хэмжээний логик нэмэх боломжийг олгодог бөгөөд ингэснээр илүү нарийн төвөгтэй тохиргооны хувилбарууд үүсгэхэд тусалдаг. Энэ талаар дэлгэрэнгүйг rc.conf(5)-с үзнэ үү.

## 12.4. Програмын Тохиргоо

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

Ерөнхийдөө эдгээр файлууд нь /usr/local/etc дотор суулгагддаг. Програм их олон тооны тохиргооны файлуудтай тохиолдолд тэдгээрийг агуулж дэд сан үүсгэгдэнэ.

Ихэнхдээ порт эсвэл багц суухад жишээ тохиргооны файлууд бас суудаг. Эдгээр нь ихэнхдээ .default дагавраар танигддаг. Хэрэв програмын хувьд тохиргооны файлууд байхгүй байвал тэдгээрийг .default файлуудыг хуулж үүсгэнэ.

Жишээ нь /usr/local/etc/apache санд байгаа файлуудыг үзье:

    -rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf
    -rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf.default
    -rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf
    -rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf.default
    -rw-r--r--  1 root  wheel  12205 May 20  1998 magic
    -rw-r--r--  1 root  wheel  12205 May 20  1998 magic.default
    -rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types
    -rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types.default
    -rw-r--r--  1 root  wheel   7980 May 20  1998 srm.conf
    -rw-r--r--  1 root  wheel   7933 May 20  1998 srm.conf.default

Файлын хэмжээнүүд нь зөвхөн srm.conf файл өөрчлөгдсөнийг харуулж байна. Apache портын дараагийн шинэчлэл энэ өөрчлөгдсөн файлыг дарж хуулахгүй.

## 12.5. Үйлчилгээнүүдийг эхлүүлэх нь

Олон хэрэглэгчид Портуудын Цуглуулгаас гуравдагч програм хангамжуудыг FreeBSD дээр суулгахаар сонгодог. Ихэнх тохиолдолд програм хангамжийг систем ачаалахад эхлүүлэхээр тохируулах шаардлагатай байж болох юм. mail/postfix эсвэл www/apache22 зэрэг үйлчилгээнүүд нь системийг ачаалахад эхлүүлж болох програм хангамжийн багцуудын зөвхөн хоёрхон жишээ юм. Энэ хэсэгт гуравдагч програм хангамжийг ажиллуулах процедурын талаар тайлбарлах болно.

FreeBSD дээр cron(8) зэрэг ихэнх үйлчилгээнүүд системийн эхлүүлэх скриптүүдийн тусламжтай эхэлдэг. Эдгээр скриптүүд FreeBSD эсвэл үйлдвэрлэгчийн хувилбараас хамааран өөр өөр байна; гэхдээ хамгийн чухал авч үзэх зүйл нь тэдгээрийн эхлэх тохиргоог энгийн эхлүүлэх скриптүүдээр хийх боломжтой явдал юм.

### 12.5.1. Програмын Өргөтгөсөн Тохиргоо

Одоогийн FreeBSD-ийн rc.d-г агуулдаг нь програмын эхлүүлэх тохиргоог илүү хялбар, боломжтой болгосон. rc.d хэсэгт хэлэлцсэн түлхүүр үгүүдийг ашиглан програмууд жишээ нь DNS зэрэг зарим үйлчилгээнүүдийн дараа ажиллахаар тохируулагдаж болно; эхлүүлэх скриптүүдэд хатуугаар бичигдсэн тугуудын оронд rc.conf-оор нэмэлт тугуудыг өгөхийг зөвшөөрч болох гэх мэт. Үндсэн скрипт дараах байдлаар харагдаж болно:

    #!/bin/sh
    #
    # PROVIDE: utility
    # REQUIRE: DAEMON
    # KEYWORD: shutdown

    . /etc/rc.subr

    name="utility"
    rcvar=utility_enable
    command="/usr/local/sbin/utility"

    load_rc_config $name

    #
    # DO NOT CHANGE THESE DEFAULT VALUES HERE
    # SET THEM IN THE /etc/rc.conf FILE
    #
    utility_enable=${utility_enable-"NO"}
    pidfile=${utility_pidfile-"/var/run/utility.pid"}

    run_rc_command "$1"

Энэ скрипт нь өгөгдсөн utility-г `DAEMON` псевдо үйлчилгээний дараа ажиллуулахаар тохируулагдсан. Мөн PID, эсвэл процессийн ID файлыг заах болон дагах аргыг бас хангадаг.

Энэ програм дараах мөрийг /etc/rc.conf файлд оруулж болно:

    utility_enable="YES"

Энэхүү арга нь тушаалын мөрийн нэмэлт өгөгдлүүдийг илүү хялбараар удирдах боломжийг зөвшөөрдөг бөгөөд /etc/rc.subr дахь анхдагч функцуудыг оруулах, rcorder(8) хэрэгсэлтэй нийцтэй байх, болон rc.conf файлын тусламжтай хялбараар тохиргоо хийх боломжийг бас хангадаг.

### 12.5.2. Үйлчилгээнүүдийг эхлүүлэхийн тулд үйлчилгээнүүдийг ашиглах нь

POP3 сервер дэмонууд, IMAP зэрэг бусад үйлчилгээнүүд inetd(8) ашиглан эхэлж болдог. Энэ нь Портуудын Цуглуулгаас /etc/inetd.conf файлд нэмэгдэх мөр бүхий эсвэл одоогийн байгаа мөрүүдийн нэгнээс тайлбарыг болиулж идэвхжүүлдэг үйлчилгээний хэрэгслийг суулгаснаар хэрэгждэг. inetd болон түүний тохиргоотой ажиллах талаар inetd хэсэгт гүнзгий тайлбарласан байгаа болно.

Зарим тохиолдолд cron(8) ашиглан системийн үйлчилгээнүүдийг эхлүүлэх нь илүү ашигтай байж болох юм. Энэ арга нь хэд хэдэн давуу талуудтай бөгөөд учир нь `cron` эдгээр процессуудыг crontab-н файлын эзэмшигчийн эрхээр ажиллуулдаг. Энэ нь ердийн хэрэглэгчдэд зарим програмуудыг эхлүүлж ажиллагааг хангах боломжийг олгодог.

`cron` хэрэгсэл `@reboot` гэсэн бусдад байхгүй боломжийг олгодог бөгөөд цаг хугацааг заах хэсэгт ашиглагдах боломжтой. Энэ нь системийг эхлүүлэх явцад cron(8) эхлэх үед тухайн ажлыг ажиллуулдаг.

## 12.6. `cron` хэрэгслийг тохируулах нь

FreeBSD-ийн хамгийн ашигтай хэрэгслүүдийн нэг нь cron(8) юм. `cron` хэрэгсэл ард ажилладаг бөгөөд /etc/crontab файлыг байнга шалгаж байдаг. `cron` хэрэгсэл /var/cron/tabs сангаас шинэ crontab файлуудыг бас шалгадаг. Эдгээр crontab файлууд нь тусгай функцуудыг агуулдаг бөгөөд эдгээрийг `cron` тодорхой хугацаанд ажиллуулах ёстой байдаг.

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

| Хэрэглэгчийн crontab-ууд нь хэрэглэгчдэд `root` эрхийн шаардлагагүйгээр бодлогуудыг цагийн хуваариар ажиллуулах боломж олгодог. Хэрэглэгчийн crontab дахь тушаалууд нь crontab-ийг эзэмшиж байгаа хэрэглэгчийн эрхээр ажилладаг. `root` хэрэглэгч бас бусад хэрэглэгчийн нэгэн адил хэрэглэгчийн crontab-тай байж болно. `root` хэрэглэгчийн crontab нь /etc/crontab-аас (системийн crontab) тусдаа байна. Яагаад гэвэл системийн crontab нь заасан тушаалуудыг root эрхээр ажиллуулдаг учраас `root` хэрэглэгчийн хувьд ихэнхдээ хэрэглэгчийн crontab шаардлагагүй байдаг.

Системийн crontab /etc/crontab файлыг харцгаая:

    # /etc/crontab - root's crontab for FreeBSD
    #
    # $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $
    #(1)
    #
    SHELL=/bin/sh
    PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin (2)
    HOME=/var/log
    #
    #
    #minute	hour	mday	month	wday	who	command (3)
    #
    #
    */5	*	*	*	*	root	/usr/libexec/atrun (4)

1 | FreeBSD-ийн ихэнх тохиргооны файлуудын адил `#` тэмдэгтээр эхэлсэн мөрүүд тайлбар юм. Тайлбарыг хүсэж байгаа үйлдэл нь юу болох яагаад хийгдэж байгааг сануулах зорилгоор файлд тавьж болдог. Тайлбаруудыг тушаал байгаа мөрд хийж болохгүй бөгөөд ингэсэн тохиолдолд тушаалын хэсэг мэтээр ойлгогдоно; тэдгээр нь шинэ мөрөнд байх ёстой. Хоосон мөрүүдийг тооцохгүй.
2 | Эхлээд орчин тодорхойлогдох шаардлагатай. Тэнцүүгийн (`=`) тэмдэг орчны тохиргоог тодорхойлоход ашиглагддаг бөгөөд энэ жишээн дээр `SHELL`,`PATH`, болон `HOME` тохируулгуудад ашиглагдаж байна. Хэрэв бүрхүүлийн мөрийг орхисон бол `cron` анхдагч болох `sh`-ийг ашигладаг. Хэрэв `PATH` хувьсагчийг орхисон бол ямар ч анхдагч ашиглагдахгүй бөгөөд файлын байрлалууд абсолют байх хэрэгтэй. Хэрэв `HOME` мөрийг орхисон бол `cron` ажиллуулж байгаа хэрэглэгчийн гэрийн санг ашигладаг.
3 | Энэ мөр нь нийт долоон талбарыг тодорхойлдог. Энд жагсаагдсан утгууд нь `minute`, `hour`, `mday`, `month`, `wday`, `who`, болон `command` юм. Эдгээрийг нэрээс нь харахад ойлгомжтой. `minute` нь тушаал ажиллах минутаар илэрхийлэгдсэн хугацаа. `hour` нь `minute`-ын адил тохируулга бөгөөд цагаар илэрхийлэгддэг. `mday` нь сарын өдрийг заана. `month` нь `hour` болон `minute`-тай адил бөгөөд сарыг зааж өгнө. `wday` тохируулга нь долоо хоногийн өдрийг заана. Эдгээр бүх талбарууд нь тоон утга байх ёстой бөгөөд хорин дөрвөн цагийг дагадаг. `who` талбар нь тусгай бөгөөд зөвхөн /etc/crontab файлд байдаг. Энэ талбар нь аль хэрэглэгчийн эрхээр тушаал ажиллахыг заадаг. Сүүлийн талбар нь ажиллуулах тушаалд зориулагдсан байна.
4 | Энэ сүүлийн мөр нь дээр дурдсан утгуудыг тодорхойлдог. Энд бид хэд хэдэн `` тэмдэгтүүд дараалсан ```/5` гэсэн жагсаалт байгааг анзаарах хэрэгтэй. Эдгээр `*` тэмдэгтүүд нь "эхний-эцсийн" гэсэн үг бөгөөд үргэлж гэж ойлгогдож болно. Тэгвэл энэ мөрөөс үзэхэд `atrun` тушаал нь `root` эрхээр 5 минут тутам аль өдөр сар байгаагаас үл хамааран ажиллана. `atrun` тушаалын талаар дэлгэрэнгүй мэдээллийг atrun(8) гарын авлагаас үзнэ үү.Тушаалууд тэдгээрт өгч болох дурын тооны тугуудтай байж болно; гэхдээ олон мөр болон уртассан тушаалууд урагшаа ташуу "\" үргэлжлүүлэх тэмдэгтээр хуваагдсан байх ёстой.

Энэ нь crontab файл болгоны хувьд үндсэн тохиргоо байна, гэхдээ нэг зүйл нь үүнээс өөр байна. Хэрэглэгчийг заадаг зургаа дахь талбар нь зөвхөн системийн /etc/crontab файлд байна. Энэ талбарыг хэрэглэгчийн crontab файлуудын хувьд орхих хэрэгтэй.

### 12.6.1. Crontab суулгах нь

| Та энд тайлбарласан процедурыг ашиглан системийн crontab /etc/crontab-ийг засаж болон суулгах хэрэггүй. Зүгээр л өөрийн дуртай засварлагчийг ашигла: `cron` хэрэгсэл файл өөрчлөгдсөнийг мэдээд тэр даруй шинэчлэгдсэн хувилбарыг ашиглаж эхэлнэ. Дэлгэрэнгүй мэдээллийг Энэ БХА-ын оруулгаас үзнэ үү.

Хэрэглэгчийн бичсэн шинэ crontab файлыг суулгахын тулд эхлээд өөрийн дуртай засварлагчийг ашиглаад зөв хэлбэршилттэй файл үүсгээд дараа нь `crontab` хэрэгслийг ашигла. Хамгийн их ашиглагддаг тушаал бол:

    % crontab crontab-file

Энэ жишээн дээрх crontab-file нь урд нь үүсгэгдсэн crontab-ийн файлын нэр юм.

Суулгасан crontab файлуудыг үзүүлдэг тохируулга бас байдаг: `-l` тохируулгыг `crontab` уруу өгч ажиллуулаад гарах үр дүнг хараарай.

Өөрийн crontab файлыг загвар ашиглалгүйгээр эхнээс нь эхлүүлэхийг хүссэн хэрэглэгчдэд зориулсан `crontab -e` тохируулга байдаг. Энэ нь сонгосон засварлагчийг хоосон файлтай ажиллуулдаг. Файл хадгалагдсаны дараа автоматаар `crontab` тушаалаар суулгагддаг.

Хэрэглэгчийн crontab-ийг бүр мөсөн устгахыг хүсвэл `crontab`-ийг `-r` тохируулгатай ашиглаарай.

## 12.7. FreeBSD дээр rc(8) ашиглах нь

2002 онд FreeBSD системийг эхлүүлэхэд зориулж NetBSD-ийн rc.d системийг оруулсан. Хэрэглэгчид /etc/rc.d сан доторх файлуудыг анзаарах хэрэгтэй. Эдгээр файлуудын ихэнх нь `start`, `stop`, болон `restart` тохируулгуудаар хянагддаг үндсэн үйлчилгээнүүд байдаг. Жишээ нь sshd(8) нь дараах тушаалаар дахин эхлэж болно:

    # /etc/rc.d/sshd restart

Энэ процедур нь бусад үйлчилгээнүүдийн адил юм. Мэдээж үйлчилгээнүүд ихэнхдээ автоматаар rc.conf(5)-д зааснаар ачаалах үед эхэлдэг. Жишээ нь Сүлжээний Хаяг Хөрвүүлэх дэмонг эхлэх үед ажиллуулахаар нээх нь амархан бөгөөд /etc/rc.conf-д дараах мөрийг нэмдэг:

    natd_enable="YES"

Хэрэв `natd_enable="NO"` мөр аль хэдийн байвал `NO`-ийг `YES` болгож өөрчлөөрэй. rc скриптүүд өөр бусад хамааралтай үйлчилгээнүүдийг дараагийн дахин ачаалалтын үеэр доор тайлбарласны дагуу автоматаар ачаалдаг.

rc.d систем нь үндсэндээ системийн эхлэх/унтрах үеэр үйлчилгээнүүдийг эхлүүлэх/зогсоох зорилготой бөгөөд стандарт `start`, `stop` болон `restart` тохируулгууд нь зөвхөн /etc/rc.conf-ийн харгалзах хувьсагчууд заагдсан үед өөрийн үйлдлийг гүйцэтгэдэг. Жишээ нь дээр дурдсан `sshd restart` тушаал нь /etc/rc.conf-д `sshd_enable` хувьсагч `YES` гэсэн тохиолдолд зөвхөн ажиллана. /etc/rc.conf-д байгаа тохируулгаас үл хамааран үйлчилгээг `start`, `stop` эсвэл `restart` хийхийн тулд тушаалууд "one" угтвартай байх шаардлагатай. Жишээ нь `sshd`-г /etc/rc.conf дахь тохиргооноос үл хамааран дахин эхлүүлэхдээ дараах тушаалыг ашиглана:

    # /etc/rc.d/sshd onerestart

Тохирох rc.d скриптийг `rcvar` тохируулгатай ажиллуулж /etc/rc.conf-д үйлчилгээ нээгдсэн эсэхийг амархан шалгадаг. Тиймээс администратор `sshd`-г /etc/rc.conf-д нээгдсэн эсэхийг дараах тушаалыг ажиллуулж шалгаж болно:

    # /etc/rc.d/sshd rcvar
    # sshd
    $sshd_enable=YES

| Хоёр дахь мөр (`# sshd`) нь `root` консолынх биш `sshd` тушаалын гаргасан үр дүн юм.

Үйлчилгээг ажиллах байгаа эсэхийг шалгах `status` тохируулга байдаг. Жишээ нь `sshd` эхэлсэн эсэхийг шалгахдаа:

    # /etc/rc.d/sshd status
    sshd is running as pid 433.

Зарим тохиолдолд үйлчилгээг `reload` хийх бас боломжтой байдаг. Энэ нь үйлчилгээг өөрийн тохиргооны файлуудыг дахин уншихыг зааж үйлчилгээ уруу дохио шидэхийг оролддог. Ихэнх тохиолдолд энэ нь үйлчилгээ уруу `SIGHUP` дохио шиднэ гэсэн үг юм. Үйлчилгээ болгонд энэ боломжийн дэмжлэг байдаггүй.

rc.d систем нь зөвхөн сүлжээний үйлчилгээнд ашиглагдаад зогсохгүй мөн системийн эхлүүлэлтэд бас ихээхэн хувь нэмэр оруулдаг. Жишээ нь bgfsck файлыг авч үзье. Энэ скрипт ажиллахад дараах мэдээллийг хэвлэж гаргана:

    Starting background file system checks in 60 seconds.

Тиймээс энэ файлыг зөвхөн системийг эхлүүлэх үед файлын системийн арын шалгалтыг хийхэд хэрэглэдэг.

Системийн олон үйлчилгээнүүд зөв ажиллахын тулд бусад үйлчилгээнүүдээс хамаардаг. Жишээ нь NIS болон бусад RPC дээр тулгуурласан үйлчилгээнүүд `rpcbind` (portmapper) үйлчилгээ ажиллахаас нааш амжилттай ажилладаггүй. Үүнийг шийдэхийн тулд хамаарлуудын тухай болон бусад мета-өгөгдлийн тухай мэдээллийг эхлүүлэх скрипт бүрийн дээд хэсэгт тайлбараар оруулсан байдаг. rcorder(8) програм хамаарлуудыг хангаж системийн үйлчилгээнүүдийг ямар дарааллаар ажиллуулах ёстойг тогтоохын тулд эдгээр тайлбаруудыг уншдаг.

Дараах үгнүүдийг бүх эхлүүлэх скриптэд оруулах ёстой (Эдгээр нь эхлүүлэх скриптийг "идэвхжүүлэх"эд rc.subr(8)-д шаардлагатай байдаг):

- `PROVIDE`: Энэ файлын хангаж байгаа үйлчилгээнүүдийг заана.

Дараах үгнүүдийг эхлүүлэх скрипт бүрийн эхэнд оруулж болно. Эдгээр нь заавал шаардлагатай биш боловч rcorder(8)-д тус дөхөм болох ашигтай байдаг:

- `REQUIRE`: Энэ үйлчилгээнд шаардлагатай үйлчилгээнүүдийг жагсаана. Энэ файл заагдсан үйлчилгээнүүдийн дараа ажиллана.

- `BEFORE`: Энэ үйлчилгээнээс хамааралтай үйлчилгээнүүдийг жагсаана. Энэ файл заагдсан үйлчилгээнүүдийн өмнө ажиллана.

Эдгээр түлхүүр үгнүүдийг эхлүүлэх скрипт болгонд болгоомжтойгоор тохируулж өгснөөр бусад зарим UNIX® үйлдлийн системүүд шиг "ажиллах түвшингүүдтэй (runlevels)" зууралдалгүйгээр скриптүүдийн эхлэх дарааллыг маш сайн хянах боломжийг администраторт бий болгох юм.

rc.d системийн талаар нэмэлт мэдээллийг rc(8) болон rc.subr(8) гарын авлагын хуудаснуудаас олж болно. Хэрэв та өөрийн rc.d скриптүүд бичих эсвэл байгаагаа сайжруулахыг сонирхож байгаа бол танд бас энэ нийтлэл хэрэгтэй байж болох юм.

## 12.8. Сүлжээний интерфэйс картууд суулгах нь

Өнөөдөр бид сүлжээний холболтгүй компьютерийн талаар бодох ч аргагүй болсон билээ. Сүлжээний картыг нэмж тохируулах нь FreeBSD-ийн дурын администраторын ердийн ажил болдог.

### 12.8.1. Тохирох драйверийг олох нь

Эхлэхээсээ өмнө та өөрт байгаа картынхаа загвар, түүнд ашигласан бичил схем болон PCI эсвэл ISA картын аль нь эсэхийг мэдэх шаардлагатай. FreeBSD өргөн төрлийн PCI болон ISA картуудыг дэмждэг. Таны карт таны ашиглах хувилбар дээр дэмжигдсэн эсэхийг Тоног Төхөөрөмжийн Нийцтэй Байдлын Жагсаалтаас шалгаарай.

Таны карт дэмжигдсэнийг мэдсэний дараа та өөрийн картанд тохирох драйвераа тодорхойлох хэрэгтэй. /usr/src/sys/conf/NOTES болон /usr/src/sys/arch/conf/NOTES нь сүлжээний интерфэйс драйверуудын жагсаалтыг дэмжигдсэн бичил схем/картуудын тухай зарим мэдээллийн хамтаар танд өгөх болно. Хэрэв та аль драйвер нь зөв эсэхэд эргэлзэж байгаа бол драйверийн гарын авлагын хуудсыг уншаарай. Гарын авлагын хуудас нь дэмжигдсэн тоног төхөөрөмж болон бүр учирч болзошгүй асуудлуудын тухай дэлгэрэнгүй мэдээллийг өгдөг.

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

    dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38
    000ff irq 15 at device 11.0 on pci0
    miibus0: <MII bus> on dc0
    bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0
    bmtphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    dc0: Ethernet address: 00:a0:cc:da:da:da
    dc0: [ITHREAD]
    dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30
    000ff irq 11 at device 12.0 on pci0
    miibus1: <MII bus> on dc1
    bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1
    bmtphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    dc1: Ethernet address: 00:a0:cc:da:da:db
    dc1: [ITHREAD]

Энэ жишээн дээр систем дээр байгаа хоёр карт dc(4) драйверийг ашиглаж байгааг бид харж байна.

Хэрэв таны NIC-д (Network Interface Card буюу Сүлжээний Интерфэйс Карт) зориулсан драйвер GENERIC-д байхгүй бол та өөрийн NIC-г ашиглахын тулд тохирох драйверийг ачаалах хэрэгтэй. Ингэхийн тулд хоёр аргын аль нэгийг ашиглана:

- Хамгийн амархан арга нь ердөө л өөрийн сүлжээний картанд зориулсан цөмийн модулийг kldload(8) ашиглан эсвэл тохирох мөрийг /boot/loader.conf-д нэмж ачаалах үед автоматаар ачаалах юм. Бүх NIC драйверууд модуль хэлбэрээр байдаггүй; модулиуд нь байдаггүй төхөөрөмжүүдийн дурдаж болох жишээнүүд гэвэл ISA картууд юм.

- Өөр нэг арга нь та өөрийн картын дэмжлэгийг цөмд оруулан статикаар хөрвүүлж болох юм. Өөрийн цөмийн тохиргооны файлд юу нэмэх ёстойг мэдэхийн тулд /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES болон драйверийн гарын авлагын хуудсыг шалгаарай. Цөмийг дахин хөрвүүлэх талаар дэлгэрэнгүй мэдээллийг FreeBSD цөмийг тохируулах нь-с үзнэ үү. Хэрэв таны картыг таны цөм (GENERIC) ачаалах явцад илрүүлсэн бол та шинэ цөм бүтээх шаардлагагүй.

#### 12.8.1.1. Windows®-ийн NDIS драйверуудыг ашиглах нь

Харамсалтай нь өөрийн драйверуудад зориулсан схемүүдийг нээлттэй эхийн хүрээнийхэнд өгдөггүй, тийм мэдээллийг худалдааны нууц гэж үздэг олон үйлдвэрлэгчид байсаар байна. Ингэснээр FreeBSD болон өөр үйлдлийн системүүдийн хөгжүүлэгчдэд хоёр сонголт үлдсэн: буцаах инженерчлэлийн хүнд хэцүү, урт хугацааны процессийг туулж драйверуудыг хөгжүүлэх эсвэл Microsoft® Windows® тавцангуудад байдаг хоёртын хэлбэрийн драйверуудыг ашиглах арга замууд юм. FreeBSD-тэй холбогдсон зэрэг ихэнх хөгжүүлэгчид сүүлийн хандлагыг авч ашигладаг.

Билл Полын (wpaul) оруулсан хувь нэмрийн ачаар Сүлжээний Драйверийн Интерфэйсийн Тодорхойлолтын (NDIS) "эх (native)" дэмжлэг ордог болсон. FreeBSD NDISulator (өөрөөр Чөтгөр Төсөл) Windows® хоёртын драйверийг аваад ерөнхийдөө түүнийг Windows® дээр ажиллаж байгаа мэтээр хуурдаг. ndis(4) драйвер нь Windows® хоёртын файл ашиглаж байгаа учраас энэ нь зөвхөн i386™ болон amd64 системүүд дээр ажилладаг. PCI, CardBus, PCMCIA (PC-Card), болон USB төхөөрөмжүүдийг дэмждэг.

NDISulator ашиглахын тулд 3 зүйл хэрэгтэй:

1. Цөмийн эхүүд

2. Windows® XP драйверийн хоёртын файл (.SYS өргөтгөл)

3. Windows® XP драйверийн тохиргооны файл (.INF өргөтгөл)

Та өөрийн картад зориулсан файлуудыг олоорой. Ерөнхийдөө тэдгээрийг хавсаргасан CD-үүд эсвэл үйлдвэрлэгчүүдийн вэб хуудаснаас олж болно. Дараах жишээнүүдэд бид W32DRIVER.SYS болон W32DRIVER.INF файлуудыг ашиглах болно.

Драйверын битийн урт FreeBSD-ийн хувилбарынхтай таарсан байх ёстой. FreeBSD/i386-н хувьд Windows® 32-бит драйвер ашиглана. FreeBSD/amd64-н хувьд Windows® 64-бит драйвер хэрэгтэй.

Дараагийн алхамд драйверийн хоёртын файлыг цөмийн ачаалж болох модуль болгон хөрвүүлнэ. `root` эрхээр ndisgen(8)-г хэрэглэнэ:

    # ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS

ndisgen(8) хэрэгсэл нь интерактив бөгөөд шаардлагатай нэмэлт мэдээллийг асуудаг. Одоо байгаа санд цөмийн шинэ модуль үүсгэнэ. kldload(8) ашиглан шинэ модулийг ачаална:

    # kldload ./W32DRIVER_SYS.ko

Үүсгэгдсэн цөмийн модулиас гадна та ndis.ko болон if_ndis.ko модулиудыг ачаалах хэрэгтэй. Энэ нь таныг ndis(4)-ээс хамаарсан дурын модулийг ачаалах үед автоматаар хийгдэх ёстой. Хэрэв та тэдгээрийг гараар ачаалахыг хүсвэл дараах тушаалыг ашиглаарай:

    # kldload ndis
    # kldload if_ndis

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

Одоо dmesg(8)-ийг шалгаж ачаалахад алдаа байгаа эсэхийг үзэх хэрэгтэй. Бүгд сайн болж өнгөрсөн бол та дараах үр дүнг харах ёстой:

    ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1
    ndis0: NDIS API version: 5.0
    ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5
    ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
    ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps

Эндээс эхлээд та ndis0 төхөөрөмжид өөр бусад сүлжээний интерфэйсийн (өөрөөр хэлбэл dc0) нэгэн адилаар хандах боломжтой болох юм.

Та бусад модулиудтай адилаар NDIS модулиудыг ачаалах явцад ачаалахаар системийг тохируулж болно. Эхлээд үүсгэгдсэн модуль W32DRIVER_SYS.ko-г /boot/modules уруу хуулах хэрэгтэй. Тэгээд дараах мөрийг /boot/loader.conf-д нэмнэ:

    W32DRIVER_SYS_load="YES"

### 12.8.2. Сүлжээний карт тохируулах нь

Сүлжээний картанд зориулсан зөв драйвер ачаалагдсаны дараа картыг тохируулах шаардлагатай. Бусад олон зүйлсийн адил сүлжээний карт нь sysinstall програмаар суулгах явцад тохируулагдаж болно.

Таны системийн сүлжээний интерфэйсүүдэд зориулсан тохиргоог харуулахын тулд дараах тушаалыг ажиллуулна:

    % ifconfig
    dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
            options=80008<VLAN_MTU,LINKSTATE>
            ether 00:a0:cc:da:da:da
            inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    dc1: flags=8802<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
            options=80008<VLAN_MTU,LINKSTATE>
            ether 00:a0:cc:da:da:db
            inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
            media: Ethernet 10baseT/UTP
            status: no carrier
    plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
            options=3<RXCSUM,TXCSUM>
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
            inet6 ::1 prefixlen 128
            inet 127.0.0.1 netmask 0xff000000
            nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

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

- dc0: Эхний Ethernet интерфэйс

- dc1: Хоёрдугаар Ethernet интерфэйс

- plip0: Параллел порт интерфэйс (хэрэв параллел порт машин дээр байгаа бол)

- lo0: Буцаж эргэх төхөөрөмж

FreeBSD нь драйверийн нэр дээр цөмийн ачаалах явцад картууд ямар дарааллаар илрүүлэгдсэн тэр дарааллын тоог нэмж сүлжээний картыг нэрлэдэг. Жишээ нь sis2 нь систем дээрх sis(4) драйвер ашиглаж байгаа 3 дахь сүлжээний карт байж болох юм.

Энэ жишээн дээр dc0 төхөөрөмж босон ажиллаж байна. Түлхүүр индикаторууд нь:

1. `UP` нь картын тохиргоо хийгдэж бэлэн болсныг илэрхийлнэ.

2. Карт нь Интернэт (`inet`) хаягтай (энэ тохиолдолд `192.168.1.3`).

3. Энэ нь зөв дэд сүлжээний багтай (`netmask`; `0xffffff00` нь `255.255.255.0` адил).

4. Энэ нь зөв нийтэд цацах хаягтай (энэ тохиолдолд `192.168.1.255`).

5. Картны MAC (`ether`) хаяг нь `00:a0:cc:da:da:da` байна.

6. Физик зөөгчийн сонголт нь автомат сонголтын горим дээр байна (`media: Ethernet autoselect (100baseTX <full-duplex>)`). dc1 нь `10baseT/UTP` зөөгчтэй ажиллахаар тохируулагдсан байгааг бид харж болно. Байж болох зөөгчийн төрлүүдийн тухай дэлгэрэнгүй мэдээллийн талаар өөрийнх нь гарын авлагын хуудсанд хандаж үзнэ үү.

7. Холболтын (`status`) төлөв нь `active` буюу идэвхтэй байна, өөрөөр хэлбэл дамжуулагч илэрсэн байна. dc1-ийн хувьд бид `status: no carrier` буюу дамжуулагч байхгүйг харж болно. Энэ нь Ethernet кабель картанд залгагдаагүй байх үед хэвийн байна.

Хэрэв ifconfig(8)-ийн үр дүн дараах маягтай төстэй байвал:

    dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
            options=80008<VLAN_MTU,LINKSTATE>
            ether 00:a0:cc:da:da:da
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active

Энэ нь карт тохируулагдаагүйг илэрхийлнэ.

Картаа тохируулахын тулд танд `root` зөвшөөрлүүд хэрэгтэй. Сүлжээний картын тохируулгууд тушаалын мөрөөс ifconfig(8)-р хийгдэх боломжтой, гэхдээ та системийг дахин ачаалсан болгоныхоо дараа үүнийг хийх хэрэгтэй болно. /etc/rc.conf файл нь сүлжээний картын тохиргоог нэмэх газар юм.

/etc/rc.conf-ийг өөрийн дуртай засварлагч дээр нээгээрэй. Систем дээрх сүлжээний карт бүрийн хувьд мөр нэмэх хэрэгтэй, манай жишээн дээр бид эдгээр мөрүүдийг нэмсэн:

    ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0"
    ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP"

Та dc0, dc1 болон бусдуудыг өөрийн картуудад зориулсан төхөөрөмжөөр өөрчлөх болон хаягуудыг зөвөөр солих хэрэгтэй. Зөвшөөрөгдсөн тохируулгуудын талаар дэлгэрэнгүйг картын драйвер болон ifconfig(8)-ийн гарын авлагын хуудаснуудаас, бас rc.conf(5) гарын авлагын хуудаснаас /etc/rc.conf-ийн синтаксын тухай дэлгэрэнгүй мэдээллийг унших хэрэгтэй.

Хэрэв та суулгах явцад сүлжээг тохируулсан бол сүлжээний карт(ууд)ын талаар зарим мөрүүд аль хэдийн байж болох юм. Мөрүүд нэмэхээсээ өмнө /etc/rc.conf-ийг дахин шалгаарай.

Мөн та LAN дахь төрөл бүрийн машинуудын нэрүүд болон IP хаягууд /etc/hosts файлд байхгүй бол тэдгээрийг нэмж засварлах шаардлагатай. Дэлгэрэнгүй мэдээллийн талаар hosts(5) болон /usr/shared/examples/etc/hosts файлд хандана уу.

| Хэрэв энэ машинаар Интернэтэд холболт хийхээр төлөвлөсөн бол та гараараа анхдагч гарц болон нэрийн серверийг бас тохируулж өгөх ёстой:
    # echo 'defaultrouter="your_default_router"' >> /etc/rc.conf
    # echo 'nameserver your_DNS_server' >> /etc/resolv.conf

### 12.8.3. Тест хийх болон алдааг олж засварлах нь

/etc/rc.conf-д хэрэгцээтэй өөрчлөлтүүдийг хийснийхээ дараа та системээ дахин ачаалах шаардлагатай. Ингэснээр интерфэйс(үүд)эд хийгдэх өөрчлөлт(үүд)ийг зөвшөөрөх бөгөөд ямар нэг тохиргооны алдаагүйгээр систем ачаалж байгаа эсэхийг шалгадаг. Мөн өөрөөр та сүлжээний системээ дахин дуудаж болно:

    # /etc/rc.d/netif restart

| Хэрэв анхдагч гарцыг /etc/rc.conf файлд зааж өгсөн бол энэ тушаалыг ашиглана:
    # /etc/rc.d/routing restart

Сүлжээний систем дахин дуудагдсаны дараа та сүлжээний интерфэйсүүдээ тест хийх хэрэгтэй.

#### 12.8.3.1. Ethernet карт тест хийх нь

Ethernet карт зөв тохируулагдсаныг шалгахдаа та 2 зүйлийг оролдох хэрэгтэй. Эхлээд интерфэйс уруу өөр уруу нь ping хийгээд дараа нь LAN дахь өөр машин уруу ping хийх хэрэгтэй.

Эхлээд локал интерфэйсийг тест хийнэ:

    % ping -c5 192.168.1.3
    PING 192.168.1.3 (192.168.1.3): 56 data bytes
    64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms
    64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms
    64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms
    64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms
    64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms

    --- 192.168.1.3 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms

Одоо бид LAN дахь өөр машин уруу ping хийх хэрэгтэй:

    % ping -c5 192.168.1.2
    PING 192.168.1.2 (192.168.1.2): 56 data bytes
    64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms
    64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms
    64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms
    64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms
    64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms

    --- 192.168.1.2 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms

Хэрэв та /etc/hosts файлыг тохируулсан бол `192.168.1.2`-ийн оронд машины нэрийг бас ашиглаж болох болох юм.

#### 12.8.3.2. Алдааг олж засварлах нь

Тоног төхөөрөмж болон програм хангамжийн тохиргоонуудын алдааг олж засварлах нь үргэлж зовлон байдаг бөгөөд зовлонг энгийн зүйлүүдийг эхлээд шалгаснаар багасгах боломжтой. Таны сүлжээний кабель холбогдсон уу? Сүлжээний үйлчилгээнүүдээ зөв тохируулсан уу? Галт ханаа зөв тохируулсан уу? Таны хэрэглэж байгаа картыг FreeBSD дэмждэг үү? Алдааны тайланг явуулахаасаа өмнө тоног төхөөрөмжийн тэмдэглэлийг заавал шалгах хэрэгтэй. Өөрийн FreeBSD-ийн хувилбарыг хамгийн сүүлийн STABLE хувилбар уруу шинэчлээрэй. Захидлын жагсаалтын архивууд шалгах буюу эсвэл Интернетээс хайгаарай.

Хэрэв карт ажилласан мөртлөө ажиллагаа муу бол tuning(7) гарын авлагын хуудсыг унших нь зүйтэй юм. Мөн буруу сүлжээний тохиргоонууд удаан холболтын шалтгаан болдог учир та сүлжээний тохиргоог бас шалгаж болох юм.

Зарим хэрэглэгчид ганц хоёр `device timeout` мэдээлэлтэй тулгарч болох бөгөөд энэ нь зарим картуудын хувьд хэвийн юм. Хэрэв энэ нь үргэлжлээд эсвэл шаналгаатай болоод эхэлбэл уг төхөөрөмж өөр бусад төхөөрөмжтэй зөрчилдөж байгаа эсэхийг та магадгүй шалгахыг хүсэх байх. Кабелийн холболтуудыг дахин шалгаарай. Магадгүй танд өөр нэг карт хэрэгтэй байж болох юм.

Хэрэглэгчид зарим үед цөөн `watchdog timeout` гэсэн алдаанууд хардаг. Ийм үед эхлээд хийх юм нь сүлжээний кабелийг шалгана. Олон картууд Bus Mastering дэмждэг PCI оролтыг шаарддаг. Зарим нэг эх хавтангуудад үүнийг зөвхөн нэг PCI оролт зөвшөөрдөг (ихэнхдээ 0-р оролт). Энэ нь асуудал байж болох эсэхийг сүлжээний карт болон эх хавтангийн баримтаас шалгаарай.

Систем пакетийг зорьсон газар нь чиглүүлж чадахгүй тохиолдолд `No route to host` мэдээллүүд гардаг. Энэ нь анхдагч чиглүүлэлт заагаагүй тохиолдолд эсвэл кабель салгагдсан бол гардаг. `netstat -rn` тушаалын үр дүнг үзээд таны хүрэхийг оролдож байгаа тэр хост уруу чинь зөв чиглүүлэлт байгаа эсэхийг шалгаарай. Хэрэв байхгүй бол Сүлжээний нэмэлт ойлголтууд-г уншаарай.

`ping: sendto: Permission denied` алдааны мэдээллүүд нь буруу тохируулсан галт ханаас ихэвчлэн болдог. Хэрэв `ipfw` нь цөмд идэвхжсэн бөгөөд ямар ч дүрэм тодорхойлогдоогүй бол анхдагч бодлого нь бүх трафикийг бүр ping хүсэлтийг хүртэл татгалзан хаадаг! Дэлгэрэнгүйг Галт хана-с уншина уу.

Заримдаа картын ажиллагаа муу эсвэл дунджаас доогуур байдаг. Эдгээр тохиолдолд зөөгч сонголтын горимыг `autoselect` горимоос зөв зөөгчийн сонголт уруу болгож тааруулах нь шилдэг арга юм. Энэ нь ихэнх тоног төхөөрөмжийн хувьд ихэвчлэн ажиллах боловч хүн болгоны хувьд байгаа ийм асуудлыг шийдэхгүй ч байж болох юм. Дахин хэлэхэд бүх сүлжээний тохиргоонуудыг шалгаж tuning(7) гарын авлагын хуудсыг уншаарай.

## 12.9. Виртуал Хостууд

FreeBSD-ийн хамгийн түгээмэл хэрэглээ бол нэг сервер сүлжээн дээр олон сервер мэтээр ажиллах виртуал сайт хост хийх боломж юм. Үүнийг нэг интерфэйс дээр олон сүлжээний хаягууд тавьж хийдэг.

Өгөгдсөн сүлжээний интерфэйс нь нэг "жинхэнэ" хаягтай бөгөөд дурын тооны "өөр(alias)" хаягуудтай байж болох юм. Эдгээр өөр хаягуудыг ихэнхдээ /etc/rc.conf-д тохирох хаягийн оруулгуудыг оруулан нэмж өгдөг.

fxp0 интерфэйсд зориулсан өөр хаягийн оруулга нь иймэрхүү байна:

    ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"

Өөр хаягийн оруулгууд нь `alias0` гэж эхлэх ёстой бөгөөд дээш өгсөх дарааллаар явдаг (жишээ нь `_alias1`, `_alias2`, гэх мэт). Тохиргооны үйл явц эхний байхгүй дугаар дээр хүрч зогсдог.

Өөр хаягийн сүлжээний багуудыг тооцоолох нь чухал байдаг, гэхдээ азаар энэ нь маш амархан. Өгөгдсөн интерфэйсийн хувьд сүлжээний багийг зөвөөр үзүүлдэг нэг хаяг байх ёстой. Энэ сүлжээн дэх өөр бусад хаягууд бүгд `1`-ээс (энэ нь `255.255.255.255` гэх буюу эсвэл `0xffffffff` гэж илэрхийлэгддэг) тогтсон сүлжээний багтай байх ёстой.

Жишээ нь fxp0 интерфэйс нь `10.1.1.0` сүлжээнд `255.255.255.0` болон `202.0.75.16` сүлжээнд `255.255.255.240` багуудыг ашиглаж хоёр сүлжээнд холбогдсон гэж бодъё. Бид системийг `10.1.1.1`-ээс `10.1.1.5` хүртэл болон `202.0.75.17`-ээс эхлээд `202.0.75.20` хүртэлх хаягууд дээр байлгахыг хүсэж байна. Дээр тэмдэглэсний дагуу өгөгдсөн сүлжээний хүрээн дэх зөвхөн эхний хаяг (энэ тохиолдолд `10.0.1.1` болон `202.0.75.17`) жинхэнэ сүлжээний багтай байх ёстой; бусад үлдсэн бүгд (`10.1.1.2`-ээс `10.1.1.5` хүртэл болон `202.0.75.18`-ээс эхлээд `202.0.75.20` хүртэл) `255.255.255.255` сүлжээний багтай байхаар тохируулагдах хэрэгтэй.

Дараах /etc/rc.conf оруулгууд нь энэ зорилгоор адаптерийг зөв тохируулж байна:

    ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
    ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
    ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
    ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
    ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
    ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
    ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
    ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
    ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"

## 12.10. Системийн лог хийгч syslogd-г тохируулах нь

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

Энэ хэсэгт FreeBSD системийн лог хийгч syslogd(8)-г хэрхэн тохируулж ашиглах талаар болон логийг багасгах ба newsyslog(8) ашиглан лог удирдах талаар хэлэлцэх болно. Локал машин дээр `syslogd`-г тохируулж ашиглах талаар анхаарах болно. Тусдаа лог хост ашиглах талаарх нэмэлт тохиргооны тухай дэлгэрэнгүйг syslogd ашиглан алсын хост руу бүртгэх нь хэсгээс үзнэ үү.

### 12.10.1. syslogd ашиглах нь

FreeBSD-н syslogd(8)-н анхдагч тохиргоо ачаалах үед эхэлдэг. Үүнийг /etc/rc.conf дахь `syslogd_enable` хувьсагчаар хянадаг. syslogd(8)-н ажиллагаанд нөлөөлдөг програмын хэд хэдэн аргументууд байдаг. Тэдгээрийг өөрчлөхийн тулд /etc/rc.conf дахь `syslogd_flags`-г ашиглана. Аргументуудын талаар дэлгэрэнгүйг syslogd(8)-оос, rc.conf(5) ба Гол Тохиргоо болон FreeBSD дээр rc(8) ашиглах нь хэсгээс /etc/rc.conf ба rc(8) дэд системийн талаар дэлгэрэнгүйг үзнэ үү.

### 12.10.2. syslogd-г тохируулах нь

Тохиргооны файл нь анхдагчаар /etc/syslog.conf бөгөөд логуудыг хүлээж авсныхаа дараа хэрхэн яаж ажиллахыг хянадаг. Ирж байгаа үйл явдлуудтай ажиллахыг хянах хэд хэдэн параметрүүд байдаг бөгөөд тэдгээрээс хамгийн хялбар нь facility ба level юм. Хэрэгсэл нь цөм эсвэл демон гэх мэт аль дэд систем логийг үүсгэснийг тайлбарлах бөгөөд түвшин нь учирсан үйл явдлын хор хөнөөлийг тайлбарладаг. Энэ нь логийг өөр лог файлууд рүү өгөх эсвэл хаях зэргээр тохиргоо болон түвшингээс хамааруулан хийх боломжтой болгодог. Лог илгээсэн програм болон алсаас лог хийж байгаа тохиолдолд лог үйл явц үүсгэж байгаа машины хостын нэрээс хамаарч арга хэмжээ авах боломж бас байдаг.

syslogd(8)-г тохируулах нь хялбар байдаг. Тохиргооны файл нь хийх үйлдэл бүрийн хувьд нэг мөртэй байх бөгөөд мөр бүрийн синтакс нь сонголтын талбар болон арга хэмжээний талбараас тогтоно. Сонголтын талбарын синтакс нь facility.level байх бөгөөд facility буюу хэрэгслээс ирж байгаа логуудыг level түвшинд буюу түүнээс дээш түвшинд авах тохиргоо юм. Мөн нэмэлтээр юу лог хийхийг илүү нарийн зааж өгөхийн тулд харьцуулах флагийг түвшингийн өмнө нэмж өгөх бас боломжтой. Адил үйлдэлд олон сонголтын талбарыг ашиглаж болох бөгөөд тэдгээрийг цэг таслалаар (`;`) тусгаарладаг. `*`-г ашиглавал бүгдийг гэсэн утгатай. Арга хэмжээний талбар нь файл эсвэл алсын лог хост зэрэг хаашаа логийг илгээхийг зааж өгдөг. Жишээ нь энд FreeBSD-н анхдагч syslog.conf байна:

    # $FreeBSD$
    #
    #       Spaces ARE valid field separators in this file. However,
    #       other *nix-like systems still insist on using tabs as field
    #       separators. If you are sharing this file between systems, you
    #       may want to use only tabs as field separators here.
    #       Consult the syslog.conf(5) manpage.
    *.err;kern.warning;auth.notice;mail.crit                /dev/console (1)
    *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
    security.*                                      /var/log/security
    auth.info;authpriv.info                         /var/log/auth.log
    mail.info                                       /var/log/maillog (2)
    lpr.info                                        /var/log/lpd-errs
    ftp.info                                        /var/log/xferlog
    cron.*                                          /var/log/cron
    *.=debug                                        /var/log/debug.log (3)
    *.emerg                                         *
    # uncomment this to log all writes to /dev/console to /var/log/console.log
    #console.info                                   /var/log/console.log
    # uncomment this to enable logging of all log messages to /var/log/all.log
    # touch /var/log/all.log and chmod it to mode 600 before it will work
    #*.*                                            /var/log/all.log
    # uncomment this to enable logging to a remote loghost named loghost
    #*.*                                            @loghost
    # uncomment these if you're running inn
    # news.crit                                     /var/log/news/news.crit
    # news.err                                      /var/log/news/news.err
    # news.notice                                   /var/log/news/news.notice
    !ppp (4)
    *.*                                             /var/log/ppp.log
    !*

1 | `err` болон түүнээс дээш, мөн `kern.warning`, `auth.notice` ба `mail.crit` түвшний бүх мэдээллийг лог хийж эдгээр мэдээллийг консол (/dev/console) руу гаргах.
2 | `mail` хэрэгслийн `info` буюу түүнээс дээш түвшний бүх мэдээллийг барьж логийг /var/log/maillog руу авах.
3 | Энэ мөр нь `=` буюу харьцуулах флагийг ашиглаж байгаа бөгөөд `debug` түвшний мэдээллийг авч /var/log/debug.log руу бичихийг заана.
4 | Энд програмыг хэрхэн заах талаар жишээг харуулсан байна. Энэ нь програмыг зааж өгсөн тэр програмын хувьд ажиллах тийм дүрэм бий болгоно. Энэ тохиолдлын

хувьд энэ мөр болон түүний дараах нь зөвхөн `ppp`-с гарах бүх мэдээллийг /var/log/ppp.log файл руу авч байна.

Энэ жишээ нь олон түвшин болон дэд системүүд байгааг харуулж байна. Түвшингүүд нь хамгийн чухлаас бага руу жагсаагдсан байна: `emerg`, `alert`, `crit`, `err`, `warning`, `notice`, `info` ба `debug`.

Хэрэгслүүд нь ямар нэг дараалалгүйгээр дараах байна: `auth`, `authpriv`, `console`, `cron`, `daemon`, `ftp`, `kern`, `lpr`, `mail`, `mark`, `news`, `security`, `syslog`, `user`, `uucp` ба `local0`-с `local7` хүртэл байна. Өөр үйлдлийн системүүдийн хувьд өөр хэрэгслүүд байж болохыг анхаараарай.

Эдгээрийг мэдсэний дараа `notice` болон түүнээс дээш түвшинд янз бүрийн демонгоос гарч байгаа бүгдийг /var/log/daemon.log руу лог хийх тохиргооны мөрийг /etc/syslog.conf руу нэмэх нь хялбар байх болно. Дараахийг нэмэхэд л болно:

    daemon.notice                                        /var/log/daemon.log

Түвшингүүд болон хэрэгслүүдийн талаарх дэлгэрэнгүй мэдээллийг syslog(3) ба syslogd(8)-с үзнэ үү. syslog.conf болон түүний синтакс, илүү нарийн тохиргоо бүхий жишээнүүдийн талаар дэлгэрэнгүйг syslog.conf(5) ба syslogd ашиглан алсын хост руу бүртгэх нь-с үзнэ үү.

### 12.10.3. Лог удирдах ба newsyslog ашиглан багасгах

Лог файлууд нь хурдан томорч аажмаар нэмэгдэх нь элбэг байдаг. Энэ нь тийм ч чухал биш мэдээллээр файл болон хатуу дискийг дүүргэхэд хүргэдэг. Үүнийг арилгахын тулд логийн удирдлагыг ашигладаг. FreeBSD-д newsyslog(8) ашиглан лог файлуудыг удирддаг. Энэ програм нь тодорхой давтамжтайгаар лог файлуудын хэмжээг багасгаж архивлах болон байхгүй болсон лог файлуудыг үүсгэх, лог файлуудыг зөөх үед дохио өгөх зэрэгт ашиглагддаг. Лог файлууд нь заавал syslog-с гарсан байх шаардлагагүй байдаг. newsyslog(8) нь дурын програмаас гарсан дурын логтой ажиллаж чаддаг. `newsyslog`-г cron(8)-с ихэвчлэн ажиллуулдаг бөгөөд системийн демон биш гэдгийг санах хэрэгтэй. Анхдагч тохиргоогоор цаг бүр ажиллахаар тохируулагдсан байдаг.

#### 12.10.3.1. newsyslog-г тохируулах

Ямар арга хэмжээ авахыг мэдэхийн тулд newsyslog(8) анхдагчаар /etc/newsyslog.conf тохиргооны файлыг уншдаг. Энэ тохиргооны файл нь newsyslog(8) удирддаг файл бүрийн хувьд нэг мөрийг агуулсан байдаг. Мөр бүр нь файлын эзэн, зөвшөөрлүүд, файлын хэмжээг хэзээ багасгаж арвивлах болон логийг багасгахад (шахалт гэх мэт) нөлөөлөх нэмэлт флагууд ба логийг хэзээ багасгахыг хэлэх програмуудыг заадаг. Жишээ нь энд FreeBSD дээрх анхдагч тохиргоо байна:

    # configuration file for newsyslog
    # $FreeBSD$
    #
    # Entries which do not specify the '/pid_file' field will cause the
    # syslogd process to be signalled when that log file is rotated.  This
    # action is only appropriate for log files which are written to by the
    # syslogd process (ie, files listed in /etc/syslog.conf).  If there
    # is no process which needs to be signalled when a given log file is
    # rotated, then the entry for that file should include the 'N' flag.
    #
    # The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'.
    #
    # Note: some sites will want to select more restrictive protections than the
    # defaults.  In particular, it may be desirable to switch many of the 644
    # entries to 640 or 600.  For example, some sites will consider the
    # contents of maillog, messages, and lpd-errs to be confidential.  In the
    # future, these defaults may change to more conservative ones.
    #
    # logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
    /var/log/all.log                        600  7     *    @T00  J
    /var/log/amd.log                        644  7     100  *     J
    /var/log/auth.log                       600  7     100  @0101T JC
    /var/log/console.log                    600  5     100  *     J
    /var/log/cron                           600  3     100  *     JC
    /var/log/daily.log                      640  7     *    @T00  JN
    /var/log/debug.log                      600  7     100  *     JC
    /var/log/init.log                       644  3     100  *     J
    /var/log/kerberos.log                   600  7     100  *     J
    /var/log/lpd-errs                       644  7     100  *     JC
    /var/log/maillog                        640  7     *    @T00  JC
    /var/log/messages                       644  5     100  @0101T JC
    /var/log/monthly.log                    640  12    *    $M1D0 JN
    /var/log/pflog                          600  3     100  *     JB    /var/run/pflogd.pid
    /var/log/ppp.log        root:network    640  3     100  *     JC
    /var/log/security                       600  10    100  *     JC
    /var/log/sendmail.st                    640  10    *    168   B
    /var/log/utx.log                        644  3     *    @01T05 B
    /var/log/weekly.log                     640  5     1    $W6D0 JN
    /var/log/xferlog                        600  7     100  *     JC

Мөр бүр багасгах файлын нэрээс эхэлдэг бөгөөд үүний дараа багасгасан болон шинээр үүссэн файлуудын эзэн болон бүлэг нэмэлтээр байж болно. Дараагийн талбар `mode` нь файлуудын горим бөгөөд `count` нь багасгасан файл хэдийг үлдээхийг зааж өгдөг. `size` ба `when` талбарууд нь файлыг хэзээ багасгахыг `newsyslog`-д хэлж өгнө. Лог файлыг `size` талбарт зааснаас том болсон үед эсвэл `when` талбарт заасан хугацаа өнгөрсөн үед багасгадаг. `*` нь энэ талбарыг орхино гэсэн утгатай. flags талбар нь багасгасан файлыг хэрхэн шахах эсвэл байхгүй байгаа лог файлыг үүсгэх зэрэг заавруудыг newsyslog(8)-д өгдөг. Хамгийн сүүлийн хоёр талбар нь нэмэлт бөгөөд процессын PID-file болон сигналын дугаарыг зааж файлыг багасгах үед тухайн процесс руу илгээх сигналыг зааж өгдөг. Бүх талбарууд, флагууд болон багасгах хугацааг хэрхэн зааж өгөх талаарх дэлгэрэнгүй мэдээллийг newsyslog.conf(5)-с үзнэ үү. `newsyslog` нь `cron`-с ажилладаг бөгөөд cron(8)-ы ажиллах давтамжаас илүү олон ажиллах боложмгүй гэдгийг санаарай.

## 12.11. Тохиргооны Файлууд

### 12.11.1. /etc-н бүтэц

Тохиргооны мэдээллийг хадгалдаг хэд хэдэн сангууд байдаг. Эдгээр нь:

/etc | Системийн ерөнхий тохиргооны мэдээлэл; энд байгаа өгөгдөл нь системийн хувьд өөр өөр.
/etc/defaults | Системийн тохиргооны файлуудын анхдагч хувилбарууд.
/etc/mail | sendmail(8)-ийн нэмэлт тохиргоо, бусад MTA тохиргооны файлууд.
/etc/ppp | Хэрэглэгч- болон цөмийн-ppp програмуудад зориулсан тохиргоо.
/etc/namedb | named(8) өгөгдөлд зориулсан анхдагч байрлал. Ихэнхдээ named.conf болон бүсийн файлууд энд хадгалагддаг.
/usr/local/etc | Суулгагдсан програмуудад зориулсан тохиргооны файлууд. Програм болгоны дэд сангуудыг агуулж болно.
/usr/local/etc/rc.d | Суулгагдсан програмуудад зориулсан эхлүүлэх/зогсоох скриптүүд.
/var/db | Багцын өгөгдлийн бааз, байршил олох өгөгдлийн бааз, гэх зэрэг систем болгоны хувьд автоматаар үүсгэгдсэн өгөгдлийн баазын файлууд.

### 12.11.2. Хостын нэрс

#### 12.11.2.1. /etc/resolv.conf

/etc/resolv.conf нь FreeBSD-ийн тодорхойлогч Интернэт Домэйн Нэрийн Системд (DNS) хэрхэн хандахыг заадаг.

resolv.conf дахь хамгийн түгээмэл оруулгууд нь:

`nameserver` | Тодорхойлогчийн асуух нэрийн серверийн IP хаяг. Серверүүд нь хамгийн ихдээ гурав байх жагсаасан дарааллаар асуугддаг.
`search` | Хостын нэрийн хайлтад зориулж жагсаалтаас хайх. Энэ нь ихэнхдээ локал хостын нэрийн домэйноор тодорхойлогддог.
`domain` | Локал домэйн нэр.

Ердийн resolv.conf:

    search example.com
    nameserver 147.11.1.11
    nameserver 147.11.100.30

| `search` болон `domain` тохируулгуудын зөвхөн нэг нь хэрэглэгдэх ёстой.

Хэрэв та DHCP ашиглаж байгаа бол dhclient(8) нь DHCP серверээс хүлээн авсан мэдээллээр resolv.conf-г дарж бичдэг.

#### 12.11.2.2. /etc/hosts

/etc/hosts нь хуучин Интернэтийн үлдэгдэл энгийн текст өгөгдлийн бааз юм. Энэ нь DNS болон NIS-тэй цуг нэрийг IP хаяг уруу болгож тааруулах боломжийг ханган ажилладаг. LAN-аар холбогдсон локал компьютеруудыг амархан нэрлэх зориулалтаар named(8) сервер суулгаж тохируулахын оронд энд байрлуулж болдог. Мөн /etc/hosts нь түгээмэл ханддаг нэрсэд зориулагдсан гадагшаа хандах хүсэлтийг багасгаж Интернэтийн нэрсийн локал бичлэгийг хангадаг байж болно.

    # $FreeBSD$
    #
    #
    # Host Database
    #
    # This file should contain the addresses and aliases for local hosts that
    # share this file.  Replace 'my.domain' below with the domainname of your
    # machine.
    #
    # In the presence of the domain name service or NIS, this file may
    # not be consulted at all; see /etc/nsswitch.conf for the resolution order.
    #
    #
    ::1			localhost localhost.my.domain
    127.0.0.1		localhost localhost.my.domain
    #
    # Imaginary network.
    #10.0.0.2		myname.my.domain myname
    #10.0.0.3		myfriend.my.domain myfriend
    #
    # According to RFC 1918, you can use the following IP networks for
    # private nets which will never be connected to the Internet:
    #
    #	10.0.0.0	-   10.255.255.255
    #	172.16.0.0	-   172.31.255.255
    #	192.168.0.0	-   192.168.255.255
    #
    # In case you want to be able to connect to the Internet, you need
    # real official assigned numbers.  Do not try to invent your own network
    # numbers but instead get one from your network provider (if any) or
    # from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.)
    #

/etc/hosts нь энгийн хэлбэрийг агуулдаг:

    [Internet address] [official hostname] [alias1] [alias2] ...

Жишээ нь:

    10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2

Дэлгэрэнгүй мэдээллийн талаар hosts(5) хуудаснаас зөвлөгөө авна уу.

### 12.11.3. sysctl.conf

sysctl.conf нь rc.conf-той бараг л адил харагддаг. Утгууд нь `хувьсагч=утга` хэлбэрээр заагддаг. Тодорхойлсон утгууд нь систем олон-хэрэглэгчийн горимд шилжсэний дараа тохируулагддаг. Энэ горимд бүх хувьсагчууд тохируулагдах боломжгүй.

Сүйрлийн дохионы гаралтуудын бүртгэлийг хааж бусад хэрэглэгчдийн эхлүүлсэн процессуудыг өөр хэрэглэгчдэд харуулахгүй байлгахын тулд дараах тохируулгуудыг sysctl.conf файлд тохируулж өгч болно:

    # Do not log fatal signal exits (e.g., sig 11)
    kern.logsigexit=0

    # Prevent users from seeing information about processes that
    # are being run under another UID.
    security.bsd.see_other_uids=0

## 12.12. sysctl(8) ашиглан тааруулах нь

sysctl(8) нь ажиллаж байгаа FreeBSD системд өөрчлөлтүүдийг хийхийг танд зөвшөөрдөг интерфэйс юм. Энэ нь туршлагатай системийн администраторын хувьд ажиллагааг мэдэгдэхүйц сайжруулж чадах TCP/IP болон виртуал санах ойн системийн олон нарийн тохируулгуудыг агуулдаг. Таван зуу гаруй системийн хувьсагчуудыг sysctl(8) ашиглан унших болон тохируулж болдог.

sysctl(8) нь голдоо хоёр үүргийг гүйцэтгэдэг: системийн тохиргоонуудыг унших болон өөрчлөх.

Уншигдаж болох бүх хувьсагчуудыг харахдаа:

    % sysctl -a

Тухайн хувьсагчийг уншихдаа, жишээ нь, `kern.maxproc`:

    % sysctl kern.maxproc
    kern.maxproc: 1044

Тухайн хувьсагчийг заахдаа хялбар хувьсагч=утга синтаксийг ашиглаарай:

    # sysctl kern.maxfiles=5000
    kern.maxfiles: 2088 -> 5000

sysctl хувьсагчуудын тохиргоонууд нь ихэвчлэн тэмдэгтүүд (strings), тоонууд эсвэл boolean (boolean `1` нь тийм эсвэл `0` нь үгүй байна) утгууд байна.

Хэрэв та машин ачаалах болгонд автоматаар зарим хувьсагчуудыг тохируулахыг хүсвэл /etc/sysctl.conf файлд тэдгээрийг нэмээрэй. Дэлгэрэнгүй мэдээллийн талаар sysctl.conf(5) гарын авлагын хуудас болон sysctl.conf-с үзнэ үү.

### 12.12.1. Зөвхөн-унших sysctl(8)

Зарим тохиолдолд зөвхөн-унших sysctl(8) утгуудыг өөрчлөх шаардлагатай байж болох юм. Энэ нь заримдаа хийхээс өөр аргагүй байдаг боловч зөвхөн (дахин) ачаалахад хийгдэх боломжтой.

Жишээ нь зарим зөөврийн компьютерийн загваруудад cardbus(4) төхөөрөмж нь санах ойн хүрээг шалгадаггүй бөгөөд доор дурдсантай төстэй алдаанууд гарган амжилтгүй болдог:

    cbb0: Could not map register memory
    device_probe_and_attach: cbb0 attach returned 12

Дээрх шиг тохиолдлууд нь ихэвчлэн зөвхөн уншихаар тохируулагдсан зарим анхдагч sysctl(8) тохиргоонуудыг өөрчлөхийг шаарддаг. Эдгээр нөхцөлүүдийг давж гарахын тулд хэрэглэгч sysctl(8) "OID"-уудыг тэдгээрийн /boot/loader.conf файлд хийж өгч болно. Анхдагч тохиргоонууд /boot/defaults/loader.conf файлд байрладаг.

Дээр дурдсан асуудлыг шийдэхийн тулд хэрэглэгч урьд нь дурдсан файлд `hw.pci.allow_unsupported_io_range=1` гэж тохируулах шаардлагатай. Ингэснээр cardbus(4) зөв ажиллах болно.

## 12.13. Дискнүүдийг тааруулах нь

### 12.13.1. Sysctl хувьсагчууд

#### 12.13.1.1. `vfs.vmiodirenable`

`vfs.vmiodirenable` sysctl хувьсагч нь 0 (идэвхгүй) эсвэл 1 (идэвхтэй) гэж тохируулагдаж болно; анхдагчаар 1 байна. Энэ хувьсагч нь систем сангуудыг хэрхэн кэш (шуурхай санамж) хийхийг хянадаг. Ихэнх сангууд зөвхөн ганц фрагментийг (ихэвчлэн 1 K) файлын системд болон түүнээс багыг буфер кэшд хэрэглэн жижиг хэмжээтэй байдаг. Энэ хувьсагчийг хааснаар (0 болгосноор) буфер кэш нь таныг асар их хэмжээний санах ойтой байсан ч гэсэн зөвхөн тодорхой тооны сангуудыг кэш хийдэг. Нээгдсэн (1 болгосон) үед энэ sysctl нь бүх санах ойг кэш хийхэд бэлэн болгож буфер кэшд VM Хуудасны Кэшийг хэрэглэн сангуудыг кэш хийх боломжийг олгодог. Гэхдээ сангуудыг кэш хийх хамгийн бага гол дахь санах ой нь 512 байт биш харин физик хуудасны хэмжээ (ихэвчлэн 4 K) байдаг. Хэрэв та их олон тооны файлуудтай ажилладаг үйлчилгээ ажиллуулж байгаа бол бид энэ тохируулгыг идэвхтэй байлгахыг зөвлөж байна. Тийм үйлчилгээнүүдэд вэб кэшүүд, том захидлын системүүд, болон мэдээний системүүд орж болно. Энэ тохируулгыг идэвхтэй байлгах нь хайр гамгүй зарцуулсан санах ойтой байхад ч гэсэн ерөнхийдөө ажиллагааг удаашруулдаггүй, гэхдээ та түүнийг мэдэхийн тулд туршиж үзэж болно.

#### 12.13.1.2. `vfs.write_behind`

`vfs.write_behind` sysctl хувьсагчийн анхдагч утга нь `1` (идэвхтэй) байна. Энэ нь том дараалсан файлуудыг бичих үед ихэвчлэн гардаг бүх кластеруудыг цуглуулсан үед зөөгчийн бичилтүүдийг хийхийг файлын системд хэлж өгдөг. Санаа нь бол I/O ажиллагааны хувьд ашиггүй байхад бохир буферууд бүхий буферийн кэшийг замхруулахаас зайлсхийхэд оршдог. Гэхдээ энэ нь процессуудыг зогсоож магадгүй бөгөөд зарим нөхцөл байдалд та магадгүй үүнийг идэвхгүй болгохыг хүсэж болох юм.

#### 12.13.1.3. `vfs.hirunningspace`

`vfs.hirunningspace` sysctl хувьсагч өгөгдсөн дурын хоромд системийн хувьд бүхэлд нь хэдий хэмжээний хүлээгдэж байгаа бичих I/O-г дискний хянагчуудад өгөх дараалалд оруулж болохыг тодорхойлдог. Анхдагч утга нь ихэвчлэн хангалттай гэхдээ олон дисктэй машинууд дээр та үүнийг дөрөв эсвэл таван мегабайт хүртэл ихэсгэхийг хүсэж болох юм. Утгыг хэтэрхий өндөр тавих нь (буфер кэшийн бичих тогтоосон хэмжээг давах нь) туйлын муу кластерлах ажиллагаанд хүргэж болно. Энэ утгыг хэтэрхий өндөр бүү тавь! Өндөр бичих утгууд нь яг тэр үед хийгдэж байгаа уншилтуудад хоцрогдол нэмж магадгүй юм.

Бусад төрөл бүрийн буфер-кэш болон VM хуудасны кэштэй холбоотой sysctl-ууд байдаг. Бид эдгээр утгуудыг өөрчлөхийг зөвлөдөггүй, VM систем нь өөрийгөө автоматаар тааруулж туйлын сайн ажилладаг.

#### 12.13.1.4. `vm.swap_idle_enabled`

`vm.swap_idle_enabled` sysctl хувьсагч нь маш олон хэрэглэгчид таны системд орж гарч байдаг, сул зогссон олон процессуудтай, том, олон-хэрэглэгчийн системүүд дээр ашигтай байдаг. Ийм системүүд нь чөлөөт санах ойн хадгалалтад ихээхэн хэмжээний байнгын дарамтыг үүсгэж байдаг. Энэ боломжийг идэвхтэй болгож ар араас нь swap хийн гаргахыг (зогссон секундээр) `vm.swap_idle_threshold1` болон `vm.swap_idle_threshold2` хувьсагчуудын тусламжтай тохируулснаар зогссон процессуудтай холбоотой санах ойн хуудаснуудын дарааллыг ердийн хуудаслаж гаргах алгоритмаас илүү хурднаар багасгах боломжийг олгодог. Энэ нь хуудаслаж гаргах дэмонд тусламжийн гарыг өгөх болно. Энэ тохируулгыг танд хэрэгтэй л биш бол идэвхтэй болгож болохгүй, учир нь үүнийг та хийснээр үндсэндээ санах ойг илүү түргэн урьдчилан-хуудаслаж ингэснээр swap болон дискний багтаамжийг илүүтэйгээр идэхэд хүргэх юм. Жижиг систем дээр энэ тохируулга нь тодорхойлогдож болохуйц нөлөөлөлтэй байх ба харин боломжийн хуудаслалт аль хэдийн хийгээд байгаа том системүүдэд энэ тохируулга нь VM системд бүх процессуудыг санах ой уруу болон санах ойгоос хялбараар гаргах боломжийг бүрдүүлдэг.

#### 12.13.1.5. `hw.ata.wc`

FreeBSD 4.3-д IDE бичих кэш хийлтийг хаасан байдаг. Энэ нь IDE дискэнд бичих багтаамжийг багасгасан боловч хатуу диск үйлдвэрлэгчдийн гаргасан өгөгдлийн бүрэн бүтэн байдлын ноцтой асуудлуудаас болоод шаардлагатай болсон. Тэр асуудал нь IDE хөтлөгчүүд бичилт дуусах үед худлаа мэдээлдэг явдал юм. IDE бичих кэшийг идэвхтэй болгосноор IDE хатуу дискнүүд ямар нэг дараалалгүйгээр бичихээс гадна диск их ачаалалтай үед зарим блокуудыг бичихэд заримдаа тодорхойгүй саатдаг. Сүйрэл болон тэжээлийн уналт файлын системийн ноцтой эвдрэлд хүргэж болзошгүй байдаг. FreeBSD-ийн анхдагч нь аюулгүй байхаар өөрчлөгдсөн. Харамсалтай нь үүний үр дүнд ажиллагааны асар том алдагдалд хүргэсэн бөгөөд хувилбар гарсны дараа бид бичих кэш хийлтийг анхдагчаар идэвхтэй байхаар буцаан өөрчилсөн юм. Та өөрийн систем дээрээ `hw.ata.wc` sysctl хувьсагчийг ажиглан анхдагч утгыг шалгах хэрэгтэй. Хэрэв IDE бичих кэш хийлт хаалттай бол та цөмийн хувьсагчийн утгыг 1 болгон түүнийг идэвхжүүлж болно. Үүнийг ачаалах үед ачаалагчаас хийх шаардлагатай. Цөм ачаалсны дараа хийхийг оролдвол ямар ч нөлөө үзүүлэхгүй.

Дэлгэрэнгүй мэдээллийн талаар ata(4)-с үзнэ үү.

#### 12.13.1.6. `SCSI_DELAY` (`kern.cam.scsi_delay`)

`SCSI_DELAY` цөмийн тохиргоо нь системийн ачаалах хугацааг багасгахад хэрэглэгддэг. Анхдагч утга нь нэлээн өндөр бөгөөд `15` секундын саатлыг ачаалах процессийн үед өгөхийг хариуцдаг. `5` секунд хүртэл багасгахад ихэвчлэн ажилладаг (ялангуяа орчин үеийн хөтлөгчүүдийн хувьд). Ачаалах үеийн тохируулга болох `kern.cam.scsi_delay` хувьсагчийг ашиглах хэрэгтэй. Энэ тохируулга болон цөмийн тохиргооны тохируулга нь секундээрбишмиллисекундээр утгыг хүлээн авдаг.

### 12.13.2. Зөөлөн Шинэчлэлтүүд

tunefs(8) програм файлын системийг нарийн тааруулахад ашиглагдаж болно. Энэ програм нь олон янзын тохируулгуудтай гэхдээ одоохондоо бид зөвхөн Зөөлөн Шинэчлэлтүүдийг идэвхжүүлэх ба хаах дээр анхаарах бөгөөд үүнийг дараах аргаар хийнэ:

    # tunefs -n enable /filesystem
    # tunefs -n disable /filesystem

Файлын систем нь холбогдсон байхдаа tunefs(8)-ээр өөрчлөгдөх боломжгүй. Зөөлөн Шинэчлэлтүүдийг идэвхжүүлэхэд тохирох үе нь аль ч хуваалтууд холболт хийгдээгүй байгаа ганц хэрэглэгчийн горим юм.

Зөөлөн Шинэчлэлтүүд нь мета-өгөгдлийн ажиллагааг мэдэгдэхүйц сайжруулдаг бөгөөд санах ойн кэшийг ашиглан голчлон файлын үүсгэлт болон устгалтыг хурдасгадаг. Бид Зөөлөн Шинэчлэлтүүдийг өөрийн бүх файлын системүүдэд ашиглахыг зөвлөж байна. Зөөлөн Шинэчлэлтүүдийн хоёр дутагдалтай талыг та мэдэж байх ёстой: Нэгдүгээрт, Зөөлөн Шинэчлэлтүүд нь сүйрэл болсон тохиолдолд файлын системийн бүрэн бүтэн байдалд баталгаа өгдөг боловч физик дискийг шинэчлэхэд хэдэн секундын (минут ч байж болно!) хоцрогдолтой байж болно. Хэрэв таны систем сүйрэхэд бусад тохиолдлоос илүүтэйгээр та хийсэн ажлаа алдаж болзошгүй юм. Хоёрдугаарт, Зөөлөн Шинэчлэлтүүд нь файлын системийн блокуудыг чөлөөлөхийг саатуулдаг. Хэрэв та бараг дүүрсэн файлын системтэй (root файл систем гэх зэрэг) байгаа бол `make installworld` зэрэг гол шинэчлэлтийг хийх нь файлын системийг зайгүй болгож шинэчлэлт амжилтгүй болох шалтгаанд хүргэж болох юм.

#### 12.13.2.1. Зөөлөн Шинэчлэлтүүдийн талаар дэлгэрэнгүй

Файлын системийн мета-өгөгдлийг диск уруу бичих уламжлалт хоёр хандлага байдаг. (Мета-өгөгдлийн шинэчлэлтүүд нь inode эсвэл сангууд зэрэг агуулгын бус өгөгдөлд хийх шинэчлэлтүүд юм)

Түүхээс авч үзэхэд анхдагч ажиллах горим нь мета-өгөгдлийн шинэчлэлтүүдийг синхроноор буюу зэрэг бичдэг байсан явдал юм. Хэрэв сан өөрчлөгдсөн бол систем өөрчлөлтийг диск уруу бичигдэхийг хүлээдэг. Файлын өгөгдлийн буферууд (файлын агуулгууд) буфер кэшээр дамжин диск уруу сүүлд нь асинхроноор хадгалагддаг. Энэ шийдлийн давуу тал нь аюулгүй ажилладаг. Хэрэв шинэчлэлтийн үед амжилтгүй болбол мета-өгөгдөл нь үргэлж бүрэн бүтэн байдаг. Файл эсвэл бүрэн үүсч эсвэл бүр ерөөсөө үүсдэггүй. Хэрэв файлын өгөгдлийн блокууд сүйрэл болох үед буферийн кэшээс диск уруу өөрсдийн гарах замаа олохгүй байгаа бол fsck(8) нь үүнийг таньж файлын уртыг 0 болгон файлын системийг засварладаг. Нэмж хэлэхэд энэ шийдэл нь цэвэрхэн ба хялбар юм. Сул тал нь мета-өгөгдлийн өөрчлөлтүүд нь удаан байдаг. `rm -r` тушаал жишээ нь сан дахь бүх файлуудад дараалан хандах бөгөөд гэхдээ сан болгоны өөрчлөлт (файлын устгалт) синхроноор зэрэг диск уруу бичигддэг. Үүнд сан уруу өөрт нь хийгдэх шинэчлэлтүүд, inode хүснэгт болон магадгүй файлын гаргасан шууд бус блокуудад хийх шинэчлэлтүүд ордог. Том иерархуудыг задлахад (`tar -x`) үүний нэгэн адилаар авч үздэг.

Хоёр дахь нь асинхрон мета-өгөгдлийн шинэчлэлтүүд юм. Энэ нь Линукс/ext2fs-ийн хувьд анхдагч байх бөгөөд *BSD ufs-ийн хувьд `mount -o async` байх юм. Бүх мета-өгөгдлийн шинэчлэлтүүд нь буфер кэшээр бас дамждаг, тэгэхээр тэдгээр нь файлын агуулгын өгөгдлийн шинэчлэлтүүдтэй харилцан холилдох болно. Энэ шийдлийн давуу тал нь мета-өгөгдөл бүрийн шинэчлэлт диск уруу бичигдэхийг хүлээдэггүй бөгөөд ингэснээр ихээхэн хэмжээний мета-өгөгдлийн шинэчлэлтүүдийг хийдэг бүх үйлдлүүд синхрон хийгдэхээс хамаагүй хурдан ажилладаг. Мөн энэ шийдэл нь цэвэрхэн бас энгийн бөгөөд ингэснээр хорхойнууд (алдаа) код уруу мөлхөн орох эрсдэл бага юм. Сул тал нь файлын системийн бүрэн бүтэн төлвийн ямар нэг баталгаа ерөөсөө байдаггүй. Хэрэв их хэмжээний мета-өгөгдөл шинэчлэх үйлдлийн явцад амжилтгүй болсон бол (тэжээлийн тасалдал, эсвэл хэн нэг нь дахин эхлүүлэх товч дарсан зэрэгт) файлын систем тааж болшгүй төлөвт үлдэх болно. Систем дахин ачаалаад дуусахад файлын системийн төлөвийг мэдэх боломжгүй байдаг; inode хүснэгт эсвэл холбоотой сангийн шинэчлэлтүүд бичигдээгүй байхад файлын өгөгдлийн блокууд диск уруу аль хэдийн бичигдчихсэн байж болох юм. Ер нь гаргасан замбараагүйтлийг (учир нь хэрэгцээтэй мэдээлэл диск дээр байхгүй) цэвэрлэж чаддаг `fsck` тушаалын шийдлийг хийх боломжгүй. Хэрэв файлын систем засвар хийж чадахааргүй эвдэрсэн бол түүнд дээр newfs(8)-ийг хэрэглэж нөөцөөс сэргээхээс өөр аргагүй юм.

Энэ асуудлын шийдэл нь бохир бүсийн бүртгэл буюу бас журналчлалт гэгддэг шийдлийг гаргах явдал бөгөөд энэ ухагдахуун нь тогтвортой хэрэглэгддэггүй ба шилжүүлэлтийн бүртгэлийн бусад хэлбэрүүдэд бас заримдаа ашиглагддаг. Мета-өгөгдлийн шинэчлэлтүүд нь синхроноор бичигдсэн хэвээр байх бөгөөд гэхдээ зөвхөн дискний жижиг бүсэд бичигдэнэ. Дараа нь тэдгээрийг тэдний зөв байрлал уруу зөөдөг. Бүртгэлийн талбар нь диск дээр бага, үргэлжилсэн бүс байдаг учраас бүр хүнд үйлдлүүдийн үед ч гэсэн дискний толгойнууд шилжихэд хол зайтай биш байдаг болохоор эдгээр үйлдлүүд нь синхрон шинэчлэлтүүдээс илүү хурдан байдаг. Мөн энэ шийдлийн төвөгтэй байдал нь маш хязгаарлагдмал болохоор алдаанууд байх эрсдэл нь бага байдаг. Сул тал нь бүх мета-өгөгдөл нь хоёр удаа бичигддэг (бүртгэлийн бүсэд нэг удаа болон зөв байрлал уруу бас нэг удаа) болохоор энгийн ажлын хувьд ажиллагааны "өөдрөг бус үзэгдэл" гарч болзошгүй юм. Нөгөө талаас сүйрэл болоод систем дахин ачаалаад дуусахад хүлээгдэж байгаа бүх мета-өгөгдлийн үйлдлүүд бүртгэлийн талбараас хурдан буцаагдаж эсвэл гүйцэд хийгдэн дуусч болох бөгөөд энэ нь файлын системийг хурдан эхлүүлэхэд хүргэдэг.

Беркли FFS-ийн хөгжүүлэгч Кирк МкКюзик энэ асуудлыг Soft Updates буюу Зөөлөн Шинэчлэлтүүдээр шийдсэн: хүлээгдэж байгаа бүх мета-өгөгдлийн шинэчлэлтүүд нь санах ойд хадгалагдах бөгөөд диск уруу эрэмбэлэгдсэн дарааллаар бичигддэг ("дараалуулсан мета-өгөгдлийн шинэчлэлтүүд"). Энэ нь мета-өгөгдлийн хүнд үйлдлүүдийн үед хэрэв эрт хийгдсэн шинэчлэлтүүд диск уруу бичигдээгүй санах ойд байж байхад нь сүүлд хийгдэх шинэчлэлтүүд тэдгээрийг "барьж" авдаг. Тэгэхээр сангийн хувьд хэлбэл түүнд хийгдэх бүх үйлдлүүд нь санах ойд шинэчлэлт диск уруу бичигдэхээс өмнө хийгддэг (өгөгдлийн блокууд нь мета-өгөгдлөөсөө түрүүлээд диск дээр байж байхгүйгээр өөрсдийн байрлалынхаа дагуу эрэмбэлэгддэг ). Хэрэв систем сүйрвэл энэ нь "бүртгэл урагшлуулахад" хүргэдэг: диск уруу гарах замаа олохгүй байгаа бүх үйлдлүүд хэзээ ч хийгдээгүй юм шиг байдаг. Файлын системийн бүрэн бүтэн төлөв хадгалагдаж 30-аас 60 секундын өмнөх төлөвт ордог. Хэрэглэгдэж байгаа эх үүсвэрүүдийг тэдгээрийн өөрсдийнх харгалзах битмапуудад: блокууд болон inode-уудад байдаг шигээр тэмдэглэхийг үүнд ашигласан алгоритм нь баталгаатай хангадаг. Сүйрэл болсны дараа зөвхөн гарсан эх үүсвэр суллан гаргалтын алдаа нь яг үнэндээ "чөлөөтэй" мөртлөө "ашиглагдаж байгаа" гэж тэмдэглэгдсэн эх үүсвэрүүд байдаг. fsck(8) энэ байдлыг таних бөгөөд ашиглагдаагүй байгаа эх үүсвэрүүдийг чөлөөлдөг. Сүйрлийн дараа файлын системийн бохир төлвийг авч үзэлгүйгээр хүчээр `mount -f` тушаалаар холбох нь аюулгүй юм. Ашиглагдаагүй байж болзошгүй эх үүсвэрүүдийг чөлөөлөхдөө fsck(8)-г сүүлд нь ажиллуулах хэрэгтэй. Энэ нь ард ажиллах fsck-ийн цаана байгаа санаа юм: системийг эхлүүлэх үед зөвхөн файлын системийн хормын зураг бичигддэг. `fsck`-г сүүлд нь ажиллуулж болно. Дараа нь бүх файлын системүүд "бохир" холбогдож системийн эхлэлт олон хэрэглэгчийн горимд үргэлжилдэг. Дараа нь ард ажиллах `fsck`-үүд ашиглагдаагүй байгаа эх үүсвэрүүдийг чөлөөлөхөөр шаардлагатай байгаа бүх файлын системийн хувьд ажиллахаар төлөвлөгддөг. (Зөөлөн Шинэчлэлтүүд ашигладаггүй файлын системүүдэд ердийн нүүрэн дээр ажиллах `fsck` хэрэгтэй хэвээр байна)

Давуу тал нь мета-өгөгдлийн үйлдлүүд нь асинхрон шинэчлэлтүүдтэй бараг л адил хурдан байдаг (өөрөөр хэлбэл мета-өгөгдлийг хоёр дахин бичдэг бүртгэл хийлтээс хурдан байдаг). Сул талууд нь төвөгтэй код (хэрэглэгчийн өгөгдлийн алдагдлын хувьд их мэдрэмтгий талбар дахь байж болох алдаануудын тэр өндөр эрсдэлийг хэлж байна) болон санах ойн илүү хэрэглээ юм. Мөн хэн нэгний хэрэглэж байсан хувийн тохиргоонууд ч бас байдаг. Сүйрэл болсны дараа файлын системийн төлөв "хуучин" юм шиг харагддаг. Стандарт синхрон хандлага нь `fsck`-ийн дараа зарим нэг тэг-урттай файлуудыг үлдээхэд хүргэсэн нөхцөлд тэдгээр файлууд нь Зөөлөн Шинэчлэлтүүдтэй файлын системийн үед огт байдаггүй бөгөөд учир нь мета-өгөгдөл болон файлын агуулгууд хэзээ ч диск уруу бичигдээгүй байдаг. Дискний зай нь магадгүй `rm` ажиллуулснаас хэсэг хугацааны дараа диск уруу шинэчлэлтүүд бичигдэх хүртэл сулардаггүй. Энэ нь бүх файлуудыг хоёр дахин хадгалахад хангалттай хүрэлцэхүйц хэмжээний чөлөөтэй зай байхгүй файлын систем дээр их хэмжээний өгөгдлийг суулгаж байх үед асуудлууд гарахад хүргэж болох юм.

## 12.14. Цөмийн хязгаарууд тохируулах нь

### 12.14.1. Файл/Процессийн хязгаарууд

#### 12.14.1.1. `kern.maxfiles`

`kern.maxfiles` нь таны системийн шаардлагуудаас хамаараад дээшилж эсвэл доошилж болно. Энэ хувьсагч нь таны систем дээрх файлын тодорхойлогчуудын (descriptor) хамгийн их тоог илэрхийлдэг. Файлын тодорхойлогчийн хүснэгт дүүрсэн тохиолдолд `file: table is full` буюу файл: хүснэгт дүүрсэн гэсэн мэдээлэл давтагдан системийн богино мэдээллийн буфферт үзэгдэх бөгөөд үүнийг `dmesg` тушаал ашиглан үзэж болдог.

Нээлттэй файл, сокет эсвэл fifo болгон нэг файлын тодорхойлогч хэрэглэдэг. Ажиллаж байгаа том-хэмжээний сервер зэрэгцээ ажиллаж байгаа үйлчилгээнүүдийн тоо болон төрлөөс хамааран олон мянган файлын тодорхойлогчуудыг өлхөн шаардаж болох юм.

Хуучин FreeBSD хувилбаруудад `kern.maxfiles`-ийн анхдагч утга нь таны цөмийн тохиргооны файлын `maxusers` тохируулгаас гарсан байдаг. `kern.maxfiles` нь `maxusers` утгатай пропорционалаар өсдөг. Өөрчлөн тохируулсан цөмийг бүтээхдээ энэ цөмийн тохиргооны тохируулгыг өөрийн системийн хэрэглээний дагуу зааж өгөх нь зүйтэй байдаг. Энэ тооноос хамаарч цөм өөрийн ихэнх урьдчилан-тодорхойлсон хязгааруудыг өгдөг. Ажиллагаанд байгаа машин яг үнэндээ нэг удаа 256 хэрэглэгч зэрэг холбогдоогүй байж болох боловч өндөр-хэмжээний вэб серверийнхтэй адил эх үүсвэрүүд хэрэгтэй байж болох юм.

`kern.maxusers` хувьсагч нь системд байгаа санах ойн дээр үндэслэн ачаалах үед автоматаар тавигддаг бөгөөд ажиллаж байх явцад зөвхөн уншигдах `kern.maxusers` sysctl хувьсагчийн утгыг шалгаж тогтоогдож болох юм. Зарим сайтууд `kern.maxusers`-ийн илүү их эсвэл бага утгуудыг шаардаж үүнийг ачаалагчаар тааруулагдахаар тохируулж болох юм; 64, 128, болон 256 утгууд нь ховор байдаг. Танд асар их тооны файлын тодорхойлогчууд хэрэгтэй л биш бол бид 256-аас дээш байлгахыг зөвлөдөггүй; өөрсдийн анхдагч утгуудад `kern.maxusers`-р заагддаг, тааруулагдах боломжтой утгуудын олонх нь тус тусдаа ачаалалтын үед эсвэл ажиллах явцад /boot/loader.conf-оор эсвэл энэ баримтын хаа нэгтээ тайлбарласнаар өөрчлөгдөж болдог (loader.conf(5) гарын авлага эсвэл /boot/defaults/loader.conf файлыг санаа авахын тулд үзнэ үү).

Хуучин хувилбаруудад хэрэв та `maxusers`-ийг `0` гэж шууд зааж өгсөн бол систем автоматаар тааруулж өгдөг . Энэ тохируулгыг заахдаа ялангуяа та хэрэв X Цонхны Систем ашиглаж байгаа эсвэл програм хангамж хөрвүүлж байгаа бол `maxusers`-ийг хамгийн багадаа 4 гэж заахыг хүсэх болно. Шалтгаан нь гэвэл `maxusers`-ээр заагдсан хамгийн чухал хүснэгт бол `20 + 16 * maxusers` гэж заагдсан процессуудын хамгийн их тоо бөгөөд хэрэв та `maxusers`-ийг 1 гэж заасан бол та 18 орчмыг нь ачаалах үед системийг эхлүүлэхэд болон 15 орчмыг нь таныг X Цонхны Системийг эхлүүлэхэд магадгүй үүсэж та нийт зөвхөн 36 зэрэг процесстой байж болох юм. Гарын авлагыг унших зэрэг хялбар бодлого хүртэл шүүх, шахсаныг задлах, болон үзэхэд зориулж есөн процессийг эхлүүлдэг. `maxusers`-ийг 64 гэж заах нь бараг л бүх хэрэгцээнд хангалттай байх 1044 зэрэг процесстой байж болохыг танд зөвшөөрнө. Гэхдээ өөр програм эхлүүлэхээр оролдож байх үед эсвэл их олон тооны зэрэгцээ хэрэглэгчидтэй сервер (`ftp.FreeBSD.org`-той адил) ажиллуулж байхад айдас төрүүлэм буюу proc хүснэгт дүүрсэн гэсэн алдаа хэрэв та харах юм бол үргэлж энэ тоог ихэсгэн цөмийг дахин бүтээж болох юм.

| `maxusers` нь таны машин уруу нэвтрэх хэрэглэгчдийн тоог хязгаарладаггүй. Энэ нь ердөө л таны систем дээр байж болох хамгийн их хэрэглэгчийн тоо болон тэдгээр тус бүрийн ажиллуулах процессийн тооноос хамааран төрөл бүрийн хүснэгтийн хэмжээнүүдийг боломжийн утгуудаар зааж өгдөг.

#### 12.14.1.2. `kern.ipc.somaxconn`

`kern.ipc.somaxconn` sysctl хувьсагч нь шинэ TCP холболтуудыг хүлээн авахад зориулсан сонсох дарааллын хэмжээг хязгаарладаг. Анхдагч утга `128` нь ачаалал ихтэй вэб серверийн орчин дахь шинэ холболтуудыг хүлээж авахад ерөнхийдөө хэтэрхий бага юм. Тийм орчны хувьд энэ утгыг `1024` эсвэл түүнээс их болгохыг зөвлөдөг. Үйлчилгээний дэмон нь өөрөө сонсох дарааллын хэмжээгээ (өөрөөр хэлбэл sendmail(8), эсвэл Apache) хязгаарлаж болох боловч ихэвчлэн өөрийн тохиргооны файлдаа дарааллын хэмжээг тааруулах тохиргооны мөртэй байдаг. Их хэмжээний сонсох дарааллууд нь бас Үйлчилгээг Зогсоох халдлагуудаас () илүү сайн зайлсхийж ажилладаг.

### 12.14.2. Сүлжээний хязгаарууд

`NMBCLUSTERS` цөмийн тохиргооны тохируулга нь системд байгаа сүлжээний Mbuf-уудын тоог зааж өгдөг. Бага тооны Mbuf-уудтай трафикийн ачаалал ихтэй сервер FreeBSD-ийн чадварт саад болдог. Кластер бүр ойролцоогоор 2 K санах ойг илэрхийлдэг, тийм болохоор 1024 гэсэн утга нь сүлжээний буферуудад зориулж хадгалсан 2 мегабайт цөмийн санах ойг илэрхийлнэ. Хичнээн хэрэгтэйг олохын тулд хялбар тооцоо хийж болно. Хэрэв та хамгийн ихдээ 1000 зэрэгцээ холболтуудтай, холболт бүр нь 16 K хүлээн авах болон 16 K илгээх буферийг иддэг вэб сервертэй бол танд ойролцоогоор вэб серверийг хангахын тулд 32 MB хэмжээтэй тэнцэх сүлжээний буферууд хэрэгтэй болно. Практикаар ер нь 2-оор үржүүлдэг, тэгэхээр 2x32 MB / 2 KB = 64 MB / 2 kB = 32768 болох юм. Бид их санах ойтой машинуудын хувьд утгуудыг 4096-аас 32768-ын хооронд байлгахыг зөвлөдөг. Энэ параметрийн хувьд өндөр утгыг ямар ч нөхцөлд тавьж болохгүй, учир нь энэ нь ачаалах үеийн сүйрэлд хүргэж болно. netstat(1)-д `-m` тохируулгыг ашиглаж сүлжээний кластерийн ашиглалтыг ажиглаж болох юм.

`kern.ipc.nmbclusters` ачаалалтын тааруулах боломжтой тохируулга нь ачаалах үед үүнийг тааруулахад хэрэглэгдэх ёстой. Зөвхөн FreeBSD-ийн хуучин хувилбарууд `NMBCLUSTERS` цөмийн config(8) тохируулгыг ашиглахыг танаас шаарддаг.

sendfile(2) системийн дуудлагыг өргөнөөр ашигладаг завгүй серверүүдийн хувьд `NSFBUFS` цөмийн тохиргооны тохируулгын тусламжтай эсвэл түүний утгыг /boot/loader.conf-д зааж sendfile(2) буферуудын тоог ихэсгэх шаардлагатай байж болох юм (дэлгэрэнгүйг loader(8)-с үзнэ үү). Процессууд `sfbufa` төлөвт харагдах нь энэ параметрийг тааруулах хэрэгтэйг ихэвчлэн заадаг. `kern.ipc.nsfbufs` sysctl хувьсагч нь цөмөөр тохируулагдсан хувьсагч дахь зөвхөн уншигддаг гялбаа юм. Энэ параметр нь `kern.maxusers`-ийн хэмжээгээр тааруулагддаг, гэхдээ үүнийг түүний дагуу тохируурах шаардлагатай байж болох юм.

| Сокет блок-хийгддэггүй гэж тэмдэглэгдсэн ч гэсэн блок-хийгддэггүй сокет дээр sendfile(2)-ийг дуудах нь хангалттай хэмжээний `struct sf_buf`-уудыг бий болготол sendfile(2) дуудлага блок хийгдэхэд хүргэж болох юм.

#### 12.14.2.1. `net.inet.ip.portrange.*`

`net.inet.ip.portrange.*` sysctl хувьсагчууд нь TCP болон UDP сокетуудад автоматаар уягдах портын дугаарын хүрээнүүдийг хянадаг. Гурван хүрээ байдаг: доод хүрээ, анхдагч хүрээ, болон өндөр хүрээ. Ихэнх сүлжээний програмууд нь анхдагчаар 1024 болон 5000 байдаг `net.inet.ip.portrange.first` болон `net.inet.ip.portrange.last` хувьсагчуудаар хянагддаг анхдагч хүрээг ашигладаг. Уягдах портын хүрээнүүд гарах холболтуудад ашиглагддаг бөгөөд зарим тохиолдолд систем дэх портууд дуусч болох юм. Энэ нь ихэвчлэн таныг ачаалал ихтэй вэб прокси ашиглаж байхад гардаг. Ихэвчлэн ирж байгаа холболтуудыг хүлээн авдаг ердийн вэб сервер эсвэл захидал дамжуулагч зэрэг хязгаарлагдмал тооны гарах холболтуудтай серверүүдийг ажиллуулж байхад портын хүрээ нь асуудал биш юм. Таны порт дуусаж болох тийм тохиолдлуудад `net.inet.ip.portrange.last` хувьсагчийг даруухнаар ихэсгэхийг зөвлөдөг. `10000`, `20000` эсвэл `30000` нь боломжийн утгууд юм. Портын хүрээг өөрчилж байхдаа галт ханын нөлөөллүүдийг бас бодолцох хэрэгтэй. Зарим галт хана их хэмжээний портуудыг хааж болох бөгөөд (ихэнхдээ бага дугаарын портууд) систем өндөр дугаарын портуудыг гарах холболтууддаа ашигладгийг бодолцох ёстой - ийм учраас `net.inet.ip.portrange.first`-ийг багасгахыг зөвлөдөггүй.

#### 12.14.2.2. TCP хурд сааруулагч бүтээгдэхүүнүүд

TCP хурд сааруулагч бүтээгдэхүүний хязгаарлалт нь NetBSD дэх TCP/Vegas-тай адилхан юм. `net.inet.tcp.inflight.enable` sysctl хувьсагчийг `1` болгон тохируулж үүнийг идэвхжүүлдэг. Систем холболт бүрийн хувьд хурд сааруулагч бүтээгдэхүүнийг тооцоолохыг оролддог бөгөөд сүлжээн дэх дараалалд оруулах өгөгдлийн хэмжээг хамгийн боломжийн нэвтрүүлэх чадамжийг байнга барьж байх тэр хэмжээнд хүргэж хязгаарладаг.

Хэрэв та өгөгдлийг модемууд, Гигабит Ethernet, эсвэл бүр өндөр хурдны WAN холболтуудаар (эсвэл дурын өндөр хурд сааруулагч бүтээгдэхүүнтэй холболт) дамжуулж байгаа бол ялангуяа та бас цонх өсгөлтийг ашиглаж байгаа эсвэл том илгээх цонх тохируулсан бол энэ боломж нь ашигтай юм. Хэрэв та энэ тохируулгыг идэвхжүүлэх бол бас `net.inet.tcp.inflight.debug`-ийг `0` (дибаг хийхийг болиулах) болгож тохируулах хэрэгтэй бөгөөд үйлдвэрлэлийн ашиглалтад `net.inet.tcp.inflight.min`-ийг хамгийн багаар бодоход `6144` болгох нь ашигтай байж болох юм. Гэхдээ хамгийн бага тоог өндөр болгох нь холболтоос хамааран хурд хязгаарлалтыг идэвхтэйгээр болиулж болохыг санах хэрэгтэй. Хязгаарлах боломж нь дундын чиглүүлэлтийн үед бүтээгдсэн өгөгдлийн хэмжээг багасгах бөгөөд пакетийн дарааллуудыг сольж локал хостын интерфэйс дэх дараалал дээр бүтээгдсэн өгөгдийн хэмжээг мөн багасгадаг. Дараалалд орсон цөөн тооны пакетуудтай, ялангуяа удаан модемоор дамжсан интерактив холболтууд нь бага Round Trip Times буюу Эргэн Аялах Хугацаатайгаар ажиллаж бас чаддаг. Гэхдээ энэ боломж нь зөвхөн өгөгдөл дамжуулалтад (илгээх / сервер талын) нөлөөлдгийг санах хэрэгтэй. Энэ нь өгөгдөл хүлээн авахад нөлөө үзүүлэхгүй (татаж авах).

`net.inet.tcp.inflight.stab`-ийг тааруулахыг зөвлөдөггүй. Энэ параметр нь хурд сааруулах бүтээгдэхүүний цонхны тооцоололд нэмсэн 2 хамгийн их пакетийг илэрхийлж анхдагчаар 20 байдаг. Энэ алгоритмийг тогтворжуулах болон өөрчлөгдөж байгаа нөхцлүүдэд хариу өгөх боломжийг сайжруулахад нэмэлт цонх шаардлагатай боловч энэ нь бас удаан холболт дээр ping хийх хугацаа ихэсгэхэд хүргэдэг (гэхдээ таныг энэ (inflight) алгоритмийг ашиглаагүй байхад гарсан үр дүнгээс хамаагүй бага хэвээр л байна). Ийм тохиолдолд энэ параметрийг 15, 10, эсвэл 5 болгон багасгахыг хүсэж болох юм; мөн хүссэн үр дүндээ хүрэхийн тулд `net.inet.tcp.inflight.min` хувьсагчийг (жишээ нь 3500 болгож) бас багасгаж болох юм. Эдгээр параметрүүдийг багасгах нь хамгийн сүүлд авах арга хэмжээ байх ёстой юм.

### 12.14.3. Виртуал санах ой

#### 12.14.3.1. `kern.maxvnodes`

vnode нь файл эсвэл сангийн дотоод дүрслэл юм. Тэгэхээр үйлдлийн системд байх vnode-ийн тоог ихэсгэх нь диск I/O-г багасгадаг. Энэ нь ихэвчлэн үйлдлийн системээр зохицуулагддаг бөгөөд өөрчлөх хэрэггүй байдаг. Зарим тохиолдолд диск I/O нь гол асуудал учруулж системд vnode байхгүй болж байвал энэ тохируулгыг ихэсгэх хэрэгтэй болно. Идэвхгүй болон чөлөөтэй RAM-ийн хэмжээг бодолцох шаардлагатай.

Тухайн үед ашиглагдаж байгаа vnode-уудыг үзэхдээ:

    # sysctl vfs.numvnodes
    vfs.numvnodes: 91349

Хамгийн их vnode-уудыг үзэхдээ:

    # sysctl kern.maxvnodes
    kern.maxvnodes: 100000

Хэрэв тухайн үеийн vnode ашиглалт хамгийн их хэмжээ уруу бараг дөхөж байвал `kern.maxvnodes`-ийг 1,000-аар ихэсгэх нь зүйтэй байж болох юм. `vfs.numvnodes`-ийн тоон дээр бас анхаарлаа хандуулаарай. Хэрэв энэ нь дахин хамгийн их уруугаа дээшилбэл `kern.maxvnodes`-ийг цааш ихэсгэх шаардлагатай болно. top(1)-ийн гаргасан дүнгээс таны санах ойн өөрчлөлт харагдах ёстой. Түрүүнийхээс илүү санах ой идэвхтэй байх ёстой.

## 12.15. Swap зай нэмэх нь

Та яаж ч сайн төлөвлөсөн байлаа гэсэн заримдаа систем таны бодсоноор ажилладагүй. Хэрэв танд swap зай илүү хэрэгцээтэйг мэдвэл та үүнийг амархнаар нэмж болно. Та гурван аргаар swap зайг ихэсгэж болно: шинэ хатуу диск нэмэх, NFS-ийн тусламжтай swap идэвхжүүлэх болон байгаа хуваалт дээр swap файл үүсгэж ихэсгэж болно.

Swap зайг хэрхэн шифрлэх, ямар тохируулгууд байгаа болон яагаад хийх ёстой талаар гарын авлагын Swap зайг шифрлэх хуудсанд хандана уу.

### 12.15.1. Шинэ эсвэл байгаа диск дээрх swap

swap-т зориулж шинэ хатуу диск нэмэх нь байгаа диск дээр хуваалт нэмэхээсээ илүүтэй ажиллагааны хувьд сайжруулдаг. Хуваалтуудыг үүсгэх болон хатуу диск нэмэх талаар Диск нэмэх хэсэгт тайлбарласан байгаа. Эхний Тохиргоо хэсэгт хуваалтын байдал болон swap хуваалтын зайн талаарх анхаарах зүйлсийг тайлбарласан байгаа.

swapon(8) ашиглан swap хуваалтыг системийг нэмж өгнө. Жишээ нь:

    # swapon /dev/ada1s1b

| Өгөгдөлтэй ч гэсэн холбогдоогүй байгаа хуваалтыг ашиглах боломжтой. swapon(8) ашигласнаар өгөгдэлтэй байгаа хуваалт дээр бичилт хийгдэж өгөгдлийг нь устгах болно. swap хэлбэрээр нэмэгдэх хуваалт нь яг тэр зорилгоор ашиглагдах гэж байгаа эсэхийг swapon(8) ажиллуулахаасаа өмнө шалгаарай.

Ачаалахад ашиглагдахаар автоматаар энэ swap хуваалтыг нэмэхийн тулд /etc/fstab файлд тухайн хуваалтын талаарх оруулгыг нэмнэ:

    /dev/ada1s1b	none	swap	sw	0	0

/etc/fstab дахь оруулгуудын талаарх тайлбарыг fstab(5) гарын авлагын хуудаснаас үзнэ үү.

### 12.15.2. NFS-ийн тусламжтай swap хийх нь

NFS-ийн тусламжтай swap хийхийг зөвхөн swap хийх локал хатуу диск танд байхгүй үед л зөвлөдөг; NFS swap хийх нь байгаа сүлжээний хурдаар хязгаарлагддаг бөгөөд NFS серверт нэмэлт ачаалал үзүүлдэг.

### 12.15.3. Swap файлууд

Та swap файл болгон ашиглахаар заасан хэмжээтэй файлыг үүсгэж болно. Энд байгаа жишээн дээр бид /usr/swap0 гэсэн нэртэй 64MB файлыг ашиглана. Мэдээж та хүссэн ямар ч нэрээ ашиглаж болно.

Жишээ 1. Swap файл FreeBSD дээр үүсгэх нь

1. GENERIC цөм нь энэ үйлдэлд шаардлагатай санах ойн дискний драйверийг (md(4)) агуулсан байдаг. Цөмийг тохируулан өөрчлөх гэж байгаа бол доорх мөрийг цөмийн тохиргооны файлдаа оруулахаа мартуузай:

       device   md

   Өөрийн хэрэгцээнд зориулж цөм бүтээх талаар FreeBSD цөмийг тохируулах нь бүлгээс үзнэ үү.

2. Swap файл (/usr/swap0) үүсгэнэ:

       # dd if=/dev/zero of=/usr/swap0 bs=1024k count=64

3. Зөв зөвшөөрлүүдийг (/usr/swap0-д) нээж тохируулна:

       # chmod 0600 /usr/swap0

4. /etc/rc.conf-д swap файлыг идэвхжүүлнэ:

       swapfile="/usr/swap0"   # Set to name of swapfile if aux swapfile desired.

5. Машиныг дахин эхлүүлнэ эсвэл swap файлыг шууд идэвхжүүлэхийн тулд дараах тушаалыг ажиллуулна:

       # mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0

## 12.16. Тэжээл болон Эх үүсвэрийн Удирдлага

Тоног төхөөрөмжийн эх үүсвэрүүдийг үр ашигтай ашиглах нь чухал юм. ACPI танилцуулагдахаас өмнө системийн тэжээлийн ашиглалт болон дулааны шинж чанаруудыг удирдахад үйлдлийн системүүдийн хувьд хэцүү, уян хатан биш байсан. Тоног төхөөрөмж нь BIOS-оор удирдагддаг байсан болохоор тэжээлийн удирдлагын тохиргоонуудын харагдац бага бөгөөд хэрэглэгчид хянах боломж бага байсан юм.Зарим нэгэн хязгаарлагдмал тохиргооны боломж Advanced Power Management буюу Тэжээлийн Дэвшилттэй Удирдлага (APM) интерфэйсээр хийгдэх боломжтой байсан. Тэжээл болон Эх үүсвэрийн Удирдлага нь орчин үеийн үйлдлийн системийн түлхүүр хэсгүүдийн нэг юм. Жишээ нь таны системийн хэм гэнэт нэмэгдэх тохиолдолд системийн хязгааруудыг үйлдлийн систем монитор хийхийг (магадгүй танд мэдээлэхийг) хүсэж болох юм.

FreeBSD Гарын авлагын энэ хэсэгт бид ACPI-ийн талаар нэвтэрхий мэдээллээр хангах болно. Цааш нэмж уншихад зориулсан мэдээллүүдийг төгсгөл хэсэгт оруулсан байгаа.

### 12.16.1. ACPI гэж юу вэ?

Advanced Configuration and Power Interface буюу Дэвшилттэй Тохиргоо ба Тэжээлийн Интерфэйс (ACPI) нь тоног төхөөрөмжийн эх үүсвэрүүд болон тэжээлийн удирдлагад (эндээс нэр гарсан) зориулсан стандарт интерфэйсийг хангах зорилгоор үйлдвэрлэгчдийн холбооноос бичин гаргасан стандарт юм. Энэ нь Үйлдлийн Системээр заалгасан тохиргоо ба Тэжээлийн Удирдлагын түлхүүр элемент юм, өөрөөр хэлбэл: энэ нь илүү хяналт болон уян хатан байдлыг үйлдлийн системд (OS) хангадаг. ACPI-г танилцуулахаас өмнө одоогийн Залгаад Тоглуулах интерфэйсүүдийн хязгааруудыг орчин үеийн системүүд "сунгасан" юм. ACPI нь APM-ийн (Advanced Power Management буюу Тэжээлийн Дэвшилтэт Удирдлага) шууд залгамжлагч юм.

### 12.16.2. Тэжээлийн Дэвшилтэт Удирдлагын (APM) сул талууд

Тэжээлийн Дэвшилтэт Удирдлага (APM) боломж нь системийн тэжээлийн ашиглалтыг түүний ажиллагаан дээр үндэслэн хянадаг. APM BIOS нь (систем) үйлдвэрлэгчээс хангагддаг бөгөөд тоног төхөөрөмжийн тавцан бүрийн хувьд онцлог байдаг. OS дахь APM драйвер нь тэжээлийн түвшингүүдийн удирдлагыг зөвшөөрдөг APM Програм хангамжийн Интерфэйс уруу хандах хандалтыг зуучилж өгдөг. APM-ийг 2000 онд болон тэрнээс өмнө үйлдвэрлэсэн системүүдэд ашиглах ёстой хэвээр байдаг.

APM-д дөрвөн үндсэн асуудал байдаг. Нэгдүгээрт, тэжээлийн удирдлага (үйлдвэрлэгчийн онцлогтой) BIOS-оор хийгддэг бөгөөд OS нь энэ талын ямар ч мэдлэг байдаггүй. Үүний нэг жишээ нь хэрэглэгч хатуу дискний сул зогсох хугацааг APM BIOS дээр зааж өгөөд тэр нь зааснаас илүү гарвал BIOS хатуу дискийг OS-ийн зөвшөөрөлгүйгээр эргүүлдэг. Хоёрдугаарт, APM-ийн логик BIOS-д суулгагдсан байдаг бөгөөд OS-ийн эрх хэмжээнээс гадна ажилладаг. Энэ нь хэрэглэгчид өөрсдийн APM BIOS-ийг зөвхөн шинэ хувилбараар нь ROM уруу нь шарж асуудлуудыг засварлах боломжтой гэсэн үг юм; энэ нь амжилтгүй болбол системийг дахин сэргээгдэхгүй төлөвт орхиж болох боломжтой маш аюултай процедур юм. Гуравдугаарт, APM нь үйлдвэрлэгчийн онцлогтой технологи бөгөөд энэ нь маш олон адил төсөөтэй байдал (чармайлтуудын хуулбар) болон нэг үйлдвэрлэгчийн BIOS-д олдсон алдаанууд бусад үйлдвэрлэгчдийн хувьд шийдэгдээгүй байж болно гэсэн үг юм. Хамгийн сүүлд гэхдээ төгсгөлийнх биш, APM BIOS нь тэжээлийн маш нарийн бодлого эсвэл машины зориулалтад зориулагдан маш сайн тохируулагдах тийм шийдлийг хийхэд хангалттай зайгүй байдаг.

Залгаад Тоглуулах BIOS (PNPBIOS) нь олон тохиолдолд найдвартай биш байсан юм. PNPBIOS нь 16-битийн технологи, тийм болохоор OS нь PNPBIOS аргуудтай холбогдохдоо 16-битийн эмуляц хэрэглэх шаардлагатай болдог.

FreeBSD-ийн APM драйвер apm(4) гарын авлагын хуудсанд баримтжуулагдсан байдаг.

### 12.16.3. ACPI-г тохируулах нь

acpi.ko драйвер нь системийг эхлүүлэх үед loader(8)-оор анхдагчаар ачаалагддаг бөгөөд цөмд оруулж хөрвүүлэгдэх ёсгүй. Үүний цаадах шалтгаан нь модулиудтай ажиллах хялбар байдаг, өөрөөр хэлбэл цөмийг дахин хөрвүүлэлгүйгээр өөр acpi.ko уруу шилждэг. Энэ нь тест хийлтийг илүү амархан болгодог давуу талтай юм. Нөгөө нэг шалтгаан нь системийг ажиллуулж дууссаны дараа ACPI-г ажиллуулахад ихэвчлэн сайн ажилладаггүй. Хэрэв та асуудлуудтай учирч байгаа бол ACPI-г бүхэлд нь хаах хэрэгтэй. Энэ драйверийг ачаалсны дараа буулгаж болиулж чаддаггүй, болдоггүй, учир нь системийн шугам үүнийг төрөл бүрийн тоног төхөөрөмжүүдийн харилцан үйлдлүүдэд хэрэглэдэг. ACPI-г /boot/loader.conf файлд юм уу эсвэл loader(8) хүлээх мөрөнд `hint.acpi.0.disabled="1"` гэж тохируулан хааж болдог.

| ACPI болон APM нь цуг байж болохгүй бөгөөд салангид хэрэглэгдэх ёстой. Сүүлд ачаалагдах драйвер нь хэрэв нөгөө нэгийг ажиллаж байгааг мэдвэл ажиллагаагаа дуусгавар болгодог.

ACPI нь acpiconf(8)-ийн `-s` туг болон `1-5` тохируулгын тусламжтайгаар системийг унтах горим шилжүүлэхэд хэрэглэгдэж болно. Ихэнх хэрэглэгчдэд зөвхөн `1` эсвэл `3` (RAM руу түр зогсоох) хэрэгтэй байдаг. `5` тохируулга нь дараах тушаалтай нэг ёсондоо адилыг гүйцэтгэнэ:

    # halt -p

Бусад тохируулгууд sysctl(8)-ийн тусламжтай байдаг. Дэлгэрэнгүй мэдээллийн талаар acpi(4) болон acpiconf(8) гарын авлагын хуудаснуудаас шалгана уу.

## 12.17. FreeBSD-ийн ACPI-г ашиглах нь ба дибаг хийх нь

ACPI нь төхөөрөмжүүдийг илрүүлэх, тэжээлийн ашиглалтыг удирдах болон урьд нь BIOS-оор удирдагддаг байсан төрөл бүрийн тоног төхөөрөмжид хандах стандартчилагдсан хандалтыг хангадаг цоо шинэ арга юм. Бүх системүүд дээр ACPI-г ажиллуулах тал дээр дэвшил хийгдсэн бөгөөд гэхдээ зарим эх хавтангуудын ACPI Машины Хэлний (AML) байткод дахь алдаанууд, FreeBSD-ийн цөмийн дэд системүүдийн бүрэн бүтэн бус байдал болон Intel® ACPI-CA тайлбарлагч дахь алдаанууд илэрсээр байна.

Энэ баримт нь таныг FreeBSD-ийн ACPI дэмжигчдэд тусалж таны ажигласан асуудлуудын үндсэн учир шалтгааныг таних, дибаг хийх болон шийдлийг хөгжүүлэхэд туслах зорилготой юм. Үүнийг уншиж байгаад талархлаа илэрхийлэхийн ялдамд бид таны системийн асуудлуудыг шийдэж чадна гэдэгт найдаж байна.

### 12.17.1. Дибаг мэдээллийг илгээх нь

| Асуудлыг илгээхээсээ өмнө та хамгийн сүүлийн үеийн BIOS-ийн хувилбар болон хэрэв байх юм бол суулгагдсан хянагчийн хамгийн сүүлийн firmware хувилбар ажиллуулж байгаа эсэхээ шалгаарай.

Асуудлыг шууд илгээхийг хүсэж байгаачууд дараах мэдээллийг freebsd-acpi@FreeBSD.org уруу илгээнэ үү:

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

- `boot -v` ажилласны дараах dmesg(8)-ийн гаралтыг алдааг шалгаж байхад таны үүсгэсэн алдааны мэдээллүүдийн хамтаар.

- Хэрэв ACPI-г хаасан байхад асуудлыг шийдэж байвал тийм байх үе дэх `boot -v`-ийн гаралт.

- `sysctl hw.acpi`-ийн гаралт. Энэ нь таны систем ямар ямар боломжуудыг санал болгож байгааг мэдэх бас нэг сайн арга юм.

- Таны ACPI Эх Хэл (ASL) байх URL хаяг. ASL нь маш том байж болох учир шууд битгий жагсаалт уруу илгээгээрэй. Өөрийн ASL-ийн хуулбарыг энэ тушаалыг ашиглаж үүсгээрэй:

      # acpidump -dt > name-system.asl

  (Өөрийн нэвтрэх нэрийг name-ийн оронд болон үйлдвэрлэгч/загварыг system-ийн оронд солиорой. Жишээ нь: njl-FooCo6000.asl)

Ихэнх хөгжүүлэгчид FreeBSD-CURRENT захидлын жагсаалт үзэж байдаг, гэхдээ асуудлуудаа харагдуулахын тулд FreeBSD ACPI захидлын жагсаалт уруу илгээгээрэй. Бид бүгд хаа нэгтээ өөр өөрийн үндсэн ажилтай учир тэвчээртэй байна уу. Хэрэв таны алдаа шууд илэрхий биш байх юм бол магадгүй бид таныг send-pr(1)-ийн тусламжтай PR илгээхийг асуух байх. PR оруулахдаа дээр хүссэний адил мэдээллээ оруулна уу. Энэ нь асуудлыг мөшгөж шийдвэрлэхэд бидэнд туслах юм. Бид PR-уудыг мэдээлэх механизмын зорилгоор биш байгаа асуудлуудыг санаж байх зорилгоор ашигладаг болохоор эхлээд FreeBSD ACPI захидлын жагсаалт уруу захидал илгээлгүйгээр PR битгий илгээгээрэй. Магадгүй таны асуудлыг урд нь өөр хэн нэгэн мэдээлсэн байж болох юм.

### 12.17.2. Оршил

ACPI нь ia32 (x86), ia64 (Itanium) болон amd64 (AMD) архитектуруудтай нийцтэй орчин үеийн бүх компьютерт байдаг. Бүрэн стандарт нь CPU-ны ажиллагааны удирдлага, тэжээлийн онгоцуудын хяналт, дулааны бүсүүд, төрөл бүрийн батарейний системүүд, суулгагдсан хянагчууд болон шугамын жагсаалт зэрэг олон боломжуудтай. Ихэнх системүүд нь бүрэн стандартыг бүгдийг хангасан шийдэлтэй байдаггүй. Жишээ нь зөөврийн компьютер хөргөх болон бас батарейний удирдлагын дэмжлэгтэй байхад ширээний систем зөвхөн шугамын жагсаалтын хэсгийн шийдлийг агуулсан байдаг. Зөөврийн компьютерууд нь бас өөр өөрийн ярвигтай асуудлуудыг агуулсан түр зогсоох болон үргэлжлүүлэх боломжуудыг агуулдаг.

ACPI-нийцтэй систем нь төрөл бүрийн хэсгүүдтэй байдаг. BIOS болон бичил схемийн үйлдвэрлэгчид APIC зураг (SMP-д ашиглагддаг), тохиргооны регистрүүд болон хялбар тохиргооны утгууд зэрэг зүйлсүүдийг заадаг төрөл бүрийн тогтмол хүснэгтүүдийг (өөрөөр хэлбэл FADT) санах ойд хангаж өгдөг. Мөн төхөөрөмжүүд болон аргуудын мод хэлбэрийн нэрийн талбарыг заадаг байткодын хүснэгтээр (Differentiated System Description Table буюу Системийн Ялгаварласан Тайлбарын Хүснэгт DSDT) бас хангадаг.

ACPI драйвер нь тогтмол хүснэгтүүдийг задлан ялгал хийх, байткодын тайлбарлагчийг шийдэх болон ACPI дэд системийн мэдээллийг хүлээн авахаар төхөөрөмжүүдийн драйверууд болон цөмийг өөрчлөх ёстой. FreeBSD-ийн хувьд Intel® нь Линукс болон NetBSD-тэй хуваалцан хэрэглэгддэг тайлбарлагчаар хангадаг. ACPI-CA эх кодын зам нь src/sys/contrib/dev/acpica. ACPI-CA-г FreeBSD дээр ажиллуулах тэр цавуу код нь src/sys/dev/acpica/Osd байршилд байдаг. Эцэст нь төрөл бүрийн ACPI төхөөрөмжүүдийн драйверууд src/sys/dev/acpica байршлаас олддог.

### 12.17.3. Нийтлэг асуудлууд

ACPI зөв ажиллахын тулд бүх хэсгүүд бас зөв ажилласан байх ёстой. Энд зарим нэг нийтлэг асуудлуудыг илэрч байгаа давтамжийн дарааллаар зарим нэг тойрон гарах замууд болон засваруудтайгаар нь дурдъя.

#### 12.17.3.1. Хулганы асуудлууд

Зарим тохиолдолд түр зогсоох үйлдэл хийгдсэний дараа үргэлжлүүлэхэд хулганыг ажиллахгүй болгодог. Мэдэгдэж байгаа тойрон гарах арга зам нь `hint.psm.0.flags="0x3000"` мөрийг /boot/loader.conf файлд нэмэх явдал юм. Хэрэв энэ нь ажиллахгүй бол дээр тайлбарласны дагуу алдааны тайлан илгээхийг бодно уу.

#### 12.17.3.2. Suspend/Resume буюу Түр зогсоох/Үргэлжлүүлэх

ACPI нь RAM уруу түр зогсоох `S1`-`S3` гэсэн гурван төлөвтэй (STR) бөгөөд диск уруу түр зогсоох `S4` гэгддэг нэг төлөвтэй (`STD`). `S5` нь "soft off буюу зөөлөн зогсоолт" бөгөөд тэжээлд залгагдсан боловч асаагдаагүй байх үеийн таны системийн жирийн төлөв юм. `S4` нь хоёр тусдаа аргаар хийгдэх боломжтой. `S4`BIOS нь BIOS-ийн тусламжтайгаар диск уруу хийгдэх түр зогсоолт юм. `S4`OS нь бүхэлдээ үйлдлийн системээр хийгддэг.

Түр зогсоолттой холбоотой зүйлүүдийг `sysctl hw.acpi` тушаалаар шалгаж эхлээрэй. Энд Thinkpad-тай холбоотой үр дүнгүүд байна:

    hw.acpi.supported_sleep_state: S3 S4 S5
    hw.acpi.s4bios: 0

Энэ нь бид `S3`, `S4`OS болон `S5`-ийг шалгахад `acpiconf -s` тушаалыг ашиглаж болно гэсэн үг юм. Хэрэв `s4bios` нь нэг (`1`) байх юм бол бид `S4`OS-ийн оронд `S4`BIOS дэмжлэгтэй байх юм.

Түр зогсоолт/үргэлжлүүлэлтийг тест хийхдээ хэрэв дэмжигдсэн бол `S1`-ээс эхлээрэй. Энэ төлөв нь драйверийн дэмжлэг барагтаа л шаарддаггүй болохоор бараг л ажиллах болно. Хэн ч `S2`-ийг хийгээгүй байдаг бөгөөд танд энэ хэрэв байгаа бол энэ нь `S1`-тэй адил байна. Дараагийн оролдох зүйл нь `S3` юм. Энэ нь хамгийн гүнзгий STR төлөв бөгөөд таны тоног төхөөрөмжийг дахин зөв эхлүүлэхийн тулд драйверийн ихээхэн дэмжлэг шаарддаг. Хэрэв үргэлжлүүлэх үед танд асуудлууд гарч байгаа бол FreeBSD ACPI захидлын жагсаалт жагсаалт уруу цахим захидал чөлөөтэй илгээгээрэй, гэхдээ илүү их тест хийлт, ажил шаардсан маш олон драйверууд/тоног төхөөрөмжүүд байдаг учир асуудал шийдэгдэхийг хүлээх хэрэггүй юм.

Түр зогсоолт/үргэлжлүүлэлттэй холбоотой түгээмэл асуудал бол олон төхөөрөмжийн драйверууд өөрсдийн эхлүүлэх програм, регистрүүд болон төхөөрөмжийн санах ойг зөв хадгалж, сэргээж, эсвэл дахин эхлүүлж чаддаггүй. Асуудлыг эхний удаа дибаг хийхийг оролдохдоо дараах тушаалыг ажиллуулж үзээрэй:

    # sysctl debug.bootverbose=1
    # sysctl debug.acpi.suspend_bounce=1
    # acpiconf -s 3

Энэ тест нь `S3` төлөв рүү жинхнээсээ оролгүйгээр бүх төхөөрөмжийн драйверуудын түр зогсолт/үргэлжлүүлэлтийн циклийг эмуляц хийдэг. Зарим тохиолдолд энэ аргыг ашиглан та асуудлыг хялбархнаар олж болно (жишээ нь эхлүүлэх програмын төлөв алдагдах, төхөөрөмжийн watchdog timeout болж дуусахгүй дахин оролдох). Систем нь жинхнээсээ `S3` төлөвт орохгүй болохыг санаарай. Тэгэхээр төхөөрөмжүүд нь тэжээлээс салгагдахгүй бөгөөд түр зогсолт/үргэлжлүүлэлтийн арга тэдний хувьд байхгүй гэсэн олонхи нь зүгээр ажиллах болно. Харин жинхэнэ `S3` төлвийн хувьд эсрэгээр байж магадгүй юм.

Хэцүү тохиолдлууд нэмэлт тоног төхөөрөмж шаарддаг, жишээ нь цуваа консолд зориулсан цуваа порт/кабель эсвэл dcons(4)-д зориулсан Firewire порт/кабел болон цөм дибаг хийх чадвар зэргийг дурдаж болно.

Асуудлыг тусгаарлахад туслахын тулд өөрийн цөмөөс аль болох олон драйверуудыг арилгаарай. Хэрэв энэ нь ажиллаж байвал та яг аль драйвер асуудалтай байгааг драйверуудыг амжилтгүй ажиллах хүртэл ачаалан тодорхойлж болох юм. nvidia.ko, X11 дэлгэцийн драйверууд болон USB зэрэг хоёртын драйверууд нь ерөнхийдөө хамгийн их асуудлуудтай байдаг байхад Ethernet интерфэйсүүд ихэвчлэн зүгээр ажилладаг. Хэрэв та драйверуудыг зөв ачаалж/буулгаж чадаж байвал та тохирох тушаалуудыг /etc/rc.suspend болон /etc/rc.resume файлуудад хийж үүнийг автоматжуулж болно. Драйверийг буулгах болон ачаалахад зориулсан тайлбар болгосон жишээ байдаг. Хэрэв таны дэлгэц үргэлжлүүлэлт хийгдсэний дараа заваарсан бол `hw.acpi.reset_video`-г тэг (`0`) болгож үзээрэй. Хэрэв тусламж болохоор бол `hw.acpi.sleep_delay`-г арай урт эсвэл арай богино утгуудаар тохируулж үзээрэй.

Өөр нэг турших зүйл нь ACPI дэмжлэгтэй сүүлийн үеийн Линуксийн түгээлтийг ачаалан тэдний түр зогсоолт/үргэлжлүүлэлтийн дэмжлэгийг адил тоног төхөөрөмж дээр турших явдал юм. Хэрэв Линукс дээр ажиллаж байвал энэ нь FreeBSD-ийн драйверийн асуудал гэсэн үг бөгөөд яг аль драйвер асуудлыг үүсгэж байгааг олсноор асуудлыг засварлахад бидэнд тус болох болно. ACPI-ийг дэмжиж байдаг дэмжигчид нь өөр бусад драйверуудыг (өөрөөр хэлбэл дуу, ATA гэх мэт) ихэвчлэн дэмжин ажилладаггүй болохоор драйверийн асуудлыг мөшгөж хийгдсэн ажил бүр магадгүй эцсийн эцэст FreeBSD-CURRENT захидлын жагсаалт жагсаалт болон драйверийг дэмжигч уруу илгээгдэх хэрэгтэйг санаарай. Хэрэв та адал явдлыг эрж байгаа бол драйверийн үргэлжлүүлэлтийн функцын аль хэсэгт өлгөгдөж байгааг мөшгөхийн тулд зарим дибаг хийх printf(3)-үүдийг асуудалтай драйверт хийж эхлээрэй.

Эцэст нь ACPI-г хааж оронд нь APM-г нээж оролдоорой. Хэрэв түр зогсоолт/үргэлжлүүлэлт APM-тэй байхад ажиллаж байвал та APM-тэйгээ үлдэх нь ялангуяа хуучин тоног төхөөрөмжийн (2000 оноос өмнөх) хувьд бараг дээр байх бизээ. ACPI дэмжлэгийг зөв болгоход үйлдвэрлэгчдэд цаг хугацаа шаардах бөгөөд магадгүй хуучин тоног төхөөрөмжүүд нь ACPI-ийн хувьд BIOS-ийн асуудлуудтай ихэвчлэн байдаг.

#### 12.17.3.3. Систем өлгөгдөх (түр хугацаагаар эсвэл бүрмөсөн)

Ихэнх системийн өлгөгдлүүд нь гээгдсэн тасалдлууд эсвэл тасалдлын шуургын үр дүн юм. Бичил схемүүд нь ачаалахаас өмнө тасалдлуудыг BIOS хэрхэн тохируулдгаас болсон асуудлууд, APIC (MADT) хүснэгтийн зөв байдал болон System Control Interrupt буюу Системийн Хянагч Тасалдлын (SCI) чиглүүлэлт дээр тулгуурласан олон асуудлуудтай байдаг.

Тасалдлын шуургыг `vmstat -i` тушаалын гаралтаас `acpi0` бүхий мөрийг шалгаж гээгдсэн тасалдлуудаас ялгаж болно. Хэрэв тоологч секунд тутам хоёроор нэмэгдэж байвал та тасалдлын шуургатай байна. Хэрэв систем өлгөгдсөн юм шиг байвал DDB (консол дээр `CTRL`+`ALT`+`ESC`) уруу орж `show interrupts` гэж бичих хэрэгтэй.

Тасалдлын асуудлуудтай ажиллаж байхад таны хамгийн шилдэг итгэл найдвар бол loader.conf-д `hint.apic.0.disabled="1"` хэмээн зааж APIC дэмжлэгийг хаах явдал юм.

#### 12.17.3.4. Үймээнүүд

Үймээнүүд нь ACPI-ийн хувьд харьцангуй ховор байдаг бөгөөд засварлах нэн тэргүүн ээлжийн асуудал байдаг. Эхний алхам бол үймээнийг дахин гаргах (хэрэв боломжтой бол) алхмуудыг тусгаарлаж буцах мөрийг (backtrace) авах явдал юм. `options DDB` мөрийг нээж сериал консол (crossref:serialcommsserialconsole-ddb,Цуваа шугамнаас DDB дибаг хийгч уруу орох]-г үзнэ үү) тохируулах эсвэл dump(8) хуваалтыг тохируулах зөвлөгөөг дагаарай. Та буцах мөрийг DDB дээр `tr`-р авч болно. Хэрэв та буцах мөрийг гараар бичих болбол мөр дэх хамгийн доодох тав (5) болон хамгийн дээдэх таван (5) мөрийг хамгийн багадаа бодоход аваарай.

Дараа нь асуудлыг тусгаарлахыг оролдож ACPI-г хааж ачаалж үзээрэй. Хэрэв энэ нь ажиллаж байвал `debug.acpi.disable`-ийн төрөл бүрийн утгуудыг хэрэглэж та ACPI дэд системийг тусгаарлаж болно. Зарим жишээнүүдийг acpi(4) гарын авлагын хуудаснаас үзнэ үү.

#### 12.17.3.5. Түр зогссоны дараа эсвэл унтраасны дараа систем дахин эхлэх

Эхлээд loader.conf(5) дээр `hw.acpi.disable_on_poweroff="0"` гэж тохируулаад үз. Энэ нь унтраах процессийн үед төрөл бүрийн үйл явцуудыг ACPI хаахыг болиулдаг. Энэ зорилгын нэгэн адил зарим системүүд энэ утгыг `1` (анхдагч) болгож тохируулахыг шаарддаг. Энэ нь түр зогсоолт эсвэл унтраалт хийгдсэний дараа аяндаа гарсан систем асаж эхлэх асуудлыг ихэвчлэн засварладаг.

#### 12.17.3.6. Бусад асуудлууд

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

### 12.17.4. ASL, `acpidump`, болон IASL

Хамгийн нийтлэг асуудал бол BIOS үйлдвэрлэгчдийн гаргасан буруу (эсвэл алдаатай!) байткод юм. Энэ нь ихэвчлэн дараах шиг цөмийн консол мэдээллүүдээр ил тод болдог:

    ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\
    (Node 0xc3f6d160), AE_NOT_FOUND

Ихэвчлэн та эдгээр асуудлуудыг өөрийн BIOS-ийг хамгийн сүүлийн хувилбар уруу шинэчилснээр шийдэж болно. Ихэнх консолын мэдээллүүд нь аюулгүй гэхдээ хэрэв танд батарейний төлөв ажиллахгүй гэх мэт өөр бусад асуудлууд байгаа бол тэдгээр мэдээллүүд нь AML-д байгаа асуудлуудыг хайж болох боломжийн газар нь юм. AML гэгддэг байткод нь ASL хэмээгддэг эх хэлээс хөрвүүлэгддэг. AML нь DSDT гэгддэг хүснэгтэд байдаг. Өөрийн ASL-ийн хуулбарыг авахын тулд acpidump(8)-ийг ашиглана. Та `-t` (тогтмол хүснэгтүүдийн агуулгуудыг үзүүлэх) болон `-d` (AML-ийг ASL уруу дизассембл хийх) тохируулгыг хоёуланг нь ашиглах хэрэгтэй. Синтаксын жишээг Дибаг Мэдээллийг Илгээх нь хэсгээс үзнэ үү.

Таны хийж болох хамгийн хялбар анхны шалгалт нь алдаануудыг шалгахын тулд өөрийн ASL-ийг хөрвүүлэх явдал юм. Анхааруулгуудыг ихэвчлэн орхиж болох боловч алдаанууд нь ACPI-г зөв ажиллуулахад гол төлөв саад болдог хорхойнууд байдаг. Өөрийн ASL-ийг дахин хөрвүүлэхдээ дараах тушаалыг ажиллуулна:

    # iasl your.asl

### 12.17.5. Өөрийн ASL-г засварлах нь

Бидний эцсийн зорилго бол бараг хүн болгоны хувьд хэрэглэгчийн ямар ч оролцоогүйгээр ACPI-г ажиллуулах явдал юм. Гэхдээ өнөөг хүртэл бид BIOS үйлдвэрлэгчдийн гаргасан нийтлэг алдаануудад зориулан тойрон гарах арга замуудыг хөгжүүлсээр байгаа билээ. Microsoft®-ийн тайлбарлагч (acpi.sys болон acpiec.sys) нь стандартыг баримталж байгааг чанд шалгадаггүй бөгөөд BIOS-ийн олон үйлдвэрлэгчид ACPI-г зөвхөн Windows® дээр тест хийж өөрсдийн ASL-ийг хэзээ ч засдаггүй. Бид Microsoft®-ийн тайлбарлагчид зөвшөөрөгдсөн ямар стандартын бус ажиллагаа байгааг үргэлжлүүлэн нарийн таньж баримтжуулан хэрэглэгчдээр ASL-ийг хүчлэн засуулалгүйгээр FreeBSD ажиллаж чадахаар түүнийг хуулбарлах болно гэж найдаж байна. Тойрон гарах арга зам болгон биднийг энэ ажиллагааг танихад тусалж та ASL-ийг гараар засварлаж болно. Хэрэв таны хувьд энэ нь ажиллавал хуучин болон шинэ ASL-ийнхээ diff(1)-ийг илгээнэ үү, бид бололцоогоороо ACPI-CA дахь алдаатай ажиллагааг тойрон гарч ингэснээр хойшид таны засвар байнга хийгдэх шаардлагагүй болох юм.

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

#### 12.17.5.1. _OS хамаарлууд

Зарим AML нь ертөнц төрөл бүрийн Windows® хувилбаруудаас тогтдог гэж үздэг. Хэрэв танд байгаа асуудлыг засаж чадаж байвал та FreeBSD-г ямар нэг OS гэж харагдуулахаар хэлж өгч болно. Үүнийг хялбар аргаар дарж бичихийн тулд /boot/loader.conf-д `hw.acpi.osname="Windows 2001"` гэж эсвэл ASL дахь өөр бусад адил мөрүүдийг тохируулж өгнө.

#### 12.17.5.2. Буцах мэдээллүүд байхгүй бол

Зарим аргууд нь стандартын дагуу шууд утга буцаадаггүй. ACPI-CA нь үүнтэй ажиллаж чадахгүй байхад FreeBSD үүнийг далдаар утга буцаалгах боломжийг олгодог тойрон гарах арга замтай байдаг. Хэрэв та утга буцаагдах ёстойг мэдэж байвал шаардлагатай газар нь Return буюу Буцах мэдээллүүдийг шууд нэмж болно. ASL-ийг `iasl` тушаалаар хүчээр хөрвүүлэхдээ `-f` тугийг ашиглана.

#### 12.17.5.3. Анхдагч AML-ийг дарж өөрчлөх нь

your.asl-ийг өөрчилсний дараа үүнийг та хөрвүүлэхдээ:

    # iasl your.asl

Хөрвүүлэх явцад алдаанууд байсан ч гэсэн та `-f` тугийг нэмж AML-ийг хүчээр үүсгэж болно. Зарим алдаануудыг (өөрөөр хэлбэл Буцах мэдээллүүд байхгүй гэх мэт) тайлбарлагчийн тусламжтайгаар автоматаар тойрон гардгийг санаарай.

DSDT.aml нь `iasl`-ийн анхдагч гаралт файлын нэр юм. Та өөрийн BIOS-ийн алдаатай хуулбарын (флэш санах ойд байсаар байгаа) оронд /boot/loader.conf-ийг дараах байдлаар засварлан үүнийг ачаалж болно:

    acpi_dsdt_load="YES"
    acpi_dsdt_name="/boot/DSDT.aml"

Өөрийн DSDT.aml файлын хуулбарыг /boot сан уруу хуулах хэрэгтэй.

### 12.17.6. ACPI-аас дибаг мэдээлэл гаргаж авах нь

ACPI драйвер нь маш уян хатан дибаг хийх боломжтой. Энэ нь дэд системүүдийн олонлог болон харуулах түвшинг зааж өгөхийг танд зөвшөөрдөг. Таны дибаг хийхийг хүсэж байгаа дэд системүүд нь "давхаргууд" болж заагдсан байдаг бөгөөд ACPI-CA хэсгүүд (ACPI_ALL_COMPONENTS) болон ACPI тоног төхөөрөмжийн дэмжлэг (ACPI_ALL_DRIVERS) болж задардаг. Дибаг гаралтын харуулалт нь "үе"ээр заагддаг бөгөөд ACPI_LV_ERROR (зөвхөн алдаануудыг хэлдэг) тогтмолоос ACPI_LV_VERBOSE (бүгд) хүртэл байдаг. "Үе" нь олон тохируулгуудыг нэг удаа зайгаар зааглан тохируулж болох бит баг (bitmask) юм. Хэрэв энэ нь маш урт тэгээд консолын мэдээллийн буферийг арилган шинэчилж байвал та практик дээр гаралтыг бүртгэх сериал консолыг ашиглахыг хүсэж болох юм. Бие даасан давхаргууд болон түвшингүүдийн бүрэн жагсаалт acpi(4) гарын авлагын хуудсанд байдаг.

Дибаг гаралт анхдагчаар идэвхжүүлэгдээгүй байдаг. Идэвхтэй болгохын тулд ACPI хэрэв цөмд хөрвүүлэгдсэн бол `options ACPI_DEBUG` мөрийг өөрийн цөмийн тохиргооны файлд нэмэх хэрэгтэй. Нийтэд нь идэвхтэй болгохын тулд /etc/make.conf-д `ACPI_DEBUG=1` мөрийг нэмж болно. Хэрэв энэ нь модуль бол та өөрийн acpi.ko модулийг дараах маягаар дахин хөрвүүлж болно:

    # cd /sys/modules/acpi/acpi
    && make clean &&
    make ACPI_DEBUG=1

acpi.ko-г /boot/kernel-д суулгаад өөрийн хүссэн давхарга болон түвшинг loader.conf-д нэмнэ. Энэ жишээ нь ACPI-CA-ийн бүх хэсгүүд болон бүх ACPI тоног төхөөрөмжийн драйверуудад (CPU, LID, гэх мэт.) зориулан дибаг мэдээллүүдийг идэвхжүүлдэг. Энэ нь зөвхөн алдааны мэдээллүүдийг хамгийн багаар гаргаж харуулна.

    debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
    debug.acpi.level="ACPI_LV_ERROR"

Хэрэв таны хүссэн мэдээлэл онцгой үйл явцаар эхэлсэн бол (түр зогсоолт болон үргэлжлүүлэлт гэж бодъё) та loader.conf-ийн өөрчлөлтүүдийг орхиж оронд нь `sysctl`-ийг ашиглан давхарга болон түвшинг ачаалсны дараа зааж онцгой үйл явцад зориулан өөрийн системийг бэлдэж болно. `sysctl`-ууд нь loader.conf дахь тохируулгуудын адилаар нэрлэгддэг.

### 12.17.7. Лавлагаанууд

ACPI-ийн талаар дэлгэрэнгүй мэдээллийг дараах байршлуудаас олж болно:

- FreeBSD ACPI захидлын жагсаалт

- ACPI Захидлын Жагсаалтын Архивууд http://lists.freebsd.org/pipermail/freebsd-acpi/

- Хуучин ACPI Захидлын Жагсаалтын Архивууд http://home.jp.FreeBSD.org/mail-list/acpi-jp/

- ACPI Тодорхойлолт

- FreeBSD Гарын авлагын хуудаснууд: acpi(4), acpi_thermal(4), acpidump(8), iasl(8), acpidb(8)

- DSDT дибаг эх үүсвэр. (Compaq-ийг жишээ болгон хэрэглэсэн боловч ерөнхийдөө хэрэгтэй.)

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

Prev
Home
Next