Kernel kompletnie zmodurazywany i tcpd

[Tomasz Kłoczko]

Moze od drugiego najpierw.

Wyglada na to, że tcpd z BSD nie ma takich kłoporów jak tcpd z
tcp_wrappers więc należałoby zacząć szykować oodejscie od tcp_wrappers.
Do braku zakłuceń jakie opisywał Marcin dochdzi jeszcze to, że tzraymanie
tcpd z tcp_wrappers to bąba zegarowa zwiazana z DoSem jaka siedzi w tej
wersji tcpd (o czym niektórym osobom wiadomo od kilku miesięcy).
Do zrobienia są w tej kwesti następujące rzeczy:

- ustalenie SONAME,
- konwersja hosts.{allow,deny} na hosts.acces %triggerpreun dla
  tcp_wrappers w tcpd

Druga sprawa to zmodurazywany kompletnie kernel. Przedwczoraj z Marcimen
próbowaliśmy troche w tym kierunku i także wspólnie na prędce
przemyśleliśmy niektóre rzeczy. Ja mając jeszcze dodatkowe półtorej dnia
przemyślałem juz chyba reszte szczegułów i wyglada na to, że będziemy
mieli dosć dziwny/ciekawy dystrybucyjny kernel. Opiszę teraz pokrótce co i
jak i w razie czego jeszcze będzie czas na wyjaśnienie niektórych
szczegułów, o ile dla kogoś bezie coś neijasne.

Krótki opis: konfiguracja kernela opiera się o kompletna modularyzację
wszystkiego co się da, a w zasadzie jedyna rzeczą która nie będzie w
module będzie obsługa romfs.

Wykonanie: żeby to zadziałało trzeba przejść na startowanie z kernela
który podpiera się przy starcie za pomocą initrd. W initrd
wpada: statycznei zlinkiowany ash, modprobe, kilka plików z /dev i skrypt
/linuxrc który zawiera sekwencję ładowania modułów przy starcie, które to
moduły są potrzebne do podmontowania root fs.

Po co to: po to żeby uzyskać binarki kernela który prawdopodobnie w ponad
98-99 procentach wszystkich przypadków będzie możliwy do użycia bez
koniecznosci rekompilacji kernela według własnej konfiguracji i
jednocześnie nadal bęzie to kernel optymalny do danych zastosowań.

Sirodki tevchniczne potrzabne do wykonaia powyższego:
w optymalnym wypadku przy instalacji pakietu kernela wygląda na to że da
sie opracować procedurę która na 100% niezawodnie wygeneruje wąłsciwie
initrd pod system na którym będzie pracowałe kernel.

Co jest potrzebne do prawidłowego wygenerowania initrd ?
Ogólnie informacje o root fs. ódła tych informacji to:
- /etc/fstab - typ systemu plikowego root fs i urządzenie które robi za
  rott fs. W tym drugim wypadku mozę to być: dyskietak, dysk ide, jakiś
  nosnik typu fixed (np. zip), dysk scsi.
  Na podstawie pierwszego bedzie można zdecydować czy załadować
  Drugie pozwoli załadować obsługę urządzenia typu scsi host adapter,
  moduły do ide czy inne, a także moduł do katry sieciowe (przy root fs na
  NFS)

- /proc/mdstat - w przypadku kiedy root fs jest na RAID to na podstawie
  wpisu do mdstat mozan sie zorientować jekie moduły muszą być załadowane
  żeby obsłużyć konkretny typ RAID na jakim jest zrobiony root fs.

- /etc/modules.conf - ten plik jest źródłem informacji o nazach modułów
  które bedą potrzebne do załadowania np. eth0 czy SCSI host adaptera.

Podsumowując. W trakcie instalcji pakeitu z kernelem w systemie są
obecnych 100% inforemacji które będą potrzebne do jednoznacznego
wygenerowania initrd.

Stan obecny. Za kilka minut nbeę u siebie robił ostateczne próby z ext2 w
module i z wkompilowanym w kernel tylko romfs. Myślę że się to uda. W tej
chwili mam już taki stan wktóryym obsługę ide mam w modułach.
Jezeli to pójdzie to zostanie tylko dogranie konfiguracji kerneli dla arch
!= i686 i kernele pod powyższe bendą gotowe.

Kolejna sprawa to skrypt do generowanai initrd. Tutaj będzie troche roboty
ale nie za dużo. Na początek w pierwszej wersji powinno wysarczyć dogranie
tego skryptu tak zeby potrafił prawidłowo wygeneroewać initrd pod
ext2/raiser jako systemy plikowe i ide/scsi.
Część zwiazana z SCSI jest juz w zasadzie zerobiona ponieważ mkinitrd z RH
jest tak zroiony, że służy do generowania poprawnie initrrd do scsi .. ale
tylko do tego :) i to co mi zaświtało w głowie to jest pomysł na to jak to
zrobić żeby nie komplikując za mocno całości otrzymać narzędzie
uniwersalne które pozwoli posługiwać się kernelem który rego będzie moąna
używać niemal wszędzie bez żmudnych rekompilacji w tym także i
prawdopodobnie na stacje bezdyskowe.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*