LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Other *NIX Forums > Solaris / OpenSolaris
User Name
Password
Solaris / OpenSolaris This forum is for the discussion of Solaris and OpenSolaris.
General Sun, SunOS and Sparc related questions also go here.

Notices

Reply
 
Search this Thread
Old 12-11-2007, 11:09 AM   #1
custangro
Senior Member
 
Registered: Nov 2006
Location: California
Distribution: Fedora , CentOS , Solaris 10, RHEL
Posts: 1,933
Blog Entries: 1

Rep: Reputation: 188Reputation: 188
zfs send/recv not working though ssh


Hello,

I've been trying to use the zfs send/recv using ssh. According to the Sun Documentation you can do this:

Code:
host1# zfs send  pool/mydata@111207 | ssh host2 zfs recv pool/bkup/mydatabkup
I've also tried:
Code:
host1# zfs send  pool/mydata@111207 | ssh user1@host2 zfs recv pool/bkup/mydatabkup
And:
Code:
host1$ zfs send  pool/mydata@111207 | ssh host2 zfs recv pool/bkup/mydatabkup
I am getting permission denied errors (i've tried the above commands many ways). I can't ssh into another machine as root; and I can't do a zfs send/recv command as a regular user. So how am I supposed to do this? Am I missing something? Thanks

-C

NOTE: My boss won't allow me to open up ssh for root...in case some of you tell me to do that (I already thought of that)

Last edited by custangro; 12-11-2007 at 11:13 AM.
 
Old 12-11-2007, 11:52 AM   #2
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,486

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
This isn't really a zfs issue, it's just you aren't allowed to remotely execute a command as root.
You can simply use a temporary file on either side. Of course, you'll need some free disk space for that.
 
Old 12-11-2007, 12:03 PM   #3
custangro
Senior Member
 
Registered: Nov 2006
Location: California
Distribution: Fedora , CentOS , Solaris 10, RHEL
Posts: 1,933
Blog Entries: 1

Original Poster
Rep: Reputation: 188Reputation: 188
True, I am not allowed to execute the command on the other side (I already knew that)

But here is what Sun says (documentation); this is verbatim:

Code:
The most common use of the zfs send command is to save a copy of a snapshot and receive the 
snapshot on another system that is used to store backup data. 

For example: 
host1# zfs send tank/dana@snap1 | ssh host2 zfs recv newtank/dana 

When sending a full stream, the destination file system must not exist. 

You can save incremental data by using the zfs send -i option. For example: 

host1# zfs send -i tank/dana@snap1 tank/dana@snap2 | ssh host2 zfs recv newtank/dana
So I am following the documentation and it doesn't work, so I assumed I was doing something wrong. Since Sun recommends using the zfs send/recv commands with ssh, I thought that it would work as listed in the documentation.

Am I missing something?

-C
 
Old 12-11-2007, 12:22 PM   #4
David1357
Senior Member
 
Registered: Aug 2007
Location: South Carolina, U.S.A.
Distribution: Ubuntu, Fedora Core, Red Hat, SUSE, Gentoo, DSL, coLinux, uClinux
Posts: 1,302
Blog Entries: 1

Rep: Reputation: 107Reputation: 107
Quote:
Originally Posted by custangro View Post
I can't ssh into another machine as root; and I can't do a zfs send/recv command as a regular user. So how am I supposed to do this?
Try sticking in an "su root" in the command on the other side. I do not have time to hack around to figure out the proper syntax, but you could get it working in a script and run the script as the parameter to ssh.
 
Old 12-11-2007, 12:25 PM   #5
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,486

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
The sample commands clearly expect you to be able to ssh as root, which you can't by local policy.
 
Old 12-11-2007, 04:32 PM   #6
custangro
Senior Member
 
Registered: Nov 2006
Location: California
Distribution: Fedora , CentOS , Solaris 10, RHEL
Posts: 1,933
Blog Entries: 1

Original Poster
Rep: Reputation: 188Reputation: 188
Quote:
Originally Posted by jlliagre View Post
The sample commands clearly expect you to be able to ssh as root, which you can't by local policy.
The default setting for ssh is to NOT let you ssh as root. So since Sun is documenting that the _best practice_ is to do it like this, I assumed that there was a setting that I was missing.

So if you can't ssh into a machine as root by default (becasue it's a security risk), why is it "clear" that that's the way they (Sun) want you to do it? I don't think it's as "clear" as you made it seem. Solaris has always been known for being stable and secure. Why would they change that for this particular command, and throw away ALL security (being drastic there...but you get my point )?

My command is faulty (I know that...why else would I post); But just because you don't think there's a way besides allowing root to ssh, doesn't mean that that's the only answer.

With all due respect,

-C
 
Old 12-11-2007, 04:43 PM   #7
custangro
Senior Member
 
Registered: Nov 2006
Location: California
Distribution: Fedora , CentOS , Solaris 10, RHEL
Posts: 1,933
Blog Entries: 1

