Registrován: 06.05.2002
Příspěvků: 468

CZF4BFU - konkretni vyvoj a realizace

Příspěvek č. 1

Na srazu ve Visnovi se myslim dopresnila rada veci tykajicich se projektu CZF4BFU a myslim ze by nebylo od veci se pustit do realizace. Uvodem tohoto vlakna zde pretisknu par prispevku z toho minuleho (popisy DEU, hruba konstrukce systemu atd..), a pak dopisu aktualni postrehy a napady...

__________________

Registrován: 06.05.2002
Příspěvků: 468

UPDATE: wiki k CZF4BFU je na adrese
http://www.czela.net/wiki/index.php/CZF4BFU

Zde muzete updatovat dokumentaci


Takze se pokusim sepsat co jsme dali dohromady (tento soupis jeste lada vyedituje pokud budu nepresny, takze prosim nereagujte hned).

Cela aplikace je zalozena na schematu, ktere tu jiz bylo navrzeno:
program u uzivatele ziskava seznam zdroju site CZFree.Net z nejakeho datoveho serveru, kterych je vice a data si mezi sebou predavaji.

Informace o zdrojich site jsme rozdelili na 3 skupiny.
- globalni (volne siritelne, bez dalsich informaci)
- lokalni volne (volne siritelne, nesou informaci o tom kde jsou rozumne dostupne napr. 10.15.xx.xx atd.)
- lokalni privatni (siritelne pouze v ramci definovane oblasti)
ktere jsou ulozeny ve dvou souborech, prvni globalni obsahuje prvni dve skupiny a je soucasti komunikace mezi servery. Druhy lokalne privatni se mezi servery neprenasi, ale jen primo uzivatelum v danem lokalnim rozsahu.

S-S (server-server) komunikace:
informace o zdrojich jsou predavany formou textovych souboru mezi servery. Zpocatku predpokladame mensi mnozstvi serveru (pro Prahu cca 5), takze znalost ostatnich muze byt ve verzi 1 uchovavana statickym seznamem, pozdeji treba podle nize uvedeneho algoritmu nebo proste nejak jinak.
Vymena dat probiha kazdy s kazdym, takze pri n serverech je uchovavano n globalnich souboru. Vymenu navrhujeme realizovat pomoci rsync. Nedostupnost spojeni mezi nekterymi servery neni nutna, staci aby server mel dostupnost alespon na jeden dalsi server a mnozina vsech servru byla konzistentni.

Datovou strukturu jsme zplodili takovouto:
polozky jsou ukonceny znakem CR jako v unixu.
GPG: verejny klic emitora (servru ktery primarne informaci o zdroji poskytuje)
verze: 1
následují bloky
TYP: (DC, FTP, HTTP, IRC ......)
URL: http//..../....php
URLIP: http://10.1.2.3/...php
URLINET: http://nejakaadresa.na.inetu
NAZEV: kratky nazev sluzby - napr. Connected forum
POPIS: popis obsahujici HTML tagy
ALT: doplnujici udaje ke zdroji, aplikacne specificke
napr: DC - 10.12.34.56:4411
IRC: #admins
TIMESTAMP: 75264675646 10:40:50 FRI JUN 7 2005
time je formatu unix time dle emitera, pocet vterin od roku 1970 ve formatu longlongint decimalne, za mezerou je nepovinny cas v citelne forme
OBLAST: 10.11.0.0/16
10.1.128.0/17,10.15.0.0/24
oddeleni carkou, strednikem, mezerou
PRIVATNi: A (jako ano, privatne-lokalni nesmi byt v globalnim seznamu)
KONTAKT: url, text, email....., nepovinne
IDPOLOZKY: decimalni cislo dle libosti emitera, nepovinne
GPS: gps souradnice v WGS84 formatu
TYP: uvozuje dalsi polozku

nazvy soubopru jsou ve formatu global(local/privat) cloud/prezdivka/IPadresa serveru
tj. global_jspoj_10_40_0_2.deu
GPG nebo PGP podpis je externi soubor stejneho nazvu s priponou .gpg

