Security Management wrote:
Andre,
I removed the deprecated lines from the workers.properties, and added the
JkMountCopy that you indicated.
Things work now.
The strange thing is, I'm not using a virtual host (name or IP based), it's
the canned apache installation for Fedora.
Maybe this is what did it??
[...]
Hi.
This now being more of an Apache configuration issue, it is getting a
bit off-topic on this list.
So since your urgent issue with mod_jk seems solved, let me just give a
couple of suggestions, and if you want to explore this further later on,
feel free to contact me off-list, or post on the Apache httpd user list.
I don't know Fedora per se, so what follows is a bit tentative.
What I suspect is that, unknown to you, the Fedora Apache installation
may be defining a Virtual Host anyway, although only a "default" one.
There is an easy way to find out. At the command line, type
"/usr/sbin/apache2ctl -S" (you may need to adjust the path to that
command). If you get an output somewhat like this :
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80 is a NameVirtualHost
default server evm2.mycompany.com
(/etc/apache2/sites-enabled/.default:1)
then it means you do have virtual hosts.
I created a mod_jk.conf in /etc/httpd/conf.d, which on Fedora, all files in
this directory get loaded at the start of the service, and in the main
configuration (not in the <Directory "/var/www/html"> element of the config
file). Was that the problem, adding all the configuration in the global
section, so it was not being seen in that site directive of httpd?
No, it is fairly logical to add it in the global section.
I explain below.
If so, the documentation was not clear to me what has to go in the global
config and what has to go in the specific site configuration.
There are some things that could be improved in the mod_jk
documentation. The mod_jk developers are aware of this, and would
welcome some help. I'm in the early stages of trying to do that. If you
can point to what wasn't clear to you (the specific page/section), I
could start around there.
I did
actually read the note about virtual hosts, but it did not indicate I need
to add the mount copy. If I have time, I'll do some more testing and see
exactly what needs to go where to not need the copy, but I don't have time
at the moment.
There is nothing wrong with the JkMountCopy per se, and you should
probably not try to remove it. It can be very practical.
Maybe the first aspect you should be aware of - if you aren't already -
is that just about every OS, and every distribution of Linux, has its
own schema for dicing up and laying out the Apache configuration files,
and adding its own specific scripts and configuration methods.
The standard Apache configuration has all of Apache installed under a
top directory like /usr/local/apache2, with a single configuration file
/usr/local/apache2/conf/httpd.conf, and does not explicitly define
VirtualHost's (an example exists in the standard httpd.conf, but it is
not activated).
The packagers of Linux distributions of Apache on the other hand (and
for a whole series of good reasons, this is no critic), seem to have a
great deal of fun splitting up Apache and its configuration in a maze of
subdirectories and files all over the filesystem.
It is usually quite practical on the one specific platform this is
written for (because it makes it easier to update the software,
load/unload additional modules, create additional virtual hosts etc..),
but makes it a bit harder for someone who is jumping from one system to
another to find where things are.
You generally end up with various schemes and bits under /etc/init.d,
/etc/apache2, /etc/apache2/*, /etc/sysconfig, /var/lib/apache2,
/usr/local/lib/apache2, /usr/share/www, /var/www, /srv/www, and so on,
plus a spaghetti-bowl of symbolic links.
All of this to say that it is just not possible for the mod_jk
documentation to describe in detail where you are likely to find what in
the real world, and what will be "included" from where to where and in
what order.
The same situation exists for Apache itself and for Tomcat, which is why
you'll often see on this forum exhortations to de-install the
platform-specific version and re-install a "real Tomcat" like ${deity}
mandated (and which is also for me a devious way of keeping this
rambling post on-topic).
Let's get back to mod_jk though.
But first let's talk about Virtual Hosts.
When an Apache server is configured with name-based virtual hosts, the
basic configuration should be seen as merely a set of "default values"
for the virtual hosts.
Then the first defined virtual host is the "default virtual host", the
one which inherits all these default values, and responds to all
requests that arrive here, but have no well-defined DNS-name to which
they are addressed (this being only a figure of speech).
Then usually, you start defining your "real" virtual hosts, the ones
that will respond to requests to "server1.company.com",
"server2.company.com" etc..
All these virtual hosts will also inherit the default configuration of
the basic httpd.conf, but then each one will probably override much of
that with its own specific configuration directives.
So, in the case of mod_jk (finally), all your basic configuration items
(like JkLogFile and so on), are placed in the main part of the
configuration and rightly so, so that they are inherited by all virtual
hosts by default. That is logical because usually, if you have a
configuration with Apache as front-end and Tomcat(s) as back-end(s), you
are probably going to want to use mod_jk and Tomcat for all your virtual
hosts, not just for one, you will want the same logfile format etc..
But..
the situation is a bit different for the mapping of URI's to Tomcat
webapps (JkMount/JkUnMount et al.). For these, usually, you will want
different mappings to be used in different virtual hosts.
That is why these URI mappings are /not/ automatically inherited from
the basic httpd configuration into the virtual hosts. You have to
specify explicitly what you want.
You can do that
- either by putting the JkMount/JkUnMount configuration directives in
each VirtualHost section (where they apply only to *this* virtual host)
- or, in each virtual host individually, add a "JkMountCopy On" if in
this virtual host you explicitly /want/ to inherit the mappings done in
the default configuration.
- or by specifying explicitly in the basic default configuration a
"JkMountCopy All" (forcing the basic default values to /be/ inherited by
/all/ virtual hosts)
To make things just a little bit more confusing, there are (at least) 3
different ways in which you can map URI's to mod_jk and Tomcat :
- JkMount/JkUnMount directives directly in the Apache configuration
files (httpd.conf and whatever is being included in it directly or
indirectly)
- "SetHandler jakarta-servlet" configuration directives used within
<Location> sections in the Apache configuration files
- separate "uriworkermap" files, pointed to by "JkMountFile" directives
in the Apache configuration files
and if you want to look like a Real Cool Connector Wizard, you can
probably combine all of the above.
HTH
André
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
