Daniel Pezely (Tieline 698-9926)
Written upon the request of Internet Services Integration.
Please consider this design and send comments to the author.
For a high performance, low cost, Web content hosting service, consider the following design.
The computer industry's products and the hosting marketplace's activities dictate certain factors. These factors drive site designers to common conclusions. Those conclusions force specific designs and the general consensus within our industry by the actual systems administrators themselves are summarized here.
This design is for low- to medium- range customers who do not need dedicated servers, databases, or additional Web services.
Dedicated hosting customers may, however, have similar configurations.
Additional services not detailed here include streaming audio, chat rooms,
and interactive multiplayer games. Such items should be considered as
straight-forward extensions to this design.
We assume the following criteria, based upon the bottom line of the company's finances and its employees' not having to work overtime.
The server farm for content hosting can have these features.
With the above criteria and factoring in the above issues and considerations, this design represents one implementation of the general consensus within our industry.
Possibly, admin/support staff workstations could access the isolated network from within the company's internal LAN by way of firewalls.
By grouping a specific number of front-end servers with specific back-end servers, scalability then becomes a matter of replicating this ``cluster'' for each set of few hundred or few thousand customers.
This has the additional benefit of isolating network traffic to potentially different network segments through the use of switches or routers.
This includes everything except customer specific items such as virtual interface IP numbers and which file systems are mounted.
This will enable any back-up server to replace any active server immediately.
Additionally, tape back-up are only required for historic archives or for physical site redundancy.
This minimizes losses of data in the most severe crashes and enables any back-up server to replace any active server immediately.
Cryptographic checksums (e.g., MD5) will be generated on all system files as a ``trip-wire'' mechanism.
This also assists in narrowing the time frame in which any cracking activity may have occured.
By using shorter time periods between mirroring/updates, the amount of data transferred will be otherwise reduced in both duration and immediate network capacity.
By using smaller segments of the file system to be integrity checked, each invocation will be otherwise reduced in both duration and computational load.
Likewise, especially for any international customers, there is no single high-impact activity during anyone's prime-time hours.
Front-end servers have separate network connections for the Internet versus the server farm LAN (connected only with front/back-end servers).
Back-end servers have separate network connections for the server farm LAN (connected only with front/back-end servers) versus the company internal LAN connection via one-way firewall.
The Adaptec 2940-Ultra SCSI disk controller with Ultra SCSI disks are highly recommended for all servers.
This is a very stable, robust implementation of Unix which is freely usable, accessible, and distributable (but is not public domain).
In many qualified people's technical/professional opinions, FreeBSD's quality matches many commercial flavors of Unix including SunOS/Solaris, HP/ux, and AIX.
The FreeBSD development SNAPSHOT now includes Symmetric Multi-Processing (SMP) support for machines with multiple Pentium (P5) or Pentium Pro (P6) CPUs. This feature should be available in the ``current'' and ``stable'' releases within six months.
This is a very stable, robust HTTP server which is freely usable, accessible, and distributable bu is not public domain.
In many qualified people's technical/professional opinions, Apache's quality surpasses many commercial servers including those from Netscape.
This software supports SSL for secure commerse.
(There are rumors mentioning the inclusion of a ``configuration server'' in the near-future. This would be much like Netscape's ``administration server.'')
This will limit the maximum load of each customer's HTTP server daemon, minimizing overall impact on the shared host.
This way, regardless of any lack of filtering by the routers or firewalls, you are protected.
See ``Secure customer access'' below.
The exact numbers will have to be determined at the preliminary implementation phase.
This will defeat ``daemon dialing'' or ``war dialing'' attempts to locate such support servers.
Additional services beyond the basic HTTP traffic of the Web are optional for a basic service offering. If customer demand is high enough, these additional, related services may supported while still fitting within the above criteria.
The security procedures are supported by the TIS fwtk program, smapd.
This way, despite being a separate server than what runs the HTTP software, the FTP site may include access to the HTTP DocumentRoot without any replication and still be secure.
This prevents any possiblity of operating system file corruption.
Custom CDs should be used. A CD-ROM writer unit (approximately $600.00) is required on at least one firewalled, administrative workstation.
Files containing passwords, hostname, and IP number assignments may be stored on a write-protected floppy disk so as to permit updates without cutting a new CD.
Considering such minimal operating system configurations, there should be no performance impact after boot-up due to the slow nature of a CD-ROM device.
Front-end mail servers would use local disks only for temporary spooling of in-bound mail. Back-end mail servers would treat front-end mail servers as NFS servers. Back-end mail servers perform all normal mail processing.
Front-end FTP servers would use local disks only for temporary spooling of uploaded (``contributed'') files. Back-end file servers would treat front-end FTP servers as NFS servers. Back-end file servers periodically (e.g., hourly) migrate uploaded/contributed files into customers' file systems.
For security purposes and integrity of the servers, restrict what the customers may do on the server and how they may do it.
This GUI should include mechanisms for compression, archiving (e.g., tar or zip), and extracting, as well as file renaming, changing access permissions, deleting files, and adding/removing directories.
Currently, no such application exists in the public domain. If development and maintenance of a custom program is not possible, remote login is then required. See ``Secure Customer Access'' below.
Such a restricted shell should be limited to their own directory tree (i.e., chroot'd).
Depending upon how secure you want the site, the following would be the maximum for a service offering.
This configuration is highly recommended.
Customers would not be severely impacted, and those who understand that Internet servers have inherit security risks will be receptive to this configuration.
This is already common practice at some hosting firms.
(There are versions available for international customers so no export control issues are of concern.)
This program permits on-the-fly compression, supports recursive copying of entire directory trees, and is much more efficient than FTP.
There is little reason to permit a customer to login to a shared hosting server, when sufficient alternatives are provided.
The customer's shell should be limited to their own directory tree (i.e., chroot'd).