ra-general-updates: kto, z kim, kiedy ?

[Tomasz Kłoczko]

On Wed, 11 Dec 2002, Jakub Bogusz wrote:

> On Wed, Dec 11, 2002 at 06:06:53PM +0100, Witold Filipczyk wrote:
> > > Budowanie dla roznych architektur zazwyczaj nie jest jednoczesne. A ktos
> > > moze (i czasami robi) commity *po* wyslaniu zlecenia (nie ma zadnej
> > > publicznie dostepnej informacji, ze cos wlasnie czeka na przebudowanie i
> > > nalezy sie z commitami wstrzymac), co w efekcie czesto daje pakiety
> > > zbudowane na podstawie roznych wersji speca / zrodel.
> > > 
> > > Chyba, ze jakies locki dla cvs-u ustawiane przez buildery wymyslimy...
> > > Mysle, ze lepiej zdejmowac tagi, jesli pakiet sie nie zbuduje. I to nawet
> > > moze sie odbywac automatycznie na podstawie wynikow z builderow.
> > 
> > Jak będzie pełna automatyka (automatykę wyzwala zmiana Release speca),
> > to rewizja speca a także rewizje wszystkich źródełek zostaną
> > zapisane w pliku, który zostanie ustawiony w kolejce oczekujących.
> 
> To jest niebezpieczne.
> Nawet jeżeli założyć pełne zaufanie do osób mających r/w do CVS - to
> hasła lecą praktycznie nieszyfrowane (w tej samej postaci, co w .cvspass
> - jakaś stała mapa).
> 
> Chociaż... teraz też nie jest najlepiej - wystarczy trafić w odpowiedni
> moment i zmodyfikować coś już po puszczeniu zlecenia :/

Dlatego de facto puszcznie zlecenia musi się wiązać z wczeniejszym
oetykietowaniem zasobów pakietu i puszczeniem całości z etykiety.

Typowo wykonuję tu coś takiego:

$ for i in <lista_speców>; do ./buildrpm_request $i; ./builder -Tvs $i; ./builder -m $i;  done

Wystarczy odwrócić klejnosć dwuch pierwszysch poleceń w pętli i 
przechwycić nazwe etykiety jaka zostaął nadana po to zby przekazać to do
./buildrpm_request.

Także ta kwestię uznałbym już za zamkniętą.

> BTW, nie wiem czy tak jest na builderach, ale użytkownicy, z których
> prawami są budowane pakiety, powinni mieć uidy inne niż wszyscy
> użytkownicy w systemie i innych chrootach (zwłaszcza systemowy użytkownik
> builder, mający dostęp do sudo chroot, co daje roota).

Wystarczy w sudoers ograniczyć że chroot musi być wykonany z konkretnymi 
parametrami żeby wymusić pzrejscie z użytkownika builder po za chroot na 
użytkownika builder w chroot.

Przykład:

builder team=(root) NOPASSWD: /usr/sbin/chroot /home/users/builder/chroot-sparc su - builder

[..]
> "Rozproszony system builderów" może służyć testowym przebudowom -
> pakiety do użytku mogą być budowane tylko na najbardziej zaufanych
> maszynkach.

O ile testowe budowanie nie bedzie się wiązać z niczym więcej jak 
zwróceniem statusu OK/FAIL+buildlog to raczej buildr klient będzie 
musiał ufać temu co dostaje.
Autentykacja oddawanych wyników może być robiona kluczem konkretnego
buildra dla którego jest to generowane. Przy stałej lokacji w 
authorized_keys2 wystarczy stawić:

allow="client.build.host.name",no-pty ssh-dsa <...>

plus obłożenie tego typu konta odbierającego fail buildlogi rssh (choć
wydaje mi się że wystarczy jeszcze uzycie commnad w authorized_keys2). 
Trzeaby wczytać sie jeszcze w mana do sshd i wykonać kilka prób.

Skrypt do generowania klucza buildera pakujący to w zgłoszenie wysyłane na
automat dopisujacy dany build host do zestawu builderów jakie może
wykorzystywać powinien być w katalogu domowym ~builder po zainstalowaniu 
pakietu pld-builder.
Prawdopodobnie builder powinien też mieć możliwość porzycenia zlecenia 
jakie przyjał i do zgłąszanai tgo przydałby się jego klucz GPG (choć na 
pcżtku bez tej funkcji będzie się można IMHO obejść zakładajac jakiś
konkretnych czas przez jaki powinien dany builder obsłużyć zlecenie).

Zacznijmu podsumowywać: w nagłówku listu zlecenai powionmny być pola:  
X-Spec:, X-build-tag:, X-build-arch:, X-build-prioryty:, X-build-commnad: 
{build|test-build|cancel|staus|install-package|dist-upgrade|remove-package}.

Zawartość każdego z pól nagłówka powinna byc filtrowana na okoliczność 
[` "] zeby nie było mozliwe wstrzelenie tu jakeigoś dodatkwego polecenai 
które wykonałoby się po stronie automatu (becnie jest to możliwe ale 
dopiero po weryfikacji podpisu GPG zlecenia).

Wydaje mi się że w nagłóku także możnaby od razu przekazywać także
X-buildlogs-host: czy X-build-result-adres: (gdzie maja być zwracany list 
z wynikiem budowania), X-return-result-packages-to: (user w host:/path gdzie 
ma być zwracany wynikowy pakiet o ile nie jest to build testowy, a w 
przyadku buildeu testowego analogiczne pole (czy może X-return-results:) 
gdzie miałby być zwracany fail buildlog.

To powinno umożliwić łatwiejsze sterowanie konfiguracja builderów co do
tego gdzie mają oddawać wyniki z jednego miejsca).

Coś jeszcze ?

Kolejna sprawa to może osobny automat pzrechowujacy informacje o tym kto
gdzie może posłać zlecenia co też ułatwiłoby zarządzanie uprawnieniami
czegos takiego (tera klucze trzeba ecznie rozrzucać po keyringach
builderów). Wtedy zlecenia musiałyby być podpisywane kluczem tegoż
automatu i tylko on mógłby zajmować się bezposrednia komunikając z build
klientami. Umożliwiłoby to także wykonywanie weryfikacji zawartości
wysyłanych zleceń w tym jesdnym punkcie. Konto buildra instalowane z
pakeitu pld-builder mogłoby być bez shellowe co także uniemożliwiałoby
zdalne czy lokalne logowanie się w takie śrosdowisko.
Chodzi generalnie o to żeby to co będzie w środowisku buildera instalowane
z pld-builder było możliwie maksymalnie bezobsługowe. Wręcz możliwść
korzystania z tego konta poprzez sesję shellową powinno być wyblokowana
żeby nie kusiło do używania tego do innych celów.
Podobne podejście z wycinaniem "luźnych stopni swobody" reszty automatyki
takzę konsekwentnie powinno być redukowane.

Jeszcze kika szczegułów miałem wstępnie obmyślanych ale nie pamiętam już
co (jak mi się przypomni to podeślę).

Jeszcze jedno. Odseparowana i dedykowaną maszynkę która była stawiana po
to żeby zarządzać autentykacją na potrzeby automatyki PLD czy która
bezobsługowo podpisywałaby wynikowe pakiety czy PLDSA do rozesłanuia mamy
(komp stopi od kilku miesiecy i sie nudzi). Także ten elemet
nowotworzonej układanki jest pod ręką.

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*