Dizzy scria la data de 9 Ianuarie 2006:
> On Thursday 05 January 2006 19:01, Liviu Daia wrote:
> > Dizzy scria la data de 5 Ianuarie 2006:
> > > E cache-er pt mai multe chesiti (nu numai hosturi DNS dar si
> > > username, group-uri, etc). E solutia GNU libc
> >
> > s/GNU libc/SysV/
>
> iar SysV e solutia luata de nu stiu unde.
Nu. SysV e SysV, nu a fost luat de nicaieri.
> Orice chestie desteapta in IT (mai ales in UNIX) are istorie foarte
> lunga, nu are sens sa mergi pe ea.
Iar istoria, nu-i asa, e cu atat mai putin interesanta cu cat e mai
lunga... :-)
> > > pt problema de scalabilitate daca ai multi useri/grupuri in system
> > > si nu ai o baza de date cum are FreeBSD pt ele.
> >
> > Baze de date pentru user-i si grupuri poti avea si sub Linux,
> > configurabil in nsswitch.conf:
>
> Deci poti avea si baze de date cu lookup rapid.
De fapt am gresit eu. Dupa cum am aflat ulterior, suportul pentru
Berkeley DB in NSS (nu insa si referintele la el din manual :-)) a fost
eliminat in glibc 2.2, din motive care tineau de inconsistenta API-ului
diferitelor versiuni ale Sleepycat DB. Asta a eliminat dependenta
bibliotecilor sistem de brain damage-ul Sleepycat DB, si a rezolvat
partial problema "DLL hell" sub Linux. A fost produs si un pachet
separat nss_db, care insa nu se mai compileaza sub versiunile glibc
ulterioare lui 2.2. Maea maxima culpa.
FWIW, pentru cei care au nevoie de ceva mai eficient decat fisiere
chioare pentru passwd si groups sub Linux, exista nss_cdb, in pachetul
tinycdb:
ftp://ftp.corpit.ru/pub/tinycdb/tinycdb_0.75.tar.gz
> Dar si nscd rezolva problema de scalabilitate pt ca iti cachuieste
> acele intrari, nu vad cu ce am gresit in ce am afirmat.
Daca esti in situatia sa ai efectiv nevoie de o baza de date pentru
passwd si groups, nscd-ul va fi de fapt mai putin eficient. In sfarsit,
discutia pornise de la altceva.
> > (1) Nu face caching la resultatele resolver-ului cum vrea omul, ci
> > la hosts si networks configurate in nsswitch.conf. Iarasi util daca
> > le importi prin retea.
>
> La mine face caching cu rezultatele intoarse la gethostbyname() de
> exemplu. Deci ce a cerut omul.
Numai ca exista aplicatii care nu folosesc gethostbyname(3), ci
direct resolver(3). In particular nscd-ul nu are cum sa cache-uiasca
inregistrari DNS care nu sunt de tip A.
> > (2) Crapa.
>
> Il folosesc de cativa ani, inca nu a crapat. Probabil ca crapa in
> configuratiile indicate de tine cu import prin retea de useri.
Nu: nscd este un sistem general de caching, nu il intereseaza de
unde ii vin item-ii care trebuie cache-uiti. Ceea ce, daca stai sa
judeci putin, are foarte mult sens.
> > Nu ai inteles la ce foloseste nscd.
>
> Hmm, poate nu complet (ca nu m-a interesat) dar nu am gresit
> ca am afirmat ca cachuieste intrari DNS. Sa vedem din man
> nscd:
> Nscd provides cacheing for accesses of the passwd(5), group(5), and
> hosts(5) databases through standard libc interfaces, such as getpw?
> nam(3), getpwuid(3), getgrnam(3), getgrgid(3), gethostbyname(3), and
> others.
Nu am afirmat nicaieri ca nscd n-ar face asta.
> In cadrul "hosts database" se considera si DNS daca e
> configurat in nssswitch.conf sa se uite asa cum e by default:
> hosts: files dns
>
> Ca dovada, fa tcpdump -pni eth0 udp port 53 si da un ping la
> www.linux.ro. Ai sa vezi lookup DNS, apoi da din nou si nu ai sa mai
> vezi (evident sa ai /etc/resolv.conf setat cu nameserver ceva remote).
Cum spuneam, nu am negat niciodata asta.
> Cu ce gresesc ?
Pentru ca bati cuie cu microscopul. Adevarat, nscd cache-uieste
unele query-uri catre DNS, dar nu pe toate, si cu siguranta nu pe toate
cele utile. Pentru a cache-ui query-uri DNS foloseste un DNS cache
dedicat, nu un sistem scris pentru a reduce numarul de query-uri locale.
In ziua de azi exista DNS cache-uri rezonabile, nu esti obligat sa umpli
80% din memorie cu Bind-ul.
In scop educativ, iata si la ce e bun nscd-ul. Imagineaza-ti un
sistem care foloseste nss_ldap pentru a importa grupurile dintr-un
server LDAP de pe reteaua locala (acelasi lucru e insa valabil si pentru
NIS, NIS+, nss_mysql si orice alta biblioteca NSS care citeste datele de
pe retea). Mai imagineaza-ti si ca pe masina respectiva ruleaza Apache.
Pentru ca Apache-ul foloseste initgroups(3), de cate ori este
deschis un fisier (de fapt de cate ori este access(3)-at, dar sa nu
ne complicam) intreaga lista de grupuri trebuie sa fie citita, pentru
a afla in care grupuri este membru Apache-ul si a decide astfel daca
acesta are dreptul sau nu sa deschida fisierul respectiv. Lista trebuie
citita de fiecare data pentru ca grupurile se pot modifica in timp ce
Apache-ul ruleaza.
Pentru ca grupurile sunt importate din LDAP, fara nscd fiecare
citire a grupurilor se traduce printr-un query LDAP. Cu nscd
rezultatele sunt cache-uite pentru un (scurt) timp, ceea te scapa de
un flood de query-uri daca Apache-ul trebuie sa deschida multe fisiere
intr-un timp scurt.
Scopul principal al nscd este deci de a cache-ui UID-uri si GID-uri.
Cache-uirea rezultatelor gethostbyname(3) are importanta daca folosesti
domenii NIS sau NIS+, situatie mai putin frecventa astazi.
Salutari,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
