on 01/04/2013 21:08, Royce Lv wrote:
I'm also agree with breaking these two as dependent services just as vdsmd and libvirtd. These will involve supervdsm died and vdsm reconnect, if we use key this will be security issue. So now we use key as local variable.If just use child/parent
pipe, here is similar restart logic to handle.


The auth key of Python manager mechanism is good, but currently when VDSM starts super VDSM, it passes the key in the command line. You can get the key from "ps aux | grep supervdsmServer". This is not secure at all. You can just start a python and try this.

# PYTHONPATH=/usr/share/vdsm python
Python 2.7.3 (default, Jul 24 2012, 10:05:38)
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import supervdsm
m = supervdsm._SuperVdsmManager(address='/var/run/vdsm/svdsm.sock', 
authkey='5e21c5e1-0050-4eca-85a0-098433f3a820')
m.register('instance')
m.register('open')
m.connect()
s = m.instance()
s.ping()
True

Here auth key is copied from the output of the ps programme. In fact the super VDSM server is not protected by the auth key, but the "srwxr-xr-x vdsm:kvm" of the /var/run/vdsm/svdsm.sock . Ordinary users can not write to this socket. The auth key is generated by VDSM each time it launches a new super VDSM server instance. I think the most useful thing of this auth key is that, after a totally restart, to prevent VDSM to connect to a previous stuck but not yet died super VDSM server, in this case we will get "Authentication Error" and kill it explicitly.

The Python manager framework starts a new thread for each request, that means the super VDSM server serve each call in a new thread. So even a operation cause a thread to stuck, the super VDSM server is still functional. In case that some operation causing the whole process of the super VDSM server stuck, the super VDSM server should fork a child itself and delegate the operation to the child. Anyway what operation will stuck the whole process?

I think splitting VDSM and super VDSM into two services and delegate everything to systemd is simple and robust, just like libvirtd and VDSM. The auth key problem you mentioned also applies to connecting libvirtd, we can just follow the existing solution for it.

--
Thanks and best regards!

Zhou Zheng Sheng / 周征晟
E-mail: zhshz...@linux.vnet.ibm.com
Telephone: 86-10-82454397

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to