Newsgroup: it.comp.os.linux.sys
Titolo: copiare file Unix ----> Linux

Devo spostare da un  server Unix 800mb su un serve Linux qualcuno
conosce un metodo veloce?
Grazie per l'attenzione

 conosce un metodo veloce?
Col vecchio tar...
monti via NFS il disco su cui trasferire poi fai:
(cd /source && tar cf - <nome>) | (cd /dest && tar xvfp - )
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 (cd /source && tar cf - <nome>) | (cd /dest && tar xvfp - )
Uhm, NFS e` la risposta sbagliata (e` notoriamente inefficiente).
Usa rsh piuttosto (o remsh, o comunque sia chiamata)
cd /source && tar cf - .|(rsh destinazione "cd /dest; tar xf -)
-- 
  /Kinkie
Se sulla scatola c'e` scritto "Per windows 95 e superiori", dovrebbe
funzionare sotto Linux, vero?

 Usa rsh piuttosto (o remsh, o comunque sia chiamata)
So che e' inefficiente ma allora mi obblighi ad essere pignolo e farti il
pelo sulla scelta di rsh che e' insicuro e ti obbliga ad avere un
/etc/hosts.equiv molto ben congegnato per evitare brutte sorprese :-)


/etc/hosts.equiv molto ben congegnato per evitare brutte sorprese :-)
Chi offre ssh? Nessuno? ftp?
1.. 2.. 3..
Aggiudicato a rsh+utp incrociato.
-- 
*** Hi! I'm a .signature Virus ! Copy me
    to your signature to help me spreading! ***

 Aggiudicato a rsh+utp incrociato.
Mi fido piu' di SSH :-) Salutami l'astante, eheheh


 /etc/hosts.equiv molto ben congegnato per evitare brutte sorprese :-)
Usare ssh come rimedio potrebbe essere peggio del male (in termini di
efficienza naturalmente). Se metti una entry in .rhosts solo per il tempo
necessario a _iniziare_ il trasferimento, riduci grandemente la
probabilita` di avere problemi. Rimane il problema che lo stream e` in
teoria sniffabile (ma se fai uno spostamento del genere solitamente sei
probabilmente su una rete almeno parzialmente trusted), e il fatto che
forse (soprattutto se l'host sorgente e` discretamente "pesante" cpu-wise e
la rete e` "lenta") conviene dare un minimo di compressione per ridurre i
tempi di trasferimento. Inoltre questo ridurrebbe i problemi di
sniffabilita` (gzip non ricostruisce un file compresso se perde la
"sincronia" con lo stream dati, non so se sia possibile tentare un
recovery): se infatti chi tenta lo sniffing non riesce a prendere l'inizio
dello stream (bastsa perdere un pacchetto), e` fregato.


cd /source && tar cf - .|(rsh destinazione "cd /dest; tar xf -)
Vogliamo aggiungerci anche una "z" a quei cf e xf? Se va via rete...
Leonardo
".signature": bad command or file name


----
                          "True programmers never die, 
                           they just branch to an odd address..."

RSH + cavo di rete (crossato) host-to-host
Che e' quello che intendevo con rsh+utp incrociato... :-)


 forse (soprattutto se l'host sorgente e` discretamente "pesante" cpu-wise e
Mah sinceramente non so fino a che punto lo possa essere: parliamo
sempre di una connessione con un tunnel criptato e non mi sembra banale
(pur non essendo un granbde esperto in materia) riuscire a sniffare una
connessione del genere. Mi aspetto suggerimenti e correzioni da qualcuno
che ne sappia piu' di me (Leonardo?)


 che ne sappia piu' di me (Leonardo?)
Se c'e` il tunnel criptato il problema non si pone, ovviamente. Io sto
dicendo: "il tunnel criptato e` sicuro, ma costoso. se non te la senti di
sostenerne il costo e la il path dei dati e` abbastanza fidato (trusted),
lascia perdere la crittografia e buttati sulle performances. In tal caso,
una leggera compressione puo` migliorare le prestazioni specie se il
processore e` risorsa abbondante e la rete risorsa scarsa (i.e. PIII-600 su
una eth 10 Mbit/s).
E` ovvio che se anche una sola delle premesse non e` valida (i.e. se la
rete non e` trusted) crolla tutto il castello di carte...


 sostenerne il costo e la il path dei dati e` abbastanza fidato (trusted),
Beh ovviamente va valutato anche questo ma immagino che in presenza di
una rete sufficientemente ampia, con dati rilevanti e che si vuole a
tutti i costi cercare di mantenere integri o sicuri penso che si possa
anche decidere di investire mezzi adatti..


 anche decidere di investire mezzi adatti..
Ovviamente. La soluzione piu` estrema e` tirare su una rete privata (non
come in VPN, ma come un pezzo di coassiale o altro che collega i due host
in questione puntopunto). Non riesco a immaginare una soluzione piu`
sicura. ^_^


 wrote:
