On 12/03/15 02:50, Aline Manera wrote:
On 10/03/2015 14:39, Frédéric Bonnard wrote:
From: Frederic Bonnard <frediz@linux.vnet.ibm.com>
Hi, I'm using the patch from Julien for this one : http://lists.ovirt.org/pipermail/kimchi-devel/2015-February/009840.html and it wasn't taking the option into account, here is some changes that worked for me.
Also, I think that the goal of disabling nginx in this patch is not to use kimchi directly, but to use another instance of nginx as I did or apache as Julien does.
I have some points on it:
1) If we allow user to disable nginx proxy we need to make sure kimchi server will continue working as expected whatever is the user reason to do that.
As long as someone uses a proxy (or some other way to make it accessible like using it on a desktop, or SSH port forwards) Kimchi just works, there's nothing special about nginx.
Based on that, please consider: http://lists.ovirt.org/pipermail/kimchi-devel/2015-February/009705.html
WRT that the X-* options are sensible, but cherrypy shouldn't be setting HSTS since it can't know if it'll be proxied using TLS. Obviously for the websockets based console to work it'll need to be via TLS. I've updated my patch to include them and will resend it, I could also look at setting them on the Kimchi side as well.
2) If the idea is allow using other proxy instead of nginx, what are the options? How would user use them? How does Kimchi will deal with them?
Royce also comments on that: http://lists.ovirt.org/pipermail/kimchi-devel/2015-February/009655.html
Remember, Kimchi is focused on entry level users which means it must be easy and simple since installation/configuration time and it affects all changes we do.
I don't think that's a real problem, the users likely to want to run their own proxy are those who would (predominantly at least) already know what they want to use, and how to configure it. Novice users will simply keep the default setting and continue using nginx unchanged. The inclusion of an apache2 configuration snippet is two-fold, first, it's the most common web server still and thus the most likely to be wanted as a proxy; second, being the most common it's common for other web servers to include a translation of apache terms in their documentation, or documents that others write.