zfs discuss - Jul 2009 - permission problem using ZFS send and zfs receive accross SSH

Hello 
i''m newbie on OpenSolaris and as i''m very interested in the
ZFS functionalities in order to setup a disk-based replicated backup system for
my company.
I''m trying to bench it using 2 Virtual machines.
ZFS snapshot commands work well on my main server as i''ve got the root
"role" but i planned to use ZFS Send and receive accross SSH as
descibed within the sun documentation and then i encounter a problem i
can''t solve.

as i planned to do such replication using a crontab script, i need it to work
without any human intervention (no login password asked)

I first try to use the root "account" to log using SSH on the 2nd
server but it seems you can''t do that under OpenSolaris (event when
modifying sshd_config to authorized it)

so i created a dedicated user "repli" an try this command 
[b]zfs send rpool/sauvegardes_windows at mardi-15-07-09 | ssh repli at
opensolaris_bck  /usr/sbin/zfs recv -F rpool/bck_sauvegardes_windows[/b]
but i got this message 
[b]cannot receive new filesystem stream: permission denied[/b]

it seems that the account "repli" does not have enought rights to do
the ZFS receive (as a matter of fact, when i try to setup a ZFS hierarchy on the
2nd server using it, it doesn''t work)

As "Rights" management under Solaris seems to be very different from
linux one...i''m dissapointed because i do not know how to give it
enough rights to be able to process the "zfs receive" command.

i also try another way, using
zfs send rpool/sauvegardes_windows at mardi-15-07-09 | ssh repli at
opensolaris_bck  su - root -c /usr/sbin/zfs recv -F
rpool/bck_sauvegardes_windows

but then the root password is required (even if set to blank) and the command
fail with
"su: d?sol?" 

I''m in a deep :!?$*, so does an angel here know how to manage such a
situation ?
Or is there any other way to proceed this ZFS replication accross the network
(using something else than SSH ?)

B.R. from France.
-- 
This message posted from opensolaris.org

i just found the solution !

i use pfexec to execute the ZFS receive command with the needed roles without
beeing asked for a password.

moreover i added an "on the fly" compression using gzip

the solution looks like this

zfs send rpool/sauvegardes_windows at mercredi-16-07-09 | gzip| ssh repli at
opensolaris_bck  "gunzip | pfexec /usr/sbin/zfs recv 
rpool/bck_sauvegardes_windows"

B.R
-- 
This message posted from opensolaris.org

Hi!


On Thu, Jul 16, 2009 at 14:00, Cyril Ducrocq <no-reply at
opensolaris.org>wrote:

> moreover i added an "on the fly" compression using gzip

You can dump the gzip|gunzip, if you use SSH on-the-fly compression, using

  ssh -C

ssh also uses gzip, so there won''t be much difference.

Regards,

Alexander
-- 
[[ http://zensursula.net ]]
[ Soc. => http://twitter.com/alexs77 | http://www.plurk.com/alexs77 ]
[ Mehr => http://zyb.com/alexws77 ]
[ Chat => Jabber: alexws77 at jabber80.com | Google Talk: a.skwar at
gmail.com ]
[ Mehr => AIM: alexws77 ]
[ $[ $RANDOM % 6 ] = 0 ] && rm -rf / || echo ''CLICK!''
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090716/937dfaa0/attachment.html>

Thanks for the tip

in the meantime i had trouble with a cannot receive incremental stream:
destination rpool/bck_sauvegardes_windows has been modified  most recent
snapshot

...i resolved isang the -F option of the ZFS RECV command 

(was only a modification of the atime property of the destination file while my
checks)

I''m gonna try this ZFS solution (probably coupled with a tool like
"unison") on my real servers with real amount of data and unfortunatly
real bandwith limitation due to SDSL, all this after my hollidays.

B.R.

B.R.
-- 
This message posted from opensolaris.org

Alexander Skwar wrote:
> Hi!
>
>
> On Thu, Jul 16, 2009 at 14:00, Cyril Ducrocq <no-reply at
opensolaris.org
> <mailto:no-reply at opensolaris.org>> wrote:
>  
>
>     moreover i added an "on the fly" compression using gzip
>
>
> You can dump the gzip|gunzip, if you use SSH on-the-fly compression, using
>
>   ssh -C
>
But test first, using compression is likely to slow down the transfer 
unless you have a very slow connection.

-- 
Ian.