Replacing Microsoft IIS Webserver and SQL Database in a Web Publishing Environment

Arnie Miles

At a previous job, I worked with a Web site administrator who'd been newly hired to develop and enhance the content of our college Web site (at Hood College in Frederick, MD), transforming it into an inexpensive yet powerful marketing tool. The new site administrator, who would be choosing new servers, operating systems, databases, and Web server software, came from a production shop with a strong Microsoft background, using Cold Fusion with MS SQL Server back ends on Windows NT servers.

The new site administrator was used to her customers connecting directly to network shares to install and test new content live on the Cold Fusion server without the need for FTP or the command line, and she wanted to replicate that environment. Our IT staff, however, had concerns with the Microsoft products the administrator proposed and she agreed to consider alternatives, provided they met her needs. With a little systems analysis, research, and some well-timed demonstrations, we met her requirements and increased security, while keeping the cost lower than an alternative solution. Our solution involved Linux, Samba, MySQL, and Cold Fusion.

Other forces pressed for a Microsoft solution, as well. The departments on campus were then responsible for creating their own Web content under the standards and guidelines set by the new Web site administrator. Although these users were willing to learn a GUI tool for Web site creation, they were generally resistant to FTP. The new Cold Fusion environment would require live, on-server testing of all changes made to Web pages. On the other hand, the users were familiar with logging into a Microsoft domain and using network shares. These users wanted a solution that looked like the Microsoft products they were used to. The only element of the setup that was not negotiable was the use of Cold Fusion with some sort of relational database back end. Other technologies for dynamic Web page creation could exist on the server, provided Cold Fusion was installed.

The Platform-Hardware and Applications

To start, I confirmed that a version of Cold Fusion was available for Linux. I wanted to keep my venerable but reliable old Alphas, but found that Cold Fusion for Linux does not run on Alpha hardware. Thus, an Intel box became necessary. When I was sure I had a viable platform to support Cold Fusion, I set up an Intel computer running Red Hat 7.2 and Samba 2.2.3a.

Cold Fusion is a powerful platform for rapid development of Web sites. We had concerns about committing to a proprietary environment, but the existence of Cold Fusion on the server does not impact the use of any other non-proprietary technologies. Even with Cold Fusion installed, your PHP and Perl scripts will run just fine. I just installed Cold Fusion and turned it over to the Web site administrator to handle. She connected to it via her Web browser and configured it in minutes. The default installation provided everything she needed.

Although Apache is generally the standard among Linux users, Hood College was using Sun's iPlanet Web server on a Tru64 UNIX platform, and decided to stay with iPlanet. Either Web server solution would meet our needs. When you set up a Web server, you obviously want your clients to feel free to play, which means you'll need an area that is not available to the general public -- like an intranet. I won't go into the details of iPlanet configuration or Apache's httpd.conf in this article, except to say that you must set up the Web Server with either a special directory to act as an intranet, or you must turn on home directories for serving Web pages and limit them to the intranet. The decision you make here will affect the settings you use when you create your "add user script" command in smb.conf, which I will cover later in the article.

Samba and the Domain Controller

At the college, there was already a surprisingly stable Windows NT domain in place, on which all users automatically had accounts. Thus, it was logical to create a Samba member server and introduce it to the existing domain. Adding your Samba server to an existing NT Domain removes all additional administrative work.

Samba 2.2.3a comes bundled with Red Hat 7.2. Hood College had used Windows NT for several years before their migration to Win2K, and the Windows systems administrators had the account administration under control. Faculty and staff accounts were handled manually at the Windows Primary Domain Controller as employees are hired or leave. Since all of the available customers already had Windows domain accounts, it seemed pointless to me to duplicate their efforts, so I chose to make my Samba server a member of the existing faculty/staff domain. Setting up the server was a matter of writing a proper smb.conf file, adding the server to the domain as a member, and then introducing the server to the domain.

Samba Configuration

There are two sections to the smb.conf file. The first section is Global Settings and contains the directives for the server itself. The second section is called Share Definitions. This defines the different shares to which the server allows connections. Syntax for smb.conf uses both # and ; as comments -- the # comments are descriptions, and the ; comments are example lines that are available to uncomment and edit for use.

