Buildery

[Tomasz Kłoczko]

On Tue, 14 Jan 2003, Lukas Dobrek wrote:
[..]
> Nie do konca bo mozna to wolac skryptem naprzykald requester robil:
> 
> ssh $TOSHED_BUILDER "su builder -c /usr/sbin/chroot/ poldek --upgrade-dist"
> ssh $TOSHED_BUILDER "su builder -c /usr/sbin/chroot/ su -c ./builder $FILE.spec"
> 
> pelna automatyka. Tylko troche bez sensu. 

Jedna uwaga. Zlecenie które idzie na klienta z requestera budującego 
pakiet nie powinno zawierać _pod żadnym pozorem_ *żadnych poleceń*.
Trzeba to zrobić w ten sposób, że przewidujemy konkretny zestaw akcji
jakie mają być prawo wykonywane na build kliencie. Na przykład:
- budownie produkcyjne,
- budowanie massiv,
- status,
- cancel zlecenia,
- wyinstalwanie pakietu i wszystkiego co jest od niego zależne,
- zainstalwanie pakietu,
- upgrade-dist,
.
.

+ do tego adekwatne dodatkowe parametry przy danym typie sygnału 
pzrekazywanego klientowi.

Konto buildera na kliencie powinno mieć wręcz /bin/false. Nie powinno być
tam możliwści zalogowania się choćby po to żebey nie kusiło żeby coś tam
majstrować czgoś przy okazji.

Dzięki takiemu czemuś w module wykonującym autentykacje można będzie
sprawdzić typ akcji pzrekazywany do wykonania i wszystkei parametry. Np.  
to że ktoś będzie chciał przebudować pakiet XX z produkcją pakietów (build
produkcyjny) prekazując np.:

X-pkg-cvs-tag: XX-<wersja`cat foo > któryś_ze_skryptów_build_klienta`

Sprawdzenie poprawności wszystkich pól nagłówka zlecenia docierajacego do
auth powinno się odbyć właśnie tutaj po to żeby można było przekazać
czyste zlecenie do samego requestera. Dzieki temu wszystko co będzie się
działo za tą barierą o ile sam bariera będzie poprawna będzie mogło się
odbywać w warunkach uproszczonej autentykacji (na minimalnym poziomie
jakie jest potrzebny do zapenienie kompletnego bezpieczeństwa reszty).

Także jeszcze raz .. proszę sobie wybić z głowy to że w zleceniu 
przekazuje się jakieś polecenia :)

Druga możliwość wejścia nieupoważnionego w strefe wewnętrznej automatyki
builderów będzie poprzez to co buildery ciągnąć. Jeżeli requester zanim
wyśle zlecenie do klienta zbuduje src.rpm-a to nie będzie tu też zadnych
dodatkowych dróg potencjalnego wejścia. Budowanie src.rpm-a o ile będzie
się odbywać po za strefą auth i sprawdzenia poprawności zlecenia też
powinno być już w strefie bezpiecznej.

Innej drogi raczje nie będzie o ile znowu .. na klienta nie będzie
przekazywane cokolwiek co bęzie mogło być zdalnym wywołaniem czegoś co 
jest wprost przekazywane w zleceniu.

[..]
> Jak skonczy to bedzie informowal requestera, ze jest wolny. 

Nie ma sensu. To może działać tak jak do tej pory. Zlecenia docierają i są
kolejkowane, a przez co requester nie musi się zajmować tym co się dzieje
na builderach.
Tak na pewno może być i musi być na builderach proukcyjnych.

Pewne mozliwości modyfikacji ogólenego schematu daje uwzględnienie massiv
bld. Otóż tutaj specyfika budowania w sumie może dawać to że zlecenie może
w sumie przybieraćconajmniej kilka innych form. Requeter tutaj takzę
powinien budować src.rpm-y dla massiv bld w osobnym katalogu publicznie
dostępnym teraz sygnał zlecenia może być dwojaki:

- albo taki sam jak dla buildrów produkcyjnych czyli PGPnietym zleceniem,

- sygnałem jest samo pojawienie się src.rpm-a i to że w katalogu (też
  publicznie dostępnym) dla danego src.rpma nie ma jeszcze pliku 
  informującego o statusie budowania.
  Najlepiej w takim wypadku jakby z pozostałych jeszczenie pzrebudowanych 
  src.rpm-ów które nie maja statusu pakeit był wybierany losowo.

Druga metoda jest to tyle dobra, że w sumie nie wymaga to żadnej 
autentykacji czy odbierania aktywnie sygnału na build kliencie. To jest 
dobre z punktu widzenia bezpieczeństwa.

Kłopot niezależnie od tego czy sygnał jest odbierany aktywnie czy pasywnie 
jest natomiast nadal z odbiorem fail loga bo mozę być ne na tyle duży że 
może nie chcieć go przepuscić któryś z SMTP serwerów.

*TU* jest jeszcze jeden ze słabych punktów całego szkieletu bo ważne w tym
wszystkim jest także bezpieczeństwo i ftp.pld serwera jak i buildlogs.pld.
Ta część jeszcze wymaga przemyslenia.

A jeszcze jedno (tak mi się własnie nasuwa na czoło) .. o ile
przewidywalibyśmy pewne połączenie obu powyższych wariantów w postaci
odbioru tylko jednego zlecenia sygnalizującego dla massiv bld z tym gdzie
są src.rpm-y i gdzie maja być odsyłane wyniki, a cała reszta odbytwałaby
się tak jak w drugim wariancie możnaby dzielić wszystkie buildery na grupy
zajmujące się weryfikacją niezleżnych od siebie grup pakietów (choćby po
to że budowanie wszystkeigo może w sumie i bedzie moze i trwało relatywnie
długo ale niezalenie od tego będzie można wykonąć równolegle niezależne
serie próbnych buildów na osobnych grupach build kleintów).

Jeszcze jeden elemnt układaniki. Chyba mam pomysł na to jak w prosty
sposób zapewnić to że dane zlecenie powinno być wykonane w środowisku
*konkrtnych* pakietów.

Otóż do wystarczyłoby w zleceniu wysyłanym z requestera wrzucać sumę
kontrolną z posortowanego rpm -qa | (X-rpm-qa-md5sum: <>). Zlecenie byłoby
wykonywane o ile na builderze "rpm -qa | sort | md5sum"  ddałoby dokładnie
to co jest w zleceniu. W razie czego build klient mógłby anonimowo już
odpytać się automatyki o to jaki zestaw na konkttetnej architektóre
powinien być zainstalowany. Otrzymawszy (PGPnięty) wynik mógłby wykonać
niezbędne korekty kompletnie bezobsługowo co najwyżej loggerem logując do
sysloga że wykonał konkretną krektę (żeby ad acta było wiadomo że coś sie
zdażyło).
Tego typu weryfikacja powinna być wykonywana zarówno przy build massiv jak
i produkcyjnym budowaniu.

Jednym z sygnałów jaki powinien docierać z requestera do build klientów
powinno być pobieranie tej sumy kontrolnej z rpm -qa. Innym sygnałem
powinno być pobieranie pełnej listy zainstalwoanych pakietów (requesterowi
będzie to potrzebne choćby po to żeby wiedzieć czego ma wymagać na reszcie
builderów i/lub żeby wykonać samemu weryfikacje całości dostępnych build
zasobów :)

Tak czy inaczej mi przynajmnie brak jeszcze tylko kilku detali do tego
żeby ze spokojem brać się do implementownia :)
Niemniej na samo implemtowanie jeszcze ciut za wcześnie .. jeszcze lepiej
poświecić nieco więcej czasu na przemyślenia.

Co do tego w czym to powinno być robione to odpowinno być robione to
odpowidź jest oczywista .. POSIX sh będzie najlepciejsze :)

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*