<?xml version='1.0' encoding='utf-8'?>
<!-- -*- DocBook -*- -->
<chapter id="customizing"><title>Налаштування вашої Debian GNU/Linux</title>
<section id="papersize"><title>Як мені переконатись, що всі програми використовують однаковий розмір паперу?</title>
<para>
Встановіть пакунок <systemitem
role="package">libpaper1</systemitem> і він встановить
однаковий розмір паперу для всієї системи.
Ця настройка буде збережена у файлі
<literal>/etc/papersize</literal>.
</para>
<para>
Користувачі можуть перепризначити розмір
паперу за допомогою змінної середовища
<literal>PAPERSIZE</literal>.  Деталі описано на
сторінці довідки
<citerefentry><refentrytitle>papersize</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
</section>

<section id="hardwareaccess"><title>Як мені надати доступ до периферійних пристроїв не ставлячи під загрозу безпеку системи?</title>
<para>
Багато пристроїв у теці <literal>/dev</literal>
належать деяким наперед визначеним групам.
Наприклад, <literal>/dev/fd0</literal> належить групі
<literal>floppy</literal>, а <literal>/dev/dsp</literal> — групі
<literal>audio</literal>.
</para>
<para>
Якщо ви хочете дати якомусь користувачеві
доступ до цих пристроїв, просто включіть
його у відповідну групу, наприклад ось
таким чином:
</para>
<screen>
adduser user group
</screen>
<para>
В цьому випадку вам не потрібно буде
змінювати права доступу до пристрою.
</para>
</section>

<section id="consolefont"><title>Яким чином в Debian задати консольний шрифт при завантаженні?</title>
<para>
Цю можливість підтримують пакунки <systemitem
role="package">kbd</systemitem> та <systemitem
role="package">console-tools</systemitem>, відредагуйте
конфігураційні файли <literal>/etc/kbd/config</literal>
або ж <literal>/etc/console-tools/config</literal>.
</para>
</section>

<section id="appdefaults"><title>Як я можу змінити стандартні настройки додатків для X11?</title>
<para>
Графічні програми для Debian записують
стандартні налаштування додатків у теку
<literal>/etc/X11/app-defaults/</literal>.  Якщо ви хочете
змінити їх глобально, запишіть ваші зміни
саме у ці файли.  Вони позначаються як
конфігураційні, отож не будуть замінені
під час оновлень.
</para>
</section>

<section id="booting"><title>Схоже, що кожна збірка завантажується по-своєму. Розкажіть, як це робить Debian.</title>
<para>
Як і всі інші Юнікси, Debian завантажується
запускаючи програму <literal>init</literal>.  Її
конфігураційний файл (<literal>/etc/inittab</literal>)
вказує, що першим має виконуватись
сценарій <literal>/etc/init.d/rcS</literal>.  Він запускає
всі інші сценарії з теки <literal>/etc/rcS.d/</literal>,
виконуючи ї х безпосередньо, або ж
відбруньковуючи, в залежності від їх
розширення, щоб провести ініціалізацію
системи (наприклад, перевірити та
змонтувати файлові системи, завантажити
модулі, запустити мережеві служби,
налаштувати годинник та ін.).  Далі, щоб
дотримуватись сумісності, він запускає
файли (за винятком тих, що містять крапки в
назві) з теки <literal>/etc/rc.boot/</literal>.  Ця тека,
зазвичай, вважається зарезервованою для
адміністраторських цілей і використання
його пакунками є ознакою поганого тону.
</para>
<para>
Після завершення завантажувального
процесу <literal>init</literal> запускає всі стартові
сценарії з теки, котра визначається
типовим рівнем запуску (який задається
відповідним записом <literal>id</literal> у
<literal>/etc/inittab</literal>).  Як і більшість System
V-сумісних Юніксів, Linux має 7 рівнів запуску:
</para>
<itemizedlist>
<listitem>
<para>
0 (зупинка системи),
</para>
</listitem>
<listitem>
<para>
1 (однокористувацький режим),
</para>
</listitem>
<listitem>
<para>
від 2 до 5 (різні багатокористувацькі
режими), та
</para>
</listitem>
<listitem>
<para>
6 (перезавантаження системи).
</para>
</listitem>
</itemizedlist>
<para>
Системи Debian як правило постачаються з id=2.
Це означає, що типовим рівнем запуску буде
'2', з багатокористувацьким режимом, при
котрому будуть виконані сценарії з теки
<literal>/etc/rc2.d/</literal>.
</para>
<para>
Фактично в теках <literal>/etc/rcN.d/</literal>
розташовуються не сценарії, а символічні
відсилачі на сценарії в теці
<literal>/etc/init.d/</literal>.  Їх <emphasis>назви</emphasis>
підбираються таким чином, щоб вказувати, в
якій <emphasis>послідовності</emphasis> будуть
запускатись відповідні сценарії з теки
<literal>/etc/init.d/</literal>.  Взагалі, перед переходом
на певний рівень запуску, спершу
виконуються сценарії, що починаються на
літеру 'K'; вони зупиняють (англ.  kill)
непотрібні служби.  Далі запускаються всі
сценарії, що починаються на літеру 'S'; вони
власне запускають необхідні служби.
Двоцифрове число, що йде після 'K' або 'S'
вказує на порядок запуску сценарію.
Сценарії з меншими числами запускаються
першими.
</para>
<para>
Такий підхід працює тому, що сценарії в
теці <literal>/etc/init.d/</literal> приймають аргументи
з набору start, stop, reload, restart та force-reload і
виконують відповідні завдання (англ.  start —
запустити, stop — зупинити, reload —
перевантажити, restart — перезапустити та
force-reload — перевантажити примусово).  Ці
сценарії можуть виконуватись при
завантаженні системи для контролю
різноманітних процесів.
</para>
<para>
Наприклад, з аргументом reload команда
</para>
<screen>
/etc/init.d/sendmail reload
</screen>
<para>
відправить демону sendmail сигнал перечитати
заново його конфігураційний файл.  (Debian
постачає <command>invoke-rc.d</command> в якості
оболонки для запуску сценаріїв з
<literal>/etc/init.d/</literal>.)
</para>
</section>