To act as a member server of an existing Windows domain, the following lines must exist in the Global Settings section of smb.conf:

workgroup = <Windows Domain Name>
server string = <Name of this server>
security = domain
password server = <comma-delimited list of domain controllers, or *>
encrypt passwords = yes
domain controller = <fully qualified Domain name of PDC>
wins server = <ip address of existing WINS server>

All these lines are required to get connected as a member server of a Windows domain. This configuration passes all authentication responsibilities off to the Windows PDC or BDC. However, all users are still required to have a local machine account to access files, which is accomplished by adding this line to the smb.conf Global Settings section:

add user script = <script to run when user is added to system>

This line allows Samba to run any predetermined script whenever it sees a user connect who is authenticated by the Windows domain, but does not have a local machine account. It accepts the variable %u to represent the username passed to it.

The simplest entry would be:

add user script = useradd -c "Account from PDC" -s /bin/false \
  -d /<home_directory_root>/%u -m -n -g webwriters %u

Note that a Samba user authentication through the domain doesn't require local login privileges, so it is not necessary to assign a password. You do need to set up username and group assignments here. In this example, the -c switch provides an entry for a comment in passwd, and the -s switch is used to turn off local login by setting the shell to /bin/false. The -d sets the default home directory. We want to set up an area for our clients to access the Web server, so this could be the root of your intranet. Alternatively, this could be a standard home directory if you want your clients to work from there. The -m creates a home directory, and the -n turns off Red Hat's default behavior of creating a group with the same name as the user. The -g switch puts all the users who connect via Samba into the same group, in this case webwriters.

To extend the functionality provided by useradd, you can add a fancy shell or Perl script to your system that adds the user, sets up various features, and then sends the user (or you) an email. The companion to add user script is delete user script = <command>, which will execute <command> whenever someone without an account on the Windows domain tries to connect to a share. Be very careful with this entry if you decide to use it.

That's it for the required entries for the Global Settings section. Now we need to define the shares. We want to provide an area in which clients can work and test Web pages within the environment that the pages will ultimately appear on the Web server. In this example, the Web site administrator is ultimately responsible for what appears on the main Web site. The departments are creating pages, and presumably they will want to test the pages for functionality, show them to their peers and supervisors, and show them to the Web site administrator before they are posted on the official Web site. Of course, some trusted users can be set up to work live on the Web Site. Certain power users, as well as the Web site administrator, may want this level of access.

The default settings for [homes] should successfully get you access to your home directory. If you have configured Apache to allow Web pages to be served from home directories to the intranet, you're done setting up your users. If you've set up a separate intranet area in which they can work, you can set up a matching [intranet] share as follows:

[intranet]
 comment = Intranet Playground
 path = /path/to/intranet/root/
 valid users = @webwriters arnie
 force create mask = 755
 force directory mask = 755

This stanza of smb.conf will make available a share called "intranet" to all members of the group "webwriters" and the user "arnie". The "@" sign denotes group names, and a name with no "@" denotes a username. By default, it is not a public share, so it requires a password to connect to it.

The force create and force directory masks will force your users' files to have permissions set to 755. In this example, everyone is playing in a common sandbox. All members of the "webwriters" group have equal read access to all the files, but only the creator of the files can edit them. This is good in an environment where users aren't particularly savvy to permissions, and no files will be created without the correct permissions for Web serving set. This allows the users to work safely, and provides the Web site administrator with sufficient rights to move the files into the main Web server.

To set up rights for the Web site administrator and certain other users to access the live Internet site, add a stanza to smb.conf that looks like this:

[http]
 comment = Live Web Site
 path = /var/www/
 valid users = arnie bruce christine
 force create mask = 755
 force directory mask = 755

This example is pretty basic. Users arnie, bruce, and christine all have access to the entire contents of the Web site, and no one else does. The forced masks are optional.

Testing and Starting Samba

You should now have a functional smb.conf file. Running the command testparm will test the basic configuration of your smb.conf. It will point out spelling errors and other simple mistakes. If your smb.conf file is okay, you will see a listing of the parameters you have set and the shares you have defined.

