Re: PATCH: Updated patches for PolicyKit support

On Fri, Sep 21, 2007 at 06:05:44AM -0400, Daniel Veillard wrote:
> On Thu, Sep 20, 2007 at 05:46:07PM +0100, Daniel P. Berrange wrote:
> > On Thu, Sep 20, 2007 at 05:14:56PM +0100, Richard W.M. Jones wrote:
> > > I guess I'd be +1.  What do the Solaris folks think?
> > > 
> > > I wonder if issues of authentication and encryption can be separated out 
> > > to allow a pluggable libvirt auth API?
> > 
> > This is an interesting question. Client authentication with PolicyKit is
> > out-of-band from the main libvirt<->client channel. ie, virt-manager has
> > to talk to DBus and say 'I want to gain credential org.libvirt.manage' and
> > then PolicyKit decides whether to allow it, require a password, require
> > the root password, etc. In my current impl, this has to be done prior to
> > connecting to the daemon. We have no API in libvirt for apps to be told
> > whether they need to authenticate, or gain credentials in some way. So
> > virt-manager just tries to use PolicyKit ahead of time, regardless since
> > it has no way to determine if the server will require it or not. I hate
> > to suggest it, but perhaps rather than re-purposing the existing UNIX
> > domain socket /var/run/libvirt/libvirt-sock or libvirt-sock-ro, I should
> > have added a distinct libvirt-sock-polkit ? That would at least give the
> > client app a way to test for existance ahead of time & thus decide if
> > it needs to request for credentials first.
> > 
> > To improve matter's we'd need a way for a client app to provide some form
> > of auth callback when opening a connection, and one or two new messages 
> > on the wire to negotiate between client &server. This would probably require 
> > a new virConnect variant taking a function pointer arg. But just what the
> > API contract will be is not all that straightforward & would want to be 
> > extendable to work with stuff like SASL / GSSAPI.
> > 

[PATCH] Found minor bug in topology code

I found a problem with an error path... I was cutting off incrementing 
of a value in the loop then checking if it was too big after the loop, 
so the way it was structured, it could never happen. Here is the fix.

-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak <at> us.ibm.com

I found a problem with an error path... I was cutting off incrementing 
of a value in the loop then checking if it was too big after the loop, 
so the way it was structured, it could never happen. Here is the fix.

--

-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak <at> us.ibm.com

remote access ?

I was looking through some of the remote code.. I was wondering
if a 32-bit virsh client is supposed to be able to connect to a 64-bit
libvirtd?

The reason I ask is because I saw some references to longs..
For example, in xdr_remote_node_get_info_ret()
...
                        objp->cpus = IXDR_GET_LONG(buf);
                        objp->mhz = IXDR_GET_LONG(buf);
                        objp->nodes = IXDR_GET_LONG(buf);
                        objp->sockets = IXDR_GET_LONG(buf);
                        objp->cores = IXDR_GET_LONG(buf);
                        objp->threads = IXDR_GET_LONG(buf);

Thanks,

MRJ

Re: remote access ?

On Thu, Oct 04, 2007 at 12:27:38PM -0400, Mark Johnson wrote:
> I was looking through some of the remote code.. I was wondering
> if a 32-bit virsh client is supposed to be able to connect to a 64-bit
> libvirtd?

Yes. The wire protocol is 32/64 invariant.

> The reason I ask is because I saw some references to longs..
> For example, in xdr_remote_node_get_info_ret()

I must admit to being puzzelled as to why rpcgen decided to use
IXDR_GET_LONG there. All the rest of the code in that function is
using int, and the protocol is defined to be int.

Are you actually seeing failures when doing 32 -> 64 remote connections
or vica-verca ?

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  -=| 

Re: remote access ?

> Yes. The wire protocol is 32/64 invariant.
>
> > The reason I ask is because I saw some references to longs..
> > For example, in xdr_remote_node_get_info_ret()
>
> I must admit to being puzzelled as to why rpcgen decided to use
> IXDR_GET_LONG there. All the rest of the code in that function is
> using int, and the protocol is defined to be int.

I'll have to go back and check which one I was compiling
at the time.. Maybe it uses that for 32-bit only which should't
be a problem...

> Are you actually seeing failures when doing 32 -> 64 remote connections
> or vica-verca ?

I'm not that far yet  Just getting those bits to compile now...

Thanks,

MRJ

Re: remote access ?