<section id="custombootscripts"><title>Виходить, Debian не використовує <literal>rc.local</literal> для налаштування процесу завантаження; що ж в такому випадку використовується?</title>
<para>
Припустимо, при завантаженні чи при зміні
рівня запуску нам потрібно запускати
сценарій <literal>foo</literal>.  Системний
адміністратор в такому випадку повинен:
</para>
<itemizedlist>
<listitem>
<para>
Помістити сценарій <literal>foo</literal> до теки
<literal>/etc/init.d/</literal>.
</para>
</listitem>
<listitem>
<para>
Запустити команду <literal>update-rc.d</literal> з
необхідними аргументами, щоб створити
відповідні відсилачі між теками rc?.d та
<literal>/etc/init.d/foo</literal> (де '?' — число від 1 до 6,
що означає рівень запуску System V).
</para>
</listitem>
<listitem>
<para>
Перезавантажити систему.
</para>
</listitem>
</itemizedlist>
<para>
Команда <literal>update-rc.d</literal> створює відсилачі
на сценарії теки <literal>/etc/init.d/</literal> у теці
rc?.d.  Кожен відсилач починається з літери 'S'
або 'K', за якими йде номер та власне назва
сценарію.  Сценарії, що починаються на 'S' з
теки <literal>/etc/rcN.d/</literal> виконуються при
завантаженні рівня запуску <literal>N</literal>; ті,
що починаються на 'K' — при його зупинці.
</para>
<para>
Отож сценарій <literal>foo</literal> можна запустити
при завантаженні системи, помістивши його
в <literal>/etc/init.d/</literal> та встановивши
відсилачі за допомогою команди <literal>update-rc.d
foo defaults 19</literal>.  Аргумент 'defaults' позначає
типові рівні запуску — від 2 до 5.  Аргумент
'19' вказує, що сценарій запуститься перед
будь-яким іншим, котрий починається з
номера 20 або більшого.
</para>
</section>

<section id="interconffiles"><title>Що система керування робить з пакунками, котрі містять конфігураційні файли інших пакунків?</title>
<para>
Хтось з користувачів може захотіти
створити, наприклад, нову службу,
встановивши групу пакунків Debian та
створивши локальний архів, з їх
конфігураційними файлами.  Взагалі-то це не
є хорошою ідеєю, тому що dpkg не знатиме про
конфігураційні файли з такого архіву і
може перезаписати суперечливі
конфігурації при оновленні одного з
пакунків такої групи.
</para>
<para>
Створіть натомість локальний пакунок, що
змінює конфігураційні файли такої групи
пакунків.  Після цього <command>dpkg</command> та інші
системи керування пакунками бачитимуть, що
ці файли були модифіковані локальним
адміністратором та не старатимуться
перезаписувати їх при оновленні.
</para>
</section>

<section id="divert"><title>Як я можу перезаписати файл, встановлений пакунком, так щоб використовувалась інша його версія?</title>
<para>
Припустимо, адміністратор, або локальний
користувач хочуть використовувати
програму login-local замість login, котра
поставляється з пакунком <systemitem
role="package">login</systemitem>.
</para>
<para>
<emphasis role="strong">НЕ</emphasis>:
</para>
<itemizedlist>
<listitem>
<para>
перезаписуйте файл <literal>/bin/login</literal>
програмою <literal>login-local</literal>.
</para>
</listitem>
</itemizedlist>
<para>
Система керування пакунками не знатиме про
цю зміну і просто перезапише ваш
модифікований <literal>/bin/login</literal> при
будь-якому встановленні чи оновленні
пакунку <literal>login</literal> (чи будь-якого іншого,
котрий постачає програму <literal>/bin/login</literal>).
</para>
<para>
Натомість
</para>
<itemizedlist>
<listitem>
<para>
виконайте:
</para>
<screen>
dpkg-divert --divert /bin/login.debian /bin/login
</screen>
<para>
для того, щоб змусити всі наступні
встановлення пакунку <systemitem
role="package">login</systemitem> записувати файл
<literal>/bin/login</literal> у <literal>/bin/login.debian</literal>.
</para>
</listitem>
<listitem>
<para>
після цього запустіть:
</para>
<screen>
cp login-local /bin/login
</screen>
<para>
щоб помістити вашу власну програму на
потрібне місце.
</para>
</listitem>
</itemizedlist>
<para>
За детальнішою інформацією зверніться до
сторінки підручника
<citerefentry><refentrytitle>dpkg-divert</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
</section>

