zfs send/recv not working though ssh

custangro · 12-11-2007, 11:09 AM

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)

jlliagre · 12-11-2007, 11:52 AM

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.

custangro · 12-11-2007, 12:03 PM

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

David1357 · 12-11-2007, 12:22 PM

Quote:

Originally Posted by custangro

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.

jlliagre · 12-11-2007, 12:25 PM

The sample commands clearly expect you to be able to ssh as root, which you can't by local policy.

custangro · 12-11-2007, 04:32 PM

Quote:

Originally Posted by jlliagre

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

custangro · 12-11-2007, 04:43 PM

Quote:

Originally Posted by David1357

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

David1357 · 12-11-2007, 04:44 PM

Quote:

Originally Posted by custangro

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?

custangro · 12-11-2007, 04:52 PM

Quote:

Originally Posted by David1357

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

David1357 · 12-11-2007, 05:07 PM

Quote:

Originally Posted by custangro

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

jlliagre · 12-11-2007, 07:27 PM

Quote:

Originally Posted by custangro

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

custangro · 12-12-2007, 11:12 AM

Quote:

Originally Posted by jlliagre

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

custangro · 12-19-2007, 07:38 PM

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