On Wed, Nov 01, 2006 at 11:57:27AM +0000, Ewan Mellor wrote:
> On Wed, Nov 01, 2006 at 11:38:47AM +0000, Alastair Tse wrote:
>
> > > - XenD should install its own PAM config file into /etc/pam.d
> > > rather than re-using the context from the 'login' program
> >
> >
> > Well, the problem I ran into is that every distro has their own
> > custom PAM stack and any PAM stack we write will only work on one
> > distro and not another. I believe this is a distro packaging problem.
> > But your concern is still valid, maybe we have to provide a PAM stack
> > for one at least one distro. Let's fight to see which one that will
> > be :)
>
> Back off, Gentoo-freak ;-)
I was about to suggest we pick a PAM config which matches those
distirbuted by upstream Linux-PAM codebase, but it appears they
don't distribute any example configs leaving that job to vendors
> > > - If we're using PAM then we must switch all communications to use
> > > SSL by default - no network daemon should be using system
> > > passwords over a cleartext network channel anymore. If we want
> > > to keep a cleartext channel, then we should use a separate
> > > password database & certainly not system logins
> >
> > Definitely. I've only been testing with a local UNIX domain socket.
> > Anything that goes over the network needs SSL encryption, but the API
> > docs don't make any mention of this, presumably because it doesn't
> > really fall into the API.
>
> Actually, I agreed at the last Xen Summit that we would add a list of
> supported transports to that API document. The intention is that any server
> meeting the spec can talk to any client meeting the spec, so of course we need
> a list of supported transports too.
>
> This list is something we need to write down -- HTTP/local, HTTP/TCP,
> HTTP/SSL/TCP are the obvious ones, but if someone needs something else, it's
> still open to discussion.
Yes, that sounds like a good set required for a minimally compliant client
implementation to talk. We'll also likely want to support the TCP listeners
on both IPv4 & IPv6 in the near future. In Fedora & RHEL its now policy
to have all network apps suppport IPv4 & IPv6 connections enabled by
default upon install, so if you don't get it into initial codebase I'll
probably find myself submitting a patch shortly thereafter :-)
>
> > My guess is we'll need to put some
> > certificate configuration options in xend-config.sxp or run the Xen
> > API on a different XMLRPC server than the one that currently serves xm.
>
> Yeah, I think that we're certainly going to need to use a different port, even
> if we're using the same dispatcher behind that. I'm not sure what to do about
> certificate management -- any suggestions?
I've never done it in pure python before, but a quick google suggests the
pyopenssl binding is the thing we want. There is a SSL.Connection object
for dealing with the socket stuff & SSL.Context for certificate side of
things.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home