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