DNS^TM isn't just a provider of UNIX technical services.

Our two decades of industrial strength experience have given us considerable insight into the needs of our customers. Certain patterns have emerged.

The first observation we made is that configurations tend to fall into one, and only one, of three categories:

• standalone
• server
• desktop

The second observation that we made is that systems tend to deploy in one of three security levels:

• low
• medium
• high

We found it convenient to categorize systems that we dealt with by placing them in the following table:

This became the central paradigm of our development effort; a set of nine basic UNIX configurations that can be used as platforms for almost any application, or combination thereof.

Needless to say, the biggest enemy of the systems administrator is inconsistency amongst the servers he or she is responsible for.

We set out to create products that would address this need - consistent, robust configurations.

Best practices involve deploying systems that are as identical as possible. If the systems cannot be identical, then at least some effort is made to deploy servers in a modular fashion, so that the unique elements of each installation are well defined.

This sort of strategy pays off in the long run by minimalizing the unique aspects of each installation. This translates directly into less data to back up, faster recovery from disasters and worst-case scenarios, and easier upgrades, as a result of a well-defined and well-documented line of demarcation between the operating system, applications, and data.

Unfortunately, installing an operating system exactly to spec is a tedious business. Where automation is not possible, a senior administrator documents what they did, from disk partitioning to system and application configuration, and these operations are manually carried out, as scripted, by junior administrators.

Even if standard files are distributed, a certain amount of human error enters into the process, and it's not always cost-effective to start over. The result still falls short of the ideal, and remains more expensive to maintain than need be.

Larger environments may find it cost-effective to create a customized CDROM, in an attempt to automate the task. But this, in itself, requires additional overhead, which is not always cost-effective. The CDROM is a development project in itself, requiring testing and revising - which involve resources that an already time- and money-strapped IT department just can't afford.

As if this were not enough, there are still some questions about the quality of the final product. For example, Adrian Cockcroft wrote a book on performance tuning for SunOS, back in the 1990s, where he suggested that administrators should turn their hard drives into a single, giant root partition. Linux administrator's manuals have been known to make the same suggestion, and some releases of Linux, as well as other UNIX operating systems, have even been known to offer this as a default.

While the conventional wisdom is that one cannot go wrong by accepting defaults, in this case one is setting oneself up for disaster. If system or application logs or data sets grow so large that they are in competition with the OS for filesystem space, you will have one unreliable server.

(Put another way, this makes about as much sense as an IT department just having one budget for everything - phones, systems, networking, security, staffing, backups - and not making the effort, beforehand, to determine what the needs of each group were, separately.)

As if this were not enough of a problem, there is the additional problem of backing up - and restoring - a single, device-sized filesystem. Much better to break the device into smaller pieces, which can be backed up, or not, selectively or at different frequencies. Much better also because these partitions can be backed up, and, more importantly, restored from backup, in parallel - which translates into less downtime for the organization.

(This is also a factor to be taken into account when partitioning very large RAID arrays.)

As you can see, here at DNS^TM, we have our own ideas about how to configure an operating system - ideas based upon twenty years of dealing with every possible aspect of operating system administration - aspects that many people have never even given a thought to, but which can bring your entire operation to a halt, if ignored.

Our goal is to deliver a single CDROM that can turn any PC into an industrial strength server, by simply inserting the CDROM, booting, answering no more than twenty questions (most with preset defaults that can't go wrong), and waiting no more than thirty minutes for the server to complete the installation.

We're well on our way to having a CDROM for each of the nine basic configurations described above, as well as a range of innovative servers layered on top of these different configurations. Some of the products we've created for customers include turn-key OpenLDAP servers, Apache servers, NFS servers and firewalls - using Red Hat, Immunix, and other releases of Linux, as well as our inhouse favorite, FreeBSD.

Naturally, at DNS^TM, we use our own products, throughout the business. Before we sell it to anyone, we use it ourselves, in our own development and production environments. If it doesn't work for us, we don't sell it to you. Period. We're engineers - not perception managers.

Whether it's Apache web servers, Samba workgroup servers, DNS servers, Internet firewalls, RDBMS servers, or X Windows laptops running open source network analysis software ... all of our systems run the same basic, robust, flexible, industrial-strength configuration - based on FreeBSD 4.8, with improvements. (FreeBSD 4.10, coming soon.)

We're very excited about the products we're developing, and we're interested in finding partners to help us develop some of these products, using our proprietary modular technologies to build consistently excellent system configurations from reusable description files.

We figure we can deploy servers that would conventionally take 60 hours to build, manually, in less than 60 minutes - a productivity increase of over 5000 percent - and we're working to put these products in the hands of our customers, so that they can do the same, without our needing to come onsite.

We're definitely interested in hearing from you if you are an Open Source venture capitalist - of the angelic variety, of course. We figure that with a budget of less than $100,000, we could, in one year, deliver products that would generate at least a fivefold return - most of which would be promptly reinvested in R&D.

(This server is currently running DAEMONIZED-BETA-0.8.2.5-DEMO.)