S-K (server-klient) komunikace
Klient se pokusi zjistit dostupnost se serveru dle defaulniho iplistu ktery bude obsahovat ip serveru cloudu/projektu ktere je pri zpracovavani aplikace vyhradi a dodaji. Pokud se klient nedostane na nikoho z defaultniho listu, pokusi se zjistit dostupnost na nejake defaultni ip ktera se dohodne (treba na mezicloudu a bude rezervovana pro tuto aplikaci), pokud nenajde, zacne projizdet ostatni cloudy a hledat tuto ip. Na teto IP bude redirekt na server, nebo primo server. Kdyz bude mit seznam IP tak si vyhodnosti jejich dostupnost a na jeden se pripoji.
Komunikace probiha se stejnymi daty. Klient se pokusi stahovat oba soubory globalni i lokalne-privatni (lokalne-privatni je ovsem omezen na strane servru pouze pro klienty z rozsahu dle vule admina).

Zpracovani klientem
Klient sezere data a exportuje z nich HTML stranku, kterou uzivateli zobrazi. Soucasti stranky budou i informace generovane dalsimi soucastmi aplikace. Napr. System zjistovani dostupnosti

System zjistovani dostupnosti
Klient si vybere u kazdeho zdroje zda chce zjistovat jeho dostupnost a pingem si ji bude v nejakem casovem kroku zjistovat, vysledky se ulozi a vykresli se z nich treba graf, procentualni dostupnost nebo treba nejaka barva.

Domnivame se ze tento model je bez problemu rozsiritelny a modulovy.

Ucastnici: lada, tropikhajma, lankvil a ja.

No snad je to vse, rano to jeste jednou projedu. A prosim ladu aby po korekture napsal ze je hotova a ostatni prosim aby do te doby poseckali se svymi poznamkami.

LADA: mirne jsem doplnil, pole NAZEV, formalni specifikaci dodelame az to tu nekdo sprdne a az vyzkousime ten rsync a ja budu mit vic casu. Dale pisu o lsm, cimz jsem se inspiroval. DEU je v podstate LSM pro czfreenet.UPDATE UPDATE

__________________

Naposledy upravil lada 19.07.2005 v 08:36

Registrován: 06.05.2002
Příspěvků: 468

TYP: HTTP
URL: http://www.czfree.net
POPIS: Domaci stranka site CZFree.Net
NAZEV: CZFree.Net forum
TIMESTAMP: 75264675646 Sat Apr 16 23:49:46 CEST 2005
OBLAST:
PRIVATNi: N
KONTAKT: deu@serenanasvsechny.nikdynezvednetelefon.czf[/email]
IDPOLOZKY: 1


TYP: HTTP
URL: http://connected.czf
URLIP: http://10.24.1.2
NAZEV: Connected forum
POPIS: Neverejne forum Connected je pracovni nastroj komunity CZFreenet dostupny jen zvnitru site
TIMESTAMP: 75264675800 Sat Apr 16 23:52:50 CEST 2005
OBLAST: 10.55.0.0/24,10.10.128.0/17
PRIVATNi: N
KONTAKT: [email]carlos@cojavim.kde
IDPOLOZKY: 2

TYP: IRC
URL: irc://irc.bakulak.kosire.czf
URLIP: irc://10.15.0.1
NAZEV: Bakulak IRC server
POPIS: IRC kecani dostupne zevnire 10.15cloudu
TIMESTAMP: 75264675800 Sat Apr 16 23:52:50 CEST 2005
OBLAST: 10.15.0.0/16
IDPOLOZKY: 3
ALT: #czfree.net


PS: Vyhodil sem z tech postu PGP klice a veci kolem PGP obecne, pokud nekdo bude chtit v budoucnu PGPckem podepisovat svoje DEU tak to nebude problem kvuli vrstvovemu navrhu CZF4BFU...

EDIT by lada: po 4 diskusich proc to neni v XML to pisu sem : chci to mit co nejjednodussi aby nikdo nemusel instalovat zadnou library a mohliu to parsovat i ldi z bashe, grepovat nebo awkckovat bez parsovani zbytecnych tagu. Hlavnim duvodem je ale rozjet projekt rychle a ne vykysnout na prilinkovani parseru - proste nejake vrstve kterou musi vsichni implementovat aby mohli datovy soubor rozdekodovat/parsnout. textak je zpracovatelny po radcich.

