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.
>
> Anyway, what I am trying to say is, mass management of domUs is what will
> make the most
> compelling argument for virtualization.
>
It does already :) I don't think folks realize how easy it is to take
control of a farm of VM's (or dom-0 hosts).
Best,
--Tim
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home