Apache

Ubuntu uses a nice symlink system to enable and disable apache modules. To enable a module. Use this simple command:


sudo a2enmod %module_name%


To disable one:


sudo a2dismod %module_name%


All PHP includes were failing in my Drupal application on a newly configured SUSE box. After verifying all the permissions, I found that the php.ini file had an extra-secure
include_path variable. Unlike most other distributions it doesn't allow relative path includes. To change that, just modify the
include_path variable like so.

The change is subtle. Notice the dot before the colon. That

SUSE's distribution of Apache does not enable mod_rewrite by default. To enable it, edit
/etc/sysconfig/apache2 as root. Look for the uncommented APACHE_MODULES variable, and add
rewrite between the quotes.

http://wiki.rubyonrails.com/rails/pages/RailsOnFedora

Virtually all J2EE servlet containers come bundled with an HTTP server, and setting one of them up is usually very simple. Despite the conveniece, I've found many reasons not to use these bundled HTTP servers in even a development/testing environment. In production, the decision is simple: the Apache HTTPD server is faster, more stable, more secure, more configurable and more powerful than any bundled HTTP server. In development and testing, I've found the configurability of Apache to be an enormous asset, offsetting the additional challenge of using mod_jk to link Apache and the servlet container.

Downloading mod_jk

The mod_jk package is closely connected to the development of Jakarta Tomcat, and can be downloaded most easily by finding a tomcat mirror site. From the Tomcat site, make your way to a download mirror (via the download links), and then browse to jakarta/tomcat-connectors/jk/binaries/ once inside the mirror (paths may be slightly different due to mirror uniquenesses). From the binaries directory for your platform, download the newest version of mod_jk that matches your Apache version. Note that there are separate packages for the Apache 1.x and 2.x release cycles.

Placing the Module

After downloading the .so file, you'll need to place it in your Apache modules directory. Rename the file mod_jk.so and place it in %APACHE_ROOT%/modules.

Notifying Apache

Create a file d:/www-config/mod_jk-apache.conf, and place the following statements in it.



LoadModule jk_module "modules/mod_jk.so"


