I know i''m probably doing something REALLY stupid.....but for some reason i can''t get send/recv to work over ssh. I just built a new media server and i''d like to move a few filesystem from my old server to my new server but for some reason i keep getting strange errors... At first i''d see something like this: pfexec: can''t get real path of ``/usr/bin/zfs'''' or something like this: zfs: Command not found from google it''s mentioned something about nfs but i''ve disabled autofs.. anyways, thanks for any help....i know it is just something stupid but my brain just isn''t working... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100520/16791087/attachment.html>
also, i forgot to say: one server is b133, the new one is b134 On Thu, May 20, 2010 at 4:23 PM, Thomas Burgess <wonslung at gmail.com> wrote:> I know i''m probably doing something REALLY stupid.....but for some reason i > can''t get send/recv to work over ssh. I just built a new media server and > i''d like to move a few filesystem from my old server to my new server but > for some reason i keep getting strange errors... > > At first i''d see something like this: > > > pfexec: can''t get real path of ``/usr/bin/zfs'''' > > > or something like this: > > > zfs: Command not found > > > from google it''s mentioned something about nfs but i''ve disabled autofs.. > > anyways, thanks for any help....i know it is just something stupid but my > brain just isn''t working... > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100520/d4c566a3/attachment.html>
On Thu, May 20, 2010 at 04:23:49PM -0400, Thomas Burgess wrote:> I know i''m probably doing something REALLY stupid.....but for some reason i > can''t get send/recv to work over ssh. I just built a new media server and > i''d like to move a few filesystem from my old server to my new server but > for some reason i keep getting strange errors... > > At first i''d see something like this: > > pfexec: can''t get real path of ``/usr/bin/zfs'''' > > or something like this: > > zfs: Command not foundAdd /usr/sbin to your PATH or use /usr/sbin/zfs as the full path of the zfs(1M) command. Nico --
On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess <wonslung at gmail.com> wrote:> I know i''m probably doing something REALLY stupid.....but for some reason i > can''t get send/recv to work over ssh. ?I just built a new media server andUnless you need to have the send to be encrypted, ssh is going to slow you down a lot. I''ve used mbuffer when doing sends on the same network, it''s worked well. -B -- Brandon High : bhigh at freaks.com
On Thu, May 20, 2010 at 3:42 PM, Brandon High <bhigh at freaks.com> wrote:> On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess <wonslung at gmail.com> wrote: >> I know i''m probably doing something REALLY stupid.....but for some reason i >> can''t get send/recv to work over ssh. ?I just built a new media server and > > Unless you need to have the send to be encrypted, ssh is going to slow > you down a lot. > > I''ve used mbuffer when doing sends on the same network, it''s worked well. > > -B > > -- > Brandon High : bhigh at freaks.com > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >Problem with mbuffer, if you do scripted send/receives, you''d have to pre-start an Mbuffer session on the receiving end somehow. SSH is always running on the receiving end, so no issues there. -- Brent Jones brent at servuhome.net
On Thu, May 20, 2010 at 4:40 PM, Brent Jones <brent at servuhome.net> wrote:> On Thu, May 20, 2010 at 3:42 PM, Brandon High <bhigh at freaks.com> wrote: > > On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess <wonslung at gmail.com> > wrote: > >> I know i''m probably doing something REALLY stupid.....but for some > reason i > >> can''t get send/recv to work over ssh. I just built a new media server > and > > > > Unless you need to have the send to be encrypted, ssh is going to slow > > you down a lot. > > > > I''ve used mbuffer when doing sends on the same network, it''s worked well. > > > > pre-start an Mbuffer session on the receiving end somehow. > SSH is always running on the receiving end, so no issues there. > > And you can always patch OpenSSH with HPN, thus enabling the NONE cipher,which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. -- Freddie Cash fjwcash at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100520/d485df0b/attachment.html>
Le 21 mai 10 ? 02:44, Freddie Cash a ?crit :> On Thu, May 20, 2010 at 4:40 PM, Brent Jones <brent at servuhome.net> > wrote: > On Thu, May 20, 2010 at 3:42 PM, Brandon High <bhigh at freaks.com> > wrote: > > On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess > <wonslung at gmail.com> wrote: > >> I know i''m probably doing something REALLY stupid.....but for > some reason i > >> can''t get send/recv to work over ssh. I just built a new media > server and > > > > Unless you need to have the send to be encrypted, ssh is going to > slow > > you down a lot. > > > > I''ve used mbuffer when doing sends on the same network, it''s > worked well. > > > > pre-start an Mbuffer session on the receiving end somehow. > SSH is always running on the receiving end, so no issues there. > > And you can always patch OpenSSH with HPN, thus enabling the NONE > cipher, which disable encryption for the data transfer > (authentication is always encrypted). And twiddle the internal > buffers that OpenSSH uses to improve transfer rates, especially on > 100 Mbps or faster links.Without patching anything, using arcfour instead of the default cipher increase the transfer rate dramatically. It is bounded by the Gb/s network here, not by ssh. Ga?tan -- Ga?tan Lehmann Biologie du D?veloppement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66 fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr
On Thu, May 20, 2010 19:44, Freddie Cash wrote:> And you can always patch OpenSSH with HPN, thus enabling the NONE > cipher, > which disable encryption for the data transfer (authentication is always > encrypted). And twiddle the internal buffers that OpenSSH uses to improve > transfer rates, especially on 100 Mbps or faster links.Ah! I''ve been wanting that for YEARS. Very glad to hear somebody has done it. With the common use of SSH for for moving bulk data (under rsync as well), this is a really useful idea. Of course one should think about where one is moving one''s data unencrypted; but the precise cases where the performance hit of encryption will show are the safe ones, such as between my desktop and server which are plugged into the same switch; no data would leave that small LAN segment. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
On Fri, May 21, 2010 at 7:12 AM, David Dyer-Bennet <dd-b at dd-b.net> wrote:> > On Thu, May 20, 2010 19:44, Freddie Cash wrote: >> And you can always patch OpenSSH with HPN, thus enabling the NONE >> cipher, >> which disable encryption for the data transfer (authentication is always >> encrypted). ?And twiddle the internal buffers that OpenSSH uses to improve >> transfer rates, especially on 100 Mbps or faster links. > > Ah! ?I''ve been wanting that for YEARS. ?Very glad to hear somebody has > done it.ssh-1 has had the ''none'' cipher from day one, though it looks like openssh has removed it at some point. Fixing the buffers seems to be a nice tweak though.> With the common use of SSH for for moving bulk data (under rsync as well), > this is a really useful idea. ?Of course one should think about where oneI think there''s a certain assumption that using ssh = safe, and by enabling a none cipher you break that assumption. All of us know better, but less experienced admins may not. -B -- Brandon High : bhigh at freaks.com
On Fri, May 21, 2010 at 10:59 AM, Brandon High <bhigh at freaks.com> wrote:> On Fri, May 21, 2010 at 7:12 AM, David Dyer-Bennet <dd-b at dd-b.net> wrote: > > > > On Thu, May 20, 2010 19:44, Freddie Cash wrote: > >> And you can always patch OpenSSH with HPN, thus enabling the NONE > >> cipher, > >> which disable encryption for the data transfer (authentication is always > >> encrypted). And twiddle the internal buffers that OpenSSH uses to > improve > >> transfer rates, especially on 100 Mbps or faster links. > > > > Ah! I''ve been wanting that for YEARS. Very glad to hear somebody has > > done it. > > ssh-1 has had the ''none'' cipher from day one, though it looks like > openssh has removed it at some point.Correct. It was available in early OpenSSH version, but then removed as it could compromise security. And the OpenSSH devs continue to reject any patches that re-enable the "none cipher" for this reason.> Fixing the buffers seems to be a nice tweak though.Yes, this really makes a difference. We were initially bottlenecked by SSH (100-200 Mbps) for our rsync connections (gigabit fibre between buildings) between two FreeBSD servers (low CPU use, medium drive I/O). Bumping the buffers to 16384 on each side increased it to over 500 Mbps (now limited by CPU). We''ve since dropped it to 4096, as we have a lot of non-HPN-enabled remote sites we need to rysnc from, and anything over 4096 causes the connection to drop (remote end can''t keep up).> > With the common use of SSH for for moving bulk data (under rsync as > well),> this is a really useful idea. Of course one should think about where one > > I think there''s a certain assumption that using ssh = safe, and by > enabling a none cipher you break that assumption. All of us know > better, but less experienced admins may not. > > That''s the gist of the OpenSSH devs'' reasoning for rejecting the HPNpatches everytime they are submitted. :) -- Freddie Cash fjwcash at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100521/7ba92eb3/attachment.html>
On Fri, May 21, 2010 12:59, Brandon High wrote:> On Fri, May 21, 2010 at 7:12 AM, David Dyer-Bennet <dd-b at dd-b.net> wrote: >> >> On Thu, May 20, 2010 19:44, Freddie Cash wrote: >>> And you can always patch OpenSSH with HPN, thus enabling the NONE >>> cipher, >>> which disable encryption for the data transfer (authentication is >>> always >>> encrypted). ?And twiddle the internal buffers that OpenSSH uses to >>> improve >>> transfer rates, especially on 100 Mbps or faster links. >> >> Ah! ?I''ve been wanting that for YEARS. ?Very glad to hear somebody has >> done it. > > ssh-1 has had the ''none'' cipher from day one, though it looks like > openssh has removed it at some point. Fixing the buffers seems to be a > nice tweak though.I thought I remembered a "none" cipher, but couldn''t find it the other year and decided I must have been wrong. I did use ssh-1, so maybe I really WAS remembering after all.>> With the common use of SSH for for moving bulk data (under rsync as >> well), >> this is a really useful idea. ?Of course one should think about where >> one > > I think there''s a certain assumption that using ssh = safe, and by > enabling a none cipher you break that assumption. All of us know > better, but less experienced admins may not.Seems a high price to pay to try to protect idiots from being idiots. Anybody who doesn''t understand that "encryption = none" means it''s not encrypted and hence not safe isn''t safe as an admin anyway. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
On Fri, May 21, 2010 at 11:28 AM, David Dyer-Bennet <dd-b at dd-b.net> wrote:> I thought I remembered a "none" cipher, but couldn''t find it the other > year and decided I must have been wrong. ?I did use ssh-1, so maybe I > really WAS remembering after all.It may have been in ssh2 as well, or at least the commercial version .. I thought it used to be a compile time option for openssh too.> Seems a high price to pay to try to protect idiots from being idiots. > Anybody who doesn''t understand that "encryption = none" means it''s not > encrypted and hence not safe isn''t safe as an admin anyway.Well, it won''t expose your passwords since the key exchange it still encrypted ... That''s good, right? Circling back to the original topic, you can use ssh to start up mbuffer on the remote side, then start the send. Something like: #!/bin/bash ssh -f root@${RECV_HOST} "mbuffer -q -I ${SEND_HOST}:1234 | zfs recv puddle/tank" sleep 1 zfs send -R tank/foo/bar | mbuffer -O ${RECV_HOST}:1234 When I was moving datasets between servers, I was on the console of both, so manually starting the send/recv was not a problem. I''ve tried doing it with netcat rather than mbuffer but it was painfully slow, probably due to network buffers. ncat (from the nmap devs) may be a suitable alternative, and can support ssl and certificate based auth. -B -- Brandon High : bhigh at freaks.com
I seem to be getting decent speed with arcfour (this was what i was using to begin with) Thanks for all the help....this honestly was just me being stupid...looking back on yesterday, i can''t even remember what i was doing wrong now....i was REALLY tired when i asked this question. On Fri, May 21, 2010 at 2:43 PM, Brandon High <bhigh at freaks.com> wrote:> On Fri, May 21, 2010 at 11:28 AM, David Dyer-Bennet <dd-b at dd-b.net> wrote: > > I thought I remembered a "none" cipher, but couldn''t find it the other > > year and decided I must have been wrong. I did use ssh-1, so maybe I > > really WAS remembering after all. > > It may have been in ssh2 as well, or at least the commercial version > .. I thought it used to be a compile time option for openssh too. > > > Seems a high price to pay to try to protect idiots from being idiots. > > Anybody who doesn''t understand that "encryption = none" means it''s not > > encrypted and hence not safe isn''t safe as an admin anyway. > > Well, it won''t expose your passwords since the key exchange it still > encrypted ... That''s good, right? > > Circling back to the original topic, you can use ssh to start up > mbuffer on the remote side, then start the send. Something like: > > #!/bin/bash > > ssh -f root@${RECV_HOST} "mbuffer -q -I ${SEND_HOST}:1234 | zfs recv > puddle/tank" > sleep 1 > zfs send -R tank/foo/bar | mbuffer -O ${RECV_HOST}:1234 > > > When I was moving datasets between servers, I was on the console of > both, so manually starting the send/recv was not a problem. > > I''ve tried doing it with netcat rather than mbuffer but it was > painfully slow, probably due to network buffers. ncat (from the nmap > devs) may be a suitable alternative, and can support ssl and > certificate based auth. > > -B > > -- > Brandon High : bhigh at freaks.com > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100521/4750d34e/attachment.html>
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Brent Jones > > Problem with mbuffer, if you do scripted send/receives, you''d have to > pre-start an Mbuffer session on the receiving end somehow. > SSH is always running on the receiving end, so no issues there.Could you use ssh to start the mbuffer session?