Original Poster
Rep: Reputation: 188Reputation: 188
Quote:
Originally Posted by David1357 View Post
Try sticking in an "su root" in the command on the other side. I do not have time to hack around to figure out the proper syntax, but you could get it working in a script and run the script as the parameter to ssh.
I did this:
Code:
host1# zfs send  pool/mydata@111207 | ssh user1@host2 su - root -c "zfs recv pool/bkup/mydatabkup"
But command still failed. But I liked the idea. I think I'll play around with the syntax and I'll post my findings. Thanks

-C
 
Old 12-11-2007, 04:44 PM   #8
David1357
Senior Member
 
Registered: Aug 2007
Location: South Carolina, U.S.A.
Distribution: Ubuntu, Fedora Core, Red Hat, SUSE, Gentoo, DSL, coLinux, uClinux
Posts: 1,302
Blog Entries: 1

Rep: Reputation: 107Reputation: 107
Quote:
Originally Posted by custangro View Post
But just because you don't think there's a way besides allowing root to ssh, doesn't mean that that's the only answer.
Did you try using a script with "su root" in it? As I mentioned above? With all due respect?
 
Old 12-11-2007, 04:52 PM   #9
custangro
Senior Member
 
Registered: Nov 2006
Location: California
Distribution: Fedora , CentOS , Solaris 10, RHEL
Posts: 1,933
Blog Entries: 1

Original Poster
Rep: Reputation: 188Reputation: 188
Quote:
Originally Posted by David1357 View Post
Did you try using a script with "su root" in it? As I mentioned above? With all due respect?
Ha ha...that's what I like. Good ol fashion American humor.

