In Part 1 (Why Are You Waiting?, September 2004 issue), I discussed the business and technical considerations in migrating Microsoft IIS Web servers to Apache on Linux as well as the overwhelming cost, security, and stability benefits of making the move. Based on the tremendous feedback I've gotten, it appears many LinuxWorld readers agree with me (evidently I'm preaching to the choir).

In Part 2, I'll address those who've decided that migrating to Apache on Linux is the way to go for their organization. Now that the decision has been made, how do you make it a reality? Well, I'm glad you asked.

Plan, Plan, Plan
Henry Ford once said, "Before everything else, getting ready is the secret to success." This is sage advice not only for making cars but deploying Web servers. Because migrations can be a problem without careful planning, you'll want to make sure your technical staff has the skills necessary to implement and maintain a Linux environment since there are major operating system and administrative differences between Windows and Linux. At least some of your staff should be Linux-certified (LPI level 1 and/or LPI level 2 or the equivalent). Many third-party training and Linux certification courses are available to organizations migrating to Linux. In addition, consider outside consulting. Professional assessment, planning, process design, and implementation services often yields less technical and cost surprises in the long run.

Choose Your Programming Language
For your server migration, should your organization support your existing development languages (such as Visual Basic served via ASP) or move to new development environments (such as PHP)? There are many limitations to ASP such as its slow execution speed and poor ability to scale. Besides ASP isn't cross-platform (it only runs under Windows). However, if you prefer Visual Basic or don't want to invest time on sites that haven't been touched in years, you can still move to Apache and keep your old ASP code. There is a commercial product available to help in this transition: Sun Java System Active Server Pages (for info visit www.versora.com/products/sun_asp.php) lets you host ASP on almost any platform Apache runs on. However, you may need to make some site-specific changes.

As many of you already know PHP is open source software and free of licensing fees. It's also considered by many to be a superior choice among Web programming languages due to its speed, excellent scalability, world-class memory management, integration with the MySQL database, and cross-platform development portability. If you decide to migrate from ASP to PHP, an open source program called asp2php will help. It seeks to convert ASP sites over to PHP automatically. While not perfect, many of the tedious changes in the conversion are made easier.

If you're migrating to a new language, make a list of all the components you're using (especially third-party components) and map those to their PHP (or other language) counterparts. Most likely you'll find that a number of components that you had to purchase for your ASP solution are freely available with PHP including e-mail, image manipulation, and PDF generation. In addition, there are entire frameworks for such things as shopping cart applications. My company uses an excellent open source tool called OS Commerce for our e-commerce needs. Making this list has a second purpose - you can use it to help determine installation options for Apache later.

Keep in mind that Apache can take advantage of several languages besides PHP including Perl, Python, and Java (via JSP). New languages and development paradigms are introduced often in the open source world. A good example is Ruby on Rails (www.rubyonrails.org).

Choose Your Hardware
I don't have space here to cover all the factors that go into deciding which hardware to use as a Web server. There's one important question you should ask yourself however. Do you plan to migrate your existing Web server from IIS to Apache or are you planning a migration in conjunction with a hardware update? If you plan to migrate your existing machine, understand that you won't be able to roll back after migrating unless, of course, you do the work required for a rollback. In either case I strongly recommend that you make a copy of your Web directories and back up any database you're using before attempting a migration. Finally, any new hardware you buy should be on the supported list of the Linux distribution you plan to use.

Manually Performing the Migration
After the planning process, there are six migration steps to follow. Let's get to work!

Step #1: Install and Configure the Target Linux System
The first step is to install the version of Linux that you want to run. There are 10 major distributions listed by Distro Watch (www.distrowatch.com) and hundreds of others depending on your comfort level with Linux. I recommend choosing a distribution with good installation support for Apache and a large number of Apache modules. For those unfamiliar with Apache setup, Apache provides some functionality in the form of add-on modules (for example, PHP support is provided as an add-on). I'm using Novell's SuSE Linux as a test as I write this article, but all the major distributions provide a fairly straightforward way to install Apache.

Step #2: Install and Configure Apache
Installing Apache is often so simple that you may wonder why I mention it at all. There are a few issues to consider. First, there's the choice of which Apache version to use - Apache 1.3 or Apache 2. Apache modules are written to work with a particular version of Apache. Most common modules work with Apache 2 (the number is increasing all the time). Unless you have some specific reason to use Apache 1.3, I recommend Apache 2. Using Yast, which is the installation tool for SuSEse, the entire Apache 2 package with a set of default modules is referred to as "Simple Web Server with Apache 2".

When installing Apache 2, you must decide which method to use for multiprocessing (MPM). This detail is important since there are a few modules that only run with one of the process models in Apache 2. Your choices are "prefork" and "worker." Simply put, "prefork" uses the Apache 1.3 process model where every server runs in its own process. "Worker" is intended to be a more efficient thread-based model incompatible with some Apache modules (some versions of mod perl being a good example). For stability and the greatest module support, I suggest using the "prefork" process model.

