Buildery

Lukas Dobrek dobrek w itp.uni-hannover.de
Śro, 15 Sty 2003, 11:59:44 CET


On Wed, Jan 15, 2003 at 01:36:51AM +0100, Tomasz Kłoczko wrote:
> 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ń*.
Nie ma powodu. 
> 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.
> 
> Także jeszcze raz .. proszę sobie wybić z głowy to że w zleceniu 
> przekazuje się jakieś polecenia :)
Troche sie nie zrozumielismy. To powyzej mialo pokazac tylko ze full
wypas automatyke mozna osiagnac tez w dosyc prosty sposob ale nie
trzeba. 
> 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.
Zawsze jest zagrozenie ze ktos zamanewroje w cvs. Ale to mamy i teraz i 
nic sie na to nie poradzi. 
> [..]
> > 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.
eeee. To gdzie chcesz miec te kolejki na requesterze czy na builderze. 
Bo mi sie wydawalo zawsze ze kolejka zadan jest w schedulerze nie na
odwrot. I tak IMHO powinnno byc.
Bo:

1. Wyobrazmy sobie sytuacje z masiv build jest 100 pakietow do
   przebudowania. 
2. Wtedy majac wiedze na temat tego jakie buildery dzialaja requester
   ma szanse wykonac operacjie ich przebudowania znacznie szybciej. 
> 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.
To bedzie cholernie nie efektywne. Ja bym wolal gdyb naprawde istnialy
kolejki, w requesterze ktore mozna by balansowac itp. 
> 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.
> 
> Co do tego w czym to powinno być robione to odpowinno być robione to
> odpowidź jest oczywista .. POSIX sh będzie najlepciejsze :)
> 
jakos jej oczywistosc do mnie nie dociera. 

To wogule nie jest jezyk. To shell w tym sie nie implementuje duzych 
programow. 

Potwornie sie ograniczamy piszac to w shellu. 

Lukasz

-- 
Łukasz Dobrek
   An optimist believes that we live in the best of all possible worlds.
   A pessimist is sure that this must be so.
http://www.pld-linux.org



Więcej informacji o liście dyskusyjnej pld-devel-pl