Документація українською/ Debian/ FAQ/ Chapter 10
← Chapter 09 | FAQ | Chapter 11 →

Розділ 10 - Налаштовування вашого Debian GNU/Linux

Як мені переконатись, що всі програми використовують однаковий розмір паперу?

Встановіть пакунок libpaper1 і він встановить однаковий розмір паперу для всієї системи. Ця настройка буде збережена у файлі /etc/papersize.

Користувачі можуть перепризначити розмір паперу за допомогою змінної середовища PAPERSIZE. Деталі описані на сторінці довідки papersize(5).

Як мені надати доступ до периферійних пристроїв не ставлячи під загрозу безпеку?

Багато пристроїв у каталозі /dev належать деяким наперед визначеним групам. Наприклад, /dev/fd0 належить групі floppy, а /dev/dsp - групі audio.

Якщо ви хочете дати якомусь користувачеві доступ до цих пристроїв, просто включіть його у відповідну групу, наприклад ось таким чином:

adduser user group

В цьому випадку вам не потрібно буде змінювати права доступу до пристрою.

Як мені задати консольний шрифт при завантаженні у стилі Debian?

Цю можливість підтримують пакунки kbd та console-tools, відредагуйте конфігураційні файли /etc/kbd/config або ж /etc/console-tools/config.

Як я можу змінити стандартні настройки додатків для X11?

Графічні програми для Debian записують стандартні настройки додатків у каталог /etc/X11/app-defaults/. Якщо ви хочете поміняти їх глобально, запишіть ваші зміни саме у ці файли. Вони позначаються як конфігураційні, отож не будуть замінені під час оновлень.

Схоже, що кожна збірка завантажується по-своєму. Розкажіть, як це робить Debian.

Як і всі інші Юнікси, Debian завантажується виконуючи програму init. Її конфігураційний файл (/etc/inittab) вказує, що першим має виконуватись сценарій /etc/init.d/rcS. Він запускає всі інші сценарії з каталогу /etc/rcS.d/ виконуючи їх безпосередньо, або ж відбруньковуючи, в залежності від їх розширення, щоб провести ініціалізацію системи (наприклад, перевірити та змонтувати файлові системи, завантажити модулі, запустити мережеві служби, налаштувати годинник та ін.). Далі, щоб дотримуватись сумісності, він запускає файли (за винятком тих, що містять символ крапки в імені) з каталога /etc/rc.boot/. Цей каталог, як правило, вважається зарезервованим для адміністраторських цілей і використання його пакунками є ознакою поганого тону.

Після завершення завантажувального процесу init запускає всі стартові сценарії з каталога, котрий визначається типовим рівнем запуску (котрий задається відповідним записом у /etc/inittab). Як і більшість System V-сумісних Юніксів, Linux має 7 рівнів запуску:

  • 0 (зупинка системи),
  • 1 (режим одиночного користувача),
  • від 2 до 5 (різноманітні багатокористувацькі режими), і
  • 6 (перевантаження системи).

Системи Debian як правило постачаються з id=2. Це означає, що типовим рівнем запуску буде '2', з багатокористувацьким режимом, при котрому будуть виконані сценарії з каталогу /etc/rc2.d/.

Фактично в каталогах /etc/rcN.d/ розташовуються не сценарії, а символічні відсилачі на сценарії в каталозі /etc/init.d/. Їх назви підбираються таким чином, щоб вказувати, як саме будуть запускатись відповідні сценарії з каталогу /etc/init.d/. Взагалі, перед переходом на певний рівень виконання, спершу виконуються сценарії, що починаються на літеру 'K'; вони зупиняють (англ. kill) непотрібні служби. Далі запускаються всі сценарії, що починаються на літеру 'S'; вони власне запускають необхідні служби. Двоцифрове число, що йде після 'K' або 'S' вказує на порядок запуску сценарію. Сценарії з меншими числами запускаються першими.

Цей принцип працює тому, що сценарії в каталозі /etc/init.d/ приймають аргументи з набору 'start', 'stop', 'reload', 'restart' та 'force-reload' та виконують відповідні завдання (англ. 'start' - запустити, 'stop' - зупинити, 'reload' - перевантажити, 'restart' - перезапустити та 'force-reload' - перевантажити примусово). Ці сценарії можуть виконуватись при завантаженні системи для контролю різноманітних служб.

Наприклад, з аргументом 'reload' команда

/etc/init.d/sendmail reload

відправить демону sendmail сигнал перечитати заново його конфігураційний файл.

Виходить, Debian не використовує rc.local для налаштування процесу завантаження; що ж в такому випадку використовується?

Припустимо, при завантаженні чи при зміні рівня запуску нам потрібно запускати сценарій foo. Системний адміністратор в такому випадку повинен:

  • Завести цей сценарій у каталозі /etc/init.d/.
  • Запустити команду update-rc.d з необхідними аргументами, щоб створити відповідні відсилачі між каталогами rc?.d та /etc/init.d/foo (де ? – число від 1 до 6, що означає рівень запуску)
  • Перевантажити систему.

Команда update-rc.d створює відсилачі на сценарії каталогу /etc/init.d/ у каталозі rc?. Кожен відсилач починається з літери 'S' або 'K', за якими йде номер та власне ім'я сценарію. Сценарії, що починаються на 'S' виконуються при завантаженні рівня запуску; ті, що починаються на 'K' – при його зупинці.

