Kompilacja XFree-4.0

[Tomasz Kłoczko]

On Thu, 16 Mar 2000, Lukasz Trabinski wrote:

> On Thu, 16 Mar 2000, Blizbor wrote:
> 
> > No dobrze, przy okazji jeszcze jedno pytanie - czy ktos sie bawil juz
> > sendmail'em 8.10 ? jak wrazenia ?
> 
> Tak. Posadzilem owego sendmaila na trzech maszynach obslugujacych miedzy
> innymi rowniez uucp. Poprostu dziala. :)

To może byś spróbował dorobić speca i ewentualne poprawki ? :-)
To czemu polecałbym się przyjrzeć to obcięcie wszystkich plików z makrami
m4 które nie są do użycia pod Linuxem. Chodzi o to, że z takiego
sendmail-cf moznaby wyciać w zasadzie ponad 3/4 plików, a w takiej
postaci IMHO mołoby być to juz zintegorwane z samym sendmailem (byłoby o
jeden pakiet mniej).

BTW. Właśnie zajrzałem do tego co zapuściłem sobie wczoraj wieczorem, a
zapuściłem sobie "rpm --rebuild XFree86-4.0-2mdk.src.rpm". Wygląda, że
wszystko poprawnie się kompiluje. Co prawda do pełnego wygenerowania
binarnych pakietów nie doszło bo jakiś (le pardon) palant który preparował
speca do contriba MDK w %install użył kilku bashizmów (a u nas /bin/sh to
nie bash przecież).

Spróbuję przejrzeć dzisiaj ten pakiet z MDK i o ile zdąrze to spreparuję
co trzeba żeby było możliwe puszczenie XF 4.0 na buildery i wtedy może
jeszcze wyjdą jakieś kwiatki (choć nie przypuzczam). Tak czy inaczej
wygląda, że przynajmniej na i686 kompilije się (jednak) jak trzeba. Jeżeli
bym nie zdążył to dokończę to w poniedziałek (bo na łykendy jadę do
rodzinki). W kolejce też czeka jeszcze puszczenie XFree 3.3.6 (z tego co
Janek wczoraj spreparował) ale tu jeszcze kilka drobnych szczegułów jest
jeszcze do dopracowania, a kilka patchy wartych do zaporzyczenia.

Jeszcze jedno. Na wykończeniu mam jeszcze heimdala ale tutaj żeby puścić
to w obieg trzba będzie wcześniej przyszykować środowisko w jakim będzie
mógł pojawić się końcowa postać pakietów heimdala bez zachodzenia na inne
pakiety co bedzie się wiazać z poszatkowaniem util-linux wyodrębiniając z
niego login w osobny pakiet (w heimdal/kerb jest osobny skerberyzowany
login), który przez Obsoletes będzie musiałbyć wyinstalowywany z zestawu
pakietów jakie są w systemie. Także jeżeli ktoś miałby chęć i czas to
zapraszałbym do jakiś bliższych oględzien util-linux bo bez jego
przerobienia heimdal nie bezie się mógł raczej pojawić.

Co do util-linux to wogóle chyba wartoby jeszcze to troche podzielić na
mniejsze kawałki, bo na przykład nie wszędzie jest potrzebne cytune
(program do tuningu wieloportów Cycladesa .. nota bene wartoby dorobić do
tego jakiś skrypt na wzór i podobieństwo rc.serial lup poszerzyc obecne
funkcje rc.serial o to zeby umożliwiał także tuning Cycladesów) lub
mcookie który raczej powinien wpaść gdzieś w okolice Xów. W util-linux
intryguje mnie jescze jedna rzecz. W zasadzie nie tyle w util-linux co w
info, bo z util-linux przychodzi info do ipc ale "info ipc" pokazuje mana
ipc(2) zamiast stronę info. Pinfo w tym wypadku zachowuje się (o dziwo)
poprawnie pokazujac wąłsciwą stronę info.

Po pojawieniu się heimdala ewentualne poprawki na kerberyzację
preferowałbym raczej z użyciem SASL niż bezposrednio heimdal/kerb gdyż w
ten sposób nie powstawać będzie bezpośrednia zależność od kerb/heimdal, a
i rózne aplikacje beą mogły być używane w środowisku z/bez kerb. Tutaj
będzie to zapewne wybmagać wiekszej pracy rozłożonej na nieco dłuzszy
okres czasu ale ten kerunek wydaje sie bardzo obiecujący. Jakby ktoś nie
kojarzył jeszcze co to jest ten SASL to może kawałek z README:

FEATURES
--------
The following mechanisms are included in this distribution:
ANONYMOUS
CRAM-MD5
DIGEST-MD5
GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5)
KERBEROS_V4
PLAIN

The library uses a Berkeley DB, gdbm or ndbm file on the server side
to store per-user authentication secrets. The utility saslpasswd has
been included for adding authentication secrets to the file.

PLAIN can either check /etc/passwd, Kerberos V4, use PAM, or the sasl
secrets database. By default PAM is used if PAM is found, then
Kerberos, finally /etc/passwd (non-shadow). This is tweakable in
the configuration file.

Mówiąc w skrócie SASL to Simple Authentication Security Layer czyli
pośrednia warstwa która umożliwia wybranie metody autentykacji. W obecnej
wersji cyrus-sasl jest to biblioteka z zestawem dynamicznie ładowanych
modułów wykonujących zadanie autentykacji i co najaważniejsze dopiero
poszczególne moduły są zależne od np. PAM, kerb itd, a wybór używanych
modułów odbywa się poprzez centralny pojedynczy plik konfiguracyjny samej
biblioteki.

Pewien kłopot może sprawieć licencja na jakiej są udostępniane obecnie
źródła cyrus-sasl, która z tego co pamiętam wygląda na dość podobną do
tej na jakiej jest idostępniany pine (choć mogę sie mylić). W razie gdyby
ten kierunek byłby obiecujacy byłbym nawet skłonny spróbować pokusić się o
spreparowanie nowej implementacji (GPL) SASL z RFC, draftami w ręku gdyż
gra wydaje się warta świeczki.

Co do sposobu dostosowywania apliakcji do SASL to zdaje się, że na ftp
obok źródeł cyrus-sasl leży patch do SASL dla pine ale do wersji 3.96 i
potencjalnie będzie jeszcze wymagało to adaptacji ale w razie czego jakis
szkoleniowy przykład co do tego jak przystosowanie do SASL robić już
raczej jest.

Do szczęścia przydałoby sie coś podobnego do SASL ale na warstwie
połączenia co umożliwiałoby w podobny sposób dodanie np. negocjowanie
kodowania połączenia z użyciem TSL/SSL czy GSSAPI. Może ktoś coś wie o
jakimś próbach opracowania takich mechanizmów ?

To tyle .. tak do śniadania :-)

Eny koments ?

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*