<chapt id="customizing">Dostosowanie systemu &debian; do Twoich potrzeb

<sect id="papersize">Skąd mogę mieć pewność, że wszystkie programy używają
  tego samego rozmiaru papieru?

<p>Zainstaluj pakiet <package/libpaperg/. 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 <tt>/etc/papersize</tt>.

<p>Użytkownicy mogą ustalić własny rozmiar papieru używając zmiennej 
systemowej <tt>PAPERSIZE</tt>. Więcej informacji uzyskasz na stronie
podręcznika systemowego
<manref name="papersize" section="5">.

<sect id="hardwareaccess">Jak mogę udostępnić urządzenia peryferyjne bez
  narażania bezpieczeństwa systemu?

<p>Wiele plików urządzeń w katalogu <tt>/dev/</tt> należy do pewnych, wcześniej
zdefiniowanych, grup. Na przykład <tt>/dev/fd0</tt> należy do grupy
<tt>floppy</tt>, a <tt>/dev/dsp</tt> należy do grupy <tt>audio</tt>.

<p>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:
  <example>adduser użytkownik grupa</example>
W ten sposób nie będziesz musiał zmieniać praw dostępu urządzenia.

<sect id="consolefont">W jaki sposób załadować czcionkę konsoli podczas startu
  systemu?

<p>Pakiety <package/kbd/ oraz <package/console-tools/ pozwalają to osiągnąć.
  Dostosuj odpowiednio do swoich potrzeb plik <tt>/etc/kbd/config</tt> lub
  <tt>/etc/console-tools/config</tt>.

<sect id="appdefaults">W jaki sposób skonfigurować domyślne parametry
 aplikacji dla środowiska X11?

<p>Programy Debiana pod X'y instalują swoje zasoby do katalogu
<tt>/etc/X11/app-defaults/</tt>. 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.

<sect id="booting">Wydaje się, że każda dystrybucja posiada inne procedury 
  startu systemu.  Jak to wygląda w Debianie?

<p>Jak wszystkie Uniksy, Debian startuje uruchamiając program <tt>init</tt>.
Plik konfiguracyjny dla <tt>init</tt> (tj. <tt>/etc/inittab</tt>) określa, że
pierwszym wykonywanym skryptem powinien być <tt>/etc/init.d/rcS</tt>. Skrypt
ten uruchamia wszystkie skrypty z katalogu <tt>/etc/rcS.d/</tt> 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 <tt>/etc/rc.boot/</tt>.
Wszystkie skrypty w tym katalogu są zazwyczaj zarezerwowane do użytku
administratora systemu. Używanie ich jest przestarzałą praktyką.

<p>Po zakończeniu procedury startu, <tt>init</tt> wykonuje wszystkie skrypty 
startowe z katalogu zależnego od domyślnego poziomu startu (domyślny poziom startu 
określany jest przez wpis <tt>id</tt> w pliku <tt>/etc/inittab</tt>). Jak większość
Uniksów zgodnych z System V, Linux ma 7 poziomów startu (runlevels):
<list>
  <item>0 (zatrzymanie systemu),
  <item>1 (tryb pojedynczego użytkownika),
  <item>2 do 5 (różne tryby wielodostępowe) i
  <item>6 (ponowne uruchomienie systemu).
</list>
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 <tt>/etc/rc2.d</tt>.

<p>Tak naprawdę skrypty, w każdym z katalogów <tt>/etc/rcN.d/</tt>, są tylko
symbolicznymi dowiązaniami do skryptów z
<tt>/etc/init.d</tt>. Jednak <em>nazwy</em> plików, z katalogów
<tt>/etc/rcN.d/</tt>, są tak nadane aby pokazać <em>sposób</em> w jaki skrypty z
<tt>/etc/init.d/</tt> 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.

<p>To podejście działa, ponieważ wszystkie skrypty z <tt>/etc/init.d/</tt>
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.

