Re: [Xen-users] Xen administration tools (for multiple Xen servers)?

[Tim Post <tim.post@xxxxxxxxxxxxxxx>]

On Fri, 2007-02-16 at 16:33 +0000, Daniel P. Berrange wrote:

> The ability to manage multiple hosts remotely is work in progress. Rather
> than hacking something in using SSH tunnelling, we're trying to get a
> long term supportable remote management capability written in libvirt which 
> will support Xen, QEMU, KVM to avoid lock-in to one virt platform. I expect
> it'll be 2-3 months before we do a release of virt-manager which enables
> this remote management capability.

I have something 'ssh like' which supports remote calls and sftp. Server
size is under 56k stripped statically linked with blowfish / md5 using
its own random challenge authentication. Client is also tiny, it was
developed for small memory model systems and revived / redone for Xen. 

Its not yet in a state that I want to release it, but I can (and will)
make it available to any who reply off list.

example use : 

srce -k /root/node2.key -s node2.mydomain.com EXEC "xm list" 
srce -k /root/node3.key -s node3.mydomain.com -o /var/templates GET
'file.img'
srce -k /root/node4.key -s node4.mydomain.com PUT "/var/domu.img"

Sample daemon config :

keyfile=/root/.srce-key
fileroot=/var/srced/journal
putroot=/var/srced/putroot 
execroot=/var/srced/exec
lockdir=/var/run
logfile=/var/srced/log/srced.log
ipfile=/etc/srced/srced.allow
loglevel=2
port=9500
noexec=no
encrypt=yes
interface=127.0.0.1,192.168.1.10

Simply explained, if a symbolic link to a binary or script (or just a
binary or script) exists in the execroot, it can be run remotely, unless
noexec is set to true in the config. You can also write scripts to offer
limited functionality of stuff like ls / etc, allowing only parts of it
to be used.

fileroot is the root where files can be retreived

putroot is the root where files can be put

On trusted networks, you can turn off encryption (blowfish), however
this is sparse to begin with, really no need for disabling it.

Its been in production about 2 years now over 300 + machines without
incident, it also lets you easily specify what IP's are 'allowed' to
connect and do business, though I much more recommend using tcp
wrappers. This is also not (yet) PAM-able, but will be, its a work in
progress but stable and proven enough for use. 

Pretty much everything you need out of SSH to manage large farms,
without the bloat.

The challenge response was written with promiscuous bridges in mind. A
keyfile looks like this :

piv6d7z9Uhbayf8k43gK6pAlMIQBRTLk
dI1yYQetH3MKeoHQejrsN4dQyjXqjMfZ
85cgtJFnyXi6GlPvOC71p8VDaTLOcIQs
ShxeIqftpqsRbUm469XkiZq8t6jdBOO9
dszOA4FZzOmrbkBRxSy1vMFOSKjuAfqe
SaquOwHSTe6ynKMzy9QwUwmXDVdatbUQ
9xTmZKaz8vkwKM4M2Pg4yaSPxjTZJYZJ
njW7ozwuf3sSvRy6u7GZ58KfMCUpyJnz
KONcPC7FBdpHTaqUAoweACQhtKiuX7Mt
U68yk3NKbNHfPjK6nDe18sgmQhMrI5SF
R79xI7SHEC1yKhbMckeyXkdOCXNnZIE5
DvWOdO4ZDheauJquKvsM3gGPIlzLQEMm
9g3b0FQrY5UwwDfnxzWXN4xu8y7GPnxR
yinWCXEDAqZULYDkNNzxREBpZvullK8T
kU4ad0fvkWDmcsarudxYgKMsFYHdHY19
SBNHNoq5PtOtO6OU80JPDVOaBxNHuBBy
MdRB12zA6vuQu9DpYveXDIBDjPY2AGBF
8qoqrgep8ChXzp5ryUMa1iZvgNvMCM6b
IyAxEEUag1Wy5Lapdx1g07QZ7wKjHNTx
kOV9dUcDGpnylqEG5lS3jq5tVQpCmAI1
BczC8H4qnFGpDQWbCUGyJdOM9nkpe36H
jM3qNlRs0bnPgZUvpyBEU88kk97kThNZ
MxNvEZHxWq6caA7DX7mfdvchJqi8SF7y
qSLKZG87m8XtOaMEsYJfB1cYGo3hPFGt
O55xPl0d9lkjjYBVgaGCFqOVMjsEjAGW
1BTmNWPZID4gJH0OehtFykCZiReVwO3L
eL7KhJpoGfdoxrk1sVAKfUGSJO7QBE3A
UHpeGqk3xRGldospnol3DHHmSHisfveY
BthqUJ5De30EqZCYge71fDzQOv6JmcDt

Client presents an AUTH request and the first line of they key, server
then asks for random lines from it (how many is up to you but you'll
need to modify a little code to ask for more than one). Client then
presents the lines the server asked for, and authenticates. 

So, at no time is the entire key presented, nor will the same 'dance'
get you in twice. 

Requirements : gcc and tcp/ip , its low level C and platform
independent. I have yet to try it on *bsd, but I don't think it will
have any issues. Its been tested on :

Debian 3.1 / Etch
Ubuntu Hoary, Dapper, Breezy, Edgy
FC3, 4, 5
CentOS 4.3 and 4.4

It should have no issues on (but was not tested on)

RHEL (*)
SuSE (*)
Gentoo (*)
*BSD

selinux was NOT enabled during testing, but wouldn't present a problem.

I also have a very easy to use PHP class to go along with it which just
uses exec() to use the client and interprets the results and exit level.
The client just exits with whatever level the remote command gave.

Installs in about 30 seconds, if someone wants to tinker just shoot me
an e-mail. While this doesn't do everything Dan was talking about, it
solves the short term problem.

SRCE assumes you have something on the other end to take arguments. For
instance, 

EXEC "setupvm domain.com"

where setupvm is a shell script that uses wget / lynx / curl / xmlrpc
(whatever) to fetch the data needed to create "domain.com" from
somewhere central and call on other scripts to do things like setup
volume groups and copy templates / make config files with the right
vaules in them, etc. 

This is not an out of the box solution, but a building block to make
things easier, if anyone is interested or needs it. It will be released
(officially) when Gridnix (gridnix.com) itself is released the middle of
this year.

Its currently managing :

Xen farms
OpenVZ / Virtuozzo Farms
Plain old Linux servers
Linux appliances (LB's and FW's)

Working on a set of scripts to integrate it with Vyatta, but that's a
long ways away.

Be forewarned, this does have a laundry list of things yet to finish,
but should work if you just need to get an automated farm up in a hurry.

Best,
--Tim


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