WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Re: 100% safe way to backup domU: (was Yet another backu

To: tim.post@xxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Re: 100% safe way to backup domU: (was Yet another backup)
From: Nico Kadel-Garcia <nkadel@xxxxxxxxx>
Date: Sat, 13 Jan 2007 12:35:23 +0000
Cc: Ligesh <myself@xxxxxxxxxx>, Ulrich Windl <ulrich.windl@xxxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 13 Jan 2007 04:35:10 -0800
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WSx+ZD8TFPOvD/VADWiHYhjvc8yHlm3wuMLb/PnR1fs0ZiTcbv9RiUu5+XLIWbaenSPa6Uyi99T5VdNgb9CAoDPrYrPP3SCL3l8Bs9eHuWef41Jyiucl1bZune7TSYhv6jrsbjlfiORWvkeFNLJw1tdQQ8u1vvD/PFE7fL6YGD4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1168673073.27886.411.camel@tower>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <200701120328.15461.mark.williamson@xxxxxxxxxxxx> <45A778F5.8776.E1BE48@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20070112113142.GA25976@xxxxxxxxxx> <1168611188.27886.310.camel@tower> <20070112152956.GA508@xxxxxxxxxx> <1168621024.27888.381.camel@tower> <20070113015658.GA13715@xxxxxxxxxx> <20070113020710.GA14121@xxxxxxxxxx> <1168673073.27886.411.camel@tower>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)
Tim Post wrote:
On Sat, 2007-01-13 at 07:37 +0530, Ligesh wrote:
 Sat, Jan 13, 2007 at 07:26:58AM +0530, Ligesh wrote:
On Sat, Jan 13, 2007 at 12:57:04AM +0800, Tim Post wrote:
.. and incremental thereof, on a typical (classic) linux system.

While I agree that lvm snapshots are the easiest way (now), if
developing something better, shouldn't a smaller option come into play?

I'd rather run a daemon on the guests (or kernel module) named xenbackup
than have to take a snapshot of every guest that needed a backup.

Daemon is a good idea--not for backup though.

I have a daemon developed that replaces SSH for all but an interactive
shell. Statically linked with blowfish / md5 its under 100k server size
(stripped) and about 30k client size (stripped). It has some unique
abilities, such as very restricted and regulated RPC, SFTP and other
components.. it was written to control a farm of VM's.
Its not quite baked yet, I'm actually looking for some help finishing it
off.
It should create a PPP over the serial port, which means we can contact it from 
the dom0 using the domain name as the parameter.

Why would TCP be a bad idea, if the daemon had its own built in
deny/allow functionality and ignored everything (including localhost)
but dom-0 talking to it?

 xm exec domain-id "command".


We have :

exec, get, put, reboot, and the options to get or put files from a list
of files. Its name is SRCE (secure remote command execution).
In the daemon config, you define an execroot, and file root. In the
execroot you place symlinks to commands you want to be able to be run
remotely, or write shell scripts to severely limit the functionality of
them vs symlinks.
the file root works in a similar fashion, you put links to files or
directories you want to be accessed via the client.

It also runs very happily in a minimal chroot. It uses a key similar to
SSH, but employs a random access dance.

Client presents the first line of the key, server responds with a random
line , client then presents the requested line. The whole key is never
presented during authentication, and even if sniffed, the same 2 lines
you were able to get would not work again. The first line of the key is
what the blowfish hash is based from. MD5 is used for even more
paranoia.

You can also disable encryption, or the built in tcp wrapper if your on
a known secure bridge / network. The daemon was written for embedded
ULV/ULM systems, its very small, very well written and very efficient.

It was written to deal well (and securely) with promiscuous bridges, Xen
was first and foremost in our minds when we created it.

It would then connect to this daemon through the serial port, execute and return the output. THe daemon would be very small with just the functionality to transfer files and also execute commands and return the output, and you have to configure init to run it as a compulsory service--though the ideal would be to have the kernel make sure of that this service is running. Anyway, I think the problem is that virtualization as such is in a nascent state and
maybe in a couple of years time, someone would implement all of these.

I have this done (almost), in about 30 days I'll be able to release.
While I'm great at designing things , defensive coding is not my
specialty.. so I pay others to do it. The guy who wrote it costs about
80 bucks an hour, and doesn't have much time to give it. So in order to
finish it I think I'll just open it up as open source, once I get a few
things cleaned up in it.

If anyone feels like taking a look at it, shoot me an e-mail.
Can you bring this up over on comp.security.ssh newsgroup? Several of the OpenSSH developers hang out there and are very helpful.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>