Налаштування вашої 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 запускає всі стартові сценарії з теки, котра визначається типовим рівнем запуску (який задається відповідним записом id у /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 постачає invoke-rc.d в якості оболонки для запуску сценаріїв з /etc/init.d/.)

Виходить, Debian не використовує rc.local для налаштування процесу завантаження; що ж в такому випадку використовується?
Припустимо, при завантаженні чи при зміні рівня запуску нам потрібно запускати сценарій foo. Системний адміністратор в такому випадку повинен:
Помістити сценарій foo до теки /etc/init.d/.
Запустити команду update-rc.d з необхідними аргументами, щоб створити відповідні відсилачі між теками rc?.d та /etc/init.d/foo (де '?' — число від 1 до 6, що означає рівень запуску System V).
Перезавантажити систему.
Команда update-rc.d створює відсилачі на сценарії теки /etc/init.d/ у теці rc?.d. Кожен відсилач починається з літери 'S' або 'K', за якими йде номер та власне назва сценарію. Сценарії, що починаються на 'S' з теки /etc/rcN.d/ виконуються при завантаженні рівня запуску N; ті, що починаються на '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