On 1/23/2014 1:07 AM, Vali Dragnuta wrote: > Varianta 1, cum cred ca s-a mai zis, faci poll. Nu e o mare tragedie ca > sa faci de pe destinatie : ideile de implementare ar fi fost cronologic dupa cum urmeaza: 1. poll pana cand se face rsync-ul corect, cu posibilitatea de a bloca cumva accesul la resursa la sursa; alta metoda decat sa modific fisierul de configurare al rsyncd si restart la daemon nu au auzit, deci sarim peste metoda 2. poll la un fisier anume de pe sursa, care atunci cand apare si este transferat da verde la toata nebunia de transferat 3. atunci cand se termina operatia de pre-rsync (statistici, arhivari, backup db, whatever), sursa notifica (prin ssh, ftp, sau cel mai bine http) destinatia, se marcheaza un flag (baza de date, sau fisier pe disc), iar un daemon care ruleaza pe destinatie, atunci cand vede 'flag-urile' respective (fisiere sau ceva in baza de date) stie ca poate face frumos rsync-ul;
prefer varianta 3 fata de varianta lui Petre cu push_server pentru ca mi se pare mult mai controlabila (am expus ieri motivele), si de asemenea cu cat sunt mai putine point of failures, cu atat mai bine (doar o conexiune de rsync are in teorie sanse mai bune decat un rsync plus un ssh, plus ca pot sa-i fac resume de cate ori vreau eu etc etc); oricum in principiu se poate face orice in ambele variante, ca doar vorbim de linux, deci pana la urma e doar o problema de gust si bonus, pentru ca am reusit sa prind niste somn bun azi noapte, descrierea problemei: - pe serverele sursa (servere) se fac niste operatii (statistici, dump-uri de db, arhivari, alte operatii) - dupa ce sunt sigur ca s-au terminat toate operatiile, vreau sa trag de pe respectivele servere pe o destinatie de backup; nu trebuie sa fie realtime, doar sa se faca transferul cat de cat la un interval rezonabil de timp - prefer pull in loc de push pentru ca la pull pot sa controlez mult mai bine ce fac cu rsync-ul, fata de push unde automat cam trebuie sa-i dau drepturi sa scrie peste tot in respectivul modul; da stiu, as putea sa schimb drepturile la destinatie dupa transfer, dar nu e mai logic sa o fac cat mai simplu pentru mine (ma rog, simplu in conditiile mele, ca cel mai simplu era push, dar nu vreau) - problema consta in notificarea destinatiei ca sursa a terminat operatia si ca poate incepe; vad ca varianta la care deja ma gandisem pare in continuare cea mai buna, sper ca acum se intelege, desi inca mai am de recuperat de somn, multumesc tuturor pentru intelegere > 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 ? > nu stiu daca neaparat sensibile, dar cum paranoia e deformatie profesionala, imi place sa gandesc o treaba ca worst case scenario, daca nu implica extraordinar de mult efort diferenta (si in cazul asta chiar se merita); vreau ca daca cumva cineva compromite sursa (aka serverul) 100% (mai bine nu, dar se poate intampla pana la urma, ca nu exista sistem perfect), macar sa stiu ca exista backup nealterat, la care nu are cum sa ajunga, oricate informatii ar obtine de pe server, backup care sa poate fi folosit la nevoie Alex _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