__________________

Naposledy upravil lada 19.07.2005 v 20:03

Registrován: 06.05.2002
Příspěvků: 468

serverova komunikace
Nejdrive by chtelo poresit par veci na sitove urovni. A to sice jak se maj servery vzajemne hledat.

Jedna varianta je sireni nejakeho seznamu serveru (to ale nedoporucuju, musela by bejt naka autorita ktera bude tendle seznam vydavat atd... a to se dostaneme k tomu, ze to bude zavisli na nakejch lidech jejich zvuli a nezvuli atd...)

Druhou variantou je vzajemne hledani serveru serverem (pomoci dotazu na nejakou presne stanovenou IP pro server CZF4BFU, napr. 10.cloud.BFUprefix.NAKYCISLO)......
Algoritmus by moh vypadat tak, ze nejdrive server pri stahovani DEU jednotek skusi ICMP pinknout na 10.cloud.0.1 (prvni dummy rozhrani), pokud mu neco odpovi tak ma smysl se tazat dal - cloud existuje a je dostupny. Provede tedy dotaz na 10.cloud.BFUprefix.NAKYCISLO. Zde je dalsi tema k diskuzi... chce zjistit jak kde jsou v cloudech obsazeny IP abysme mohli najit vhodny prefix pro presne urceni BFU serveru... nastesti v CZFRFC ADRESSING se tusim pamatovalo na naky rezervy.. takze to by se dalo sikovne pouzit....

interpretace DEU jednotek
Dalsi veci je jak interpretovat DEU jednotky... Navrhuji zatim nejaky jednoduchy PHP nebo Perl parser, ktery z DEU jednotek vytvori nejakou jednoduchou HTML stranku s urcitou moznosti setrideni podle typu zdroje ci mista urceni... Dobre bude take udelat nejaky html help soubor kde budou popsany jednotlive typy zdroju (predpoklad je, ze totalni lama nevi co znamena zkratka irc atd...)... vyhodou tohodle je, ze na server nebudou kladeny naky velky naroky, staci web server, phpko nebo perl a to je vsechno, klient si vystaci s prohlizecem....

Dale az se system nak tak rozjede bylo by dobre popsat CZF4BFU pomoci DNS (ne pro komunikaci server-server ale pro komunikaci klienta se serverem), aby lama mohla navazat kontakt na html se zdrojema pomoci dotazu http://bfu.mujcloud.czf

Jo a snad posledni postreh, mozna by nebylo od veci do DEU zakomponovat ID nodu v mape... bylo by velmi elegantni pri nalezeni nakeho zdroje hned vedet kde presne fyzicky je (+ napr. u takove web kamery je to uplnne husta informace....)

__________________

Registrován: 28.06.2002
Příspěvků: 2325

quote:

Originally posted by Hyvris Datovou strukturu jsme zplodili takovouto: polozky jsou ukonceny znakem CR jako v unixu. GPG: verejny klic emitora (servru ktery primarne informaci o zdroji poskytuje)

technicka poznamka - v UNIXu je zvykem oddelovat radky znakem LF (line feed). Znak CR (carriage return) (diky za opravu Lado) se pouziva spolu s LF v MS DOSu.

__________________

Naposledy upravil oook 29.06.2005 v 11:00

Registrován: 16.06.2003
Příspěvků: 1941

ad vzajemne hledani: Stanovi se treba 5 stejnych adres v kazdem cloudu a na jedne to vzdy pobezi.

Jinak se nedomnivam ze by tento system mel byt propojen z mapovym systemem tohoto portalu.

__________________

Registrován: 31.08.2004
Příspěvků: 14

nestacilo by uplne v pohode, kdyby treba nekdo na http://connected.czf nebo na jine predem stanovene adrese udrzoval seznam v tehlech zdroju napriklad v mysql a exportoval to pres www+php normalne na web?
a jak budou osetreny treba situace, aby se nevyskytly duplicity (treba IDPOLOZKY) soucasne na trech serverech. a na cem to pobezi ldap, mysql nebo uplne neco jineho?

