Biuletym PLD nr 9
Tomasz Kłoczko
kloczek w rudy.mif.pg.gda.pl
Wto, 22 Wrz 1998, 06:14:00 CEST
-- Tryb zgłaszania materiałów --------------
--------------------------------------------
Jest jedna zaległa rzecz do poruszenia.
Otóż chodzi o sposób zgłaszania materiałów i poprawek do tychże.
Chodzi oto, żeby same spece, które pojawiają się na liście wysyłać jako
attachment do listów. Po co ? Chodzi o to, że ja czy Wojtek jako
odbierający całość (a także inni) mogą wtedy automatycznie wychwytywać
takie materiały filtrując takie rzeczy przez procmaila. Druga sprawa to
jest kwestia zgłaszania poprawek do speców czy innych materiałów. Chodzi o
to żeby zgłaszać to w postaci diffa (najlepiej unifited) i o ile taka
poprawka jest dłuzszy niż powiedzmy 40 linijek, to żeby to też przekazywać
przez attachment.
Jak wygenerować diffa:
$ diff -u <orginał> <plik_z_poprawkami> > <plik>.{diff|patch}
Jeżeli będą to diffy to same zmiany i ich umiejscowienie będzie łatwiej
wypakowywać i przenosić do włąściwych zasobów.
-- Koncik speca ----------------------------
--------------------------------------------
** Pusta linia ****************************
Nie wiem ilu z was ma jakieś dłuższe doświadczeni w pisani źródeł
jakichkolwiek programów w różnych językach. Generalnie odnoszę wrażenie,
że w tych materiałach jakie do mnie docierają bezśrednio czy tym co jest
robione w devel osoby to preparujące boją się pustych linii lub nie zdają
sobie znaczenia z tego co one wprowadzaj. Przykład z Grześkowego
radius.spec. Orginał:
------------------
%install
rm -rf $RPM_BUILD_ROOT
make install-all BUILD_ROOT=$RPM_BUILD_ROOT
strip $RPM_BUILD_ROOT/usr/{sbin/*,bin/*}
mkdir -p $RPM_BUILD_ROOT/etc/rc.d/init.d
cp ./redhat/radiusd $RPM_BUILD_ROOT/etc/rc.d/init.d/
------------------
i wersja nieco zmodyfikowana:
------------------
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/etc/rc.d/init.d
make install-all BUILD_ROOT=$RPM_BUILD_ROOT
cp ./redhat/radiusd $RPM_BUILD_ROOT/etc/rc.d/init.d/
strip $RPM_BUILD_ROOT/usr/{sbin/*,bin/*}
------------------
Raz, że wprowadziłem tu pewien układ logiczny, który zachowany jest we
wszystkich innych specach:
- "rm -rf $RPM_BUILD_ROOT"
- tworzenie drzewka katalogów
- rozrzucenie wszsystkiego po drzewku katalogów,
- striping binarek i inne kosmetyczne rzeczy jak pakowanie plików info,
korekty rozmieszczenia binarek, korekty linków itp.
Dodatkowo wprowadzone zostały dwie puste linie odzielające poszczególne
części tego co się dzieje w %install.
Czemu to ma służyć ? Po pierwsze lepsza przejrzystoś. Po drugie
przyzwyczja do pewnego porządku czynności jakie powinny być wykonywane w
np. %install, co przy robieniu większych ilości speców pomaga
minimalizować błędy. Taki spec o ile ma pewien logiczny układ do którego
się przyzwyczai, to jeżeli będzie posiadał jakieś niedoróbki lub
pominięcia pewnych czynności to często wystarczy rzut oka na tekst żeby
wychwycić błędy pewnej klasy.
Także prosiłby coby nie bać się pustych linii ale też i z nimi nie
przesadzać ;)
** %verifyscripts, %post{un}, %pre(un} ***
Kolejna część omówienia nie omawianych przezemnie dotąd elementów speca
które mogą znacznie wzbogacić funkcjonalność pakietu i jego automatyzm
funkcjonowania jako zainstalowane zasoby w systemie czyli skrypty. Jest
ich sześć rodzajów niemniej pomin tu %triggerscripts zostawiając to na
inny odcinek czyli mamy tu:
%post - skrypt post instalacyjny
%postun - skrypt post deinstalacyjny
%pre - skrypt pre instalacyjny
%preun - skrypt pre deinstalacyjny
%verifyscript - skrypt weryfikujący
Do czego to tak naprawdę jest potrzebne ? Otóż czasami zachodzi potrzeba
wykonania czegoś dodatkowo coś co będzie wykraczało po za proste
rozrzucenie plików po katalogach i nadanie im odpowioedznich uprawnień.
Czasmi też przydałoby się wzbogacić nieco procedurę weryfikacji pakietu
lub też dobrze by było próbować wykonywać pewne czynnoŚci korygujące w
zasobach systemowych. Do tego wszystkiego mają służyć powyższe sekcje w
specu opisujące czynności jakie by trzeba było wykonywać podczas
powyższych operacji w postaci skryptu.
Standardowym interpreterem tych skryptów jest /bin/sh (dlatego w globalnym
rpmrc jest "Require: /bin/sh") niemniej w bardzo prosty sposób można to
zmienić na dowolny inny interpreter poprzez dodanie
"-p </program/interpretera>" jako parametr. taka konstrukcja ma tą zaletę,
że sam </program/interpretera> jest automatycznie dodawany do listy Prereq
pakietu. Czyli jego obecnoś będzie wymagana już przed instalacją samego
pakietu, który zawiera jakąś sekcję z paramerem
"-p </program/interpretera>"
Typowo w sekcjach %post, %postun w przypadku pakietów zawierających
biblioteki współdzielone wywołuje się /sbin/ldconfig w celu przebudowania
/etc/ld.so.cache po dodaniu lub usunięciu biblioteki z zasobów
systemowych. Sam ldconfig zresztą przy okazji tworzy odpowiednie linki
typu lib<SONAME> w poszczególnych katalogach zawierających owe biblioteki.
Żeby nie trzeba było dodawać do nagłowków posdzczególnych pakietów
"Prereq: /sbin/ldconfig" lepiej jest umieścić bezpośrednio /sbin/ldconfig
jako interpreter pustego skryptu w %post/%postun.
Inną często spotykaną operacj po instalacji i przed deinstalacją pakietów
devel jest rejestracja stron info w bazie info w /usr/info/dir.
Tutaj akurat powinno się używać nie %post/%postun tylko %post/%preun.
Innymi zastosowaniami %post{un}, %pre(un} może być szeroko roumiane
automatyczne dostosowywanie konfiguracji innych pakietów czy samego
właśnie instalowanego pakietu.
Na %verifyscripts typowo zaleca sie wykonywanie korekt atrybutów plików o
ile ma sie do czynienie z sytuacją kiedy coś w trakcie eksploaccji systemu
się w jakiś sposób sie zmienia. NA samym %verifyscript możnaby też zrobić
tymczasowo przebudowywanie bazy fontów pzrez wołania mkfonntdir w pakiecie
zawierającym fonty iso-2. Niemniej to bedzie tylko tmczasowe gdyż docelowo
pakiety z XFree86 nie powinny instalować włąsnej bazy w plikach fonts.* a
powinny je poprostu też generować w %post/%postun i o ile same bazy po
deinstalacji będą już pusdte powinny usuwać same pliki fonts.* i puste
katalogi które zawierały fonty.
Wszystkie skrypty mogą zwócić kod błędu. W przypadku %cverifyscript
zostanie wypisamny tylko komunikat, że weryfikacja nie przebiegła
prawidłowo, a przy innych skryptach będzie to stopować procez
instalacji/deinstalacji. W ten sposób np. pakiet z kernelem i modułami
"broni" się przed odinstalowaniem jęzli pracuje się na kernwlu którego
moduły są własnie eksploatowane (sprawdzenie "uname -r" w %pre).
Można pominąć wykonuwanie skryptów przy instalacji, upgrade czy
weryfikacji pakietu(ów) poprzez dodanie --noscripts co umożliwia
odinstalownie po mimo ostrzeżeń bierzących modułów. Niemniej o ile
takowych modułów i kernela nie zainstaluje się pzred ponownym restartem to
mogą być niejakie kłopoty z podniesieniem systemu o ile nie mamy modułow i
kernela z innej jeszcze wersji :)
** Pole Obsoletes *************************
Były wątpliwości co do pola Obsoletes. Otóż pole to zawira listę nazw
pakietów jakie powinny być wyinstalowane przed wykonaniem jeszcze %pre.
Jeżeli operacja usunięcia wymienionych pakietów nie powiedzie się bo np.
są one potrzebne jeszcze dla innchy pakietów to cała operacja jest
wstrzymywana i instalacja pakietu, który próbuje jednocześnie usuwać inne
pakiety kończy się neipowodzenie.
Gdzie to może być przydatne ? Otóż czasami zdaża się, ze pakiet zmienia
swoja nazwę i o ile chcemy żeby nowa wersja pakietu pod nową
nazwą zaisnatalowała się poprawnie, to powinniśmy zadbac o to żeby usunąć
pakiet z poprzedniej wersji, który występował pod nieco inną nazwą.
Innym zastosowaniem może być np. usuwanie innych programów robiących
podobne rzeczy. Np. proftpd zawiera w swojej liście Obsoletes: wu-ftpd
ncftpd, beroftpd, anonftp, co spowoduje pousuwanie innych ftpd i
potrzebnych im zasobów przed rozpoczęciem rozpoczęciem instalacji samego
proftpd. W tej chwili np. kompiluję kerberosa i tam wrzuciłem w Obsoletes
do pakietów na serwer i klienta "Obsoletes: telnet, rsh, ftp" co spowoduje
usunięcie klasycznych klientów i daemonów ftp, rcp, rsh, rlogin i ftp po
to żeby gładko podmnienić wszystko to na odpowiedniki kerberosowe.
-- Lista dyskusyjna poświęcona PLD-devel ---
--------------------------------------------
Została utworzona lista poświęcona wyłącznie sprawom PLD-deve. Chodzi o
to, że kilka osób chętnie by się przyłączyło do prac nad PLD ale tylko w
ramach wersji opatej o kernel 2.1. Ponieważ ruch na liście jest już
całkiem całkiem, a w większości nie jest on poświęcony PLD-devel to
namówiłem Wojtka zeby została utworzona lista poświęcona wyłącznie devel.
Niestety Wojtek nie przekazał mi jak ta lista się nazywa ale przypuszczam,
że jest to pld-devel-list.
-- Obecny stan PLD-stable ------------------
--------------------------------------------
Wczoraj przekompilowywałem wszystko co do tej pory udało się zgromadzić do
stable. Była to pierwsza całościowa rekompilacja po przeniesieniue wielu
rzeczy do /usr/X11R6. Po zweryfikowaniu okazało się, że kilka pakietów nie
jest jrszcze gotowych do tego żeby poprawnie się budować kiedy zasoby w
postaci bibliotek i plików nagłówkowych są właśnie tutaj posadowione. Do
kulawych pakietów nalęż mc, gnome-utils, gnome-guile. Trzeba będzie to
wykończyć jeszcze. Ze względu na jakieś nie namierzone jeszcze kłopoty z
obecną postacią proftpd z patche jaki zmajstrowałem chwilowo go wycofałem
z całości. W tej chwili moge w miarę spokojnie powiedzieć, że to co jest w
stable obecnie jest spokojnie do szerokiego używania.
-- Tłumaczenia -----------------------------
--------------------------------------------
Były zapytania o to co można przetłumaczyć. Umieszczam poniżej listę
speców ze stable które nie mają jeszcze tłumaczeń na poziomie speca.
Jeżeli ktoś ma chęć po kawałku nawet to robić to prosiłbym o pomoc w tej
sprawie. Propozycje tłumaczeń prosiłbym od razu zgłaszać w postaci
diffów (będzie łatwiej to dołączać Wojtkowi i mi do zasobów).
ORBit, WindowMaker, X11R6-contrib, aalib, at, bzip2, dia, expect, fnlib,
gdbm, ggv, glib, gltt, gnupg, gpm, gtk+, guile, kdbg, kless, lesstiff,
libtool, m4, mouseconfig, nas, ncurses, nedit, newt, pam, pine, rpm,
rsync, sharefonts, slang, tcl, tcp_wrappers, tk, type1inst, wmconfig,
xkeycaps, xmbdfed.
-- (PLD) Automated Firewall Setup (AFuS ? ;)
--------------------------------------------
Kika dni temu wpadł mi pomysł na coś czego nigdzie indziej nie znalazłem,
a w zasadzie jest naturalną konsekwencją istnienia pakietów i ich
własności. Otóż możnaby pomodyfikować wszystkie pakiety zawierające usługi
sieciowe i oprogramowanie (także) klienckie tak żeby w trakcie instalacji
dodawały plik z list portów i protokołow które muszą być odpięte żeby dana
usługa mogął chodzić poprawnie. Da to mniej więcej tyle, ze pop
rzebudowaniu nieco firewall-init (stable) czy ipchains-scripts możnaby
mieć automatycznie konfigurowanego FW.
I tak np. zainstalowanie sendmaila mogłoby automatycznie odpinać na
incoming port 25/tcp. Instalacja klienta poczty pop czy imap powodowałaby
odpięcie na outgoing portów imap/pop na zewnąrtrz i na loopback dev.
Same modyfikacje powinny być wręcz trywialne tylko trzeba będzie się
jeszcze zdecydować czy pakiet włąćiwie od razu wrzuca odpowiedni plik z
rejestracją tego co potrzebuje czy odpowiedznei "zapotrzebowania"
rejestruje w bazie z której są generowane ustawienia FW. Pierwsze wydaje
mi się prostrze.
O ile zdecydujemy się na AFuSa to będzie to wymagało przeribienia
wszystkich pakietów ze stuffem sieciowym.
A oczywiściesama koncepcja AFuSa obejmować może tylko regóły incoming,
outgoig, które default powinny być deny. Z forwardingiem będzie admin
niestety musiał sam się bawić. Sama koncepcja AFuSa niesie ze sobą jedną
podstawową korzyść, że nawet kiepski admin nie będzie musiał sie za bardzo
bać skanowania portów. Także odpadnie nam ewentualne dokoptowywanie
jakiego kolwiek softu do ustawiania generalnie FW. W %verifyscripts
możnaby dorobic automatyczne sprawdzanie czy w danym momencie regółą jaką
potrzbuje pakiet jest obecna w bierzących ustawienianiach FW. W zasadzie
jeżeli by się uprzeć to zrobienie wsparcia na ustawianie forwardingu w FW
powinno być już o wiele prostrze niż cała reszta w kupie.
-- Krótkie podsumowanie --------------------
--------------------------------------------
W tej chwili PLD-stable jest:
- w CVS: 106 speców na sumę 495,339 bajtów
- pakietów binarnych w części wytestowanej: 175 na sumę 44,914,377 bajtów
- pakietów src w części wytestowanej: 92 na sumę 67,454,538 bajtów
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*
Więcej informacji o liście dyskusyjnej pld-devel-pl