DryDock "It's just a good idea" Guide
Deepak GiridharagopalPrincipal Developer
Updated: 2003/10/23 00:45:02
Version: 1.1
Abstract
This guide shows you the recommended way to set up DryDock.
1. Introduction
This is going to be short and sweet. You should run DryDock with 2 seperate web servers, where one lives inside a firewall (the staging server) and the other lives inside a DMZ (the production server). You should customize your SyncKit so that DryDock copies the content over an encrypted channel (say, SSH) to the server in the DMZ.
Web authors interact with the internal machine to edit their content. Nobody should be interacting with the external machine. It should be a drone that does nothing but recieve approved documents over SSH diruing a sync, and then update its web root with the new set of files.
Both instances of Apache (or the web server of your choice) should be configured as identically as possible. This will ensure that when a file is copied from the internal machine to the outside one, they will still work.
And that's how it should be done. For more details on how users interact with the two server setup, refer to the DryDock overview guide's section on usage. Chances are, if your actually considering DryDock for use than you are in an organization that already has a firewall and can also afford a duplicate web server box. It's just A Good Idea, but if you need convincing...
2. Why it's a good idea
The DMZ server is easy to harden
DryDock's dual web server setup makes the production server easy to harden. Users never interact directly with the production machine; DryDock interacts with it on their behalf. This allows administrators to operate the production server in a more secure and regimented network environment than normally feasible.
Because normal users never access the web server, system administrators can restrict its logins to a single administrative account. If you configure DryDock to update the server's content over SSH, traditional file access services such as Samba, NFS, or FTP can also be disabled.
If the web site is comprised of mostly static pages and simple scripts, backups are much less complicated. Since DryDock rebuilds the entire web tree during each synchronization, if you always sync the full tree to the production server then there's no need to maintain backups of the production web server beyond a base image of the machine's initial configuration. You should treat your production web server as a drone -- all web content is housed safely inside the firewall on the staging server, and it's pushed out to the external machine when necessary.
3. So do it!
Though you can customize your SyncKit to do almost anything, a firewalled, 2 server setup is really a good idea. It's what DryDock was conceived to work with. It makes it easy for many web authors to safely publish content to a web server that remains almost completely isolated from your internal network. And come on, isn't that a good enough reason?
