[ powrót ] [ Spis treści ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ dalej ]

Debian GNU/Linux FAQ
Część 10 - Dostosowanie systemu Debian GNU/Linux do Twoich potrzeb

10.1 Skąd mogę mieć pewność, że wszystkie programy używają tego samego rozmiaru papieru?

Zainstaluj pakiet 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 /etc/papersize.

Użytkownicy mogą ustalić własny rozmiar papieru używając zmiennej systemowej PAPERSIZE. Więcej informacji uzyskasz na stronie podręcznika systemowego papersize(5).

10.2 Jak mogę udostępnić urządzenia peryferyjne bez narażania bezpieczeństwa systemu?

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

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:

     adduser użytkownik grupa

W ten sposób nie będziesz musiał zmieniać praw dostępu urządzenia.

10.3 W jaki sposób załadować czcionkę konsoli podczas startu systemu?

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

10.4 W jaki sposób skonfigurować domyślne parametry aplikacji dla środowiska X11?

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

10.5 Wydaje się, że każda dystrybucja posiada inne procedury startu systemu. Jak to wygląda w Debianie?

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

Po zakończeniu procedury startu, init wykonuje wszystkie skrypty startowe z katalogu zależnego od domyślnego poziomu startu (domyślny poziom startu określany jest przez wpis id w pliku /etc/inittab). Jak większość Uniksów zgodnych z System V, Linux ma 7 poziomów startu (runlevels):

0 (zatrzymanie systemu),

1 (tryb pojedynczego użytkownika),

2 do 5 (różne tryby wielodostępowe) i

6 (ponowne uruchomienie systemu).

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 /etc/rc2.d.

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

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

Na przykład, z argumentem `reload', polecenie:

     /etc/init.d/sendmail reload

wyśle sygnał demonowi sendmail'a aby ponownie przeczytał i zinterpretował swój plik konfiguracyjny.

10.6 Wygląda na to że Debian nie używa `rc.local` aby dostosować proces startu systemu. Jakie narzędzia zostały dostarczone do tego celu?

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

Umieścić skrypt foo w katalogu /etc/init.d/.

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

Ponownie uruchomić system.

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

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

10.7 Jak system zarządzania pakietami radzi sobie z pakietami, zawierającymi pliki konfiguracyjne innych pakietów?

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

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

10.8 Jak mogę nadpisać plik instalowany przez inny pakiet tak żeby używana była moja wersja?

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

Nie należy:

Nadpisywać pliku /bin/login plikiem login-local.

System zarządzania pakietami nie będzie wiedział o tej zmianie i po prostu nadpisze Twój plik /bin/login jeśli login (lub każdy inny pakiet dostarczający plik /bin/login) zostanie zainstalowany lub uaktualniony.

Zrób raczej tak:

Wykonaj:
```
     dpkg-divert --divert /bin/login.debian /bin/login
```
aby każde przyszłe instalacje pakietu login zamiast zapisywać plik /bin/login zapisywały go jako /bin/login.debian

Następnie wykonaj:
```
     cp login-local /bin/login
```
aby przenieść Twój lokalnie zbudowany program na właściwe miejsce.

Więcej informacji znajdziesz w dpkg-divert(8).

10.9 W jaki sposób dodać do listy dostępnych pakietów moje lokalnie zbudowane pakiety tak, aby system zarządzania pakietami o nich wiedział?

Wykonaj polecenie:

     dpkg-scanpackages BIN_KAT PLIK_NADP [PRZEDR_SCIEZKI] > moje_Pakiety

gdzie:

BIN_KAT jest katalogiem gdzie przechowywane są pliki archiwów Debiana (zwykle mają rozszerzenia ,,.deb'').

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 indices/override.main.gz. Możesz zignorować ten plik dla lokalnych pakietów.

PRZEDR_SCIEZKI jest opcjonalnym parametrem, którego wartość może zostać dołączona do nazwy tworzonego pliku moje_Pakiety.

Kiedy już plik moje_Pakiety zostanie utworzony powiadom o tym system zarządzania pakietami wykonując polecenie:

     dpkg --merge-avail moje_Pakiety

Jeśli używasz APT to możesz również dodać lokalne repozytorium do swojego pliku sources.list(5).

10.10 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ń?

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.

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.

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

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

Na przykład, aby sprawdzić jakie pliki wykonywalne dostarcza 'x-window-manager' uruchom:

     update-alternatives --display x-window-manager

Jeśli chcesz to zmienić uruchom:

     update-alternatives --config x-window-manager

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

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:

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

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

Aby usunąć alternatywny wpis, który dodałeś uruchom po prostu:

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