Open Stack

> On Apr 22, 2014, at 9:50 PM, sylecn <sylecn at gmail.com> wrote:
> 
>> On Tue, Apr 22, 2014 at 4:57 AM, Aaron Knister <aaron.knister at gmail.com> wrote:
>> I just spent a couple hours trying to figure this out so I thought I'd share.
>> 
>> I'm using the stackforge puppet modules and writing my own integration module to pull the individual modules together. That allows me to integrate better with our current puppet methodology and with local security policy. 
>> 
>> One of the things we disallow, by accident actually, is packages dropping their own sudo rules in /etc/sudoers.d. All sudo rules must be explicitly specified and managed via puppet resources. As a side effect of this when I went to start the nova metadata api on the controller node my logs blew up (as did the inboxes of my coworkers) with security violations from the nova metadata api attempting to use the nova root wrapper via sudo. 
>> 
>> I thought it a little odd that the nova metadata api would need to do anything as root since I'm running the neutron metadata agents which already run actions as root. I figured out that this was coming from the nova.api.manager.MetadataManager class which I'm pretty sure isn't needed for neutron. I changed the value of metadata_manager in nova.conf to nova.manager.Manager and now the api service no-longer needs the rootwrap sudo setup.
>> 
>> I couldn't find this documented anywhere, so hopefully this helps someone in the future.
>> 
>> -Aaron
> 
> Aaron, thanks for sharing. Are you using this in production? Do you notice performance improvements on the metadata service after this change, i.e. when starting lots of VM at the same time?

It's quasi production. It's operational but it's hosting development machines. I haven't seen any performance changes although I haven't tried to spin up many machines at once. 

Sent from my iPhone


> 
> -- 
> 
> YY Inc. is hiring openstack and python developers. Interested? Check http://www.nsbeta.info/jobs
> 
> --
> Thanks,
> Yuanle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140423/8d281976/attachment.html>