<section id="localpackages"><title>Як мені додати свій пакунок до списку відомих системі керування пакунками?</title>
<para>
Запустіть команду:
</para>
<screen>
dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages
</screen>
<para>
де:
</para>
<itemizedlist>
<listitem>
<para>
BIN-DIR — це тека, в котрій зберігаються файли
архівів Debian (що як правило мають розширення
„.deb“)
</para>
</listitem>
<listitem>
<para>
OVERRIDE_FILE — це файл, що редагується
супроводжуючими збірок та зберігається як
правило на FTP-сайтах архівів Debian як
<literal>indices/override.main.gz</literal> для пакунків зі
збірки main.  Для локальних пакунків ви
можете ігнорувати цю опцію.
</para>
</listitem>
<listitem>
<para>
PATHPREFIX — це <emphasis>необов'язковий</emphasis>
ланцюжок, що може бути доданий до файлу
<literal>my_Packages</literal> при його створенні.
</para>
</listitem>
</itemizedlist>
<para>
Після того, як ви сформуєте файл
<literal>my_Packages</literal>, накажіть системі
керування пакунками використовувати його
за допомогою команди:
</para>
<screen>
dpkg --merge-avail my_Packages
</screen>
<para>
Якщо ви використовуєте АРТ, ви також можете
додати локальне сховище до вашого файлу
<citerefentry><refentrytitle>sources.list</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
</section>

<section id="diverse"><title>Деяким користувачам подобається mawk, іншим gawk; одні користуються vim, інші elvis; дехто уподобав trn, а дехто tin; як Debian підтримує такі різноманітності?</title>
<para>
Є декілька випадків, коли два пакунки
забезпечують дві різні варіації програм,
кожна з котрих володіє однаковою базовою
функціональністю.  Користувачі по якихось
причинах можуть надавати перевагу одній
перед іншою.  В той же час інші користувачі
на тій самій системі можуть мати інші
вподобання.
</para>
<para>
Debian використовує „віртуальну“ систему
пакунків, щоб дозволити адміністраторам
(або дати можливість користувачам) обирати
улюблені інструменти за наявності двох чи
більше програм, котрі пропонують однакову
базову функціональність, підтримуючи при
цьому залежності без вказування
конкретного пакунку.
</para>
<para>
Наприклад, у системі є дві різні версії
програм для читання новин.  Пакунок серверу
новин може рекомендувати
<emphasis>котрусь</emphasis> із них, але кінцевий
вибір між <literal>tin</literal> та <literal>trn</literal>
робить кожен користувач особисто.  Це
забезпечується тим, що обидва ці пакунки
забезпечують віртуальний пакунок <systemitem
role="package">news-reader</systemitem>.  Котру з програм
використовувати вказує відсилач
<literal>/etc/alternatives/news-reader</literal> на вибраний
файл, наприклад <literal>/usr/bin/trn</literal>.
</para>
<para>
Сам по собі відсилач не здатен
підтримувати повноцінне використання
альтернативних програм; зазвичай сторінки
довідки та можливо інші використовувані
файли також повинні підтримуватись.
Сценарій Perl <literal>update-alternatives</literal> дає
можливість переконатись, що всі файли,
пов'язані з певним пакунком, вибрані як
типові для системи.
</para>
<para>
Наприклад, щоб перевірити, які файли
забезпечує x-window-manager, запустіть:
</para>
<screen>
update-alternatives --display x-window-manager
</screen>
<para>
Якщо ви хочете щось змінити, виконайте:
</para>
<screen>
update-alternatives --config x-window-manager
</screen>
<para>
та дотримуйтесь інструкцій на екрані (як
правило, натискайте номер елементу, котрий
вам більше подобається).
</para>
<para>
Якщо з якоїсь причини пакунок не
зареєстрував себе, як віконний менеджер,
або ж ви хочете використовувати менеджер з
теки /usr/local, то екранне меню не буде містити
потрібного вам елементу.  Ви можете оновити
конфігурацію за допомогою опцій
командного рядка, як наприклад:
</para>
<screen>
update-alternatives --install /usr/bin/x-window-manager \
  x-window-manager /usr/local/bin/wmaker-cvs 50
</screen>
<para>
Перший аргумент опції '--install' є символічним
відсилачем, що вказує на /etc/alternatives/ІМ'Я, де
ІМ'Я — другий аргумент.  Третій аргумент —
це програма, на котру повинен вказувати
/etc/alternatives/ІМ'Я, четвертий — пріоритет (чим
більше значення, тим вища ймовірність
автоматичного вибору даної програми).
</para>
<para>
Щоб видалити додану альтернативу, просто
запустіть:
</para>
<screen>
update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs
</screen>
</section>

</chapter>