Step #3: Install and Configure Support Languages and Tools Installing Apache Modules
Hopefully you took my advice and wrote a document that maps the set of modules you're using on IIS to the set of modules you'll need to support on Linux. Depending on the language you chose you'll need to install the appropriate module to support PHP (apache2-mod-php4), Python (apache2-mod-python), Perl (apache2-mod-perl), etc.

Some other popular modules you may want to install are:

• mod_mono: Support for ASP .NET Web development
• mod_ssl: SSL support
• mod_dav: WebDAV support (see www.webdav.org)
• mod_auth_mysql: This module lets you use a MySQL database for Web site authentication
• mod_auth-ldap: This module lets you use LDAP for Web site authentication

Installing Java
Depending on the specific Java support you want, there are a number of different options for installing Java. Servlet support can be provided by the excellent Apache Tomcat project. See the Jakarta project at http://jakarta.apache.org for more information on Java-related Apache support.

Installing Additional Modules
Depending on your language choice you may need to install non-standard modules for your language. With PHP, almost everything you'll need is built-in. Certain functionality like XML DOM manipulation may require additional modules to be installed as part of PHP. You may need to rebuild PHP itself to enable support for the full set of modules you need. Consult the map you created during the planning phase to determine if this is necessary.

Step #4: Copy Web Documents
One of the more obvious steps in migrating from IIS to Apache is moving Web documents to your new server. By default, IIS stores its documents in c:\inetpub\wwwroot. Apache (on SuSE) uses /srv/www/htdocs for the main server and subfolders of /srv/www/vhosts/ for virtual hosts.

Moving files from one server to another can be quite easy using Samba, an open source implementation of Microsoft's file-sharing protocol. Make sure file sharing is enabled on your Windows server, and then share the folders you need to migrate (your document root, for example). On the new server, we'll temporarily grant write access to the document root so we can use graphical tools to do the copying. Launch a terminal program (such as Konsole) and type:

sudo chmod 777 /srv/www/htdocs
sudo mkdir /srv/www/vhosts
sudo chmod 777 /srv/www/vhosts

You'll need to enter the root password for the server after the first line. Use the graphical tools built into your Linux distribution to copy the files. For example, in KDE you can use Konqueror to browse to the Windows server and copy the files over to the Apache document root location (/srv/www/htdocs or subfolders of /srv/www/hosts/). Once you've browsed to the Windows server, highlight the IIS folders that you've shared and wish to move, and drag them over to /srv/www/htdocs/ (you can type this path into a second open Konqueror window). At the pop-up menu that appears, choose "Copy here."

Note: Depending on the number of files being copied, this can take a while. When you've completed this step, you should reset the file permissions (via sudo chmod 755 /srv/www/htdocs) to keep others from changing these files.

Step #5: Configure File System and Web Server Security
The security models used with IIS and Apache are vastly different. IIS is tightly integrated with Windows and uses the exact same authentication rights as Windows itself. While this leads to easier central user management, it also leads to security problems.

For instance, if a user is created for Web access, by default that user will also have permissions to log on locally, connect over Windows networking, and possibly even connect directly to an SQL Server database. These permissions must be disabled for that user. Apache, on the other hand, by default stores its own user names, passwords, and permissions. A user created for Apache will only be able to connect via Apache. Keep in mind that it's also possible to make Windows create new users without many permissions, and it's also possible to configure Apache to handle all users from a central repository of users.

Another major difference in file permissions comes in how a logged-in user can access a file. When a user logs on to IIS, IIS uses the user's access rights to access any file. So if Joe user needs access to upload a directory, then Joe must be given write permissions to that directory. You'll also need to allow write access for the directory in the IIS console - before any user can upload.

Apache, on the other hand, will always run as the user it is configured as (normally nobody, though sometimes /www/ or /apache/). To give Joe access to upload to that same directory, you must set write permission for nobody on that directory. Doing so, however, gives other users complete write access to the Apache directory.

Avoiding this situation is a bit complicated. Let's see first what the configuration should be and then subdivide the configuration into components. The example below can be used in any virtual host, directory, or file directive:

AuthType Basic
AuthName "Password Area"
AuthUserFile /etc/httpd/basic.passwd
AuthGroupFile /etc/httpd/basic.group
AuthAuthoritative On
<Limit GET POST PROPFIND OPTIONS CONNECT>
Require valid-user
</Limit>
<Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require user joe
Require group uploaders
</Limit>

• The AuthType and AuthName directives turn on basic authentication. Note that Apache supports other authentication schemes as well (including NTLM using an add-on module).
• The Require directive tells Apache which users or groups are needed to access this page. Require commands are or'ed together, meaning that lines

will require either the user joe or any other user in the group uploaders. The word /valid-user/ is a keyword that means any user as all.

