<div dir="ltr">Yeah, the setting for user was neutron. The setting for group was different than the process that started up the proxy (which had user neutron and group neutron). The review 161494, was it applied to Liberty?<div><br></div><div>I think in our case, DHCP agent only had dhcp ini file and not metadata ini file, so it didn't have the user/group setting. </div><div><br></div><div>I was wondering if the user/group should be (only) set in a common config, like neutron.conf, if it should be duplicated in dhcp and metadata config files, or if the metadata ini should be added to the list of ini files, when starting up the DHCP agent.</div><div><br></div><div>With the wrong config, I hit the access denied issue and had no info indicating that is what has happened. Was wondering if there was any protection against that misconfiguration case, or way to get an indication of it.</div><div><br></div><div>P.S. Sorry, I didn't see your reply till now...</div><div><br></div><div>PCM</div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 31, 2016 at 10:36 AM ZZelle <<a href="mailto:zzelle@gmail.com">zzelle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,<br><br>Are you sure metadata_proxy_user==neutron? <br><br>neutron-metadata-proxy must be able to connect to the metadata-agent socket and watchs its log files and neutron user should be able to do both with usual file permissions.<br></div><div><br></div><div>Otherwise the metadata proxy is generally no more able to:<br>- watch log[1] so you should set metadata_proxy_watch_log=False<br></div><div>- connect to the metadata-agent because of socket permissions, so you should set metadata_proxy_socket_mode option[2] in order to let the metadata agent set the correct perms on metadata socket.<br><br></div><div>If you provide metadata_proxy_user/group in l3/dhcp-agent and metadata-agent config then neutron should be able to deduce both metadata_proxy_watch_log and metadata_proxy_socket_mode values.<br></div><div><br></div><br><div><br>[1] <a href="https://review.openstack.org/#/c/161494/" target="_blank">https://review.openstack.org/#/c/161494/</a><br>[2] <a href="https://review.openstack.org/#/c/165115/" target="_blank">https://review.openstack.org/#/c/165115/</a><br><br></div><div>Cédric/ZZelle<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 31, 2016 at 2:16 PM, Paul Michali <span dir="ltr"><<a href="mailto:pc@michali.net" target="_blank">pc@michali.net</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I had seen something and was not sure if this was a subtle bug or not.</div><div><br></div><div>I have a Liberty based openstack setup. The account that is setting up processes was user=neutron, group=neutron, however the metadata_agent.ini config file was set up for a different group. So there was a metadata_proxy_user=neutron, and metadata_proxy_group=foo config setting.</div><div><br></div><div>This ini file was used by the metadata agent process, but it was not included in the DHCP agent process (not sure if I should have included the metadata_agent.ini in the startup of DHCP or should have added these two metadata proxy settings to neutron.conf, so that they were available to DHCP).</div><div><br></div><div>In any case, here is what I saw happen...</div><div><br></div><div>I created a subnet (not using a router in this setup). It looks like DHCP starts up the metadata agent proxy daemon) and the DHCP configuration is used, which does NOT include the metadata_proxy_user/group, so the current user's uid and gid are used (neutron/neutron) for the metadata_proxy_user/group settings.</div><div><br></div><div>The proxy calls drop_privileges(), which because the group is different, the log file can no longer be accessed by the daemon. An OSError occurs with permission denied on the log file for this process, and the process exits without any indications.</div><div><br></div><div>When I then try to use metadata services it fails (obviously). Looking, we see that the metadata service is running (but the proxy is not, and I don't see a way for an end user to check that - is there a way?).</div><div><br></div><div>Looking in the proxy log, the initial startup messages are seen, showing all the configuration settings, and then there is nothing more. No indication that it is lowering privileges to run under some other user/group, that there was a fatal error, or that it is working and ready to process requests. Nothing more appears in the log, as it was working and there were no metadata proxy requests occurring.</div><div><br></div><div>I was only able to figure it out, by first checking to see if the proxy was running, and then manually trying to start the proxy, using the command line in the log, under a debugger, to find out that there was a permission denied error.</div><div><br></div><div>So, it is likely a misconfiguration error on the user's part, but it was really hard to figure that out.</div><div><br></div><div>Should/could we somehow indicate if there is an error lowering privs?</div><div><br></div><div>Is there a (user) way to tell if proxy is running?</div><div><br></div><div>Is there some documentation indicating that the proxy user/group settings need to be available for both the metadata agent and for other agents that may spawn the proxy (DHCP, L3)?</div><div><br></div><div>Regards,</div><div><br></div><div>PCM</div><div><br></div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>