Web Hosting

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%


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

XHTML Markup Standards

Every New Media Logic template should share nearly identical XHTML structures. They should include each of the following elements. Certain elements may be omitted, but only if the feature is not needed. Do not omit elements in this list while replacing them with an alternately-named element that serves the same purpose.

Required Elements

div#page

This element will usually be the first child of the body tag. It should wrap the entire content of the web page, including the header, footer and content area. Exterior page margins and borders should be defined through styling of this element.

• Read more

Create group webadmin. Grant group access to all users who need administrative access to the web server.

Download the Jetty distribution from jetty.mortbay.org.

Extract to /usr/local/jetty-%VERSION%.

Create symbolic link to /usr/local/jetty-%VERSION% at /usr/local/jetty.

Edit /usr/local/jetty/extra/unix/bin/boot-jetty.sh. Change the JAVA_HOME variable to /etc/alternatives/java_sdk. Change JETTY_HOME to /usr/local/jetty. Change JETY_XML_FILE to /usr/local/jetty/etc/admin.xml /usr/local/jetty/etc/jetty.xml. Check permissions on LOG_DIR.

Create a symbolic link to /usr/local/jetty/extra/unix/bin/boot-jetty.sh at /etc/init.d/jetty. Set permissions for /etc/init.d/jetty.

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.

The Apache Software Foundation's Tomcat servlet container was developed with an external module to connect it to other web servers using a protocol called AJP. The code is implemented in a project called JK. It is often referred to as mod_jk, because that's the name of the Apache HTTPD module. For some reason, the implementation for IIS is called ISAPI_Redirect.

The connection between IIS and Tomcat (or any of the numerous other servlet containers that have implemented AJP receivers to work with JK) is relatively simple. The JK DLL is installed into IIS as a filter + extension. It is configured to activate itself on certain URL patterns. For those patterns that match, the DLL sends an AJP packet to the servlet containers (called "workers") that have been configured. Assuming the servlet container has an AJP listener turned on, it then responds with the content of the response.

Note: Communication via AJP can be configured to happen on any port. By default, the port is 8009. AJP is not a secure protocol, so this port should be limited to communication between internal servers. Port 8009 should not be open on the external firewall.

Installation

First, download the JK 1.X Win32 binary from the an Apache mirror:
http://jakarta.apache.org/site/downloads/downloads_tomcat-connectors.cgi

If using IIS 5 or newer, download the isapi_redirect-1.x.exe. The EXE installer is the most convenient installation method.

The installer places all its files in C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\. Example (usable) configuration files are placed in the conf subdirectory.

Registry configuration is also set up at HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0. The registry keys point the ISAPI dll to the configuration files in C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf.

You'll also find a new Virtual Directory, called jakarta in the IIS Web Site configuration window. This directory is needed to forward the requests on to the application server, although it will not be present in your site's URLs.

Setting up a Context

To set up a context (an application hosted in a subdirectory of the site), you need to edit the
uriworkermap.properties file in the installation folder. This file maps URLs to workers. A "worker" is an instance of Tomcat, Jetty or another application server that supports the AJP protocol. The term more accurately applies when mod_jk is used in a load balancing environment.

The uriworkermap.properties simply identifies URL patterns that should be forwarded to an application server. The URL will not be changed in the process, so IIS mapped URLs must be identical to the context/URL configuration of the application server.

For example, assume we have applications (contexts) called accounting, intranet, and development set up in Tomcat. When using Tomcat's own HTTP, the URL for the accounting application woudl be http://localhost:8080/accounting. To set up this application to be accessed through IIS, we'd modify uriworkermap.properties like so:


/accounting/*=ajp13w


In this case, ajp13w identifies the name of the Tomcat worker. The name ajp13w is the name of the default installation worker (which will likely be configured correctly if IIS and Tomcat and IIS are on the same server). The mapping indicates that all requests to the accounting subdirectory be sent to Tomcat.

Note: You'll need to restart IIS to get the new URL mappings to activate.

Division of Labor

You may want to divide responsibilities so that IIS handles static files, and only dynamic content is served by the underlying application server. This is typically done by unmapping certain file extensions in the uriworkermap.properties file. Unmap directives are identical to mapping ones, with an added ! as the first character.


!/accounting/*.jpg=ajp13w
!/accounting/*.gif=ajp13w
!/accounting/*.png=ajp13w
!/accounting/static/*=ajp13w


The above directives would cause mod_jk to not forward JPG, GIF and PNG requests for the accounting context. It also causes the entire static subdirectory to be ignored by mod_jk as well.

Now to make sure IIS knows where to find these files, we'll need to set up a Virtual Directory where these files can be found. In this case, we'll set up an IIS Virtual Directory called accounting (it must be the same as the context). We'll point that virtual directory to the same one that hosts the application server files.

HTTP Authentication

In many cases, you'll want the application server to continue to manage authentication. This setup is more portable (the same username database will be used on any web server), and it saves the effort of configuring usernames and passwords through Windows or IIS.

If your application uses HTTP Digest or Basic authentication, you'll need some special configuration, as IIS will normally try to hijack the application servers authentication attempts.

By default, the jakarta Virtual Directory has its own Directory Security settings turned on (Integrated Windows authentication is enabled, I believe). If you want authentication to be handled by the application server, you'll need to turn off all but Anonymous access in the Directory Security tab for the jakarta Virtual Directory. The same applies to context Virtual Directories if you're using them.

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

Experience shows that the effectiveness of web sites increases in proportion to their interactivity. Put simply, the more customers can do with your web site, the more they'll visit. We believe web sites should be more than digital brochures. A web site is an opportunity to extend and enhance your relationship with your clients and customers. Content Management Systems represent the most powerful way to turn your web site into an interactive online community.

Our Content Management System solutions allow you to easily make changes to the pages of your web site. Update your online p

• Read more