#
# Standard mod_jk mappings
#
JkMount /*.jsp java1
JkMount /servlet/* java1
JkUnMount /servlet/*.gif java1


That file is imported using the Apache configuration recommended in another post, where Apache's httpd.conf includes all .conf files in d:/www-config. Note: the documentation for mod_jk directives is available.

The workers.properties file referenced above is a listing of "workers" (instances of a Java servlet container). Create the file d:/www-config/mod_jk-workers.properties.


worker.list=java1

worker.java1.port 8009
worker.java1.host localhost
worker.java1.type ajp13


The complete chain works like this: 1) The Apache JkMount and JkUnmount directives tell Apache which request patterns to forward on to the servlet container by its "worker" name. 2) The servlet container with the worker name in question receives the request as if it came directly from the client computer. 3) The servlet container's response is retrieved by Apache and returned to the end user. The trick is that only portions of the hosting tree are mapped to Java. Ideally, static HTML, Javascript, CSS and images are handled by Apache directly, without having to consult the servlet container.

For developing Java servlet-based web applications, I prefer the startup speed of Jetty combined with the configurability of Apache. This tutorial describes how I connect Jetty and Apache through mod_jk in a development environment.

Installing Jetty

To use the Windows NT service, we need the Jetty "extra", package. Download the distribution from the downloads page on the Jetty Web Site. This can be either a tarball or a zipped archive.

Unzip the archive to c:\jetty. The zip structure has an internal folder structure, so the final location will be c:\jetty\jetty-%VERSION%.

Setting up the Windows Service

The Windows Service is configured by customizing the extra/win32/wrapper.conf file. The following lines should be inserted in their logical positions (i.e. config.3 comes after config.2 and config.1).


wrapper.java.classpath.3=../resources

wrapper.logfile=d:/www-logs/jetty-wrapper.log


There are a few things to note in the configuration changes above. First, the Jetty STDOUT log has been directed to our universal logging directory at d:/www-logs/jetty-wrapper.log. Secondly, we're not using the default admin.xml and jetty.xml locations. We've pointed those to our universal configuration directory at d:/www-config. We'll cover the contents of the jetty.xml file later.

After applying the changes to the wrapper configuration, the NT service is installed with the wrapper.exe application. Run the following commands from the extra/win32/ directory.


wrapper -i wrapper.conf


Jetty Server Configuration: jetty.xml

As mentioned earlier, the primary Jetty configuration file, jetty.xml, has been moved to a new location in our setup. For the most part we copy the settings in the default jetty.xml. Be sure to enable the AJP13 listener. This is how Jetty supports mod_jk.





8009
5
20
0
443





No other changes are strictly required, but I'll include the following as an example of a web application context.




/tempo
d:/projects/exampletarget/webapp-stage



Jetty can now be started and stopped with the Windows net command. As long as Jetty is running, it will accept properly configured mod_jk requests sent from Apache.


net start jetty
net stop jetty


I don't normally host production web sites with Apache running on Windows. However, I develop primarily on a Windows machine, and Apache's configuration options are far superior to IIS. Things like mod_rewrite and wildcard configuration files greatly simplify the development cycle for me.

I've put together this tutorial to explain how I have set up my Apache2 environment in Windows. This setup should be easy to modify to fit several different strategies.

Installation Process

Apache's automated installer works very well now. I do not recall exactly, but I believe my last install used all default settings, with the exception of the install path (I use c:\apache\%VERSION% instead of the c:\Program Files mess).

Post-Install Configuration

Apache's configuration begins with the httpd.conf file, which is located at %APACHE_DIR%\conf on Windows systems. I typically make several changes to this file, and then use wildcard imports to bring in virtual hosting directories and other optional hosting features.

The first change is to add a wildcard Include at the top of the file. This will bring in optional functionality (PHP, JK, etc). I would prefer this statement to come at the bottom, but mod_jk requires a specific loading order in the Apache config. Note that the .conf files are stored on the D drive. This separates them from the operating system, easing the setup for re-installs/crashes of the Windows hard drive.


Include "d:/www-config/*.conf"


Other documents on this site describe the contents of the .conf files.

Next, set up the DocumentRoot directive to a location on the D drive as well. Replace the default DocumentRoot value with the one below.


DocumentRoot "d:/www"


Then point the logs to a unified logging directory, also on the D drive. Replace the default ErrorLog and CustomLog entries with those below.


ErrorLog "d:/www-logs/apache-error.log"

CustomLog "d:/www-logs/apache-access.log" combined


Lastly, I like to host development projects in aliased subdirectories. I've found that wildcard Includes work well for this task. I add one to the last line of httpd.conf.


Include "d:/www-config/vhost.*"


Despite the name, the vhost.* files do not contain Apache <VirtualHost> entries. Here is an example file.


Alias /projectname d:/projects/projectname/target/webapp-stage


Order Allow,Deny
Allow from All



Apache's web site has its own Windows hosting guide. It is much more extensive than this tutorial, so check it out.

I found this article:

http://www.thompsonbd.com/chris/tutorials/apachessl.html

I've been having trouble with the DirectoryIndex directive when I'm using mod_jk to map JSPs (and other J2EE URLs) to Jetty or Tomcat. When accessing the directory path /webappname or /webappname/, I receive a 403 Forbidden error. If I add Options Indexes to the directory, I receive an apache file listing. Oddly, when accessing the file directly, using /webappname/index.jsp, it works fine.

The reason: mod_dir was being loaded before mod_jk. This causes the mod_jk check for the file to never occur. To apache, it looked like the file didn't exist, because mod_jk has jurisdiction for *.jsp in the directory.

• Add new comment
• Read more