<p>Na przykład, z argumentem `reload', polecenie:
  <example>/etc/init.d/sendmail reload</example>
wyśle sygnał demonowi sendmail'a aby ponownie przeczytał i zinterpretował 
swój plik konfiguracyjny.

<sect id="custombootscripts">Wygląda na to że Debian nie używa
<tt>rc.local</tt> aby dostosować proces startu systemu. Jakie narzędzia
zostały dostarczone do tego celu?

<p>Przypuśćmy, że system ma uruchomić skrypt <tt>foo</tt> podczas startu
systemu lub podczas przejścia w dany poziom startu (runlevel). W takiej
sytuacji administrator systemu powinien:

<list>
  <item>Umieścić skrypt <tt>foo</tt> w katalogu <tt>/etc/init.d/</tt>.
  <item>Uruchomić polecenie Debiana <tt>update-rc.d</tt> z odpowiednimi
  parametrami w celu ustanowienia dowiązań pomiędzy (określonymi w linii
  poleceń)
  katalogami rc?.d, a <tt>/etc/init.d/foo</tt>. W tym przypadku '?' jest cyfrą
  od 0 do 6 i oznacza odpowiedni poziom startu Systemu V. 
  <item>Ponownie uruchomić system.
</list>

<p>Polecenie <tt>update-rc.d</tt> ustanowi dowiązania w
katalogach rc?.d ze skryptem w <tt>/etc/init.d</tt>.
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
<tt>/etc/rcN.d/</tt> zostaną wykonane przy przejściu do poziomu startu
<tt>N</tt>. Skrypty zaczynające się literą 'K' zostaną wykonane przy wyjściu z
poziomu startu <tt>N</tt>.

<p>Można, na przykład, sprawić by skrypt <tt>foo</tt> wykonał się podczas startu
systemu poprzez umieszczenie go w katalogu <tt>/etc/init.d/</tt> oraz
utworzenie dowiązań przy pomocy polecenia <tt>update-rc.d foo defaults 19</tt>. 
Parametr 'defaults' oznacza domyślne poziomy startu tzn. od 2 do 5.
Parametr '19' daje pewność, że <tt>foo</tt> zostanie uruchomiony wcześniej niż
skrypty o numerach 20 i wyższych.

<sect id="interconffiles">Jak system zarządzania pakietami radzi sobie z
pakietami, zawierającymi pliki konfiguracyjne innych pakietów?

<p>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 <prgn/dpkg/ 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.

<p>Zamiast tego utwórz lokalny pakiet, który modyfikuje pliki konfiguracyjne
,,grupy'' pakietów Debiana, które Cię interesują. Wtedy <prgn/dpkg/ 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.

<!-- check against dpkg-divert description -->
<sect id="divert">Jak mogę nadpisać plik instalowany przez inny pakiet tak
  żeby używana była moja wersja?

<p>Powiedzmy, że administrator lub lokalny użytkownik woli używać programu
,,login-local'' niż ,,login'', który dostarczany jest przez pakiet Debiana o
nazwie <package/login/ .

<p>Nie należy:
  <list>
    <item> Nadpisywać pliku <tt>/bin/login</tt> plikiem <tt>login-local</tt>.
  </list>
System zarządzania pakietami nie będzie wiedział o tej zmianie i po prostu
nadpisze Twój plik <tt>/bin/login</tt> jeśli <tt>login</tt> (lub każdy
inny pakiet dostarczający plik <tt>/bin/login</tt>) zostanie zainstalowany 
lub uaktualniony.
<!-- XXX dpkg-divert: is this correct ? -->
<p>Zrób raczej tak:
<list>
  <item>Wykonaj:
    <example>dpkg-divert --divert /bin/login.debian /bin/login</example>
  aby każde przyszłe instalacje pakietu <package/login/ zamiast
  zapisywać plik <tt>/bin/login</tt> zapisywały go jako <tt>/bin/login.debian</tt>
  <item>Następnie wykonaj:
    <example>cp login-local /bin/login</example>
  aby przenieść Twój lokalnie zbudowany program na właściwe miejsce.
</list>

<p>Więcej informacji znajdziesz w <manref name="dpkg-divert" section="8">.


<sect id="localpackages">W jaki sposób dodać do listy dostępnych pakietów
moje lokalnie zbudowane pakiety tak, aby system zarządzania pakietami o 
nich wiedział?

<p>Wykonaj polecenie:

<example>
dpkg-scanpackages BIN_KAT PLIK_NADP [PRZEDR_SCIEZKI] > moje_Pakiety
</example>

<p>gdzie:
  <list>
    <item>BIN_KAT jest katalogiem gdzie przechowywane są pliki archiwów
    Debiana (zwykle mają rozszerzenia ,,.deb'').
    <item>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
    <tt>indices/override.main.gz</tt>.
    Możesz zignorować ten plik dla lokalnych pakietów.
    <item>PRZEDR_SCIEZKI jest <em>opcjonalnym</em> parametrem, którego wartość 
    może zostać dołączona do nazwy tworzonego pliku <tt>moje_Pakiety</tt>.
  </list>

<p>Kiedy już plik <tt>moje_Pakiety</tt> zostanie utworzony powiadom o tym
system zarządzania pakietami wykonując polecenie:

<example>
dpkg --merge-avail moje_Pakiety
</example>

<p>Jeśli używasz APT to możesz również dodać lokalne repozytorium do swojego pliku 
<manref name="sources.list" section="5">.

<sect id="diverse">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ń?

<p>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.

<p>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.

<p>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 <em>jakiś</em> czytnik grup dyskusyjnych ale wybór
<tt>tin</tt>'a lub <tt>trn</tt>'a pozostawiony zostaje użytkownikowi. Działa
to w ten sposób, że oba pakiety <package/tin/ oraz <package/trn/
dostarczają wirtualny pakiet <package/news-reader/. <em>Który</em> program
zostanie wywołany zależy od dowiązania pliku z nazwą wirtualnego
pakietu <tt>/etc/alternatives/news-reader</tt> do wybranego pliku czytnika np.
<tt>/usr/bin/trn</tt>.

<p>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
<tt>update-alternatives</tt> dostarcza sposobu, który zapewnia, że wszystkie
pliki powiązane z danym pakietem zostaną wybrane jako domyślne dla systemu.

<p>Na przykład, aby sprawdzić jakie pliki wykonywalne dostarcza
'x-window-manager' uruchom:
  <example>update-alternatives --display x-window-manager</example>
Jeśli chcesz to zmienić uruchom:
  <example>update-alternatives --config x-window-manager</example>
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).
 
<p>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:
  <example>update-alternatives --install /usr/bin/x-window-manager \
  x-window-manager /usr/local/bin/wmaker-cvs 50</example>

<p>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).

<p>Aby usunąć alternatywny wpis, który dodałeś uruchom po prostu:
  <example>update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs</example>
