Re: [vdsm] starting up vdsm and svdsm
- Original Message - > From: "Zhou Zheng Sheng" > To: "Alon Bar-Lev" > Cc: vdsm-devel@lists.fedorahosted.org > Sent: Sunday, January 6, 2013 11:25:39 AM > Subject: Re: [vdsm] starting up vdsm and svdsm > > > on 01/06/2013 17:07, Alon Bar-Lev wrote: > > > > - Original Message - > >> From: "Zhou Zheng Sheng" > >> To: vdsm-devel@lists.fedorahosted.org > >> Sent: Sunday, January 6, 2013 11:03:59 AM > >> Subject: Re: [vdsm] starting up vdsm and svdsm > >> 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. > > I don't understand this auth key thing. > > Why is it required? > > Shouldn't it be sufficient to allow only vdsm user to interact with > > svdsm? > > > > Thanks, > > Alon. > > > > The auth key is not very useful. It is passed in the command > arguments > of super VDSM server, very insecure. > > By writing follow the existing solution, I mean libvirtd refer to a > SASL > DB for password and VDSM refer to /etc/pki/vdsm/keys/libvirt_password > when connecting to libvirtd. > > I agree to allow only vdsm user to access the svdsm.sock and forget > the > auth key thing because saving the auth key in a vdsm user readonly > file > does not improve any security level. If the some one can access > svdsm.sock, he can always access libvirt_password. libvirtd is mean > to > be used by many clients so its unix socket file can not be restricted > to > vdsm user only, it needs a password for each user in the SASL DB. The > super VDSM server is only for VDSM itself, so restricting access > svdsm.sock is enough, no auth key needed. Great. BTW: The auth key is not required even if you use multiple local users, as usock can ask the identity of the other party[1]. Alon [1] http://linux.die.net/man/7/unix SCM_CREDENTIALS ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
on 01/06/2013 17:07, Alon Bar-Lev wrote: - Original Message - From: "Zhou Zheng Sheng" To: vdsm-devel@lists.fedorahosted.org Sent: Sunday, January 6, 2013 11:03:59 AM Subject: Re: [vdsm] starting up vdsm and svdsm 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. I don't understand this auth key thing. Why is it required? Shouldn't it be sufficient to allow only vdsm user to interact with svdsm? Thanks, Alon. The auth key is not very useful. It is passed in the command arguments of super VDSM server, very insecure. By writing follow the existing solution, I mean libvirtd refer to a SASL DB for password and VDSM refer to /etc/pki/vdsm/keys/libvirt_password when connecting to libvirtd. I agree to allow only vdsm user to access the svdsm.sock and forget the auth key thing because saving the auth key in a vdsm user readonly file does not improve any security level. If the some one can access svdsm.sock, he can always access libvirt_password. libvirtd is mean to be used by many clients so its unix socket file can not be restricted to vdsm user only, it needs a password for each user in the SASL DB. The super VDSM server is only for VDSM itself, so restricting access svdsm.sock is enough, no auth key needed. -- 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
Re: [vdsm] starting up vdsm and svdsm
- Original Message - > From: "Zhou Zheng Sheng" > To: vdsm-devel@lists.fedorahosted.org > Sent: Sunday, January 6, 2013 11:03:59 AM > Subject: Re: [vdsm] starting up vdsm and svdsm > 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. I don't understand this auth key thing. Why is it required? Shouldn't it be sufficient to allow only vdsm user to interact with svdsm? Thanks, Alon. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
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
Re: [vdsm] starting up vdsm and svdsm
Currently, vdsm deamon script starts (respawn) vdsm process as vdsm user, and during that vdsm starts super vdsm process as root. * when vdsm dies, svdsm process supposed to notice and exit by itself. * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to start new svdsm instance after verifying that old instance is dead and call it. This is super vdsm and vdsm startup design in general. -- In current implementation we have some edge cases that we need to handle: * vsdm can try to communicate with old instance of svdsm. * vdsm can kill wrong process that got last svdsm pid before starting the new instance of svdsm. * vdsm can try to communicate with svdsm before svdsm starts to serve requests. And i guess there are many more possible senerios that can cause bugs.. As it seems, it doesn't make sense that vdsm manages root process, and can kill it.. What if svdsm will be the manager of vdsm: * deamon script starts up svdsm instance instead of vdsm * svdsm forks vdsm and changes its privilege (uid to vdsm) * vdsm receives as parameter svdsm pid for sudo requests you mean vdsm can kill svdsm? I'd suggest svdsm exports a getProxy().killSvdsm() functinon. * when vdsm dies, svdsm will start new instance of vdsm automatically, supervdsm poke should be change to periodically wait() and restart. and note the crash reason to syslog. * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its son process, and another instance of svdsm will start automatically and start new instance of vdsm. usecase: svdsm recieve SIGTERM, (1)if svdsm waits to join vdsm in a thread: vdsm as its child process should receive signal to terminate, Using Process() to start vdsm, and if supervdsm reload SIGTERM(sigterm handler is to kill vdsm), supervdsm will never join vdsm and exit.It will just hang there. (2)when svdsm not wait: vdsm still be alive,svdsm will need to kill vdsm at next time startup or will result in: error: [Errno 98] Address already in use when start a new vdsm to bind xmlrpc server also, Not sure about if it is safe for svdsm to terminate vdsm because vdsm may in the middle of other activities. Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm user (check log permissions, clean old temporary files and so on if needed..) Royce Lv has already started to work on such design here http://gerrit.ovirt.org/#/c/4145/ So my previous choice is to : 1) As root, create a new process for supervdsmServer 2) Drop privileges in the parent 3) Start vdsm in the parent Then, if vdsm detects a problem with supervdsm, it can just exit. This will cause respawn to restart everything again. So if either process (vdsm, or supervdsm) dies, the whole thing will be respawned. See the draft here, let's discuss about it: http://www.ovirt.org/Normalize_vdsm_start_up_process 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. I want to update it and push it forward. I would like to hear more opinions and point of views on this change, Thanks. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
- Original Message - > From: "ybronhei" > To: "Alon Bar-Lev" > Cc: "VDSM Project Development" > Sent: Sunday, December 30, 2012 2:28:45 PM > Subject: Re: [vdsm] starting up vdsm and svdsm > > On 12/30/2012 01:45 PM, Alon Bar-Lev wrote: > > > > > > - Original Message - > >> From: "ybronhei" > >> To: "Alon Bar-Lev" > >> Cc: "VDSM Project Development" > >> Sent: Sunday, December 30, 2012 1:40:03 PM > >> Subject: Re: [vdsm] starting up vdsm and svdsm > >> > >> On 12/30/2012 12:11 PM, Alon Bar-Lev wrote: > >>> > >>> > >>> ----- Original Message - > >>>> From: "ybronhei" > >>>> To: "VDSM Project Development" > >>>> > >>>> Sent: Sunday, December 30, 2012 11:53:17 AM > >>>> Subject: [vdsm] starting up vdsm and svdsm > >>>> > >>>> Currently, vdsm deamon script starts (respawn) vdsm process as > >>>> vdsm > >>>> user, and during that vdsm starts super vdsm process as root. > >>>> * when vdsm dies, svdsm process supposed to notice and exit > >>>> by > >>>> itself. > >>>> * if svdsm dies, in the next proxy call by vdsm, vdsm > >>>> supposed > >>>> to > >>>> start new svdsm instance after verifying that old instance is > >>>> dead > >>>> and > >>>> call it. > >>>> This is super vdsm and vdsm startup design in general. > >>>> -- > >>>> > >>>> In current implementation we have some edge cases that we need > >>>> to > >>>> handle: > >>>> * vsdm can try to communicate with old instance of svdsm. > >>>> * vdsm can kill wrong process that got last svdsm pid before > >>>> starting > >>>> the new instance of svdsm. > >>>> * vdsm can try to communicate with svdsm before svdsm starts > >>>> to > >>>> serve > >>>> requests. > >>>> And i guess there are many more possible senerios that can cause > >>>> bugs.. > >>>> > >>>> As it seems, it doesn't make sense that vdsm manages root > >>>> process, > >>>> and > >>>> can kill it.. > >>>> > >>>> What if svdsm will be the manager of vdsm: > >>>> * deamon script starts up svdsm instance instead of vdsm > >>>> * svdsm forks vdsm and changes its privilege (uid to vdsm) > >>>> * vdsm receives as parameter svdsm pid for sudo requests > >>>> * when vdsm dies, svdsm will start new instance of vdsm > >>>> automatically, > >>>> and note the crash reason to syslog. > >>>> * svdsm starts with respawn, so when svdsm dies, vdsm dies > >>>> also > >>>> as > >>>> its > >>>> son process, and another instance of svdsm will start > >>>> automatically > >>>> and > >>>> start new instance of vdsm. > >>>> > >>>> Sounds like much correcter and easier to maintain design. > >>> > >>> I am not sure I understand why these two services are related. > >>> > >>> As far as I understand svdsm is a total stateless slave without > >>> any > >>> logic, to provide privilege escalation to vdsm. > >>> Why does it need to be restarted if vdsm changes state? > >>> I expect it to exist as a separate service (init.d/systemd) and > >>> vdsmd to depend on that service. > >>> > >>> What am I missing? > >>> > >> There is no relation between the states of the two. The only > >> relation > >> is > >> that if one is up the other one must also be up and serve > >> requests. > >> for > >> that case, systemd dependencies can solve the issue.. > > > > This is a dependency. > > Why "the other when must also be up?" > > From what I understand, there is no problem in having svdsm up > > anyway, hence no mutual dependency. > > If we do have mutual dependency we should work to eliminate that > > anyway. > > > right, svdsm can be up anyway.. but must be up and serve to let vdsm > to >
Re: [vdsm] starting up vdsm and svdsm
On 12/30/2012 01:45 PM, Alon Bar-Lev wrote: - Original Message - From: "ybronhei" To: "Alon Bar-Lev" Cc: "VDSM Project Development" Sent: Sunday, December 30, 2012 1:40:03 PM Subject: Re: [vdsm] starting up vdsm and svdsm On 12/30/2012 12:11 PM, Alon Bar-Lev wrote: - Original Message - From: "ybronhei" To: "VDSM Project Development" Sent: Sunday, December 30, 2012 11:53:17 AM Subject: [vdsm] starting up vdsm and svdsm Currently, vdsm deamon script starts (respawn) vdsm process as vdsm user, and during that vdsm starts super vdsm process as root. * when vdsm dies, svdsm process supposed to notice and exit by itself. * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to start new svdsm instance after verifying that old instance is dead and call it. This is super vdsm and vdsm startup design in general. -- In current implementation we have some edge cases that we need to handle: * vsdm can try to communicate with old instance of svdsm. * vdsm can kill wrong process that got last svdsm pid before starting the new instance of svdsm. * vdsm can try to communicate with svdsm before svdsm starts to serve requests. And i guess there are many more possible senerios that can cause bugs.. As it seems, it doesn't make sense that vdsm manages root process, and can kill it.. What if svdsm will be the manager of vdsm: * deamon script starts up svdsm instance instead of vdsm * svdsm forks vdsm and changes its privilege (uid to vdsm) * vdsm receives as parameter svdsm pid for sudo requests * when vdsm dies, svdsm will start new instance of vdsm automatically, and note the crash reason to syslog. * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its son process, and another instance of svdsm will start automatically and start new instance of vdsm. Sounds like much correcter and easier to maintain design. I am not sure I understand why these two services are related. As far as I understand svdsm is a total stateless slave without any logic, to provide privilege escalation to vdsm. Why does it need to be restarted if vdsm changes state? I expect it to exist as a separate service (init.d/systemd) and vdsmd to depend on that service. What am I missing? There is no relation between the states of the two. The only relation is that if one is up the other one must also be up and serve requests. for that case, systemd dependencies can solve the issue.. This is a dependency. Why "the other when must also be up?" From what I understand, there is no problem in having svdsm up anyway, hence no mutual dependency. If we do have mutual dependency we should work to eliminate that anyway. right, svdsm can be up anyway.. but must be up and serve to let vdsm to be operational. and we can solve that by normal systemd dependency, as vdsm will require svdsm service and run it in type=forking (this way we guarantee that the parent exists and runs before starting). I don't see any other mutual dependency between the two.. Instead of using systemd dependency and split the vdsmd service, I suggested to change the current relation and startup progress. Any benefit in that over using proper system services? Maybe not.. just need to consider differences between systemd and initctl (upstart) dependencies mechanism if we decide to rely on system services. And they work quite different.. If we don't want to have 2 implementations for that as we have now with some if-else statements in vdsmd.init script, it might help to keep it in one service that splits to 2 processes.. Separate to two services that depended on each-other is another option to consider. Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm user (check log permissions, clean old temporary files and so on if needed..) Royce Lv has already started to work on such design here http://gerrit.ovirt.org/#/c/4145/ I want to update it and push it forward. I would like to hear more opinions and point of views on this change, Thanks. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
- Original Message - > From: "ybronhei" > To: "Alon Bar-Lev" > Cc: "VDSM Project Development" > Sent: Sunday, December 30, 2012 1:40:03 PM > Subject: Re: [vdsm] starting up vdsm and svdsm > > On 12/30/2012 12:11 PM, Alon Bar-Lev wrote: > > > > > > - Original Message - > >> From: "ybronhei" > >> To: "VDSM Project Development" > >> Sent: Sunday, December 30, 2012 11:53:17 AM > >> Subject: [vdsm] starting up vdsm and svdsm > >> > >> Currently, vdsm deamon script starts (respawn) vdsm process as > >> vdsm > >> user, and during that vdsm starts super vdsm process as root. > >>* when vdsm dies, svdsm process supposed to notice and exit by > >>itself. > >>* if svdsm dies, in the next proxy call by vdsm, vdsm supposed > >>to > >> start new svdsm instance after verifying that old instance is dead > >> and > >> call it. > >> This is super vdsm and vdsm startup design in general. > >> -- > >> > >> In current implementation we have some edge cases that we need to > >> handle: > >>* vsdm can try to communicate with old instance of svdsm. > >>* vdsm can kill wrong process that got last svdsm pid before > >>starting > >> the new instance of svdsm. > >>* vdsm can try to communicate with svdsm before svdsm starts to > >>serve > >> requests. > >> And i guess there are many more possible senerios that can cause > >> bugs.. > >> > >> As it seems, it doesn't make sense that vdsm manages root process, > >> and > >> can kill it.. > >> > >> What if svdsm will be the manager of vdsm: > >>* deamon script starts up svdsm instance instead of vdsm > >>* svdsm forks vdsm and changes its privilege (uid to vdsm) > >>* vdsm receives as parameter svdsm pid for sudo requests > >>* when vdsm dies, svdsm will start new instance of vdsm > >>automatically, > >> and note the crash reason to syslog. > >>* svdsm starts with respawn, so when svdsm dies, vdsm dies also > >>as > >>its > >> son process, and another instance of svdsm will start > >> automatically > >> and > >> start new instance of vdsm. > >> > >> Sounds like much correcter and easier to maintain design. > > > > I am not sure I understand why these two services are related. > > > > As far as I understand svdsm is a total stateless slave without any > > logic, to provide privilege escalation to vdsm. > > Why does it need to be restarted if vdsm changes state? > > I expect it to exist as a separate service (init.d/systemd) and > > vdsmd to depend on that service. > > > > What am I missing? > > > There is no relation between the states of the two. The only relation > is > that if one is up the other one must also be up and serve requests. > for > that case, systemd dependencies can solve the issue.. This is a dependency. Why "the other when must also be up?" From what I understand, there is no problem in having svdsm up anyway, hence no mutual dependency. If we do have mutual dependency we should work to eliminate that anyway. > Instead of using systemd dependency and split the vdsmd service, I > suggested to change the current relation and startup progress. Any benefit in that over using proper system services? > Separate > to two services that depended on each-other is another option to > consider. > > >> > >> Also, svdsm can init whatever vdsm needs and is limited to do as a > >> vdsm > >> user (check log permissions, clean old temporary files and so on > >> if > >> needed..) > >> > >> Royce Lv has already started to work on such design here > >> http://gerrit.ovirt.org/#/c/4145/ > >> I want to update it and push it forward. > >> > >> I would like to hear more opinions and point of views on this > >> change, > >> > >> Thanks. > >> > >> -- > >> Yaniv Bronhaim. > >> RedHat, Israel > >> 09-7692289 > >> 054-7744187 > >> ___ > >> vdsm-devel mailing list > >> vdsm-devel@lists.fedorahosted.org > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >> > > > -- > Yaniv Bronhaim. > RedHat, Israel > 09-7692289 > 054-7744187 > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
On 12/30/2012 12:11 PM, Alon Bar-Lev wrote: - Original Message - From: "ybronhei" To: "VDSM Project Development" Sent: Sunday, December 30, 2012 11:53:17 AM Subject: [vdsm] starting up vdsm and svdsm Currently, vdsm deamon script starts (respawn) vdsm process as vdsm user, and during that vdsm starts super vdsm process as root. * when vdsm dies, svdsm process supposed to notice and exit by itself. * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to start new svdsm instance after verifying that old instance is dead and call it. This is super vdsm and vdsm startup design in general. -- In current implementation we have some edge cases that we need to handle: * vsdm can try to communicate with old instance of svdsm. * vdsm can kill wrong process that got last svdsm pid before starting the new instance of svdsm. * vdsm can try to communicate with svdsm before svdsm starts to serve requests. And i guess there are many more possible senerios that can cause bugs.. As it seems, it doesn't make sense that vdsm manages root process, and can kill it.. What if svdsm will be the manager of vdsm: * deamon script starts up svdsm instance instead of vdsm * svdsm forks vdsm and changes its privilege (uid to vdsm) * vdsm receives as parameter svdsm pid for sudo requests * when vdsm dies, svdsm will start new instance of vdsm automatically, and note the crash reason to syslog. * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its son process, and another instance of svdsm will start automatically and start new instance of vdsm. Sounds like much correcter and easier to maintain design. I am not sure I understand why these two services are related. As far as I understand svdsm is a total stateless slave without any logic, to provide privilege escalation to vdsm. Why does it need to be restarted if vdsm changes state? I expect it to exist as a separate service (init.d/systemd) and vdsmd to depend on that service. What am I missing? There is no relation between the states of the two. The only relation is that if one is up the other one must also be up and serve requests. for that case, systemd dependencies can solve the issue.. Instead of using systemd dependency and split the vdsmd service, I suggested to change the current relation and startup progress. Separate to two services that depended on each-other is another option to consider. Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm user (check log permissions, clean old temporary files and so on if needed..) Royce Lv has already started to work on such design here http://gerrit.ovirt.org/#/c/4145/ I want to update it and push it forward. I would like to hear more opinions and point of views on this change, Thanks. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] starting up vdsm and svdsm
- Original Message - > From: "ybronhei" > To: "VDSM Project Development" > Sent: Sunday, December 30, 2012 11:53:17 AM > Subject: [vdsm] starting up vdsm and svdsm > > Currently, vdsm deamon script starts (respawn) vdsm process as vdsm > user, and during that vdsm starts super vdsm process as root. > * when vdsm dies, svdsm process supposed to notice and exit by > itself. > * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to > start new svdsm instance after verifying that old instance is dead > and > call it. > This is super vdsm and vdsm startup design in general. > -- > > In current implementation we have some edge cases that we need to > handle: > * vsdm can try to communicate with old instance of svdsm. > * vdsm can kill wrong process that got last svdsm pid before > starting > the new instance of svdsm. > * vdsm can try to communicate with svdsm before svdsm starts to > serve > requests. > And i guess there are many more possible senerios that can cause > bugs.. > > As it seems, it doesn't make sense that vdsm manages root process, > and > can kill it.. > > What if svdsm will be the manager of vdsm: > * deamon script starts up svdsm instance instead of vdsm > * svdsm forks vdsm and changes its privilege (uid to vdsm) > * vdsm receives as parameter svdsm pid for sudo requests > * when vdsm dies, svdsm will start new instance of vdsm > automatically, > and note the crash reason to syslog. > * svdsm starts with respawn, so when svdsm dies, vdsm dies also as > its > son process, and another instance of svdsm will start automatically > and > start new instance of vdsm. > > Sounds like much correcter and easier to maintain design. I am not sure I understand why these two services are related. As far as I understand svdsm is a total stateless slave without any logic, to provide privilege escalation to vdsm. Why does it need to be restarted if vdsm changes state? I expect it to exist as a separate service (init.d/systemd) and vdsmd to depend on that service. What am I missing? > > Also, svdsm can init whatever vdsm needs and is limited to do as a > vdsm > user (check log permissions, clean old temporary files and so on if > needed..) > > Royce Lv has already started to work on such design here > http://gerrit.ovirt.org/#/c/4145/ > I want to update it and push it forward. > > I would like to hear more opinions and point of views on this change, > > Thanks. > > -- > Yaniv Bronhaim. > RedHat, Israel > 09-7692289 > 054-7744187 > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] starting up vdsm and svdsm
Currently, vdsm deamon script starts (respawn) vdsm process as vdsm user, and during that vdsm starts super vdsm process as root. * when vdsm dies, svdsm process supposed to notice and exit by itself. * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to start new svdsm instance after verifying that old instance is dead and call it. This is super vdsm and vdsm startup design in general. -- In current implementation we have some edge cases that we need to handle: * vsdm can try to communicate with old instance of svdsm. * vdsm can kill wrong process that got last svdsm pid before starting the new instance of svdsm. * vdsm can try to communicate with svdsm before svdsm starts to serve requests. And i guess there are many more possible senerios that can cause bugs.. As it seems, it doesn't make sense that vdsm manages root process, and can kill it.. What if svdsm will be the manager of vdsm: * deamon script starts up svdsm instance instead of vdsm * svdsm forks vdsm and changes its privilege (uid to vdsm) * vdsm receives as parameter svdsm pid for sudo requests * when vdsm dies, svdsm will start new instance of vdsm automatically, and note the crash reason to syslog. * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its son process, and another instance of svdsm will start automatically and start new instance of vdsm. Sounds like much correcter and easier to maintain design. Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm user (check log permissions, clean old temporary files and so on if needed..) Royce Lv has already started to work on such design here http://gerrit.ovirt.org/#/c/4145/ I want to update it and push it forward. I would like to hear more opinions and point of views on this change, Thanks. -- Yaniv Bronhaim. RedHat, Israel 09-7692289 054-7744187 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
