Re: [Bobs-devel] .. using bobs for internet servers ....

[Jochen M. <ml...@om...>]

Am Son, den 28.12.2003 schrieb Joe Zacky um 01:31:

> >First of all I think that BOBS is a masterpiece of software.
> >I have installed it at a clients place, using it for his 
> >Fileserver (this is only Intranet though).
> >
> I think Rene did a great job and filled a vacant niche. It's hard to 
> come up with new software ideas. That's primarily why I joined this project.

Yes, that is pretty true... 

> 
> >
> >My current approach is to use it for backupping a mixture
> >of Intranet (2x) and Internet-Server (2x). 
> >
> >Approaching this my preferred backupping method is rsync 
> >through ssh. 
> >
> >Well, I have come through some obstacles concerning this:
> >
> >1. I do not want to have an rsync - daemon running on
> >   the Internet Server, but I have seen that class_backup.php
> >   (method: rsync_backup) uses one.
> >
> >2. I want to use user and pw for ssh. 
> >
> >3. I do not want to write a rsyncd.conf file on every server.
> >   At present with to Internet-Servers it is not problem,
> >   but of course you can do without, and it would be less 
> >   overhead like this.
> >  
> >
> Are you saying ssh can be used in place of rsync to copy the files from 
> one machine to the other? I've not used ssh that way before. Can you 
> give some more details on this?

Well, I have been spending about one day to get into the SSH / rsync
stuff.

There are to ways of using rsync:

