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

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.

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.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to