<?xml version='1.0' encoding='utf-8'?>
<!-- -*- DocBook -*- -->
<chapter id="customizing"><title>Dostosowanie systemu Debian GNU/Linux do Twoich potrzeb</title>
<section id="papersize"><title>Skąd mogę mieć pewność, że wszystkie programy używają tego samego rozmiaru papieru?</title>
<para>
Zainstaluj pakiet <systemitem role="package">libpaperg</systemitem>.  Podczas
instalacji zostaniesz zapytany o domyślny rozmiar papieru, który ma być
używany w całym systemie.  Ustawienie to będzie przechowywane w pliku
<literal>/etc/papersize</literal>.
</para>
<para>
Użytkownicy mogą ustalić własny rozmiar papieru używając zmiennej
systemowej <literal>PAPERSIZE</literal>.  Więcej informacji uzyskasz na
stronie podręcznika systemowego
<citerefentry><refentrytitle>papersize</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
</section>

<section id="hardwareaccess"><title>Jak mogę udostępnić urządzenia peryferyjne bez narażania bezpieczeństwa systemu?</title>
<para>
Wiele plików urządzeń w katalogu <literal>/dev/</literal> należy do
pewnych, wcześniej zdefiniowanych, grup.  Na przykład
<literal>/dev/fd0</literal> należy do grupy <literal>floppy</literal>, a
<literal>/dev/dsp</literal> należy do grupy <literal>audio</literal>.
</para>
<para>
Jeśli chcesz żeby dany użytkownik miał dostęp do jednego z tych urządzeń
to po prostu dodaj go do grupy, do której należy to urządzenie.  Możesz to
zrobić na przykład tak:
</para>
<screen>
adduser użytkownik grupa
</screen>
<para>
W ten sposób nie będziesz musiał zmieniać praw dostępu urządzenia.
</para>
</section>

<section id="consolefont"><title>W jaki sposób załadować czcionkę konsoli podczas startu systemu?</title>
<para>
Pakiety <systemitem role="package">kbd</systemitem> oraz <systemitem
role="package">console-tools</systemitem> pozwalają to osiągnąć.  Dostosuj
odpowiednio do swoich potrzeb plik <literal>/etc/kbd/config</literal> lub
<literal>/etc/console-tools/config</literal>.
</para>
</section>

<section id="appdefaults"><title>W jaki sposób skonfigurować domyślne parametry aplikacji dla środowiska X11?</title>
<para>
Programy Debiana pod X'y instalują swoje zasoby do katalogu
<literal>/etc/X11/app-defaults/</literal>.  Jeśli chcesz dostosować aplikacje
X'ów globalnie to dokonaj zmiany w tych plikach.  Oznaczone są one jako
konfiguracyjne więc ich zawartość pozostanie niezmieniona podczas procesu
aktualizacji.
</para>
</section>

