sbackup remote target fails

Bug #44260 reported by Christopher Barrington-Leigh
6
Affects Status Importance Assigned to Milestone
sbackup (Ubuntu)
Fix Released
Medium
Aigars Mahinovs

Bug Description

Binary package hint: sbackup

I am using the gui interface to sbackup.
There is a "location" tab to select the target for the backup data. The option to send the result straight to a remote server through an ssh pipe does not work.

Dapper.

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

In particular, for any working ssh target I have tried in the form indicated, pushing the "test" button gives "the selected destination is not writtable [sic] with current permissions".

Revision history for this message
Jonh Wendell (wendell) wrote :

It's working now. Fixed in 0.10 version.

Changed in sbackup:
assignee: nobody → aigarius
status: Unconfirmed → Fix Committed
Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

No, it is not working for me, or else I am doing something wrong. I get the same error as before. I am using version 0.10.

Revision history for this message
Aigars Mahinovs (aigarius) wrote :

what do you mean by "ssh pipe"? What exactly are you trying to write into the URL field? (mask the password obviosely) There is currently a bug that shared key logins via ssh do not work correctly. Only username/password authentification is currently supported.

Changed in sbackup:
status: Fix Committed → Needs Info
Revision history for this message
Aigars Mahinovs (aigarius) wrote :

The problem most likely is that ssh key of the server has changed and Gnomevfs rejects connecting to that server on such basis. Try erasing /root/.ssh/known_hosts and see if that helps.

Changed in sbackup:
status: Needs Info → Confirmed
Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

That is a shame about shared key logins, but I've also tried with a target that does not.
I've also tried erasing root's known_hosts. The only difference is that when pressing the "test" button I got a dialogue box warning me that it was an unknown host. I chose to log in anyway, and then got the failure message: "...destination is not writtable [sic] ..." in the main window.

I am trying with, to be explicit:

ssh://robert:<email address hidden>/

or with a further path on the server.

To check it should work: Using "ssh robert@..." at a command line prompts me for a password and the connection is successful.

Can I look for more detailed error messages somewhere?
Thanks!

Revision history for this message
Jonh Wendell (wendell) wrote :

Hi!

You can open a terminal and type:

sudo sbackupd

You'll se the error message there.

By the way, are you putting the right path on ssh string connection?

ssh://robert:<email address hidden>/ --> it's missing the directory part, something like that:

ssh://robert:<email address hidden>:/home/robert

If you want, you can create an user on this machine, and send its password to my email so that i can do some tests from my machine... Feel free to not accept it.

Thank you for your bug report,
 Wendell.

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

Aha.

ssh://robert:<email address hidden>:/home/robert

Something lke that works for me.
But the sample string given in the dialog box is not of that format at all! There is no colon at the end of the host (contrary to ssh convention) in the example.
Moreover, there is no indication that an absolute path is necessary. In normal ssh syntax, the default directory would be the user's home.

So, I think the sample string needs to be corrected.
Also, there is no documentation.
Can there be a link to some documentation for non-hackers?

I would offer to provide some text, but at the sbackup.sourceforge.org wiki, I cannot even create an account for myself.

Thanks!

Revision history for this message
Jonh Wendell (wendell) wrote :

Thank you for your suggestions.
Can you open a new bug with that specifications (Asking for documentation)?

Documentation is very important, we know that. If you want to help [more] by writing docs, feel free to contact Aigars. He's main developer of sbackup. Any help is appreciate.

Bye,
 Wendell.

Changed in sbackup:
status: Confirmed → Fix Released
Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

Thanks.
Documentation is very important once an application is useful and popular! Thank you for sbackup.

I will file a doc bug, but there is also a programming bug, it seems to me:
the sample string in the ssh:// box is wrong. In my version, it reads:

ssh://username:<email address hidden>/remote/dir/

yet strings in this form fail for me.
Thanks,
c

Revision history for this message
Aigars Mahinovs (aigarius) wrote :

I am not sure why the colon is needed for you. It works without the colon for me and the directory is always absoulute as in ssh://username:<email address hidden>/home/user/backupdir

I will try to investigate this how GnomeVFS handles that colon and try to come up with a good way to explain when it is needed.

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote : Partial retraction

Oops! Aigars, I'm sorry it does seem to work without a colon now(!).

It is just the root-based path that I find unintuitive, then, I guess (though I could have sworn I tried that earlier... :( )

It would be best if the user did not have to experiment much to figure it out, ie to guess what "remote/dir" means.

I think your string ssh://username:<email address hidden>/home/user/backupdir
is clearer.

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

Yet another update:
 Okay, maybe this is what had gone wrong before: The "test" function works without a colon, but the actual back up resulted in the following error. With the colon back in, the backup went ahead fine. Anyway, I'm just happy to know one option that works for what I'm doing (scheduled backups), and for me that is with a colon and a full path name.

Date: Sat, 14 Oct 2006 12:00:05 -0700 (PDT)
From: Cron Daemon <root@cpbl-laptop>
To: root@cpbl-laptop
Subject: Cron <root@cpbl-laptop> if [ -x /usr/sbin/sbackupd ]; then
    /usr/sbin/sbackupd; fi;

I: Securing permissions at:
ssh://cpbl:<email address hidden>/homegrad/cpbl/private/backup//2006-10-
02_12.00.09.708563.cpbl-laptop.inc
Traceback (most recent call last):
  File "/usr/sbin/sbackupd", line 404, in ?
    upgrader.upgrade_target( target, purge )
  File "/usr/sbin/upgrade_backups.py", line 60, in upgrade_target
    self.upgrade_tdir( target+"/"+adir )
  File "/usr/sbin/upgrade_backups.py", line 78, in upgrade_tdir
    v = self.openfile( tdir + "/ver" )
  File "/usr/sbin/upgrade_backups.py", line 307, in openfile
    return gnomevfs.open( uri, 1 )
gnomevfs.NotFoundError: File not found

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

Sorry.. i've posted a few times lately without enough experimention. You can ignore the last post. I don't konw what's going on. I still don't have a smoothly working backup, but I don't know why.

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

I've listed the gnomevfs.NotFoundError failure mode above as a new bug, since I cannot get a working backup:

https://launchpad.net/distros/ubuntu/+source/sbackup/+bug/67814

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.