On Tue 22 Nov 2011 04:53:33 PM EST, Andrew Cathrow wrote:
>
>
> ----- Original Message -----
>> From: "Adam Litke"<a...@us.ibm.com>
>> To: vdsm-devel@lists.fedorahosted.org
>> Sent: Tuesday, November 22, 2011 4:29:41 PM
>> Subject: MOM integration questions
>>
>> Hi guys,
>>
>> I've got MOM up and running as a vdsm thread but I've hit two small
>> problems.
>> I'll bounce them around on the list to see if people have some ideas.
>>
>> 1.) Libvirt SASL authentication
>>
>> I was able to easily modify MOM to connect to libvirt by hardcoding
>> the vdsm
>> credentials.  Obviously this is not an acceptable long-term solution.
>>   What is
>> the best way to share the vdsm libvirt password with MOM in a way
>> that does not
>> compromise security?  Whatever method we choose should not involve
>> vdsm-specific
>> changes to MOM.  For starters I think I will just place the username
>> and
>> password in the mom.conf file.  We could make this file readable only
>> by the
>> vdsm user.  Thoughts?
>
> Is it safe just to read it from /etc/pki/vdsm/keys/libvirt_password
>
> What's the reason for not wanting VDSM specific changes in MOM, is this 
> project is part of oVirt then we can always assume VDSM is present.
>>
>> 2.) Permissions
>>
>> The first error I noticed was MOM failing to adjust KSM via sysfs:
>>
>> 2011-11-22 10:13:48,313 - mom.Controllers.KSM - WARNING - KSM: Failed
>> to write
>> /sys/kernel/mm/ksm/run: Permission denied
>>
>> MOM is used to running as root so that it can adjust these settings.
>>   I would
>> prefer not to complicate the MOM architecture by having a separate
>> process that
>> receives instructions from the main MOM thread and then applies the
>> requested
>> changes as root.
>>
>> Another solution would be to allow MOM to run as a completely
>> separate daemon
>> (as it has been originally doing).  In this scenario, vdsm would
>> reconfigure MOM
>> by replacing the default configuration file and policy.  vdsm could
>> then
>> interact with the running momd via the existing xmlrpc interface.
>>
>> Thoughts on these issues?
>>
>> --
>> Adam Litke<a...@us.ibm.com>
>> IBM Linux Technology Center
>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel@lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel

I would like to +1 what Ayal said.
Seperating MOM to be a policy engine and using other ovirt projects for 
collecting and performing actions through APIs will allow us to 
integrate better while allowing solutions not wishing to use the full 
ovirt bundle to implement these interfaces.

As to the sticking MOM on VDSM solution. supervdsm is used to perform 
root operations. But the operation has to be as specific as possible to 
prevent compromised svdm from doing to much damage.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to