Microsoft IIS Webserver and SQL Database in a Web Publishing Environment
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
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.
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
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:
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:
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 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
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.
MySQL Front: http://www.anse.de/mysqlfront/
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.