diff --git a/mn_MN.UTF-8/books/handbook/config/chapter.sgml b/mn_MN.UTF-8/books/handbook/config/chapter.sgml index 5ab5f8c404..3544da7963 100644 --- a/mn_MN.UTF-8/books/handbook/config/chapter.sgml +++ b/mn_MN.UTF-8/books/handbook/config/chapter.sgml @@ -1,3114 +1,3114 @@ Шерн Ли Хойно дурдсан заавар болон гарын авлага дээр тулгуурлан бичсэн Майк Смит Зааврыг бичсэн Мэтт Диллон tuning(7)-г бичсэн Цагаанхүүгийн Ганболд Орчуулсан Тохиргоо ба Тааруулалт Ерөнхий агуулга системийн тохиргоо системийн оновчлол &os;-ийн хамгийн чухал зүйлүүдийн нэг нь системийн тохиргоо юм. Зөв системийн тохиргоо нь ирээдүйн шинэчлэлтүүдийн үед толгойн өвчин гаргахгүй байхад тусална. Энэ бүлэг &os; системийг тааруулахад хэрэглэгддэг зарим нэг параметрүүд болон тохиргооны процессийн талаар илүү тайлбарлах болно. Энэ бүлгийг уншсаны дараа, та дараах зүйлсийг мэдэх болно: Файлын системүүд болон хуваалтуудтай хэрхэн үр ашигтай ажиллах талаар. rc.conf тохиргоо болон /usr/local/etc/rc.d эхлэлийн системүүдийн үндсүүд. Сүлжээний картыг хэрхэн тохиргоо болон тест хийх талаар. Сүлжээний төхөөрөмж дээрээ виртуал хостууд хэрхэн тохируулах талаар. /etc дэх төрөл бүрийн тохиргооны файлыг хэрхэн ашиглах талаар. sysctl хувьсагчуудыг ашиглан &os;-ийг хэрхэн тааруулах талаар. Дискний хурдан ажиллагааг хэрхэн тааруулах болон цөмийн хязгааруудыг хэрхэн өөрчлөх талаар. Энэ бүлгийг уншихаасаа өмнө, та дараах зүйлсийг мэдэх шаардлагатай: &unix; болон &os;-ийн үндсийг ойлгох (). Цөмийн тохиргоо/хөрвүүлэлтийн үндсүүдийн талаар ойлголттой байх (). Эхний Тохиргоо Хуваалтын байрлал хуваалтын байрлал /etc /var /usr Үндсэн Хуваалтууд &man.bsdlabel.8; болон &man.sysinstall.8; ашиглан файлын системүүдийг байрлуулахдаа хатуу хөтлөгчүүд өгөгдлийг дотоод замуудаас илүү гаднах замуудаас хурдан шилжүүлдгийг санаарай. Тиймээс жижиг, байнга ханддаг файлын системүүд хөтлөгчийн гадна тал уруу ойрхон байх ёстой бөгөөд /usr зэрэг том хуваалтууд дотор тал уруу байх хэрэгтэй. Хуваалтуудыг иймэрхүү дарааллаар байрлуулах нь зөв юм: root, swap, /var, /usr. /var-ийн хэмжээ төлөвлөсөн машины хэрэглээг тусгадаг. /var нь шуудангийн хайрцгууд, бүртгэлийн файлууд, болон принтерийн spool агуулдаг. Шуудангийн хайрцгууд болон бүртгэлийн файлууд хичнээн хэрэглэгч байгаа болон ямар хугацаанд бүртгэлийн файлууд байхаас хамаараад төсөөлөшгүй хэмжээнд хүртэл ихсэж болдог. Ихэнх хэрэглэгчид гигабайтыг шаардахгүй боловч /var/tmp нь багцуудыг багтаахаар том байх шаардлагатай. /usr хуваалт &man.ports.7; цуглуулга (байлгахыг зөвлөдөг), болон эх код (заавал биш) зэрэг системийг дэмжихэд шаардлагатай ихэнх файлуудыг агуулдаг. Эдгээрийг суулгалтын үед сонгох боломжтой. Энэ хуваалтад хамгийн багаар 2 гигабайтыг зөвлөдөг. Хуваалтын хэмжээг сонгохдоо зайн шаардлагыг бодох хэрэгтэй. Нэг хуваалт нь бараг л ашиглагдахгүй байхад нөгөө нь зайгүй болж байх нь асуудал юм. &man.sysinstall.8;-ийн Auto-defaults хуваалтын хэмжээг өгөгч нь заримдаа /var болон / хуваалтуудад боломжоос бага хэмжээг сонгодгийг зарим хэрэглэгчид олсон байна. Хуваалтыг ухаалгаар харамгүй хийгээрэй. Swap Хуваалт swap хэмжээ нэмэх swap хуваалт Swap хуваалтын хэмжээ системийн санах ойг (RAM) хоёр дахин авсан хэмжээтэй байх ёстой. Жишээлбэл машин 128 мегабайт санах ойтой бол swap файл 256 мегабайт байх ёстой. Бага санах ойтой системүүд их swap-тай бол илүү хурдан ажиллаж болох юм. 256 мегабайтаас бага swap-ийг хэрэглэхийг зөвлөдөггүй бөгөөд санах ойн өргөтгөл хэрэгтэй. Цөмийн VM хуудаслах алгоритмууд нь багаар бодоход гол санах ойг хоёр дахин авсантай тэнцэх swap хуваалттай байх үед хамгийн хурдан ажиллахаар тааруулагдсан байдаг. Хэтэрхий бага swap тохируулах нь VM хуудас скан хийх кодыг үр ашиггүйтэлд хүргэж илүү санах ой хожим нэмэхэд асуудал үүсгэж болох юм. Олон SCSI дискнүүд бүхий (эсвэл олон IDE дискнүүд өөр өөр хянагчууд дээр ажиллаж байгаа) томоохон системүүдэд swap-ийг хөтлөгч болгон дээр (4 хөтлөгч хүртэл) тохируулахыг зөвлөдөг. Swap хуваалтууд нь ойролцоогоор адилхан хэмжээний байх шаардлагатай. Цөм дурын хэмжээтэй ажиллаж чадах боловч дотоод өгөгдлийн бүтцүүд хамгийн том swap хуваалтыг 4 дахин авсантай адил хэмжээгээр томрох боломжтой. Swap хуваалтуудыг ойролцоогоор адил хэмжээтэй байлгах нь swap зайг дискнүүдийн дагуу оновчтойгоор судал үүсгэх боломжийг цөмд олгодог. Swap их ашиглагддаггүй байсан ч гэсэн том swap хэмжээ байж болно. Хүчээр дахин ачаалагдах үед дагаж хаагдсан програмаас өгөгдлийг сэргээх нь амархан байж болох юм. Яагаад Хуваах хэрэгтэй гэж? Зарим хэрэглэгчид ганц том хуваалт байхад болно гэж боддог, гэхдээ энэ нь яагаад буруу болох хэд хэдэн шалтгаан бий. Нэгдүгээрт хуваалт болгон өөр өөр ажиллагааны шинж чанаруудтай бөгөөд тэдгээрийг тусгаарласнаар файлын системийг тэдгээрт тааруулах боломжийг олгодог. Жишээ нь root болон /usr хуваалтууд байнга бичигдэхээсээ илүү ихэвчлэн уншигддаг. Харин уншилт болон бичилт /var болон /var/tmp-д байнга хийгддэг. Системийг зөв хувааснаар ачаалалтай хуваалтуудад хийсэн жижиг бичилтээр гарсан хэсэглэлт илүүдэж байнга уншигддаг хуваалтууд уруу хальдаггүй. Бичилт-ачаалсан хуваалтуудыг дискний ирмэг уруу байрлуулах нь бичилт ихэвчлэн хийгддэг хуваалтууд дахь I/O ажиллагааг хурдасгадаг. Том хуваалтуудад I/O-н хурдан ажиллагаа хэрэгтэй байж болох ч тэдгээрийг дискний ирмэг уруу илүүтэй ойртуулах нь /var-ийг ирмэг уруу шилжүүлснээс илүү мэдэгдэхүйц хурдан ажиллагаанд хүргэхгүй. Эцэст нь найдвартай байдлыг бодох ёстой. Ихэвчлэн уншигддаг, жижиг, цэвэрхэн root хуваалт хэцүү сүйрэл болоход сэргэх боломж нь хамаагүй илүү байна. Гол Тохиргоо rc файлууд rc.conf Системийн тохиргооны мэдээлэл /etc/rc.conf дотор байдаг. Энэ файл нь өргөн хүрээний, зарчмын хувьд системийг эхлэх үед системийг тохируулахад ашиглагддаг тохиргооны мэдээллүүдээс тогтоно. Үүний нэр нь шууд утгыг тодорхойлно; энэ нь rc* файлуудад зориулсан тохиргооны мэдээлэл юм. Администратор /etc/defaults/rc.conf-ийн анхдагч утгуудыг rc.conf файлд өөрчилж оруулах хэрэгтэй. Анхдагчуудын файл /etc уруу хуулагдах ёсгүй - энэ нь жишээ биш анхдагч утгуудыг агуулдаг. Бүх системийн холбогдолтой өөрчлөлтүүд rc.conf файлд өөрт нь хийгдэх ёстой. Удирдлагын нэмэлт ачааллыг байнга бага байлгахын тулд сайт дагуух тохиргоог системийн тусгайлсан тохиргооноос тусгаарлах хэд хэдэн стратеги кластер хийгдсэн програмуудад байж болох юм. Сайтын дагуух тохиргоог /etc/rc.conf.site зэрэг өөр файлд байрлуулж дараа нь энэ файлыг зөвхөн системийн тусгайлсан мэдээллийг агуулдаг /etc/rc.conf-д оруулахыг зөвлөдөг. rc.conf нь &man.sh.1;-ээр уншигддаг болохоор үүнийг хийхэд амархан байна. Жишээ нь: rc.conf: . /etc/rc.conf.site hostname="node15.example.com" network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 10.1.1.1" rc.conf.site: defaultrouter="10.1.1.254" saver="daemon" blanktime="100" Дараа нь rc.conf.site файл систем болгонд rsync эсвэл адил програмаар түгээгдэж болох бөгөөд харин rc.conf файл нь өөр өөр хэвээр байх болно. &man.sysinstall.8; эсвэл make world ашиглан системийг шинэчлэхэд rc.conf файлыг дарж бичихгүй, тэгэхээр системийн тохиргооны мэдээлэл хаягдахгүй. Програмын Тохиргоо Ерөнхийдөө суулгасан програмууд нь өөрийн дүрэм гэх мэт онцлогтой өөр өөрийн тохиргооны файлуудтай байдаг. Эдгээр файлуудыг багц удирдах хэрэгслүүдээр амархан олж удирдаж болохоор үндсэн системээс тусад нь байлгах нь чухал юм. /usr/local/etc Ерөнхийдөө эдгээр файлууд нь /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 портын дараагийн шинэчлэл энэ өөрчлөгдсөн файлыг дарж хуулахгүй. Том Рөүдс Хувь нэмэр болгон оруулсан Цагаанхүүгийн Ганболд Орчуулсан Үйлчилгээнүүдийг эхлүүлэх нь үйлчилгээнүүд Олон хэрэглэгчид Портуудын Цуглуулгаас гуравдагч програм хангамжуудыг &os; дээр суулгахаар сонгодог. Ихэнх тохиолдолд програм хангамжийг систем ачаалахад эхлүүлэхээр тохируулах шаардлагатай байж болох юм. mail/postfix эсвэл www/apache13 зэрэг үйлчилгээнүүд нь системийг ачаалахад эхлүүлж болох програм хангамжийн багцуудын зөвхөн хоёрхон жишээ юм. Энэ хэсэгт гуравдагч програм хангамжийг ажиллуулах процедурын талаар тайлбарлах болно. &os; дээр &man.cron.8; зэрэг ихэнх үйлчилгээнүүд системийн эхлүүлэх скриптүүдийн тусламжтай эхэлдэг. Эдгээр скриптүүд &os; эсвэл үйлдвэрлэгчийн хувилбараас хамааран өөр өөр байна; гэхдээ хамгийн чухал авч үзэх зүйл нь тэдгээрийн эхлэх тохиргоог энгийн эхлүүлэх скриптүүдээр хийх боломжтой явдал юм. rc.d-ээс өмнө програм хангамжууд энгийн эхлүүлэх скриптээ системийн эхлүүлэх скриптүүдийн уншдаг /usr/local/etc/rc.d санд хийдэг байсан. Дараа нь эдгээр скриптүүд нь системийн ачаалалтын сүүлийн шатуудад ажилладаг. Олон хувь хүмүүс хуучин тохиргооны загварыг шинэ систем уруу нийлүүлэх гэж олон цагийг зарсаар байгаа боловч зарим гуравдагч хэрэгслүүд скриптээ дээр дурдсан сан уруу хийхийг шаардсан хэвээр байгаа юм. Скриптүүдийн гол ялгаанууд нь rc.d ашиглаж байгаа эсэхээс хамаарна. &os; 5.1-ээс өмнө хуучин тохиргооны загвар ашиглагдаж байсан бөгөөд бараг бүх л тохиолдлуудад шинэ загварын скриптүүд ч бас зүгээр ажиллах юм. Скрипт бүр зарим хамгийн бага шаардлагыг хангах ёстой боловч ихэнхдээ &os;-ийн хувилбараас хамаарна. Скрипт бүр систем дээр ажиллах боломжтой байх ёстой бөгөөд үүнийг chmod тушаал ашиглан ганц 555 эрхийг заан хийж болно. Мөн хамгийн багаар бодоход програмыг эхлүүлэх болон зогсоох тохируулгууд байх ёстой. Хамгийн энгийн эхлүүлэх скрипт яг энэн шиг харагдах болов уу: #!/bin/sh echo -n ' utility' case "$1" in start) /usr/local/bin/utility ;; stop) kill -9 `cat /var/run/utility.pid` ;; *) echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 Энэ скрипт utility хэмээгдсэн програмд зориулагдсан зогсоох болон эхлүүлэх тохируулгатай байна. Гараар ингэж эхлүүлж болно: &prompt.root; /usr/local/etc/rc.d/utility start Бүх гуравдагч програм хангамжууд rc.conf-д мөр байхыг шаарддаггүй боловч бараг л өдөр болгон шинэ порт энэ тохиргоог авахаар өөрчлөгдөж байна. Тухайн програмын талаар дэлгэрэнгүй мэдээллийг суулгалтын сүүлийн дэлгэцэд гаргасан үр дүнгээс шалгаарай. Зарим гуравдагч програм хангамжууд програмыг rc.d-тэй цуг ашиглахыг зөвшөөрдөг эхлүүлэх скриптүүдтэй байдаг; гэхдээ энэ нь дараагийн хэсэгт хэлэлцэгдэнэ. Програмын Өргөтгөсөн Тохиргоо Одоогийн &os;-ийн rc.d-г агуулдаг нь програмын эхлүүлэх тохиргоог илүү хялбар, боломжтой болгосон. rc.d хэсэгт хэлэлцсэн түлхүүр үгүүдийг ашиглан програмууд жишээ нь DNS зэрэг зарим үйлчилгээнүүдийн дараа ажиллахаар тохируулагдаж болно; эхлүүлэх скриптүүдэд хатуугаар бичигдсэн тугуудын оронд rc.conf-оор нэмэлт тугуудыг өгөхийг зөвшөөрч болох гэх мэт. Үндсэн скрипт дараах байдлаар харагдаж болно: #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # KEYWORD: shutdown # # DO NOT CHANGE THESE DEFAULT VALUES HERE # SET THEM IN THE /etc/rc.conf FILE # utility_enable=${utility_enable-"NO"} utility_flags=${utility_flags-""} utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} . /etc/rc.subr name="utility" rcvar=`set_rcvar` command="/usr/local/sbin/utility" load_rc_config $name pidfile="${utility_pidfile}" start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}" run_rc_command "$1" Энэ скрипт нь өгөгдсөн utility-г daemon үйлчилгээний дараа ажиллуулахаар тохируулагдсан. Мөн PID, эсвэл процессийн ID файлыг заах болон дагах аргыг бас хангадаг. Энэ програм дараах мөрийг /etc/rc.conf файлд оруулж болно: utility_enable="YES" Энэхүү арга нь тушаалын мөрийн нэмэлт өгөгдлүүдийг илүү хялбараар удирдах боломжийг зөвшөөрдөг бөгөөд /etc/rc.subr дахь анхдагч функцуудыг оруулах, &man.rcorder.8; хэрэгсэлтэй нийцтэй байх, болон rc.conf файлын тусламжтай хялбараар тохиргоо хийх боломжийг бас хангадаг. Үйлчилгээнүүдийг эхлүүлэхийн тулд үйлчилгээнүүдийг ашиглах нь POP3 сервер дэмонууд, IMAP зэрэг бусад үйлчилгээнүүд &man.inetd.8; ашиглан эхэлж болдог. Энэ нь Портуудын Цуглуулгаас /etc/inetd.conf файлд нэмэгдэх мөр бүхий эсвэл одоогийн байгаа мөрүүдийн нэгнээс тайлбарыг болиулж идэвхжүүлдэг үйлчилгээний хэрэгслийг суулгаснаар хэрэгждэг. inetd болон түүний тохиргоотой ажиллах талаар inetd хэсэгт гүнзгий тайлбарласан байгаа болно. Зарим тохиолдолд &man.cron.8; ашиглан системийн үйлчилгээнүүдийг эхлүүлэх нь илүү ашигтай байж болох юм. Энэ арга нь хэд хэдэн давуу талуудтай бөгөөд учир нь cron эдгээр процессуудыг crontab-н файлын эзэмшигчийн эрхээр ажиллуулдаг. Энэ нь ердийн хэрэглэгчдэд зарим програмуудыг эхлүүлж ажиллагааг хангах боломжийг олгодог. cron хэрэгсэл @reboot гэсэн бусдад байхгүй боломжийг олгодог бөгөөд цаг хугацааг заах хэсэгт ашиглагдах боломжтой. Энэ нь системийг эхлүүлэх явцад &man.cron.8; эхлэх үед тухайн ажлыг ажиллуулдаг. Том Рөүдс Хувь нэмэр болгон оруулсан Цагаанхүүгийн Ганболд Орчуулсан <command>cron</command> хэрэгслийг тохируулах нь cron тохиргоо &os;-ийн хамгийн ашигтай хэрэгслүүдийн нэг нь &man.cron.8; юм. cron хэрэгсэл ард ажилладаг бөгөөд /etc/crontab файлыг байнга шалгаж байдаг. cron хэрэгсэл /var/cron/tabs сангаас шинэ crontab файлуудыг бас шалгадаг. Эдгээр crontab файлууд нь тусгай функцуудыг агуулдаг бөгөөд эдгээрийг cron тодорхой хугацаанд ажиллуулах ёстой байдаг. cron хэрэгсэл системийн crontab болон хэрэглэгчийн crontab гэсэн хоёр төрлийн тохиргооны файлыг ашигладаг. Энэ хоёр хэлбэршилтийн зөвхөн ялгаа нь зургаа дахь талбар юм. Системийн crontab дээрх зургаа дахь талбар нь тушаалыг ажиллуулах хэрэглэгчийн нэр байдаг. Энэ нь системийн crontab-ийг ямар ч хэрэглэгчийн эрхээр тушаалуудыг ажиллуулах боломж олгодог. Хэрэглэгчийн crontab дээрх зургаа дахь талбар нь ажиллуулах тушаал бөгөөд бүх тушаалууд нь crontab-ийг үүсгэсэн хэрэглэгчийн эрхээр ажилладаг; энэ нь аюулгүй байдлын нэг чухал боломж юм. Хэрэглэгчийн crontab-ууд нь хэрэглэгчдэд root эрхийн шаардлагагүйгээр бодлогуудыг цагийн хуваариар ажиллуулах боломж олгодог. Хэрэглэгчийн crontab дахь тушаалууд нь crontab-ийг эзэмшиж байгаа хэрэглэгчийн эрхээр ажилладаг. root хэрэглэгч бас бусад хэрэглэгчийн нэгэн адил хэрэглэгчийн crontab-тай байж болно. Энэ нь /etc/crontab-аас (системийн crontab) өөр байна. Системийн crontab байдаг учраас root хэрэглэгчийн хувьд ихэнхдээ хэрэглэгчийн crontab шаардлагагүй байдаг. /etc/crontab файлыг (системийн crontab) харцгаая: # /etc/crontab - root's crontab for &os; # # $&os;: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $ # # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log # # #minute hour mday month wday who command # # */5 * * * * root /usr/libexec/atrun &os;-ийн ихэнх тохиргооны файлуудын адил # тэмдэгт тайлбарыг илэрхийлнэ. Тайлбарыг хүсэж байгаа үйлдэл нь юу болох яагаад хийгдэж байгааг сануулах зорилгоор файлд тавьж болдог. Тайлбаруудыг тушаал байгаа мөрд хийж болохгүй бөгөөд ингэсэн тохиолдолд тушаалын хэсэг мэтээр ойлгогдоно; тэдгээр нь шинэ мөрөнд байх ёстой. Хоосон мөрүүдийг тооцохгүй. Эхлээд орчин тодорхойлогдох шаардлагатай. Тэнцүүгийн (=) тэмдэг орчны тохиргоог тодорхойлоход ашиглагддаг бөгөөд энэ жишээн дээр SHELL,PATH, болон HOME тохируулгуудад ашиглагдаж байна. Хэрэв бүрхүүлийн мөрийг орхисон бол cron анхдагч болох sh-ийг ашигладаг. Хэрэв PATH хувьсагчийг орхисон бол ямар ч анхдагч ашиглагдахгүй бөгөөд файлын байрлалууд абсолют байх хэрэгтэй. Хэрэв HOME мөрийг орхисон бол cron ажиллуулж байгаа хэрэглэгчийн гэрийн санг ашигладаг. Энэ мөр нь нийт долоон талбарыг тодорхойлдог. Энд жагсаагдсан утгууд нь minute, hour, mday, month, wday, who, болон command юм. Эдгээрийг нэрээс нь харахад ойлгомжтой. minute нь тушаал ажиллах минутаар илэрхийлэгдсэн хугацаа. hour нь minute-ын адил тохируулга бөгөөд цагаар илэрхийлэгддэг. mday нь сарын өдрийг заана. month нь hour болон minute-тай адил бөгөөд сарыг зааж өгнө. wday тохируулга нь долоо хоногийн өдрийг заана. Эдгээр бүх талбарууд нь тоон утга байх ёстой бөгөөд хорин дөрвөн цагийг дагадаг. who талбар нь тусгай бөгөөд зөвхөн /etc/crontab файлд байдаг. Энэ талбар нь аль хэрэглэгчийн эрхээр тушаал ажиллахыг заадаг. Хэрэглэгч өөрийн crontab файлыг суулгах үед энэ тохируулга байдаггүй. Эцэст нь command тохируулга жагсаагддаг. Энэ нь сүүлийн талбар бөгөөд ажиллуулах тушаалд зориулагдсан байх ёстой. Энэ сүүлийн мөр нь дээр дурдсан утгуудыг тодорхойлдог. Энд бид хэд хэдэн * тэмдэгтүүд дараалсан */5 гэсэн жагсаалт байгааг анзаарах хэрэгтэй. Эдгээр * тэмдэгтүүд нь эхний-эцсийн гэсэн үг бөгөөд үргэлж гэж ойлгогдож болно. Тэгвэл энэ мөрөөс үзэхэд atrun тушаал нь root эрхээр 5 минут тутам аль өдөр сар байгаагаас үл хамааран ажиллана. atrun тушаалын талаар дэлгэрэнгүй мэдээллийг &man.atrun.8; гарын авлагаас үзнэ үү. Тушаалууд тэдгээрт өгч болох дурын тооны тугуудтай байж болно; гэхдээ олон мөр болон уртассан тушаалууд урагшаа ташуу \ үргэлжлүүлэх тэмдэгтээр хуваагдсан байх ёстой. Энэ нь crontab файл болгоны хувьд үндсэн тохиргоо байна, гэхдээ нэг зүйл нь үүнээс өөр байна. Хэрэглэгчийг заадаг зургаа дахь талбар нь зөвхөн системийн /etc/crontab файлд байна. Энэ талбарыг хэрэглэгчийн crontab файлуудын хувьд орхих хэрэгтэй. Crontab суулгах нь Та энд тайлбарласан процедурыг ашиглан системийн crontab-ийг засаж/суулгах шаардлагагүй. Зүгээр л өөрийн дуртай засварлагчийг ашигла: cron хэрэгсэл файл өөрчлөгдсөнийг мэдээд тэр даруй шинэчлэгдсэн хувилбарыг ашиглаж эхэлнэ. Дэлгэрэнгүй мэдээллийг Энэ БХА-ын оруулгаас үзнэ үү. Хэрэглэгчийн бичсэн шинэ crontab файлыг суулгахын тулд эхлээд өөрийн дуртай засварлагчийг ашиглаад зөв хэлбэршилттэй файл үүсгээд дараа нь crontab хэрэгслийг ашигла. Хамгийн их ашиглагддаг тушаал бол: &prompt.user; crontab crontab-file Энэ жишээн дээрх crontab-file нь урд нь үүсгэгдсэн crontab-ийн файлын нэр юм. Суулгасан crontab файлуудыг үзүүлдэг тохируулга бас байдаг: тохируулгыг crontab уруу өгч ажиллуулаад гарах үр дүнг хараарай. Өөрийн crontab файлыг загвар ашиглалгүйгээр эхнээс нь эхлүүлэхийг хүссэн хэрэглэгчдэд зориулсан crontab -e тохируулга байдаг. Энэ нь сонгосон засварлагчийг хоосон файлтай ажиллуулдаг. Файл хадгалагдсаны дараа автоматаар crontab тушаалаар суулгагддаг. Хэрэв та дараа нь өөрийн хэрэглэгчийн crontab-ийг бүр мөсөн устгахыг хүсвэл crontab-ийг тохируулгатай ашиглаарай. Том Рөүдс Хувь нэмэр болгон оруулсан Цагаанхүүгийн Ганболд Орчуулсан &os; дээр rc ашиглах нь 2002 онд &os; системийг эхлүүлэхэд зориулж NetBSD-ийн rc.d системийг оруулсан. Хэрэглэгчид /etc/rc.d сан доторх файлуудыг анзаарах хэрэгтэй. Эдгээр файлуудын ихэнх нь , , болон тохируулгуудаар хянагддаг үндсэн үйлчилгээнүүд байдаг. Жишээ нь &man.sshd.8; нь дараах тушаалаар дахин эхлэж болно: &prompt.root; /etc/rc.d/sshd restart Энэ процедур нь бусад үйлчилгээнүүдийн адил юм. Мэдээж үйлчилгээнүүд ихэнхдээ автоматаар &man.rc.conf.5;-д зааснаар ачаалах үед эхэлдэг. Жишээ нь Сүлжээний Хаяг Хөрвүүлэх дэмонг эхлэх үед ажиллуулахаар нээх нь амархан бөгөөд /etc/rc.conf-д дараах мөрийг нэмдэг: natd_enable="YES" Хэрэв мөр аль хэдийн байвал -ийг болгож өөрчлөөрэй. rc скриптүүд өөр бусад хамааралтай үйлчилгээнүүдийг дараагийн дахин ачаалалтын үеэр доор тайлбарласны дагуу автоматаар ачаалдаг. rc.d систем нь үндсэндээ системийн эхлэх/унтрах үеэр үйлчилгээнүүдийг эхлүүлэх/зогсоох зорилготой бөгөөд стандарт , болон тохируулгууд нь зөвхөн /etc/rc.conf-ийн харгалзах хувьсагчууд заагдсан үед өөрийн үйлдлийг гүйцэтгэдэг. Жишээ нь дээр дурдсан sshd restart тушаал нь /etc/rc.conf-д sshd_enable хувьсагч гэсэн тохиолдолд зөвхөн ажиллана. /etc/rc.conf-д байгаа тохируулгаас үл хамааран үйлчилгээг , эсвэл хийхийн тулд тушаалууд one угтвартай байх шаардлагатай. Жишээ нь sshd-г /etc/rc.conf дахь тохиргооноос үл хамааран дахин эхлүүлэхдээ дараах тушаалыг ашиглана: &prompt.root; /etc/rc.d/sshd onerestart Тохирох rc.d скриптийг тохируулгатай ажиллуулж /etc/rc.conf-д үйлчилгээ нээгдсэн эсэхийг амархан шалгадаг. Тиймээс администратор sshd-г /etc/rc.conf-д нээгдсэн эсэхийг дараах тушаалыг ажиллуулж шалгаж болно: &prompt.root; /etc/rc.d/sshd rcvar # sshd $sshd_enable=YES Хоёр дахь мөр (# sshd) нь root консолынх биш sshd тушаалын гаргасан үр дүн юм. Үйлчилгээг ажиллах байгаа эсэхийг шалгах тохируулга байдаг. Жишээ нь sshd эхэлсэн эсэхийг шалгахдаа: &prompt.root; /etc/rc.d/sshd status sshd is running as pid 433. Зарим тохиолдолд үйлчилгээг хийх бас боломжтой байдаг. Энэ нь үйлчилгээг өөрийн тохиргооны файлуудыг дахин уншихыг зааж үйлчилгээ уруу дохио шидэхийг оролддог. Ихэнх тохиолдолд энэ нь үйлчилгээ уруу SIGHUP дохио шиднэ гэсэн үг юм. Үйлчилгээ болгонд энэ боломжийн дэмжлэг байдаггүй. rc.d систем нь зөвхөн сүлжээний үйлчилгээнд ашиглагдаад зогсохгүй мөн системийн эхлүүлэлтэд бас ихээхэн хувь нэмэр оруулдаг. Жишээ нь bgfsck файлыг авч үзье. Энэ скрипт ажиллахад дараах мэдээллийг хэвлэж гаргана: Starting background file system checks in 60 seconds. Тиймээс энэ файлыг зөвхөн системийг эхлүүлэх үед файлын системийн арын шалгалтыг хийхэд хэрэглэдэг. Системийн олон үйлчилгээнүүд зөв ажиллахын тулд бусад үйлчилгээнүүдээс хамаардаг. Жишээ нь NIS болон бусад RPC дээр тулгуурласан үйлчилгээнүүд rpcbind (portmapper) үйлчилгээ ажиллахаас нааш амжилттай ажилладаггүй. Үүнийг шийдэхийн тулд хамаарлуудын тухай болон бусад мета-өгөгдлийн тухай мэдээллийг эхлүүлэх скрипт бүрийн дээд хэсэгт тайлбараар оруулсан байдаг. &man.rcorder.8; програм хамаарлуудыг хангаж системийн үйлчилгээнүүдийг ямар дарааллаар ажиллуулах ёстойг тогтоохын тулд эдгээр тайлбаруудыг уншдаг. Дараах үгнүүдийг бүх эхлүүлэх скриптэд оруулах ёстой (Эдгээр нь эхлүүлэх скриптийг идэвхжүүлэхэд &man.rc.subr.8;-д шаардлагатай байдаг): PROVIDE: Энэ файлын хангаж байгаа үйлчилгээнүүдийг заана. Дараах үгнүүдийг эхлүүлэх скрипт бүрийн эхэнд оруулж болно. Эдгээр нь заавал шаардлагатай биш боловч &man.rcorder.8;-д тус дөхөм болох ашигтай байдаг: REQUIRE: Энэ үйлчилгээнд шаардлагатай үйлчилгээнүүдийг жагсаана. Энэ файл заагдсан үйлчилгээнүүдийн дараа ажиллана. BEFORE: Энэ үйлчилгээнээс хамааралтай үйлчилгээнүүдийг жагсаана. Энэ файл заагдсан үйлчилгээнүүдийн өмнө ажиллана. Эдгээр түлхүүр үгнүүдийг эхлүүлэх скрипт болгонд болгоомжтойгоор тохируулж өгснөөр бусад зарим &unix; үйлдлийн системүүд шиг ажиллах түвшингүүдтэй (runlevels) зууралдалгүйгээр скриптүүдийн эхлэх дарааллыг маш сайн хянах боломжийг администраторт бий болгох юм. rc.d системийн талаар нэмэлт мэдээллийг &man.rc.8; болон &man.rc.subr.8; гарын авлагын хуудаснуудаас олж болно. Хэрэв та өөрийн rc.d скриптүүд бичих эсвэл байгаагаа сайжруулахыг сонирхож байгаа бол танд бас энэ нийтлэл хэрэгтэй байж болох юм. Марк Фонвил Хувь нэмэр болгон оруулсан Цагаанхүүгийн Ганболд Орчуулсан Сүлжээний интерфэйс картууд суулгах нь сүлжээний картууд тохиргоо Өнөөдөр бид сүлжээний холболтгүй компьютерийн талаар бодох ч аргагүй болсон билээ. Сүлжээний картыг нэмж тохируулах нь &os;-ийн дурын администраторын ердийн ажил болдог. Тохирох драйверийг олох нь сүлжээний картууд драйвер Эхлэхээсээ өмнө та өөрт байгаа картынхаа загвар, түүнд ашигласан бичил схем болон PCI эсвэл ISA картын аль нь эсэхийг мэдэх шаардлагатай. &os; өргөн төрлийн 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 dc0: Ethernet address: 00:a0:cc:da:da:da miibus0: <MII bus> on dc0 ukphy0: <Generic IEEE 802.3u media interface> on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 dc1: Ethernet address: 00:a0:cc:da:da:db miibus1: <MII bus> on dc1 ukphy1: <Generic IEEE 802.3u media interface> on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Энэ жишээн дээр систем дээр байгаа хоёр карт &man.dc.4; драйверийг ашиглаж байгааг бид харж байна. Хэрэв таны NIC-д (Network Interface Card буюу Сүлжээний Интерфэйс Карт) зориулсан драйвер GENERIC-д байхгүй бол та өөрийн NIC-г ашиглахын тулд тохирох драйверийг ачаалах хэрэгтэй. Ингэхийн тулд хоёр аргын аль нэгийг ашиглана: Хамгийн амархан арга нь ердөө л өөрийн сүлжээний картанд зориулсан цөмийн модулийг &man.kldload.8; ашиглан эсвэл тохирох мөрийг /boot/loader.conf-д нэмж ачаалах үед автоматаар ачаалах юм. Бүх NIC драйверууд модуль хэлбэрээр байдаггүй; модулиуд нь байдаггүй төхөөрөмжүүдийн дурдаж болох жишээнүүд гэвэл ISA картууд юм. Өөр нэг арга нь та өөрийн картын дэмжлэгийг цөмд оруулан статикаар хөрвүүлж болох юм. Өөрийн цөмийн тохиргооны файлд юу нэмэх ёстойг мэдэхийн тулд /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES болон драйверийн гарын авлагын хуудсыг шалгаарай. Цөмийг дахин хөрвүүлэх талаар дэлгэрэнгүй мэдээллийг -с үзнэ үү. Хэрэв таны картыг таны цөм (GENERIC) ачаалах явцад илрүүлсэн бол та шинэ цөм бүтээх шаардлагагүй. &windows;-ийн NDIS драйверуудыг ашиглах нь NDIS NDISulator &windows; драйверууд Microsoft Windows Microsoft Windows төхөөрөмжийн драйверууд KLD (kernel loadable object буюу цөмийн ачаалж болох обьект) Харамсалтай нь өөрийн драйверуудад зориулсан схемүүдийг нээлттэй эхийн хүрээнийхэнд өгдөггүй, тийм мэдээллийг худалдааны нууц гэж үздэг олон үйлдвэрлэгчид байсаар байна. Ингэснээр &os; болон өөр үйлдлийн системүүдийн хөгжүүлэгчдэд хоёр сонголт үлдсэн: буцаах инженерчлэлийн хүнд хэцүү, урт хугацааны процессийг туулж драйверуудыг хөгжүүлэх эсвэл µsoft.windows; тавцангуудад байдаг хоёртын хэлбэрийн драйверуудыг ашиглах арга замууд юм. &os;-тэй холбогдсон зэрэг ихэнх хөгжүүлэгчид сүүлийн хандлагыг авч ашигладаг. Билл Полын (wpaul) оруулсан хувь нэмрийн ачаар &os; 5.3-RELEASE-с эхлээд Сүлжээний Драйверийн Интерфэйсийн Тодорхойлолтын (NDIS) эх (native) дэмжлэг ордог болсон. &os; NDISulator (өөрөөр Чөтгөр Төсөл) &windows; хоёртын драйверийг аваад ерөнхийдөө түүнийг &windows; дээр ажиллаж байгаа мэтээр хуурдаг. &man.ndis.4; драйвер нь &windows; хоёртын файл ашиглаж байгаа учраас энэ нь зөвхөн &i386; болон amd64 системүүд дээр хэрэглэгдэх боломжтой. &man.ndis.4; драйвер голчлон PCI, CardBus болон PCMCIA төхөөрөмжүүдийг дэмжихээр хийгдсэн бөгөөд одоогоор USB төхөөрөмжүүдийн дэмжлэг хийгдээгүй. NDISulator ашиглахын тулд танд 3 зүйл хэрэгтэй: Цөмийн эхүүд &windowsxp; драйверийн хоёртын файл (.SYS өргөтгөл) &windowsxp; драйверийн тохиргооны файл (.INF өргөтгөл) Та өөрийн картад зориулсан файлуудыг олоорой. Ерөнхийдөө тэдгээрийг хавсаргасан CD-үүд эсвэл үйлдвэрлэгчүүдийн вэб хуудаснаас олж болно. Дараах жишээнүүдэд бид W32DRIVER.SYS болон W32DRIVER.INF файлуудыг ашиглах болно. Та &windows;/i386 драйверийг &os;/amd64 дээр ашиглаж чадахгүй, зөв ажиллуулахын тулд &windows;/amd64 драйвер заавал олох шаардлагатай. Дараагийн алхамд драйверийн хоёртын файлыг цөмийн ачаалж болох модуль болгон хөрвүүлнэ. Үүнийг хийхийн тулд root эрхээр &man.ndisgen.8;-г хэрэглэнэ: &prompt.root; ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS &man.ndisgen.8; хэрэгсэл нь интерактив бөгөөд шаардлагатай нэмэлт мэдээллийг асуудаг; энэ нь одоо байгаа санд цөмийн модуль үүсгэх бөгөөд дараах маягаар ачаалж болно: &prompt.root; kldload ./W32DRIVER.ko Үүсгэгдсэн цөмийн модулиас гадна та ndis.ko болон if_ndis.ko модулиудыг ачаалах хэрэгтэй. Энэ нь таныг &man.ndis.4;-ээс хамаарсан дурын модулийг ачаалах үед автоматаар хийгдэх ёстой. Хэрэв та тэдгээрийг гараар ачаалахыг хүсвэл дараах тушаалыг ашиглаарай: &prompt.root; kldload ndis &prompt.root; kldload if_ndis Эхний тушаал нь NDIS минипорт драйвер дугтуйлагчийг ачаалах бөгөөд хоёр дахь нь яг сүлжээний интерфэйсийг ачаална. Одоо &man.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.ko-г /boot/modules уруу хуулах хэрэгтэй. Тэгээд дараах мөрийг /boot/loader.conf-д нэмнэ: W32DRIVER_load="YES" Сүлжээний карт тохируулах нь сүлжээний картууд тохиргоо Сүлжээний картанд зориулсан зөв драйвер ачаалагдсаны дараа картыг тохируулах шаардлагатай. Бусад олон зүйлсийн адил сүлжээний карт нь sysinstall програмаар суулгах явцад тохируулагдаж болно. Таны системийн сүлжээний интерфэйсүүдэд зориулсан тохиргоог харуулахын тулд дараах тушаалыг ажиллуулна: &prompt.user; ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:a0:cc:da:da:db media: Ethernet 10baseT/UTP status: no carrier lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 &os;-ийн хуучин хувилбарууд тохируулгыг &man.ifconfig.8;-ийн араас залгахыг шаардаж болох бөгөөд &man.ifconfig.8;-ийн зөв синтаксын дэлгэрэнгүй мэдээллийн талаар гарын авлагын хуудсанд хандана уу. Энэ жишээн дээр IPv6-тай (inet6 гэх мэт.) холбоотой оруулгууд орхигдсон болохыг анхаарна уу. Энэ жишээн дээр дараах төхөөрөмжүүдийг харуулсан: dc0: Эхний Ethernet интерфэйс dc1: Хоёрдугаар Ethernet интерфэйс lp0: Параллел порт интерфэйс lo0: Буцаж эргэх төхөөрөмж tun0: Туннель төхөөрөмж нь ppp-д ашиглагдана. &os; нь драйверийн нэр дээр цөмийн ачаалах явцад картууд ямар дарааллаар илрүүлэгдсэн тэр дарааллын тоог нэмж сүлжээний картыг нэрлэдэг. Жишээ нь sis2 нь систем дээрх &man.sis.4; драйвер ашиглаж байгаа 3 дахь сүлжээний карт байж болох юм. Энэ жишээн дээр dc0 төхөөрөмж босон ажиллаж байна. Түлхүүр индикаторууд нь: UP нь картын тохиргоо хийгдэж бэлэн болсныг илэрхийлнэ. Карт нь Интернэт (inet) хаягтай (энэ тохиолдолд 192.168.1.3). Энэ нь зөв дэд сүлжээний багтай (netmask; 0xffffff00 нь 255.255.255.0 адил). Энэ нь зөв нийтэд цацах хаягтай (энэ тохиолдолд 192.168.1.255). Картны MAC (ether) хаяг нь 00:a0:cc:da:da:da байна. Физик зөөгчийн сонголт нь автомат сонголтын горим дээр байна (media: Ethernet autoselect (100baseTX <full-duplex>)). dc1 нь 10baseT/UTP зөөгчтэй ажиллахаар тохируулагдсан байгааг бид харж болно. Байж болох зөөгчийн төрлүүдийн тухай дэлгэрэнгүй мэдээллийн талаар өөрийнх нь гарын авлагын хуудсанд хандаж үзнэ үү. Холболтын (status) төлөв нь active буюу идэвхтэй байна, өөрөөр хэлбэл дамжуулагч илэрсэн байна. dc1-ийн хувьд бид status: no carrier буюу дамжуулагч байхгүйг харж болно. Энэ нь Ethernet кабель картанд залгагдаагүй байх үед хэвийн байна. Хэрэв &man.ifconfig.8;-ийн үр дүн дараах маягтай төстэй байвал: dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 ether 00:a0:cc:da:da:da Энэ нь карт тохируулагдаагүйг илэрхийлнэ. Картаа тохируулахын тулд танд root зөвшөөрлүүд хэрэгтэй. Сүлжээний картын тохируулгууд тушаалын мөрөөс &man.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 болон бусдуудыг өөрийн картуудад зориулсан төхөөрөмжөөр өөрчлөх болон хаягуудыг зөвөөр солих хэрэгтэй. Зөвшөөрөгдсөн тохируулгуудын талаар дэлгэрэнгүйг картын драйвер болон &man.ifconfig.8;-ийн гарын авлагын хуудаснуудаас, бас &man.rc.conf.5; гарын авлагын хуудаснаас /etc/rc.conf-ийн синтаксын тухай дэлгэрэнгүй мэдээллийг унших хэрэгтэй. Хэрэв та суулгах явцад сүлжээг тохируулсан бол сүлжээний карт(ууд)ын талаар зарим мөрүүд аль хэдийн байж болох юм. Мөрүүд нэмэхээсээ өмнө /etc/rc.conf-ийг дахин шалгаарай. Мөн та LAN дахь төрөл бүрийн машинуудын нэрүүд болон IP хаягууд /etc/hosts файлд байхгүй бол тэдгээрийг нэмж засварлах шаардлагатай. Дэлгэрэнгүй мэдээллийн талаар &man.hosts.5; болон /usr/share/examples/etc/hosts файлд хандана уу. Тест хийх болон алдааг олж засварлах нь /etc/rc.conf-д хэрэгцээтэй өөрчлөлтүүдийг хийснийхээ дараа та системээ дахин ачаалах шаардлагатай. Ингэснээр интерфэйс(үүд)эд хийгдэх өөрчлөлт(үүд)ийг зөвшөөрөх бөгөөд ямар нэг тохиргооны алдаагүйгээр систем ачаалж байгаа эсэхийг шалгадаг. Систем дахин ачаалагдсаны дараа та сүлжээний интерфэйсүүдээ тест хийх хэрэгтэй. Ethernet карт тест хийх нь сүлжээний картууд тест хийх нь Ethernet карт зөв тохируулагдсаныг шалгахдаа та 2 зүйлийг оролдох хэрэгтэй. Эхлээд интерфэйс уруу өөр уруу нь ping хийгээд дараа нь LAN дахь өөр машин уруу ping хийх хэрэгтэй. Эхлээд локал интерфэйсийг тест хийнэ: &prompt.user; 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 хийх хэрэгтэй: &prompt.user; 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-ийн оронд машины нэрийг бас ашиглаж болох болох юм. Алдааг олж засварлах нь сүлжээний картууд алдааг олж засварлах нь Тоног төхөөрөмж болон програм хангамжийн тохиргоонуудын алдааг олж засварлах нь үргэлж зовлон байдаг бөгөөд зовлонг энгийн зүйлүүдийг эхлээд шалгаснаар багасгах боломжтой. Таны сүлжээний кабель холбогдсон уу? Сүлжээний үйлчилгээнүүдээ зөв тохируулсан уу? Галт ханаа зөв тохируулсан уу? Таны хэрэглэж байгаа картыг &os; дэмждэг үү? Алдааны тайланг явуулахаасаа өмнө тоног төхөөрөмжийн тэмдэглэлийг заавал шалгах хэрэгтэй. Өөрийн &os;-ийн хувилбарыг хамгийн сүүлийн STABLE хувилбар уруу шинэчлээрэй. Захидлын жагсаалтын архивууд шалгах буюу эсвэл Интернетээс хайгаарай. Хэрэв карт ажилласан мөртлөө ажиллагаа муу бол &man.tuning.7; гарын авлагын хуудсыг унших нь зүйтэй юм. Мөн буруу сүлжээний тохиргоонууд удаан холболтын шалтгаан болдог учир та сүлжээний тохиргоог бас шалгаж болох юм. Зарим хэрэглэгчид ганц хоёр device timeout мэдээлэлтэй тулгарч болох бөгөөд энэ нь зарим картуудын хувьд хэвийн юм. Хэрэв энэ нь үргэлжлээд эсвэл шаналгаатай болоод эхэлбэл уг төхөөрөмж өөр бусад төхөөрөмжтэй зөрчилдөж байгаа эсэхийг та магадгүй шалгахыг хүсэх байх. Кабелийн холболтуудыг дахин шалгаарай. Магадгүй танд өөр нэг карт хэрэгтэй байж болох юм. Хэрэглэгчид зарим үед цөөн watchdog timeout гэсэн алдаанууд хардаг. Ийм үед эхлээд хийх юм нь сүлжээний кабелийг шалгана. Олон картууд Bus Mastering дэмждэг PCI оролтыг шаарддаг. Зарим нэг эх хавтангуудад үүнийг зөвхөн нэг PCI оролт зөвшөөрдөг (ихэнхдээ 0-р оролт). Энэ нь асуудал байж болох эсэхийг сүлжээний карт болон эх хавтангийн баримтаас шалгаарай. Систем пакетийг зорьсон газар нь чиглүүлж чадахгүй тохиолдолд No route to host мэдээллүүд гардаг. Энэ нь анхдагч чиглүүлэлт заагаагүй тохиолдолд эсвэл кабель салгагдсан бол гардаг. netstat -rn тушаалын үр дүнг үзээд таны хүрэхийг оролдож байгаа тэр хост уруу чинь зөв чиглүүлэлт байгаа эсэхийг шалгаарай. Хэрэв байхгүй бол -г уншаарай. ping: sendto: Permission denied алдааны мэдээллүүд нь буруу тохируулсан галт ханаас ихэвчлэн болдог. Хэрэв ipfw нь цөмд идэвхжсэн бөгөөд ямар ч дүрэм тодорхойлогдоогүй бол анхдагч бодлого нь бүх трафикийг бүр ping хүсэлтийг хүртэл татгалзан хаадаг! Дэлгэрэнгүйг -с уншина уу. Заримдаа картын ажиллагаа муу эсвэл дунджаас доогуур байдаг. Эдгээр тохиолдолд зөөгч сонголтын горимыг autoselect горимоос зөв зөөгчийн сонголт уруу болгож тааруулах нь шилдэг арга юм. Энэ нь ихэнх тоног төхөөрөмжийн хувьд ихэвчлэн ажиллах боловч хүн болгоны хувьд байгаа ийм асуудлыг шийдэхгүй ч байж болох юм. Дахин хэлэхэд бүх сүлжээний тохиргоонуудыг шалгаж &man.tuning.7; гарын авлагын хуудсыг уншаарай. Виртуал Хостууд виртуал хостууд өөр IP хаягууд (alias) &os;-ийн хамгийн түгээмэл хэрэглээ бол нэг сервер сүлжээн дээр олон сервер мэтээр ажиллах виртуал сайт хост хийх боломж юм. Үүнийг нэг интерфэйс дээр олон сүлжээний хаягууд тавьж хийдэг. Өгөгдсөн сүлжээний интерфэйс нь нэг жинхэнэ хаягтай бөгөөд дурын тооны өөр(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" Тохиргооны Файлууд <filename>/etc</filename>-н бүтэц Тохиргооны мэдээллийг хадгалдаг хэд хэдэн сангууд байдаг. Эдгээр нь: /etc Системийн ерөнхий тохиргооны мэдээлэл; энд байгаа өгөгдөл нь системийн хувьд өөр өөр. /etc/defaults Системийн тохиргооны файлуудын анхдагч хувилбарууд. /etc/mail &man.sendmail.8;-ийн нэмэлт тохиргоо, бусад MTA тохиргооны файлууд. /etc/ppp Хэрэглэгч- болон цөмийн-ppp програмуудад зориулсан тохиргоо. /etc/namedb &man.named.8; өгөгдөлд зориулсан анхдагч байрлал. Ихэнхдээ named.conf болон бүсийн файлууд энд хадгалагддаг. /usr/local/etc Суулгагдсан програмуудад зориулсан тохиргооны файлууд. Програм болгоны дэд сангуудыг агуулж болно. /usr/local/etc/rc.d Суулгагдсан програмуудад зориулсан эхлүүлэх/зогсоох скриптүүд. /var/db Багцын өгөгдлийн бааз, байршил олох өгөгдлийн бааз, гэх зэрэг систем болгоны хувьд автоматаар үүсгэгдсэн өгөгдлийн баазын файлууд. Хостын нэрс хостын нэр DNS <filename>/etc/resolv.conf</filename> resolv.conf /etc/resolv.conf нь &os;-ийн тодорхойлогч Интернэт Домэйн Нэрийн Системд (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 ашиглаж байгаа бол &man.dhclient.8; нь DHCP серверээс хүлээн авсан мэдээллээр resolv.conf-г дарж бичдэг. <filename>/etc/hosts</filename> хостууд /etc/hosts нь хуучин Интернэтийн үлдэгдэл энгийн текст өгөгдлийн бааз юм. Энэ нь DNS болон NIS-тэй цуг нэрийг IP хаяг уруу болгож тааруулах боломжийг ханган ажилладаг. LAN-аар холбогдсон локал компьютеруудыг амархан нэрлэх зориулалтаар &man.named.8; сервер суулгаж тохируулахын оронд энд байрлуулж болдог. Мөн /etc/hosts нь түгээмэл ханддаг нэрсэд зориулагдсан гадагшаа хандах хүсэлтийг багасгаж Интернэтийн нэрсийн локал бичлэгийг хангадаг байж болно. # $&os;$ # # # 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 Дэлгэрэнгүй мэдээллийн талаар &man.hosts.5; хуудаснаас зөвлөгөө авна уу. Бүртгэлийн файлын тохиргоо бүртгэлийн файлууд <filename>syslog.conf</filename> syslog.conf syslog.conf нь &man.syslogd.8; програмын тохиргооны файл юм. Энэ нь ямар төрлийн syslog мэдээллүүд яг аль бүртгэлийн файлд бүртгэгдэхийг заадаг. # $&os;$ # # 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) manual page. *.err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cron *.err root *.notice;news.err root *.alert root *.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 #*.* /var/log/all.log # uncomment this to enable logging to a remote log host 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 !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log Дэлгэрэнгүй мэдээллийн талаар &man.syslog.conf.5; гарын авлагын хуудаснаас зөвлөгөө авна уу. <filename>newsyslog.conf</filename> newsyslog.conf newsyslog.conf нь ихэнхдээ &man.cron.8; хуваарилан цагаар ажиллуулдаг &man.newsyslog.8;-д зориулагдсан тохиргоо юм. &man.newsyslog.8; нь хэзээ бүртгэлийн файлууд архивлагдах эсвэл дахин зохицуулагдахыг тодорхойлдог. logfile нь logfile.0 уруу, logfile.0 нь logfile.1 шилжих гэх зэргээр зохицуулагддаг. Бүртгэлийн файлууд өөрөөр &man.gzip.1; хэлбэрээр logfile.0.gz, logfile.1.gz гэх зэргээр нэрлэгдэн архивлагдаж болно. newsyslog.conf нь аль бүртгэлийн файлууд удирдагдах, хичнээн нь хадгалагдах болон хэзээ тэдгээрт хүрэхийг зааж өгдөг. Бүртгэлийн файлууд нь тодорхой хэмжээнд хүрэх үед болон эсвэл тодорхой цаг/огнооны давтамжтайгаар зохицуулагддаг ба/эсвэл архивлагддаг. # configuration file for newsyslog # $&os;$ # # filename [owner:group] mode count size when [ZB] [/pid_file] [sig_num] /var/log/cron 600 3 100 * Z /var/log/amd.log 644 7 100 * Z /var/log/kerberos.log 644 7 100 * Z /var/log/lpd-errs 644 7 100 * Z /var/log/maillog 644 7 * @T00 Z /var/log/sendmail.st 644 10 * 168 B /var/log/messages 644 5 100 * Z /var/log/all.log 600 7 * @T00 Z /var/log/slip.log 600 3 100 * Z /var/log/ppp.log 600 3 100 * Z /var/log/security 600 10 100 * Z /var/log/wtmp 644 3 * @01T05 B /var/log/daily.log 640 7 * @T00 Z /var/log/weekly.log 640 5 1 $W6D0 Z /var/log/monthly.log 640 12 * $M1D0 Z /var/log/console.log 640 5 100 * Z Дэлгэрэнгүй мэдээллийн талаар &man.newsyslog.8; гарын авлагын хуудаснаас зөвлөгөө авна уу. <filename>sysctl.conf</filename> sysctl.conf sysctl 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 sysctl ашиглан тааруулах нь sysctl тааруулах нь sysctl ашиглан &man.sysctl.8; нь ажиллаж байгаа &os; системд өөрчлөлтүүдийг хийхийг танд зөвшөөрдөг интерфэйс юм. Энэ нь туршлагатай системийн администраторын хувьд ажиллагааг мэдэгдэхүйц сайжруулж чадах TCP/IP болон виртуал санах ойн системийн олон нарийн тохируулгуудыг агуулдаг. Таван зуу гаруй системийн хувьсагчуудыг &man.sysctl.8; ашиглан унших болон тохируулж болдог. &man.sysctl.8; нь голдоо хоёр үүргийг гүйцэтгэдэг: системийн тохиргоонуудыг унших болон өөрчлөх. Уншигдаж болох бүх хувьсагчуудыг харахдаа: &prompt.user; sysctl -a Тухайн хувьсагчийг уншихдаа, жишээ нь, kern.maxproc: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 Тухайн хувьсагчийг заахдаа хялбар хувьсагч=утга синтаксийг ашиглаарай: &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 sysctl хувьсагчуудын тохиргоонууд нь ихэвчлэн тэмдэгтүүд (strings), тоонууд эсвэл boolean (boolean 1 нь тийм эсвэл 0 нь үгүй байна) утгууд байна. Хэрэв та машин ачаалах болгонд автоматаар зарим хувьсагчуудыг тохируулахыг хүсвэл /etc/sysctl.conf файлд тэдгээрийг нэмээрэй. Дэлгэрэнгүй мэдээллийн талаар &man.sysctl.conf.5; гарын авлагын хуудас болон -с үзнэ үү. Том Рөүдс Хувь нэмэр болгон оруулсан Цагаанхүүгийн Ганболд Орчуулсан Зөвхөн-унших &man.sysctl.8; Зарим тохиолдолд зөвхөн-унших &man.sysctl.8; утгуудыг өөрчлөх шаардлагатай байж болох юм. Энэ нь заримдаа хийхээс өөр аргагүй байдаг боловч зөвхөн (дахин) ачаалахад хийгдэх боломжтой. Жишээ нь зарим зөөврийн компьютерийн загваруудад &man.cardbus.4; төхөөрөмж нь санах ойн хүрээг шалгадаггүй бөгөөд доор дурдсантай төстэй алдаанууд гарган амжилтгүй болдог: cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 Дээрх шиг тохиолдлууд нь ихэвчлэн зөвхөн уншихаар тохируулагдсан зарим анхдагч &man.sysctl.8; тохиргоонуудыг өөрчлөхийг шаарддаг. Эдгээр нөхцөлүүдийг давж гарахын тулд хэрэглэгч &man.sysctl.8; OID-уудыг тэдгээрийн /boot/loader.conf файлд хийж өгч болно. Анхдагч тохиргоонууд /boot/defaults/loader.conf файлд байрладаг. Дээр дурдсан асуудлыг шийдэхийн тулд хэрэглэгч урьд нь дурдсан файлд гэж тохируулах шаардлагатай. Ингэснээр &man.cardbus.4; зөв ажиллах болно. Дискнүүдийг тааруулах нь Sysctl хувьсагчууд <varname>vfs.vmiodirenable</varname> vfs.vmiodirenable vfs.vmiodirenable sysctl хувьсагч нь 0 (идэвхгүй) эсвэл 1 (идэвхтэй) гэж тохируулагдаж болно; анхдагчаар 1 байна. Энэ хувьсагч нь систем сангуудыг хэрхэн кэш (шуурхай санамж) хийхийг хянадаг. Ихэнх сангууд зөвхөн ганц фрагментийг (ихэвчлэн 1 K) файлын системд болон түүнээс багыг буфер кэшд хэрэглэн жижиг хэмжээтэй байдаг. Энэ хувьсагчийг хааснаар (0 болгосноор) буфер кэш нь таныг асар их хэмжээний санах ойтой байсан ч гэсэн зөвхөн тодорхой тооны сангуудыг кэш хийдэг. Нээгдсэн (1 болгосон) үед энэ sysctl нь бүх санах ойг кэш хийхэд бэлэн болгож буфер кэшд VM Хуудасны Кэшийг хэрэглэн сангуудыг кэш хийх боломжийг олгодог. Гэхдээ сангуудыг кэш хийх хамгийн бага гол дахь санах ой нь 512  байт биш харин физик хуудасны хэмжээ (ихэвчлэн 4 K) байдаг. Хэрэв та их олон тооны файлуудтай ажилладаг үйлчилгээ ажиллуулж байгаа бол бид энэ тохируулгыг идэвхтэй байлгахыг зөвлөж байна. Тийм үйлчилгээнүүдэд вэб кэшүүд, том захидлын системүүд, болон мэдээний системүүд орж болно. Энэ тохируулгыг идэвхтэй байлгах нь хайр гамгүй зарцуулсан санах ойтой байхад ч гэсэн ерөнхийдөө ажиллагааг удаашруулдаггүй, гэхдээ та түүнийг мэдэхийн тулд туршиж үзэж болно. <varname>vfs.write_behind</varname> vfs.write_behind vfs.write_behind sysctl хувьсагчийн анхдагч утга нь 1 (идэвхтэй) байна. Энэ нь том дараалсан файлуудыг бичих үед ихэвчлэн гардаг бүх кластеруудыг цуглуулсан үед зөөгчийн бичилтүүдийг хийхийг файлын системд хэлж өгдөг. Санаа нь бол I/O ажиллагааны хувьд ашиггүй байхад бохир буферууд бүхий буферийн кэшийг замхруулахаас зайлсхийхэд оршдог. Гэхдээ энэ нь процессуудыг зогсоож магадгүй бөгөөд зарим нөхцөл байдалд та магадгүй үүнийг идэвхгүй болгохыг хүсэж болох юм. <varname>vfs.hirunningspace</varname> vfs.hirunningspace vfs.hirunningspace sysctl хувьсагч өгөгдсөн дурын хоромд системийн хувьд бүхэлд нь хэдий хэмжээний хүлээгдэж байгаа бичих I/O-г дискний хянагчуудад өгөх дараалалд оруулж болохыг тодорхойлдог. Анхдагч утга нь ихэвчлэн хангалттай гэхдээ олон дисктэй машинууд дээр та үүнийг дөрөв эсвэл таван мегабайт хүртэл ихэсгэхийг хүсэж болох юм. Утгыг хэтэрхий өндөр тавих нь (буфер кэшийн бичих тогтоосон хэмжээг давах нь) туйлын муу кластерлах ажиллагаанд хүргэж болно. Энэ утгыг хэтэрхий өндөр бүү тавь! Өндөр бичих утгууд нь яг тэр үед хийгдэж байгаа уншилтуудад хоцрогдол нэмж магадгүй юм. Бусад төрөл бүрийн буфер-кэш болон VM хуудасны кэштэй холбоотой sysctl-ууд байдаг. Бид эдгээр утгуудыг өөрчлөхийг зөвлөдөггүй, VM систем нь өөрийгөө автоматаар тааруулж туйлын сайн ажилладаг. <varname>vm.swap_idle_enabled</varname> vm.swap_idle_enabled vm.swap_idle_enabled sysctl хувьсагч нь маш олон хэрэглэгчид таны системд орж гарч байдаг, сул зогссон олон процессуудтай, том, олон-хэрэглэгчийн системүүд дээр ашигтай байдаг. Ийм системүүд нь чөлөөт санах ойн хадгалалтад ихээхэн хэмжээний байнгын дарамтыг үүсгэж байдаг. Энэ боломжийг идэвхтэй болгож ар араас нь swap хийн гаргахыг (зогссон секундээр) vm.swap_idle_threshold1 болон vm.swap_idle_threshold2 хувьсагчуудын тусламжтай тохируулснаар зогссон процессуудтай холбоотой санах ойн хуудаснуудын дарааллыг ердийн хуудаслаж гаргах алгоритмаас илүү хурднаар багасгах боломжийг олгодог. Энэ нь хуудаслаж гаргах дэмонд тусламжийн гарыг өгөх болно. Энэ тохируулгыг танд хэрэгтэй л биш бол идэвхтэй болгож болохгүй, учир нь үүнийг та хийснээр үндсэндээ санах ойг илүү түргэн урьдчилан-хуудаслаж ингэснээр swap болон дискний багтаамжийг илүүтэйгээр идэхэд хүргэх юм. Жижиг систем дээр энэ тохируулга нь тодорхойлогдож болохуйц нөлөөлөлтэй байх ба харин боломжийн хуудаслалт аль хэдийн хийгээд байгаа том системүүдэд энэ тохируулга нь VM системд бүх процессуудыг санах ой уруу болон санах ойгоос хялбараар гаргах боломжийг бүрдүүлдэг. <varname>hw.ata.wc</varname> hw.ata.wc &os; 4.3-д IDE бичих кэш хийлтийг хаасан байдаг. Энэ нь IDE дискэнд бичих багтаамжийг багасгасан боловч хатуу диск үйлдвэрлэгчдийн гаргасан өгөгдлийн бүрэн бүтэн байдлын ноцтой асуудлуудаас болоод шаардлагатай болсон. Тэр асуудал нь IDE хөтлөгчүүд бичилт дуусах үед худлаа мэдээлдэг явдал юм. IDE бичих кэшийг идэвхтэй болгосноор IDE хатуу дискнүүд ямар нэг дараалалгүйгээр бичихээс гадна диск их ачаалалтай үед зарим блокуудыг бичихэд заримдаа тодорхойгүй саатдаг. Сүйрэл болон тэжээлийн уналт файлын системийн ноцтой эвдрэлд хүргэж болзошгүй байдаг. &os;-ийн анхдагч нь аюулгүй байхаар өөрчлөгдсөн. Харамсалтай нь үүний үр дүнд ажиллагааны асар том алдагдалд хүргэсэн бөгөөд хувилбар гарсны дараа бид бичих кэш хийлтийг анхдагчаар идэвхтэй байхаар буцаан өөрчилсөн юм. Та өөрийн систем дээрээ hw.ata.wc sysctl хувьсагчийг ажиглан анхдагч утгыг шалгах хэрэгтэй. Хэрэв IDE бичих кэш хийлт хаалттай бол та цөмийн хувьсагчийн утгыг 1 болгон түүнийг идэвхжүүлж болно. Үүнийг ачаалах үед ачаалагчаас хийх шаардлагатай. Цөм ачаалсны дараа хийхийг оролдвол ямар ч нөлөө үзүүлэхгүй. Дэлгэрэнгүй мэдээллийн талаар &man.ata.4;-с үзнэ үү. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) kern.cam.scsi_delay цөмийн тохируулгууд SCSI_DELAY SCSI_DELAY цөмийн тохиргоо нь системийн ачаалах хугацааг багасгахад хэрэглэгддэг. Анхдагч утга нь нэлээн өндөр бөгөөд 15 секундын саатлыг ачаалах процессийн үед өгөхийг хариуцдаг. 5 секунд хүртэл багасгахад ихэвчлэн ажилладаг (ялангуяа орчин үеийн хөтлөгчүүдийн хувьд). &os;-ийн шинэ хувилбарууд (5.0 болон түүнээс дээш) ачаалах үеийн тохируулга болох kern.cam.scsi_delay хувьсагчийг ашиглах хэрэгтэй. Энэ тохируулга болон цөмийн тохиргооны тохируулга нь секундээр биш миллисекундээр утгыг хүлээн авдаг. Зөөлөн Шинэчлэлтүүд Зөөлөн Шинэчлэлтүүд tunefs &man.tunefs.8; програм файлын системийг нарийн тааруулахад ашиглагдаж болно. Энэ програм нь олон янзын тохируулгуудтай гэхдээ одоохондоо бид зөвхөн Зөөлөн Шинэчлэлтүүдийг идэвхжүүлэх ба хаах дээр анхаарах бөгөөд үүнийг дараах аргаар хийнэ: &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem Файлын систем нь холбогдсон байхдаа &man.tunefs.8;-ээр өөрчлөгдөх боломжгүй. Зөөлөн Шинэчлэлтүүдийг идэвхжүүлэхэд тохирох үе нь аль ч хуваалтууд холболт хийгдээгүй байгаа ганц хэрэглэгчийн горим юм. Зөөлөн Шинэчлэлтүүд нь мета-өгөгдлийн ажиллагааг мэдэгдэхүйц сайжруулдаг бөгөөд санах ойн кэшийг ашиглан голчлон файлын үүсгэлт болон устгалтыг хурдасгадаг. Бид Зөөлөн Шинэчлэлтүүдийг өөрийн бүх файлын системүүдэд ашиглахыг зөвлөж байна. Зөөлөн Шинэчлэлтүүдийн хоёр дутагдалтай талыг та мэдэж байх ёстой: Нэгдүгээрт, Зөөлөн Шинэчлэлтүүд нь сүйрэл болсон тохиолдолд файлын системийн бүрэн бүтэн байдалд баталгаа өгдөг боловч физик дискийг шинэчлэхэд хэдэн секундын (минут ч байж болно!) хоцрогдолтой байж болно. Хэрэв таны систем сүйрэхэд бусад тохиолдлоос илүүтэйгээр та хийсэн ажлаа алдаж болзошгүй юм. Хоёрдугаарт, Зөөлөн Шинэчлэлтүүд нь файлын системийн блокуудыг чөлөөлөхийг саатуулдаг. Хэрэв та бараг дүүрсэн файлын системтэй (root файл систем гэх зэрэг) байгаа бол make installworld зэрэг гол шинэчлэлтийг хийх нь файлын системийг зайгүй болгож шинэчлэлт амжилтгүй болох шалтгаанд хүргэж болох юм. Зөөлөн Шинэчлэлтүүдийн талаар дэлгэрэнгүй Зөөлөн Шинэчлэлтүүд дэлгэрэнгүй Файлын системийн мета-өгөгдлийг диск уруу бичих уламжлалт хоёр хандлага байдаг. (Мета-өгөгдлийн шинэчлэлтүүд нь inode эсвэл сангууд зэрэг агуулгын бус өгөгдөлд хийх шинэчлэлтүүд юм) Түүхээс авч үзэхэд анхдагч ажиллах горим нь мета-өгөгдлийн шинэчлэлтүүдийг синхроноор буюу зэрэг бичдэг байсан явдал юм. Хэрэв сан өөрчлөгдсөн бол систем өөрчлөлтийг диск уруу бичигдэхийг хүлээдэг. Файлын өгөгдлийн буферууд (файлын агуулгууд) буфер кэшээр дамжин диск уруу сүүлд нь асинхроноор хадгалагддаг. Энэ шийдлийн давуу тал нь аюулгүй ажилладаг. Хэрэв шинэчлэлтийн үед амжилтгүй болбол мета-өгөгдөл нь үргэлж бүрэн бүтэн байдаг. Файл эсвэл бүрэн үүсч эсвэл бүр ерөөсөө үүсдэггүй. Хэрэв файлын өгөгдлийн блокууд сүйрэл болох үед буферийн кэшээс диск уруу өөрсдийн гарах замаа олохгүй байгаа бол &man.fsck.8; нь үүнийг таньж файлын уртыг 0 болгон файлын системийг засварладаг. Нэмж хэлэхэд энэ шийдэл нь цэвэрхэн ба хялбар юм. Сул тал нь мета-өгөгдлийн өөрчлөлтүүд нь удаан байдаг. rm -r тушаал жишээ нь сан дахь бүх файлуудад дараалан хандах бөгөөд гэхдээ сан болгоны өөрчлөлт (файлын устгалт) синхроноор зэрэг диск уруу бичигддэг. Үүнд сан уруу өөрт нь хийгдэх шинэчлэлтүүд, inode хүснэгт болон магадгүй файлын гаргасан шууд бус блокуудад хийх шинэчлэлтүүд ордог. Том иерархуудыг задлахад (tar -x) үүний нэгэн адилаар авч үздэг. Хоёр дахь нь асинхрон мета-өгөгдлийн шинэчлэлтүүд юм. Энэ нь Линукс/ext2fs-ийн хувьд анхдагч байх бөгөөд *BSD ufs-ийн хувьд mount -o async байх юм. Бүх мета-өгөгдлийн шинэчлэлтүүд нь буфер кэшээр бас дамждаг, тэгэхээр тэдгээр нь файлын агуулгын өгөгдлийн шинэчлэлтүүдтэй харилцан холилдох болно. Энэ шийдлийн давуу тал нь мета-өгөгдөл бүрийн шинэчлэлт диск уруу бичигдэхийг хүлээдэггүй бөгөөд ингэснээр ихээхэн хэмжээний мета-өгөгдлийн шинэчлэлтүүдийг хийдэг бүх үйлдлүүд синхрон хийгдэхээс хамаагүй хурдан ажилладаг. Мөн энэ шийдэл нь цэвэрхэн бас энгийн бөгөөд ингэснээр хорхойнууд (алдаа) код уруу мөлхөн орох эрсдэл бага юм. Сул тал нь файлын системийн бүрэн бүтэн төлвийн ямар нэг баталгаа ерөөсөө байдаггүй. Хэрэв их хэмжээний мета-өгөгдөл шинэчлэх үйлдлийн явцад амжилтгүй болсон бол (тэжээлийн тасалдал, эсвэл хэн нэг нь дахин эхлүүлэх товч дарсан зэрэгт) файлын систем тааж болшгүй төлөвт үлдэх болно. Систем дахин ачаалаад дуусахад файлын системийн төлөвийг мэдэх боломжгүй байдаг; inode хүснэгт эсвэл холбоотой сангийн шинэчлэлтүүд бичигдээгүй байхад файлын өгөгдлийн блокууд диск уруу аль хэдийн бичигдчихсэн байж болох юм. Ер нь гаргасан замбараагүйтлийг (учир нь хэрэгцээтэй мэдээлэл диск дээр байхгүй) цэвэрлэж чаддаг fsck тушаалын шийдлийг хийх боломжгүй. Хэрэв файлын систем засвар хийж чадахааргүй эвдэрсэн бол түүнд дээр &man.newfs.8;-ийг хэрэглэж нөөцөөс сэргээхээс өөр аргагүй юм. Энэ асуудлын шийдэл нь бохир бүсийн бүртгэл буюу бас журналчлалт гэгддэг шийдлийг гаргах явдал бөгөөд энэ ухагдахуун нь тогтвортой хэрэглэгддэггүй ба шилжүүлэлтийн бүртгэлийн бусад хэлбэрүүдэд бас заримдаа ашиглагддаг. Мета-өгөгдлийн шинэчлэлтүүд нь синхроноор бичигдсэн хэвээр байх бөгөөд гэхдээ зөвхөн дискний жижиг бүсэд бичигдэнэ. Дараа нь тэдгээрийг тэдний зөв байрлал уруу зөөдөг. Бүртгэлийн талбар нь диск дээр бага, үргэлжилсэн бүс байдаг учраас бүр хүнд үйлдлүүдийн үед ч гэсэн дискний толгойнууд шилжихэд хол зайтай биш байдаг болохоор эдгээр үйлдлүүд нь синхрон шинэчлэлтүүдээс илүү хурдан байдаг. Мөн энэ шийдлийн төвөгтэй байдал нь маш хязгаарлагдмал болохоор алдаанууд байх эрсдэл нь бага байдаг. Сул тал нь бүх мета-өгөгдөл нь хоёр удаа бичигддэг (бүртгэлийн бүсэд нэг удаа болон зөв байрлал уруу бас нэг удаа) болохоор энгийн ажлын хувьд ажиллагааны өөдрөг бус үзэгдэл гарч болзошгүй юм. Нөгөө талаас сүйрэл болоод систем дахин ачаалаад дуусахад хүлээгдэж байгаа бүх мета-өгөгдлийн үйлдлүүд бүртгэлийн талбараас хурдан буцаагдаж эсвэл гүйцэд хийгдэн дуусч болох бөгөөд энэ нь файлын системийг хурдан эхлүүлэхэд хүргэдэг. Беркли FFS-ийн хөгжүүлэгч Кирк МкКюзик энэ асуудлыг Soft Updates буюу Зөөлөн Шинэчлэлтүүдээр шийдсэн: хүлээгдэж байгаа бүх мета-өгөгдлийн шинэчлэлтүүд нь санах ойд хадгалагдах бөгөөд диск уруу эрэмбэлэгдсэн дарааллаар бичигддэг (дараалуулсан мета-өгөгдлийн шинэчлэлтүүд). Энэ нь мета-өгөгдлийн хүнд үйлдлүүдийн үед хэрэв эрт хийгдсэн шинэчлэлтүүд диск уруу бичигдээгүй санах ойд байж байхад нь сүүлд хийгдэх шинэчлэлтүүд тэдгээрийг барьж авдаг. Тэгэхээр сангийн хувьд хэлбэл түүнд хийгдэх бүх үйлдлүүд нь санах ойд шинэчлэлт диск уруу бичигдэхээс өмнө хийгддэг (өгөгдлийн блокууд нь мета-өгөгдлөөсөө түрүүлээд диск дээр байж байхгүйгээр өөрсдийн байрлалынхаа дагуу эрэмбэлэгддэг ). Хэрэв систем сүйрвэл энэ нь бүртгэл урагшлуулахад хүргэдэг: диск уруу гарах замаа олохгүй байгаа бүх үйлдлүүд хэзээ ч хийгдээгүй юм шиг байдаг. Файлын системийн бүрэн бүтэн төлөв хадгалагдаж 30-аас 60 секундын өмнөх төлөвт ордог. Хэрэглэгдэж байгаа эх үүсвэрүүдийг тэдгээрийн өөрсдийнх харгалзах битмапуудад: блокууд болон inode-уудад байдаг шигээр тэмдэглэхийг үүнд ашигласан алгоритм нь баталгаатай хангадаг. Сүйрэл болсны дараа зөвхөн гарсан эх үүсвэр суллан гаргалтын алдаа нь яг үнэндээ чөлөөтэй мөртлөө ашиглагдаж байгаа гэж тэмдэглэгдсэн эх үүсвэрүүд байдаг. &man.fsck.8; энэ байдлыг таних бөгөөд ашиглагдаагүй байгаа эх үүсвэрүүдийг чөлөөлдөг. Сүйрлийн дараа файлын системийн бохир төлвийг авч үзэлгүйгээр хүчээр mount -f тушаалаар холбох нь аюулгүй юм. Ашиглагдаагүй байж болзошгүй эх үүсвэрүүдийг чөлөөлөхдөө &man.fsck.8;-г сүүлд нь ажиллуулах хэрэгтэй. Энэ нь ард ажиллах fsck-ийн цаана байгаа санаа юм: системийг эхлүүлэх үед зөвхөн файлын системийн хормын зураг бичигддэг. fsck-г сүүлд нь ажиллуулж болно. Дараа нь бүх файлын системүүд бохир холбогдож системийн эхлэлт олон хэрэглэгчийн горимд үргэлжилдэг. Дараа нь ард ажиллах fsck-үүд ашиглагдаагүй байгаа эх үүсвэрүүдийг чөлөөлөхөөр шаардлагатай байгаа бүх файлын системийн хувьд ажиллахаар төлөвлөгддөг. (Зөөлөн Шинэчлэлтүүд ашигладаггүй файлын системүүдэд ердийн нүүрэн дээр ажиллах fsck хэрэгтэй хэвээр байна) Давуу тал нь мета-өгөгдлийн үйлдлүүд нь асинхрон шинэчлэлтүүдтэй бараг л адил хурдан байдаг (өөрөөр хэлбэл мета-өгөгдлийг хоёр дахин бичдэг бүртгэл хийлтээс хурдан байдаг). Сул талууд нь төвөгтэй код (хэрэглэгчийн өгөгдлийн алдагдлын хувьд их мэдрэмтгий талбар дахь байж болох алдаануудын тэр өндөр эрсдэлийг хэлж байна) болон санах ойн илүү хэрэглээ юм. Мөн хэн нэгний хэрэглэж байсан хувийн тохиргоонууд ч бас байдаг. Сүйрэл болсны дараа файлын системийн төлөв хуучин юм шиг харагддаг. Стандарт синхрон хандлага нь fsck-ийн дараа зарим нэг тэг-урттай файлуудыг үлдээхэд хүргэсэн нөхцөлд тэдгээр файлууд нь Зөөлөн Шинэчлэлтүүдтэй файлын системийн үед огт байдаггүй бөгөөд учир нь мета-өгөгдөл болон файлын агуулгууд хэзээ ч диск уруу бичигдээгүй байдаг. Дискний зай нь магадгүй rm ажиллуулснаас хэсэг хугацааны дараа диск уруу шинэчлэлтүүд бичигдэх хүртэл сулардаггүй. Энэ нь бүх файлуудыг хоёр дахин хадгалахад хангалттай хүрэлцэхүйц хэмжээний чөлөөтэй зай байхгүй файлын систем дээр их хэмжээний өгөгдлийг суулгаж байх үед асуудлууд гарахад хүргэж болох юм. Цөмийн хязгаарууд тохируулах нь тохируулах нь цөмийн хязгаарууд Файл/Процессийн хязгаарууд <varname>kern.maxfiles</varname> kern.maxfiles kern.maxfiles нь таны системийн шаардлагуудаас хамаараад дээшилж эсвэл доошилж болно. Энэ хувьсагч нь таны систем дээрх файлын тодорхойлогчуудын (descriptor) хамгийн их тоог илэрхийлдэг. Файлын тодорхойлогчийн хүснэгт дүүрсэн тохиолдолд file: table is full буюу файл: хүснэгт дүүрсэн гэсэн мэдээлэл давтагдан системийн богино мэдээллийн буфферт үзэгдэх бөгөөд үүнийг dmesg тушаал ашиглан үзэж болдог. Нээлттэй файл, сокет эсвэл fifo болгон нэг файлын тодорхойлогч хэрэглэдэг. Ажиллаж байгаа том-хэмжээний сервер зэрэгцээ ажиллаж байгаа үйлчилгээнүүдийн тоо болон төрлөөс хамааран олон мянган файлын тодорхойлогчуудыг өлхөн шаардаж болох юм. Хуучин FreeBSD хувилбаруудад kern.maxfiles-ийн анхдагч утга нь таны цөмийн тохиргооны файлын тохируулгаас гарсан байдаг. kern.maxfiles нь утгатай пропорционалаар өсдөг. Өөрчлөн тохируулсан цөмийг бүтээхдээ энэ цөмийн тохиргооны тохируулгыг өөрийн системийн хэрэглээний дагуу зааж өгөх нь зүйтэй байдаг. Энэ тооноос хамаарч цөм өөрийн ихэнх урьдчилан-тодорхойлсон хязгааруудыг өгдөг. Ажиллагаанд байгаа машин яг үнэндээ нэг удаа 256 хэрэглэгч зэрэг холбогдоогүй байж болох боловч өндөр-хэмжээний вэб серверийнхтэй адил эх үүсвэрүүд хэрэгтэй байж болох юм. kern.maxusers хувьсагч нь системд байгаа санах ойн дээр үндэслэн ачаалах үед автоматаар тавигддаг бөгөөд ажиллаж байх явцад зөвхөн уншигдах kern.maxusers sysctl хувьсагчийн утгыг шалгаж тогтоогдож болох юм. Зарим сайтууд kern.maxusers-ийн илүү их эсвэл бага утгуудыг шаардаж үүнийг ачаалагчаар тааруулагдахаар тохируулж болох юм; 64, 128, болон 256 утгууд нь ховор байдаг. Танд асар их тооны файлын тодорхойлогчууд хэрэгтэй л биш бол бид 256-аас дээш байлгахыг зөвлөдөггүй; өөрсдийн анхдагч утгуудад kern.maxusers-р заагддаг, тааруулагдах боломжтой утгуудын олонх нь тус тусдаа ачаалалтын үед эсвэл ажиллах явцад /boot/loader.conf-оор эсвэл энэ баримтын хаа нэгтээ тайлбарласнаар өөрчлөгдөж болдог (&man.loader.conf.5; гарын авлага эсвэл /boot/defaults/loader.conf файлыг санаа авахын тулд үзнэ үү). Хуучин хувилбаруудад хэрэв та maxusers-ийг 0 гэж шууд зааж өгсөн бол систем автоматаар тааруулж өгдөг Автоматаар тааруулах алгоритм maxusers-ийг систем дэх санах ойн хэмжээтэй адилаар хамгийн багадаа 32 ба хамгийн ихдээ 384 гэж зааж өгдөг.. Энэ тохируулгыг заахдаа ялангуяа та хэрэв X Цонхны Систем ашиглаж байгаа эсвэл програм хангамж хөрвүүлж байгаа бол maxusers-ийг хамгийн багадаа 4 гэж заахыг хүсэх болно. Шалтгаан нь гэвэл maxusers-ээр заагдсан хамгийн чухал хүснэгт бол 20 + 16 * maxusers гэж заагдсан процессуудын хамгийн их тоо бөгөөд хэрэв та maxusers-ийг 1 гэж заасан бол та 18 орчмыг нь ачаалах үед системийг эхлүүлэхэд болон 15 орчмыг нь таныг X Цонхны Системийг эхлүүлэхэд магадгүй үүсэж та нийт зөвхөн 36 зэрэг процесстой байж болох юм. Гарын авлагыг унших зэрэг хялбар бодлого хүртэл шүүх, шахсаныг задлах, болон үзэхэд зориулж есөн процессийг эхлүүлдэг. maxusers-ийг 64 гэж заах нь бараг л бүх хэрэгцээнд хангалттай байх 1044 зэрэг процесстой байж болохыг танд зөвшөөрнө. Гэхдээ өөр програм эхлүүлэхээр оролдож байх үед эсвэл их олон тооны зэрэгцээ хэрэглэгчидтэй сервер (ftp.FreeBSD.org-той адил) ажиллуулж байхад айдас төрүүлэм proc table full буюу proc хүснэгт дүүрсэн гэсэн алдаа хэрэв та харах юм бол үргэлж энэ тоог ихэсгэн цөмийг дахин бүтээж болох юм. maxusers нь таны машин уруу нэвтрэх хэрэглэгчдийн тоог хязгаарладаггүй. Энэ нь ердөө л таны систем дээр байж болох хамгийн их хэрэглэгчийн тоо болон тэдгээр тус бүрийн ажиллуулах процессийн тооноос хамааран төрөл бүрийн хүснэгтийн хэмжээнүүдийг боломжийн утгуудаар зааж өгдөг. <varname>kern.ipc.somaxconn</varname> kern.ipc.somaxconn kern.ipc.somaxconn sysctl хувьсагч нь шинэ TCP холболтуудыг хүлээн авахад зориулсан сонсох дарааллын хэмжээг хязгаарладаг. Анхдагч утга 128 нь ачаалал ихтэй вэб серверийн орчин дахь шинэ холболтуудыг хүлээж авахад ерөнхийдөө хэтэрхий бага юм. Тийм орчны хувьд энэ утгыг 1024 эсвэл түүнээс их болгохыг зөвлөдөг. Үйлчилгээний дэмон нь өөрөө сонсох дарааллын хэмжээгээ (өөрөөр хэлбэл &man.sendmail.8;, эсвэл Apache) хязгаарлаж болох боловч ихэвчлэн өөрийн тохиргооны файлдаа дарааллын хэмжээг тааруулах тохиргооны мөртэй байдаг. Их хэмжээний сонсох дарааллууд нь бас Үйлчилгээг Зогсоох халдлагуудаас (DoS) илүү сайн зайлсхийж ажилладаг. Сүлжээний хязгаарууд NMBCLUSTERS цөмийн тохиргооны тохируулга нь системд байгаа сүлжээний Mbuf-уудын тоог зааж өгдөг. Бага тооны Mbuf-уудтай трафикийн ачаалал ихтэй сервер &os;-ийн чадварт саад болдог. Кластер бүр ойролцоогоор 2 K санах ойг илэрхийлдэг, тийм болохоор 1024 гэсэн утга нь сүлжээний буферуудад зориулж хадгалсан 2 мегабайт цөмийн санах ойг илэрхийлнэ. Хичнээн хэрэгтэйг олохын тулд хялбар тооцоо хийж болно. Хэрэв та хамгийн ихдээ 1000 зэрэгцээ холболтуудтай, холболт бүр нь 16 K хүлээн авах болон 16 K илгээх буферийг иддэг вэб сервертэй бол танд ойролцоогоор вэб серверийг хангахын тулд 32 MB хэмжээтэй тэнцэх сүлжээний буферууд хэрэгтэй болно. Практикаар ер нь 2-оор үржүүлдэг, тэгэхээр 2x32 MB / 2 KB = 64 MB / 2 kB = 32768 болох юм. Бид их санах ойтой машинуудын хувьд утгуудыг 4096-аас 32768-ын хооронд байлгахыг зөвлөдөг. Энэ параметрийн хувьд өндөр утгыг ямар ч нөхцөлд тавьж болохгүй, учир нь энэ нь ачаалах үеийн сүйрэлд хүргэж болно. &man.netstat.1;-д тохируулгыг ашиглаж сүлжээний кластерийн ашиглалтыг ажиглаж болох юм. kern.ipc.nmbclusters ачаалалтын тааруулах боломжтой тохируулга нь ачаалах үед үүнийг тааруулахад хэрэглэгдэх ёстой. Зөвхөн &os;-ийн хуучин хувилбарууд NMBCLUSTERS цөмийн &man.config.8; тохируулгыг ашиглахыг танаас шаарддаг. &man.sendfile.2; системийн дуудлагыг өргөнөөр ашигладаг завгүй серверүүдийн хувьд NSFBUFS цөмийн тохиргооны тохируулгын тусламжтай эсвэл түүний утгыг /boot/loader.conf-д зааж &man.sendfile.2; буферуудын тоог ихэсгэх шаардлагатай байж болох юм (дэлгэрэнгүйг &man.loader.8;-с үзнэ үү). Процессууд sfbufa төлөвт харагдах нь энэ параметрийг тааруулах хэрэгтэйг ихэвчлэн заадаг. kern.ipc.nsfbufs sysctl хувьсагч нь цөмөөр тохируулагдсан хувьсагч дахь зөвхөн уншигддаг гялбаа юм. Энэ параметр нь kern.maxusers-ийн хэмжээгээр тааруулагддаг, гэхдээ үүнийг түүний дагуу тохируурах шаардлагатай байж болох юм. Сокет блок-хийгддэггүй гэж тэмдэглэгдсэн ч гэсэн блок-хийгддэггүй сокет дээр &man.sendfile.2;-ийг дуудах нь хангалттай хэмжээний struct sf_buf-уудыг бий болготол &man.sendfile.2; дуудлага блок хийгдэхэд хүргэж болох юм. <varname>net.inet.ip.portrange.*</varname> 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-ийг багасгахыг зөвлөдөггүй. TCP хурд сааруулагч бүтээгдэхүүнүүд TCP хурд сааруулагч бүтээгдэхүүний хязгаарлалт net.inet.tcp.inflight.enable 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 болгож) бас багасгаж болох юм. Эдгээр параметрүүдийг багасгах нь хамгийн сүүлд авах арга хэмжээ байх ёстой юм. Виртуал санах ой <varname>kern.maxvnodes</varname> vnode нь файл эсвэл сангийн дотоод дүрслэл юм. Тэгэхээр үйлдлийн системд байх vnode-ийн тоог ихэсгэх нь диск I/O-г багасгадаг. Энэ нь ихэвчлэн үйлдлийн системээр зохицуулагддаг бөгөөд өөрчлөх хэрэггүй байдаг. Зарим тохиолдолд диск I/O нь гол асуудал учруулж системд vnode байхгүй болж байвал энэ тохируулгыг ихэсгэх хэрэгтэй болно. Идэвхгүй болон чөлөөтэй RAM-ийн хэмжээг бодолцох шаардлагатай. Тухайн үед ашиглагдаж байгаа vnode-уудыг үзэхдээ: &prompt.root; sysctl vfs.numvnodes vfs.numvnodes: 91349 Хамгийн их vnode-уудыг үзэхдээ: &prompt.root; sysctl kern.maxvnodes kern.maxvnodes: 100000 Хэрэв тухайн үеийн vnode ашиглалт хамгийн их хэмжээ уруу бараг дөхөж байвал kern.maxvnodes-ийг 1,000-аар ихэсгэх нь зүйтэй байж болох юм. vfs.numvnodes-ийн тоон дээр бас анхаарлаа хандуулаарай. Хэрэв энэ нь дахин хамгийн их уруугаа дээшилбэл kern.maxvnodes-ийг цааш ихэсгэх шаардлагатай болно. &man.top.1;-ийн гаргасан дүнгээс таны санах ойн өөрчлөлт харагдах ёстой. Түрүүнийхээс илүү санах ой идэвхтэй байх ёстой. Swap зай нэмэх нь Та яаж ч сайн төлөвлөсөн байлаа гэсэн заримдаа систем таны бодсоноор ажилладагүй. Хэрэв танд swap зай илүү хэрэгцээтэйг мэдвэл та үүнийг амархнаар нэмж болно. Та гурван аргаар swap зайг ихэсгэж болно: шинэ хатуу диск нэмэх, NFS-ийн тусламжтай swap идэвхжүүлэх болон байгаа хуваалт дээр swap файл үүсгэж ихэсгэж болно. Swap зайг хэрхэн шифрлэх, ямар тохируулгууд байгаа болон яагаад хийх ёстой талаар гарын авлагын хуудсанд хандана уу. Шинэ диск дээрх swap Мэдээж swap нэмэх хамгийн шилдэг арга нь энэ боломжийг шалтаг болгон ашиглаж өөр хатуу диск нэмэх явдал юм. Ер нь та үргэлж өөр хатуу диск ашиглаж болно л доо. Хэрэв та ингэх бол өөрийн swap-аа хэрхэн хамгийн шилдгээр зохион байгуулж болох талаар дурдсан зарим зөвлөгөөнүүдийн тухай Гарын авлагын дахь swap зайн хэлэлцүүлгээс дахин уншаарай. NFS-ийн тусламжтай swap хийх нь NFS-ийн тусламжтай swap хийхийг зөвхөн swap хийх локал хатуу диск танд байхгүй үед л зөвлөдөг; NFS swap хийх нь байгаа сүлжээний хурдаар хязгаарлагддаг бөгөөд NFS серверт нэмэлт ачаалал үзүүлдэг. Swap файлууд Та swap файл болгон ашиглахаар заасан хэмжээтэй файлыг үүсгэж болно. Энд байгаа жишээн дээр бид /usr/swap0 гэсэн нэртэй 64MB файлыг ашиглана. Мэдээж та хүссэн ямар ч нэрээ ашиглаж болно. Swap файл &os; дээр үүсгэх нь Таны цөмийн тохиргоонд санах ойн дискний драйвер (&man.md.4;) орсон эсэхийг шалгаарай. Энэ нь GENERIC цөмд анхдагчаар орсон байдаг. device md # Memory "disks" Swap файл (/usr/swap0) үүсгэнэ: &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Зөв зөвшөөрлүүдийг (/usr/swap0-д) нээж тохируулна: &prompt.root; chmod 0600 /usr/swap0 /etc/rc.conf-д swap файлыг идэвхжүүлнэ: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. Машиныг дахин эхлүүлнэ эсвэл swap файлыг шууд идэвхжүүлэхийн тулд дараах тушаалыг ажиллуулна: &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Хитэн Пандиа Бичсэн Том Рөүдс Цагаанхүүгийн Ганболд Орчуулсан Тэжээл болон Эх үүсвэрийн Удирдлага Тоног төхөөрөмжийн эх үүсвэрүүдийг үр ашигтай ашиглах нь чухал юм. ACPI танилцуулагдахаас өмнө системийн тэжээлийн ашиглалт болон дулааны шинж чанаруудыг удирдахад үйлдлийн системүүдийн хувьд хэцүү, уян хатан биш байсан. Тоног төхөөрөмж нь BIOS-оор удирдагддаг байсан болохоор тэжээлийн удирдлагын тохиргоонуудын харагдац бага бөгөөд хэрэглэгчид хянах боломж бага байсан юм.Зарим нэгэн хязгаарлагдмал тохиргооны боломж Advanced Power Management буюу Тэжээлийн Дэвшилттэй Удирдлага (APM) интерфэйсээр хийгдэх боломжтой байсан. Тэжээл болон Эх үүсвэрийн Удирдлага нь орчин үеийн үйлдлийн системийн түлхүүр хэсгүүдийн нэг юм. Жишээ нь таны системийн хэм гэнэт нэмэгдэх тохиолдолд системийн хязгааруудыг үйлдлийн систем монитор хийхийг (магадгүй танд мэдээлэхийг) хүсэж болох юм. &os; Гарын авлагын энэ хэсэгт бид ACPI-ийн талаар нэвтэрхий мэдээллээр хангах болно. Цааш нэмж уншихад зориулсан мэдээллүүдийг төгсгөл хэсэгт оруулсан байгаа. ACPI гэж юу вэ? ACPI APM Advanced Configuration and Power Interface буюу Дэвшилттэй Тохиргоо ба Тэжээлийн Интерфэйс (ACPI) нь тоног төхөөрөмжийн эх үүсвэрүүд болон тэжээлийн удирдлагад (эндээс нэр гарсан) зориулсан стандарт интерфэйсийг хангах зорилгоор үйлдвэрлэгчдийн холбооноос бичин гаргасан стандарт юм. Энэ нь Үйлдлийн Системээр заалгасан тохиргоо ба Тэжээлийн Удирдлагын түлхүүр элемент юм, өөрөөр хэлбэл: энэ нь илүү хяналт болон уян хатан байдлыг үйлдлийн системд (OS) хангадаг. ACPI-г танилцуулахаас өмнө одоогийн Залгаад Тоглуулах интерфэйсүүдийн хязгааруудыг орчин үеийн системүүд сунгасан юм. ACPI нь APM-ийн (Advanced Power Management буюу Тэжээлийн Дэвшилтэт Удирдлага) шууд залгамжлагч юм. Тэжээлийн Дэвшилтэт Удирдлагын (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-битийн эмуляц хэрэглэх шаардлагатай болдог. &os;-ийн APM драйвер &man.apm.4; гарын авлагын хуудсанд баримтжуулагдсан байдаг. <acronym>ACPI</acronym>-г тохируулах нь acpi.ko драйвер нь системийг эхлүүлэх үед &man.loader.8;-оор анхдагчаар ачаалагддаг бөгөөд цөмд оруулж хөрвүүлэгдэх ёсгүй. Үүний цаадах шалтгаан нь модулиудтай ажиллах хялбар байдаг, өөрөөр хэлбэл цөмийг дахин хөрвүүлэлгүйгээр өөр acpi.ko уруу шилждэг. Энэ нь тест хийлтийг илүү амархан болгодог давуу талтай юм. Нөгөө нэг шалтгаан нь системийг ажиллуулж дууссаны дараа ACPI-г ажиллуулахад ихэвчлэн сайн ажилладаггүй. Хэрэв та асуудлуудтай учирч байгаа бол ACPI-г бүхэлд нь хаах хэрэгтэй. Энэ драйверийг ачаалсны дараа буулгаж болиулж чаддаггүй, болдоггүй, учир нь системийн шугам үүнийг төрөл бүрийн тоног төхөөрөмжүүдийн харилцан үйлдлүүдэд хэрэглэдэг. ACPI-г /boot/loader.conf файлд юм уу эсвэл &man.loader.8; хүлээх мөрөнд hint.acpi.0.disabled="1" гэж тохируулан хааж болдог. ACPI болон APM нь цуг байж болохгүй бөгөөд салангид хэрэглэгдэх ёстой. Сүүлд ачаалагдах драйвер нь хэрэв нөгөө нэгийг ажиллаж байгааг мэдвэл ажиллагаагаа дуусгавар болгодог. ACPI нь &man.acpiconf.8;-ийн туг болон 1-5 тохируулгын тусламжтайгаар системийг унтах горим шилжүүлэхэд хэрэглэгдэж болно. Ихэнх хэрэглэгчдэд зөвхөн 1 эсвэл 3 (RAM руу түр зогсоох) хэрэгтэй байдаг. 5 тохируулга нь дараах тушаалтай нэг ёсондоо адилыг гүйцэтгэнэ: &prompt.root; halt -p Бусад тохируулгууд &man.sysctl.8;-ийн тусламжтай байдаг. Дэлгэрэнгүй мэдээллийн талаар &man.acpi.4; болон &man.acpiconf.8; гарын авлагын хуудаснуудаас шалгана уу. Нэйт Лоосон Бичсэн Питер Шульц Хувь нэмэрлэцгээсэн Том Рөүдс Цагаанхүүгийн Ганболд Орчуулсан &os;-ийн <acronym>ACPI</acronym>-г ашиглах нь ба дибаг хийх нь ACPI асуудлууд ACPI нь төхөөрөмжүүдийг илрүүлэх, тэжээлийн ашиглалтыг удирдах болон урьд нь BIOS-оор удирдагддаг байсан төрөл бүрийн тоног төхөөрөмжид хандах стандартчилагдсан хандалтыг хангадаг цоо шинэ арга юм. Бүх системүүд дээр ACPI-г ажиллуулах тал дээр дэвшил хийгдсэн бөгөөд гэхдээ зарим эх хавтангуудын ACPI Машины Хэлний (AML) байткод дахь алдаанууд, &os;-ийн цөмийн дэд системүүдийн бүрэн бүтэн бус байдал болон &intel; ACPI-CA тайлбарлагч дахь алдаанууд илэрсээр байна. Энэ баримт нь таныг &os;-ийн ACPI дэмжигчдэд тусалж таны ажигласан асуудлуудын үндсэн учир шалтгааныг таних, дибаг хийх болон шийдлийг хөгжүүлэхэд туслах зорилготой юм. Үүнийг уншиж байгаад талархлаа илэрхийлэхийн ялдамд бид таны системийн асуудлуудыг шийдэж чадна гэдэгт найдаж байна. Дибаг мэдээллийг илгээх нь Асуудлыг илгээхээсээ өмнө та хамгийн сүүлийн үеийн BIOS-ийн хувилбар болон хэрэв байх юм бол суулгагдсан хянагчийн хамгийн сүүлийн firmware хувилбар ажиллуулж байгаа эсэхээ шалгаарай. Асуудлыг шууд илгээхийг хүсэж байгаачууд дараах мэдээллийг freebsd-acpi@FreeBSD.org уруу илгээнэ үү: Системийн төрөл болон загварыг оролцуулан алдааг гаргаж байгаа зүйлийн хамтаар алдаатай ажиллагааг тайлбарласан мэдээлэл. Мөн хэрэв алдаа таны хувьд шинэ бол яг хэзээ гарч эхэлснийг аль болох тодорхой гаргаарай. boot -v ажилласны дараах &man.dmesg.8;-ийн гаралтыг алдааг шалгаж байхад таны үүсгэсэн алдааны мэдээллүүдийн хамтаар. Хэрэв ACPI-г хаасан байхад асуудлыг шийдэж байвал тийм байх үе дэх boot -v-ийн гаралт. sysctl hw.acpi-ийн гаралт. Энэ нь таны систем ямар ямар боломжуудыг санал болгож байгааг мэдэх бас нэг сайн арга юм. Таны ACPI Эх Хэл (ASL) байх URL хаяг. ASL нь маш том байж болох учир шууд битгий жагсаалт уруу илгээгээрэй. Өөрийн ASL-ийн хуулбарыг энэ тушаалыг ашиглаж үүсгээрэй: &prompt.root; acpidump -dt > name-system.asl (Өөрийн нэвтрэх нэрийг name-ийн оронд болон үйлдвэрлэгч/загварыг system-ийн оронд солиорой. Жишээ нь: njl-FooCo6000.asl) Ихэнх хөгжүүлэгчид &a.current; үзэж байдаг, гэхдээ асуудлуудаа харагдуулахын тулд &a.acpi.name; уруу илгээгээрэй. Бид бүгд хаа нэгтээ өөр өөрийн үндсэн ажилтай учир тэвчээртэй байна уу. Хэрэв таны алдаа шууд илэрхий биш байх юм бол магадгүй бид таныг &man.send-pr.1;-ийн тусламжтай PR илгээхийг асуух байх. PR оруулахдаа дээр хүссэний адил мэдээллээ оруулна уу. Энэ нь асуудлыг мөшгөж шийдвэрлэхэд бидэнд туслах юм. Бид PR-уудыг мэдээлэх механизмын зорилгоор биш байгаа асуудлуудыг санаж байх зорилгоор ашигладаг болохоор эхлээд &a.acpi.name; уруу захидал илгээлгүйгээр PR битгий илгээгээрэй. Магадгүй таны асуудлыг урд нь өөр хэн нэгэн мэдээлсэн байж болох юм. Оршил ACPI ACPI нь ia32 (x86), ia64 (Itanium) болон amd64 (AMD) архитектуруудтай нийцтэй орчин үеийн бүх компьютерт байдаг. Бүрэн стандарт нь CPU-ны ажиллагааны удирдлага, тэжээлийн онгоцуудын хяналт, дулааны бүсүүд, төрөл бүрийн батарейний системүүд, суулгагдсан хянагчууд болон шугамын жагсаалт зэрэг олон боломжуудтай. Ихэнх системүүд нь бүрэн стандартыг бүгдийг хангасан шийдэлтэй байдаггүй. Жишээ нь зөөврийн компьютер хөргөх болон бас батарейний удирдлагын дэмжлэгтэй байхад ширээний систем зөвхөн шугамын жагсаалтын хэсгийн шийдлийг агуулсан байдаг. Зөөврийн компьютерууд нь бас өөр өөрийн ярвигтай асуудлуудыг агуулсан түр зогсоох болон үргэлжлүүлэх боломжуудыг агуулдаг. ACPI-нийцтэй систем нь төрөл бүрийн хэсгүүдтэй байдаг. BIOS болон бичил схемийн үйлдвэрлэгчид APIC зураг (SMP-д ашиглагддаг), тохиргооны регистрүүд болон хялбар тохиргооны утгууд зэрэг зүйлсүүдийг заадаг төрөл бүрийн тогтмол хүснэгтүүдийг (өөрөөр хэлбэл FADT) санах ойд хангаж өгдөг. Мөн төхөөрөмжүүд болон аргуудын мод хэлбэрийн нэрийн талбарыг заадаг байткодын хүснэгтээр (Differentiated System Description Table буюу Системийн Ялгаварласан Тайлбарын Хүснэгт DSDT) бас хангадаг. ACPI драйвер нь тогтмол хүснэгтүүдийг задлан ялгал хийх, байткодын тайлбарлагчийг шийдэх болон ACPI дэд системийн мэдээллийг хүлээн авахаар төхөөрөмжүүдийн драйверууд болон цөмийг өөрчлөх ёстой. &os;-ийн хувьд &intel; нь Линукс болон NetBSD-тэй хуваалцан хэрэглэгддэг тайлбарлагчаар хангадаг. ACPI-CA эх кодын зам нь src/sys/contrib/dev/acpica. ACPI-CA-г &os; дээр ажиллуулах тэр цавуу код нь src/sys/dev/acpica/Osd байршилд байдаг. Эцэст нь төрөл бүрийн ACPI төхөөрөмжүүдийн драйверууд src/sys/dev/acpica байршлаас олддог. Нийтлэг асуудлууд ACPI асуудлууд ACPI зөв ажиллахын тулд бүх хэсгүүд бас зөв ажилласан байх ёстой. Энд зарим нэг нийтлэг асуудлуудыг илэрч байгаа давтамжийн дарааллаар зарим нэг тойрон гарах замууд болон засваруудтайгаар нь дурдъя. Хулганы асуудлууд Зарим тохиолдолд түр зогсоох үйлдэл хийгдсэний дараа үргэлжлүүлэхэд хулганыг ажиллахгүй болгодог. Мэдэгдэж байгаа тойрон гарах арга зам нь hint.psm.0.flags="0x3000" мөрийг /boot/loader.conf файлд нэмэх явдал юм. Хэрэв энэ нь ажиллахгүй бол дээр тайлбарласны дагуу алдааны тайлан илгээхийг бодно уу. Suspend/Resume буюу Түр зогсоох/Үргэлжлүүлэх ACPI нь RAM уруу түр зогсоох S1-S3 гэсэн гурван төлөвтэй (STR) бөгөөд диск уруу түр зогсоох S4 гэгддэг нэг төлөвтэй (STD). S5 нь soft off буюу зөөлөн зогсоолт бөгөөд тэжээлд залгагдсан боловч асаагдаагүй байх үеийн таны системийн жирийн төлөв юм. S4 нь хоёр тусдаа аргаар хийгдэх боломжтой. S4BIOS нь BIOS-ийн тусламжтайгаар диск уруу хийгдэх түр зогсоолт юм. S4OS нь бүхэлдээ үйлдлийн системээр хийгддэг. Түр зогсоолттой холбоотой зүйлүүдийг sysctl hw.acpi тушаалаар шалгаж эхлээрэй. Энд Thinkpad-тай холбоотой үр дүнгүүд байна: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0 Энэ нь бид S3, S4OS болон S5-ийг шалгахад acpiconf -s тушаалыг ашиглаж болно гэсэн үг юм. Хэрэв нь нэг (1) байх юм бол бид S4OS-ийн оронд S4BIOS дэмжлэгтэй байх юм. Түр зогсоолт/үргэлжлүүлэлтийг тест хийхдээ хэрэв дэмжигдсэн бол S1-ээс эхлээрэй. Энэ төлөв нь драйверийн дэмжлэг барагтаа л шаарддаггүй болохоор бараг л ажиллах болно. Хэн ч S2-ийг хийгээгүй байдаг бөгөөд танд энэ хэрэв байгаа бол энэ нь S1-тэй адил байна. Дараагийн оролдох зүйл нь S3 юм. Энэ нь хамгийн гүнзгий STR төлөв бөгөөд таны тоног төхөөрөмжийг дахин зөв эхлүүлэхийн тулд драйверийн ихээхэн дэмжлэг шаарддаг. Хэрэв үргэлжлүүлэх үед танд асуудлууд гарч байгаа бол &a.acpi.name; жагсаалт уруу цахим захидал чөлөөтэй илгээгээрэй, гэхдээ илүү их тест хийлт, ажил шаардсан маш олон драйверууд/тоног төхөөрөмжүүд байдаг учир асуудал шийдэгдэхийг хүлээх хэрэггүй юм. Асуудлыг тусгаарлахад туслахын тулд өөрийн цөмөөс аль болох олон драйверуудыг арилгаарай. Хэрэв энэ нь ажиллаж байвал та яг аль драйвер асуудалтай байгааг драйверуудыг амжилтгүй ажиллах хүртэл ачаалан тодорхойлж болох юм. nvidia.ko, X11 дэлгэцийн драйверууд болон USB зэрэг хоёртын драйверууд нь ерөнхийдөө хамгийн их асуудлуудтай байдаг байхад Ethernet интерфэйсүүд ихэвчлэн зүгээр ажилладаг. Хэрэв та драйверуудыг зөв ачаалж/буулгаж чадаж байвал та тохирох тушаалуудыг /etc/rc.suspend болон /etc/rc.resume файлуудад хийж үүнийг автоматжуулж болно. Драйверийг буулгах болон ачаалахад зориулсан тайлбар болгосон жишээ байдаг. Хэрэв таны дэлгэц үргэлжлүүлэлт хийгдсэний дараа заваарсан бол -г тэг (0) болгож үзээрэй. Хэрэв тусламж болохоор бол -г арай урт эсвэл арай богино утгуудаар тохируулж үзээрэй. Өөр нэг турших зүйл нь ACPI дэмжлэгтэй сүүлийн үеийн Линуксийн түгээлтийг ачаалан тэдний түр зогсоолт/үргэлжлүүлэлтийн дэмжлэгийг адил тоног төхөөрөмж дээр турших явдал юм. Хэрэв Линукс дээр ажиллаж байвал энэ нь &os;-ийн драйверийн асуудал гэсэн үг бөгөөд яг аль драйвер асуудлыг үүсгэж байгааг олсноор асуудлыг засварлахад бидэнд тус болох болно. ACPI-ийг дэмжиж байдаг дэмжигчид нь өөр бусад драйверуудыг (өөрөөр хэлбэл дуу, ATA гэх мэт) ихэвчлэн дэмжин ажилладаггүй болохоор драйверийн асуудлыг мөшгөж хийгдсэн ажил бүр магадгүй эцсийн эцэст &a.current.name; жагсаалт болон драйверийг дэмжигч уруу илгээгдэх хэрэгтэйг санаарай. Хэрэв та адал явдлыг эрж байгаа бол драйверийн үргэлжлүүлэлтийн функцын аль хэсэгт өлгөгдөж байгааг мөшгөхийн тулд зарим дибаг хийх &man.printf.3;-үүдийг асуудалтай драйверт хийж эхлээрэй. Эцэст нь ACPI-г хааж оронд нь APM-г нээж оролдоорой. Хэрэв түр зогсоолт/үргэлжлүүлэлт APM-тэй байхад ажиллаж байвал та APM-тэйгээ үлдэх нь ялангуяа хуучин тоног төхөөрөмжийн (2000 оноос өмнөх) хувьд бараг дээр байх бизээ. ACPI дэмжлэгийг зөв болгоход үйлдвэрлэгчдэд цаг хугацаа шаардах бөгөөд магадгүй хуучин тоног төхөөрөмжүүд нь ACPI-ийн хувьд BIOS-ийн асуудлуудтай ихэвчлэн байдаг. Систем өлгөгдөх (түр хугацаагаар эсвэл бүрмөсөн) Ихэнх системийн өлгөгдлүүд нь гээгдсэн тасалдлууд эсвэл тасалдлын шуургын үр дүн юм. Бичил схемүүд нь ачаалахаас өмнө тасалдлуудыг BIOS хэрхэн тохируулдгаас болсон асуудлууд, APIC (MADT) хүснэгтийн зөв байдал болон System Control Interrupt буюу Системийн Хянагч Тасалдлын (SCI) чиглүүлэлт дээр тулгуурласан олон асуудлуудтай байдаг. тасалдлын шуургууд Тасалдлын шуургыг vmstat -i тушаалын гаралтаас acpi0 бүхий мөрийг шалгаж гээгдсэн тасалдлуудаас ялгаж болно. Хэрэв тоологч секунд тутам хоёроор нэмэгдэж байвал та тасалдлын шуургатай байна. Хэрэв систем өлгөгдсөн юм шиг байвал DDB (консол дээр CTRL ALTESC) уруу орж show interrupts гэж бичих хэрэгтэй. APIC хаах нь Тасалдлын асуудлуудтай ажиллаж байхад таны хамгийн шилдэг итгэл найдвар бол loader.conf-д hint.apic.0.disabled="1" хэмээн зааж APIC дэмжлэгийг хаах явдал юм. Үймээнүүд Үймээнүүд нь ACPI-ийн хувьд харьцангуй ховор байдаг бөгөөд засварлах нэн тэргүүн ээлжийн асуудал байдаг. Эхний алхам бол үймээнийг дахин гаргах (хэрэв боломжтой бол) алхмуудыг тусгаарлаж буцах мөрийг (backtrace) авах явдал юм. options DDB мөрийг нээж сериал консол (-г үзнэ үү) тохируулах эсвэл &man.dump.8; хуваалтыг тохируулах зөвлөгөөг дагаарай. Та буцах мөрийг DDB дээр tr-р авч болно. Хэрэв та буцах мөрийг гараар бичих болбол мөр дэх хамгийн доодох тав (5) болон хамгийн дээдэх таван (5) мөрийг хамгийн багадаа бодоход аваарай. Дараа нь асуудлыг тусгаарлахыг оролдож ACPI-г хааж ачаалж үзээрэй. Хэрэв энэ нь ажиллаж байвал -ийн төрөл бүрийн утгуудыг хэрэглэж та ACPI дэд системийг тусгаарлаж болно. Зарим жишээнүүдийг &man.acpi.4; гарын авлагын хуудаснаас үзнэ үү. Түр зогссоны дараа эсвэл унтраасны дараа систем дахин эхлэх Эхлээд &man.loader.conf.5; дээр hw.acpi.disable_on_poweroff="0" гэж тохируулаад үз. Энэ нь унтраах процессийн үед төрөл бүрийн үйл явцуудыг ACPI хаахыг болиулдаг. Энэ зорилгын нэгэн адил зарим системүүд энэ утгыг 1 (анхдагч) болгож тохируулахыг шаарддаг. Энэ нь түр зогсоолт эсвэл унтраалт хийгдсэний дараа аяндаа гарсан систем асаж эхлэх асуудлыг ихэвчлэн засварладаг. Бусад асуудлууд Хэрэв танд ACPI-тай холбоотой бусад асуудлууд (суулгах станцтай ажиллах, төхөөрөмжүүд илрүүлэгдэхгүй гэх мэт) байвал тайлбарыг захидлын жагсаалт уруу бас илгээнэ үү; гэхдээ эдгээр асуудлуудын зарим нь ACPI дэд системийн дуусаагүй хэсгүүдтэй холбоотой байж болох бөгөөд тэдгээрийг шийдэж хийхэд нэлээн хугацаа зарцуулж болох юм. Тэвчээртэй байж бидний илгээж болох засваруудыг тест хийхэд бэлэн байгаарай. <acronym>ASL</acronym>, <command>acpidump</command>, болон <acronym>IASL</acronym> ACPI ASL Хамгийн нийтлэг асуудал бол BIOS үйлдвэрлэгчдийн гаргасан буруу (эсвэл алдаатай!) байткод юм. Энэ нь ихэвчлэн дараах шиг цөмийн консол мэдээллүүдээр ил тод болдог: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND Ихэвчлэн та эдгээр асуудлуудыг өөрийн BIOS-ийг хамгийн сүүлийн хувилбар уруу шинэчилснээр шийдэж болно. Ихэнх консолын мэдээллүүд нь аюулгүй гэхдээ хэрэв танд батарейний төлөв ажиллахгүй гэх мэт өөр бусад асуудлууд байгаа бол тэдгээр мэдээллүүд нь AML-д байгаа асуудлуудыг хайж болох боломжийн газар нь юм. AML гэгддэг байткод нь ASL хэмээгддэг эх хэлээс хөрвүүлэгддэг. AML нь DSDT гэгддэг хүснэгтэд байдаг. Өөрийн ASL-ийн хуулбарыг авахын тулд &man.acpidump.8;-ийг ашиглана. Та (тогтмол хүснэгтүүдийн агуулгуудыг үзүүлэх) болон (AML-ийг ASL уруу дизассембл хийх) тохируулгыг хоёуланг нь ашиглах хэрэгтэй. Синтаксын жишээг Дибаг Мэдээллийг Илгээх нь хэсгээс үзнэ үү. Таны хийж болох хамгийн хялбар анхны шалгалт нь алдаануудыг шалгахын тулд өөрийн ASL-ийг хөрвүүлэх явдал юм. Анхааруулгуудыг ихэвчлэн орхиж болох боловч алдаанууд нь ACPI-г зөв ажиллуулахад гол төлөв саад болдог хорхойнууд байдаг. Өөрийн ASL-ийг дахин хөрвүүлэхдээ дараах тушаалыг ажиллуулна: &prompt.root; iasl your.asl Өөрийн <acronym>ASL</acronym>-г засварлах нь ACPI ASL Бидний эцсийн зорилго бол бараг хүн болгоны хувьд хэрэглэгчийн ямар ч оролцоогүйгээр ACPI-г ажиллуулах явдал юм. Гэхдээ өнөөг хүртэл бид BIOS үйлдвэрлэгчдийн гаргасан нийтлэг алдаануудад зориулан тойрон гарах арга замуудыг хөгжүүлсээр байгаа билээ. µsoft;-ийн тайлбарлагч (acpi.sys болон acpiec.sys) нь стандартыг баримталж байгааг чанд шалгадаггүй бөгөөд BIOS-ийн олон үйлдвэрлэгчид ACPI-г зөвхөн &windows; дээр тест хийж өөрсдийн ASL-ийг хэзээ ч засдаггүй. Бид µsoft;-ийн тайлбарлагчид зөвшөөрөгдсөн ямар стандартын бус ажиллагаа байгааг үргэлжлүүлэн нарийн таньж баримтжуулан хэрэглэгчдээр ASL-ийг хүчлэн засуулалгүйгээр &os; ажиллаж чадахаар түүнийг хуулбарлах болно гэж найдаж байна. Тойрон гарах арга зам болгон биднийг энэ ажиллагааг танихад тусалж та ASL-ийг гараар засварлаж болно. Хэрэв таны хувьд энэ нь ажиллавал хуучин болон шинэ ASL-ийнхээ &man.diff.1;-ийг илгээнэ үү, бид бололцоогоороо ACPI-CA дахь алдаатай ажиллагааг тойрон гарч ингэснээр хойшид таны засвар байнга хийгдэх шаардлагагүй болох юм. ACPI алдааны мэдээллүүд Энд нийтлэг алдааны мэдээллүүд, тэдгээрийн шалтгаан болон хэрхэн засаж болох жагсаалтыг үзүүлэв: _OS хамаарлууд Зарим AML нь ертөнц төрөл бүрийн &windows; хувилбаруудаас тогтдог гэж үздэг. Хэрэв танд байгаа асуудлыг засаж чадаж байвал та &os;-г ямар нэг OS гэж харагдуулахаар хэлж өгч болно. Үүнийг хялбар аргаар дарж бичихийн тулд /boot/loader.conf-д hw.acpi.osname="Windows 2001" гэж эсвэл ASL дахь өөр бусад адил мөрүүдийг тохируулж өгнө. Буцах мэдээллүүд байхгүй бол Зарим аргууд нь стандартын дагуу шууд утга буцаадаггүй. ACPI-CA нь үүнтэй ажиллаж чадахгүй байхад &os; үүнийг далдаар утга буцаалгах боломжийг олгодог тойрон гарах арга замтай байдаг. Хэрэв та утга буцаагдах ёстойг мэдэж байвал шаардлагатай газар нь Return буюу Буцах мэдээллүүдийг шууд нэмж болно. ASL-ийг iasl тушаалаар хүчээр хөрвүүлэхдээ тугийг ашиглана. Анхдагч <acronym>AML</acronym>-ийг дарж өөрчлөх нь your.asl-ийг өөрчилсний дараа үүнийг та хөрвүүлэхдээ: &prompt.root; iasl your.asl Хөрвүүлэх явцад алдаанууд байсан ч гэсэн та тугийг нэмж AML-ийг хүчээр үүсгэж болно. Зарим алдаануудыг (өөрөөр хэлбэл Буцах мэдээллүүд байхгүй гэх мэт) тайлбарлагчийн тусламжтайгаар автоматаар тойрон гардгийг санаарай. DSDT.aml нь iasl-ийн анхдагч гаралт файлын нэр юм. Та өөрийн BIOS-ийн алдаатай хуулбарын (флэш санах ойд байсаар байгаа) оронд /boot/loader.conf-ийг дараах байдлаар засварлан үүнийг ачаалж болно: acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" Өөрийн DSDT.aml файлын хуулбарыг /boot сан уруу хуулах хэрэгтэй. <acronym>ACPI</acronym>-аас дибаг мэдээлэл гаргаж авах нь ACPI асуудлууд ACPI дибаг ACPI драйвер нь маш уян хатан дибаг хийх боломжтой. Энэ нь дэд системүүдийн олонлог болон харуулах түвшинг зааж өгөхийг танд зөвшөөрдөг. Таны дибаг хийхийг хүсэж байгаа дэд системүүд нь давхаргууд болж заагдсан байдаг бөгөөд ACPI-CA хэсгүүд (ACPI_ALL_COMPONENTS) болон ACPI тоног төхөөрөмжийн дэмжлэг (ACPI_ALL_DRIVERS) болж задардаг. Дибаг гаралтын харуулалт нь үеээр заагддаг бөгөөд ACPI_LV_ERROR (зөвхөн алдаануудыг хэлдэг) тогтмолоос ACPI_LV_VERBOSE (бүгд) хүртэл байдаг. Үе нь олон тохируулгуудыг нэг удаа зайгаар зааглан тохируулж болох бит баг (bitmask) юм. Хэрэв энэ нь маш урт тэгээд консолын мэдээллийн буферийг арилган шинэчилж байвал та практик дээр гаралтыг бүртгэх сериал консолыг ашиглахыг хүсэж болох юм. Бие даасан давхаргууд болон түвшингүүдийн бүрэн жагсаалт &man.acpi.4; гарын авлагын хуудсанд байдаг. Дибаг гаралт анхдагчаар идэвхжүүлэгдээгүй байдаг. Идэвхтэй болгохын тулд ACPI хэрэв цөмд хөрвүүлэгдсэн бол options ACPI_DEBUG мөрийг өөрийн цөмийн тохиргооны файлд нэмэх хэрэгтэй. Нийтэд нь идэвхтэй болгохын тулд /etc/make.conf-д ACPI_DEBUG=1 мөрийг нэмж болно. Хэрэв энэ нь модуль бол та өөрийн acpi.ko модулийг дараах маягаар дахин хөрвүүлж болно: &prompt.root; 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 дахь тохируулгуудын адилаар нэрлэгддэг. Лавлагаанууд ACPI-ийн талаар дэлгэрэнгүй мэдээллийг дараах байршлуудаас олж болно: &a.acpi; ACPI Захидлын Жагсаалтын Архивууд Хуучин ACPI Захидлын Жагсаалтын Архивууд ACPI 2.0 Тодорхойлолт &os; Гарын авлагын хуудаснууд: &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, &man.acpidb.8; DSDT дибаг эх үүсвэр. (Compaq-ийг жишээ болгон хэрэглэсэн боловч ерөнхийдөө хэрэгтэй.) diff --git a/mn_MN.UTF-8/books/handbook/cutting-edge/chapter.sgml b/mn_MN.UTF-8/books/handbook/cutting-edge/chapter.sgml index 82cb97c3a3..7cbf617426 100644 --- a/mn_MN.UTF-8/books/handbook/cutting-edge/chapter.sgml +++ b/mn_MN.UTF-8/books/handbook/cutting-edge/chapter.sgml @@ -1,1707 +1,1707 @@ Жим Мок Бүтцийг дахин өөрчлөн зохион байгуулж зарим хэсгүүдийг шинэчилсэн Жордан Хаббард Анхлан эхийг бичсэн Поул-Хэннинг Камп Жон Полстра Ник Клэйтон Цагаанхүүгийн Ганболд Орчуулсан Амжилт ололтын тэргүүнд Ерөнхий агуулга &os; нь өөрийн хувилбаруудын хооронд байнгын хөгжүүлэлтийн доор оршин тогтнож байдаг. Амжилт ололтын тэргүүнд байхыг хүссэн хүн бүхэнд өөрийн системийг хамгийн сүүлийн үеийн хөгжүүлэлтийн хэлбэрт оруулах хэд хэдэн хялбар арга байдаг. Амжилт ололтын тэргүүнд байх нь хүн бүхэнд зориулагдаагүйг анхаарна уу! Энэхүү бүлэг нь хөгжүүлэлтийн системийг дагахыг хүсэх эсвэл гаргасан хувилбартай үлдэх эсэхийг шийдэхэд танд туслах болно. Энэ бүлгийг уншсаны дараа, та дараах зүйлсийг мэдэх болно: &os.stable; болон &os.current; хөгжүүлэлтийн салбаруудын ялгаа. CVSup, CVS, эсвэл CTM програмуудын тусламжтай өөрийн системийг хэрхэн хамгийн сүүлийн хэлбэрт авчрах талаар. Бүх үндсэн системийг make buildworld (гэх мэт) ашиглан хэрхэн дахин бүтээж суулгах талаар. Энэ бүлгийг уншихаасаа өмнө, та дараах зүйлсийг мэдэх шаардлагатай: Өөрийн сүлжээний холболтыг зөв тохируулах (). Нэмэлт гуравдагч програм хангамжуудыг хэрхэн суулгахыг мэдэх (). Энэ бүлэгт &os;-ийн эхийг авч шинэчлэхийн тулд cvsup тушаалыг ашиглагдсан. Үүнийг хэрэглэхийн тулд net/cvsup-without-gui гэсэн порт буюу багцыг та суулгах хэрэгтэй. Хэрэв та &os; 6.2-RELEASE юм уу эсвэл түүнээс хойшхи хувилбар хэрэглэж байвал үндсэн системийн хэсэг болсон &man.csup.1; тушаалаар үүнийг орлуулж хэрэглэж болно. &os.current; vs. &os.stable; -CURRENT -STABLE FreeBSD-ийн хоёр хөгжүүлэлтийн салбар байдаг: &os.current; болон &os.stable;. Энэ хэсэгт эдгээр тус бүрийг тайлбарлаж өөрийн системийг тус тусын модны хувьд хамгийн шинэ хэлбэрт байнга байлгах талаар тайлбарлах болно. &os.current; эхлээд хэлэлцэгдэх бөгөөд дараа нь &os.stable;-ийн тухай яригдах болно. &os;-ийн одоо үеийн хэлбэрт байх нь Та үүнийг уншихдаа &os.current; нь &os;-ийн хөгжүүлэлтийн bleeding edge салбар буюу амжилт ололтын хамгийн тэргүүний салбар гэдгийг санаарай. &os.current; хэрэглэгчдийг техникийн өндөр чадавхитай бөгөөд системийн хүнд хэцүү асуудлуудыг өөрсдөө шийдвэрлэх чадвартай байна гэж тооцдог. Хэрэв та &os;-д анхлан суралцагч бол үүнийг суулгахаасаа өмнө дахин сайн бодоорой. &os.current; гэж юу вэ? хормын агшны хувилбар &os.current; нь &os;-ийн хамгийн сүүлийн үеийн ажлын эх юм. Энэ нь хийгдэж байгаа ажлууд, туршилтын өөрчлөлтүүд болон програм хангамжийн дараагийн албан ёсны хувилбарт байхгүй ч байж болох эсвэл байж ч болох шилжилтийн аргуудыг багтаадаг. &os;-ийн олон хөгжүүлэгчид &os.current;-ийн эх кодыг өдөр болгон эмхэтгэн хөрвүүлж байдаг боловч эхийг бүтээх боломжгүй үе бас байдаг. Эдгээр асуудлууд нь боломжийн хэрээр хурдан шийдэгддэг боловч &os.current; нь сүйрэл авчрах эсвэл тун их хүссэн ажиллагааг авчрах эсэх нь та яг ямар агшинд эх кодыг татаж авснаас хамаарах юм! &os.current; хэнд хэрэгтэй вэ? &os.current; нь үндсэн 3 сонирхлын бүлэгт зориулагдан хийгдсэн: Эх модны зарим хэсэг дээр идэвхтэйгээр ажиллаж байгаа &os;-ийн хүрээний гишүүд болон current буюу одоо үеийн хэлбэрт байлгах нь туйлын шаардлага болсон хүмүүст. &os.current;-г аль болох ухаалаг байлгахыг хичээж асуудлуудыг шийдвэрлэхэд цагаа зарах хүсэлтэй байдаг идэвхтэй тест хийгч &os;-ийн хүрээний гишүүд. Эдгээр хүмүүс нь өөрчлөлтүүд болон &os;-ийн ерөнхий чиглэлд цаг үеийн саналуудыг тусгахыг хүсэж тэдгээрийг шийдэх засваруудыг илгээдэг бас хүмүүс юм.. Юу болж байгааг зөвхөн харж мэдэж байхыг хүссэн эсвэл одоо үеийн эхийг лавлагааны зорилгоор ашиглахыг зөвхөн хүссэн хүмүүс (өөрөөр хэлбэл ажиллуулах биш унших зорилгоор). Эдгээр хүмүүс нь хааяа бас санал гаргаж кодонд хувь нэмэр оруулдаг. &os.current; нь юу <emphasis>Биш</emphasis> вэ? Та зарим нэг дажгүй шинэ боломж байгааг сонссон учраас бусдаас түрүүлж урьдчилсан хувилбарын тэдгээр битүүдийг авах таны нэн тэргүүний арга зам. Шинэ боломжийг авч эхэнд байна гэдэг нь та шинэ алдаанууд, хорхойнуудыг бас авч эхэнд байна гэсэн үг юм. Алдааны засваруудыг хурдан авах арга зам. &os.current;-ийн өгөгдсөн дурын хувилбар нь илэрсэн алдаануудыг засахын хажуугаар бас магадгүй шинэ алдаанууд бас гаргаж байдаг. Аль ч үед албан ёсоор дэмжигдсэн. Бид өөрсдийн чадлын хирээр хууль ёсны 3 &os.current; бүлгийн аль нэгэнд хүмүүст бодитоор туслахыг хичээдэг, гэхдээ бидэнд ердөө л техникийн дэмжлэг үзүүлэх цаг байдаггүй. Энэ нь бид хүмүүст туслах дургүй өөдгүй муухай хүмүүс учраас гэсэн үг биш юм (хэрэв бид байгаагүй бол бид &os;-г хийж байхгүй байх байсан). Бид ердөө л өдрийн хэдэн зуун захидлуудад хариулахын хажуугаар FreeBSD дээр ажиллаж чаддаггүй! &os;-г сайжруулах болон туршилтын кодон дээр тавигдсан маш олон асуултуудад хариулах хоёр сонголтын эхнийхийг хөгжүүлэгчид сонгосон юм. &os.current; ашиглах нь -CURRENT ашиглах нь &a.current.name; болон &a.svn-src-head.name; жагсаалтуудад элсэн орно уу. Энэ нь зөвхөн сайн санаанаас гадна бас чухал юм. Хэрэв та &a.current.name; жагсаалтад ороогүй бол системийн одоогийн төлвийн талаар хүмүүсийн өгч байгаа санал хүсэлтүүдийг харахгүй учраас бусдын аль хэдийн олоод шийдсэн маш их асуудлууд дээр магадгүй та бүдрэн төөрөлдөж дуусах биз ээ. Бүр илүү чухал зүйл нь юу вэ гэвэл таны системийн эрүүл мэндэд эгзэгтэй байж болох чухал мэдээнүүдээс та хоцрох болно. &a.svn-src-head.name; жагсаалт нь кодонд оруулсан өөрчлөлт бүрийн бүртгэл оруулгыг болзошгүй сөрөг нөлөөнүүдийн талаар тохирсон мэдээллийн хамтаар танд харах боломжийг олгодог. Эдгээр жагсаалтууд эсвэл байгаа бусдын аль нэгэнд элсэхийн тулд &a.mailman.lists.link; хаяг уруу орж элсэхийг хүссэн жагсаалтаа сонгоорой. Дарааллын үлдсэн зааврууд тэнд байгаа болно. Хэрэв та бүх л эх модон дахь өөрчлөлтийг дагах сонирхолтой байгаа бол &a.svn-src-all.name; жагсаалтад бүртгүүлэхийг бид зөвлөж байна. &os;-ийн толин тусгалаас эхийг авна. Та үүнийг хоёр аргаар хийж болно: cvsup cron -CURRENT CVSup ашиглан сүүлийн хэлбэрт аваачих /usr/share/examples/cvsup санд байх standard-supfile гэж нэрлэгдсэн supfile-тай цуг cvsup програм ашигла. Энэ нь бүхэл цуглуулгыг нэг л удаа авч дараа нь зөвхөн өөрчлөгдсөнүүдийг танд авах боломжийг олгодог хамгийн сайшаасан арга юм. Олон хүмүүс cvsup-г cron-с ажиллуулж өөрсдийн эхийг хамгийн сүүлийн хэлбэрт автоматаар аваачдаг. Та дээр дурдсан жишээ supfile-г өөрчлөн cvsup-г өөрийн орчны хувьд тохируулах хэрэгтэй. Жишээ standard-supfile нь &os.current;-ийн биш &os;-ийн аюулгүй байдлын тусгай салбарыг дагахад хэрэглэгдэнэ. Танд энэ файлыг засварлаж дараах мөрийг өөрчлөх хэрэгтэй болно: *default release=cvs tag=RELENG_X_Y Дээрх мөрийг дараах мөрөөр сольно: *default release=cvs tag=. Хэрэгцээтэй хаяг/шошгонуудын дэлгэрэнгүй тайлбарыг гарын авлагын CVS хаяг/шошгонууд хэсгээс үзнэ үү. -CURRENT CTM ашиглан сүүлийн хэлбэрт аваачих CTM хэрэгслийг ашигла. Хэрэв та маш муу холболттой (өндөр үнэтэй холболтууд эсвэл зөвхөн цахим захидлын хандалт) бол CTM нь сонголт болох юм. Гэхдээ энэ нь бөөн зовлон бөгөөд та эвдэрсэн файлуудтай үлдэж болох юм. Энэ нь үүнийг ховор ашиглахад хүргэдэг бөгөөд ингэснээр ажиллахгүй байх боломжийг нэлээн удаан хугацаагаар ихэсгэдэг. Бид 9600 bps модем болон түүнээс хурдан холболттой хүмүүст CVSup-г ашиглахыг зөвлөдөг. Хэрэв та эхийг зөвхөн харахаар биш ажиллуулахаар татаж авч байгаа бол зөвхөн сонгосон хэсгүүдийг биш &os.current;-ийн бүх эхийг татаж аваарай. Үүний шалтгаан нь эхийн төрөл бүрийн хэсгүүд нь бусад хаа нэгтээ байгаа шинэчлэлтүүдээс хамаардаг бөгөөд зөвхөн хэсэг бүлэг эхийг хөрвүүлэхийг оролдох нь таныг бараг л баталгаатайгаар асуудалтай учруулах болно. -CURRENT хөрвүүлэх &os.current;-ийг хөрвүүлэхээсээ өмнө /usr/src дахь Makefile-г анхааралтай уншина уу. Эхний удаа та хамгийн багаар бодоход шинэчлэлтийн процессийн хэсэг болох шинэ цөмийг суулгаж ертенцийг дахин бүтээх хэсгээр дамжих хэрэгтэй. &a.current; болон /usr/src/UPDATING файлыг унших нь биднийг дараагийн хувилбар уруу шилжихэд заримдаа шаардлагатай болдог бусад эхлүүлэх процедуруудын хувьд хамгийн сүүлийн мэдээлэлтэй байлгах боломжийг бидэнд олгодог. Идэвхтэй бай! Хэрэв та &os.current; ажиллуулж байгаа бол түүний талаар таныг юу хэлэхийг ялангуяа хэрэв танд өргөжүүлэлт эсвэл алдааны засваруудын талаар санал хүсэлт байвал түүнийг бид мэдэхийг хүсдэг юм. Хавсаргасан кодтой санал хүсэлтүүдийг хамгийн их урам зоригтойгоор хүлээн авдаг билээ! &os;-ийн тогтвортой хэлбэрт байх нь &os.stable; гэж юу вэ? -STABLE &os.stable; нь үндсэн хувилбарууд гардаг бидний хөгжүүлэлтийн салбар юм. Өөрчлөлтүүд нь эхлээд тест хийгдэх зорилгоор &os.current; уруу ордог гэсэн ерөнхий төсөөлөл/таамаглалтайгаар янз бүрийн зөвшөөрлөөр энэ салбар уруу ордог. Энэ нь одоо болтол хөгжүүлэлтийн салбар бөгөөд гэхдээ энэ нь ямар ч үед &os.stable;-д зориулагдсан эх нь ямар ч зорилгод тохирч эсвэл тохирохгүй байж болно гэсэн үг юм. Энэ нь эцсийн хэрэглэгчид зориулагдсан эх үүсвэр бус ердөө л өөр нэг инженерчлэлийн хөгжүүлэлтийн арга зам юм. &os.stable; хэнд хэрэгтэй вэ? Хэрэв та FreeBSD-ийн хөгжүүлэлтийн процессод хувь нэмэр оруулах сонирхолтой, энэ нь ялангуяа FreeBSD-ийн дараагийн гарах хувилбартай холбоотой байдаг, эсвэл юу болж байгааг мэдэж байх сонирхолтой байгаа бол та дараах &os.stable;-г бодолцох хэрэгтэй. Аюулгүй байдлын засварууд бас &os.stable; салбар уруу орж байдаг нь үнэн боловч та үүнийг хийхийн тулд &os.stable;-г заавал дагах хэрэггүй. FreeBSD-ийн аюулгүй байдлын зөвлөмжүүд нь тухайн хувилбарт хамааралтай асуудлыг хэрхэн засах тухай тайлбарладаг Энэ нь бүр яг үнэн биш юм. Бид FreeBSD-ийн хуучин хувилбаруудыг үргэлж дэмжиж чадахгүй, гэхдээ бид тэдгээрийг олон жилийн турш дэмжсээр ирсэн. FreeBSD-ийн хуучин хувилбаруудын одоогийн аюулгүй байдлын бодлогын бүрэн тайлбарыг http://www.FreeBSD.org/security/-с үзнэ үү. бөгөөд зөвхөн аюулгүй байдлын үүднээс бүхэл бүтэн хөгжүүлэлтийн салбарыг дагаж байна гэдэг бас зөндөө олон хүсээгүй өөрчлөлтүүдийг авчрах магадлалтай юм. Бид &os.stable; салбар үргэлж хөрвүүлэгдэн эмхэтгэгдэж дандаа ажилладаг байлгахаар чармайж байдаг боловч энэ нь баталгаатай биш юм. Нэмж хэлэхэд код нь &os.stable;-д орохоосоо өмнө &os.current;-д хөгжүүлэгдэж байдаг боловч &os.current;-г ашиглан ажиллуулдгаас илүү &os.stable;-г хүмүүс ажиллуулдаг болохоор &os.current;-ийн хувьд илэрхий биш байсан алдаанууд болон булангийн тохиолдлууд &os.stable;-д илрэх нь заримдаа зайлшгүй юм. Эдгээр шалтгаануудаас болоод бид &os.stable;-г сохроор дагахыг танд зөвлөдөггүй бөгөөд энэ нь өөрийн хөгжүүлэлтийн орчиндоо кодыг эхлээд сайтар тест хийлгүйгээр үйлдвэрлэлд (production) ашиглаж байгаа серверүүдээ &os.stable; уруу шинэчлэхгүй байхад танд ялангуяа чухал ач холбогдолтой юм. Хэрэв танд үүнийг хийх эх үүсвэрүүд байхгүй бол бид FreeBSD-ийн хамгийн сүүлийн үеийн хувилбарыг ажиллуулж хоёртын шинэчлэлт хийх аргыг хувилбараас хувилбар уруу шилжихдээ ашиглахыг танд зөвлөж байна. &os.stable; ашиглах нь -STABLE ашиглах нь &a.stable.name; жагсаалтад элсэн орно уу. Энэ нь &os.stable;-д илэрч болох бүтээлтийн хамаарлууд эсвэл тусгайлсан анхаарал шаардлагатай өөр бусад асуудлуудын талаар танд мэдээлж байх болно. Хөгжүүлэгчид нь зарим нэг маргаантай засвар эсвэл шинэчлэлийн талаар бодож байгаа талаараа бас энэ захидлын жагсаалтад мэдээлдэг бөгөөд ийнхүү санал болгож байгаа өөрчлөлтийн талаар хэрэглэгчдэд ямар нэг асуудал байвал тэдэнд эргээд хариу өгөх боломж олгодог юм. Өөрийн дагаж байгаа салбарын тохирох SVN жагсаалтад элсэн орох хэрэгтэй. Жишээ нь хэрэв та 7-STABLE салбарыг дагаж байгаа бол &a.svn-src-stable-7.name; жагсаалтад элсэн ороорой. Энэ нь кодонд оруулсан өөрчлөлт бүрийн бүртгэл оруулгыг болзошгүй сөрөг нөлөөнүүдийн талаар тохирсон мэдээллийн хамтаар танд харах боломжийг олгодог. Эдгээр жагсаалтууд эсвэл байгаа бусдын аль нэгэнд элсэхийн тулд &a.mailman.lists.link; хаяг уруу орж элсэхийг хүссэн жагсаалтаа сонгоорой. Дарааллын үлдсэн зааврууд тэнд байгаа болно. Хэрэв та бүх л эх модон дахь өөрчлөлтийг дагах сонирхолтой байгаа бол &a.svn-src-all.name; жагсаалтад бүртгүүлэхийг бид зөвлөж байна. Хэрэв та шинэ систем суулгаж &os.stable;-ээс бүтээсэн сар бүрийн хормын агшны хувилбарыг түүн дээр ажиллуулахыг хүсэж байгаа бол дэлгэрэнгүй мэдээллийн талаар Хормын агшны хувилбарууд вэб хуудаснаас шалгана уу. Үүнээс гадна хамгийн сүүлийн үеийн &os.stable; хувилбарыг толин тусгалын хаягуудаас татан авч суулгах боломжтой бөгөөд доор дурдсан заавруудыг дагаж өөрийн системийг хамгийн сүүлийн үеийн &os.stable; эх код уруу шинэчилж болох юм. Хэрэв та &os;-ийн урдны хувилбар аль хэдийн ажиллуулж байгаа бөгөөд эхээс шинэчлэхийг хүсэж байгаа бол &os;-ийн толин тусгал хуудасаас хялбараар хийж болно. Үүнийг хоёр аргаар хийж болно: cvsup cron -STABLE CVSup ашиглан сүүлийн хэлбэрт аваачих /usr/share/examples/cvsup санд байх standard-supfile гэж нэрлэгдсэн supfile-тай цуг cvsup програм ашигла. Энэ нь бүхэл цуглуулгыг нэг л удаа авч дараа нь зөвхөн өөрчлөгдсөнүүдийг танд авах боломжийг олгодог хамгийн сайшаасан арга юм. Олон хүмүүс cvsup-г cron-с ажиллуулж өөрсдийн эхийг хамгийн сүүлийн хэлбэр автоматаар аваачдаг. Та дээр дурдсан жишээ supfile-г өөрчлөн cvsup-г өөрийн орчны хувьд тохируулах хэрэгтэй. -STABLE CTM ашиглан сүүлийн хэлбэрт аваачих CTM хэрэгслийг ашигла. Хэрэв танд Интернэт уруу холбогдсон хурдан хямд холболт байхгүй бол энэ аргыг та ашиглах хэрэгтэй. Гол нь хэрэв та эхэд хурдан, шаардлагын улмаас хандах хэрэгтэй болоод холболтуудын зурвасын өргөн ач холбогдолгүй бол cvsup эсвэл ftp ашиглаарай. Бусад тохиолдолд CTM-г ашигла. -STABLE хөрвүүлэх нь &os.current;-ийг хөрвүүлэхээсээ өмнө /usr/src дахь Makefile-г анхааралтай уншина уу. Эхний удаа та хамгийн багаар бодоход шинэчлэлтийн процессийн хэсэг болох шинэ цөмийг суулгаж ертенцийг дахин бүтээх хэсгээр дамжих хэрэгтэй. &a.current; болон /usr/src/UPDATING файлыг унших нь биднийг дараагийн хувилбар уруу шилжихэд заримдаа шаардлагатай болдог бусад эхлүүлэх процедуруудын хувьд хамгийн сүүлийн мэдээлэлтэй байлгах боломжийг бидэнд олгодог. Өөрийн эхийг хамгийн сүүлийн хэлбэрт аваачих нь Интернетийн (эсвэл цахим захидал) холболт ашиглан &os; төслийн эхүүдийн аль ч хэсгийн хувьд эсвэл таны юу сонирхож байгаагаас хамааран бүх хэсгүүдийг хамгийн шинэ байлгаж байх төрөл бүрийн аргууд байдаг. Бидний санал болгодог үндсэн үйлчилгээнүүд бол Anonymous буюу нэргүй CVS, CVSup болон CTM юм. Өөрийн эх модны зөвхөн зарим хэсгийг шинэчлэх боломжтой боловч цорын ганц шинэчлэх арга бол модыг бүтнээр нь шинэчилж хэрэглэгчийн талбар (өөрөөр хэлбэл /bin болон /sbin гэх мэт дэх хэрэглэгчийн талбарт ажилладаг бүх програмууд) болон цөмийн эхүүдийг дахин эмхэтгэх явдал юм. Өөрийн эх модны зөвхөн нэг хэсэг зөвхөн цөм эсвэл зөвхөн хэрэглэгчийн талбарыг шинэчлэх нь асуудлууд гарахад ихэвчлэн хүргэдэг. Эдгээр асуудлууд нь эмхэтгэлтийн үеийн алдаануудаас авахуулаад цөмийн сүйрлүүд эсвэл өгөгдлийн эвдрэлийг хүртэл хамардаг. CVS anonymous буюу нэргүй Нэргүй CVS болон CVSup нь эхийг шинэчлэхдээ татах загварыг хэрэглэдэг. CVSup-ийн хувьд хэрэглэгч (эсвэл cron скрипт) cvsup програмыг эхлүүлэн хаа нэгтээ байгаа cvsupd серверт хандаж таны өөрийн файлуудыг хамгийн шинэ хэлбэрт авчирдаг. Таны хүлээн авах шинэчлэлтүүд нь хамгийн сүүлийн минут хүртэлх үеийнх байх бөгөөд та тэдгээрийг зөвхөн өөрийн хүссэн тэр үедээ авдаг. Та өөрийн шинэчлэлтүүдийг таны сонирхож байгаа тусгайлсан файлууд эсвэл сангуудаар хялбараар хязгаарлаж болно. Шинэчлэлтүүд нь таны юуг авахыг хүссэн болон танд юу байгаагаас хамааран серверээр тухайн үед үүсгэгддэг. Нэргүй CVS нь алсын CVS repository буюу кодын архиваас өөрчлөлтүүдийг шууд татахыг түүнд зөвшөөрдөг CVS-ийн ердөө л нэг өргөтгөл бөгөөд үүгээрээ CVSup-с арай илүү хялбар юм. CVSup нь үүнийг хамаагүй илүү үр дүнтэйгээр хийж чаддаг боловч Нэргүй CVS-г ашиглахад илүү хялбар байдаг. CTM Нөгөө талаас CTM нь танд байгаа эхийг мастер архив дахь эхтэй лавлаж асуух зарчмаар харьцуулдаггүй бөгөөд өөрөөр хэлбэл тэдгээрийг татаж авдаггүй. Ингэхийн оронд харин өмнө нь ажиллуулснаас хойшх файл дахь өөрчлөлтүүдийг таньдаг скрипт өдөрт хэд хэдэн удаа мастер CTM машин дээр ажиллаж илэрсэн өөрчлөлтүүдийг шахаж дарааллын-дугаар тавин цахим захидлаар дамжуулахад зориулан кодчилдог (зөвхөн хэвлэгдэх боломжтой ASCII хэлбэрээр). Эдгээр CTM дельтануудыг авсаны дараа тэдгээрийг автоматаар декод хийж шалган хэрэгчид байгаа эхийн хуулбарт өөрчлөлтүүдийг хийх &man.ctm.rmail.1; хэрэгсэл уруу өгдөг. Энэ процесс нь CVSup-с хамаагүй илүү үр дүнтэй бөгөөд энэ нь татах биш харин түлхэх загвар учраас бидний серверийн эх үүсвэрт бага ачаалал учруулдаг юм. Мэдээж үүнээс гадна харилцан сул болон давуу талуудтай асуудлууд байдаг. Хэрэв та санамсаргүйгээр өөрийн архивын хэсгийг устгачих юм бол CVSup үүнийг илрүүлж эвдэрсэн хэсгүүдийг дахин бүтээж өгдөг. CTM ингэж хийдэггүй бөгөөд хэрэв та өөрийн эх модны зарим хэсгийг устгасан (бас нөөцлөн аваагүй) бол та дахин шинээр эхнээс нь (хамгийн сүүлийн үеийн CVS суурь дельтагаас) эхэлж CTM-ийн тусламжтайгаар бүгдийг дахин бүтээх буюу эсвэл Нэргүй CVS-ийн тусламжтайгаар муу битүүдийг ердөө л устгаж дахин сүүлийн хэлбэрт аваачих хэрэгтэй болно. <quote>Ертөнц</quote>ийг дахин бүтээх нь Ертөнцийг дахин бүтээх нь Та өөрийн локал эх модоо &os;-ийн тухайн хувилбарын (&os.stable;, &os.current;, гэх зэрэг) хамгийн сүүлийн үеийн хэлбэрт аваачсаныхаа дараа та эх модоо ашиглан системийг дахин бүтээж болно. Нөөц хий Та дээрхийг хийхээсээ өмнө өөрийн системийг нөөцлөн авах нь ямар чухал болохыг энэ нь хангалттай хэлж өгч чаддаггүй. Ертөнцийг дахин бүтээх нь (хэрэв та эдгээр заавруудыг дагасан тохиолдолд) хялбар боловч таныг алдаа гаргахад эсвэл бусдын эх модонд хийсэн алдаанууд нь таны системийг ачаалагдахгүй болгох нөхцөлд зайлшгүй хүргэдэг. Нөөц хийж авсан эсэхээ шалгаарай. Засварлах уян диск эсвэл ачаалагдах CD-г гарын дор байлгаарай. Магадгүй та үүнийг хэзээ ч хэрэглэхгүй байж болох юм, гэхдээ харамсахаасаа өмнө аюулгүй байж байх нь илүү дээр юм! Тохирох захидлын жагсаалтад бүртгүүл захидлын жагсаалт &os.stable; болон &os.current; салбарууд нь угаасаа хөгжүүлэлтэд байдаг. &os;-д хувь нэмэр оруулж байгаа хүмүүс нь хүн л учраас алдаанууд заримдаа гардаг. Заримдаа эдгээр алдаанууд нь нэг их хор хөнөөлгүй бөгөөд ердөө л таны системийг шинэ оношлогооны анхааруулга хэвлэхэд хүргэдэг. Эсвэл өөрчлөлт нь сүйрлийн байж болзошгүй байдаг бөгөөд таны системийг ачаалагдахгүй болгож эсвэл файлын системүүдийг чинь устгаж (эсвэл бүр муу юм болж) болох юм. Эдгээртэй адил асуудлууд гарвал асуудлын учир шалтгаан болон аль систем дээр энэ асуудал хамааралтайг тайлбарласан heads up буюу бүхний сонорт хандсан зарлал тохирох захидлын жагсаалтад илгээгддэг. Тэгээд all clear буюу бүгд цэвэр зарлал асуудал шийдэгдсэний дараа тавигддаг. Хэрэв та &os.stable; эсвэл &os.current;-ийг дагахыг оролдож &a.stable; эсвэл &a.current;-г харгалзуулан уншихгүй байгаа бол энэ нь та өөртөө гай төвөг асууж байна л гэсэн үг юм. <command>make world</command> тушаалыг бүү ашигла Ихэнх хуучин баримтууд үүнд зориулан make world тушаалыг ашиглахыг зөвлөдөг. Энэ тушаалыг ажиллуулснаар зарим нэг чухал алхмуудыг алгасах бөгөөд та юу хийж байгаагаа мэдэж байгаа тохиолдолд үүнийг зөвхөн ашиглах хэрэгтэй. Бараг ихэнх тохиолдолд make world хийх нь буруу зүйл бөгөөд энд тайлбарласан процедурыг түүний оронд ашиглах ёстой юм. Шалгагдсан аргаар өөрийн системийг шинэчлэх нь Өөрийн системийг шинэчлэхийн тулд өөрт чинь байгаа эхийн хувилбарт шаардлагатай байгаа бүтээхээс урьдах алхмууд та /usr/src/UPDATING файлд байгаа эсэхийг шалгах хэрэгтэй бөгөөд үүний дараа доор дурдсан процедурыг ашиглана: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now buildworld алхмаас өмнө mergemaster -p тушаалыг нэмж ажиллуулах цөөн ховор тохиолдлууд байдаг. Эдгээрийн талаар UPDATING файлд тайлбарласан байдаг. Хэрэв та &os;-ийн нэг буюу олон голлох хувилбаруудын дагуу шинэчлэл хийхгүй байгаа бол ерөнхийдөө энэ алхмыг эмээлгүйгээр орхиж болох юм. installkernel амжилттай дууссаны дараа та ганц хэрэглэгчийн горим уруу ачаалах хэрэгтэй (өөрөөр хэлбэл  boot -s тушаалыг дуудагч мөрөөс ашиглана). Дараа нь доор дурдсан тушаалуудыг ажиллуулна: &prompt.root; mount -a -t ufs &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Тайлбаруудыг цааш уншина уу Дээр тайлбарласан дараалал нь зөвхөн таныг эхлэхэд туслах богино сэргээлт болох юм. Гэхдээ хэрэв та ялангуяа өөрчлөн тохируулсан цөмийн тохиргоо ашиглахыг хүсэж байгаа бол дараах хэсгүүдийг уншиж алхам бүрийг сайтар ойлгох хэрэгтэй. <filename>/usr/src/UPDATING</filename> файлыг унш Өөр юм хийж эхлэхээсээ өмнө та /usr/src/UPDATING-г (эсвэл эх кодын хуулбар хаана байгаа тэндээс үүнтэй төстэй файлыг ) уншаарай. Энэ файл нь танд учирч болзошгүй асуудлуудын талаар чухал мэдээлэл агуулдаг бөгөөд эсвэл таны ажиллуулах зарим нэг тушаалуудын дарааллын талаар заасан байдаг. Хэрэв UPDATING файл таны энд уншсантай зөрчилдөж байвал UPDATING файлд заасныг дагах хэрэгтэй. UPDATING файлыг унших нь өмнө нь тайлбарласнаар зөв захидлын жагсаалтад бүртгүүлэхтэй харьцуулах юм бол хүлээн зөвшөөрч болохуйц орлогч байж чадахгүй юм. Энэ хоёр шаардлага нь нэмэлт бөгөөд заавал шаардлагатай биш юм. <filename>/etc/make.conf</filename> файлыг шалга make.conf /usr/share/examples/etc/make.conf болон /etc/make.conf файлыг шалгаарай. Эхнийх нь зарим нэг анхдагч тодорхойлолтуудыг агуулдаг – тэдгээрийн ихэнх нь тайлбар болон хаагдсан байдаг. Та системээ эхээс нь дахин бүтээх үедээ тэдгээрийг ашиглахын тулд /etc/make.conf файлд нэмэх хэрэгтэй. /etc/make.conf файлд нэмсэн болгон make тушаалыг ажиллуулах бүрд бас ашиглагддаг учир өөрийн системдээ зориулан тэдгээрийг боломжийн утгаар тохируулж өгөх нь зүйтэй юм. Ердийн хэрэглэгч /usr/share/examples/etc/make.conf файлд байдаг CFLAGS болон NO_PROFILE мөрүүдийг /etc/make.conf уруу хуулж тэдгээрийг тайлбар болгосныг болиулж нээхийг магадгүй хүсэж болох юм. Бусад тодорхойлолтуудыг (COPTFLAGS, NOPORTDOCS гэх зэрэг) шалгаж танд хамаатай эсэхээс хамаарч оруулах эсэхээ шийдээрэй. <filename>/etc</filename> дэх файлуудыг шинэчил /etc сан нь таны системийн тохиргооны мэдээллийн ихэнх хэсгийг агуулдгаас гадна системийг эхлүүлэхэд ажилладаг скриптүүд энд байдаг. Эдгээр скриптүүдийн зарим нь FreeBSD-ийн хувилбараас хувилбарт өөрчлөгддөг. Тохиргооны файлуудын зарим нь бас системийг ажиллуулахад өдөр тутам хэрэглэгддэг. Ялангуяа /etc/group-г дурдаж болно. make installworld тушаалын суулгалт хийх хэсэг нь зарим нэг хэрэглэгчийн нэр эсвэл бүлгүүд байж байна гэж тооцдог тохиолдлууд байдаг. Шинэчлэл хийж байх үед эдгээр хэрэглэгчид эсвэл бүлгүүд ихэнхдээ байхгүй байдаг. Энэ нь шинэчлэл хийхэд асуудал учруулдаг. Зарим тохиолдолд make buildworld нь эдгээр хэрэглэгчид эсвэл бүлгүүд байгаа эсэхийг шалгана. Үүний нэг жишээ нь smmsp хэрэглэгч нэмэгдсэн тохиолдол юм. &man.mtree.8; нь /var/spool/clientmqueue-г үүсгэхийг оролдох үед хэрэглэгчийн суулгалтын процесс энэ асуудлаас болж амжилтгүй болж байсан. Үүний шийдэл нь &man.mergemaster.8;-г ертөнцийг бүтээхээс урд тохируулгатай ажиллуулах явдал юм. Энэ нь buildworld эсвэл installworld тушаалыг амжилттай болгоход зөвхөн шаардлагатай файлуудыг харьцуулдаг. Хэрэв таны хуучин mergemaster хувилбар тохируулгыг дэмждэггүй бол эх модон дахь шинэ хувилбарыг эхний удаа ажиллуулахдаа ашиглаарай: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Хэрэв та ялангуяа хэтэрхий санаа зовж байгаа бол тухайн бүлэгт харьяалагдаж байгаа нэрийг нь өөрчилж байгаа эсвэл устгаж байгаа ямар файлууд байгааг өөрийн системээс шалгаарай: &prompt.root; find / -group GID -print дээрх нь GID (энэ бүлгийн нэр байж болно эсвэл бүлгийн тоон ID байж болно) бүлгийн эзэмшдэг файлуудыг харуулна. Ганц хэрэглэгчийн горимд шилж ганц хэрэглэгчийн горим Та системийг ганц хэрэглэгчийн горимд эмхэтгэхийг хүсэж болох юм. Энэ нь шинэчлэлтийг арай илүү хурдасгах илэрхий ашиг тустайгаас гадна системийг дахин суулгах нь системийн стандарт хоёртын файлууд, libraries буюу туслах сангууд, оруулгын файлууд гэх зэрэг системийн маш олон чухал файлуудыг хөнддөг. Ажиллаж байгаа систем дээр эдгээрийг өөрчлөх нь (ялангуяа хэрэв тухайн үед таны систем дээр идэвхтэй хэрэглэгчид байвал) гай төвгийг өөрөө эрж байна гэсэн үг юм. олон хэрэглэгчийн горим Өөр нэг арга бол системийг олон хэрэглэгчийн горимд эмхэтгэж дараа нь суулгахдаа ганц хэрэглэгчийн горимд шилжин хийх явдал юм. Хэрэв та энэ замаар хийхийг хүсэж байвал бүтээлт дуустал дараах алхмууд дээр хүлээж байгаарай. Та installkernel эсвэл installworld хийх хүртлээ ганц хэрэглэгчийн горимд оролгүйгээр хүлээж байж болно. Супер хэрэглэгч болоод та доор дурдсаныг: &prompt.root; shutdown now ажиллаж байгаа системээс ганц хэрэглэгчийн горим уруу оруулахдаа ажиллуулж болно. Өөр нэг арга нь системийг дахин ачаалаад ачаалалтын тушаал хүлээх мөрөн дээр single user буюу ганц хэрэглэгч тохируулгыг сонгоорой. Ингэхэд систем ганц хэрэглэгчийг ачаална. Бүрхүүлийн тушаал хүлээх мөрөнд та доор дурдсан тушаалуудыг ажиллуулах шаардлагатай: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Энэ нь файлын системүүдийг шалгаж /-г дахин унших/бичихээр дахин холбож бусад бүх UFS файлын системүүдийг /etc/fstab-д заасны дагуу холбон дараа нь swap-ийг идэмвхжүүлэх болно. Хэрэв таны CMOS цаг нь GMT биш локал хугацаагаар тохируулагдсан бол (хэрэв &man.date.1; тушаалын гаралт зөв цаг болон бүсийг харуулахгүй бол энэ нь үнэн) та дараах тушаалыг бас ажиллуулах хэрэгтэй болж болох юм: &prompt.root; adjkerntz -i Энэ нь таны локал цагийн бүсийн тохируулгуудыг зөвөөр тохируулж өгдөг — үүнийг хийхгүй бол та дараа нь зарим асуудлуудтай тулгарч магадгүй. <filename>/usr/obj</filename>-г устга Системийн хэсгүүд дахин бүтээгдсэнийхээ дараа (анхдагчаар) /usr/obj дахь сангуудад байршдаг. Эдгээр сангууд нь /usr/src дотор байгааг халхалдаг. Та make buildworld процессийг хурдасгаж болох бөгөөд энэ санг бас устгаснаар хамаарлын зовлонгуудаас өөрийгөө магадгүй аврах болно. /usr/obj доторх зарим файлуудад immutable буюу хувиршгүй туг тавигдсан (дэлгэрэнгүй мэдээллийг &man.chflags.1;-с үзнэ үү ) байж болох бөгөөд түүнийг эхлээд арилгах хэрэгтэй. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Үндсэн системийг дахин эмхэтгэ Гаралтыг хадгалах нь &man.make.1;-г ажиллуулахдаа гарах үр дүнг өөр файл уруу хадгалах нь зүйтэй юм. Хэрэв ямар нэг юм болохоо боливол та алдааны мэдэгдлийн хуулбартай байх болно. Энэ нь танд юу буруутсаныг шинжлэхэд чинь тус болохгүй байж болох боловч та өөрийн энэ асуудлаа &os;-ийн аль нэг захидлын жагсаалт уруу илгээсэн тохиолдолд бусдад тус болж болох юм. Үүнийг хамгийн амраар хийхийн тулд &man.script.1; тушаалыг бүх гаралтыг хадгалах файлын нэрийг заасан параметрийн хамтаар ашиглана. Та үүнийг ертөнцийг дахин бүтээхээс өмнөхөн нэн даруй хийж дараа нь процесс дууссаны дараа exit гэж бичиж гарна. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … Хэрэв та үүнийг хийх бол гаралтыг /tmp дотор битгий хадгалаарай. Энэ сан нь таныг дахин ачаалсны дараа цэвэрлэгдэж болох юм. Энэ файлыг хадгалах арай илүү боломжийн газар нь /var/tmp (өмнөх жишээн дээрх шиг) эсвэл root хэрэглэгчийн гэр сан байж болох юм. Үндсэн системийг эмхэтгэ Та /usr/src сан дотор байх шаардлагатай: &prompt.root; cd /usr/src (гэхдээ мэдээж таны код өөр газар байгаа тохиолдолд тэр сан уруугаа орох хэрэгтэй). make Ертөнцийг дахин бүтээхдээ та &man.make.1; тушаалыг ашиглана. Энэ тушаал нь &os;-ийн агуулсан програмууд ямар дарааллаар дахин хэрхэн бүтээгдэх зэргийг тайлбарласан Makefile файлаас заавруудыг уншдаг. Таны бичих тушаалын мөрийн ерөнхий хэлбэр нь дараах байдлаар байна: &prompt.root; make -x -DVARIABLE target Энэ жишээн дээр нь &man.make.1; уруу таны дамжуулах тохируулга юм. &man.make.1;-н гарын авлагын хуудаснаас та дамжуулж болох тохируулгуудын жишээг үзнэ үү. тохируулга нь Makefile уруу хувьсагч дамжуулж байна. Makefile-ийн ажиллагаа эдгээр хувьсагчуудаар хянагдана. Эдгээр нь /etc/make.conf дотор зааж өгсөн хувьсагчуудтай адил бөгөөд энэ нь тэдгээрийг тохируулах бас нэг өөр арга юм. &prompt.root; make -DNO_PROFILE target тушаал нь профиль хийгдсэн сангууд бүтээгдэх ёсгүйг заах өөр нэг арга бөгөөд энэ нь /etc/make.conf дахь дараах NO_PROFILE= true # Avoid compiling profiled libraries мөрд харгалзах юм. target нь &man.make.1;-д таны юу хийхийг хэлж өгдөг. Makefile болгон өөр өөр targets буюу даалгаврын төрлүүдийг тодорхойлдог бөгөөд таны сонгосон төрөл юу болохыг тодорхойлдог. Зарим төрлүүд Makefile-д жагсаагдсан байх бөгөөд гэхдээ эдгээр нь таныг ажиллуулахад зориулагдаагүй. Харин тэдгээр нь системийг дахин бүтээхэд шаардлагатай алхмуудыг хэд хэдэн дэд алхмуудад хуваахын тулд бүтээх процессод хэрэглэгддэг. Ихэнх тохиолдолд та &man.make.1; уруу ямар ч параметр дамжуулах хэрэггүй бөгөөд тэгэхээр таны тушаал дараахтай ижил байж болно: &prompt.root; make target дээрх target нь олон бүтээх тохируулгуудын нэг болно. Эхний төрөл нь үргэлж buildworld байх ёстой. Нэртэйгээ адилаар buildworld нь /usr/obj дотор бүрэн гүйцэд шинэ модыг бүтээх бөгөөд өөр нэг төрөл болох installworld нь энэ модыг тухайн машин дээр суулгадаг. Тусдаа тохируулгуудтай байх нь хоёр шалтгаанаар маш ач холбогдолтой юм. Нэгдүгээрт энэ нь бүтээлтийг таны ажиллаж байгаа системийн ямар ч хэсэгт нөлөөлөхгүйгээр аюулгүйгээр хийхийг танд зөвшөөрдөг. Бүтээлт нь өөр дээрээ хийгдэнэ (self hosted). Ийм болохоор та buildworld тушаалыг олон хэрэглэгчийн горимд ажиллаж байгаа машин дээр буруу нөлөөллөөс айлгүйгээр аюулгүйгээр хийж болно. Гэхдээ installworld хэсгийн хувьд ганц хэрэглэгчийн горимд хийхийг танд зөвлөдөг. Хоёрдугаарт энэ нь сүлжээн дэх олон машинуудыг шинэчлэхэд NFS холболтуудыг ашиглахыг танд зөвшөөрдөг. Хэрэв танд гурван машин байгаа бөгөөд A, B болон C машинуудыг шинэчлэхийг хүсвэл make buildworld болон make installworld тушаалыг A дээр ажиллуулна. Дараа нь B болон C машинууд A дээрх /usr/src болон /usr/obj сангуудыг NFS холболт хийн make installworld-г ажиллуулж бүтээлтийн үр дүнг B болон C дээр суулгаж болох юм. world төрөл байсаар байгаа хэдий ч танд түүнийг ашиглахгүй байхыг зөвлөж байна. Дараах тушаалыг ажиллуул &prompt.root; make buildworld Хэд хэдэн зэрэгцээ процессуудыг үүсгэх тохируулгыг make тушаалд зааж өгөх боломжтой. Энэ нь олон CPU-тэй машинууд дээр хамгийн их ашигтай. Гэхдээ эмхэтгэх процессийн ихэнх нь CPU дээр биш IO дээр ажилладаг болохоор энэ нь бас нэг CPU-тэй машинууд дээр ашигтай юм. Ердийн нэг CPU-тэй машин дээр та доор дурдсаныг ажиллуулж болох юм: &prompt.root; make -j4 buildworld &man.make.1; нь 4 хүртэлх процессийг нэгэн зэрэг ажиллуулах юм. Захидлын жагсаалтуудад илгээгдсэн туршлагаас харахад энэ нь ерөнхийдөө ажиллагааг хамгийн сайн хангаж хурдасгадаг байна. Хэрэв та олон CPU машинтай бөгөөд SMP тохируулагдсан цөм ашиглаж байвал утгыг 6-аас 10 хүртэл болгож хэр хурдсаж байгааг хараарай. Хугацаа ертөнцийг дахин бүтээх нь хугацаа Бүтээхэд шаардагдах хугацаанд олон хүчин зүйлс нөлөөлдөг, гэхдээ нэлээн сүүлийн үеийн машинуудын хувьд &os.stable; модыг процессийн явцад ямар нэгэн заль мэх эсвэл дөт зам ашиглалгүйгээр бүтээхэд зөвхөн нэг юм уу эсвэл хоёр цаг л шаардагдах болох юм. &os.current; модны хувьд арай удах болов уу. Шинэ цөмийг эмхэтгэж суулга цөм суулгах нь Та өөрийн шинэ системийн давуу талыг бүгдийг нь авахын тулд цөмөө дахин эмхэтгэх хэрэгтэй. Зарим нэг санах ойн бүтцүүд өөрчлөгдсөн байх талтай бөгөөд &man.ps.1; болон &man.top.1; зэрэг програмууд нь цөм болон эх кодын хувилбарууд адил болтол ажилладаггүй болохоор эмхэтгэх нь үнэндээ чухал хэрэгцээтэй юм. Үүнийг хамгийн хялбараар аюулгүйгээр хийхийн тулд GENERIC дээр тулгуурласан цөмийг бүтээж суулгах явдал юм. GENERIC нь таны системийн хувьд хэрэгцээтэй төхөөрөмжүүдийг агуулаагүй байж болох боловч таны системийг ядаж ганц хэрэглэгчийн горимд ачаалахад шаардлагатай бүгдийг агуулсан байх ёстой. Шинэ систем зөв ажиллуулахад энэ сайн тест болж өгдөг. GENERIC-с ачаалж таны систем ажиллаж байгааг шалгасны дараа та өөрийн ердийн цөмийн тохиргооны файл дээр тулгуурлан шинэ цөмөө бүтээж болох юм. &os; дээр шинэ цөм бүтээхээсээ өмнө ертөнцийг бүтээх нь чухал юм. Хэрэв та өөрчлөн тохируулсан цөмийг бүтээхийг хүсэж тохиргооны файлаа аль хэдийн үүсгэсэн бол доор дурдсантай адилаар KERNCONF=MYKERNEL гэж ашиглаарай: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL Хэрэв та kern.securelevel хувьсагчийг 1-ээс дээш болгон ихэсгэсэн бөгөөд noschg эсвэл түүнтэй адил тугуудыг өөрийн цөмийн хоёртын файлд тавьсан бол installkernel хийхийн тулд та ганц хэрэглэгчийн горимд шилжин орох шаардлагатай байж болох юм. Үгүй бол та энэ хоёр тушаалыг олон хэрэглэгчийн горимоос ямар ч асуудалгүйгээр ажиллуулах ёстой. kern.securelevel-ийн талаар дэлгэрэнгүйг &man.init.8; болон төрөл бүрийн файлын тугуудын талаар дэлгэрэнгүйг &man.chflags.1; гарын авлагын хуудаснуудаас үзнэ үү. Ганц хэрэглэгчийн горим уруу дахин ачаалан ор ганц хэрэглэгчийн горим Та шинэ цөмийн ажиллагааг шалгахын тулд ганц хэрэглэгчийн горимд дахин ачаалан орох хэрэгтэй. Үүнийг дахь заавруудын дагуу хийнэ. Шинэ системийн хоёртын файлуудыг суулга Хэрэв та make buildworld тушаалыг ашигласан саяхны &os;-ийн хувилбарыг бүтээж байгаа бол одоо шинэ системийн хоёртын файлуудыг суулгахын тулд installworld тушаалыг ашиглах шаардлагатай. Доор дурдсаныг ажиллуулна &prompt.root; cd /usr/src &prompt.root; make installworld Хэрэв та make buildworld тушаалын мөрөнд хувьсагчуудыг зааж өгсөн бол тэдгээр хувьсагчуудыг make installworld тушаалын мөрөнд бас адилаар зааж өгөх хэрэгтэй. Энэ бусад тохируулгуудын хувьд заавал шаардлагатай биш байж болох юм; жишээ нь тохируулга installworld-той цуг хэзээ ч хэрэглэгдэх ёсгүй. Жишээ нь хэрэв та доор дурдсаныг ажиллуулсан бол: &prompt.root; make -DNO_PROFILE buildworld хоёртын файлуудыг дараах тушаалаар суулгана: &prompt.root; make -DNO_PROFILE installworld ингэхгүй бол make buildworld тушаалын ажиллах явцад бүтээгдээгүй профиль хийгдсэн сангуудыг (libraries) суулгахыг оролдох болно. <command>make installworld</command> тушаалаар шинэчлэгдээгүй файлуудыг шинэчил Ертөнцийг дахин бүтээх нь зарим нэг сангуудыг (ялангуяа /etc, /var болон /usr) шинэ болон өөрчлөгдсөн тохиргооны файлуудаар шинэчилдэггүй. Эдгээр файлуудыг хамгийн амархнаар шинэчлэх арга нь &man.mergemaster.8;-г ашиглах явдал юм, гэхдээ та хэрэв хүсвэл үүнийг гараар ажиллуулах боломжтой юм. Аль ч аргыг сонголоо гэсэн ямар нэгэн зүйл буруутсан тохиолдолд сэргээх боломжтойгоор /etc-г нөөцөлж авах нь зүйтэй юм. Том Рөүдс Хувь нэмэр болгон оруулсан <command>mergemaster</command> mergemaster &man.mergemaster.8; хэрэгсэл нь /etc дэх таны тохиргооны файлууд болон /usr/src/etc эх модон дахь тохиргооны файлуудын ялгааг тодорхойлоход танд тусалдаг Bourne скрипт юм. Энэ нь системийн тохиргооны файлуудыг эх модон дахь тохиргооны файлуудаар шинэчлэх зориулалттай бидний зөвлөдөг шийдэл юм. Эхлэхийн тулд өөрийн тушаал оруулах мөрөнд ердөө л mergemaster-г бичиж түүний эхлэхийг нь хараарай. mergemaster нь түр зуурын root орчныг /-с доошлуулан бүтээж төрөл бүрийн системийн тохиргооны файлуудаар дамждаг. Тэдгээр файлууд нь таны системд суулгагдсан файлуудтай харьцуулагддаг. Энэ үед хоорондоо ялгаатай файлууд &man.diff.1; хэлбэрээр үзүүлэгддэг бөгөөд тэмдэгтээр нэмэгдсэн эсвэл өөрчлөгдсөн мөрүүдийг тэмдэгтээр устгагдсан эсвэл шинэ мөрөөр солигдсон мөрүүдийг харуулдаг. &man.diff.1;-н синтакс болон файлын өөрчлөлтүүдийг хэрхэн үзүүлдэг талаар дэлгэрэнгүй мэдээллийг &man.diff.1; гарын авлагын хуудаснаас үзнэ үү. &man.mergemaster.8; нь зөрчилдөөнүүдийг үзүүлсэн файл болгоныг харуулдаг бөгөөд энэ үед танд шинэ файлыг устгах (түр зуурын файл гэгддэг), түр зуурын файлыг өөрчлөлгүйгээр суулгах, суусан байгаа файлтай түр зуурын файлыг нийлүүлэх эсвэл &man.diff.1;-н гаралтыг дахин харах сонголтыг үзүүлэх болно. Түр зуурын файлыг устгахыг сонгосноор бид одоо байгаа файлаа хэвээр өөрчлөлгүй үлдээж шинэ хувилбарыг устгахыг хүсэж байгаагаа &man.mergemaster.8;-д хэлж байна гэсэн үг юм. Хэрэв та одоо байгаа файлаа өөрчлөх шалтгааныг олж харахгүй байгаагаас бусад тохиолдолд энэ сонголтыг хийхийг зөвлөдөггүй. Та ямар ч үед &man.mergemaster.8; тушаал хүлээх мөрөн дээр ? гэж бичин тусламж авч болох юм. Хэрэв хэрэглэгч файлыг орхихоор сонгосон бол энэ нь бусад бүх файлуудтай ажилсны дараа дахин үзүүлэгдэн хэрэглэгчээс тушаал хүлээх болно. Өөрчлөгдөөгүй түр зуурын файлыг суулгахыг сонгосноор одоо байгаа файлыг шинээр сольдог. Ихэнх өөрчлөгдөөгүй файлуудын хувьд энэ нь хамгийн шилдэг сонголт юм. Файлыг нийлүүлэхийг сонгосноор текст засварлагч болон хоёр файлын агуулгыг танд харуулах болно. Та дэлгэцийн хоёр талд байрласан тэдгээр хоёр файлыг хоёуланг нь шалган аль аль талаас нь хэрэгтэй хэсгүүдийг сонгон эцсийн бүтээгдэхүүн гаргаж аван нийлүүлж болно. Файлууд нь дэлгэцийн хоёр талд байрлан харьцуулагдах явцад l түлхүүр таны зүүн талын агуулгыг сонгодог бол r түлхүүр нь таны баруун тал дахь агуулгыг сонгох юм. Гарах эцсийн үр дүн нь хоёр файлын хоёулангийн хэсгүүдийг агуулсан файл болох бөгөөд түүнийг дараа нь суулгах боломжтой болох юм. Энэ сонголтыг хэрэглэгчийн тохиргоонуудад хийгдсэн өөрчлөлтүүдтэй файлуудын хувьд хэрэглэх нь зуршил болжээ. &man.diff.1;-ээс гарах үр дүнг дахин харахыг сонгосноор өмнө нь &man.mergemaster.8; файлын өөрчлөлтүүдийг харуулан таны сонголтыг хүлээсний нэгэн адилыг дахин харуулдаг. &man.mergemaster.8; системийн файлуудтай ажиллаж дууссаны дараа танаас бусад сонголтуудыг хийхийг хүлээдэг. &man.mergemaster.8; тушаал нууц үгийн файлыг дахин бүтээхийг хүсэж байгаа эсэхийг танаас асууж үлдсэн түр зуурын файлуудыг устгах сонголтыг үзүүлэн дуусдаг. Гараар шинэчлэх Хэрэв та гараар шинэчлэхийг хүсвэл гэхдээ та /usr/src/etc сангаас /etc сан уруу файлуудыг зүгээр л дарж хуулж ажиллуулж чадахгүй. Зарим файлуудыг эхлээд суулгах хэрэгтэй. Учир нь /usr/src/etc сан таны /etc сангийн хуулбар шиг байхаар харагддагүй. Мөн /usr/src/etc санд байдаггүй хэрнээ /etc сан дотор байх шаардлагатай зарим файлууд байдаг. Хэрэв та &man.mergemaster.8; (зөвлөсний дагуу) ашиглаж байвал та дагаагийн хэсэг уруу орж болно. Үүнийг гараар хамгийн хялбар аргаар хийхийн тулд файлуудыг шинэ сан уруу суулгаж нэг бүрчлэн өөрчлөлтүүдийг хайн ажиллах хэрэгтэй. Өөрт байгаа <filename>/etc</filename>-г нөөцөл Онолоор бол автоматаар энэ санд юу ч хүрдэггүй ч үүнд үргэлж итгэлтэй байх хэрэгтэй. Тэгэхээр өөрийн байгаа /etc санг хаа нэг аюулгүй газар хуулах хэрэгтэй. Доорхтой адилаар: &prompt.root; cp -Rp /etc /etc.old нь рекурсив хуулбар хийх бөгөөд нь файлуудын хугацаа, эзэмшигч гэх мэтийг хадгалдаг. Та шинэ /etc болон бусад файлуудыг суулгахын тулд хоосон сангууд бүтээх хэрэгтэй. /var/tmp/root нь боломжийн сонголт болох бөгөөд энэ сангийн доор хэд хэдэн дэд сангууд бас шаардлагатай болно. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Энэ нь шаардлагатай сангийн бүтцийг бүтээж файлуудыг суулгадаг. /var/tmp/root дотор үүсгэгдсэн олон дэд сангууд хоосон бөгөөд тэдгээрийг устгах шаардлагатай байдаг. Үүнийг хамгийн хялбараар хийхийн тулд: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Энэ нь бүх хоосон сангуудыг устгана. (Хоосон биш сангуудын тухай анхааруулгуудыг гаргахгүйн тулд стандарт алдаа нь /dev/null уруу илгээгддэг.) Одоо /var/tmp/root нь /-с доор байрлах тохирох байрлалуудад байршуулах ёстой бүх файлуудыг агуулсан байх болно. Та одоо эдгээр файл бүрийг шалгаж танд байгаа файлуудаас хэрхэн ялгаатай болохыг тогтоох хэрэгтэй. /var/tmp/root дотор суулгагдсан зарим файлуудын нэр урдаа . тэмдэгттэй байдгийг анхаарна уу. Энэ баримтыг бичиж байх үед ийм файлуудтай адил файлууд /var/tmp/root/ болон /var/tmp/root/root/ сан дахь бүрхүүлийн эхлүүлэх файлууд байсан, гэхдээ (таны хэзээ үүнийг уншиж байгаагаас хамаарч) өөр бусад файлууд байхыг үгүйсгэхгүй. Тэдгээрийг олж харахын тулд ls -a тушаалыг заавал ашиглаарай. Үүнийг хамгийн хялбар аргаар хийж хоёр файлыг харьцуулахын тулд &man.diff.1; тушаалыг ашиглах явдал юм: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Энэ нь таны /etc/shells файл болон шинэ /var/tmp/root/etc/shells файлын хоорондын ялгааг харуулна. Эдгээрийг ашиглаж өөрийн хийсэн өөрчлөлтүүдийг нийлүүлэх эсвэл өөрийн хуучин файл дээрээс хуулах эсэхээ шийдээрэй. Хувилбаруудын Хоорондох Ялгаануудыг Хялбараар Харьцуулахын Тулд Та Шинэ Root Сангаа Тухайн Үеийн Хугацаагаар Нэрлээрэй Ертөнцийг байнга дахин бүтээнэ гэдэг нь /etc-г та бас байнга шинэчилнэ гэсэн үг бөгөөд энэ нь ердөө л жижиг хэвшмэл ажил юм. Та энэ процессийг /etc уруу нийлүүлсэн өөрийн хамгийн сүүлийн өөрчлөгдсөн файлуудыг хадгалснаар хурдасгаж болох юм. Дараах процедур үүнийг хэрхэн хийж болох нэг санааг өгч байна. Ертөнцийг жирийнээр бүтээ. /etc болон бусад сангуудыг шинэчлэхийг хүсэхдээ тухайн цаг дээр тулгуурласан нэр бүхий санг өг. Хэрэв та үүнийг 1998 оны 2 сарын 14-нд хийж байгаа бол дараах байдлаар хийнэ: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Энэ сангийн өөрчлөлтүүдийг дээр дурдсаны дагуу нийлүүл. Та дууссаныхаа дараа /var/tmp/root-19980214 санг битгий устгаарай. Та эхийн хамгийн сүүлийн хувилбарыг татан авч дахин бүтээхдээ 1-р алхмыг дага. Энэ нь танд шинэ сан өгөх бөгөөд /var/tmp/root-19980221 гэж нэрлэгдсэн байж болох юм (хэрэв та шинэчлэлтүүдийг хийхдээ долоо хоног хүлээсэн бол). Та одоо &man.diff.1; ашиглан хоёр сангийн хооронд рекурсив diff үүсгэж долоо хоногийн хооронд хийгдсэн өөрчлөлтүүдийг харж болно: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Ихэнхдээ энэ нь /var/tmp/root-19980221/etc болон /etc хоёрын хоорондох өөрчлөлтүүдийг бодох юм бол харьцангуй бага өөрчлөлтүүд байдаг. Өөрчлөлтүүд нь арай бага болохоор тэдгээр өөрчлөлтүүдийг өөрийн /etc сан уруу шилжүүлэх нь илүү хялбар байдаг. Та одоо хоёр /var/tmp/root-* сангуудын аль хуучныг устгаж болно: &prompt.root; rm -rf /var/tmp/root-19980214 /etc уруу өөрчлөлтүүдийг нийлүүлэх болгондоо энэ процессийг давтах хэрэгтэй. Та &man.date.1;-г ашиглан сангийн нэрсийг автоматаар үүсгэж болно: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Дахин ачаалах нь Та ерөнхийдөө ингээд хийгээд дуусч байна. Та бүх зүйл байх ёстой байрандаа байгаа эсэхийг шалгасныхаа дараа системийг дахин ачаалж болно. Энгийн &man.shutdown.8; үүнийг хийх болно: &prompt.root; shutdown -r now Дууслаа Одоо та өөрийн &os; системийг амжилттайгаар шинэчлээд дууссан байх ёстой. Баяр хүргэе. Хэрэв юмс шал буруугаар эргэвэл системийн тухайн хэсгийг дахин бүтээхэд амархан байдаг. Жишээ нь хэрэв та шинэчлэлтийн явцад эсвэл /etc-г нийлүүлэх явцад санамсаргүйгээр /etc/magic файлыг устгасан бол &man.file.1; тушаал ажиллахаа больно. Ийм тохиолдолд дараах засварыг ажиллуулж болох юм: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Асуултууд Өөрчлөлт бүрт зориулан ертөнцийг дахин бүтээх хэрэгтэй юу? Үүнд хялбар хариулт байхгүй, учир нь өөрчлөлтийн цаад утга чанараас хамаарна. Жишээ нь хэрэв та CVSup-г дөнгөж ажиллуулахад дараах файлууд шинэчлэгдэж байгааг үзүүлж байгаа бол: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk магадгүй бүхэл ертөнцийг дахин бүтээх хэрэггүй байж болох юм. Та тохирох дэд сангууд уруу орж make all install гэж тушаалыг өгөөд л болох юм. Хэрэв зарим нэг гол чухал зүйл жишээ нь src/lib/libc/stdlib өөрчлөгдсөн бол та ертөнцийг эсвэл хамгийн багаар бодоход статикаар холбогдсон (statically linked) түүний тэдгээр хэсгүүдийг дахин бүтээх шаардлагатай болно. Эцсийн эцэст энэ нь танаас л хамаарна. Та жишээ нь хоёр долоо хоног тутам ертөнцийг дахин бүтээж тэр хоёр долоо хоногийн хугацаанд өөрчлөлтүүдийг хуримтлуулж байгаадаа сэтгэл хангалуун байж болно. Эсвэл та зөвхөн өөрчлөгдсөн зүйлсүүдийг дахин бүтээхийг хүсэж магадгүй бөгөөд бүх хамаарлуудыг шийднэ гэдэгтээ итгэлтэй байх хэрэгтэй. Тэгээд мэдээж энэ бүхэн таны ямар давтамжтайгаар шинэчлэхийг хүсдэг болон &os.stable; эсвэл &os.current;-ийн алийг дагаж байгаагаас хамаарах болно. Миний эмхэтгэл маш олон дохио 11 (эсвэл бусад дохионы дугаар) алдаагаар амжилтгүй болсон. Юу болсон юм бол? дохио 11 Энэ нь ихэвчлэн тоног төхөөрөмжийн асуудлыг илэрхийлдэг. Ертөнцийг (дахин) бүтээх нь өөрийн тоног төхөөрөмжийг ачаалах тест хийх үр дүнтэй арга бөгөөд удаа дараа санах ойн асуудлууд байвал тэдгээрийг илрүүлдэг. Эмхэтгэгч нь сонин/хачин дохионуудыг хүлээн авч ид шидийн байдлаар амжилтгүй болсноор тэдгээр асуудлууд нь өөрсдийгөө зарлан тунхагладаг. Хэрэв та бүтээлтийг дахин эхлүүлээд тэр нь процессийн өөр өөр хэсэгт амжилтгүй болж байвал энэ нь үүнийг тодоор зааж байна гэсэн үг юм. Энэ тохиолдолд та өөрийн машин дахь бүрэлдэхүүн хэсгүүдээ өөрчлөн нэгээс нөгөөд сольж тавин аль нь ажиллахгүй байгааг олохоос өөр зүйл хийж чадахгүй л болов уу. Би дууссаныхаа дараа /usr/obj-г устгаж болох уу? Товчхондоо бол болно. /usr/obj нь эмхэтгэх үед бүтээгдсэн бүх обьект файлуудыг агуулдаг. Жирийн үед make buildworld процессийн эхний алхмуудын нэг нь энэ санг устгаад цоо шинээр эхлэх явдал юм. Энэ тохиолдолд /usr/obj-г дууссаныхаа дараа байлгаад байх нь ухаалаг биш бөгөөд үүнийг устгаснаар ихээхэн хэмжээний дискний зайг суллах болно (одоогоор 340 MB орчим). Гэхдээ хэрэв та юу хийж байгаагаа мэдэж байгаа бол make buildworld хийхдээ энэ алхмыг алгасаж болно. Энэ нь дараа дараагийн бүтээлтийг илүү хурдасгадаг бөгөөд учир нь ихэнх эхүүд дахин эмхэтгэх шаардлагагүй байдаг. Үүний сул тал нь баригдашгүй хамаарлын асуудлууд илэрч таны бүтээлтийг хачин байдлаар амжилтгүй болгодог. Хэн нэгэн илүү дөтлөх гэснээсээ болоод амжилтгүй болсныг мэдэлгүй өөрийн бүтээлтийг амжилтгүй болсныг гомдоллосноор &os;-ийн захидлын жагсаалтуудад хий дэмий шуугианыг удаа дараа үүсгэдэг билээ. Тасалдсан бүтээлтүүдийг үргэлжлүүлж болох уу? Энэ нь асуудлыг олох хүртлээ та хэр хол явснаас хамаарна. Ерөнхийдөө (энэ нь хэцүү бас хурдан дүрэм биш) make buildworld процесс нь үндсэн багажуудын (&man.gcc.1;, болон &man.make.1; зэрэг) болон системийн сангуудын шинэ хуулбаруудыг бүтээдэг. Тэдгээр багажууд болон сангууд нь дараа нь суулгагддаг. Шинэ багажууд болон сангууд дараа нь өөрсдийгөө дахин бүтээхэд ашиглагддаг бөгөөд дахин суулгагддаг. Бүхэл бүтэн систем (одоо &man.ls.1; эсвэл &man.grep.1; зэрэг ердийн хэрэглэгчийн програмууд) дараа нь шинэ системийн файлуудтайгаар дахин бүтээгддэг. Хэрэв та сүүлийн шатанд байгаа бөгөөд та үүнийг мэдэж байгаа бол (та хадгалж байгаа гаралтаас харсан болохоор) та дараах тушаалыг ажиллуулж (бараг л аюулгүйгээр) болно: … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all Энэ нь өмнөх make buildworld тушаалын хийснийг буцаахгүй. Хэрэв та доорх мэдэгдлийг : -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- make buildworld тушаалын гаралт дээр харсан бол магадгүй тэгж хийх нь аюулгүй байж болох юм. Хэрэв та тийм мэдэгдэл харахгүй байгаа бол эсвэл та итгэлтэй биш байгаа бол харамсахаасаа өмнө аюулгүй байдлыг бодож бүтээлтийг бүр эхнээс нь дахин эхлүүлсэн нь дээр юм. Би ертөнцийг бүтээхийг хэрхэн хурдасгах вэ? Ганц хэрэглэгчийн горимд ажиллуул. /usr/src болон /usr/obj сангуудыг тус тусдаа байх дискнүүд дээр тус тусдаа байх файлын системүүд дээр байрлуул. Хэрэв боломжтой бол эдгээр дискнүүдийг тус тусад нь дискний хянагчууд дээр байрлуул. &man.ccd.4; (нийлүүлсэн дискний драйвер) төхөөрөмж ашиглан эдгээр файлын системүүдийг олон дискнүүдийн дагуу байрлуулах нь бас арай илүү хурдасгах юм. Профиль хийгдэхийг (/etc/make.conf файлд NO_PROFILE=true гэж зааж өг) болиул. Танд энэ бараг гарцаагүй хэрэггүй. /etc/make.conf файлд бас CFLAGS-г гэдэгтэй адилаар заа. оновчлол нь илүү удаан байдаг бөгөөд болон оновчлолын ялгаа ихэвчлэн өчүүхэн байдаг. нь эмхэтгэгчид холбооны зориулалтаар түр зуурын файлуудыг биш хоолойнуудыг ашиглахыг зөвшөөрдөг бөгөөд энэ нь дискэнд хандах хандалтыг (санах ойг илүүтэй хэрэглэж) багасгадаг. тохируулгыг &man.make.1;-д дамжуулж олон процессийг зэрэгцээгээр ажиллуул. Энэ нь танд ганц эсвэл олон процессортой машин аль нь ч байсан ялгаагүйгээр ихэвчлэн тусалдаг. /usr/src-г агуулж байгаа файлын систем тохируулгаар холболт хийгдэж (эсвэл салгагдаж) болно. Энэ нь файлын систем файл уруу хандах хандалтын хугацааг бүртгэхийг болиулдаг. Танд магадгүй энэ мэдээлэл бараг л хэрэггүй биз ээ. &prompt.root; mount -u -o noatime /usr/src Энэ жишээ /usr/src нь өөрийн файлын систем дээр байгаа гэж тооцож байгаа болно. Хэрэв энэ нь тийм биш бол (хэрэв энэ сан жишээ нь /usr-ийн хэсэг маягаар байгаа бол) та /usr/src-г биш харин тэр файлын системээ холболтын цэг болгон ашиглах хэрэгтэй. /usr/obj-г агуулж байгаа файлын систем тохируулгатай холболт хийгдэж (эсвэл салгагдаж) болно. Энэ нь диск уруу хийх бичилтийг асинхроноор буюу зэрэг биш хийлгэдэг. Өөрөөр хэлбэл бичилт нэн даруй хийгдээд өгөгдөл диск уруу цөөн секундын дараа бичигддэг. Энэ нь бичилтүүдийг бүлэглэхийг зөвшөөрч маш их үр дүнтэйгээр ажиллагааг хурдасгаж болох юм. Энэ тохируулга нь таны файлын системийг илүү эмзэг болгохыг санаарай. Тэжээл тасалдаж машин дахин ачаалах үед файлын систем сэргээж болшгүй төлөвт орох магадлал энэ тохируулгатай байхад илүү байдаг. Хэрэв /usr/obj нь энэ файлын систем дээрх цорын ганц зүйл бол энэ асуудал биш юм. Хэрэв танд уг файлын систем дээр өөр, үнэтэй өгөгдөл байгаа бол энэ тохируулгыг идэвхжүүлэхээсээ өмнө өөрийн нөөц чинь шинэ эсэхийг шалгаарай. &prompt.root; mount -u -o async /usr/obj Дээр дурдсан шиг хэрэв /usr/obj нь өөрийн файлын систем дээр биш байх юм бол жишээн дээрхийг тохирох холболт хийх цэгийн нэрээр солиорой. Хэрэв ямар нэг юм буруутвал би юу хийх вэ? Таны орчинд өмнөх бүтээлтүүдийн үеийн илүү үлдэгдлүүд байхгүйд үнэхээр итгэлтэй байх хэрэгтэй. Энэ нь их амархан юм. &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir Тиймээ, make cleandir тушаалыг үнэндээ хоёр удаа ажиллуулах шаардлагатай. Тэгээд make buildworld тушаалыг эхлүүлж бүх процессийг дахин эхлүүл. Хэрэв та асуудалтай хэвээр байгаа бол алдаа болон uname -a тушаалын дүнг &a.questions; уруу явуулаарай. Өөрийн тохиргооныхоо талаар бусад асуултанд хариулахад бэлэн байгаарай! Майк Мэйэр Хувь нэмэр болгон оруулсан Олон машины хувьд дагах нь NFS олон машин суулгах нь Хэрэв та олон машинуудын хувьд ижил эх модыг дагахыг хүсэж бүгдийн хувьд эхийг татан авахуулж бүгдийг дахин бүтээхийг хүсэж байгаа бол энэ нь дискний зай, сүлжээний зурвасын өргөн болон CPU циклүүд зэрэг эх үүсвэрүүдийг үр ашиггүйгээр ашиглахад хүргэхээр санагдаж болох юм. Тиймээ, үүний шийдэл нь нэг машинаар ихэнх ажлыг хийлгэж бусад машинууд нь тэр ажлыг NFS-ээр дамжуулан холбох явдал юм. Энэ хэсэгт ингэж хийх аргыг тайлбарсан. Бэлтгэл ажлууд Эхлээд хоёртын адил файлуудыг ажиллуулах build set буюу бүтээх олонлог гэж бидний нэрлэх машинуудыг олох хэрэгтэй. Машин бүр өөрчлөн тохируулсан цөмтэй байж болох бөгөөд гэхдээ тэд ижил хэрэглэгчийн талбарын хоёртын файлуудыг ажиллуулж байх ёстой. Тэр олонлогоос бүтээх машиныг сонгох хэрэгтэй. Энэ нь ертөнц болон цөм бүтээгдэх машин байх юм. Туйлын хүслээр бол энэ нь make buildworld болон make buildkernel тушаалуудыг ажиллуулахад хангалттай нөөц CPU бүхий хурдан машин байх хэрэгтэй. Та мөн үйлдвэрлэлд ашиглахаас өмнө програм хангамжуудыг тест хийдэг тест машин сонгохыг бас хүсэж болох юм. Энэ нь удаан хугацаагаар унтраастай эсвэл зогссон байж болох машин байх ёстой. Энэ нь бүтээх машин байж болох юм, гэхдээ заавал биш юм. Энэ бүтээх олонлог дахь бүх машинууд нь өөр өөрийн машин дээрээсээ ижил цэг дээр /usr/obj болон /usr/src-г холболт хийх хэрэгтэй. Туйлын хүслээр бол энэ нь бүтээх машин дээрх хоёр өөр дискнүүд байж болох бөгөөд гэхдээ эдгээр нь уг машин дээр NFS холболт бас хийгдэж болохоор байж болох юм. Хэрэв танд олон бүтээх олонлогууд байгаа бол /usr/src сан нь нэг бүтээх машин дээр байрлаж бусад дээр нь NFS холболт хийгдсэн байх юм. Төгсгөлд нь бүтээх олонлогийн бүх машинууд дээрх /etc/make.conf болон /etc/src.conf файлууд бүтээх машиныхтай тохирч байгаа эсэхийг шалгаарай. Энэ нь бүтээх олонлогийн машин бүрийн суулгах үндсэн системийн бүх хэсгүүдийг бүтээх машин хийх ёстой гэсэн үг юм. Мөн бүтээх машин бүр өөрийн цөмийн нэрийг /etc/make.conf файлд KERNCONF хувьсагчид заан өгөх ёстой бөгөөд бүтээх машин бүр KERNCONF хувьсагчдаа өөрийн цөмийг эхэнд оруулан дараа нь тэдгээрийг жагсаах ёстой байдаг. Бүтээх машин нь машин бүрийн цөмийг бүтээхээр болох юм бол тэдгээрийн тохиргооны файлыг /usr/src/sys/arch/conf санд агуулсан байх шаардлагатай. Үндсэн систем Одоо бүх юм ингэж хийгдсэний дараа та бүгдийг бүтээхэд бэлэн боллоо. Бүтээх машин дээр -д тайлбарласны дагуу цөм болон ертөнцийг бүтээ, гэхдээ юуг ч битгий суулгаарай. Бүтээлт дууссаны дараа тест машин дээр дөнгөж саяхан бүтээсэн цөмөө суулга. Хэрэв энэ машин нь /usr/src болон /usr/obj сангуудыг NFS-ээр холболт хийх гэж байгаа бол та ганц хэрэглэгчийн горимд дахин ачаалахдаа сүлжээг нээж тэдгээрийг холбож өгөх хэрэгтэй. Үүнийг хамгийн хялбараар хийхийн тулд олон хэрэглэгчийн горимд ачаалан shutdown now тушаалыг ажиллуулж ганц хэрэглэгчийн горимд орох явдал юм. Тэгэж орсныхоо дараа та шинэ цөм болон ертөнцийг суулгаж жирийн үедээ хийдэг mergemaster тушаалыг ажиллуулж болно. Ингэж дууссаныхаа дараа энэ машины хувьд ердийн олон хэрэглэгчийн үйлдлүүдэд дахин ачаалж орно. Тест машин дээрх бүх зүйлс зөв ажиллаж байгааг мэдсэнийхээ дараа та бүтээх олонлогийн бусад машин бүр дээр шинэ програм хангамж суулгахдаа ижил процедурыг ашиглаарай. Портууд Үүнтэй адил санааг бас портуудын модонд ашиглаж болно. Эхний чухал алхам бол нөгөө машин дээрх /usr/ports санг бүтээх олонлогийн бусад машинууд дээр холбож өгөх явдал юм. Дараа нь та /etc/make.conf файлыг distfiles буюу түгээлтийн файлуудыг хуваалцахаар зөв тохируулж өгч болно. Та DISTDIR хувьсагчийг таны NFS холболтуудад заагдсан аль ч root хэрэглэгчийн хувьд бичигдэх боломжтой байх нийтлэг хуваалцсан сангаар тохируулах шаардлагатай. Машин бүр WRKDIRPREFIX хувьсагчийг локал бүтээх сангаар зааж өгөх хэрэгтэй. Эцэст нь хэрэв та багцуудыг бүтээж түгээх гэж байгаа бол PACKAGES хувьсагчийг DISTDIR хувьсагчийн нэгэн адил сангаар зааж өгөх хэрэгтэй.