On Thu, Oct 04, 2007 at 12:43:53PM -0400, Mark Johnson wrote:
> > Yes. The wire protocol is 32/64 invariant.
> >
> > > The reason I ask is because I saw some references to longs..
> > > For example, in xdr_remote_node_get_info_ret()
> >
> > I must admit to being puzzelled as to why rpcgen decided to use
> > IXDR_GET_LONG there. All the rest of the code in that function is
> > using int, and the protocol is defined to be int.
> 
> I'll have to go back and check which one I was compiling
> at the time.. Maybe it uses that for 32-bit only which should't
> be a problem...

The remote_protocol.c/h  files are generated from remote_protocol.x
using rpcgen. That said, we actually distribute the generated files
and keep them in CVS, since the protocol doesn't change & we prefer
to have known tested code, rather than whatever rpcgen decides to
generate per OS. If you do see problems it could of course be a bug
in the rpcgen tool we used, so may be worth deleting the .c/h files
and seeing if the Solaris rpcgen does a better job.

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  -=| 

Re: remote access ?

On 10/4/07, Daniel P. Berrange <berrange <at> redhat.com> wrote:
> The remote_protocol.c/h  files are generated from remote_protocol.x
> using rpcgen. That said, we actually distribute the generated files
> and keep them in CVS, since the protocol doesn't change & we prefer
> to have known tested code, rather than whatever rpcgen decides to
> generate per OS. If you do see problems it could of course be a bug
> in the rpcgen tool we used, so may be worth deleting the .c/h files
> and seeing if the Solaris rpcgen does a better job.

Haven't gotten to that part yet.. 

Right now, I'm trying to do a simple tcp connect on my fedora 7 box
to my fedora 7 box (with 0.3.2). I'm not sure why the following is
not working?  Anyone know what I'm doing wrong?

[root <at> fedora ~]# cat /etc/libvirt/libvirtd.conf
listen_tcp=1
tcp_port="16509"
root <at> fedora ~]# /etc/init.d/libvirtd stop
Stopping libvirtd daemon:                                  [  OK  ]
[root <at> fedora ~]# /etc/init.d/libvirtd start
Starting libvirtd daemon:                                  [  OK  ]
[root <at> fedora ~]# virsh connect xen+tcp://localhost
libvir: Remote error : Connection refused
error: Failed to connect to the hypervisor
[root <at> fedora ~]# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  - solaris              shut off

Re: remote access ?

On Thu, Oct 04, 2007 at 04:36:35PM -0400, Mark Johnson wrote:
> On 10/4/07, Daniel P. Berrange <berrange <at> redhat.com> wrote:
> > The remote_protocol.c/h  files are generated from remote_protocol.x
> > using rpcgen. That said, we actually distribute the generated files
> > and keep them in CVS, since the protocol doesn't change & we prefer
> > to have known tested code, rather than whatever rpcgen decides to
> > generate per OS. If you do see problems it could of course be a bug
> > in the rpcgen tool we used, so may be worth deleting the .c/h files
> > and seeing if the Solaris rpcgen does a better job.
> 
> Haven't gotten to that part yet.. 
> 
> Right now, I'm trying to do a simple tcp connect on my fedora 7 box
> to my fedora 7 box (with 0.3.2). I'm not sure why the following is
> not working?  Anyone know what I'm doing wrong?

The config file merely controls whether todo TCP or TLS, to actually
enable listening for connection you need to edit /etc/sysconfig/libvirtd 
and then restart the daemon

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  -=| 

Re: [PATCH] Found minor bug in topology code

On Wed, Oct 03, 2007 at 10:56:05AM -0400, beth kon wrote:
> I found a problem with an error path... I was cutting off incrementing 
> of a value in the loop then checking if it was too big after the loop, 
> so the way it was structured, it could never happen. Here is the fix.

Thanks for th patch, I've just committed it.

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  -=| 

Re: remote access ?

On Thu, Oct 04, 2007 at 05:34:04PM +0100, Daniel P. Berrange wrote:
> On Thu, Oct 04, 2007 at 12:27:38PM -0400, Mark Johnson wrote:
> > I was looking through some of the remote code.. I was wondering
> > if a 32-bit virsh client is supposed to be able to connect to a 64-bit
> > libvirtd?
> 
> Yes. The wire protocol is 32/64 invariant.
> 
> > The reason I ask is because I saw some references to longs..
> > For example, in xdr_remote_node_get_info_ret()
> 
> I must admit to being puzzelled as to why rpcgen decided to use
> IXDR_GET_LONG there. All the rest of the code in that function is
> using int, and the protocol is defined to be int.
> 
> Are you actually seeing failures when doing 32 -> 64 remote connections
> or vica-verca ?

FYI, I completely forgot, but I am actually using 32- > 64 on a regular
basis. My laptop is 32-bit and I'm using virt-manager to remotely access
64-bit hosts using both SSH + TLS data transports

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  -=|