rsaf
Senior Member
zastupce cloudu 10.152
Registrován: 16.01.2003
Příspěvků: 866
|
Ja bych taky pridal svou ruku, muzu nabidnout:
- znalost RIPE DB (z pozice LIR)
- nejakou tu znalost PHP/MySQL (co potrebuju jsem vzdy napsal, myslim ze dokazu napsat i neprasacky kod)
- zkusenosti s pokusem (uspesnym) o zprovozneni RIPE WHOIS serveru (kdo zkousel, vi ze to neni sranda)
Jako nejdulezitejsi veci se mi jevi:
- vytvoreni maintainer objektu (minimalne ochrana pres neco jako MD5-PW a co nejdriv i PGP podpisy - pokud totiz, nahodou, jednu zmenu musi autorizovat vic subjektu, je PHP nebo proste nejaky podpis v zasade jedina sance)
- doplneni hierarchie pro INETNUM objekt:
-- doplneni parametru "status" (allocated, assigned)
-- doplneni parametru mnt-lower (cizi klic k maintainer, rozhodne multiple)
Tohle by nasledne umoznilo hierarchickou praci typu:
- cloud vznese pozadavek o prideleni /16
- nekdo z clenu RIPE vytvori patricny INETNUM (samotny inetnum by cloud nemel mit menit pravo - jen menit nektere parametry, ale ne treba nazev...) a nastavi v nem mnt-lower na seznam adminu z cloudu (zde se asi musi pouzit nejake pretizeni prav pravy spravce, pripadne nejlepsi by bylo, kdyby se prava dedila shora - kdyz jsem mnt-lower u 10/8, mel bych mit pravo menit jakykoliv inetnum pod 10/8), parametr status se nastavit na allocated (prideleno ale nepouziva se - pro dalsi deleni)
- admini z cloudu, autorizovani svym maintainer objektem, budou vytvaret podrizene inetnum pro sve site / uzivatele a davat jim status assigned, taky by mohli/meli vytvaret inetnum se statusem allocated (subalokace)... Hierarchie prideleni (a udrzovani zaznamu v DB) by pak mohla vypadat asi takto (example):
--- RIPE alokuje cloudu /16
--- cloud alokuje APcku /22
--- APckar assignuje 3x /27 primo pro sve site (svuj vsesmer, sektor, sit v baraku napr.)
--- APckar alokuje /25 Frantovi Novakovi (ten ma nutne svuj person a mntner v databazi - to se vytvari volne) ktery je na nej pripojeny se svym blokem panelaku
--- Franta assignuje ruzne rozsahy, nekdy i /32 pro sve usery
Vysledkem je:
- zadna centralni sprava
- moznost mit maximum detailu v db
Dalsi vec, ktera by se mela resit je kontrola kvality pridelovani... opet bych navrhoval podobny postup, jaky ma RIPE:
- male rozsahy (podle zkusenosti toho kdo prideluje - stejne jako assignment window u RIPE) se prideluji bez sohlasu RIPE, pouze by mohla byt povinnost pri vytvoreni jakehokoliv INETNUM poslat na nejaky e-mail kratke (dva radky) zduvodneni, povinnosti by bylo, ze do subjectu napise nazev inetnum.
Rovnez navrhuju (alespon se tim vazne zabyvat, neprosazuju to) kouknout se na RIPE WHOIS server - ten uz ma vyresenou vetsinu veci:
- bezi to v ostrem provozu, vi se ze to funguje
- celkem asi implementuje to, co jsem psal vyse (az na nejake veci ohledne tech maintaineru, to bych musel jeste dost prozkoumat)
- nebylo by s tim tolik prace/vyvoje/testovani...
Nutno ovsem dodat ze:
- zdrojaky k tomu jsou, ale podle me kod NIKDO NIKDY nepochopi (podivejte se jak je to udelane, je to slepenina xxx jazyku - minimalne c/java/perl - neverim tomu, ze ten kdo dokaze nekdy nekdo procist tak, aby rekl ze tomu uvnitr rozumi
- je to dost vazane na konkretni verze napr. knihoven - to, ze to pobezi na nejakem stroji jeste s necim nevidim prilis realne - ja to mam pustene ve vmWare
__________________
Lide v CZFree se dělí na tři skupiny: 1) deu; netdave 2) ti co znají jejich čísla 3) ti ostatní
Naposledy upravil rsaf 25.12.2006 v 20:58
|
26.11.2006 v 21:20