I'm writing the script right now...I'll see what happens...(how do I start?...hmmm...maybe #!/bin/ksh )

With all due respect...


-C
 
Old 12-11-2007, 05:07 PM   #10
David1357
Senior Member
 
Registered: Aug 2007
Location: South Carolina, U.S.A.
Distribution: Ubuntu, Fedora Core, Red Hat, SUSE, Gentoo, DSL, coLinux, uClinux
Posts: 1,302
Blog Entries: 1

Rep: Reputation: 107Reputation: 107
Quote:
Originally Posted by custangro View Post
I'm writing the script right now...I'll see what happens...(how do I start?...hmmm...maybe #!/bin/ksh )
Don't use ksh... then we'll have one more thing to debug
 
Old 12-11-2007, 07:27 PM   #11
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,486

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
Originally Posted by custangro View Post
The default setting for ssh is to NOT let you ssh as root. So since Sun is documenting that the _best practice_ is to do it like this
You are absolutely right. My understanding is this paragraph isn't describing a best practice but a "most common use ..." that obviously violates the ssh best practice. This may be acceptable depending on the context but anyway I guess the command was kept simple for demonstration purposes.
Quote:
I assumed that there was a setting that I was missing.
There are settings that would allow a similar command to be run without violating the no root ssh rule. More about them later.
Quote:
So if you can't ssh into a machine as root by default (because it's a security risk), why is it "clear" that that's the way they (Sun) want you to do it?
I didn't wrote it was clear Sun wanted you to do that that way, I meant it was clear from the syntax convention used (# prompt) and the ssh parameters that the command was run as root on both sides.
Quote:
I don't think it's as "clear" as you made it seem. Solaris has always been known for being stable and secure. Why would they change that for this particular command, and throw away ALL security (being drastic there...but you get my point )?
To keep the example simple.
Quote:
My command is faulty
The command fails but isn't faulty.
Quote:
(I know that...why else would I post); But just because you don't think there's a way besides allowing root to ssh, doesn't mean that that's the only answer.
I wrote there was no way to run that particular command without allowing root to ssh. I didn't wrote there was no alternatives. Actually, there are several ways to circumvent the issue. Here a some of them.

- Delegating ZFS administration rights for this particular filesystem to a non root user by using the zfs allow [mount/create/receive] subcommand, should you use a recent enough Solaris release (build 69 and newer). http://blogs.sun.com/marks/entry/zfs...administration

- Giving the remote user "Primary Administrator" profile.

- Giving the remote user "ZFS File System Management" profile.

- Granting the remote user the minimum set of privileges required for the command to succeed.

- Using "sudo" or similar command.

- Using a suid wrapper

Last edited by jlliagre; 12-11-2007 at 07:30 PM.
 
Old 12-12-2007, 11:12 AM   #12
custangro
Senior Member
 
Registered: Nov 2006
Location: California
Distribution: Fedora , CentOS , Solaris 10, RHEL
Posts: 1,933
Blog Entries: 1

Original Poster
Rep: Reputation: 188Reputation: 188
Quote:
Originally Posted by jlliagre View Post
You are absolutely right. My understanding is this paragraph isn't describing a best practice but a "most common use ..." that obviously violates the ssh best practice. This may be acceptable depending on the context but anyway I guess the command was kept simple for demonstration purposes.There are settings that would allow a similar command to be run without violating the no root ssh rule. More about them later.
I didn't wrote it was clear Sun wanted you to do that that way, I meant it was clear from the syntax convention used (# prompt) and the ssh parameters that the command was run as root on both sides.
To keep the example simple.
The command fails but isn't faulty.I wrote there was no way to run that particular command without allowing root to ssh. I didn't wrote there was no alternatives. Actually, there are several ways to circumvent the issue. Here a some of them.

- Delegating ZFS administration rights for this particular filesystem to a non root user by using the zfs allow [mount/create/receive] subcommand, should you use a recent enough Solaris release (build 69 and newer). http://blogs.sun.com/marks/entry/zfs...administration

- Giving the remote user "Primary Administrator" profile.

- Giving the remote user "ZFS File System Management" profile.

- Granting the remote user the minimum set of privileges required for the command to succeed.

- Using "sudo" or similar command.

- Using a suid wrapper
Now that's an answer

The zfs allow command is what I was looking...Here I what I got:

Code:
global:/<29># zfs allow
unrecognized command 'allow'
usage: zfs command args ...
Hmm...which made me think (yes, thinking is possible for me )...
Code:
global:/<37># cat /etc/release
                       Solaris 10 8/07 s10s_u4wos_12b SPARC
           Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 16 August 2007
So I assumed that I don't have the proper build. So as a long shot I did:
Code:
global:/<38># man zfs | grep allow
Reformatting page.  Please Wait... done
     aclinherit=discard | noallow | secure | passthrough
         value of "noallow" only inherits inheritable ACL entries
         property which can be inherited. This allows datasets to
So now I did (just for fun)
Code:
global:/<48># zfs set
missing property=value argument
usage:
        set <property=value> <filesystem|volume> ...

The following properties are supported:

        PROPERTY       EDIT  INHERIT   VALUES

        type             NO       NO   filesystem | volume | snapshot
        creation         NO       NO   <date>
        used             NO       NO   <size>
        available        NO       NO   <size>
        referenced       NO       NO   <size>
        compressratio    NO       NO   <1.00x or higher if compressed>
        mounted          NO       NO   yes | no | -
        origin           NO       NO   <snapshot>
        quota           YES       NO   <size> | none
        reservation     YES       NO   <size> | none
        volsize         YES       NO   <size>
        volblocksize     NO       NO   512 to 128k, power of 2
        recordsize      YES      YES   512 to 128k, power of 2
        mountpoint      YES      YES   <path> | legacy | none
        sharenfs        YES      YES   on | off | share(1M) options
        checksum        YES      YES   on | off | fletcher2 | fletcher4 | sha256
        compression     YES      YES   on | off | lzjb
        atime           YES      YES   on | off
        devices         YES      YES   on | off
        exec            YES      YES   on | off
        setuid          YES      YES   on | off
        readonly        YES      YES   on | off
        zoned           YES      YES   on | off
        snapdir         YES      YES   hidden | visible
        aclmode         YES      YES   discard | groupmask | passthrough
        aclinherit      YES      YES   discard | noallow | secure | passthrough
        canmount        YES       NO   on | off
        shareiscsi      YES      YES   on | off | type=<type>
        xattr           YES      YES   on | off

Sizes are specified in bytes with standard units such as K, M, G, etc.


User-defined properties can be specified by using a name containing a colon (:).
It seems that the zfs allow dosen't exist (yet...or at least not on 08/07) but it seems I need to play around with aclinherit and aclmode.

Too bad opensolaris isn't stable enough (at least for my taste) to put it into a production environment.

Oh well...I guess the best thing I can do is use zfs send to a file; scp that file to host2, then zfs get from the file on host2. (I guess I can script that somehow...)

Thanks all for your help

-C

Last edited by custangro; 12-12-2007 at 11:14 AM.
 
Old 12-19-2007, 07:38 PM   #13
custangro
Senior Member
 
Registered: Nov 2006
Location: California
Distribution: Fedora , CentOS , Solaris 10, RHEL
Posts: 1,933
Blog Entries: 1

Original Poster
Rep: Reputation: 188Reputation: 188
SOLVED...well...sort of...

Hey all...

I've solved my send/recv woes using rsh. I know rsh isn't encrypted but my boss says it's ok (for whatever reason).

Side note:

ZFS send uses standard out so it can be redirected to almost anything....


HAPPY ZFSing!

-C
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
high recv-q and send-q and collision rate sarah_haff Linux - Networking 2 08-19-2008 06:49 AM
Simultaneous Socket Send/Recv in Perl? juanbobo Programming 10 07-28-2008 03:30 AM
send/recv binary files with C++ sockets dafatdude Programming 3 02-12-2006 08:02 AM
Post fix can recv mail from outside but cant send. luvonmik Linux - Networking 1 03-30-2004 11:07 AM
Cable modem send/recv constantly /home/kyle Linux - Software 2 03-12-2004 12:09 PM


All times are GMT -5. The time now is 10:29 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration