Re: [Bobs-devel] rsync over ssh -> ready

[Jochen M. | steptown.c. <j.m...@st...>]

Hi,

sorry, I did not read that email yet. Sorry 
the question if it is implemented o.k. with
"backup_method" => "none" is superfluent 
now.

> > I think browsing the files just makes sense, when you can restore them..
> > What is your opinion Rene and Joe.
> > 
> 
> You could be right. I'm fine with that solution.
> 
Ok. fine for me too.
> > > 
> > > 1. No access to the UI at all.
> > > Simple to implement.
> > > 
> > THAT was the I did it now:
> > 
> Yes. I'm fine fine with this solution as implemented.
> 
> 
Pretty.

> > > 3. Access to the UI, and ability to restore to the originating server.
> > > Could be complex. How hard I'm really not able to say at the moment.
> > > I'm a bit rusty on the internal workings of bobs.
> > I would appreciate 3. of course:
> > 
> 
> I'll take a closer look at implementing this. Sftp looks good to me and
> this would give bobs a great new feature which would be useful to a lot
> of people. Including myself.
> 
Fine.

> > The scenario I am thinking about at present, is:
> > 
> > A user having an account on our webserver can 
> > open the bobs-browser on the backup-machine
> > and login with his account data (which is equal to his account
> > on the webserver)
> 
> I would suggest getting rid of the dropdowns completely in that case.
> Make the users type in the servername and sharename they wish to access.
> They would get some fairly large dropdowns if you have a lot of users.
> 
Hmh, I did not get the point. What do you mean.
I just wanted to figure out, that it might be possible, that the admin
uses another user to access the remote server with rsync / ssh.

This of course makes sense, cause otherwice you have to create a private
and public key for every user on the remote server. Which is an overhead
in my opinion. 

The accounts on the bobs server should be based on the webserver account
though, because a user "web1" should not be able to restore the files 
from user "web2".

1. So the admin creates a share "/home/www/web2" which he accesses with
root or admin or something else with rsync/ssh to back it up.
The username and password will be "web2" and "web2password" though for
the restore gui

2. He creates another share "/home/www/web1" which he accesses with root
or admin or something else with rsync/ssh to back it up.
The username and password will be "web1" and "web1password" though for 
the restore gui

That is also the way it works at present.

Did you mean something else?

> 
> Actually this seems to be rather easy to implemnt if we are using
> private/public keys and sftp to do the copying.
> 
> > 
> > mhm, can you have a look at current solution (1.) and tell me if 
> > if it fits or something like (2.) would be better?
> 
> Well. 1. works and doesn't present a problem. 
> 

> > BTW... could you give me a commit access to sf.net like suggested?
> 
> Yes. I just need your sourceforge user number and/or sourceforge
> username. 
> 
Fine I'll check that out.

> 
> Joe, do you have any comments on the changes proposed?
> 
> Otherwise I'll merge this and then have a go at make rsync_ssh 
> restoring work.
> I'll also bump the version number to 0.6.1 and include a doc 
> describing how to make a key pair for the auth part.
> 
Fine fine...

Cheers 

Jochen