Re: [rlug] sistem de fisiere suportat de linux rapid pentru fisiere putine dar mari
sin wrote: Vali Dragnuta wrote: Subscriu la ideea de a folosi raw devices daca aplicatia ta suporta; In ce priveste fisierele mari, reiserul este un pic mai lent (nu atit de mult, totusi); In ce priveste ext3, recomandarea majora este sa ai ups si backup, in rest e ok :) tinand cont de faptu ca in curand o sa trebuiasca sa folosesc si oracle, cu ce e mai bun raw device decat daca as pune ext3 pe discurile unde o sa aiba oracle database-ul ? ma gandesc ca in caz de nevoie, mai usor incerc sa fac recovery de pe ext3 decat de pe raw device, sau gresesc undeva ? Presupunand ca DB-ul nu e brain-dead, in mod normal ar trebui sa fie mai rapid, pentru ca are un nivel mai putin de functii (adica in loc sa treci prin db calls-fs calls-disk calls e direct db calls-disk calls, iar organizarea datelor pe disk ar trebui sa fie cea optima dictata de DBM si nu cea dictata de fs. La partea cu recuperarea insa nu stiu ce se intampla, probabil backup e cuvantul cheie. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] log analizer pentru postfix+amavis+clamav+spamassassin
On Friday 11 August 2006 18:36, Tarhon-Onu Victor wrote: On Fri, 11 Aug 2006, David Williams wrote: nu ia dublurile ? nu conteaza cat de rudimentar este, atat timp cat imi da un output care pot sa il bag in pana la urma in rrdtool logwatch nu are vreun add-on si pentru ampasarea? Ai incercat pflogsumm? Acum mai bine de un an avea oarece probleme legate de simptomul descris de tine ... Poate intre timp s-au corectat! Si mai exista Mailgraph care scuipa datele intr-un rrd (exact ceea ce doresti tu) si din cite stiu, nu mai are probleme in a trata corect dublurile (are si suport pentru amavis) Vezi aici: http://people.ee.ethz.ch/~dws/software/mailgraph/ Alx ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sistem de fisiere suportat de linux rapid pentru fisiere putine dar mari
. La partea cu recuperarea insa nu stiu ce se intampla, probabil backup e cuvantul cheie. Bine, asta oricind e cuvintul cheie :) Dar cred ca cel mai important lucru este ca atit oracle cit si fs-ul au propriile mecanisme de jurnalizare, si nu stiu ce se intimpla atunci cind ambele mecanisme ar incerca sa repare niste inconsistente create de un crash, mai ales ca recovery-ul filesystemului poate incerca sa faca recovery la niste structuri de date pe care in mod normal db-ul le crede in stare buna (jurnalele,spre ex ) In plus, in cazul unui incident major ext3 (sau in ultima instanta orice alt fs) se poate busi atit de nasol incit singura solutie vazuta de fsck ar fi sa arunce niste blocuri ale unui inod sau sa arunce in lost+found inoduri intregi, bineinteles de cele mai multe ori intr-un stadiu de degradare suficient de mare incit sa nu mai ai ce face cu el. Pe de alta parte, in cazul rawdevices, deviceul devine datafile si nimic nu-i poate afecta ordinea si numarul blocurilor componente ca in cazul unui datafile mapat pe un fisier. Drept pt care baza de date ar putea avea mult mai multe sanse sa-si dea seama cum sa faca recovery. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] log analizer pentru postfix+amavis+clamav+spamassassin
On 8/11/06, David Williams [EMAIL PROTECTED] wrote: Am o mica problema cu toate log analyzers care am incercat inafara de sawmill (care trebuie licenta). Problema e ca analizeaza aiurea e-mailurile scanate, adica dublu. Vine mailu il ia amavis si il timite la postfix si in loguri deja apara dublu. Este ceva log analyzer care stie ce face amavis si nu ia dublurile ? nu conteaza cat de rudimentar este, atat timp cat imi da un output care pot sa il bag in pana la urma in rrdtool DW Nu stiu, mane cum e pe hp-ux si juniper, dar la noi la Tartasestii din Deal ne-a invatat sa folosim mailgraph, sau sa folosim syslog_name diferit la a doilea apel de postfix, sau sa ne scriem singuri reguli de logwatch. Petre. PS: Oh, and you were great in Jumanji. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sistem de fisiere suportat de linux rapid pentru fisiere putine dar mari
On Sat, 2006-08-12 at 10:52 +0300, Vali Dragnuta wrote: . La partea cu recuperarea insa nu stiu ce se intampla, probabil backup e cuvantul cheie. Bine, asta oricind e cuvintul cheie :) Dar cred ca cel mai important lucru este ca atit oracle cit si fs-ul au propriile mecanisme de jurnalizare, si nu stiu ce se intimpla atunci cind ambele mecanisme ar incerca sa repare niste inconsistente create de un crash, mai ales ca recovery-ul filesystemului poate incerca sa faca recovery la niste structuri de date pe care in mod normal db-ul le crede in stare buna (jurnalele,spre ex ) In plus, in cazul unui incident major ext3 (sau in ultima instanta orice alt fs) se poate busi atit de nasol incit singura solutie vazuta de fsck ar fi sa arunce niste blocuri ale unui inod sau sa arunce in lost+found inoduri intregi, bineinteles de cele mai multe ori intr-un stadiu de degradare suficient de mare incit sa nu mai ai ce face cu el. Pe de alta parte, in cazul rawdevices, deviceul devine datafile si nimic nu-i poate afecta ordinea si numarul blocurilor componente ca in cazul unui datafile mapat pe un fisier. Drept pt care baza de date ar putea avea mult mai multe sanse sa-si dea seama cum sa faca recovery. PS : daca vrei sa fii super safe, pui si baza de date in archivelog mode, mod in care orice modificare creata in baza de date se si inregistreaza in fisiere-log pe care ulterior le poti aplica pe un backup initial si restaura baza pina la momentul crashului. Arhivele in timp devin destul de mari, insa le poti muta periodic pe o alta masina. Oracle stie chiar si sa le verse direct pe banda, insa nu am incercat niciodata, si s-ar putea sa fie PITA sa setezi treaba asta. Cred ca cel mai safe (cu sau fara raw devices) e sa tii baza in archivelog mode, sa faci periodic un warm total backup (sa zicem o data la o saptamina sau doua) si sa iti pastrezi in permanenta arhivele incepind cu ultimul backup total pina in prezent. In ce priveste dimensiunea arhivelor iti pot da ca exemplu o baza de aprox 80G,cu multe tranzactii, peste 200 useri simultani, a adunat de la 1 august pina in acest moment aprox 20 G de arhive. Numitele arhive precum si backupurile totale periodice se duc catre o alta masina.Ca medie pe zi vad ca aduna cam 2..3 G. Cum backupul total se face saptaminal, teoretic nevoile de storage aditional cu arhivele pt aceasta baza sint cam de 9..12G Si ca sa fii si mai safe, poti sa pui baza de date sa iti verse (transparent) toate arhivele in mai multe locuri simultan :) Daca mai vrei detalii, intreaba-ma pe adresa personala :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
RE: [rlug] log analizer pentru postfix+amavis+clamav+spamassassin
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ratiu Petru Sent: Saturday, 12 August 2006 5:44 PM To: Romanian Linux Users Group Subject: Re: [rlug] log analizer pentru postfix+amavis+clamav+spamassassin On 8/11/06, David Williams [EMAIL PROTECTED] wrote: Am o mica problema cu toate log analyzers care am incercat inafara de sawmill (care trebuie licenta). Problema e ca analizeaza aiurea e-mailurile scanate, adica dublu. Vine mailu il ia amavis si il timite la postfix si in loguri deja apara dublu. Este ceva log analyzer care stie ce face amavis si nu ia dublurile ? nu conteaza cat de rudimentar este, atat timp cat imi da un output care pot sa il bag in pana la urma in rrdtool DW Nu stiu, mane cum e pe hp-ux si juniper, dar la noi la Tartasestii din Deal ne-a invatat sa folosim mailgraph, sau sa folosim syslog_name diferit la a doilea apel de postfix, sau sa ne scriem singuri reguli de logwatch. Petre. PS: Oh, and you were great in Jumanji. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug in primul rand logwatch are aceiasi problema, si mailgraph la fel, mai mult nu este pe HPUX, este pe trustix 3.0 si nu intzeleg ce are Juniper de aface cu asta, oricum dabea asteptai hah ? :) DW ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] log analizer pentru postfix+amavis+clamav+spamassassin
in primul rand logwatch are aceiasi problema, si mailgraph la fel, mai mult nu este pe HPUX, este pe trustix 3.0 si nu intzeleg ce are Juniper de aface cu asta, oricum dabea asteptai hah ? :) 1. mailgraph are --ignore-localhost sau asa ceva (pachetul din debian are o setare in debconf fix pt. amavis). 2. puteai sa te uiti un pic si la ce am zis cu syslog_name, asa poti sa-ti pui direct din syslog sau cu logwatch sau cu orice altceva logurile pre- si post-amavis in locuri diferite. 3. incearca sa nu mai arunci cu cuvinte mari asa in toate partile, doar de dragul de a te da mare, nu toata lumea de aici se da doar pe Linux, dar asta e tema listei, asa ca sa ne limitam la atat, da? 4. http://wiki.lug.ro/mediawiki/index.php/Regulile_listelor_RLUG 5. http://wiki.lug.ro/mediawiki/index.php/Cum_se_pun_intrebari_inteligente Have a nice weekend! -- Linux admins don't piss on their hands ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sistem de fisiere suportat de linux rapid pentru fisiereputine dar mari
Valkai Elod wrote: On Fri, Aug 11, 2006 at 11:25:26PM +1000, David Williams wrote: comentari? DA. Cred ca stii si tu cat de enervant esti, nu? Pornesti thread nou cu reply, ti-e lene sa stergi pasajele irelevante cand dai reply. Fa ceva. lasa-l, ca ori e picardu, ori e AMD-ul in disguise, in ambele cazuri am incurcat-o. PS: do not feed the trolls, please. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sistem de fisiere suportat de linux rapid pentru fisiere putine dar mari
O baza de date oracle se descurca binisor cu recuperarea de date pe raw devices dirty. Si dupa cum spunea co-listasul, exista de asemenea logurile tranzactionale, dar si flash area recovery (prezenta doar in 10g din pacate). nu recomand scrierea de loage direct pe banda din motive de performanta. in schimb un rac te poate scoate din multe belele. --- Original Message --- On Sat, 2006-08-12 at 10:52 +0300, Vali Dragnuta wrote: . La partea cu recuperarea insa nu stiu ce se intampla, probabil backup e cuvantul cheie. Bine, asta oricind e cuvintul cheie :) Dar cred ca cel mai important lucru este ca atit oracle cit si fs-ul au propriile mecanisme de jurnalizare, si nu stiu ce se intimpla atunci cind ambele mecanisme ar incerca sa repare niste inconsistente create de un crash, mai ales ca recovery-ul filesystemului poate incerca sa faca recovery la niste structuri de date pe care in mod normal db-ul le crede in stare buna (jurnalele,spre ex ) In plus, in cazul unui incident major ext3 (sau in ultima instanta orice alt fs) se poate busi atit de nasol incit singura solutie vazuta de fsck ar fi sa arunce niste blocuri ale unui inod sau sa arunce in lost+found inoduri intregi, bineinteles de cele mai multe ori intr-un stadiu de degradare suficient de mare incit sa nu mai ai ce face cu el. Pe de alta parte, in cazul rawdevices, deviceul devine datafile si nimic nu-i poate afecta ordinea si numarul blocurilor componente ca in cazul unui datafile mapat pe un fisier. Drept pt care baza de date ar putea avea mult mai multe sanse sa-si dea seama cum sa faca recovery. PS : daca vrei sa fii super safe, pui si baza de date in archivelog mode, mod in care orice modificare creata in baza de date se si inregistreaza in fisiere-log pe care ulterior le poti aplica pe un backup initial si restaura baza pina la momentul crashului. Arhivele in timp devin destul de mari, insa le poti muta periodic pe o alta masina. Oracle stie chiar si sa le verse direct pe banda, insa nu am incercat niciodata, si s-ar putea sa fie PITA sa setezi treaba asta. Cred ca cel mai safe (cu sau fara raw devices) e sa tii baza in archivelog mode, sa faci periodic un warm total backup (sa zicem o data la o saptamina sau doua) si sa iti pastrezi in permanenta arhivele incepind cu ultimul backup total pina in prezent. In ce priveste dimensiunea arhivelor iti pot da ca exemplu o baza de aprox 80G,cu multe tranzactii, peste 200 useri simultani, a adunat de la 1 august pina in acest moment aprox 20 G de arhive. Numitele arhive precum si backupurile totale periodice se duc catre o alta masina.Ca medie pe zi vad ca aduna cam 2..3 G. Cum backupul total se face saptaminal, teoretic nevoile de storage aditional cu arhivele pt aceasta baza sint cam de 9..12G Si ca sa fii si mai safe, poti sa pui baza de date sa iti verse (transparent) toate arhivele in mai multe locuri simultan :) Daca mai vrei detalii, intreaba-ma pe adresa personala :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sistem de fisiere suportat de linux rapid pentru fisiere putine dar mari
On Fri, 2006-08-11 at 21:52 +0300, sin wrote: Vali Dragnuta wrote: Subscriu la ideea de a folosi raw devices daca aplicatia ta suporta; In ce priveste fisierele mari, reiserul este un pic mai lent (nu atit de mult, totusi); In ce priveste ext3, recomandarea majora este sa ai ups si backup, in rest e ok :) tinand cont de faptu ca in curand o sa trebuiasca sa folosesc si oracle, cu ce e mai bun raw device decat daca as pune ext3 pe discurile unde o sa aiba oracle database-ul ? ma gandesc ca in caz de nevoie, mai usor incerc sa fac recovery de pe ext3 decat de pe raw device, sau gresesc undeva ? Daca e Oracle RAC nu poti folosi ext3, trebuie sa folosesti raw devices sau un cluster file system suportat de Oracle. Un raw device sau raw partition este o partitie care este accesata ca un character device si astfel operatiile I/O se fac direct, fara buffering, si se elimina overhead-ul cauzat de un sistem de fisiere. Pentru Oracle, raw devices prezinta doua avantaje: 1) fiecare operatie de scriere sau citire e mai rapida 2) o parte din memoria folosita pentru file cache poate fi folosita mai eficient de Oracle care face propriul sau caching si propriul sau I/O. Principalul dezavantaj este insa faptul ca administrarea devine mult mai dificila: trebuie sa planifici configuratia cu atentie inca de la inceput, pentru ca e mai dificil sa o schimbi apoi. Multe utilitare ( cp, mv, tar, cpio) nu functioneaza pe raw devices. Din punct de vedere al performantei, daca I/O nu este o sursa de probleme, nu folosi raw devices. Acestea nu reduc numarul de operatii I/O, ci doar le fac mai rapide. În plus, pentru Oracle poti folosi Direct I/O intr-o configuratie care îi permite sa efectueze operatiile I/O pe un sistem de fisiere ext3 fara buffering la nivel OS. -- Catalin Nastase ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
[rlug] cand pornesc HTB pica netul
Salut,
Folosesc kernelul 2.6.15.7 cu suport pt HTB (de fapt toata sectiunea qos),
HTB-tools.0.3.0-beta4 si Mandriva2006. Am 4 placi de retea (3 fizice si una
virtuala) deoarece momentan am 3 clase de IP-uri, dar una dintre clase (eth1)
nu este inca data in folosinta si fac teste pe ea
cum procedez:
iptables -t mangle -N mark_horiz_src
iptables -t mangle -N mark_horiz_dst
iptables -t mangle -A PREROUTING -i eth0 -j mark_horiz_src
iptables -t mangle -A PREROUTING -i eth1 -j mark_horiz_dst
iptables -t mangle -A OUTPUT -o eth0 -j mark_horiz_dst
...
#la sfarsitul fw
/usr/sbin/importbgp
unde importbgp este:
#!/bin/bash
bgp_file=/var/local/ipclasses.bgp
if wget -q --output-document=$bgp_file
http://clienti.evolva.ro/subnets.php?net=all; then
mipclasses -s mark_horiz_src -d mark_horiz_dst -m 1 $bgp_file |
iptables-restore -n
fi
eth0-qos.cfg si eth1-qos.cfg arata astfel:
eth0-qos.cfg
class class_1 {
bandwidth 4096;
limit 4096;
burst 0;
priority 1;
client client1 {
bandwidth 128;
limit 256;
burst 0;
priority 1;
src {
xx.xx.xx.230/32;
};
};
client client2 {
bandwidth 64;
limit 256;
burst 0;
priority 1;
src {
xx.xx.xx.2/32;
};
};
...
client clientX {
bandwidth 128;
limit 128;
burst 0;
priority 1;
src {
xx.xx.xx.90/32;
};
};
class default { bandwidth 8; };
si
eth1-qos.cfg
class class_1 {
bandwidth 4096;
limit 4096;
burst 2;
priority 1;
que sfq;
client client1 {
bandwidth 96;
limit 128;
burst 0;
priority 1;
dst {
xx.xx.xx.230/32;
};
};
client client2 {
bandwidth 96;
limit 128;
burst 0;
priority 1;
dst {
xx.xx.xx.2/32;
};
};
client clientX {
bandwidth 96;
limit 128;
burst 0;
priority 1;
dst {
xx.xx.xx.90/32;
};
};
};
class default { bandwidth 8; };
dar cand pornesc HTB, pica netul...pe toate placile de retea .
[EMAIL PROTECTED] gelu]# /etc/rc.d/init.d/rc.htb start
Starting HTB-tools on eth0 ...
Checking the config file ...OK
Checking kernel support for HTB: present.
HTB-tools was successfuly started on eth0.
Starting HTB-tools on eth1 ...
Checking the config file ...OK
Checking kernel support for HTB: present.
HTB-tools was successfuly started on eth1.
[EMAIL PROTECTED] gelu]# ping www.yahoo.com
[EMAIL PROTECTED] gelu]# /etc/rc.d/init.d/rc.htb stop
Deleting rules for device eth0
Deleting rules for device eth1
[EMAIL PROTECTED] gelu]# ping www.yahoo.com
PING www.yahoo.akadns.net (209.191.93.52) 56(84) bytes of data.
64 bytes from f1.www.vip.mud.yahoo.com (209.191.93.52): icmp_seq=1 ttl=49
time=1
73 ms
64 bytes from f1.www.vip.mud.yahoo.com (209.191.93.52): icmp_seq=2 ttl=49
time=1
72 ms
--- www.yahoo.akadns.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 172.960/173.024/173.088/0.064 ms
Multumesc
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] cand pornesc HTB pica netul
reguli pe masina locala exista?
eg, pachetele generate local trec prin vreo regula htb?
PS: si de ce marchezi pachetele?
--- Original Message ---
Salut,
Folosesc kernelul 2.6.15.7 cu suport pt HTB (de fapt toata
sectiunea qos), HTB-tools.0.3.0-beta4 si Mandriva2006. Am 4
placi de retea (3 fizice si una virtuala) deoarece momentan
am 3 clase de IP-uri, dar una dintre clase (eth1) nu este inca
data in folosinta si fac teste pe ea
cum procedez:
iptables -t mangle -N mark_horiz_src
iptables -t mangle -N mark_horiz_dst
iptables -t mangle -A PREROUTING -i eth0 -j mark_horiz_src
iptables -t mangle -A PREROUTING -i eth1 -j mark_horiz_dst
iptables -t mangle -A OUTPUT -o eth0 -j mark_horiz_dst
...
#la sfarsitul fw
/usr/sbin/importbgp
unde importbgp este:
#!/bin/bash
bgp_file=/var/local/ipclasses.bgp
if wget -q --output-document=$bgp_file
http://clienti.evolva.ro/subnets.php?net=all; then
mipclasses -s mark_horiz_src -d mark_horiz_dst -m 1
$bgp_file | iptables-restore -n
fi
eth0-qos.cfg si eth1-qos.cfg arata astfel:
eth0-qos.cfg
class class_1 {
bandwidth 4096;
limit 4096;
burst 0;
priority 1;
client client1 {
bandwidth 128;
limit 256;
burst 0;
priority 1;
src {
xx.xx.xx.230/32;
};
};
client client2 {
bandwidth 64;
limit 256;
burst 0;
priority 1;
src {
xx.xx.xx.2/32;
};
};
...
client clientX {
bandwidth 128;
limit 128;
burst 0;
priority 1;
src {
xx.xx.xx.90/32;
};
};
class default { bandwidth 8; };
si
eth1-qos.cfg
class class_1 {
bandwidth 4096;
limit 4096;
burst 2;
priority 1;
que sfq;
client client1 {
bandwidth 96;
limit 128;
burst 0;
priority 1;
dst {
xx.xx.xx.230/32;
};
};
client client2 {
bandwidth 96;
limit 128;
burst 0;
priority 1;
dst {
xx.xx.xx.2/32;
};
};
client clientX {
bandwidth 96;
limit 128;
burst 0;
priority 1;
dst {
xx.xx.xx.90/32;
};
};
};
class default { bandwidth 8; };
dar cand pornesc HTB, pica netul...pe toate placile de retea
.
[EMAIL PROTECTED] gelu]# /etc/rc.d/init.d/rc.htb start
Starting HTB-tools on eth0 ...
Checking the config file ...OK
Checking kernel support for HTB: present.
HTB-tools was successfuly started on eth0.
Starting HTB-tools on eth1 ...
Checking the config file ...OK
Checking kernel support for HTB: present.
HTB-tools was successfuly started on eth1.
[EMAIL PROTECTED] gelu]# ping www.yahoo.com
[EMAIL PROTECTED] gelu]# /etc/rc.d/init.d/rc.htb stop
Deleting rules for device eth0
Deleting rules for device eth1
[EMAIL PROTECTED] gelu]# ping www.yahoo.com
PING www.yahoo.akadns.net (209.191.93.52) 56(84) bytes of
data.
64 bytes from f1.www.vip.mud.yahoo.com (209.191.93.52):
icmp_seq=1 ttl=49 time=1
73 ms
64 bytes from f1.www.vip.mud.yahoo.com (209.191.93.52):
icmp_seq=2 ttl=49 time=1
72 ms
--- www.yahoo.akadns.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 172.960/173.024/173.088/0.064 ms
Multumesc
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sistem de fisiere suportat de linux rapid pentru fisiere putine dar mari
Daca e Oracle RAC Nu cred ca vrea rac. Besides, RAC is more hype than real benefit. But this is something else,let's keep it for another day. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] cand pornesc HTB pica netul
mark-ez pachetele pt ca vreau sa fac limitare numai pe extern...si trebuie sa fac diferentierea intr-un fel sau altul metro/extern. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
