Well, I'll be damned, I do have virtual hosts: VirtualHost configuration: wildcard NameVirtualHosts and _default_ servers: _default_:443 sirrus.smc (/etc/httpd/conf.d/ssl.conf:81) *:* sirrus.smc (/etc/httpd/conf.d/system-config-httpd.conf:314) Syntax OK
Andre, I don't know how long that would have taken me without the help, but it would have been a lot longer. Thanks a bunch. I will investigate further, but it's definitely OT for this list at this point. Mike. -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, April 15, 2009 10:36 AM To: 'Tomcat Users List' Subject: Re: Help with mod_jk and Apache 2.2 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