-> 
thorin_...@at-gruppocm-cs.it
 writes:
-> 
-> > > Se c'e` il tunnel criptato il problema non si pone, ovviamente. Io sto
-> > > dicendo: "il tunnel criptato e` sicuro, ma costoso. se non te la senti di
-> > > sostenerne il costo e la il path dei dati e` abbastanza fidato (trusted),
-> > Beh ovviamente va valutato anche questo ma immagino che in presenza di
-> > una rete sufficientemente ampia, con dati rilevanti e che si vuole a
-> > tutti i costi cercare di mantenere integri o sicuri penso che si possa
-> > anche decidere di investire mezzi adatti..
-> 
-> Ovviamente. La soluzione piu` estrema e` tirare su una rete privata (non
-> come in VPN, ma come un pezzo di coassiale o altro che collega i due host
-> in questione puntopunto). Non riesco a immaginare una soluzione piu`
-> sicura. ^_^
Un bel PGP (o GPG) a 2048 bit ?
Se poi interessa, sul Linux Journal di Dicembre 1999 e Gennaio 2000 c'e' spiegato
come fare una VPN con Linux.
Comunque usando GPG si possono mandare dati in maniera sicura su reti
insicure.
bye
Gianluca
-- 
Home Page                	Contro i brevetti del sw     Boicotta Microsoft
www.infinito.it/utenti/chewbe
 
no-patents.prosa.it/
 
www.boycott-ms.org/
 
"If we have to file a thousand lawsuits a day, we'll do it.
It's less expensive than losing CONTROL of YOUR creative works."
---Jack Valenti, President and CEO, Motion Picture Association of America

 sicura. ^_^
Gia', la VPN e' tutt'altro che sicura, specie nella implementazione
degli skiavi di zio Bill (oh come godo per la sentenza, oh come godo per
la sentenza :-) )


 come fare una VPN con Linux.
Lo cerchero' perche' questo comunque mi interessa..


 wrote:
-> In un messaggio del Wed, 5 Apr 2000 00:16:35 +0200 Gianluca scriveva:
-> 
-> > -> Ovviamente. La soluzione piu` estrema e` tirare su una rete privata (non
-> > -> come in VPN, ma come un pezzo di coassiale o altro che collega i due host
-> > -> in questione puntopunto). Non riesco a immaginare una soluzione piu`
-> > -> sicura. ^_^
-> 
-> > Un bel PGP (o GPG) a 2048 bit ?
-> PGP e' molto bello ma non puoi spiegare ad un utonto che prima deve
-> creare una propria public key, poi creare un key ring con le chiavi
-> degli altri e tutto il resto..
Non mi sembra una gran complicazione, tanto e' vero che e' possibile
automatizzarlo.
-> > Se poi interessa, sul Linux Journal di Dicembre 1999 e Gennaio 2000 c'e' spiegato
-> > come fare una VPN con Linux.
-> Lo cerchero' perche' questo comunque mi interessa..
Hai un FAX ? Vuoi la copia degli articoli ?


 Hai un FAX ? Vuoi la copia degli articoli ?
Se hai una copia da mandarmi via altro mezzo che non sia il fax sarebbe
preferibile.. BTW passa via mail che e' meglio.


Un bel PGP (o GPG) a 2048 bit ?
2048 bit?
'sagerato :-)
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(per rispondere via email fai un rot13 dell'indirizzo)
(apply a rot13 to reply)

 insicure.
Vero, ma
1) con prestazioni indegne
2) chi si fida completamente dei suoi strumenti va incontro a guai.


 la sentenza :-) )
E che c'entra bill adesso? Qui stiamo parlando di cose serie ^_-


modo sufficientemente sicuro, da un amministratore incapace.. 
SEMPRE. Oggi puoi avere un sistema sicuro al 100%. Domani si puo'
scoprire un bug in ipchains e un altro in postfix.
"Una perpetua vigilanza e' il prezzo della liberta'": B. Franklin


 E che c'entra bill adesso? Qui stiamo parlando di cose serie ^_-
Lo so ma non abbiamo detto che cazzeggiare ogni tanto non fa male? :-))


 "Una perpetua vigilanza e' il prezzo della liberta'": B. Franklin
Leo, io sono uno di quelli che predica che un amministratore degno di
tale nome dovrebbe *sempre* provvedere a tenere aggiornato il suo
sistema per prevenire buchi di sicurezza.


"corromperlo".
Direi *molto* esigua.
Hai un computer quantistico che fattorizza numeri di 2048 bit? :-)
