LAN DESIGN - Part 4

by Wayne M. Krakau - Chicago Computer Guide, January 1995 - NewsWare, July 1996

This article is the final installment in my LAN Design epic. Last month I covered fault tolerance, and electrical protection. This month I will begin with network organization issues.

It is vital to plan the organization of your LAN. For instance, managing and debugging LANs is an arduous task when individual login scripts are used. One small change in the network that would be trivial to accommodate in a system login script can result in a mad scramble to change individual login scripts. Even Novell, after years of teaching that user login scripts are practical, has finally changed their opinion and now strongly encourages the use of a flexible system login script with little or no employment of user login scripts.

People who say that they can't avoid user login scripts are like the programmers that I used to encounter who always came up with excuses as to why they couldn't write a particular routine using structured coding techniques. It's all a matter of mindset. As you get more practice with the system login script, you find that you eventually don't need the user login scripts. The underlying logic becomes apparent.

The workstation-based backup system that I suggested in Part 3 of this series is a good example. I used to implement that type of system as a user login script. Eventually, I figured out how to get around the limitations of the early versions of backup software available years ago and have since used the system login script

Amazingly, many people who were originally exposed to login scripts in old (2.x and below) versions of Netware still haven't figured out the improvements that have been made to the flexibility of login scripts over the years. The addition of an "ELSE" statement (as part of the "IF" logic), the accessibility of DOS environment variables, and the enhanced "ROOT" option of the "MAP" command are the three that I've found the most useful.

One technique that makes using only a system login script easier, is to organize users into groups. Groups also make the assignment of rights much easier. By extensive use of groups, you avoid the temptation to neglect the security aspects of the network. With groups, there is much less overhead involved in administering security.

Planning security is a tricky issue. I have found that the best way is to use the "need-to-know" method. Just assign the rights that are required to get everyone's job done and no more. Every file that someone cannot needlessly change is one less potential "oops" that can be avoided. Also, remember that a virus gets the same access rights as the user who inadvertently executes it. If the user can't change a file, then most viruses can't. In Netware, you can even make a file "execute-only". I have not heard of anyone being able to break that attribute. As an added bonus, it makes files impossible to copy, thereby limiting the potential for piracy.

Another interesting aspect of security can be found in applications programs. I strongly recommend that you carefully analyze all directions and documentation from applications programs regarding rights assignments. The vast majority of software companies, including the giants, are far too liberal. Work out their suggestions on paper and, if possible, experiment to try to find out how much extra protection you can provide without affecting the reliability of the program. You will find that, although the documentation often instructs you, for instance, to give all rights to all users of a given program, that the program will actually

run fine in a very protected environment. Creative use of trustee directory assignments, trustee file assignments, and individual file attributes may be necessary to effectively secure the program's files.

Now comes the "fun" part - documentation! Everything on the LAN should be documented. Anything that's not will have to be discovered on-the-fly, during a debugging session - with the LAN down and users and management screaming at you! If you have to call in outside help, their meter will be running while you try to gather information, or worse, they have to do it. Creating this documentation will also help you avoid configuration mistakes.

All hardware needs to be tracked right down to the smallest detail. IRQs, DMA channels, low memory address ranges, high memory address ranges, CMOS settings, ROM and board version numbers, and all associated details have to be recorded. Serial numbers are also necessary to fill out registration cards. There are many utility programs available to collect hardware and software configuration information. Most are not really comprehensive, so you may have to use multiple utilities. I carry several of them with me.

Much software information has to be tracked. Directory structure, configuration files, login scripts, version numbers, licensing limits, and individual software settings, need to be recorded.

The method used to record this data is immaterial. Paper documentation works fine if it is well organized. A database or even a spreadsheet will do for an electronic record. If you want to get fancy, there are several commercial LAN inventory programs available. Just gather the information any way you can. By the way, if you use a computer to record this stuff, make sure you have a backup so you can get at it during a catastrophic system failure!

Since I just mentioned version numbers, I want to emphasize that the driver software that you get with network operating systems, network interface cards, disk controllers, and just about anything else that needs drivers is usually out of date. Always check with the manufacturer's bulletin board or its forum within an online service to see that you have the latest drivers.

For Netware administrators, a Compuserve account is absolutely vital, since Novell's online support is on Netwire, within Compuserve. When I teach Netware classes, I only half-jokingly tell my students to throw out all of Netware except SERVER.EXE, and to download the rest.

I also want to warn you that using VLMs, or Virtual Loadable Modules, may be hazardous to your network’s health. Make sure that you test all of your applications thoroughly before switching. I discovered one client in the middle of uninstalling Netware 4 and reverting back to version 3.11 because too many of their applications were incompatible with VLMs. Netware 4.01 was not very useful for them without VLMs, so they just pulled the plug. Also, remember that even though Netware 3.12 specifies VLMs, it doesn’t really need them. It will run just fine with the older ODI Shell. I have several clients who have switched back to ODI from VLMs after upgrading to version 3.12. I expect that both compiler publishers and Novell will eliminate these incompatibilities over time. Until then, make sure you test prior to your implementation.

In this series, I have given you some ways to prepare for troubleshooting and to try to avoid the need for troubleshooting. By implication, I hope that you realize that I chose these suggestions based on my observations as to what kind of problems actually occur. To do the troubleshooting, you need to look at these proactive methods and probe for weaknesses in their implementations through what can be best be described as detective work. By sneaking this information to you via a discussion of management and planning, I hope that you will be better prepared to do your detective work. Good hunting!