Registrován: 13.05.2004
Příspěvků: 777

Vim ze je to pro UNIXaky netradicni, ale nechteli byste pouzit jako format XML ?
Vyhody:
- snadno se validuje podle schematu
- pole jako Popis svadeji k viceradkovemu textu - potiz u radkove-orientovaneho formatu
- trivialne se resi vicenasobne polozky (e.g. subnety) -- nemusi se vymyslet vhodne oddelovace pro tu-kterou polozku
- XMLka se "jednoduse" transformuji na HTML (XQuery ci XSLT)
- modularita: pri pouziti XML namespaces jde povolit (v definovanych mistech) prakticky libovolne (nepovinne) extenze. Vyhody validace & transformace zustavaji nedotceny.


Ad mySQL vs. textak - textak se krasne verzuje v CVS, cvs commit logger muze rovnou spustit pregenerovani... a navic se da textovy format lepe menit nez relacni schema (sorry, uchylka -- nemam rad db )

Registrován: 16.06.2003
Příspěvků: 1941

quote:

Originally posted by marek_zet nestacilo by uplne v pohode, kdyby treba nekdo na http://connected.czf nebo na jine predem stanovene adrese udrzoval seznam v tehlech zdroju napriklad v mysql a exportoval to pres www+php normalne na web? a jak budou osetreny treba situace, aby se nevyskytly duplicity (treba IDPOLOZKY) soucasne na trech serverech. a na cem to pobezi ldap, mysql nebo uplne neco jineho?

Zakladni pozadavek na tento system je aby byl DECENTRALIZOVANY a nezavisly na jakekoli entite v siti CZFree.Net. Tato distribuovana varianta prinasi mnohe prednosti nez jeden webserver (navic se tento model v praxi neosvedcil). Pokladas vsak duplicitni dotaz, procti si starsi vlakno o CZF4BFU.

Ohledne text x XML jsme se hodne bavili. Treba tu.

__________________

Naposledy upravil =PJ= Azzie 29.06.2005 v 08:59

Registrován: 16.06.2003
Příspěvků: 1941

Chtelo by to zacit neco delat.
Proto jako zakladni bod to chce navrhnout tech 5 defaultnich IP adres pro tuto aplikaci.
Co treba
10.x.0.1
10.x.0.2
10.x.0.63
10.x.0.67
10.x.0.132
(vychazim z CZF-RFC-ADRESSING)

Dalsi bod je aby nekdo napsal ten jednoduchej skriptik ktery bude ty soubory prenaset.

Pak jiz mame v podstate pater hotovou a muze prijit aplikace.

__________________

Registrován: 06.05.2002
Příspěvků: 468

quote:

Originally posted by =PJ= Azzie Chtelo by to zacit neco delat. Proto jako zakladni bod to chce navrhnout tech 5 defaultnich IP adres pro tuto aplikaci. Co treba 10.x.0.1 10.x.0.2 10.x.0.63 10.x.0.67 10.x.0.132 (vychazim z CZF-RFC-ADRESSING) Dalsi bod je aby nekdo napsal ten jednoduchej skriptik ktery bude ty soubory prenaset. Pak jiz mame v podstate pater hotovou a muze prijit aplikace.

Zdar Azzie, navrhuju pro poradek pouzivat pismeno C pro oznaceni cisla cloudu, napr. 14 viz RFC ktere o rezervach rika toto:

code:

Rezervni rozsahy:
Timto rozdelenim zustavaji z adresniho prostoru CLOUDu volne nasledujici
rozsahy:

    * 10.C.0.64/26 & 10.C.0.128/25 (nepouzite adresy z 10.C.0.0/24)
    * 10.C.193-255.0/24 (63 volnych rozsahu velikosti /24)

Tyto muzou byt prideleny NODEum pokud jim z nejakeho opodstatneneho
duvodu nestaci vyse pridelene rozsahy (velky pocet pointu s vlastnimi
sitemi, mnoho provozovanych APcek, nejaky zajimavy projekt vyzadujici
velke mnozstvi IP adres.....)

__________________