Bug#833129: usage with sudo

2016-08-08 Thread John Goerzen


On 08/08/2016 04:22 AM, helix84 wrote:
> I'm not quite sure how.
>
> Calling simplesnapwrap from backuphost directly seems to succeed
> (though I can't see the output anywhere):
>
> backuphost:~$ ssh -i /home/ivan/.ssh/id_rsa_simplesnap -l
> ivan activehost sudo simplesnapwrap listfs

Use -l root and authenticate to the root account instead of a user account.

John



Bug#833129: usage with sudo

2016-08-08 Thread helix84
I just realized that exit code 10 comes from the command ssh runs, that is
simplesnapwrap. It's not helpful that simplesnapwrap uses code 10 for
everything... but the server-side syslog shows us the culprit:

Invoked with parameters "" and SSH_ORIGINAL_COMMAND: "sudo simplesnapwrap
listfs"
Reinvoking to parse parameters
Reinvoked with paramters "sudo simplesnapwrap listfs"
Invalid mode "simplesnapwrap" specified.

I forgot to mention that in the original email, but I just realized that I
already tried this approach and the problem is that simplesnapwrap expects
that $0 is simplesnapwrap, $1 is the command, whereas when running with
sudo, $0 is sudo etc.


Regards,
~~helix84


Bug#833129: usage with sudo

2016-08-08 Thread helix84
I'm not quite sure how.

Calling simplesnapwrap from backuphost directly seems to succeed
(though I can't see the output anywhere):

backuphost:~$ ssh -i /home/ivan/.ssh/id_rsa_simplesnap -l ivan activehost
sudo simplesnapwrap listfs

Calling simplesnapwrap from backuphost via simplesnap using wrapcmd
seems to fail:

backuphost:~$ sudo simplesnap --host activehost --setname mainset --store
backup/simplesnap --sshcmd "ssh -i /home/ivan/.ssh/id_rsa_simplesnap -l
simplesnapuser" --wrapcmd "sudo simplesnapwrap"

Here's the log from backuphost:


Invoked as: /usr/sbin/simplesnap --host activehost --setname
mainset --store backup/simplesnap --sshcmd ssh
-i /home/ivan/.ssh/id_rsa_simplesnap -l simplesnapuser --wrapcmd
sudo simplesnapwrap
Store backup/simplesnap is mounted at /backup/simplesnap
Lock obtained at /backup/simplesnap/activehost/.lock with dotlockfile
Finding remote datasets to back up
Running ssh -i /home/ivan/.ssh/id_rsa_simplesnap -l
simplesnapuser activehost sudo simplesnapwrap listfs
ssh exited with error 10


Logging ssh with -vvv shows that "sudo simplesnapwrap listfs" is run but no
other useful info apart from exit code 10. I'm not sure if I found the
correct ssh exit code definitions (why the minus sign?) but interpreting it
as "invalid argument" leaves me none the wiser.

https://github.com/openssh/openssh-portable/blob/master/ssherr.h#L34


Regards,
~~helix84


Bug#833129: usage with sudo

2016-08-05 Thread John Goerzen
I don't believe this is a bug with simplesnapwrap.  If all of these
commands require root anyway, why not run simplesnapwrap as root? 
(That's what it's designed to do.)

John

On 08/01/2016 03:35 AM, helix84 wrote:
> Package: simplesnap
> Version: 1.0.3
>
>
> Hello, first of all I'd like to apologize that I'm reporting here
> while I tried the package on Ubuntu where things may be set up
> differently. Secondly, thank you for this package, I just set it up
> for the first time along with zfSnap and it is very convenient, it
> exactly fills the niche I had.
>
> The problem on Ubuntu 16.04 (which may not be the case in Debian)
> stems from the fact that zfs is set up to be used via sudo whereas
> simplesnapwrap on activehost calls zfs without sudo (which is
> hardcoded in simplesnapwrap).
>
> My workaround was to add the simplesnap user on activehost to sudoers
> and allow the required subset of zfs commands:
>
> sudo visudo -f /etc/sudoers.d/zfs
>
> Cmnd_Alias C_ZFS_SIMPLESNAP = \
>   /sbin/zfs list *, \
>   /sbin/zfs send *, \
>   /sbin/zfs snapshot *, \
>   /sbin/zfs destroy tank@__simplesnap_*, \
>   /sbin/zfs destroy tank/root@__simplesnap_*
>
> simplesnapuser ALL = (root) NOPASSWD: C_ZFS_SIMPLESNAP
>
> But unfortunately I had to do a modification to
> /usr/sbin/simplesnapwrap on activehost:
> #ZFSCMD=/sbin/zfs
> ZFSCMD="sudo /sbin/zfs"
>
> Then as usual, I run simplesnap on backuphost from cron:
> 6-56/10 *   * * *   rootPATH=/usr/sbin:/usr/bin:/sbin:/bin
> /usr/sbin/simplesnap --host matrix --setname mainset --store
> backup/simplesnap --sshcmd "ssh -i /home/ivan/.ssh/id_rsa_simplesnap
> -l simplesnapuser"
>
> Of course, I hate to do changes to files owned by the package which
> can be overwritten in case of package upgrade, ergo this bug report.
>
> The solution I suggest is to allow the user to specify ZFSCMD as an
> environment variable, thus enabling creation of a "simplesnapwrap
> wrapper" (calling simplesnapwrap with ZFSCMD="sudo /sbin/zfs") which
> can be called from backuphost via --wrapcmd.
>
> If you see another way around it, I'll be happy to hear your thoughts.
> Thanks again.
>
>
> Regards,
> ~~helix84



Bug#833129: usage with sudo

2016-08-01 Thread helix84
Package: simplesnap
Version: 1.0.3


Hello, first of all I'd like to apologize that I'm reporting here
while I tried the package on Ubuntu where things may be set up
differently. Secondly, thank you for this package, I just set it up
for the first time along with zfSnap and it is very convenient, it
exactly fills the niche I had.

The problem on Ubuntu 16.04 (which may not be the case in Debian)
stems from the fact that zfs is set up to be used via sudo whereas
simplesnapwrap on activehost calls zfs without sudo (which is
hardcoded in simplesnapwrap).

My workaround was to add the simplesnap user on activehost to sudoers
and allow the required subset of zfs commands:

sudo visudo -f /etc/sudoers.d/zfs

Cmnd_Alias C_ZFS_SIMPLESNAP = \
  /sbin/zfs list *, \
  /sbin/zfs send *, \
  /sbin/zfs snapshot *, \
  /sbin/zfs destroy tank@__simplesnap_*, \
  /sbin/zfs destroy tank/root@__simplesnap_*

simplesnapuser ALL = (root) NOPASSWD: C_ZFS_SIMPLESNAP

But unfortunately I had to do a modification to
/usr/sbin/simplesnapwrap on activehost:
#ZFSCMD=/sbin/zfs
ZFSCMD="sudo /sbin/zfs"

Then as usual, I run simplesnap on backuphost from cron:
6-56/10 *   * * *   rootPATH=/usr/sbin:/usr/bin:/sbin:/bin
/usr/sbin/simplesnap --host matrix --setname mainset --store
backup/simplesnap --sshcmd "ssh -i /home/ivan/.ssh/id_rsa_simplesnap
-l simplesnapuser"

Of course, I hate to do changes to files owned by the package which
can be overwritten in case of package upgrade, ergo this bug report.

The solution I suggest is to allow the user to specify ZFSCMD as an
environment variable, thus enabling creation of a "simplesnapwrap
wrapper" (calling simplesnapwrap with ZFSCMD="sudo /sbin/zfs") which
can be called from backuphost via --wrapcmd.

If you see another way around it, I'll be happy to hear your thoughts.
Thanks again.


Regards,
~~helix84