<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 10:33 AM, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Any solution where you need to modify sudoers every time the code<br>
> changes is painful, because there is only one sudo configuration on a<br>
> machine and it's owned by root.<br>
<br>
</div>Hmm? At least on ubuntu there is a default /etc/sudoers.d directory,<br>
where we could land per-service files like nova-compute.conf,<br>
nova-network.conf, etc. I don't think that's there by default on Fedora<br>
or RHEL, but adding the includedir to the base config works as expected.<br>
<div class="im"><br>
> The end result was that the sudoers file were not maintained and<br>
> everyone ran and tested with a convenient blanket-permission sudoers<br>
> file.<br>
<br>
</div>Last I checked, The nova rootwrap policy includes blanket approvals for<br>
things like chmod, which pretty much eliminates any sort of expectation<br>
of reasonable security without improvement by the operator (which I<br>
think is unrealistic).<br>
<br>
I'm not sure what the right answer is here. I'm a little afraid of a<br>
rootwrap daemon. However, nova-network choking on 50 instances seems to<br>
be obviously not an option...<br></blockquote><div><br></div><div>I agree.  The good news is that neutron does not timeout like nova-network does here, although it makes many rootwrapped calls so it will get a performance boost from a faster rootwrap solution.</div>

<div><br></div><div>It sounds like rootwrap isn't going anywhere in Havana, and we can explore faster and more secure solutions for Icehouse.  But there may be some short term solutions to make nova (with nova-network) not choke on 50 instances. I would like to be able to say Havana, in its default config, won't choke when trying to spawn a small number of instances.   Some possible solutions are:</div>

<div><br></div><div>* Make rootwrap faster --  rootwrapped calls to iptables-save are still 3 to 4x slower then without rootwrap.  but the python load time counts for less then half of that.</div><div>* Finer grained locks, right now it looks like the iptables lock is what is killing us, so we may be able to find a better way to use iptables-save and restore.</div>

<div>* Reduce the number of rootwrapped calls when possible, I would be very surprised if every single rootwrapped call is needed.</div><div>* See how neutron does it, it seems to work much better for them</div><div>* ???</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--Dan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>