LinuxQuestions.org - zfs send/recv not working though ssh

- Solaris / OpenSolaris (https://www.linuxquestions.org/questions/solaris-opensolaris-20/)

- - zfs send/recv not working though ssh (https://www.linuxquestions.org/questions/solaris-opensolaris-20/zfs-send-recv-not-working-though-ssh-606073/)

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)

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.

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

Quote:

Originally Posted by custangro (Post 2987272)

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.

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

Quote:

Originally Posted by jlliagre (Post 2987355)

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

Quote:

Originally Posted by David1357 (Post 2987354)

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

Quote:

Originally Posted by custangro (Post 2987578)

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?

Quote:

Originally Posted by David1357 (Post 2987590)

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

Quote:

Originally Posted by custangro (Post 2987598)

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 ;)

Quote:

Originally Posted by custangro (Post 2987578)

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

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

Quote:

Originally Posted by jlliagre (Post 2987726)

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

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