Description of problem: The references architecture team hit a scenario where their toplevel apache would not proxypass to the backend broker when using the broker hostname. It would work with either 'localhost' or the broker's IP address. eg, Broken: curl -k https://broker-spr.osop.cloud.lab.eng.bos.redhat.com/broker/rest/api Worked: curl -k https://localhost/broker/rest/api curl -k https://10.16.138.13/broker/rest/api We worked around this issue by setting the Server to the actual hostname instead of the default value we ship with of 'localhost'. We should advise users to fix this in oo-accept-broker.
We might want to look into doing this of oo-accept-node as well.
oo-diagnostics might already take care of this.
I want to look deeper into this to make sure we're making the right recommendation for all circumstances. Right now, if you install broker+console+node on the same server this is still a bit hinky. I think the accept/diag scripts should provide good guidance on this but I need to figure out exactly what that guidance is.
ServerName localhost isn't necessarily a problem. The problem comes with trying to juggle three independent RPMs trying to define the same default vhost *:443. To do it without warnings or unintended consequences is a little tricky. The simplest workaround is to remove the ssl.conf vhost, as it serves no purpose, and currently gets its ServerName from reverse DNS resolution of the server IP (i.e. "it depends"). Slightly more complicated, move ServerName outside the vhosts so it's set for the main host and thus all vhosts not otherwise declaring one, including the one in ssl.conf. Adjust number of NameVirtualHost directives as needed to not get a warning. Going to wait a little while for anyone to express preferences and then proceed. Will include updated directions / script / conf as well as diagnostics scripts. BTW this isn't really a problem on nodes. Though we might someday want the default vhost to actually direct visitors somewhere useful.
I like the idea of warning the user that they should remove the stock ssl.conf. We could do that in oo-accept-broker/node. Would it be possible to have a new configuration file that sets the ServerName at the server level and all the vhosts would pick it up? Could we even have the default for that be 'ServerName localhost'? Ideally 'ServerName localhost' would work since it would be one less thing to configure dynamically. Admins that want to change that value should be able to and our tooling should suggest it. It would be great to expose one setting for them to change instead of having to play around with the various vhosts.
After reading up on some of the other threads I'm fine with only removing the vhost from the stock ssl.conf too.
I was waiting to see if anyone had strong opinions, but my thought is this: 1. Advise folks (document) to remove the ssl.conf vhost. 2. Modify broker and node conf to: 2a. put "ServerName localhost" outside the vhost (can be modified if desired, doesn't really matter, the point is to give an explicit default ServerName). 2b. specify "ServerAlias localhost" inside both vhosts. Mainly I want the broker to have it in case the node is also installed. 2c. remove "NameVirtualHost" from broker conf as it shouldn't be needed if they've followed #1. 3. Modify oo-accept-broker to fail for two problems: 3a. where the ssl.conf vhost has a different ServerName than anything else and thus might get traffic - advise to remove the ssl.conf vhost 3b. where the node is also installed and has a different ServerName and thus might get broker traffic (particularly "localhost" since oo-accept-broker uses that to check the broker) - advise ServerName juggling. This script doesn't really "do" warns, it's pretty much oriented at "fail/ok" so I think anything more subtle needs to stay in oo-diagnostics.
Meant to say - as far as having a new configuration file just for server-wide ServerName, we could do that, it's just a question of where to put it so there's always exactly one. If both node and broker RPMs own the file they'll conflict but they don't really have a common dependency and it seems a bit silly to create one just for this.
My thought it that we should have the broker and node RPM each create their one httpd config file for setting the ServerName server-wide. Something like: /etc/httpd/conf.d/000000_openshift_origin_broker_server_name.conf /etc/httpd/conf.d/000001_openshift_origin_node_server_name.conf The fact is both of these files would have the same content. Even in the case where the broker and node were installed together in development that should be OK. I think we should still document removing the vhost from the stock ssl.conf.
I added these files as suggested and made other changes. In OSE 1.1 the changes are in openshift-origin-broker-1.0.8-1 and rubygem-openshift-origin-node-1.0.10-1. Upstream I committed the same changes with https://github.com/openshift/origin-server/pull/1120 for Origin. This includes oo-diagnostics changes to detect this problem and warn about it. I didn't think it actually merited a FAIL from oo-accept-broker or oo-accept-node. The way I expect this to work out of the box is this: 1) On a broker, there's no longer a NameVirtualHost *:443 so there is a warning at httpd startup. Removing the ssl.conf vhost is the solution. It will work regardless, but oo-diagnostics and docs will advise removal. 2) On a node, everything works fine, the ssl.conf vhost is still advised to be removed but it has no effect at all. 3) On a combination broker+node, everything works fine, the ssl.conf vhost is still advised to be removed but it has no effect at all. I still need to put in a docs bug about removing ssl.conf vhost and do the same in the kickstart script, but even if they don't do this there will be no functional problems.
This will ship with the next puddle.
Retest this bug with 1.1.x/2013-01-08.1, and FAIL. 000000_openshift_origin_broker_server_name.conf and 000001_openshift_origin_node_server_name.conf are not installed into broker and node. But they are existing in enterprise-server github repo.
About 000000_openshift_origin_broker_server_name.conf and 000001_openshift_origin_node_server_name.conf, I do not think these two config files to set server-wide ServerName is necessary to be created. Even in the case where the broker and node were installed together, if these two files do NOT exist, all the request could be sent to correct backend. If I miss some thing, pls correct me.
I did something wrong somewhere, trying to set it right; apparently I committed the RPM spec file changes in the wrong place. It's a little tricky because you're right, in most cases there is no problem, especially in production systems. It's hard to explain coherently why this change is needed without explaining a lot of contingencies.
The spec file should correctly lay down these files with openshift-origin-broker-1.0.9-2 and rubygem-openshift-origin-node-1.0.10-4
oo-diagnostics now detects the problem. First, it warns if there is a vhost in ssl.conf. Then it FAILs if either the node vhosts or the ssl.conf vhost has ServerName that could possibly interfere with the broker vhost. The recent kickstart script includes a line to remove the ssl.conf vhost.
Verified this bug with broker+node env set up from 1.1.x/2013-01-16.1 puddle, and PASS. 000001_openshift_origin_node_servername.conf and 000000_openshift_origin_broker_servername.conf are installed into correct place. oo-diagnostics does NOT report error in broker + node env, and if warning is seen if there is a vhost in ssl.conf. <--snip--> INFO: checking for vhost interference problems WARN: test_vhost_servernames The VirtualHost defined by default in /etc/httpd/conf.d/ssl.conf is not needed and can cause spurious warnings. Please remove it by running this command: sed -i '/VirtualHost/,/VirtualHost/ d' /etc/httpd/conf.d/ssl.conf <--snip-->
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0220.html