<section id="booting"><title>Wydaje się, że każda dystrybucja posiada inne procedury startu systemu. Jak to wygląda w Debianie?</title>
<para>
Jak wszystkie Uniksy, Debian startuje uruchamiając program
<literal>init</literal>.  Plik konfiguracyjny dla <literal>init</literal> (tj.
<literal>/etc/inittab</literal>) określa, że pierwszym wykonywanym skryptem
powinien być <literal>/etc/init.d/rcS</literal>.  Skrypt ten uruchamia
wszystkie skrypty z katalogu <literal>/etc/rcS.d/</literal> poprzez
bezpośrednie interpretowanie lub uruchamianie podprocesów interpretujących
(zależnie od rozszerzeń plików) w celu dokonania inicjalizacji, takiej jak:
sprawdzenie oraz zamontowanie systemów plików, załadowanie modułów,
uruchomienie usług sieciowych, ustawienie zegara i innych.  W dalszej
kolejności, w celu utrzymania zgodności ze starszymi wersjami, uruchamia
również skrypty (oprócz tych ze znakiem '.'  w nazwach) z katalogu
<literal>/etc/rc.boot/</literal>.  Wszystkie skrypty w tym katalogu są
zazwyczaj zarezerwowane do użytku administratora systemu.  Używanie ich jest
przestarzałą praktyką.
</para>
<para>
Po zakończeniu procedury startu, <literal>init</literal> wykonuje wszystkie
skrypty startowe z katalogu zależnego od domyślnego poziomu startu (domyślny
poziom startu określany jest przez wpis <literal>id</literal> w pliku
<literal>/etc/inittab</literal>).  Jak większość Uniksów zgodnych z System
V, Linux ma 7 poziomów startu (runlevels):
</para>
<itemizedlist>
<listitem>
<para>
0 (zatrzymanie systemu),
</para>
</listitem>
<listitem>
<para>
1 (tryb pojedynczego użytkownika),
</para>
</listitem>
<listitem>
<para>
2 do 5 (różne tryby wielodostępowe) i
</para>
</listitem>
<listitem>
<para>
6 (ponowne uruchomienie systemu).
</para>
</listitem>
</itemizedlist>
<para>
Systemy oparte na Debianie posiadają domyślny wpis id=2 co oznacza, że w
momencie wejścia w stan pracy wielodostępowej, domyślnym poziomem startu
będzie '2' oraz, że zostaną uruchomione skrypty z katalogu
<literal>/etc/rc2.d</literal>.
</para>
<para>
Tak naprawdę skrypty, w każdym z katalogów <literal>/etc/rcN.d/</literal>,
są tylko symbolicznymi dowiązaniami do skryptów z
<literal>/etc/init.d</literal>.  Jednak <emphasis>nazwy</emphasis> plików, z
katalogów <literal>/etc/rcN.d/</literal>, są tak nadane aby pokazać
<emphasis>sposób</emphasis> w jaki skrypty z <literal>/etc/init.d/</literal>
będą uruchamiane.  Przed wejściem do dowolnego poziomu startu wszystkie
skrypty zaczynające się literą 'K' zostaną uruchomione.  Te skrypty
usuwają usługi.  Następnie wykonane zostaną wszystkie skrypty zaczynające
się literą 'S'.  Te skrypty uruchamiają usługi.  Dwucyfrowa liczba, która
występuje po 'K' lub 'S' oznacza kolejność, w jakiej uruchamiają się
skrypty.  Mniejsza liczba oznacza, że skrypt uruchomi się wcześniej.
</para>
<para>
To podejście działa, ponieważ wszystkie skrypty z
<literal>/etc/init.d/</literal> pobierają jeden z argumentów: `start',
`stop', `reload', `restart' lub `force-reload' i wykonają zadanie określone
przez ten argument.  Skrypty te mogą być używane nawet po zakończeniu
rozruchu systemu w celu kontroli różnych procesów.
</para>
<para>
Na przykład, z argumentem `reload', polecenie:
</para>
<screen>
/etc/init.d/sendmail reload
</screen>
<para>
wyśle sygnał demonowi sendmail'a aby ponownie przeczytał i zinterpretował
swój plik konfiguracyjny.
</para>
</section>

<section id="custombootscripts"><title>Wygląda na to że Debian nie używa <literal>rc.local</literal> aby dostosować proces startu systemu. Jakie narzędzia zostały dostarczone do tego celu?</title>
<para>
Przypuśćmy, że system ma uruchomić skrypt <literal>foo</literal> podczas
startu systemu lub podczas przejścia w dany poziom startu (runlevel).  W
takiej sytuacji administrator systemu powinien:
</para>
<itemizedlist>
<listitem>
<para>
Umieścić skrypt <literal>foo</literal> w katalogu
<literal>/etc/init.d/</literal>.
</para>
</listitem>
<listitem>
<para>
Uruchomić polecenie Debiana <literal>update-rc.d</literal> z odpowiednimi
parametrami w celu ustanowienia dowiązań pomiędzy (określonymi w linii
poleceń) katalogami rc?.d, a <literal>/etc/init.d/foo</literal>.  W tym
przypadku '?'  jest cyfrą od 0 do 6 i oznacza odpowiedni poziom startu Systemu
V.
</para>
</listitem>
<listitem>
<para>
Ponownie uruchomić system.
</para>
</listitem>
</itemizedlist>
<para>
Polecenie <literal>update-rc.d</literal> ustanowi dowiązania w katalogach
rc?.d ze skryptem w <literal>/etc/init.d</literal>.  Każde dowiązanie
składać się będzie, w kolejności: z litery 'S' lub 'K', dwucyfrowej liczby
oraz nazwy skryptu.  Skrypty zaczynające się literą 'S' w
<literal>/etc/rcN.d/</literal> zostaną wykonane przy przejściu do poziomu
startu <literal>N</literal>.  Skrypty zaczynające się literą 'K' zostaną
wykonane przy wyjściu z poziomu startu <literal>N</literal>.
</para>
<para>
Można, na przykład, sprawić by skrypt <literal>foo</literal> wykonał się
podczas startu systemu poprzez umieszczenie go w katalogu
<literal>/etc/init.d/</literal> oraz utworzenie dowiązań przy pomocy
polecenia <literal>update-rc.d foo defaults 19</literal>.  Parametr 'defaults'
oznacza domyślne poziomy startu tzn.  od 2 do 5.  Parametr '19' daje
pewność, że <literal>foo</literal> zostanie uruchomiony wcześniej niż
skrypty o numerach 20 i wyższych.
</para>
</section>

<section id="interconffiles"><title>Jak system zarządzania pakietami radzi sobie z pakietami, zawierającymi pliki konfiguracyjne innych pakietów?</title>
<para>
Niektórzy użytkownicy chcieliby, na przykład, stworzyć nowy serwer
instalując grupę pakietów Debiana i lokalnie wygenerowane pakiety
zawierające pliki konfiguracyjne.  Zazwyczaj nie jest to dobry pomysł
ponieważ program <command>dpkg</command> nie będzie wiedział o istnieniu
plików konfiguracyjnych jeśli znajdują się one w innych pakietach.  Może
to doprowadzić do nadpisania konfliktowych plików gdy jeden z pakietów
oryginalnej ,,grupy'' zostanie uaktualniony.
</para>
<para>
Zamiast tego utwórz lokalny pakiet, który modyfikuje pliki konfiguracyjne
,,grupy'' pakietów Debiana, które Cię interesują.  Wtedy
<command>dpkg</command> i reszta systemu zarządzania pakietami będzie
wiedział, że pliki zostały zmodyfikowane przez lokalnego administratora i
nie będzie próbował ich nadpisać w czasie aktualizacji.
</para>
</section>

<section id="divert"><title>Jak mogę nadpisać plik instalowany przez inny pakiet tak żeby używana była moja wersja?</title>
<para>
Powiedzmy, że administrator lub lokalny użytkownik woli używać programu
,,login-local'' niż ,,login'', który dostarczany jest przez pakiet Debiana o
nazwie <systemitem role="package">login</systemitem> .
</para>
<para>
Nie należy:
</para>
<itemizedlist>
<listitem>
<para>
Nadpisywać pliku <literal>/bin/login</literal> plikiem
<literal>login-local</literal>.
</para>
</listitem>
</itemizedlist>
<para>
System zarządzania pakietami nie będzie wiedział o tej zmianie i po prostu
nadpisze Twój plik <literal>/bin/login</literal> jeśli
<literal>login</literal> (lub każdy inny pakiet dostarczający plik
<literal>/bin/login</literal>) zostanie zainstalowany lub uaktualniony.
</para>
<para>
Zrób raczej tak:
</para>
<itemizedlist>
<listitem>
<para>
Wykonaj:
</para>
<screen>
dpkg-divert --divert /bin/login.debian /bin/login
</screen>
<para>
aby każde przyszłe instalacje pakietu <systemitem
role="package">login</systemitem> zamiast zapisywać plik
<literal>/bin/login</literal> zapisywały go jako
<literal>/bin/login.debian</literal>
</para>
</listitem>
<listitem>
<para>
Następnie wykonaj:
</para>
<screen>
cp login-local /bin/login
</screen>
<para>
aby przenieść Twój lokalnie zbudowany program na właściwe miejsce.
</para>
</listitem>
</itemizedlist>
<para>
Więcej informacji znajdziesz w
<citerefentry><refentrytitle>dpkg-divert</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
</section>

<section id="localpackages"><title>W jaki sposób dodać do listy dostępnych pakietów moje lokalnie zbudowane pakiety tak, aby system zarządzania pakietami o nich wiedział?</title>
<para>
Wykonaj polecenie:
</para>
<screen>
dpkg-scanpackages BIN_KAT PLIK_NADP [PRZEDR_SCIEZKI] > moje_Pakiety
</screen>
<para>
gdzie:
</para>
<itemizedlist>
<listitem>
<para>
BIN_KAT jest katalogiem gdzie przechowywane są pliki archiwów Debiana (zwykle
mają rozszerzenia ,,.deb'').
</para>
</listitem>
<listitem>
<para>
PLIK_NADP (ang.  override file) jest plikiem, który modyfikowany jest przez
opiekunów wydania i, dla pakietów z dystrybucji main, zwykle znajduje się w
archiwum FTP Debiana jako <literal>indices/override.main.gz</literal>.  Możesz
zignorować ten plik dla lokalnych pakietów.
</para>
</listitem>
<listitem>
<para>
PRZEDR_SCIEZKI jest <emphasis>opcjonalnym</emphasis> parametrem, którego
wartość może zostać dołączona do nazwy tworzonego pliku
<literal>moje_Pakiety</literal>.
</para>
</listitem>
</itemizedlist>
<para>
Kiedy już plik <literal>moje_Pakiety</literal> zostanie utworzony powiadom o
tym system zarządzania pakietami wykonując polecenie:
</para>
<screen>
dpkg --merge-avail moje_Pakiety
</screen>
<para>
Jeśli używasz APT to możesz również dodać lokalne repozytorium do swojego
pliku
<citerefentry><refentrytitle>sources.list</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
</section>

<section id="diverse"><title>Niektórzy użytkownicy lubią mawk, inni gawk; jedni lubią vim'a, inni lubią elvis'a; niektórzy lubią trn, inni lubią tin. Jak Debian wspiera taką różnorodność upodobań?</title>
<para>
Istnieje wiele przypadków kiedy dwa pakiety dostarczają dwie różne wersje
programu o takiej samej funkcjonalności.  Użytkownicy mogą preferować jeden
z nich bardziej od drugiego z przyzwyczajenia, lub z powodu interfejsu
użytkownika, który dla danego pakietu jest, w jakiś sposób, bardziej
przyjazny niż interfejs drugiego.  Różni użytkownicy w tym samym systemie
mogą dokonać różnych wyborów.
</para>
<para>
Debian używa systemu pakietów ,,wirtualnych'' aby pozwolić administratorom
systemu na wybór (lub pozwolić wybrać użytkownikom) ulubione narzędzia,
gdy istnieją dwie lub więcej wersji z taką samą podstawową
funkcjonalnością, która zaspokoi wymagania zależności bez podawania nazwy
konkretnego pakietu.
</para>
<para>
Na przykład: w systemie zainstalowane są dwie różne wersje czytników grup
dyskusyjnych.  Serwer grup dyskusyjnych może 'zalecać' aby w systemie był
zainstalowany <emphasis>jakiś</emphasis> czytnik grup dyskusyjnych ale wybór
<literal>tin</literal>'a lub <literal>trn</literal>'a pozostawiony zostaje
użytkownikowi.  Działa to w ten sposób, że oba pakiety <systemitem
role="package">tin</systemitem> oraz <systemitem
role="package">trn</systemitem> dostarczają wirtualny pakiet <systemitem
role="package">news-reader</systemitem>.  <emphasis>Który</emphasis> program
zostanie wywołany zależy od dowiązania pliku z nazwą wirtualnego pakietu
<literal>/etc/alternatives/news-reader</literal> do wybranego pliku czytnika
np.  <literal>/usr/bin/trn</literal>.
</para>
<para>
Pojedyncze dowiązanie nie wystarcza aby wspierać pełne użycie
alternatywnych programów.  Strony pomocy i prawdopodobnie inne, powiązane z
programem, pliki muszą także zostać wybrane.  Skrypt Perl'a
<literal>update-alternatives</literal> dostarcza sposobu, który zapewnia, że
wszystkie pliki powiązane z danym pakietem zostaną wybrane jako domyślne dla
systemu.
</para>
<para>
Na przykład, aby sprawdzić jakie pliki wykonywalne dostarcza
'x-window-manager' uruchom:
</para>
<screen>
update-alternatives --display x-window-manager
</screen>
<para>
Jeśli chcesz to zmienić uruchom:
</para>
<screen>
update-alternatives --config x-window-manager
</screen>
<para>
i wykonaj instrukcje, które pojawią się na ekranie (po prostu naciśnij
klawisz z cyfrą, która znajduje się przy programie, który bardziej lubisz).
</para>
<para>
Jeśli z jakiegoś powodu pakiet nie zarejestruje się jako menedżer okien
(wyślij informacje o błędzie jeśli uznasz to za usterkę) lub jeśli
używasz menedżera okien z katalogu /usr/local (taki wybór nie pojawi się na
ekranie), możesz uaktualnić dowiązania poprzez parametry wywołania tak jak
na przykładzie poniżej:
</para>
<screen>
update-alternatives --install /usr/bin/x-window-manager \
  x-window-manager /usr/local/bin/wmaker-cvs 50
</screen>
<para>
Pierwszy parametr za `--install' jest dowiązaniem symbolicznym, które
wskazuje na /etc/alternatives/NAZWA, gdzie NAZWA jest drugim parametrem.
Trzeci parametr to program, do którego /etc/alternatives/NAZWA powinien
zostać dowiązany, a czwarty jest priorytetem (większe wartości wskazują,
że ta alternatywa, przy działaniu automatycznym, będzie wybrana z większym
prawdopodobieństwem).
</para>
<para>
Aby usunąć alternatywny wpis, który dodałeś uruchom po prostu:
</para>
<screen>
update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs
</screen>
</section>

</chapter>