o Use a daemon running on an own port ( started by e.g. rsync --daemon )
  (AFAIK this will make it impossible to use ssh
   - so the option 
  "-e ssh" in class_backup.php ( method rsync_backup) is IMHO 
superfluent (which also causes the error mentioned in the mailinglist)

o Use rsync in conjunction with ssh. So rsync makes an ssh tunnel and   
calls rsync on the remote server.

There is one easy way to figure out which one you are using:
(= difference between ":" and "::")

Example:
1. rsync -vre ssh /local/path ro...@re...::/save/here

Here the daemon (remote sync server) is used, cause you use "::".
(Refer to the manpages (man rsync) Section GENERAL
 There are six ways different ways of using rsync:
)
   So it would be the same to write:
   rsync -vr /local/path ro...@re...::/save/here

2. rsync -vre ssh /local/path ro...@re...:/save/here

Here we only use one ":" so the connection is done over a 
"remote shell program as the transport (such as rsh or ssh)"
(quoted from manpages)

=========

I would appreciate the second way, cause there are some advantages:
o secure connection
o not necessary to create rsyncd.conf on each backupped machine (less
overhead)
You do not need to create Shares.

o makes it possible (and secure) to backup internet hosts.
o no additional ports open on internet host.


There is of course an obstacle concerning the password:
>>>>>>>>
After studying a while, I found out, that the best way,
is to use authorized keys (private/public key),
cause there is no "plain" password for the backuped
server remaining on the backup server.

The thing is that you first have to create the authorized
keys and transfer them to the backuped server to get every
thing working.

Well, I have done this this way:
( I know using root is not the best way, but it is a
  present the way with the less overhead concerning right etc.)

Steps:
======
1. Login as root on the backup server.
2. ssh-keygen -t dsa
(it takes a while - about 5 minutes till the first output comes up)
Press Return (without entering a password) when prompted for passphrase
Press Return a 2nd time (without entering a password) when prompted for
passphrase a second time
(If additional questions are given always press return without further
input)
3. The DSA-pair is created in ~/.ssh/
   The following files can be found there now:
   id_dsa (private key - has to remain - and only there - on the
backupserver)
   id_dsa.pub (public - has to be transfered to all the backupped
machines)
4. cd .ssh
5. Now make up a sftp connection to backuped server as root
   ( you have to use the same user both on the backup (local machine)
     and the backupped server (remote machine))
   sftp ro...@re...
   
   #Now you are prompted for the password:    
   mypassword [ENTER]   

   # Transfer the public key now 
   cd .ssh
   put id_dsa.pub

   # Jump to Shell by just entering "!"
   !

   # Create a file authorized_keys2 or just add a line with the public
   # key of the backup server to it
   cat id_dsa.pub >> authorized_keys2
 
   # remove the public key - just for nicer clean up
   rm -f id_dsa.pub

   # exit the connection
   exit

6. Make up a test connection 

   ssh ro...@re...
 
   # you should now not be prompted for the password anymore

7. Everything should work beautifully now

REMARK:
Doing it this way, only the backup server can connect to the
backupped machine (Remote Server) BUT NOT vice versa, which
is great.

Sorry, I am sure, you know all these steps, but to make the process
clear and maybe think about how it can be automated, I wrote it 
down. And maybe it can used for the docs.

( and additional remark:
  Difference between RSA and DSA. You come accross these in conjunction 
  with autorized keys:

  DSA is newer.
  DSA is OpenSource.
  DSA seems to be slightly safer.
 
  But they do not have that great difference. RSA seems to have been 
  cracked a couple of times more. That's it
)


Security Issues:
================

I think it is time to think about some security issues here concerning
an internet host.

1. I think it is okay, that the BackupServer can connect to the 
   Backuped Machine (RemoteServer) with authorized keys, but it
shouldn't work the other way round. 
 
   So the backupServer running with bobs can also be behind a firewall
   Thinking of Internet Host in my opinion it would be to dangerous to 
   allow a connection from the Internet Host to the BackupServer.

2. I have added a "none" - restore method, to be able to work with that
   at present for our Internet Hosts, because
   
   smb and nfs 

   are to insecure for that purpose.

   I have implemented it that way, that the Server also does not come
   up when calling:

   http://bobsdomain/bobs/
   
   This shall be a quick interims solution till it is clear, which
restore method for internet hosts could be appropriate.

3. Restore method for Internet Hosts.

   This is really a problem, cause 

   NFS and smb seems to dangerous to me.
   But:
   The 2nd most important thing is, that you to have a daemon running
   on the other side (The Remote (backuped) Server)

   A suggestion would be, to make up connection with rsync over ssh
   and use that.

   So, the backupServer makes up the connection and puts them to 
   the backuped machine.

   What do you think about that?


====

So hopefully, I have come to end for the first mail.
I'll work on the issue of rsync / ssh  - backup, to
get that working.


Looking forward to your feedback

Cheers

Jochen Metzger
Berlin, Germany



 










The good structure of the sources makes it easy to get into it.










> 
> >Another smal obstactle is the following:
> >4. When creating a new share and using "/" in the descriptive name
> >   the system will take it, but display an error, cause
> >   the corresponding ini-file (e.g. inc/servers/domain.share.inc)
> >   can not be created correctly.
> >
> >   -> What would be the best way to change this ? 
> >   Display an error? Or maybe change "/" in "_" while creating?
> >  
> >
> I think an error message would be appropriate. As discussed in your 
> other email, it's really a name and not a description.
> 
Well I've done that already. I assumed the way, you suggested here.
I'll send the diffs to the mailing list, as soon as I have checked out
the version from cvs.




> >So my questions are:
> >
> >1. Is there an approach towards this ?
> >2. Is this interesting for bobs and further development.
> >   When making changes, the best is, in my opinion, doing 
> >   it in a way, that it can be reused for the next version
> >
> I'd be wary of running an rsync or smb daemon on an internet server too. 
> So if it can be done with ssh it would be more secure. I thinks that's 
> worthwhile and interesting.
> 
> >3. I have to make changes, so I would like to discuss, what would
> >   be the best way 
> >4. How can I communicate the changes? Should I put them in the  
> >bugs-list (bugzilla or whatever sourceforge uses)?
> >  
> >
> Download the CVS version to a development directory on your pc. 
> Instructions on how to do that are under "Anonymous CVS Access" at 
> http://sourceforge.net/cvs/?group_id=54656

Yeah, I'll do that.

> If you want to share the changes, run 'diff' on the files you change and 
> post them to this list.

OK, I'll do it this way. I have already documented some small changes.

> 
> If you really want to get into it, perhaps Rene would add you to the 
> developer list and you could upload the changes. Someone should work on 
> this project and Rene and I haven't done anything in months.

Well, of course I can do some changes, that will make the project
better. Based on my situation of being forced to earn money with my
own business to feed my family, I think it wouldn't have to time
to join the project as a developer.

Of course I can commit minor changes though to keep the overhead mini-
malistic. I'll do it the best way for you ( either diffs or commit
directly)


> 
> Thanks for your interest,
> Joe Zacky
> 
Thanks for your feedback.