This chapter covers the planning and implementation steps necessary to set up a server. Taking the time to develop a thorough setup plan before getting started will help ensure your success. Recording a detailed log throughout both the planning and implementation processes will help keep the setup process in order and serve as a road map for work on the setup. So, begin by starting your log, then plan the implementation, then do the actual work.
The planning and record keeping may seem, at first, too exhaustive. However, nowhere more than in the initial stages of setting up is it possible to find and correct problems quickly and, most importantly, cheaply. Pinpointing these problems is possible only if you plan first and act later. If you fail to do so and server problems do creep up later, you'll be forced to backtrack your way into solutions-an inefficient way to work and usually a costly price to pay.
In deciding what you should keep in your log, you must define a log umbrella, as shown in Figure 9.1. This means you must determine two types of boundaries: which computers are logged and which procedures are logged. To make this judgment, begin by establishing which computers are most important. Many of the other decisions about which procedures to log will be determined by what operating systems are running on the important computers. You should keep records for any machines that are important or large enough to have a premium placed on their reliability. This includes computers that perform any file, print, Web, security, or application service. It also should include any backup devices or large electronic storage devices such as RAIDs, which provide a redundant array of hard disks that are simultaneously updated on a system.
You should keep records on any software that requires user modification. This is often the case with UNIX, but certainly not exclusively. Software on all platforms often requires attention to certain details. These details must be logged, as is discussed in the section "Installed Software."
All system administrators should keep a log of problems and their solutions. When a systems administrator notices a problem with any computer or software that is under the umbrella, he or she should log it immediately so it can be tracked. This means that all system problems fall under the umbrella.
Keep logs of the initial parameters of any software or computer under the umbrella. Having software version numbers, Ethernet address, and initial configuration files at your fingertips will save you hours.
One of the most important components of the log is a list of emergency startup procedures. When an important component of your system will not restart, nothing is more essential than regaining control. Having any necessary procedures written down will shorten this process considerably and make it less frenetic. This should include not only steps to take but also the locations of any useful startup disks.
For both Windows 95 and Windows NT computers, the emergency repair disk is absolutely essential.
Log any modifications to system startup files for all computers under the umbrella. This applies to any operating system.
For Intel-based computers running Windows, copies of the configuration files (config.sys, autoexec.bat, win.ini, system.ini, and protocol.ini) should be on disk, with the disk's location in the log. Do the same for Windows 95 computers, and keep a copy of the registry.
For Macintosh computers, keep a list of the extensions and control panels that load together to make a working system, and note any unusual preferences, as shown in Figure 9.2.
For UNIX-based computers, document any modifications to the startup files, and keep copies of all the original configuration files. Also, write down the locations of any relevant log files; make sure they are easily accessible.
Also keep logs of important attributes of any installed software; this is true of important software even if it is not currently running on a machine within the umbrella. This information should include the location of the installed software (the full pathname) as well as the location of and any modifications to configuration files for the software.
Other important software information includes the location of the original source. Whether this is a set of disks, a CD-ROM, or a compressed archive file, this original and untouched source is extremely valuable.
After the software has been installed, make sure log entries are made each time the software is modified. Document any alterations to Windows-style .INI files, Mac preference alterations, or adjustments to UNIX make or configuration files.
All this log keeping is not just an organizational drill. Keeping a log is a key component of system administration, not to mention an important part of sound engineering principles.
Logs provide an important record when it becomes necessary to troubleshoot. These logs provide a chronological record of changes that will help determine when a problem started. Logs also can provide a list of suspects for problems. A log entry provides the troubleshooter with valuable leads when he or she is trying to determine why the system is malfunctioning.
Logs, especially logs of the troubleshooting process, can serve as a knowledge base far superior to any other manual or guide. Logs provide lists of problem symptoms and solutions that can be reviewed for similarities. Logs also provide an initial knowledge base for training new systems administrators. This knowledge base is specific to your system, so it provides a much more relevant body of information.
When determining what goes into the log, it is equally important to determine who will keep the log. Those responsible must agree on what will be kept and why. Simply telling those working on the server that they must keep a log will be insufficient. Keeping a log is often an unpleasant, time-consuming task. It often involves deliberately slowing down progress on a problem just for the sake of "paperwork." Being able to keep a log during a real crisis is a very difficult skill, but it is essential for preventing the crisis from recurring.
All system administrators must be scrupulous record keepers. The system administrators are most responsible for the overall health of the system, and they will be the ones who have the task of restoring it to health when its gets sick. Thus, system administrators are responsible to both themselves and the organization to keep good records.
Any users who have system-level access to a computer or software under the umbrella must know what actions are to be logged. Anyone who has system-level access may make adjustments that can affect the system as a whole. These adjustments are all relevant to the logs. Again, it is important that anyone in a position to perform functions that should be logged agrees to update the logs as appropriate. A tradeoff to receiving root access is an understanding that logs must be kept.
The method used to keep the log is in some ways as important as the log itself. Electronic solutions give the advantage of retrievability, but they lose out on convenience. If the staff is particularly meticulous about the records, an all-electronic solution may work, as shown in Figure 9.3. Otherwise, solutions may be more low-tech, such as a notebook next to an important computer.
Figure 9.3: How an online log book should look.
After making arrangements for keeping a log, you must plan the implementation of your server. Now it's time to plan the server's place in your operation, as well as the steps to get the server up and running.
Begin the planning process with a top-down perspective on the business. The plan should be driven by concerns for the business, not concerns for the technology. To develop the plan, you should have previously determined what products and services the system will offer. Do not alter your plans on the basis of what the technology offers; rather, decide what you want to accomplish and then find the appropriate tools to do it. Set priorities and then focus on what products fit those ideas.
When drawing up the plan, spend most of your time determining what hardware and software best fit your needs. As you plan the server setup, you will discover that technology will only solve so many, if any, problems.
Remember, choosing hardware determines what operating system you can use. And, when the operating system is chosen, you will have set some limits on software options. The choice of software, of course, limits the functions your server can perform, so concentrate on doing things in the right order. When making these choices, proceed in the order from most general (operating system) to most specific (software packages). Although you must make choices in a specific order, making all your choices at the same time can translate into an optimum package. Remember not to focus on just one aspect of the system; instead, view the system as a whole.
An important aspect of planning is planning for maintenance. Support and maintenance often are the most costly aspects of a server, so don't forget to factor these costs into the overall plan.
The most important aspect of the plan is determining how much reliability is necessary. You must decide between cost and reliability, probably the most direct tradeoff you will face when planning. Money will buy you more redundancy, better equipment, and more comprehensive coverage. It will not buy you reliability, however, unless your planning and execution are solid.
You must determine how important avoiding downtime is. When your applications are not time sensitive, the cost of downtime is not so severe. So don't make the mistake of overestimating the cost of downtime. High reliability is costly and creates numerous support headaches. If you don't have to go through it, don't. It's also important to remember that the last 10 percent of reliability costs the most.
Another important aspect of planning reliability is to understand what role other factors play in your downtime. Your Internet provider can easily be the source of most of your downtime. No matter how good your system is, it is as good as down if it cannot reach the Internet.
Also consider technical support. Sometimes a problem will be beyond the scope of your in-house technical staff. There are many companies that provide hardware and software support for companies of all sizes. Having your hardware supported means getting a replacement disk or CPU in a matter of hours. Having your software supported means getting immediate answers to critical questions and reducing the time it takes to identify and solve problems.
You also must determine the dollar value of your data. Data is prone to loss, damage, and theft, so plan ahead for these risks. When your data consists mostly of casual e-mail, data loss is not so critical.
Evaluate the necessary security level of your data. That is, how much of the value of the data is lost if an unauthorized user sees it? Everyone uses passwords and file permission structures to secure their data, but do you need more than that? How physically secure is your network? This determination is critical in deciding how secure your transmission must be.
Transmission security means how secure your data is when it moves from place to place. Transmission security is often a weak link that people ignore. When determining the costs and benefits of security measures, never forget to consider the cost of restricted access. Remember that the computer exists so users can access data. If the access to the data is too restricted, you have decreased the value of your whole system. Evaluating and handling security threats are discussed in more detail in Chapters 14 through 16.
A further important consideration when planning the server is how that server will be upgraded. All aspects of a computer system quickly become obsolete. Never trust that the computer you buy today will be exactly the same a year from now. It's likely you will buy a completely different piece of hardware three years from now. To maximize the value of your investment, you want a computer that can adapt to change. To find this beast, you must think carefully about your business.
Take time to consider seriously where and how the business will grow. Simple, less expensive systems often are not very scaleable, meaning they have little capability to grow. For instance, Microsoft Access is a fine database as long as you are dealing with a very simple table structure, a few forms and reports, and fewer than 15,000 records. To reach a larger scale, you need a tool with more power.
When planning a server, consider the following:
When you've finally gotten around to planning the actual work of installing and configuring the server, you must think on a pragmatic, straightforward level. The more carefully you plan here, the less likely it is that you'll have a Phillips head in your hand at midnight wondering how it happened. At the center of a good plan are the equipment manuals and software you will need. With these in hand, first decide what you need immediately. This should include the following:
Now you are ready to plan for the stage of implementation that will occur next month.
This list might include the following:
In six months you will probably be well into your first major upgrade. It's likely you will have attempted or experienced some of the following tasks:
Each of these events and transitions must be understood and planned for in terms of both service losses and cost.
In spite of everything else that has been said, don't overplan. Seeing a year into the future of your system requires a crystal ball. Within a year, expect to be looking for more capacity to deliver your services. Expect to have had a second six months full of more change than the first six months, and expect to be dissatisfied with your current server's capabilities.
When scheduling the initial sessions of setup and configuration, don't underestimate the time it will take. If you have had some experience with the system you will be setting up, you should be able to make some good estimates about the time it will take. If there are any aspects of the system you are unfamiliar with, expect to be surprised by how many new variables it adds.
Two rules should be uppermost in your mind when planning:
Technology that doesn't work decreases your credibility with everyone involved. When you set up a system, it's no good if it doesn't work, and making adjustments is ten times harder after users are on board. Before you roll it out, you can restart a server as many times as you want. After you roll out the server, these things all have to be scheduled well in advance.
Everyone involved in the plan must understand the importance of planning. Convincing everyone of the validity and importance of the plan is as important as the plan itself. A plan is of no value if no one follows it.
When ready to purchase software, take time to draw up a shopping list. Such a list is valuable in determining where the overlapping functions are. You can use your software plan to build redundancy into your system. A shopping list also will allow you to spot potential conflicts of versions or features.
Cost is always a driving force in business decisions, so you must plan to make accurate cost assessments. Without a plan of what you will buy when, cost assessment is not possible. Also, when planning the purchases, you can compare competing proposals directly.
Another important aspect of planning is that it allows you to factor in things often left out, such as maintenance costs. Maintenance is an important expense, and it must be added to the cost of each system component. This includes hardware and software. Planning out these extra expenses gives you a more accurate estimate of the cost of each piece. Also, planning for maintenance costs means that maintenance can be effective from the minute you start up the system.
A final benefit of planning is that users, customers, and technical staff can all form reasonable expectations about the system. If you write out what steps will take place when during implementation, the staff involved will know what's expected and prepare for it. Laying out the completion dates for various projects lets the users know when to expect what services. And working out the costs beforehand lets the managers of the project plan a budget. All these expectations will prevent anyone from demanding more than you can give before you can give it.
You must make decisions from the outset about who will be involved in the planning process. Too few people will produce a plan with too narrow a focus; too many people involved and the plan's too wide. Be sure that there are both technical and nontechnical people involved. Never let the system administrators do all the planning. Even though they have a firm grasp of all the technical issues, other perspectives should be heard as well. The system is set up not for the ease of the administrators, but for service to the customers. The system should always plan to adapt to the customers' needs. Ease of administration should always be the last concern and never the first.
Those who direct the company will have to provide the initial priorities. Again, let the business pick the technology. The systems administrators must plan out the actual implementation. Systems administrators included in the planning stage must be sure they don't let the technology pick the business.
The plan, like everything else in your system, must be changed periodically. Deciding when and how this change takes place is an important part of making your plan. Always review the plan when new functions are proposed to look for foreseeable conflicts. Look back at what you envisioned the server to do; if adding a new function will impair delivery of the old services, you should review the plan to remember why you set up that way in the first place. The plan will provide a stable body of knowledge about what your servers do and why. Use this to judge proposed changes.
Review the plan on a regular basis for bottlenecks, and make sure the plan includes an estimate of system limits at any particular time. Regular reviews of the plan should be compared with estimates of user and customer needs. Evaluate the plan's relevance to its goals before it becomes inadequate, and use the plan to predict upgrade paths.
Before making purchases, check them against current and future paths. Implementation scheduling will be simpler based on the plan. Business can be structured around the planned introduction of services. Acquisition of new business should be coordinated with the technical bottlenecks.
The plan and the log book are not completely separate entities. Use them together. Remember that the primary function of the plan is to provide a framework for making decisions about the system. The function of the log book is to keep track of what is actually happening. If the plan does not include disk space expansion, but the log book notes many errors due to lack of disk space, there is a problem with the plan that appears first in the log book.
The log book and the plan are never closer together than during the implementation phase. During the actual implementation of the server, the entries in the log book should follow the plan exactly. If that is not the case, note the variations. Pay careful attention to elements of the plan that cannot be implemented. If the Web server you have chosen does not install because it is not compatible with your operating system or it conflicts with a database, revise the plan and record the specific reasons for this in the log of the session during which this was dis-covered.
A second way in which the plan and log book will work together is in scheduling. Your plan includes your proposed schedule, but the log book will tell you when it actually happened. Comparing your estimates with actual time spent helps your current activity and lets you plan more precisely for future upgrades.
The server setup plan is used to familiarize someone with the context in which your system is operating; therefore, the log book should relate all the details of the setup to someone unfamiliar with it. Staff working on the system should be cognizant of where their activity fits into the plan. When this is the case, simple notations can tie pages in the log to specific line items in the plan. This helps keep the log book current through every change or tweak, large or small.
The log book will provide insight not only into individual line items in the plan, but also into your planning process as a whole. The log book will point out deviations from the plan, possibly revealing a pattern from those deviations. You may notice that you often fail to see hardware incompatibilities or that you're always underestimating the time it takes to complete certain tasks. Examine your log book periodically to understand where the shortcomings are in your planning process.
At last, you get to the real job. If you've read and followed the advice in the previous sections, installation will be much easier. During this stage your efforts will take fruition. This also is the part of the job that absolutely must go right. Poor planning and inconsistent log keeping may still produce a working system, but poor implementation will never do so.
There is no substitute for technical knowledge. No matter how good you are at following instructions, reading manuals, or troubleshooting systems, the technical knowledge of the system you are working with is extremely valuable and, in many cases, irreplaceable. You must do your homework on the things you will be installing and the concepts governing your system well before you try to set it up. Much of this you will discover as you try to plan, but there will still be many technical details with which you must become familiar. Take your implementation plan and figure out each aspect of it. Try to visualize what you will be doing and how. This process of trying to pin down every step will help you remember to have crucial items when you begin implementation.
The following technical terms and areas are some of the most basic concepts needed to set up an intranet. If there is anything in the following list that you cannot at least define, you have more reading to do.
Hardware
NIC
Ethernet
CPU
RAM
Networking
Theory
OSI model
Internetwork
Protocols
NetBIOS
TCP/IP
IPX
Communication
ISDN
SLIP
PPP
T1
The following list contains some terms often presented in contrast to one another. Understanding what each term means and how it relates to its counterpart is essential for understanding your intranet. You should understand the meanings of and the differences between the following:
M&J's server plan was relatively simple. The systems administrator was very familiar with the operating system and the server's procedures were not complex. Also, the server was not expected to receive a lot of traffic right off
the bat. The accounting firm was in no hurry to initiate its intranet's entire audience at once; it planned to slowly introduce its users to the site.
To organize the initiation process, M&J started two separate log books: The first was for the systems administrator and her assistant, the second was for the administrators in charge of developing content on the site. The first log held all the pertinent information on how to start up and shut down the server, including where application and configuration files were stored and a record of problems solved or outstanding with the software or hardware. The second log kept all the information pertaining to the actual site itself: file naming conventions, times and processes for regular updates, templates for standard pages, usernames and passwords for administrative areas and e-mail, and the instructions for such basic administrative processes as setting up new message boards, adding a new user, and creating new folders on the FTP site. |
The SGAA needed a much more complex plan than M&J did. The new systems administrator worked closely with the consultants that built the back-end software to create a comprehensive reference document for future use. From the
first time the server was turned on to the last piece of software installed, each configuration and modification was logged in a notebook. The notebook was eventually converted to HTML and used as an online reference vehicle for the systems
administrator.
In developing the plan for the server, one of the first steps was to map out the hard drive space and decide what would go where on the drive. The consultants and the systems administrator simply mapped it out on paper, leaving space for expansion and placing system files, applications, and configuration files in logical and secure places. Several other steps were included to ensure that the file structure for the Web server and the database was secure. Finally, the plan was implemented slowly. Over two weeks the server was configured and each function was tested. The security was tested completely before the server went online for the first time. |
After you are conversant on the technical issues, you must adopt an engineer's attitude. Each person working on the implementation must understand and religiously follow a few basic principles:
If this is your first time dealing with any component, you should expect to do everything at least twice. The first time you will often make mistakes, and only on the second try will you have the chance to correct those mistakes. Often only a third try will let you know if you really corrected your original mistakes. Don't get hung up on doing it right the first time. Expect to make the mistakes, and go ahead and make them. Doing an initial install presents a unique opportunity to make and learn from your mistakes. You won't ever know what those options do until you try them. Just make sure you follow some basic guidelines:
Make sure that your important tasks have extra time built in. Never rush the jobs that require concentration; you'll only have to pay for it later. Plan for your new system to fail repeatedly. If it holds together, be pleasantly surprised. Expect to be lost. Expect to be confronted with a problem that baffles you, and expect this problem to eat up your planned extra time. Another reason to plan extra time is that you don't just make a problem go away. You must understand the problem first. If you never understand it, you may never solve it.
An old computer expression is "RTFM," which means "read the manual." Nothing gives you as high-quality information as reading the manuals that come with your hardware and software. You should never be tempted to call or ask anyone a question until you have read the relevant sections in the manual. You should read all relevant materials and reread whatever is definitely relevant. Just as important is reading the supplements that come with the manuals. Supplements provide information that is too recent to have made it into the manuals. As such, supplements often provide the most relevant information to your problem. You must make sure that you keep any supplements.
Even more late-breaking and often far more useful are the so-called README files, which contain information too recent to be included in the supplement. Often READMEs are included with software retrieved from online. In this case, sometimes the README is the only manual you have. Another important aspect of READMEs is that they often contain the most candid information. Often a README will contain lists of shortcomings, bugs, and limitations that a company would never allow into a manual.
The following is a brief smattering of issues that seem to crop up almost every time. This list is by no means an exhaustive compilation, but only a sample for those who may be dealing with an unfamiliar product for the first time. Many neophytes will find this useful, and many old hands will nod knowingly.
The broad class of Intel or Intel-clone computers, also known as PCs, have several idiosyncrasies. With the advent of Plug and Play, this has diminished somewhat, but many are still there. Here are a few:
The Macintosh, or Mac, was once the exclusive property of Apple Computer, but now some other companies such as Radius have been allowed to make Mac clones. Macs are known for their easy setup and forgiving nature. Still, there are a few nuances to be aware of:
Make sure you have the right network card or adapter for the cabling scheme you plan to use. Multi-interface cards are often not much more expensive than single interface.
Peripherals are devices you connect to your computer through an external port, such as extra disk drives, scanners, tape drives, and printers. Here are a few issues to keep in mind:
This section lists some of the most common operating systems and one or two of the most common problems specific to those systems.
Even with the advent of Windows 95, these systems are still plagued with nagging problems. Luckily, the operating system is simple, and even the most serious problems can usually be fixed in a matter of an hour or so.
Here are a few tips: Always have a boot disk specific to each computer. When having problems, start removing drivers and features until your system works. Never assume that it is impossible that some component could be causing the trouble. Rebuild slowly to find the troublemaker. Windows systems are easy to strip to the bone. Doing this will give you a clear picture of where the trouble starts.
Even though the Macintosh enjoys a reputation as a trouble-free system, this is only a relative statement; you can still expect to be confronted with vexing mysteries. Sometimes the Mac's hands-off nature works against it, as there are no obvious fixes for the user to try.
Incompatible extensions are the source of a large number of problems. Know how to boot with extensions turned off, and always keep clean copies of the system handy.
Anyone who has a UNIX system already knows what troubleshooting is all about. Problems seem to crop up with UNIX systems more regularly than other, simpler systems, but with UNIX it always works out in the end. The answer is often only a Web search away.
Know how to reboot in single-user mode in the event of catastrophic failure. Have a kernel handy that you know works and know how to boot with that kernel.
Be aware of exactly which version of which flavor of UNIX you are using.
With a concrete plan and a log book in hand, you'll soon be ready to set up a server! Use these two tools together, and don't even consider setting up a server without both of them. After arranging your priorities under your log umbrella, you're ready to begin creating your road map to the server. Remember that the primary function of your plan is to provide a framework for making decisions about the server system. Use this chapter as a framework for your system, and you'll be on your way to setting up a successful server.