Отож сценарій foo можна запустити при завантаженні системи, помістивши його в /etc/init.d/ та встановивши відсилач за допомогою команди

update-rc.d foo defaults 19

Аргумент 'defaults' позначає типові рівні запуску – від 2 до 5. Аргумент '19' вказує, що сценарій запуститься перед будь-яким іншим, котрий починається з номера 20 або більшого.

Що система керування робить з пакунками, котрі містять конфігураційні файли інших пакунків?

Хтось з користувачів може захотіти створити, наприклад, нову службу, встановивши групу пакунків Debian та локально створених пакунків, що містять конфігураційні файли. Взагалі-то це не є хорошою ідеєю, тому що dpkg не знатиме про конфігураційні файли з іншого пакунку і може записати суперечливі конфігурації при оновленні одного з пакунків такої групи.

Створіть натомість локальний пакунок, що змінює конфігураційні файли такої групи пакунків. Після цього dpkg та інші системи керування пакунками бачитимуть, що ці файли були модифіковані локальним адміністратором та не старатимуться перезаписувати їх при оновленні.

Як я можу перезаписати файл, встановлений пакунком, так щоб використовувалась інша його версія?

Припустимо, адміністратор, або локальний користувач хочуть використовувати програму "login-local" замість "login", котра поставляється з пакунком login.

НЕ:

  • перезаписуйте файл /bin/login програмою login-local.
    Система керування пакунками не знатиме про цю зміну і просто перезапише ваш модифікований /bin/login при будь-якому встановленні чи оновленні пакунку login (чи будь-якого іншого, котрий поставляє програму /bin/login).

Натомість

  • Виконайте:

     dpkg-divert --divert /bin/login.debian /bin/login

    для того, щоб примусити всі наступні встановлення пакунку login записувати файл /bin/login у /bin/login.debian.

  • Далі запустіть:

     cp login-local /bin/login

    щоб перемістити вашу програму на місце.

За детальнішою інформацією зверність до сторінки підручника dpkg-divert(8).

Як мені додати свій пакунок до списку відомих системі керування пакунками?

Запустіть команду

dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages

де:

  • BIN-DIR – це каталог, в котрому зберігаються файли архівів Debian (що як правило мають розширення ".deb")
  • OVERRIDE_FILE – це файл, що редагується поширювачами збірок та зберігається як правило на FTP-архівах Debian як indices/override.main.gz для пакунків із збірки "main". Для локальних пакунків ви можете ігнорувати цю опцію.
  • PATHPREFIX – це необов’язковий ланцюжок, що може бути доданий до файлу my_Packages при його створенні.

Після того, як ви сформуєте файл my_Packages, накажіть системі керування пакунками використовувати його за допомогою команди

dpkg --merge-avail my_Packages

Якщо ви використовуєте АРТ, ви також можете додати локальне сховище до вашого файлу sources.list(5).

Деяким користувачам подобається mawk, іншим gawk; одні користуються vim, інші elvis; дехто уподобав trn, а дехто tin; як Debian підтримує такі різноманітності?

Є декілька випадків, коли два пакунки поставляють дві різні версії програм, кожна з котрих володіє однаковою базовою функціональністю. Користувачі по якихось причинах можуть надавати перевагу одній перед іншою. В той же час інші користувачі на тій самій системі можуть хотіти користуватись іншою програмою.

Debian використовує "віртуальну" систему пакунків, щоб дозволити адміністраторам (або дати можливість користувачам) обирати улюблені інструменти за наявності двох чи більше програм, котрі пропонують однакову базову функціональність, підтримуючи при цьому залежності без вказування конкретного пакунку.

Наприклад, у системі існує дві різні версії програм для читання новин. Пакунок серверу новин може рекомендувати котрусь із них, але кінцевий вибір між tin та trn робить кожен користувач особисто. Це забезпечується тим, що обидва ці пакунки поставляють віртуальний пакунок news-reader. Котру з програм використовувати вказує відсилач /etc/alternatives/news-reader на вибраний файл, наприклад /usr/bin/trn.

Сам по собі відсилач не здатен підтримувати повноцінне використання альтернативних програм; зазвичай сторінки довідки та можливо інші використовувані файли також повинні підтримуватись. Сценарій Perl update-alternatives забезпечує можливість переконатись, що всі файли, пов’язані з певним пакунком, вибрані як типові у системі.

Наприклад, щоб перевірити, які файли забезпечує 'x-window-manager', запустіть:

update-alternatives --display x-window-manager

Якщо ви хочете щось змінити, виконайте:

update-alternatives --config x-window-manager

Та слідуйте за інструкціями на екрані (як правило, натискайте номер елементу, котрий вам подобається).

Якщо по якійсь причині пакунок не зареєстрував себе, як віконний менеджер, або ж ви хочете використовувати менеджер з каталогу /usr/local, то екранне меню не буде містити потрібного вам елементу. Ви можете оновити конфігурацію за допомогою опцій командного рядка, як наприклад:

update-alternatives --install /usr/bin/x-window-manager \
 x-window-manager /usr/local/bin/wmaker-cvs 50

Перший аргумент опції '--install' є символічним від силачем, що вказує на /etc/alternatives/ІМ’Я, де ІМ’Я – другий аргумент. Третій аргумент – це програма, на котру повинен вказувати /etc/alternatives/ІМ’Я, а четвертий - пріоритет (чим більше значення, тим вища ймовірність автоматичного вибору даної програми).

Щоб видалити додану альтернативу, просто запустіть:

update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs