. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Або користуватися для цього тою або ╕ншою схемою автоматичного монтування директор╕й. Виб╕р в Л╕накс╕ зводиться або до користування amd - демоном автомонтування BSD, або до autofs - "р╕дно╖" системи автомонтування в Л╕накс╕, яка можлива з ядрами 2.x. Як та, так ╕ ╕нша схема мають сво╖ плюси та м╕нуси, але як т╕, так ╕ ╕нш╕ виходять за рамки тематики даного п╕дручника, а скор╕ше належать до Системно╖ адм╕н╕страц╕╖ мереж╕. Можливо колись дойдуть руки ╕ до цього. (-Д.К.)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
В деяких випадках бува╓ зручн╕ше монтувати /var/spool/mail як NFS директор╕ю з поштового сервера. Наприклад, розглянемо орган╕зац╕ю з великою розгалуженою мережею робочих станц╕й ╕ одним основним розпод╕льником пошти (поштовим вузлом (mail hub)). Якщо пошта розпод╕ля╓ться з головного поштового розпод╕льника по робочих станц╕ях, кожна робоча станц╕я буде мати т╕льки поштов╕ скрин╕ ос╕б, як╕ працюють на дан╕й станц╕╖. Отож, неможливо прочитати свою пошту при переход╕ на ╕нший комп'ютер. Звичайно, можна користуватися POP-поштою, але це тема для ╕ншо╖ розмови ╕ кр╕м того вона ма╓ сво╖ проблеми. Кр╕м того на поштовому вузл╕ потр╕бно буде пост╕йно п╕дтримувати в робочому стан╕ файл /etc/aliases або базу даних користувач╕в, в якому збер╕гаються адреси (поштов╕ "псевда") користувач╕в системи - де, на як╕й робоч╕й станц╕╖, той чи ╕нший користувач хот╕в би читати свою пошту. Вих╕д ╕з ц╕╓╖ ситуац╕╖ виявля╓ться надзвичайно простим. Достатньо орган╕зувати одну-╓дину директор╕ю /var/spool/mail на поштовому вузл╕ ╕ монтувати ╖╖ на кожн╕й робоч╕й станц╕╖, як проблеми в╕дпадають сам╕ собою. Кожне робоче м╕сце буде мати вс╕ поштов╕ скриньки змонтован╕ в /var/spool/mail ╕ кожен користувач зможе читати свою пошту на будь-якому робочому м╕сц╕. (-Д.К.)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Дозволю соб╕ не погодитися з твердженням про ``зм╕стовн╕сть'' даних ╕ндикатор╕в. Три числа, як╕ вказують на завантаження системи, ╓ середня к╕льк╕сть процес╕в, як╕ стоять в черз╕ на доступ до процесора, заф╕ксована в три р╕зн╕ моменти часу, а саме: на час в╕дкриття файлу /proc/loadavg (Чи на час виконання команди uptime в системах, як╕ не мають /proc/loadavg , як, наприклад, SunOS, Solaris чи Л╕накс з ядром до 1.3.59), п'ять хвилин тому та п'ятнадцять хвилин тому. В систем╕ з одним користувачем, процесор майже завжди спить, прокидаючись лиш на коротк╕ мит╕ щоб в╕ддати коротке розпорядження комусь ╕з п╕длеглих - дискам, пам'ят╕ чи дисплею та щоб знову заснути п╕сля цього. Тому ╕ завантаження тако╖ системи завжди буде не б╕льше, н╕ж 0,1-0,2. Пристойно завантажений сервер покаже 2-3 процеси, яких мучить безсоння чи не да╓ спати турбота про користувача. Якщо ж loadavg ф╕ксу╓ навантавження б╕ля 10-20, то це ╓ ознакою того, що щось негаразд ╕з даною системою - з яко╖сь причини навантаження на сервер занадто велике. (-Д.К.)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Запис геометр╕╖ диску в CMOS ╓ специф╕чною ознакою PC BIOS'╕в. ╤нш╕ системи користуються б╕льш розвиненими методами визначення геометр╕╖ диск╕в. Всього лиш к╕лька сл╕в для прикладу - в SunOS та Solaris ╓ спец╕альна база даних тип╕в диск╕в, в як╕й ставиться у в╕дпов╕дн╕сть р╕зн╕ типи диск╕в та ╖х геометр╕╖. Тип диску визнача╓ться системою з його етикетки, яка записана в заголовку самого диску. Sparc Л╕накс теж не користу╓ться BIOS'ом для визначення геометр╕╖ диск╕в з то╖ просто╖ причини, що комп'ютери Sun просто не мають BIOS'╕в. Я не знаю, як саме Sparc Л╕накс визнача╓ геометр╕ю диск╕в, тому буду радий, якщо хтось з Вас под╕литься з╕ мною знаннями.
Також б╕льш сучасн╕ BIOS'и (практично вс╕, що випускаються на сьогодн╕шн╕й день - я не зустр╕чав в останн╕й час жодно╖ ново╖ материнсько╖ плати PC без ц╕╓╖ установки) вм╕ють визначати типи диск╕в п╕д'╓днаних до системи. ╤ в╕д користувача не вимага╓ться вносити зм╕ни в установки BIOS'у п╕сля зм╕ни диск╕в.
(-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Результатом такого п╕дходу ╕ ╓ те, що: з одного боку система
завжди автоматично знаходиться в межах 1024 перших цил╕ндр╕в,
а з ╕ншого - несистемний диск можна зробити системним т╕льки
наново в╕дформатувавши його (що, можливо, не вс╕м до
смаку). Кр╕м того, що ще г╕рше, систему неможливо поновити
(тобто поновити ╖╖ ядро) записавши зам╕сть старого ядра нове
на диск. А мр╕яти про те, щоб мати на диску два ядра (йдеться
не про два р╕зних розд╕ли з р╕зними системами на них, а саме
про один розд╕л з к╕лькома ядрами, як╕ можна стартувати за
бажанням).
В будь-якоому Юн╕кс╕, ( Л╕накс не ╓ виключенням), можливо
вказати яке саме ядро Ви хочете стартувати. Але оск╕льки
Л╕наксу д╕сталися в спадщину обмеження, ╕снуюч╕ в св╕т╕ PC,
доводиться трохи хитрувати, щоб ╖х об╕йти - ╕ вимога мати ядро
на перших цил╕ндрах ╓ саме такими хитрощами. (-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Кожен файл ма╓ inode, але не кожен файл ма╓ св╕й власний inode. Власне, для кращого розм╕ння варто п╕дкреслити, що саме inode ╕ ╓ файлом, а та назва, що бачить користувач, ╓ всього-навсього етикеткою, яка причеплена до inode. Якщо inode ма╓ к╕лька етикеток, то кажуть, що м╕ж файлами встановлен╕ ``жорстк╕ ссилки'' - hard link. Тобто дв╕ р╕зн╕ етикетки можуть вказувати на один ╕ той же файл - для користувача це вигляда╓ так, н╕би то один файл ма╓ к╕лька назв.
Сл╕д також в╕дчувати р╕зницю м╕ж жорсткими та м'якими (символ╕чними) ссилками (soft link або symbolic link, symlink). Якщо жорстка ссилка це не що ╕нше, як просто ╕нша назва одного ╕ того ж файлу, то символ╕чна ссилка - це спец╕альний вид файлу. Якщо подивитися на символ╕чну ссилку, наприклад, командою ls -l , то пом╕тно, що символ╕чна ссилка - це файл дуже невеликого розм╕ру, часто 10-14 байт. Що ж таке ц╕ байти? Це - просто маршрут до ориг╕налу (як кажуть "батька") ц╕╓╖ символ╕чно╖ ссилки.
Так, наприклад, якщо символ╕чна ссилка була створена такою командою, як ln -s /usr/X11R6 /usr/X11 , то файл /usr/X11 буде символ╕чною ссилкою на /usr/X11R6 , ╕ його розм╕р буде р╕вно 10 байт - тобто к╕льк╕сть символ╕в у /usr/X11R6, разом ╕з '/'.
# ln -s /usr/X11R6 /usr/X11
#ls -l
#total 42
#lrwxrwxrwx 1 root root 10 Mar 31 08:22 X11 -> /usr/X11R6/
# [...]
В╕д звичайних файл╕в (в тому числ╕ ╕ в╕д жорстких ссилок) символ╕чн╕ ссилки в╕др╕зняються першим символом в рядку, що вказу╓ тип файлу - тобто в тому байт╕ inode, де запису╓ться тип файлу, у символ╕чно╖ ссилки записано ``l''.
(-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Наявн╕сть д╕рок в файлах ╕нколи може спричинити деяк╕ непри╓мнощ╕. Тому треба пам'ятати про те в яких файлах д╕рки можуть траплятися ╕ що треба робити, щоб ц╕ д╕рки ``обходити''.
Так, наприклад, одним з найб╕льш розповсюджен╕ших тип╕в
файл╕в, в яких можуть траплятися д╕рки ╓ файли баз даних
dbm. Так╕ файли використовуються в базах даних мап
NIS ![[*]](cross_ref_motif.gif)
або в базах даних користувач╕в, як╕
використовуються в sendmail верс╕й 8.x.
Через те, ╕нколи виявля╓ться, що сума розм╕р╕в вс╕й файл╕в баз
даних може бути б╕льшою, н╕ж розм╕р дискового розд╕лу, який
м╕стить так╕ файли. Якщо в мереж╕ ма╓ться к╕лька сервер╕в NIS,
то вони найчаст╕ше будуються за принципом - один головний
сервер (master) ╕ вс╕ ╕нш╕ сервери-п╕длегл╕ (slave). При
необх╕дност╕ обновити бази даних на п╕длеглих серверах
використову╓ться команда xfer , яка фактично робить
коп╕ювання файл╕в баз даних з головного сервера на п╕длегл╕.
Це ж саме може в принцип╕ робити команда rcp , ╕ якщо
файли не мають д╕рок, то д╕я обох команд ╕дентична. Але
команда rcp ``не розум╕╓'' д╕рок ╕ у випадку файл╕в з
д╕рками використання команди rcp приводить до того, що
коп╕я виявля╓ться б╕льшою ори╜╕налу ╕ дисковий розд╕л
п╕длеглого сервера може переповнитися в той час, як на
головному сервер╕ ще буде повно в╕льного м╕сця. (-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- vfat
- Файлова система застосовувана в Windows 95 -
розширення файлово╖ системи DOS, яке дозволя╓
користуватися довгими назвами файл╕в.
- hfs
``╤╓рарх╕чна файлова система'' (hierarchical file system), яка застосову╓ться в операц╕йн╕й систем╕ MacOS на Мак╕нтошах. Ця система може мати так╕ два застосування - для читання дискет записаних на Мак╕нтош╕, та (в по╓днанн╕ з реал╕зац╕╓ю протоколу р╕дно╖ Мак╕нтош╕всько╖ мереж╕ AppleTalk) для побудови файл сервера для мереж╕ Mac'╕в (Л╕накс дозволя╓, наприклад, змонтувати Мак╕нтошевський компакт-диск та експортувати його для вс╕╓╖ мереж╕ Mac'╕в).
- ufs
- Файлова система, що застосову╓ться в SunOS та Solaris. В терм╕ноло╜╕╖ SunOS - це файлова система типу ``4.2'', а в Solaris'╕ вона ж носить назву ``ufs''. Дуже важлива файлова система особливо для Sparc Linux'а, оскл╕льки дозволя╓ сп╕льно користуватися файловими системами SunOS/Solaris ╕ Sparc Л╕накса.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(-Д.К.)$mount : only root can do that
$
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
В╕д себе можу додати, що це також зменшу╓ проблеми з системою. Якщо система не користу╓ться квотами (р╕дко хто ма╓ бажання псувати в╕дносини з користувачами), то рано чи п╕зно, не залежно в╕д розм╕ру диску, вид╕леного п╕д домашн╕ директор╕╖, в╕н переповниться. ╤ нав╕ть якщо Ви й змушен╕ будете розсилати користувачам пов╕домлення: ``Панове, чи не будете Ви наст╕льки ласкавими зтерти непотр╕бн╕ файли в Ваших домашн╕х директор╕ях'', або ``Панове: $(cd /home; du -s * | sort -nr | head -10 | awk ' { print $2}') | xargs rm -rf''! (Якщо не зрозум╕ло, що це означа╓, не варто посп╕шати друкувати команду в командному рядку, щоб подивитися, що вона робить. Спробуйте спочатку роз╕братися.) Але при всьому цьому система залиша╓ться в робочому стан╕, ╕ не залежно в╕д того наск╕льки довго користувач╕ будуть борсатися в файлов╕й системи заповнен╕й на 99-100%, Ви зможете зловт╕шно усм╕хаючись, встановлювати нов╕ програми п╕д /usr/local/games .
(-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Кр╕м того, як уже в╕дм╕чалося ран╕ше по тексту, ╕ SunOS ╕
Solaris вм╕ють користуватися NFS для створення файл╕в своп╕н╜у
на NFS сервер╕. (-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Для того, щоб зрозум╕ти зв╕дки така порада з'явилася - дек╕лька сл╕в з ╕стор╕╖. Юн╕кси попередн╕х рок╕в користувалися своп-п╕дрозд╕лом системи для дампу пам'ят╕.
П╕д час навчання в ун╕верситет╕ я п╕дробляв оператором на М4030, ╕ к╕лька раз╕в мен╕ довелося бачити, як виглядав дамп пам'ят╕ там. П╕д час краху (в Юн╕кс╕ кажуть, що ядро виклика╓ стан пан╕ки, або пан╕ку╓) системи М4030 намагалася скинути поточний стан вс╕╓╖ сво╓╖ пам'ят╕ на пап╕р - тобто дамп пам'ят╕ виглядав як неск╕нченне друкування поток╕в ш╕стнадцядкових код╕в. К╕лометри ╕ к╕лограми паперу ╕з стовпчиками чисел по вс╕й його ширин╕. Приблизно те ж саме робили ╕ Юн╕кси, з ╓диною в╕дм╕нн╕стю, що вся пам'ять скидалася на диск. Диск в цьому випадку використовувася, як сирий пристр╕й без файлово╖ системи (важко вимагати в╕д системи, щоб в стан╕ пан╕ки вона ще дбала про як╕сь там файли). Пам'ять скидалася на своп розд╕л диску ╕ робиться в╕д гори до низу - тобто з протилежного к╕нця до того, з якого система почина╓ користуватися диском п╕д своп╕н╜. Коли систему п╕сля цього все таки вдасться завантажити, то в верхн╕й частин╕ розд╕лу ще залиша╓ться образ пам'ят╕ системи в╕д часу пан╕ки, нав╕ть якщо система вже почала своп╕н╜ деяких стор╕нок пам'ят╕ на диск. Л╕накс не користу╓ться такою схемою дампу пам'ят╕, тому рекомендац╕╖ мати своп вдв╕ч╕ б╕льший в╕д ф╕зично╖ пам'ят╕ не мають п╕д собою основи.
(-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
З доданням деяких др╕бничок PC можна зробити бездисковим кл╕╓нтом - тобто комп'ютером, в якому нема╓ н╕ гнучких н╕ жорстких диск╕в, ╕ який можна грузити з сервера в мереж╕. Справжня знах╕дка для обчислювальних зал╕в на багато користувач╕в чи для навчальних клас╕в в школах чи ун╕верситетах. Для робочих станц╕й Sun Sparc не треба н╕чого додавати взагал╕ - кожен Sparc - це готовий бездисковий кл╕╓нт, який буде грузитися зв╕дти, зв╕дки скаже адм╕н╕стратор. Теж саме - нов╕ модел╕ Macintosh'╕в, як╕ побудован╕ з п╕дтримкою загрузки з мереж╕ (╕ для яких, до реч╕, теж ╕сну╓ верс╕я Л╕накса).
(-Д.К.)
В традиц╕йних Юн╕ксах самим першим процесом ╓ завжди процес з
номером 0 - swapper. Цей процес старту╓ (народжу╓) один ╓диний
процес - процес init, який (як це не дивно) отриму╓ номер
1. Вс╕ ╕нш╕ процеси кр╕м цих двох можуть народжуватися ╕
вмирати поки працю╓ процесор, отримують р╕зн╕ номери, але
процеси 0 ╕ 1 живуть поки жива система ╕ вмирають разом з
нею. init - багатод╕тний батько вс╕х ╕нших процес╕в системи.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Я цього не писав. Я всього навсього перекладач. ╤нколи в в╕льний в╕д переклад╕в час, потроху займаютсь системною адм╕н╕страц╕╓ю, за що ╕ отримую грош╕ на св╕й хл╕б.
Взагал╕ керування робочими середовищами користувач╕в заслугову╓ на окрему книжку. Стандарт╕в в ц╕й област╕ нема╓, н╕хто не присвячу╓ ц╕й тем╕ жодних ессе, мемуар╕в... А в цей час страждають беззахисн╕ користувач╕. Але част╕ше трапля╓ться, що страждають в╕д цього саме системн╕ адм╕н╕стратори, - хто його зна╓, як╕ можуть бути користувач╕? Взагал╕ кажучи ``порушення лог╕ки роботи файлу користувача'' занадто сильний вираз, сила якого може в деяких випадках може переважувати варт╕сть позиц╕╖ системного адм╕н╕стратора з ус╕ма вит╕каючими зв╕дси результатами.
Тож щоб порушути табу мовчання в ц╕й област╕... Якщо Ваша орган╕зац╕я ма╓ дуже багато користувач╕в (я маю на уваз╕ `` дуже багато''), то скор╕ше всього вони будуть лог╕чно б╕льш-менш д╕лим╕ на певн╕ групи, тобто: ``професори'' та ``студенти'' чи ``хакери'' та ``бугалтери ╕ завгоспи''. Тож можна замислитися над питанням: "А чи варто взагал╕ бугалтерам та завгоспам давати доступ до редагування ╖хн╕х "персональних" .profile '╕в? Чи може створити для них один ╓диний /home/ENVIRON/ZAVHOSP/profile ╕ зробити /.profile посиланням (softlink) на цей файл. Для користувач╕в же з р╕внем ╕нтелекту вищим в╕д середньо-загально-галузевого варто передбачити в .profile лог╕ку типу: [ -x ${HOME}/.profile-custom ] && { . ${HOME}/.profile-custom}
Ще можу додати, що можливо директор╕я /etc/skel зда╓ться
непоганою ╕де╓ю, але, (з свого власного досв╕ду) т╕льки для систем
в╕д малих до середн╕х - в╕д одного до п╕в-десятка комп'ютер╕в
(можливо до десятка, якщо кожен з комп'ютер╕в ма╓ одного-двох
пост╕йних користувач╕в). Для б╕льших систем користування ц╕╓ю
директор╕╓ю виявля╓ться непрактичним, якщо /etc/skel
м╕стить б╕льше, н╕ж один-два файли ╕ у переважн╕й б╕льшост╕
випадк╕в нехту╓ться. (-Д.К.)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.