Idea buildera srcrpmoww fantazjach o Ac. Może ktoś to wyjaśnić ?

[Tomasz Kłoczko]

On Sat, 8 Feb 2003, Radoslaw Zielinski wrote:

> Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [08-02-2003 20:13]:
> > On Sat, 8 Feb 2003, Mariusz Mazur wrote:
> >> On Saturday 08 February 2003 19:07, Tomasz Kłoczko wrote:
> >>>> A jaka jest przewaga instalowania pakietów poldkiem zamiast ściągania ich
> >>>> ftpem i robienia rpm -i?
> 
> Wykorzystywanie -- do zadania, które i tak musi zostać wykonane --
> narzędzia, które jest znane, przetestowane, i spełnia zadanie bardzo
> podobne.  Wygodne.  Możnaby potraktować poldka jako ,,czarną skrzynkę''.
> 
> > Dobra .. niemniej tak czy inaczje w tej chwili kluczową sprawą jest
> > zupełnie cos innego. Tym czymś są szczegóły dotyczące tego jak
> > zaimplemrtować mozliwie prosto autentykację mając trzy parametry:
> > - login,
> > - czynność,
> > - architektórę/lisę architektór (allarch, lista architektór).
> 
> Serwer kluczy trzyma klucze publiczne wszystkich, którzy mają coś
> wspólnego z builderami i tych, którzy mają ochotę je tam wrzucić.

To czy klucze są lokalnie czy zdalnie nei ma znaczenia.
Juz jest po autentykacji. Masz już trzy parametry w reku i teraz 
powinieneś w oparciu oa opis ACLi stwierdzić czy dane zlecenie 
przyjmujesz. Chodzi o włąsnie taki w miarę prosto obsługiwalną z poziomu 
narzedzi typu awk/sed/sh definicję ACLi w pliku i sposobu posługiwanai sie 
tym .. i tylko o to.

> Na builderze każdej architektury znajduje się plik o składni 'klucz
> separator lista_akcji'; zarówno klucze, jak i listy akcji mogą być
> kumulowane w grupy (@grupa_kluczy, %grupa_akcji).

Niepoprawnie, bo zakłada że klucz może być różny w zależności od tego 
gdzie się posyłą zlecenie. weryfikacja podpisu pod zleceniem ma być 
wyłacznei po to zbey stiwrdzić że osoba wysyłajaca zlecenie jest 
upreawniona do operowanai na automatyce.
Załóż że podpisywanym kawałeki mtekstu jest lista zmiennych i ich watości 
w ppostaci SH:

LOGIN=<login>
ACTION=<action>
ARCH={<arch_list>|allarch}
<inne_zmienne>

Ergo: jeżlei ktoś patrzy na zaszyfrowany kawałek zawartosci listu to nie 
może sie zorientować kto ani co wysyłąw tym zleceniu. Po rozkodowaniu body 
listu zwiwrajace powyższe jest zapisywane do pliku. Potym następuje 
weryfikacja czy pzrypadkiem ktoś w zleceniu nei króbuje pzrejazać np.:

ARCH=allarch'zrób coś bardzo brzydkiego'

po zweryfikowaniu całości
nasepuje włączenie tego pliku w treść skryoptu i masz juz w środowisku 
gotowe parametry LOGIN, ACTION, ARCH i inne i wykonujesz weryfikację w 
oparciiu o ACLe czy przyjać zlecenie czy nie na konkretne architektóry. W 
eyniku tego odkłądane sąw kolejny kataklog zlecenai na konkretne 
architektóry. Na tym kończy się działlnoisć modułu do auutykacji. Z crona 
osobny skrypt pzreglada katalof ze zleceniami i wysyłą juz na fizyczne 
buildery podpisujac zlecenia włąsnym kluczem. Buildery odbieraja zlecenai 
tylko z jednego miejsca (sprawa niezawodnej identyfikacji tego opiera się
takze o GPG).


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*