Hala ssh üzerinden yazılmakta olan bir dosya nasıl kopyalanır?


20

Durum şu:

  1. A istemcisinden sftp kullanarak bir sunucuya büyük bir dosya yüklüyorum.
  2. Ayrıca bu dosyayı sunucudan istemci B'ye ssh üzerinden indirmem gerekiyor.

Ne yapmak istiyorum yükleme hala istemci A gerçekleşiyorsa sunucudan istemci B'ye aktarma başlatmaktır.

Bunu yapmak için en iyi yöntem / araç nedir?

GÜNCELLEME :

Şimdiye kadar cevaplar ilginç - hepsini okuyup test edeceğim. A İstemcisinin dosyayı nasıl yüklediğini kontrol etmeye bağlı olmayan cevaplar için bonus puan. (yani A istemcisinden bildiğimiz tek şey, dosyanın bilinen bir dosya adına yazılmasıdır.)


Ooo, güzel soru. Bu kesinlikle mümkün, ama onu uygulayan hiçbir şeyin farkında değilim
Michael Mrozek

Yanıtlar:


10

SFTP kullanmak yerine tek bir dosya için, gönderen taraftaki catveya pvgönderen ve teeorta sunucudaki verileri hem orada bir dosyaya göndermek hem de diğer taraftaki başka bir ssh bağlantısı üzerinden bir kopya göndermek için ssh üzerinde dosya oluşturabilirsiniz. sadece verileri bir dosyaya yazar. Tam voodoo gerekli Okuyucu için bir egzersiz olarak bırakacağım, çünkü şu anda oynamak için zamanım yok (üzgünüm). Bu yöntem yalnızca, ikinci hedefe SSH aracılığıyla herkes tarafından erişilebiliyorsa işe yarar; bu, istemci makine olarak tanımladığınız durumda olmayabilir.

Daha az "çalıştır ve bekle" olan ancak aksi takdirde daha kolay olabilen başka bir yaklaşım, rsyncsunucu ve istemci B arasında kullanılmasıdır . Bunu ilk çalıştırdığınızda verilerin kısmi bir kopyasını alabilir, ancak yeniden çalıştırabilirsiniz. daha sonra daha fazla veri almak için (Client1-> Server aktarımı tamamlandığında son bir çalışma ile). Bu, yalnızca sunucu verileri SFTP aktarımı sırasında doğrudan doğru dosya adına koyarsa çalışır (bazen dosya tamamen aktarıldıktan sonra yeniden adlandırılan verilerin geçici bir dosyaya gittiğini görürsünüz - bu, dosya güncelleme daha atomik ama rsync fikrini kullanılamaz hale getirecektir). Ayrıca scp yerine C1-> S transferi için rsync kullanabilirsiniz (--inplaceyukarıda belirtilen sorunu önlemek için seçenek) - rsync kullanmak da büyük bir aktarım sırasında C1-> Server bağlantısı sorunları yaşıyorsa her şeyi yeniden göndermeye karşı koruma sağlar ( rsync --inplace -a --progress <source> <dest>rsync kullanılabilir olduğunda scp / sftp yerine kullanma eğilimindeyim , çünkü bu "aktarma devam" davranışı).

Yukarıdakileri özetlemek için şunu çalıştırın:

rsync --inplace -a --progress <source> user@server:/<destination_file_or_folder>

client1 üzerinde sonra çalışıyor

rsync --inplace -a --progress user@server:/<destination_file_or_folder> <destination_on_cli2>

ilk aktarım tamamlanana kadar art arda 2 kez (daha sonra her şeye sahip olduğunuzdan emin olmak için bir kez daha çalışır). rsyncher seferinde lotun tamamını aktarmak yerine bir konumu güncellemek için gereken mutlak minimum değeri aktarmak konusunda çok iyidir. Paranoya için --checksumseçeneği rsync komutlarına eklemek isteyebilirsiniz (büyük dosyalar için çok daha fazla CPU zamanı alır, ancak gerekmedikçe önemli ölçüde daha fazla veri aktarılmasına neden olmaz) ve hız --compressiçin veri aktardığınız dosya zaten sıkıştırılmış bir biçimde değil.


5

Şu anda deneyemiyorum, bu yüzden bu da başarısız olabilir: Benim fikrim şudur: Dosyanın B istemcisine ulaştığı dizini bağlayın, örneğin, sshfs ile / mnt / server istemcisinin dosya sisteminde. Sonra

tail -c +0 -f /mnt/server/thefileinquestion > ~/finalfile

