11:39 a.m.
Thanks for the clarification, this clears my confusion about previous patch.
one remaining problem is: as we use self-signed certificate for kimchi,
every sub-site need to use its own cert--kimchi doesn't want others to
use this cert, and others may have there own certs.
but I suppose if we use different site (niginx server), we can leverage
TLS SNI support.
On 02/26/2015 08:25 AM, Frédéric Bonnard wrote:
From: Frederic Bonnard <frediz(a)linux.vnet.ibm.com>
Hi,
many people and distros use a subdirectory in the configuration of the system's
webserver
to configure different websites.
The usual way to setup a website is thus to :
1. use the distro's webserver to serve all the websites
2. have a subdirectory to copy the configuration file that makes available a website
by only restarting the webserver (and removing the website is just done by removing
the configuration file and restart). Concerning this point, the classical
configurations can be :
a) a sub web location : https://website.org/webapp
b) a virtual host : http://webapp.website.org
a) and b) correspond each to different configuration files that are just dropped into
:
- Ubuntu/Debian :
/etc/{apache,nginx,..}/sites-available/{webapp_subweb,webapp_virthost}.conf
- Fedora/Opensuse : /etc/{httpd,nginx,..}/conf.d/
At the moment kimchi is launched with a private instance of nginx, not the system's
installed one and it would be nice to have this improved and this is covered in another
thread :
http://lists.ovirt.org/pipermail/kimchi-devel/2015-February/009642.html
Provided that previous patch, one can use the distro's webserver to run proxy kimchi
and that fullfills 1.
Then for 2. one need a configuration file for either b) (provided for apache in the
link above ; I have also one for nginx ) and a), which I provide in this patch.
But this nginx configuration file is not enough for a sub web location configuration
as kimchi relies on absolute path based on / from the http://server/.
I tried to make URLs paths relative so that kimchi doesn't have to know where it has
been placed on the webserver, for example https://server/kimchi/ which will probably
be the URL used in distros.
I'm not a web developer and I tried to modify all failing requests with a a)
configuration
with relative paths in mind. So I'd like comments on the way this is done, and this
may need more extensive testing (paths I didn't test).
Though I used that code back on a virtualhost configuration and it worked as well.
Thanks for your help,
F.
Frederic Bonnard (1):
Making urls relative
docs/Makefile.am | 1 +
docs/nginx.conf.subsite.ex | 37 +++++++
src/kimchi/screenshot.py | 2 +-
ui/css/theme-default/template_add.css | 20 ++--
ui/css/theme-default/topbar.css | 2 +-
ui/js/src/kimchi.api.js | 176 +++++++++++++++++-----------------
ui/js/src/kimchi.login.js | 2 +-
ui/pages/guest.html.tmpl | 2 +-
ui/pages/help/dita-help.xsl | 4 +-
ui/pages/kimchi-ui.html.tmpl | 4 +-
ui/pages/storagepool-add.html.tmpl | 2 +-
ui/pages/tabs/storage.html.tmpl | 2 +-
ui/pages/template-add.html.tmpl | 2 +-
13 files changed, 147 insertions(+), 109 deletions(-)
create mode 100644 docs/nginx.conf.subsite.ex