| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xend port
OK, let me list all the ports involved:
* 8000 - Xend's HTTP interface for control
* 8001 - from Anthony's e-mail this is Xend's event port
* 8002 - from Anthony's e-mail this is xfrd's (control???) port
* 8080 - this is the HTTP port for the XenSV web interface
The situation regarding web interfaces is a bit confused. Xend serves a basic
web interface on 8000 if you connect with a web browser or communicates using
an SXP-based protocol if you connect using xm.
XenSV is a pretty web interface that runs as a separate server. You connect
to it using a browser pointed at port 8080. It issues commands to Xend using
the SXP-based protocol on port 8000 (!).
AFAIK, neither of these use SSL. Xend can be secured by only allowing
connections from localhost but XenSV cannot, so you should only use it in an
environment where you have reason to trust your network!
> > 1) xend web interface appears on port 8080 (non SSL). Is the
> > xend-config.sxp parameter not honored?
>
> I'm not sure. I'm reasonably sure that even if you could support
> changing the port, changing it to 443 would not automatically make it
> use SSL.
The parameter in the Xend config file is for Xend's HTTP control interface
(i.e. to make this other than 8000). This is not the same as the XenSV web
interface, which is at 8080. The XenSV one is the one you have to edit a
Python file to change the port :-/
HTH,
Mark
> > 2) Does Twisted natively support SSL? I found conflicting statements
> > in my brief research.
>
> I'm not sure about "native" but I'm quite sure you can use SSL with
> Twisted.
>
> > 3) What is listening on ports 8000 and 8001?
>
> Xend listens on 8000 (provides a web interface). 8001 is used by Xend
> for events.
>
> > 4) Related subject, how is xfrd (port 8002) secured against malicious
> > domain transfers?
>
> It's not. This is one of the reasons why VM-Tools takes such a
> different approach to domain migration.
>
> All of the tools in VM-Tools are small and single purposed. One of
> these tools (vm-create) will have the ability to read a saved image from
> standard input. Another tool (vm-save) will be able to save an image to
> standard output.
>
> Migration is simply a matter of piping vm-save to an instance of
> vm-create executed via ssh.
>
> The transport is actually transparent to the migration process. You
> could just as easily use rexec, or write a simple remote shell that did
> IP-level filtering instead of authentication.
>
> This approach gives you a wide variety of choices in terms of signing,
> sealing, and authentication mechanisms. Since ssh uses pam, you
> instantly are tied into most existing single sign-on environments
> (through pam_krb5, pam_winbind, etc.). While using ssh as the transport
> is debatable, I believe tying into pam is inevitable for any migration
> implementation.
>
> Of course, VM-Tools is still a work in progress. Someone is currently
> working on migration support. We're hoping to have it available by the
> end of the month.
>
> Regards,
>
> > Rich
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home