Re: [rlug] inregistrare ip lease in server extern
cred ca poti obtine ce vrei tu cu https://www.consul.io/ On Mon, 2016-03-28 at 12:33 +0300, Adrian Sevcenco wrote: > > Error verifying signature: parse > error > Salut! Subiectul explicit e urmatorul : > Intr-o retea unde nu am controlul asupra dhcp + dns (iar dns-ul oricum > nu are zona interna pentru ip-urile private) as avea nevoie sa > inregistrez undeva ip-ul luat de vm prin dhcp. > Preferinta ar fi ca : > 1. vm-ul sa isi ia ip-ul din aceasta retea privata nu sa fac nat prin > hostul vm-urilor (din diverse considerente am nevoie sa fie toate in > reteaua privata comuna) > 2. sa fie o solutie light, fara pachete aditionale in kickstart daca se > poate (eventual sa fac un POST prin curl? dar nu am idee cum sa fac o > pagina care sa faca asha ceva...) > > Aveti o idee cum se poate face asha ceva? > Multumesc frumos! > Adrian > > > --ms020209000602050109050700-- > ___ > 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] lug.ro server downtime
On Fri, 2016-01-29 at 16:13 +, Nux! wrote: > Mutati-l in claud, sa stiti o treaba. > > ;) > Eu credeam ca e deja in claud: - nu este in debaraua cu muraturi a lui rpetre, asta sigur - merge sau nu merge it's not my problem (tm) - cind nu merge, someone must the needful do. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Raspberry Pi Zero: the $5 computer - Raspberry Pi
Spune sincer, merge angry birds pe el ? :)) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Blocare VPS CentOS
> > Truncate e si mai rapid pt crearea sparse files, dar nu vrei asta la swap, > pentru ca ce castigi ca timp la crearea fisierului pierzi insutit la scrierea > lui de cand ajunge de la 0 la dimensiune maxima. Last time i checked kernelul refuza sa faca swap pe fisiere sparse. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] certificat ssl wildcard
Si eu folosesc startssl comercial si imi iau certificate cu wildcard. Ca sa le poti lua din cite imi amintesc iti trebuie un personal identity validation si ceva company validation. Iti cer niste acte/copii de acte pt astea (factura cu adresa pt personal validation si pt company validation iti cer niste chestii asemanatoare). Pare complicat, dar nu e, de obicei merge repede procesul, iar daca ai probleme raspund repede la mailuri. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] md *NU* continua rebuild dupa reboot
Incorect : A. Debian cere explicit mdadm.conf https://wiki.debian.org/SoftwareRAID Cindva am mai avut discutia asta, s-a reintrodus necesitatea de a avea mdadm.conf pentru un motiv anume, momentan nu gasesc detaliile tehnice, mai caut. B. RHEL/Centos 5 si 6 (nu am testat inca pe 7) RHEL5 cere explicit mdadm.conf, conform documentatiei RHEL6 se comporta astfel : Daca faci array cu metadate 1.x post instalare si nu le treci in mdadm.conf, dupa urmatorul reboot deviceul este detectat drept md127, este inutilizabil si nici nu se sincronizeaza. Arata asa : Personalities : [raid1] md127 : active (auto-read-only) raid1 sdc1[1] sdb1[0] 488252928 blocks super 1.2 [2/2] [UU] resync=PENDING bitmap: 4/4 pages [16KB], 65536KB chunk Conform linkului tau, : Version 1.2 superblocks will not automatically assemble with a numbered device name unless specifically told to do so. There are two way to do this: 1. Pass the --name= option to the mdadm --create command. This will cause the name to be a simple number, and mdadm will assume that you want the array created with that number as the device name. Aka, 0 will get assembled as /dev/md0, 1 as /dev/md1, etc. -> Nu functioneaza 2. Create an ARRAY line in the mdadm.conf file that specifies the uuid of the array and the name you wish the array to have -> asta este fix ca am recomandat eu initial, si functioneaza. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] md *NU* continua rebuild dupa reboot
Probabil ca nu e de fapt activ. Prin alte distributii, dupa ce faci matricea trebuie musai sa produci si /etc/mdadm.conf cu ceva gen mdadm --examine --scan > /etc/mdadm.conf si eventual rebuild de initramfs daca ai. Dupa ce faci asta o sa-ti fie initializat la boot si o sa porneasca reconstructia de unde a ramas. Oricum, numele deviceului de md127 seamana a initializare incompleta la boot => fa-i mdadm.conf. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Cum restartez sunetul pe ub UBUNTU-14.04 64 bits ?
Eh, eu de vreo 5 ani am tot sunetul pe pulse audio si de vreo 4 nu am mai avut vreun issue semnificativ cu pulseaudio. Dimpotriva, face unele lucruri ceva mai simplu de facut. Culmea e ca problema lui este cel mai probabil legata nu de pulse audio care e in ultima instanta doar un wrapper, ci de alsa (poate s-a incarcat alt driver dupa reboot) sau de faptul ca a incercat sa amestece aplicatii configurate explicit sa aleaga alsa in loc de pulse. Pulse face device sharing by default, alsa nu intotdeauna, iar daca ai vreo aplicatie alsa-only pornita inainte de pulse si care si-a facut lock pe deviceurile alsa, nu o sa-ti mai mearga nici alta aplicatie cu alsa si nici pulseaudio. Parerea mea din cel putin ultimele 2 releaseuri ubuntu lts este ca pulse functioneaza destul de ok si nu are sens sa te pisi impotriva vintului dezactivindu-l doar pentru ca "stii tu mai bine". Btw, ce inseamna ca nu merge ? Aplicatiile care vor sa foloseasca sunetul se blocheaza ? Sau par sa trimita date dar nu se aude nimic ? Vezi de asemenea ca in pulse ai si mixer per aplicatie, sa nu-ti fi dat mute pe o aplicatie... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Nu pot instala dictionarul Everest pe un Ubuntu 14.04.3 pe 64 bit
QT este temabil, mi se pare ca daca rulezi qtconfig inainte si alegi o tema mai normala se va reflecta si in aplicatiile care nu-si aleg explicit o tema qt. Doar ca trebuie sa rulezi qtconfig pt versiunea de qt folosita de aplicatia respectiva. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ulei, bere, suc, alte lichide?
Credeam ca pleci in tara corectitudinii politice :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ulei, bere, suc, alte lichide?
Mie mi-ar conveni acolo, e foarte aproape de birou, numa' bine. Doar nu ploua chiar atunci.Si chiar si daca ploua, macar nu e fum. On Mon, 2015-08-17 at 11:58 +0300, Petru Rațiu wrote: 2015-08-17 11:55 GMT+03:00 Bogdan-Stefan Rotariu bog...@rotariu.ro: ce ziceti de locatia http://restaurant.hoteldiesel.ro/en/contact/ http://restaurant.hoteldiesel.ro/en/contact/ ? Este la lac, aer curat :), poate acomoda mese mari, locuri de parcare si evident bere E fain acolo, am mai fost, dar nu stiu daca au loc inauntru in caz ca ploua. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ulei, bere, suc, alte lichide?
Aproape de Primaverii mi se pare foarte in Bucuresti. Da' daca vrei putem incerca si ceva in Berceni. Sau Ferentari. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] bash fork process separat
#!/bin/sh ( gzip bigfile /dev/null 2/dev/null ) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] rich man / poot man d.f.s
1.Daca excluzi java doar pentru ca java atunci esti mai tut decit pari. 2.Am testat si eu si ceph si gluster, la fiecare am gasit cite ceva care m-a oprit (deocamdata) sa implementez mai departe. For the record eu caut pentru a tine volume de masini virtuale pe ele. Gluster is getting there, but still no cigar.La gluster spre exemplu un issue era ca writerul (clientul) scria simultan ambele copii ale datelor (adica daca ai un volum cu o replica, in momentul in care scrii ceva scrii in 2 locuri simultan, injumatatind performanta de scriere pt ca banda e in general limitata. Intr-o oarecare masura, depinzind si de hardware poti compensa cu interface bonding. Implementari viitoare de glusterfs vor avea un mecanism ceva mai elegant in care scrii catre un nod si nodul la rindul sau propaga datele catre o replica. 3. Nu am apucat inca sa testez asta, poate in perioada urmatoare. https://en.wikipedia.org/wiki/BeeGFS ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sf-uri php
Poti pastra interfata dintre client si tine sincrona pina la un anumit punct, iar in spate faci tot asincron. Important e ca partea sincrona sa o faci cit mai light in asa fel incit sa-ti permiti sa tii un numar foarte mare de clienti cu un request sincron in asteptare fara ca tu sa blochezi prea multe resurse facind asta. Ceva de genul : [client] -(sincron)- [php1] ...(asincron)...[php2 ] |[cache] Clientul face requesturi sincrone catre un php1 care trebuie sa fie cit mai eficient in asa fel incit chiar si cu un numar mare de requesturi active sa ai impact foarte mic. Backendul asta verifica daca ai sau nu rezultatul intr-un cache (care poate fi un sistem dedicat, iclusiv ceva nosql in-memory daca vrei) iar daca nu-l gaseste submiteaza mai departe requestul intr-o coada pentru backendul2, heavy. Dupa care sta, cu clientul initial agatat. Intrucit nu faci alta procesare memofaga in php1, ar trebui sa poti tine un numar relativ mare de requesturi active simultan. Dpdv al clientului, este in continuare o procesare sincrona. Din momentul asta, php1 face polls (operatie relativ ieftina) in coada sa vada daca i s-a rezolvat requestul de catre un backend. In fine, in php2 preiei requesturi din coada si le procesezi intr-un ritm ales de tine (nu mai mult de N in paralel, cu N stabilit in functie de ce resurse ai la dispozitie). Pe masura ce requesturile sint rezolvate, le marchezi in coada ca procesata si le pui rezultatul ce va fi preluat de php1 si dat clientului. In felul asta, poti si jongla mai usor cu un numar variabil de backenduri levell1 sau level2 ca sa poti adauga/scoate dinamic in functie de nevoi. (adica poti adauga in perioade de virf mai multe php2 ca sa-ti proceseze mai repede din coada de procesare) Coada si cacheul pot fi entitati diferite sau pot reprezenta aceeasi entitate. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] sf-uri php
Rght. In assembler eventual. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] filesystem pentru disk cache / lru
In cel mai rau caz poate sa configureze/modifice aplicatiile in cauza sa puna datele in directoare dinamice astfel incit sa nu ai jdemii de fisiere in acelasi director. De exemplu ar putea sa aiba cache_location=/mnt/cache/$(date +)%Y%m%d)/ Sau pornind de la timpul de validitate necesar pt obiectele din cache poate sa se asigure ca le sterge mereu pe alea mai vechi (astfel incit sa nu apuci niciodata sa aduni prea multe in locul ala). Sau sa intermediezi locatia printr-un symlink pe care il schimbi periodic samd. Ma rog,propunerea e un pic far fetched pt ca el nu a spus ce aplicatii sint alea si in ce masura se poate sau nu interveni in ele. Foarte de acord cu sugestia primita anterior ca mai bine expune X-ul. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] secure voip pentru ~10 oameni
On Sat, 2015-02-14 at 19:50 +0200, Alexandru Balan wrote: Multam la amandoi (daca mai are cineva vreo sugestie sau material, nu ezitati). M-am gandit la un VPN ca solutie pentru problemele cu apeluri din 3G dar nu e fezabil ca usability. Nu pot sa-i pun pe toti sa stea tot timpul cu vpn-ul pornit catre mine. Altfel, m-ar ajuta foarte mult niste sugestii de clienti (iOS, Android, Blackberry). Ori SIP ori Jabber. Si de ce nu ? Nemaipunind la socoteala ca poti sa ai vpn activ nonstop dar trimiti prin el doar o parte din trafic,cel cu resursele private (ii dai doar niste rute specifice nu default route) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] VMware esxi si centos
Vezi ca exista destule loguri, atit ale hypervisorului cit si per VM cu care ai putea incerca sa vezi ce s-a intimplat. Vezi tab-ul events la fiecare VM sau la nivel de host.Vezi properties pe storage-ul vazut de hypervisor, vezi daca apare ceva ciudat acolo. Fa un efort, vmware e destul de clica clica asa, trebuie doar sa cauti putin prin el :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Tomato/OpenWRT reset conexiune TCP activă
a). vezi si tcpkill din dsniff b). poti sa adaugi temporar inainte de regula care face match pe ESTABLISHED reguli noi care sa faca match pe sursa si destinatia conexiunii active si sa dea REJECT c). dupa ce schimbi regulile de acces faci flush pe toata tabela de connection tracking sau individual pe flowurile care te deranjeaza. man conntrack, vezi --delete c) este solutia cea mai eleganta. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Tomato/OpenWRT reset conexiune TCP activă
Esti sigur ca nu exista deja pachet ? https://dev.openwrt.org/browser/trunk/package/network/utils/conntrack-tools/Makefile?rev=33701 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] java cacat
1.Ce ai patit tu e o problema care nu isi are originea doar in java. Pe de-o parte, din cauza unor buguri mai vechi in java care s-au lasat cu ceva 0-days cu oarece succes, browserele au inceput sa chitzaie daca te prind cu jre-uri mai vechi si pe care le considera nesigure. Din cauza asta nu poti sa-ti folosesti java mai veche cu care toolurile de administrare functionau. Nu am cautat, dar e posibil sa existe in browserul tau preferat ceva setare hidden - sau alternativ un plugin - care sa inhibe warningul pentru jre vechi -permitindu-ti astfel sa folosesti un jre convenabil scopului tau; 2.A doua problema este ca de la versiuni de java ceva mai noi, runtimeul verifica daca appletul/codul pe care vrei sa-l rulezi este semnat. Daca este semnat si certificatul poate fi validat, atunci va functiona totul as expected, daca nu atunci in functie de setari ori blocheaza cu totul appletul ORI ii restrictioneaza accesul, spre exemplu nu-i da voie sa deschida socketi - ceea ce probabil ti se intimpla tie. Ai ori alternativa de a whitelista fiecare site la care te conectezi si sa-l declari ca trusted, SAU (si asta mi se pare mai elegant) sa iti importi certificatele toolurilor de administrare pe toate statiile de la care folosesti consola aia de administrare. Deployment automat de certificate poti face in ziua de astazi destul de lejer. Java va valida certificatele prezentate si contra listei de CA-uri din sistemul de operare.Poti in principiu sa-ti faci un bundle de certificate pe care sa-l poti instala automat pe toate statiile relevanta. 3. A treia potentiala problema este data de incompatibilitati inevitabile intre versiuni. Daca consola ta a fost initial facuta sa functioneze cu java 1.5 si intre timp tu incerci sa rulezi cu 1.8 sint ceva sanse ca unele clase, unele interfete sa se fi obsoletat si cum e normal sa nu mai functioneze pe versiuni noi. In fine, as putea sa-ti sugerez sa-ti instalezi intr-o locatie alternativa o versiune mai veche de browser + javele aferente astfel incit pentru administrarea acelor tooluri sa folosesti doar comboul de browser mai vechi + jre mai vechi. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Migrare statii de lucru Office catre Linux
Dupa prima amenda isi vor schimba brusc viziunea asupra lumii. E suficient un fost angajat suparat sa dea o sesizare anonima la BSA friends, sa vezi ce repede vin controalele. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Migrare statii de lucru Office catre Linux
On Fri, 2014-11-14 at 16:51 +0200, Petru Ratiu wrote: 2014-11-14 16:50 GMT+02:00 Vali Dragnuta vali.dragn...@inode.ro: Dupa prima amenda isi vor schimba brusc viziunea asupra lumii. E suficient un fost angajat suparat sa dea o sesizare anonima la BSA friends, sa vezi ce repede vin controalele. De ce fost daca e anonima? Din experienta mea anterioara, cine vrea sa se razbune o face doar dupa ce s-a pus la adapost si a plecat din locul respectiv. Sau uneori motivul razbunarii este chiar faptul ca a fost fortat sa plece. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Migrare statii de lucru Office catre Linux
Ai fi surprins, nu mai e chiar asa cum crezi tu. Asta si din cauza ca in special firmele mici si mijlocii sint ceva mai limitate financiar si nu isi permit sa plateasca atita banet pe licente de office. Cred ca nici nu e cazul sa discutam aici de aceia care instaleaza office la liber pentru ca nu-i controleaza nimeni, ia sa-i pui sa cumpere licente si sa vezi pe urma cum isi pun problema da' totusi de ce nu incercam sa folosim de sus pina jos altceva.Vorbim de cei care vor sa stea in limitele legale. Kingsoft office nu pare a fi freeware pentru utilizare comerciala. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Migrare statii de lucru Office catre Linux
http://products.office.com/en-us/business/compare-office-365-for-business-plans La 10 dolari/luna per utilizator zic ca este destul de decent. Pai ala vad ca e online, nu-ti da decit maxim 5 instalari locale pe statii. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Migrare statii de lucru Office catre Linux
On Fri, 2014-11-14 at 01:28 +0200, Eugeniu Patrascu wrote: 2014-11-14 1:25 GMT+02:00 Vali Dragnuta vali.dragn...@inode.ro: http://products.office.com/en-us/business/compare-office-365-for-business-plans La 10 dolari/luna per utilizator zic ca este destul de decent. Pai ala vad ca e online, nu-ti da decit maxim 5 instalari locale pe statii. Each user can install Office on 5 PCs or Macs, 5 Windows tablets or iPads, and 5 phones. Chiar si asa, pt o firma de 30 de oameni 10*30*12=3600$/an poate fi o suma considerabila. Excluzind serviciile colaterale,pentru o utilizare estimata de peste 30 zile tot mai convenabil este sa-ti iei licente homebusiness pt fiecare utilizator, cu dezavantajul ca nu beneficiezi de versiuni mai noi si ca sa faci upgrade trebuie sa platesti din nou, probabil cam la fiecare 3..4 ani. Cind incepi sa aduni toate taxele de protectie ms ajungi la niste sume considerabile care se simt pe bugetele multianuale. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Lentoare RHEL7
Cred ca pentru o evaluare obiectiva ar trebui sa mai testezi si altceva pentru a stabili daca versiunea de python din el7 este mai lenta sau tot sistemul. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Bash Bug - centos 4
sursele sint disponibile CLIENTILOR. licenta nu cere sa fie date intregului univers :) Ok, dar in cazul asta licenta permite celui ce primeste sursele sa le redistribuie in mod legal: Any licensee who adheres to the terms and conditions is given permission to modify the work, as well as to copy and redistribute the work or any derivative version. The licensee is allowed to charge a fee for this service, or do this free of charge. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Bash Bug - centos 4
On Fri, 2014-09-26 at 17:46 +0300, manuel lonely wolf wolfshant wrote: On 09/26/2014 05:13 PM, Andrei Pascal wrote: Deci nici sursele nu mai e la liber?... Sursele pt RHEL 5 si 6 sint in continuare disponibile la ftp.redhat.com , ca intotdeauna. Cele pt 7 sint furnizate prin intermediul git.centos.org ( cineva de la RH face push initial ; cei din CentOS sintem doar consumatori ale acestor versiuni) Sursele pt variantele Extended Support nu au fost niciodata puse la dispozitie altora decit celor cu abonament. De aceea nici nu exista suport in CentOS pentru minor release X.N-1 odata ce a aparut versiunea X.N. Nu avem cum sa mai mentinem/garantam compatibilitatea cu ceea ce furnizeaza in continuare RH in cadrul Extended Support. Dar updateurile din Extended Support nu se constituie in modificari ale surselor initiale care au licenta GPL ? Legal vorbind, aceste surse nu ar trebui sa fie disponibile, daca nu din initiativa RH atunci cel putin la cererea unui client ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] metoda backup imagine OS
Sigur, pentru userul de windows tip tuta bacula este cea mai buna si usor de folosit solutie... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ip public
Nu are nevoie de proxy arp, e suficient sa-si puna ruta statica spre al doilea ip prin interfata legata in segentul la care a conectat al doilea IP. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ip public
Tot ce se poate deși mi s-ar părea ciudat ca routerul să răspundă la arp request pentru un ip pe care nu-l are pe nici o interfată, doar pentru că are rută către el. Depinde cum ti-a fost alocat de provider : daca ti-a alocat un alt ip din acelasi subnet cu cel direct conectat, ai dreptate. Daca de fapt ai un ip direct conectat si un subnet pe care providerul il routeaza prin adresa ta ip primara(adica are si el o ruta) atunci nu e nevoie. A se observa ca cele 2 adrese mentionate nu par sa faca parte din acelasi subnet, asa ca providerul are sigur la rindul sau in tabela de routare o ruta catre 86.200.200.200 via 86.100.100.100 Asa ca routerul providerului o sa faca arp lookup pentru 86.100.100.100 apoi o sa trimita pachetele pentru 86.200.200.200 catre adresa ethernet a lui 86.100.100.100 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ip public
Dacă providerul îi rutează 86.200.200.200 prin 86.100.100.100 atunci problema este banală si clasică, eu am înțeles că, totuși, 86.100.100.100 și 86.200.200.200, deși probabil din subneturi diferite, sunt în acelasi domeniu de broadcast, practic am înțeles că, într-un switch providerul i-a mai alocat un port și i-a mai dat un IP (de altfel se înțelege din emailul initial că a primit câte un gateway pentru fiecare ip). Mai mult, de obicei dacă un provider vrea să ruteze prin ip-ul tau alt ip atunci îți va da cel putin un /30 nu un /32. 1. daca cele doua adrese alocate s-ar afla in acelasi domeniu de broadcast dar cu subneturi diferite ar trebui sa fi primit si un default gateway + subnet mask pentru cel de-al doilea ip, si nu a primit. asa ca most likely se afla chiar in situatia 2. ... in care are probabil un subnet foarte mic routat prin celalalt ip. Nu ca ar fi relevant daca e /30 sau /32, providerul face configurarea aproximativ la fel. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ip public
On Tue, 2014-04-29 at 15:00 +0300, Ionut Matei wrote: Scuze, dar nu primesc e-mail-uri de la lista si nu am la ce da reply. Am doua ip-uri din clase diferite, am ceva de genul urmator: ip router 86.100.100.100 ip nou 86.200.200.200 Ip-urile sunt statice si le introduce manual, nu le primesc prin dhcp, iar gateway-urile sunt diferite. Nu vreau sa folosesc ambele ip-uri pe server, vreau sa-l folosesc pe primul ca pana acum, iar pe al doilea sa il folosesc pe un alt calculator. Nu am incercat varianta cu ambele intr-un switch inainte de router. Merci Sint mai multe posibilitati : Varianta 1. Daca pe router ai : interfata catre provider eth0, cu adresa 86.100.100.100 interfata catre reteaua interna eth1 cu adresa 192.168.0.1 Masinile din reteaua interna ar fi 192.168.0.2192.168.0.254 avind ca default gateway 192.168.0.1 Acum, pentru a da unei alte masini un ip public ar fi preferabil sa ai un alt segment de retea separat de cel privat, dar eliminind aceasta restrictie uite cum poti sa faci : Presupunem ca ai deja pe segmentul intern masina 192.168.0.10 pe care vrei sa o publici pe adresa 86.200.200.200 Atunci, vei configura pe interfata acestei masini adresa aditionala (86.200.200.200) cu netmaskul corespunzator. Vei avea deci ceva gen : eth0192.168.0.10/24 eth0:1 86.200.200.200/ce netmask ti-a dat providerul Ruta default ar trebui sa fie prin 192.168.0.1 (ca inainte) dar pentru ca sa ai conexiunile spre exterior realizate de aceasta masina sa se faca dinspre adresa publica, probabil ar trebui sa ai ruta setata asa : ip ro add default via 192.168.0.1 src 86.200.200.200 (daca omiti partea cu src pachetele vor pleca de la prima interfata, cea privata, si desi vei avea conectivitate pentru ca routerul va face in continuare nat pentru clasa interna, probabil vrei totusi sa ai conexiunile initiate cu adresa nou alocata) Pe router vei adauga o ruta statica permanenta : ip ro add 86.200.200.200 dev eth1 scope link Pentru a permanentiza rutele setate ca mai sus, sint conventii diferite pt fiecare distributie. De exemplu, pe rhel/centos faci un fisier /etc/sysconfig/network-scripts/route-ethX in care iti vei pune rutele customizate ce vor fi aplicate pe interfata ethX dupa ce a fost ridicata. Pe debian/ubuntu o varianta simpla e sa adaugi o linie gen up ip ro add . la sfirsitul definitiei interfetei Pe router sa nu uit sa ai regula care sa permita traficul spre noua adresa publica, la minim iptables -A/-I FORWARD -d 86.200.200.200 -j ACCEPT si eventual iptables -A/-I FORWARD -s 86.200.200.200 -j ACCEPT Varianta 2: ar fi sa faci pe router NAT all the way astfel incit orice iti vine din exterior spre destinatia 86.200.200.200 sa fie dus mai departe (dnat) in interior catre 192.168.0.10 , si in plus orice vine dinspre 192.168.0.10 spre exterior sa aiba snat si sa para ca vin dinspre 86.200.200.200 Reiterez sugestia ca e preferabil sa ai masinile cu adresa ip publica sa le pui in alt segment de retea. Ai grija si cu firewallul, e usor sa te pacalesti. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Clona hdd
Da, e posibil sa nu-ti incarce driverul pentru controllerul sata . Probabil trebuie sa adaugi in /etc/modprobe.conf linii gen : alias scsi_hostadapter2 ata_piix alias scsi_hostadapter3 ahci sau ce controller ai tu in sistem. Pe urma trebuie refacut initrd si bootat din nou. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Clona hdd
Pai teoretic asta se intimpla, probabil in initrd incarca driverul pentru vechiul controller raid, poate si pentru ata_piix dar nu pentru ahci care probabil e necesar pentru un hardware mai recent. Drept pt care nu-ti vede deloc discurile, iar lvm nici nu are pe ce discuri fizice sa-si caute metadatele. Copia ta este bit cu bit, dar hardwareul nu este, asa ca trebuie sa iti adaugi driverul in initrd cum ti s-a spus. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] NAS cu consum rezonabil
Nu inteleg ce tot va aberati cu pi-ul, performanta pe care o poti scoate din el pus pe post de storage este groaznica. Cu sau fara hub usb atit discurile cit si traficul de retea vor trece prin acelasi bus usb de pe raspberry pi. Mai mult, pentru ca usb2 este semnificativ mai ineficient la transferurile intre cpu si periferice, orice activitate sustinuta pe busul usb se reflecta in cpu usage foarte mare, iar pi-ul nici la cpu nu sta extraordinar. Una peste alta, pentru citi bani dai pe un raspberry pi + un hub usb + carcasa pt hard disc usb daca nu o ai deja + carcasa pentru raspberry pi + sursa pentru pi + sursa pt usb hub iti iei cel mai ieftin NAS de 3.4 mil care are sanse sa suporte o rata de transfer mai mare. Acum, daca vreti musai sa mergeti pe varianta diy puteti face asta, dar mergeti pe o platforma mai performanta (ex cubieboard care are deja sata onboard + ethernet corespunzator). Lasati prostiile cu raspberri pi - ala poate fi bun pentru multe lucruri dar nu pentru asta. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Delivery Status Notification (Delay)
Blacklistul este pentru IP-ul SMTP-ului, nu pentru sender. Cum ti s-a spus deja, esti victima colaterala faptului ca altcineva a trimis spam din gmail si s-a intimplat sa trimita cu aceleasi smtp-uri care te-au deservit pe tine cind ai trimis mesajul tau cuminte. Acel smtp ajunsese sa fie deja inregistrat cu probleme in blacklisturi in momentul in care ti-a trimis si tie mesajul, drept pt care deja incepusera sa-i fie refuzate mesajele trimise. On Sun, 2014-04-06 at 20:15 +0300, Abibula Aygun wrote: Pai pentru ce ? Nu am facut decat sa scriu pe lista si sa intreb omul daca a gasit o rezolvare la situatie. Nu am facut SPAM , sa trimit mesaje una dupa alta . etc etc . Virusi nu am ! Intrebarea era , ce ii veni lui Google sa faca traznaia asta ? On Sun, Apr 6, 2014 at 5:31 PM, manuel lonely wolf wolfshant wo...@prolinux.ro wrote: On 04/06/2014 11:08 AM, Abibula Aygun wrote: Alo , RLUG - WTF is this? conform cu THIS IS A WARNING MESSAGE ONLY. , e un avetisment Dau un mail si google ma notifica de ceva SPAM. The error that the other server returned was: 554 5.7.1 Service unavailable; Client host [209.85.217.176] blocked using bl.spamcop.net; Blocked - seehttp:// www.spamcop.net/bl.shtml?209.85.217.176 Si care parte din see http://www.spamcop.net/bl.shtml?209.85.217.176; ti-a fost neclara ? ___ 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 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] limitari rsync
2. un rsync de tip pull (trag de la sursa de pe destinatie), dar comanda este pornita de un eveniment de pe sursa (de genul: s-a terminat o comanda pe sursa - stiu eu, un dump de baze de date sa zicem, sau s-au terminat niste procesari care nu se stie cat dureaza, am verde la initierea rsync-ului) mecanismul de push_server pe care l-ai precizat ar fi o solutie ok pentru problema emisa, nu neaparat cea mai buna (pentru ca nu poti controla direct ce se intampla spre destinatie); spre exemplu ai 50 de servere, daca toate triggereaza rsync-ul in acelasi timp ai cam pus-o de mamaliga; dar pe de alta parte poti sa setezi niste flag-uri de pe sursa pe destinatie (gen pus un fisier prin ssh, pus ceva intr-o baza de date, etc.), si poti manageui mai bine sincronizarea dintr-un singur loc, pentru ca de fapt ceea ce ardea era momentul in care am verde sa pot face sincronizarea Varianta 1, cum cred ca s-a mai zis, faci poll. Nu e o mare tragedie ca sa faci de pe destinatie : ssh gigi@sursa_de_fisiere test -f /cale/catre/fisierul_asteptat rsync gigi@sursa_de_fisiere /cale/catre /mybackup Impactul ca performanta as zice ca e minimal, si poti sa faci asta intr-o bucla ca sa verifici fiecare sursa pe rind. Exista chiar niste tooluri cu care poti executa in paralel o suita de comenzi pe mai multe masini, eventual cu un grad de paralelism configurat, daca nu vrei sa faci tu manual un script care cicleaza printre toate masinile si vrei si un anume grad de paralelism. Varianta 2,daca astepti un numar limitat de fisiere produse de o aplicatie pe care o controlezi, atunci fa aplicatia sa genereze initial fisierele in /cale/secreta/ apoi la sfirsit redenumeste /cale/secreta in /cale/catre pt ca urmatorul rsync sa gaseasca directorul populat. De asemenea, nu ai spus pe cine vrei sa limitezi. In schema ta care resursa (sursele sau destinatia) sint mai sensibile si le vrei protejate de eventualul comportament eronal al celeilalte parti ? Vrei sa protejezi sursele de fisiere de eventuale probleme venite dinspre destinatie sau vrei sa protejezi destinatia (backup server ?) de eventuale surse compromise ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mdadm chunk size
De-aia ai optiunea sa modifici tu chunk size la ceva mai potrivit. Vezi insa ca daca-l faci prea mic o sa simti ca va merge mult mai prost. Stiu ca eu am testat la un moment dat si pe implementari hardware si software si daca faci chunk size prea mic performanta se degradeaza semnificativ, in special la transferuri mai mari. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mdadm chunk size
Ce hard disk are blocksize de 1M ? On Thu, 2013-12-19 at 21:07 +0200, Petru Ratiu wrote: Atata timp cat storage-ul de sub el are 1MB sau mai mult blocksize-ul, nu te ajuta la nimic sa-l micsorezi. On Dec 19, 2013 8:07 PM, Alex 'CAVE' Cernat c...@cernat.ro wrote: Salut Am văzut ca by default mdadm-ul creeaza array-urile cu un chunk/stripe size de 512k, ceea ce mi se pare enorm, având în vedere ca mai mult se creeaza directoare pe acel device. Practic orice creare de link înseamnă scriere în director, deci multe scrieri marunte, pe care din câte ştiu le optimizeaza fs -ul cât poate, dar nu cred ca destul. Ca idee, snapshoturi cu rsync şi cp -al, partitie XFS. Comentarii şi idei? Ca pe net parerile sunt destul de impartite Alex ___ 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 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Intalnirile RLUG - reboot
Ai putea sa te inscrii sa-l prezinti... Iar daca-l faci si opensource ar fi chiar si mai apreciat :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Mam ce nazist esti... BINEINTELES ca am vrut sa scriu iti detecteaza maxim un bit eronat, da' m-a luat graba la vale si am scris gresit. Cred ca toata lumea a inteles ce vroiam sa spun :P On Sun, 2013-11-17 at 06:54 +0200, tiberiu socaciu wrote: --- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza maxim un bit corect. hmm. puneti mana pe teorie si (re)cititi capitolul coduri detectoare si corectoare de erori. bitul de paritate poate DETECTA doar 1 bit eronat. t. 2013/11/16 Vali Dragnuta vali.dragn...@inode.ro On Fri, 2013-11-15 at 17:25 +, Dan Borlovan wrote: Io nu sint in clar cu o chestie hdd-ul are ECC (si da il foloseste). Nu stiu daca memoria cache de pe hdd e si ea macar cu bit de paritate, dar de pe platane erorile de citire sint detectate (si in masura posibilitatilor corectate) --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este acel ECC (16bit, 32 bit...ce algoritm...) sata are si el ceva crc, ca si sirmele de firma pot avea probleme (asta ca sa nu ma leg de ingeniosul care a proiectat mufele, care ies afara numai cind te uiti la ele) --- Da memoria dintr-un server e ecc --- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza maxim un bit corect. Tocmai am o masina care logeaza erori de paritate pe un anume bank de memorie si totusi crapa frecvent. Presupun ca dimm-ul e atit de stricat incit inregistreaza deseori coruptii dincolo de bitul corectat de paritate. Shit can happen, easily. BTW, de ce crezi ca sint masini care nu numai ca folosesc memorii ECC, dar au posibilitatea sa implementeze si mirroring de memorie ? Pentru ca uneori e nevoie de mai mult. http://h18000.www1.hp.com/products/servers/technology/memoryprotection.html nu stiu memoria cache din controller-ul raid, cel putin unele folosesc memorii simple de pc, dar la cele profi ma astept sa aiba si ele ecc pe ethernet avem si acolo checksum-uri --- Sigur. Dar sint sigur ca stii ca avem ecc in frame-ul ethernet dar avem si checksum (doar pt header,ce-i drept) in header-ul IP si mai avem si in TCP...Pentru ca e clar ca nu doar procesul de transmitere poate provoca erorile ci si eventual procesul de transmisie poate genera erori ci si softwareul prin care trece intre transmisii :) Si atunci, exceptind cazuri extreme - de coruptie intre doua medii de transfer (gen bug in fw la controllerul raid sau hdd care nu onoreaza un flush de cache) - modificari care trec de suma de control (ca nah orice algoritm de suma de control mai scurta decit datele respective va avea coliziuni - cazuri de erori nedetectate) de unde naiba atitea silent data corruption? --- Sigur, nu zice nimeni ca sint asa frecvente - probabil ca cu cit ai hardware mai scump cu atit mai putine erori ai. Da' guess what, de multe ori hardwareul mai scump isi are rezilienta fix in mecanisme de detectie si corectie a erorilor suplimentare (vezi memory mirroring de mai sus). Am avut masini care erau rebootate normal (deci nu datorita unui crash!) dupa ~180 zile de uptime si fsck.ext3 full gasea mereu si corecta diverse erori minore, in ciuda faptului ca masina nu a avut intreruperi bruste, nu avea probleme cu memoriile etc. De unde ? Probabil ca si de la software bugs si alti factori, daca mai cauti online vei mai gasi diverse referinte. Cert e ca cu cit volumele de date pe care le avem sint mai mari, cu atit probabilitatea de a intilni aceste erori este mai mare. ___ 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 ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Fri, 2013-11-15 at 17:25 +, Dan Borlovan wrote: Io nu sint in clar cu o chestie hdd-ul are ECC (si da il foloseste). Nu stiu daca memoria cache de pe hdd e si ea macar cu bit de paritate, dar de pe platane erorile de citire sint detectate (si in masura posibilitatilor corectate) --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este acel ECC (16bit, 32 bit...ce algoritm...) sata are si el ceva crc, ca si sirmele de firma pot avea probleme (asta ca sa nu ma leg de ingeniosul care a proiectat mufele, care ies afara numai cind te uiti la ele) --- Da memoria dintr-un server e ecc --- Mai exact, de obicei ai paritate, ceea ce inseamna ca-ti corecteaza maxim un bit corect. Tocmai am o masina care logeaza erori de paritate pe un anume bank de memorie si totusi crapa frecvent. Presupun ca dimm-ul e atit de stricat incit inregistreaza deseori coruptii dincolo de bitul corectat de paritate. Shit can happen, easily. BTW, de ce crezi ca sint masini care nu numai ca folosesc memorii ECC, dar au posibilitatea sa implementeze si mirroring de memorie ? Pentru ca uneori e nevoie de mai mult. http://h18000.www1.hp.com/products/servers/technology/memoryprotection.html nu stiu memoria cache din controller-ul raid, cel putin unele folosesc memorii simple de pc, dar la cele profi ma astept sa aiba si ele ecc pe ethernet avem si acolo checksum-uri --- Sigur. Dar sint sigur ca stii ca avem ecc in frame-ul ethernet dar avem si checksum (doar pt header,ce-i drept) in header-ul IP si mai avem si in TCP...Pentru ca e clar ca nu doar procesul de transmitere poate provoca erorile ci si eventual procesul de transmisie poate genera erori ci si softwareul prin care trece intre transmisii :) Si atunci, exceptind cazuri extreme - de coruptie intre doua medii de transfer (gen bug in fw la controllerul raid sau hdd care nu onoreaza un flush de cache) - modificari care trec de suma de control (ca nah orice algoritm de suma de control mai scurta decit datele respective va avea coliziuni - cazuri de erori nedetectate) de unde naiba atitea silent data corruption? --- Sigur, nu zice nimeni ca sint asa frecvente - probabil ca cu cit ai hardware mai scump cu atit mai putine erori ai. Da' guess what, de multe ori hardwareul mai scump isi are rezilienta fix in mecanisme de detectie si corectie a erorilor suplimentare (vezi memory mirroring de mai sus). Am avut masini care erau rebootate normal (deci nu datorita unui crash!) dupa ~180 zile de uptime si fsck.ext3 full gasea mereu si corecta diverse erori minore, in ciuda faptului ca masina nu a avut intreruperi bruste, nu avea probleme cu memoriile etc. De unde ? Probabil ca si de la software bugs si alti factori, daca mai cauti online vei mai gasi diverse referinte. Cert e ca cu cit volumele de date pe care le avem sint mai mari, cu atit probabilitatea de a intilni aceste erori este mai mare. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 12:23 +, Dan Borlovan wrote: --- Prespunind ca ajunge corect acolo.Oricum, nu stim cit de bun este acel ECC (16bit, 32 bit...ce algoritm…) La mediile magnetice sau optice iti trebe un ecc destul de serios. Mai ales la densitatea de informatie de acuma (c'mon, 6TB intr-un singur hdd cu 7 platane… in alte epoci hdd-ul avea 10MB) Nu stiu la hdd; la cdrom in mod date ai vreo 276 de octeti (nu biti) de ECC pentru fiecare 2048 de octeti de date, nu doar 32 de biti de detectie La cdrom da,(cred ca e in standard, si e normal sa fie public si standard astfel ca toate unitatile sa poata citi toate discurile); la hdd-uri din cite stiu numarul de biti redundanti si nici nu cred ca sint informatii care trebuie facute publice : platanele nu sint schimbate, asa ca fiecare producator este liber sa-si rezerve cit considera de cuviinta pentru acel disc in functie de pretul cerut pe disc, garantia oferita si nivelul de activitate pe care il anticipeaza pentru acel model. Ideea de aici e nu cit de bun e - in sensul cite erori poate corecta - ci faptul ca exista un mecanism de _detectie_ a erorilor Sigur, dar bun = ce rata de corupere accepta inainte de a fi pacalit (vezi paritatea care poate detecta doar un bit corupt, dupa care intri in zonele in care poti avea date corupte cu paritate corecta). Pe noi ne deranjeaza silent corruption - erorile nedetectate - nu erorile detectate Nu inteleg ce vrei sa spui aici. Erorile detectate prin faptul ca iti crapa o masina sau ai erori in filesystem si trebuie sa intervina fsck sa stearga inozi sau sa mute lanturi in lost+found la mine nu se califica pt detectie cu succes. Nemaipunind la socoteala ca doar fsck le poate detecta si fsck prin natura sa ruleaza rar. Da in 18 ani in zona IT am vazut - un hdd de desktop care corupea silent datele la scriere, banuiesc ca memoria de pe el era defecta si nu avea mecanism de detectie a erorilor - doua laptop-uri care corupeau datele de pe hdd, unul dupa ce bause cafea/cola, celalalt posibil din cauza ca a stat prea mult pe patura la caldurica Nimic voodoo / cabluri posedate / radiatii cosmice, doar defecte care duc la coruptie de date in etape in care nu exista paritate/crc/ecc Well,esti fericit atunci :P Eu am vazut ceva mai multe. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Trebuie sa refaci mdadm.conf ( cu ceva gen mdadm --examine --scan newmdadm.conf ) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca arrayurile se declara in mdadm.conf. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 20:07 +0200, Mihai Badici wrote: On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca arrayurile se declara in mdadm.conf. Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni inchiderea robinetului :) Nu, inchiderea robinetului este cauzata de userul care nu stie cum se manevreaza robinetul. In lumina faptului ca sistemul se asteapta sa aiba mdadm.conf, devine brusc foarte logic ca dupa ce pui setul de discuri intr-o instanta a sistemului de operare ce nu le-a mai folosit inainte trebuie sa refaci dupa caz mdadm.conf si eventual initrd. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 20:25 +0200, Mihai Badici wrote: On Saturday 16 November 2013 20:16:34 Vali Dragnuta wrote: On Sat, 2013-11-16 at 20:07 +0200, Mihai Badici wrote: On Saturday 16 November 2013 19:49:16 Vali Dragnuta wrote: Cam prin toate distributiile cu apa calda s-a convenit de ceva vreme ca arrayurile se declara in mdadm.conf. Dar dupa cum vezi, chiar si distributiile cu apa calda nu pot preveni inchiderea robinetului :) Nu, inchiderea robinetului este cauzata de userul care nu stie cum se manevreaza robinetul. In lumina faptului ca sistemul se asteapta sa aiba mdadm.conf, devine brusc foarte logic ca dupa ce pui setul de discuri intr-o instanta a sistemului de operare ce nu le-a mai folosit inainte trebuie sa refaci dupa caz mdadm.conf si eventual initrd. Da, cred ca ambele trebuie refacute, din motivele expuse mai sus. Presupun insa ca mai intai trebuie sa opreasca md127 si sa o asambleze ca md0, nu sunt sigur cum face detectia mdadm. Probabil nu a incheiat oficial procesul de migrare, cred ca-si permite un reboot ca sa se asigure ca se asambleaza corect la boot. (Eu chiar as recomanda un reboot final inainte de go production ca sa se asigure ca totul se initializeaza cum trebuie in caz de reboot accidental) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
On Sat, 2013-11-16 at 19:06 +, Dan Borlovan wrote: PS: tot in distributiile cu apa calda, montam fs-urile dupa UUID (prietenii stiu de ce) si nu dupa device, asa ca ni se cam rupe daca e md0, md127 sau md99 Indeed :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Mutare Hard-uri arie raid linux pe o instalare
Cred ca ce vrea el sa spuna este ca avind checksumuri (si cred ca si ceva error correction code) pentru fiecare unitate de date, la fiecare citire standard (as in citire din timpul utilizarii NORMALE) ai posibilitatea sa iti dai seama relativ usor daca datele citite sint in regula sau nu (si daca ai si ceva redundanta sa si corectezi situatia). Lucrul asta la raid1 poate fi ceva mai dificil, pentru ca majoritatea implementarilor la citirea unui bloc de date nu fac de fapt citire de pe ambele discuri ca sa si compare daca blocurile citite sint sau nu identice. Nu ca nu s-ar putea, dar nu se face mereu. Scrubul ala de zfs probabil ca forteaza aceasta verificare la nivelul intregului filesystem, dar nu depinzi de el pt detectia erorilor. De asemenea, este adevarat ca pentru fiecare bloc lowlevel in hard disc exista un alt checksum care este validat de controllerul intern al discului si eventual semnalat/realocat, dupa caz. Dar asta nu te protejeaza decit de erorile care au aparut pe suprafata magnetica ulterior momentului scrierii. Exista destule lucruri ingrijoratoare la zfs, precum cit de usor este ca atunci cind chiar ti s-au corupt discurile peste un anumit nivel cit de usor este sa repari filesystemul cu fsck (si eventual sa ramii si cu ceva date recuperate). Ext3/4 este relativ robust din punctul asta de vedere, ai sanse mari ca de pe un volum plin de erori logice sa restaurezi o cantitate semnificativa de date. Nu stiu cit de usor e lucrul asta pe un setup mai complicat de zfs atunci cind shit hits the fan. Dar la capitolul utilitate checksumuri pt ce salveaza si validare checksum la fiecare citire de unitati de pe disc versus a nu avea deloc, e clar ca e mai bine sa le ai. Ba mai mult, chiar si aplicatiile de deasupra vin in layerul lor si pentru blocurile lor isi fac alt checksum (bazele de date fiind un exemplu). Discutia versus nu ne trebuie asigurari suplimentare ca noi punem doar cabluri bune mi se pare un pic puerila, atita vreme cit validarea unui checksum la citire e o operatie cu cost minim nu poti argumenta ca nu e bine sa ai SI asa ceva, pentru ca tu ai cabluri bune si discuri enterprise. Chiar si alea dau rateuri, doar ca cu probabilitate mai mica. Culmea e ca eu la rindul meu sint zfs sceptic, atit pentru motivul de mai sus referitor la sansele de recovery atunci cind chiar se duce in balarii cit si pentru ca nu-l pot folosi normal sau oficial pe kerneluri linux (sa stau sa-l builduiesc de mina nu mi se pare convenabil). Dar trebuie a recunosc ca cel putin la capitolul asta cu validarea datelor citite are un avantaj, si mi se pare o prostie sa argumentezi ca un sistem de securitate in plus este prost pentru ca tu tii la datele tale si ai cabluri bune si hardware de top. On Fri, 2013-11-15 at 13:16 +0200, Andrei Pascal wrote: Of of, măi măi... Poți lăsa scrub-ul ăla să ruleze , e drept - dar tot îți va fute discurile. Și, întreb eu, CÂND ruleziscrub-ul? Dacă îl rulezi la scriere și cu asta basta, nu e nici o diferență între ZFS și RAID 5 de exemplu. Plus că e la mintea cocoșului că într-un mirror nu pui discuri din același lot de producție. Argumentul cu rebuildul mirror-ului ZFS e valabil, dar, cum spuneam mai înainte, ZFS e și volume manager și filesystem iar suport comercial n-are decât pe Solaris. Pentru tine acasă însă merge și pe *bsd, nu-i bai. Sau dacă nu te interesează suportul. 2013/11/15 Iulian Murgulet gul...@casbv.ro ... mai fac o incercare. 1. MD RAID1(2xHDD) Scriu un block de date care sa zicem contine A1B2(ca idee) pe un /dev/mdX, asta inseamna ca in spate, md-ul va scrie acel block identic pe HDD1 si pe HDD2. HDD1 si 2 zice gata e OK, am terminat Citesc acel block de date peste 3 luni(ipotetic), md-ul il va citi de pe HDD1 sau de pe HDD2(round-robin), daca il poate citi fara erori, zice ca e OK. - in astea 3 luni sa intamplat ceva(orice vreti voi sa va imaginati), si cand citesc el citeste cu SUCCES A1B0 - e bine? Cu siguranta nu e bine. 2. ZFS-mirror(2xHDD) Inainte de a scrie, calculez un check-sum pt. A1B2, si scriu pe HDD1 si 2 atat blocul de date cat SI check-sum-ul pe fiecare disk. Citesc acel block de date peste 3 luni(ipotetic), zfs-ul il va citi de pe HDD1 sau de pe HDD2(round-robin), calculez check-sum-ul la ce am citit si compar cu check-sum-ul stocat pe disk la scriere, daca bate verificarea, este OK. Daca nu bate verificarea, atunci citesc din nou acelasi bloc oglindit care se afla pe HDD2. Daca aici verificarea este OK, atunci, scriu din din nou acelasi bloc si pe HDD1, si returnez datele CORECTE pt. acel block aplicatiei. ZFS scrub, asta face, citeste fiecare bloc de date(si atentie, daca am un pool de 2 TB, da eu am date doar pe 10 GB, verific doar cei 10 GB de date), si verifica daca bate cu check-sum-ul stocat la scriere. 1. MD RAID1(2xHDD) - dintr-un motiv oarecare HDD2 a fost scos din raid(nu discutam cauza) - il bagam din nou
Re: [rlug] Card USB 3.0 VL805 pe FC12 kernel 2.6.32
On Thu, 2013-10-17 at 15:49 +0300, Paul Lacatus (Personal) wrote: On 16.10.2013 19:40, manuel lonely wolf wolfshant wrote: On 10/16/2013 07:20 PM, Paul Lacatus wrote: Am pus un card USB 3.0 pe un calculator cu fedora core 12 cu kernel 2.6.32 . Card-ul e PCI-E de la Anker si-l cheama USPEED. E bazat pe chipul VL805 de la VIA. Desi pare ca sistemul il recunoaste un disc conectat intr-unul din porturile USB 3.0 nu e vazut . Din ce am citit pe kernel 3.9 ar merge ok cardul . Ceva informatii despre problema asta mai stie cineva ? pune si tu macar kernelul din centos 6.4 , F12 e depasit moral de ani buni. eventual incearca kernelele pt centos 6 de la elrepo.org ( repo-ul elrepo-kernel include kernel-lt bazat pe seria 3.0 si kernel-ml bazat actualmente pe 3.11 ) E ceva timp de cind nu am mai pus alte kernel-uri in afara de update-urile oficiale. Si la ce iti foloseste asta atunci cind updateurile oficiale nu mai exista de mult timp si oricum ai un sistem cu pachete obsolete si cu gauri de securitate care nu au mai fost acoperite de updateuri pentru ca updateurile nu mai exista ? Abordarea ta nu e de fapt incorecta, doar ca ar trebui sa inglobezi in strategia pe termen lung si ce faci cind produsul devine ajunge la EOL. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Was Pornire MySql, but now is Agatare Mysql Slackware64 14.0
Nemaipunind la socoteala ca prin celelalte distributii merge, dar in slackware nu. Deh, sistemul conspiratiile e impotriva slackware. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Was Pornire MySql, but now is Agatare Mysql Slackware64 14.0
In To Do-ul meu, problema lansarii MySql a fost bifata ca Solved Acuma, dupa cateva zile sa ma intorc la ea si sa incerc s-o rezolv --- Asa, deci daca ramii cu masina^H^H^H^H cazanul in drum la fiecare iesire si il impingi pe jos pina ajungi la destinatie tu bifezi ca problema este rezolvata. Corect ? Si apoi, ma trezesc eu, un diletant in Linux, sa rezolv un bug care bantuie de mai bine de 7 ani dupa cum se zice. --- Da,se pare ca este un bug teribil de periculos si nimeni nu a reusit sa-l invinga. Daca am aplica aceeasi analogie la automobile (sau orice alt echipament pina la urma) ai mai cumpara o masina care la fiecare generatie pastreaza defectele de fabricatie ale versiunii anterioare ? Ma rog, poate pentru unii scopul masinii este sa surubareasca in fiecare duminica ajustind jigloare in fata blocului. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Centos 6.4 x64 XFS
Ai cumva mai mult de doua discuri pe sistemul acela ? E posibil ca tu sa fi instalat bootloaderul pe doua dintre ele dar biosul sa incerce de fapt sa booteze de pe alte discuri ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Centos 6.4 x64 XFS
Hai sa facem un sondaj cu citi avem / pe raid1. Ce zici citi norocosi se vor gasi ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] De ce nu am drept de ls pe un director?
On Mon, 2013-09-30 at 14:03 +0300, Adrian Popa wrote: Da, e dubios rău... Am încercat cu relogin, restart de sistem dar tot nu a funcționat. În directorul respectiv e montată o partiție xfs cu următoarele opțiuni (nu am un /etc/fstab, ăsta e outputul din mount): /dev/md2 on /DataVolume type xfs (rw,usrquota) Directorul /shares pare să fie hardlink către /DataVolume, oricum se comportă la fel indiferent de ce director încerc să accesez. Fișiere și directoare pot creea ușor ca user root, doar că vreau să încarc prin sftp ca user adrianp. - /hardlink sau bind mount ? ca user adrianp poti sa accesezi ce vrei sa accesezi via /DataVolume ? adica ls /DataVolume/Kits ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] intrebare naiva de kvm si bridge
On Fri, 2013-09-27 at 14:21 +0200, Ionel Mugurel Ciobîcă wrote: On 19-09-2013, at 19h 48'14, Nux! wrote about Re: [rlug] intrebare naiva de kvm si bridge Sapa pana dai de libvirt si virt-manager. :) Mersi, alea nu-s de folos. Ce te face sa crezi ca alea nu-s de folos ? Nu de alta, dar alea iti fac singure ce nu stii tu sa faci trimitind parametri la kvm... ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block Joe Jobs Qmail
On Thu, 2013-09-26 at 09:57 +0300, Mihai Badici wrote: On Thursday 26 September 2013 09:54:35 Mișu Moldovan wrote: 2013/9/26 Catalin Vasilescu catalin.vasile...@ymail.com Qmailul nu le filtreaza si ajung in exchange. Care ce face cu spamurile astea? În plus, am o bănuială că qmailu' tău nu știe care-s adresele de mail valide din domeniile pentru care acceptă mail, prin urmare Exchange-ul face backscatter la adresele invalide de destinatari din propriile domenii. Pai asta era valabil si daca nu era qmail-ul. Dar se poate dezactiva NDR-ul din exchange. Presupun ca cu altceva era mai simplu sa faca un lookup de conturi valide in (spre exemplu) ldap si sa respinga mesajele chiar in timpul tranzactiei initiale de livrare - nu ulterior sub forma de NDR distinct. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block Joe Jobs Qmail
Da, si asta e problema in sine in cazul in care ai un proxy in fata Exchange-ului care nu stie sa faca verificare de adresa a destinatarului cand primeste conexiunea de la client, cum e cazul qmail-ului chior. Raspunsul 55x genereaza un bounce trimis de proxy la o adresa nevinovata si asta e exact backscatter. Cred ca exchangeul ala nu merge fara un ldap/AD si in teorie cred ca ai putea sa faci lookup si din proxy pt conturi valide. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block Joe Jobs Qmail
On Thu, 2013-09-26 at 17:14 +1000, Adi Pircalabu wrote: 2013/9/26 Vali Dragnuta vali.dragn...@inode.ro: Presupun ca cu altceva era mai simplu sa faca un lookup de conturi valide in (spre exemplu) ldap si sa respinga mesajele chiar in timpul tranzactiei initiale de livrare - nu ulterior sub forma de NDR distinct. In Postfix exista suport pentru verificarea adresei destinatie de multa vreme fara artificii suplimentare gen LDAP, vezi reject_unverified_recipient http://www.postfix.org/ADDRESS_VERIFICATION_README.html Pai daca pui postfixul doar sa forwardeze mailurile spre un server intern trebuie sa ajungi sa faci lookup in altceva (ex ldap). ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block Joe Jobs Qmail
De ce? Pentru verificarea de adresa, dupa rcpt to Postfix tine conexiunea deschisa cu clientul, initiaza o conexiune noua la MTA-ul pentru care face relay in care verifica raspunsul la rcpt to. Pentru ce i-ar trebui sa faca lookup intr-o baza de date cand o face direct prin SMTP? A, ca vrei tu sa reduci numarul de conexiuni SMTP la serverul din spate e partea a doua, poti lucra cu LDAP si fratii sai, dar implicit nu e nevoie. Pentru ca o verificare sincrona de genul asta nu mi se pare prea eficienta ca si consum de resurse cind ai un volum mare de mailuri. Si ce se intimpla daca smtpul din spate contra caruia verifici e pe jos ? Sau doar raspunde greu ?De ce sa conditionezi functionarea proxyului extern de situatia resurselor din backend ? Sau daca iti da un raspuns negativ din cauza unei alte erori decit user inexistent ? Nemaipunind la socoteaca ca exchangeul oricum se va uita el in ldap ca el acolo cred ca-si tine userii... O interogare ldap ar trebui sa fie mult mai rapida chiar si doar pentru ca scoti middle-man din ecuatie. Plus de asta pe resursa ldap de obicei ai mai multa redundanta, si in plus cu asta poti sa mai implementezi la nevoie si smtp authentication si alte lucruri utile care deja sint dificil de implementat doar apelind la smtpul din spate. Pe scurt, folosirea tot a protocolului smtp(intre front proxy si backend smtp) pentru validare sincrona de useri nu mi se pare o solutie eleganta chiar daca altfel poate functiona pina la un punct. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block Joe Jobs Qmail
Vezi mai sus, afla de ce si rezolva problema. Daca junghiul de exchange da raspuns negativ e *foarte* probabil sa nu accepte mailul, atunci de ce l-ar accepta serverul din fata lui? Cel mai simplu exemplu ca sa vezi ca in cazul asta, daca nu esti atent, ajungi la backscatter: proxy-ul accepta conexiunea de la client, la rcpt to se uita in LDAP, accepta mailul, dupa care cand da sa-l livreze la destinatie backend-ul trimite 5xx desi userul exista in ldap. Ce crezi ca se intampla in cazul asta? :) Pai de obicei lumea pune smtp frontend nu doar de dragul de a nu expune direct in internet exchangeul (sa zicem groupwareul) cit si pentru a minimiza sau ascunde momentele de indisponibilitate temporara a acelui backend. Backendul fiind o platforma tehnica mai complexa este posibil sa mai aibe momente de indisponibilitate cind mai crapa bazele de date,resursele sau cind i se mai face upgrade samd. Mie mi se pare un pic iresponsabil sa refuzi mailuri pe care ai putea sa le accepti bine merci si fara niciun cost suplimentar in resurse (pina la urma asta face orice mx backup) pina cind backendul devine din nou disponibil. Altfel nu faci decit sa exporti problemele din interior spre exterior si ramii cu singurul beneficiu al frontendului acela ca nu expui groupwareul la riscuri de securitate din internet. Dar poti face mult mai mult cu cost 0 si cum spuneam, mi se pare un pic iresponsabil sa nu faci asta :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Block Joe Jobs Qmail
Punctual, cum rezolvi tu problema cu backend-ul care a luat-o razna si intoarce 5xx la toate conexiunile? Ce crezi ca trebuie sa faca proxy-ul in situatia asta? Sa accepte mailul sau nu? Asta e o alta problema a solutiei use smtp as identity verification : nu mai poti deosebi situatia in care iti da 5xx din motive corecte (ex content filter, a gasit un virus etc) sau din motiv de problema de configurare (ex administratoru' loveste si blacklisteaza *@*.com) sau din motive accidentale (ex userul are quota pe groupware si si-a umplut quota rezervata). Exceptind cazul cu virusii eu mi-as dori in celelalte cazuri sa pastrez mesajul primit ca sa-l pot livra mai tirziu cind problema din backend dispare. Scopul unui server de mail e sa poata primi cit mai multe mesaje *legitime* nu sa refuze din principiu mesaje pe motivul daca sefu' de deasupra are o problema imi bag si eu piciorul si nu mai lucrez. Tot legat de ce ai spus tu cu serverele configurate de oameni normai care fac retry mai ai si aici o problema : pe de-o parte ca nu stii exact cit de mult vor face retry comparativ cu perioada ta de downtime... sau cu perioada pina cind iti dai seama ca ai o problema - in caz ca nu este imediat aparenta. Pe de alta parte, daca tu te hotarasti sa copiezi statusul de la backend si pe frontend, atunci in cazul in care backendul are o problema de configurare si intoarce 5xx iar tu il mirrorezi vei inchide posibilitatea de a avea retry mai tirziu. Doar daca intorci 4xx pentru 4xx de la backend, dar atunci ce faci cu 5xx-ul corect de la backend ? (ex virus detected )? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Fisier aleator destul de mare
On Tue, 2013-05-28 at 22:17 +0300, Andrei-Florian Staicu wrote: Salut, Am nevoie sa generez repede* un fisier destul de aleator (i.e. care sa nu fie prea comprimabil cu gzip) de 1TB. Am incercat cu dd if=/dev/urandom bs=4194304 count=262144 of=/tapetest, dar merge cam greu, cam 8MBps. Care dd mai foloseste si 100% un core. Cam toata lumea zice ca urandom nu e bun pentru fisiere mari, dar care e alternativa? Aveti vreo idee? dd if=/dev/zero bs=1M count=1024 | aespipe binary_junk.dat Merge si cu ceva gpg cu cheie simetrica. Factorul limitator va fi CPU-ul, insa la mine pe laptop merge cu 37MB/sec, ma gindesc ca pe un server merge mai ok. De asemenea, poti face citeva in paralel si le concatenezi pe urma. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Copiere date peste retea de pe un NAS cu probleme pe HDD
nu trebuie neaparat sa monteze : 1) rsync (rsync /mnt/nas u...@other.host:/tmp/saved/ ) 2) dd if=/dev/mounted_device |ssh u...@other.host dd of=/tmp/saved.img Aproape sigur poti din surse alternative sa instalezi ddrescue care ar fi mult mai potrivit scopului de recovery. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] pwrite() slow
- nu sunt recomandate journaled fs pentru a tine pe ele baze de date. --- Um, what ?Asta e o prostie, folosesc de multi ani de zile baze de date si toate pe fs-uri jurnalizate (ext3,xfs, ext4...). Sincer chiar nu cred ca e vreun issue acolo. Inca nu inteleg de ce doar ext4 e in principal vinovat; stiam ca ext3/ext4/jfs/xfs folosesc toate jurnale, dar se pare ca jfs sau xfs sunt totusi acceptabile (nu intru in discutia cu db pe raw partition). Motivul pentru care (pana acum) nu am dorit sa renunt nici la DB forced writes nici la FS journal/barriers a fost ca (speram eu) doua protectii pentru consistenta/integritate nu strica, mai ales ca serverul se comporta admirabil in productie (scriptul sql in cauza e foarte intensiv la update-uri, pe cand in productie se fac multe select-uri si relativ putin inserturi). I was wrong. --- Depinde de baza de date, insa nu ar trebui sa ai penalitate atit de mare doar de la foarte multe update-uri. DB-urile moderne oricum la update-uri nu trebuie sa se asigure decit ca au scris corect log-ul (care este suficient pentru ca in caz de crash baza sa ramina consistenta in caz de crash), nu si blocurile de date efective care pot fi trimise ulterior intr-o ordine mai bine aleasa. Ce-i drept nu am lucrat cu firebird, insa daca intr-adevar face sync pt fiecare operatie, va merge prost no matter what. - ref. fs block size == db page size: db-ul meu are deja indecsi pe 3 nivele, la un page size de 8k; ideal ar fi sa fac page size de 16k insa nu stiu cum se va comporta un fs cu astfel de block size. Pe de alta parte, daca refac db page size sa fie egal cu 4k recomandat la fs, o sa imi incetineasca performanta accesarii paginilor in db (indecsi pe mai multe nivele, multe selecturi folosite in productie) - de curiozitate am rulat scriptul pe o copie a bazei de date, pe o masina virtuala - un container openvz cu mult mai putine resurse ca serverul de productie, hdd sata desktop, insa cu firebird forced writes dezactivat; pana m-am intors sa vad in ce stare mai este terminase deja (in mai putin de doua ore). Am sa refac testul cronometrat cu time si separat un alt test cu forced writes ON insa ext4 cu nobarrier/writeback/noatime/commit marit etc etc. Daca nu e cu banat, as schimba intrebarea din Subj in: cum e mai bine? sync la nivel de DB sau de FS? Impreuna m-am lamurit clar ca nu coabiteaza, nici macar institutional... --- Din pacate raspunsul la intrebarea ta ar depinde de DB. Insa indiferent de db NU as renunta la un fs jurnalizat.Mai degraba as investiga de ce db-ul tau mai vrea in secolul asta sa scrie totul in mod sincron (ma rog, intrebarea este chiar TOT ce scrie scrie sincron ? Ca daca doar logul (sau echivalentul sau in dbul ala) este sincron, asta e ok. De asemenea, as sugera sa rescrii acel script sa face updateurile intr-un mod mai eficient - sa updatezi mai multe inregistrari inainte sa faci commit-. Daca faci commit dupa fiecare update pt fiecare inregistrare (si ai si DB-ul lucrind in mod sincron) este de asteptat sa mearga prost, chiar si pentru simplul fapt ca trebuie sa faci foarte des apeluri de sistem sa scrii ceea ce tocmai ai modificat. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Recomandare 10 GbE (switch + nic)
On Mon, 2013-03-04 at 20:37 +0200, Mihai Rotaru wrote: @Victor Am comentat deja legat de jumbo. Fac un benchmark pentru MigratoryData WebSocket Server si trebuie sa merg pe o configuratie standard (mtu 1500). Cat despre 5gbps, probabil cu duce mai mult chiar fara jumbo, dar nu am mers cu testele mai departe deocamdata. Mersi oricum pentru sugestie. Sint scenarii in care jumbo poate ajuta si in setupul tau. De exemplu, daca ai ceva frontend intre clientii externi si serverul tau din interior (de ex reverse proxy, cache etc) in principiu ar ajuta un pic sa iti mearga mai repede tranferul local, chiar daca in exterior se trece inapoi pe frameuri mici. Also, daca tot ai inceput sa spui ca driverul implicit este mai slab, povesteste-ne daca ai timp si mai concret in ce a constat performanta mai proasta a driverului default apoi cu ce optiuni ai compilat driverul actualizat si ce alte setari ai mai facut ca sa obtii performante mai bune. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Recomandare 10 GbE (switch + nic)
In c6.3 vad ca exista acum versiunea 3.6.7-k in vreme ce versiunea de pe site este 3.13.10. Daca faci o impachetare pentru versiunea mai noua prin epel/elrepo fa un anunt. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ssd, raid, lvm, wtf, etc
On Thu, 2013-02-21 at 08:44 +0200, Dan Borlovan wrote: On 02/21/2013 08:16 AM, Mircea Mitu wrote: Ca nu merge Trim pe raid 1, 4, 5, 6, 10 Numarul de scrieri pe ssd intr-unul din raidurile astea se mareste semnificativ = scade durata de viata si performanta Hmmm. Din cite stiu ssd-urile din ultimii ani au - gc intern care ar trebui sa mai compenseze lipsa de trim - wear leveling ca sa un te stresezi ca-ti crapa un block in care scrii Ai dreptate in ce spui, dar mecanismele de mai sus functioneaza pe baza unui map de blocuri folosite/nefolosite (ca sa stie firmwareul pe unde poate sau nu plimba date). Lista de blocuri unused este initial tot discul vazut de OS PLUS o sectiune de obicei consistenta de blocuri vizibile doar pentru firmware si invizibile pt OS. Pe masura ce tu scrii in sectiunea publica, sectoarele scrise sint eliminate din lista de unused si nu mai sint folosite pentru wear leveling, raminind cu cele publice inca nescrise si cele private rezervate. Pe masura ce umpli discul si numarul de blocuri libere scade (chiar daca tu intre timp la nivel logic, in fs ai sters tot pr0nul pe care il stocasei acolo). TRIM te ajuta sa pasezi catre firmware blocurile care pot fi readaugate in map-ul de unused. Sint sigur ca stiai asta, da' am vrut sa subliniez ca mecanismele mentionate de tine sint fix atit de eficiente pe cit loc de manevra au acele mecanisme, iar trim-ul ajuta foarte mult la pastrarea unui loc de manevra cit mai mare. Ca workaround (care in principiu ar putea fi folosit si la unele raid, inclusiv hardware) ar fi sa folosesti din start doar o parte din disc pentru ca partea nefolosita sa ramina in permanent in lista de blocuri unused a firmwareului in adaos fata de blocurile rezervate, private. Poti sa faci asta ori alocind o partitie mai mica decit discul pe un OS care nu stie trim sau (posibil in unele controllere) sa faci volumele raid din mai putin decit capacitatea nominala a discurilor din array. Unele controllere au un feature sa foloseasca doar o parte din disc. Cu linux md este si mai simplu, compui arrayul din partitii si ai grija ca partitiile sa fie mai mici. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] ssd, raid, lvm, wtf, etc
On Thu, 2013-02-21 at 10:54 +0200, Mircea MITU wrote: On Feb 21, 2013, at 10:49 AM, Dan Borlovan d...@level7.ro wrote: Da' eu nu m-as stresa foarte tare ca n-am trim. La niste baze de date cu doar citeva milioane de inregistrari sporul de viteza a dramatic (in unele cazuri minute in loc de ore) incit chiar mi se rupe daca la un moment dat nu mai scrie cu 500mb/s ca nu mai sint blocuri pregatite. Si aici intervine raid-ul, ca +500mb/s ai in conditii de laborator, dupa ce faci raid ai 170mb/s. De asta intrebam ce experiente aveti cu ssd in raid (eventual si lvm), pentru ca teoria de pe net rareori seamana cu practica Eu de exemplu vreau sa fac un raid10 dar din testele interne reiese ca ies la aceiasi bani / performanta cu sas, insa la ssd risc ca peste 6-12 luni sa am performante de sata 7200rpm Dar probabil ma insel Tu vorbesti aici de rata de transfer sustinuta. La heavy random io nu o sa ai acelasi nivel de performanta niciodata cu un disc mecanic.Adica fix in situatiile alea cind un disc mecanic scade la 10..20mb/sec. In special la baze de date se vede. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Pidgin kind of sucks
On Sun, 2012-12-02 at 12:11 +0200, Valentin Cozma wrote: On Sat, 01 Dec 2012 21:59:27 +0200 Vali Dragnuta vali.dragn...@inode.ro wrote: 1. nu pot sa caut in loguri intr-un mod decent (sunt aranjate pe conversatii doh) --- De ce nu ? Poti face si grep recursiv pe directorul cu loguri, dar are si search in history viewer. Imi este un pic neclar in ce fel nu poti cauta. ok, sunt de acord cu voi ca pot cauta cu find grep etc. Am uitat sa zic ca am log in html ... Deja e mai distractiv. still, de ce naiba au mai facut functia de view log daca nu se poate folosi decent. Repet, eu am si search in gaim - care chiar functioneaza. De ce zici tu ca nu are search ? Ca mentiune insa, eu am logurile in plain text. Asta e un avantaj pentru cind vrei sa cauti din exterior prin ele. Faptul ca iti da mesajele unu cate unu e un feature sau un bug? Nu vad in ce fel m-ar ajuta sa mi le dea cu picatura. Unul cite unul = separate pe parteneri de deiscutie, nu pe linii de conversatie. Cu alte cuvinte, daca ai 10 linii/mesaje necitite de la buddy1 si 1 de la buddy2, vei da 2 clickuri pe notificare si iti va deschide prima data o fereastra cu cele 10 linii scrise de b1 si apoi o fereastra cu 1 linie scrisa de b2. Mie mi se pare un feature ca imi produce notificari pina cind nu mai sint evenimente la care trebuie sa reactionez. corect am si eu asta. Dai click si te muta in Desktop5 din Desktop1. Super frustrant. Asta e un bug(feature:)) de gnome .. Un pic incomplet pt ca ar trebui sa te si poti intoarce in desktopul in care lucrai inainte. Eh, nu ma deranjeaza atit de mult. Apropo de empathy : ala are loguri salvate ca xml-ul vietii, sa vezi e bucurie sa cauti prin alea cu orice altceva. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Pidgin kind of sucks
1. nu pot sa caut in loguri intr-un mod decent (sunt aranjate pe conversatii doh) --- De ce nu ? Poti face si grep recursiv pe directorul cu loguri, dar are si search in history viewer. Imi este un pic neclar in ce fel nu poti cauta. 2. mi se tot ascund ferestrele , iar conversatiile noi nu se adauga in lista, ci stau si rad de mine in iconul de la pidgin (mi-am dezactivat osd-ul care oricum ma enerva ; daca scriu 2 oameni odata nu mai intelegi nimic). --- Eu folosesc alt setup : In primul rind am dezactivat multitabbed chat window. Apoi am activat pentru notificare pe de-o parte systray icon blinking. Clipeste pina dai click pe icon si cind dai click pe icon iti deschide un chat window cu primul contact de la care ai mesaje. Daca mai erau si de la altii, mai dai click inca o data si iti deschide inca o fereastra cu urmatorul contact. De asemenea am activat si alta optiune de notificare pt taskbar, care face sa-ti clipeasca in taskbar (indiferent de desktopul activ) fereastra in care s-au mai produs evenimente, astfel incit chiar daca aveai deja o fereastra activa cu un anume contact pe un desktop oarecare, iti apare in taskbar acea fereastra si poti da click pe ea sa ti se mute focusul pe acea fereastra. Cu combinatia asta eu nu ma pierd niciodata printre chat windows. Chestia cu escape care merge pe chat windows dar nu pe buddy list este intr-adevar cam enervanta - insa buddy list-ul nu-l accesez chiar asa de des. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Intrebare file mirroring
De ce sute ? Ar trebui sa faci deploy manual pe o singura masina si sa ai acolo un master script care face rsync pe toate masinile slave. Desigur, sint niste conditii care ar trebui indeplinite in prealabil dar altfel... nu cred ca e asa complicat :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] script output consola
In plus de avertismentele deja date , ar trebui sa stie ca pot exista surprize daca scriptul respectiv se intimpla sa isi inceapa rularea in momentul in care exista altceva/altcineva care deja se joaca pe consola switchului cu un (spre exemplu) minicom. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Nu am sunet cind vizionez video prin cablu HDMI
In mod normal ar trebui sa poti din clica clica sa-i spui lui pulseaudio ce placa sa foloseasca. Daca mplayer are output pe pulse, atunci setarea respectiva la nivel de pulse ar trebui sa rezolve si mplayer. Daca faci output pe alsa, atunci va trebui sa-i specifici explicit care device sa-l foloseasca. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Server tunning - imbunatatire IO
Daca aveti oracle rac va trebui din pacate sa ramineti la un setup cu storage partajat de noduri. Exista solutii diverse dar cred ca deja sint in afara scopului innitial al discutiei :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Server tunning - imbunatatire IO
Eu as zice sa nu puna zfs in productie pe linux... si MAI ALES sub o baza de date oracle. Se pot intimpla chestii amuzante, iar suportul nu va fi deloc incintat daca are vreo problema. Plus de asta, parca zicea intr-un alt email ca are RAC, ceea ce inseamna ca ii trebuie si shared storage. So, e ceva mai complicat. Ma rog, ar putea sa renunte la rac (in anumite conditii). ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Server tunning - imbunatatire IO
Am banuiala ca acel rezultat nu tocmai corect pentru ca la cum a dat comanda este afectat de cel putin doua cacheuri : al controllerului raid ( daca are minim 4G - unele controllere areca suporta atit de mult) dar mai ales al sistemului de operare (presupun ca are memorie peste 4G). Pentru rezultate mai corecte cu dd, ar trebui adaugat la dd : oflag=direct In felul asta elimini bufferele OS-ului din schema. Ramine cel al controllerului, si ca sa minimizezi efectul sau scrii 16G in loc de 4G. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Server tunning - imbunatatire IO
1.De fapt raid5 nu e asa rau pe operatii de citire (si hdparm -t face citire). 2.Pe de alta parte, faptul ca discurile alea au 15krpm nu (mai) inseamna mare lucru - s-ar putea ca ele sa fie extrem de vechi si foarte lente. Faptul ca sint pe U320 SCSI sugereaza de asemenea ca sint discuri vechi si lente. 3.Poate cardul raid nu se descurca extrem de bine cu atit de multe discuri in array. Ar trebui incercat intii cu expunerea unui SINGUR disc ca sa vezi cit poate duce acel singur disc. Apoi incearca diverse configuratii de raid din discuri mai putine (4 de exemplu) si vezi ce se intimpla. 4.Daca ai pe undeve optiunea sa enablezi in mod safe cacheuri in mod writeback fa-o. Asta ajuta in special la scriere. 5.Nu in ultimul rind, HP MSA-urile nu sint tocmai renumite pentru performanta lor, de fapt as zice ca sint destul de triste. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Server tunning - imbunatatire IO
In cazul de fata as zice ca storageul este totusi destul de trist. Daca nici la hdparm (care citeste secvential date) nu merge ok...nu vreau sa stiu ce se intimpla la random I/O. Desigur, exista intotdeauna un loc epsilonic de optimizare in stiva software, insa e posibil ca raportul cost optimizare/beneficii sa nu fie tocmai favorabil. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Server tunning - imbunatatire IO
Cred ca si daca pui un server de generatie recenta cu 4xSATA enterprise de 1T in raid6 sau raid10 vei obtine performante net superioare. A, si vei iesi si mai ieftin. Presupun ca storageul ala nu-l folositi pentru RAC ci doar pentru ca la vremea achizitiei cuiva i-a parut ca este o investitie foarte buna. Ce vreau sa spun este ca daca nu aveti RAC sau offsite mirroring sau alte minuni unde unde trebuie folosit si eventual partajat un storage extern, e posibil sa obtii beneficii spectaculoase cu o investitie financiara foarte mica. Doar din evolutia hardwareului. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Server tunning - imbunatatire IO
On Thu, 2012-09-13 at 18:56 +0300, Mircea Mitu wrote: In plus cartile de istorie la capitolul baze de date includ doua note de subsol, marunte 1. Nu folosi Raid5 (si derivati) 2. SSDurile ajuta unde programatorul nu indexeaza, dar nu iti baga si in sac Aia cu raid5 este adevarata dar nu chiar atit de generala. De fapt, daca baza de date este folosita mai mult pentru raportare (deci are un procent de scrieri semnificativ mai mic decit citirile) s-ar putea ca un raid5 sa fie ceva mai convenabil atit ca raport capacitate/pret cit si ca viteza. Mai mult, am vazut implementari decente de raid5 care tineau si scrieri mai mult decit onorabil. In concluzie, nimic nu e asa tare batut in cuie. Banalul depinde se aplica si aici :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] iptables :: listare porturi permise neprivilegiate
Cred ca tu confunzi doua notiuni diferite, anume cea de port deschis cu cea de port neblocat de un firewall . ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] dosemu si fullscreen
Cel mai simplu ar fi sa maresti fontul din Putty, gasesti o marime a.i. 80x25 sa-i umple ecranul. 1) In putty exista o optiune windows-change font size when maximised (care iti va schimba fontul la dimensiunea necesara pastrarii rezolutiei in caractere aleasa de tine) 2) Exista si optiunea de fullscreen, caz in care tot ecranul este ocupat de putty. So, din 1+2 presupun ca obtii exact ce vrei.Ai grija insa, ca e posibil sa ai mici probleme cu diverse shortcuturi din aplicatiile vechi in fox. (E posibil sa nu iti ajunga toate in dosemu, probabil ca va trebui sa ai si un trial inainte ca sa nu te injure userul ulterior...) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] 3ware si prieteni
Dar raidul ala era 0 sau 1 ? :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Rsync from samba share
In cazul in care si urcarea fisierelor se face tot prin intermediul unui script de la o alta locatie (deci ceva automat) ai putea sa modifici scriptul uploader sa a) Creeze si un fisier flag (de exemplu $originalfilename.ready ) dupa ce a terminat de uploadat b) Sa urce fisierele intii intr-un director incoming exclus de la rsync iar in momentul terminarii uploadului sa le mute in zona de lucru (operatia de mutare e instantanee) c)Presupunind ca uploadul este relativ predictibil ca durata si rata de transfer este relativ constanta poti sa rsync-uiesti doar fisierele care nu s-au modificat in ultimele 4 ore de exemplu d)Poti sa ai un job aditional care verifica periodic fisierele din share si face o lista cu cele care nu si-au schimbat anumite atribute in ultimele N minute. Ai putea sa te uiti de dimensiune (daca fisierul este in curs de upload sigur isi schimba dimensiunea in mod continuu pina la terminarea uploadului) sau in cazuri extreme un hash (dar nerecomandat). On Tue, 2012-08-07 at 11:25 +0100, Gyula Keresztely-Krall wrote: Salut, Deoarece sufar de boala cronica si acuta lipsa de idei, postez si aici poate ma ajuta cineva :) : Se da urmatoarea situatie: Pe un share samba sunt incarcate cateva fisiere (in general audio si video) pe care trebuie sa le sincronizez pe un ftp aflata pe o alta masina. Toate cele bune merge bine cu rsync cu exceptia unei chestii: Frecvent se intimpla ca fisierele respective sa fie in curs de upload (sunt fisiere mari 100Mb), caz in care fisierul syncronizat cu rsync va fii varza. Mai sunt si altii care sau lovit de aceasta problema: http://lists.samba.org/archive/rsync/2006-November/016680.html Intrebarea mea : exista vreun mod prin care sa-l fac pe rsync sa sara peste fiserele care nu sunt inca incarcate in intregime (ar fii o metoda de a verifica smb lock cica), sau vreun alt mod de a verifica acele fisiere (in script bineinteles) inainte sa lansez rsync pe tot directorul? Sau orice alta idee e binevenita. Mentionez ca nu am alt access la masina cu samba share decat un mount (cifs) cu un user si parola, iar masina de pe care rulez scriptul de rsync e un centos 5 (desi nu cred ca are relevanta). Multumesc. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] url network monitoring
Ceea ce incearca toata lumea sa-ti explice este ca diferentierea intre veveve.testulica.com si www.youtube.com se poate face undeva mai sus in lantul trofic al protocoalelor. Mai mult decit atit, este destul de dificil sa faci acea diferentiere cind : - intervin diverse retele de distributie care iti mapeaza www.youtube.com peste (spre exemplu) youtube-ui.l.google.com - contentul NU este servit doar de www.youtube.com ci este imprastiat peste o multime de-alde : i1.ytimg.com i3.ytimg.com www.youtube-nocookie.com o-o.preferred.rds-tsr2.v1.lscache3.c.youtube.com p2.jmj4evpfokto4.2ssf4fds6ljhyq4m.216131.i1.ds.ipv6-exp.l.google.com clients1.google.com colac peste pupaza, hosturi de genul celor de mai sus se tot regasesc printre celelalte aplicatii google. - apoi ce te faci cu traficul SSL, ala nu ai [*] cum sa-l parsezi sa vezi daca gigel s-a conectat la https://youtube.com sau la https://gmail.com Nu, doar sa te uiti la reverse-ul adresei nu prea ajuta. [*] prea usor sau legal. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] NU pot instala Gnome pe un UBUNTU 12.04
On Fri, 2012-07-13 at 08:25 +0300, Mihai Badici wrote: 2012/7/13 Vali Dragnuta vali.dragn...@inode.ro: Mirrorul ro.archive.ubuntu.com face figuri de citeva zile. O solutie ar fi sa schimbi in /etc/apt/sources.list orice referinta la ro.archive cu (de ex) eu.archive sau us.archive Nu avem mirror si la noi in Romania, adica ftp.lug.ro? Ba da, desigur - doar ca implicit configuratia contine ro.archive... si configuratia implicita a dat chix din cauza de mirror mucit. M-am gindit ca pentru less trained monkeys e mai simplu sa inlocuiasca ro cu eu decit sa inlocuiasca tot urlul :) Si daca tot vorbim de mirroruri ma intreb de ce nu a adaugat nimeni mirrorul de bubuntu din lug.ro la lista oficiala pentru ro.archive ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Nu ma lasa sa scriu intr-un director montat prin samba
Nu stiu daca ai nevoie de inherit permissions,acls si owner in definitia shareului si nici daca chiar vrei chestia asta; Mai degraba pui force user si force group (parca asa era) sa le faca pe toate ale lui oracle; De asemenea,cred ca lu mount.cifs trebuie sa-i pui si -o uid=oracleid,gid=oraclegid pentru ca ownerul care apare pe client sa se mapeze peste userul oracle de pe client. On Thu, 2012-07-12 at 14:03 +0300, Silviu Marin-Caea wrote: Am asa: serverA share-uieste un director prin samba serverB il monteaza cu userul oracle Pe serverB trebuie sa pot scrie in directorul acela si cu alti useri in afara de oracle. Am setat pe el permisiuni pentru oricine. Nu ma lasa sa scriu! Culmea, creeaza fisierul, dar nu vrea sa scrie nimic in el. Indiferent ce am incercat pe server1 in smb.conf, nu se poate. Mai exact, am incercat inherit owner, inherit permissions, inherit acls Asta este smb.conf pe serverA [global] workgroup = whatever printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Never include = /etc/samba/dhcp.conf logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = Yes [mergibai] path = /opt/oracle/mergibai inherit permissions = Yes inherit acls = Yes inherit owner = Yes valid users = oracle writeable = yes Montarea pe serverB o fac asa mount.cifs //serverA/mergibai /opt/oracle/mergibai -o username=oracle,password=*** In capul meu este ca trebuie sa pot scrie de pe serverB cu orice user, pentru ca permisiunile sunt pentru toata lumea, iar samba sa transforme userul acela in oracle pe server1. E o tampenie? De ce incerc sa folosesc samba intre doua servere Linux? Pentru ca serviciul NFS se blocheaza la 2-3 zile, si asa de tare ca trebuie sa dau reboot. Filesystem-ul din /opt/oracle/mergibai este OCFS2 1.4. ___ 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] NU pot instala Gnome pe un UBUNTU 12.04
Mirrorul ro.archive.ubuntu.com face figuri de citeva zile. O solutie ar fi sa schimbi in /etc/apt/sources.list orice referinta la ro.archive cu (de ex) eu.archive sau us.archive ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Cum disablesc GUI boot in UBUNTU 12.04
Eu cred ca el vrea de fapt ori ubuntu server ori slackware de unde a venit. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Custom centos repository
Probabil ca ai nevoie de yum install yum-plugin-priorities Description : This plugin allows repositories to have different priorities. : Packages in a repository with a lower priority can't be overridden by packages : from a repository with a higher priority even if repo has a later version. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Custom centos repository
Si deci ce nu-ti convine la repo priority ? Din cum ai descris tu problema, repo priority face exact ce vrei tu, va prefera oricind si oricum pachete din repositoryul prioritizat de tine (cel pe care ti-l faci tu) versus pachete din alte repo-uri.Indiferent de versiune. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] lansare scripturi/aplicatii din browser
Credeam ca vrei sa dai userilor acces la o cale de a rula simplu diverse aplicatii interne expuse pe un repository central (si care eventual se pot si schimba frecvent). Daca de fapt vrei doar o modalitate de a instala (permanent) pe statiile lor ceva atunci apturl e cu siguranta varianta cea mai buna. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] lansare scripturi/aplicatii din browser
O alternativa pentru ce ti s-a mai sugerat. Ca sa nu cumva sa inceapa userii sa execute orice gogomanie si din alte surse, ma gindesc ca ai putea face un minim de efort ca sa : 1) Iti faci o mini aplicatie (ex perl script ) pe care o deployezi in prealabil pe toate statiile. Ai grija sa deployezi manual aceasta aplicatie dinainte. 2) Iti creezi un urlhandler pentru browser astfel incit toate linkurile de forma sigur.ro_executer://adresa.repository/aplicatie.sh sa fie pasate catre mini aplicatia de la 1). Acea mini aplicatie iti face ceva validari (ex daca adresa aplicatiei este intr-o sursa acceptata) apoi downloadeaza aplicatia si o executa - eventual setind si un environment corespunzator. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Samba mysql authentication
On Wed, 2012-04-04 at 23:41 +0300, Andrei Pascal wrote: 2012/4/4 Mircea Mitu mir...@sigu.ro: On 04.04.2012, at 21:22, Andrei Pascal avpas...@gmail.com wrote: Esti sigur ca VREI cu adevarat asa ceva? Eu zic sa te mai gandesti de cateva ori... La ce anume? Useri comuni sau autentificare in mysql? Ambele? Hai ca mysql-ul ala mai poate fi trecut cu vederea... desi la 30 useri cred ca e putin prea complicat. Daca iuzarii aia isi pot schimba singuri parolele devine amuzant sa poti sa faci vpn in interiorul firmei ics cu o parola gen 123456. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Samba mysql authentication
On Thu, 2012-04-05 at 08:02 +0300, Mircea Mitu wrote: On 05.04.2012, at 07:09, Vali Dragnuta vali.dragn...@inode.ro wrote: On Wed, 2012-04-04 at 23:41 +0300, Andrei Pascal wrote: 2012/4/4 Mircea Mitu mir...@sigu.ro: On 04.04.2012, at 21:22, Andrei Pascal avpas...@gmail.com wrote: Esti sigur ca VREI cu adevarat asa ceva? Eu zic sa te mai gandesti de cateva ori... La ce anume? Useri comuni sau autentificare in mysql? Ambele? Hai ca mysql-ul ala mai poate fi trecut cu vederea... desi la 30 useri cred ca e putin prea complicat. Daca iuzarii aia isi pot schimba singuri parolele Da' asta nu e acelasi lucru cu active directory si ipsec/l2tp? Daca e naspa hai sa i-o zici si lui Zoli azi la Load :) devine amuzant sa poti sa faci vpn in interiorul firmei ics cu o parola gen 123456. pt asta exista password policies Sint complet de acord, dar de cele mai multe ori lumea omite acest mic amanunt :). Si alte mici amanunte. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] LOAD 2012
Ohnoez, teh cloud haz failed. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