/ usr / bin / tail: okumak için `+0 'açılamıyor: Böyle bir dosya veya dizin yok - coreutils 7.4
maxschlepzig

Maalesef, -c eksikti. Yukarıdaki cevapta düzelttim.
fschmitt

Tamam, bu konuda gördüğüm bir sorun komut sona ermiyor (-f -> takip ...). Dosya sorgusunun tamamen yazıldığından emin olduğunuzda, bir sigQUIT veya bunun gibi bir şey yayınlamalıdır. Btw, kuyruk sürümünüze ve fs'ye bağlı olarak, kuyruk dahili olarak dosyanın yoklamasını yapar (örneğin her saniye).
maxschlepzig

Bir durumum vardı: HDD'ye video dosyası kaydetme, ancak harici bir USB Flash belleğe kopyalamak istedim, böylece kayıt durur durmaz bir kişiye verebiliyorum. Birden fazla denedim rsync --appendve daha sonra kontrol ettim md5sumama dosyalar asla eşleşmedi. tail -c +0işi benim için yaptı. Ayrıca pv -pterakuyruğun ilerlemesini izlerdim, çalışıp çalışmadığını görmeme izin verir. Henüz çalıştığını doğrulamak için md5'leri kontrol etmeyi bitirmedim, ancak harika görünüyor.
unfa

@ unfa Lütfen aşağıya bir cevap ekleyerek yorumunuzu güncelleyin (yani yorum değil).
Xofo

1

Bunun işe yarayacağını düşünüyorum:

user@clientA:~$ cat file | ssh server "cat > dest"

ve sonra

user@clientB:~$ ssh server "tail +0 -f dest" > file

Veriminizi görmek istiyorsanız pv komutunu ekleyin.


Bunu yazmak tail -c +0mı istediniz ?
tatlı

1

Bunun için bir fifo kullanabilirsiniz. Sadece iki xterm içeren ssh olmadan basitlik için:

Xterm A'da:

$ mkfifo fif
$ cat test.tar.gz | tee copy.tar.gz > fif

Xterm B'de:

$ cat fif > dest.tar.gz
$ cmp test.tar.gz dest.tar.gz
$ echo $?
0
$ cmp test.tar.gz copy.tar.gz
$ echo $?
0

Ssh ile bu satırlar boyunca bir şey olmalı - belki de ssh'deki kaçış karakterini devre dışı bırakmalısınız (-e hiçbiri):

müşteri A:

 $ ssh server mkfifo fif
 $ cat src.tar.gz | ssh "tee fif > copy.tar.gz"

müşteri B:

 $ ssh server cat fif > dest.tar.gz

1

Sorulan orijinal poster gibi bir çözüme ihtiyaç duyan bir durumum var. Bilgisayarımda bir yerde bir hokey maçı kaydediyorum ve başka bir yerde televizyonumda izlemek istiyorum. İki konum arasındaki bağlantı, kopyanın yaklaşık 1.3Mb / s hızında gitmesini sağlar ve kayıt videosu yaklaşık 1.5Mb / s'dir. Yani dosyayı kaydetmeye başladığında kopyalamak istiyorum. Bu şekilde 3 saatlik oyunum yaklaşık 3,5 saat içinde kopyalanacak. Bu yüzden kaydetmeye başladığında kopyalarım ve başladıktan 30 dakika sonra izlemeye başlayabilirim. O zaman neredeyse gerçek zamanlı olarak kesintisiz izleyebilirim. Yani, yeni dosyayı yazarken kopyalayabildiğim sürece. Rsync ve scp gibi araçlarla ilgili sorun, kopyayı başlattığınızda dosyanın boyutuna bakmaları ve bu miktarda veri kopyaladıktan sonra çıkmalarıdır; dosya bu kopya sırasında ikiden fazla büyüse bile. Ve, eğer, sadece bir döngü durduğunda kopyalamak için bir döngüde rsync kullanıyorum, bir sonraki rsync bittiğinde hedef dosyayı yeniden oluşturuyor ve video oynatıcımı öldürüyor ve izlemeye yeniden başlayıp nerede olduğuma hızlıca ilerlemeliyim aniden öldürdüğünde programda. Daha iyi bir çözüm istedim ve bir tane bulamadım, bu yüzden bunun yerine bir araya getirdim:

dd if=2031_20160514030000.mpg |
pv --size 4653819304 |
ssh -C -c arcfour,blowfish-cbc -p 5555 myserver.com 'dd of=/media/TV/2031_20160514030000.mpg'

Peki bu ne yapıyor?

İlk olarak, dosyayı büyüdükçe kopyalamak için dd kullanıyorum. Dosya dd'nin ağ üzerinden gönderebileceğinden daha hızlı büyüdüğünden, dd hiçbir zaman dosyanın sonuna yetişmez. Sonra, "boru görüntüleyici (pv)" boru ve ben bu dosyaların genellikle ne kadar büyük olduğuna dayalı dosya ne kadar büyük olacağını bir tahmin vermek. Bu gerekli değil, ama bir ilerleme ölçer görmeyi seviyorum. Sonra akışı ssh bağlantımla bağlarım. Ssh bağlantı kullanır-C sıkıştırma için kullanılır (ağ bant genişliğini azaltmak ve hızlandırmaya çalışmak), -c arcfour,blowfish-cbcen ucuz şifreleme için (yine işleri biraz hızlandırmak için),-pgüvenlik duvarı bağlantı noktası için hedefte kullanıyorum ve ssh sonunda dosyayı alırken dosyayı yeniden oluşturmak için hedefe dd komutunu çalıştırır. Bu çözüm harika çalışıyor. Dosya oluşturulurken ve sadece kısa bir gecikmeyle kopyalanırken hokey oyununu izleyebilirim.


0

Kuyruk -f yönteminin çalıştığından emin değilim (yine de dosya metin ise). Çünkü kuyruk -f ve sftp aktarımını ve meta bilgilere nasıl güveneceğimi bilmiyorum.

Sftp ilk önce meta bilgileri aktarırsa ve tail -f, daha fazla dosya olmadığını söylemek için meta bilgilere dayanırsa, tail EOF'ler veya null'larla sona erebilir.

Yükleme yolunu önemsemiyorsanız, örn. Bilgisayar 1, bilgisayara 2 yüklemeler, bilgisayar 3'e yüklenirse, sftp yerine en üst bittorent kullanmayı deneyebilirsiniz. Görünüşe göre bunun için tasarlandı.


0

Dosyayı en baştan okumayı deneyebilirsiniz, ancak en azından aynı hızda yazabildiğinizden emin olmanız gerekir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.