In Red Hat 7.2, the smb startup script is in /etc/rc.d/init.d. It accepts the arguments Start, Stop, Restart, and Status. Therefore, running /etc/rc.d/init.d/smb Start should get everything going. When this step is complete, you can connect to your Samba server from a local client. To do so, run:

smbclient /yourserver.domain.name/sharename -U username

where yourserver.domain.name is the fully qualified domain name of your server as it appears in the local DNS tables, and the sharename is a share that you have defined in smb.conf. Try this with your username; if it fails, be sure you are using a good machine name, or try localhost instead of the machine name.

Introducing the New Member Server to the Domain

Samba services must be shut down before introducing the server as a member of the domain. This is a two-step process. First, the server must be given a machine account on the Domain by the Windows administrator using Server Manager. Second, with Samba turned off, you must run:

smbpasswd -j DOMAINNAME

This should result in a line that says Joined domain DOMAINNAME. You can now restart Samba and begin serving up pages. This is also a good time to add Samba to your startup scripts.

From any Windows computer, you can now click on "Start|Run" and type in \\<servername.domain.name>\<share> to connect to your new Samba Server, just like you would with a standard Windows fileserver. If your Web developers are using Macs, you can still connect to your Samba shares. In OS X, click on "Go|Connect to Server" and put in smb://<server.domain.name>/<share> in the Address block. You'll be greeted with a share mapping on your desktop.

The Database

The final step in eliminating Windows servers from your solution is to replace the MS SQL server with MySQL. Cold Fusion developers are not alone in their use of a database to hold content for dynamic pages and general content management. I like to set up my MySQL server on a different server than the one hosting the Web pages, which gave me an excuse to break out one of the old Alphas. MySQL is bundled with Red Hat and comes with excellent documentation. Setting up the MySQL server itself is beyond the scope of this article, but there are several good tools for administering the database remotely from Windows.

Once the database was installed with its own root password, I created an account for the Web site administrator with full rights and gave her a copy of MySQL Front, which is available at http://www.anse.de/mysqlfront/. This program seamlessly connects to a remote (or local) MySQL server from Windows. The Web site administrator, an MS SQL server fan, immediately began using this tool. She used her Cold Fusion Administrative tools, made one built-in connection to the MySQL database on the remote server, and was in business. Of course, this database is now available for all "webwriters" to use, so they can produce PHP or Perl scripts to serve up whatever data they have to share.

Conclusion

With this setup, Hood College avoided the extra licensing costs, security risks, and administrative headaches of setting up extra MS IIS and SQL servers, while still providing the full set of expected features to a Web site administrator and her clients, who were used to Microsoft solutions. The only piece of this solution that is still Microsoft-driven is the existing Primary Domain controller, onto which we piggy-backed for authentication.

Resources

Samba: http://www.samba.org

MySQL Front: http://www.anse.de/mysqlfront/

MySQL: http://www.mysql.com

Red Hat Linux: http://www.redhat.com

Cold Fusion: http://www.macromedia.com/

The Samba Project Documentation: http://us1.samba.org/samba/docs/Samba-HOWTO-Collection.html

Samba Pocket Reference, Robert Eckstein, David Collier-Brown and Peter Kelly, O'Reilly & Associates, Inc. April 2001

Special thanks to the current UNIX/Linux Administrator at Hood College, Bruce Embrey, who assisted in the testing of some modifications to my original installation for this article; Hood College's Web Site Administrator Christine Brown, for helping define this installation; Steve Moore at Georgetown University for editorial assistance; and to Jeff Whipp and Brian Petrewicz at Hood College for providing a Windows Domain stable enough for me to do this testing with, and for trusting me with their domain while I worked.

Arnie Miles is currently a systems administrator for the Advanced Research Computing Center of Georgetown University, where he provides various IT support for special research projects in the Chemistry and Biology fields, including Beowulf cluster administration, open source database design and administration, data-driven Web site design, Samba server administration, training, and whatever else he can get his hands on. He was formerly the End User Computing Manager and Linux/UNIX Systems Administrator for Hood College. He holds a Masters of Computer Science with a Concentration in Information Technology from Hood College and a Bachelor's of Business Administration from Columbia College.