-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rainer,
On 11/7/14 5:44 PM, Rainer Jung wrote: > Hi Chris, > > Am 07.11.2014 um 23:04 schrieb Christopher Schultz: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> All, >> >> I've been playing around with mod_jk's status screens a lot >> lately. I also recently upgraded from Apache httpd 2.2 to Apache >> httpd 2.4 and the hostname shown at the top of the page changed >> from the "real" hostname to the masquerading hostname (more on >> that in a second) and I was wondering what else was going on. >> >> First off, I have a load-balancer with 3 web servers behind it. >> Each individual web server has its own distinct hostname (the >> "real" hostname) like foo.example.com, bar.example.com, etc. >> plus, when you contact it through the load-balancer, it thinks >> it's "www.example.com" of course. >> >> Everything seems to work fine. >> >> These days, the jk-status page always says "JK Status Manager >> for www.example.com:443" when I visit the page, no matter which >> back-end server I get by entering >> https://foo.example.com/jk-status. When I connect to an >> individual server, I use HTTPS of course, so I get the >> "_default_:443" virtual host which makes sense. >> >> My conf/hostname.conf has "ServerName www.example.com" and no >> server aliases, and my conf.d/ssl.conf has no ServerName and no >> ServerAlias. (This is on Amazon Linux, which is essentially >> CentOS, and I'm using package-managed versions of httpd so this >> is the layout they have). >> >> I'm assuming that, since I have no ServerAlias for my :443 >> VirtualHost, that's where the name at the top of the page comes >> from. Can anyone confirm that? It would be nice if the page >> advertised my "real" hostname instead of the generic one. That >> is, I'd like to see "JK Status Manager for foo.example.com:443" >> instead of "www.example.com:443". Would adding a ServerAlias in >> either hostname.conf (which I believe is loaded at the top-level >> configuration) or in ssl.conf inside the VirtualHost achieve >> that? > > The name that is shown is the server name for the request being > handled. This name is influenced by > > - the host header send by the client - the ServerName configured in > the VirtualHost or global server actually serving the jk-status > request - the UseCanonicalName setting Ah, I had forgotten about UseCanonicalName. It is set to "On" so everything is being set to www.example.com. > For details see: > > http://httpd.apache.org/docs/2.4/en/mod/core.html#usecanonicalname > > A ServerAlias does not directly change that name. But if setting a > ServerAlias in a VirtualHost that does not handle jk-status > currently results in that VirtualHost handling your jk-status afer > setting the Alias, it can also change the name shown in the page. > > First check what your UseCanonicalName setting is. If it is off, > then mod_jk will simply show what is in the host header of your > request - as long as your LB forwards the host header correctly. > That would typically the best situation. Everything else quickly > gets messy. Agreed. I may disable UseCanonicalName for the direct-to-web-server VirtualHost. Or, perhaps I'll do: ServerName foo.example.com ServerAlias www.example.com UseCanonicalName Off >> Next, I have a question about the workers. I believe - but I'm >> not sure - that each worker is unique to the server as a whole, >> and not to just a single VirtualHost, right? That is, my >> jk_workers.properties file contains a series of worker >> definitions and I can use them in any VirtualHost I like. If I >> reference the same worker from two different VirtualHosts, I just >> get two references to the same worker, right? >> >> The reason I ask is that I don't have the jk-status page >> available for users coming from the load-balancer. I want to make >> sure that when I disable a worker when looking at the :443 >> jk-status page that I'm disabling it across all VirtualHosts in >> the server. >> >> (The load-balancer uses a different VirtualHost, and it's tough >> to convince the load-balancer to pick a specific back-end server >> to direct my commands to, so... it's kind of important that the >> above be true.) >> >> Can anyone confirm that the workers are shared? I think it would >> be very difficult to administer if the workers were not shared, >> but I wanted to be absolutely sure. > > Yes, workers and their status are global (shared). Only Mounts are > not. Great. We've been having some problems draining Tomcat nodes, and I was concerned that maybe I had overlooked this one possibility. Our next release will include a version of the recently-discussed load-balancer draining filter/valve so we'll see how that does. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUXU6oAAoJEBzwKT+lPKRYyFYQALYipZysSxOlYHrx0UYRFneW r/169hi1JZ87ZF56LADktME82kJLQZJ1kpk0217YEBVg+8gNgCVHWiA5Xd2jGPnB jOY+YBmytly4wzLB3zeiNW+dXoy2Nzb3br1ctnWcHPSOqaoWkwMTqcwPp1IPfPAY XtFLPt7tWTJKRnEGyWaC0MWmVpNF51xDudtSENsetJAMLdyCSe/SXOksdD2/ERIh 0+sGI3vjubUKO/JkMQr93+q5e0ZhAPQu5sopoq6vfoMyghCA/16RQOwQBHNYFCAN O77Tysk7HwsifIXckj9QFQukGV5kP+rVKU3m31Vw75b3fX7XyK2Gv5HW3uLLSYV8 iq5e0Fpf4ZmDgEZG+oRRkeEoC2MgdsGbGYy5ljW0bWZ2GyAV+9OzehZywwEyXITM mOr4kn6qe7hko2NF4R1zA3TBdhhMxocI7mHGK/4e3z5Y03XU2uKYZkkNWbof5Vpi CFH42YPPxkExsBuhTizAx4omh6rFYs5W1lcdyFzM9bfJ0mTE/i9IBOiZ0wTJjyp0 04F/CJFy9vgsNhu8RFD+CfgH2kpsCvlmLSNfiqRw4U/1nSpxfLIG95J06yJVPm0a pGdaAjcV6AH1jCGFrABNH8ANg/4GODCyJNfHf43wlgcJmwyuyngdCOzcprxKFHCf g4utrDTCOZHlI3qaBnBM =5Ys2 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