• The Limit command is the tricky part but lets us have different requires for different types of access. Given the example above, we have two different groups: one for downloading and one for uploading.

If you again look at the configuration, you can see an interesting tidbit. To set permissions in IIS, you set the general-level access through IIS itself, and user-level access on the files/directories in question. In Apache, you set the general-level access on the file or directory, and the user-level access through Apache's configuration file.

Step #6: Configure Virtual Hosts, Virtual Directories, and Other Settings
Let's look into setting up a virtual host with a handful of virtual directories to get a feel for editing configuration files manually. To save changes to the Apache configuration file, you'll need to edit that file as root. (For security reasons, I don't recommend logging into your server as root unless you need to make changes, and even then judicious use of sudo is more appropriate.)

To manually edit httpd.conf, launch a Linux editor as root and open /etc/apache2/httpd.conf. For example in KDE you would launch Konsole and type: sudo kwrite /etc/apache2/httpd.conf. Note that some distributions have a modified version of this file that divides the file into multiple sub-files. This promotes ease in upgrading from one version of a particular Linux distribution to another. For example, if you follow the commands above, SLES 9's highly modified httpd.conf file will be displayed. The main SLES 9 configuration file includes detailed comments explaining where each setting is.

On SLES 9 you'll see that to add a new virtual host, you simply need to add a configuration file for it in the vhosts.d directory. To do this, make a copy of the example template with a command like:

sudo cp /etc/apache2/vhosts.d/vhost.template
/etc/apache2/vhosts.d/migratedvhost.conf

Once you've made a copy, open it with your favorite editor (as root). Near the top you'll see <VirtualHost *:80>, which means that this host will listen for any incoming connection on port 80. A few lines down is the most important directive ServerName. It tells Apache which VirtualHost to use when a connection is made. Change this to the first of the virtual hosts you want to migrate (so it says something like ServerName www.mysite.com). Locate the DocumentRoot directive. It indicates which directory to serve this virtual host from. Change this to wherever you copied the files (somewhere in //srv/www/vhosts//, for example, /DocumentRoot /srv/www/vhosts/www.mysite.com/.

For practice, you can add an additional directive DirectoryIndex - one that isn't already in the template. Each directive can only be put in a limited number of locations in the configuration file. In this case, DirectoryIndex can be located inside VirtualHost or in any directory entry.

To change which document gets loaded by Apache when this virtual host is loaded, simply add a new line under the DocumentRoot directive saying: DirectoryIndex default.htm or whatever the default document was on your IIS machine.

If you used multiple default documents in different directories, you can add them in succession, such as: DirectoryIndex defaut.htm default.asp index.php. Replace the rest of the instances of dummy-host.example.com throughout the template with the real paths of your migrated host.

Finally, you should test the configuration by directing the Linux machine to load from the new server instead of the IIS machine. You can do this by editing the hosts file (sudo /etc/hosts) and adding a line at the end of the hosts file that says 127.0.0.1 www.mysite.com. Once this is done, any time you visit www.myserver.com, you'll connect to your local machine instead. Before connecting, you'll also need to restart Apache by running sudo /usr/sbin/apache2ctl restart (this command may differ slightly depending on your Linux distribution).

As with older versions of IIS, Apache has to be restarted for any changes to take effect because the configuration file must be parsed, a task too time consuming to done for each request; IIS changes settings directly in memory.

Launch a Web browser and visit www.mysite.com (or whatever your migrated virtual host is). You should now see your default document (though perhaps not parsed correctly if it's ASP, PHP, or the like) from your virtual host. This completes a very basic Apache setup.

There's still a lot left to configure via Apache's configuration files. Depending on your needs, you may want to set up virtual directories or files, set timeouts, tweak connection settings, or change the error pages people get when an error is encountered. You'll probably want to set up PHP, mod_perl, JSP, or Sun Java System Active Server Pages 4.0. For information on configuring every setting that ships with Apache, go to the Apache Documentation Project at http://httpd.apache.org/docs-project/. Information about how to set up different languages or runtime environments should be available at the place you got those systems.

Tools to Ease IIS to Apache Migration
Fortunately, there are tools available to ease IIS to Apache migration. I've already mentioned products that let you host ASP on Apache platforms: Sun Java Active Server Pages and asp2php. More to the issue at hand, there are two commercial software products that automate the migration from Microsoft IIS to Apache on Linux: Versora's Progression Web (www.versora.com/products - note the shameless plug) and Das Technology's LSP (www.das.com.tw). Such automated software solutions cut the man-hours needed by your organization for a Web server migration.

In summary, migrating from Microsoft IIS to Apache on Linux isn't without its concerns. As with many changes, educating yourself, planning the migration, and choosing the right tools are key to a successful migration. Ultimately, the benefits of a move are the strongest motivators: reduced cost, stability, and security.