Taming PC Networks with Remoteboot

This paper re-introduces remoteboot as a basic building block for large PC networks that are cheap to run. Once a concept that applied to dedicated diskless computer hardware, then implemented by 3Com, Novell, Microsoft and other LAN suppliers in proprietary solutions, remoteboot is now an important administrative tool based on recent Internet standards.
A Component Approach to Managing Large-Scale PC Networks

* Large PC Networks - More Options, Less Choice
* Remoteboot - How it Works
* Applying Remoteboot
* The Shape of Remoteboot to Come

Large PC Networks - More Options, Less Choice
Times change, but do PC networks? The IT world is in more than turmoil with the latest developments in the fatware vs. thinware and Total Cost of Ownership debates. Netscape releasing source code, Java and CORBA finally mating, Network Computers being widely deployed… there’s a new technology in this area every other week. A lot of it makes sense but the trouble is, you’ve already got a few thousand PCs in the network that you run and nobody is going to pay for them to be replaced in the foreseeable future. The applications in use are strictly PC workstation-only, and the company depends on them for its livelihood. Changing the application base will be a huge task. Besides, all too often corporate IT directions seem to be set on golf courses where there isn’t any annoying technical input… sound depressingly familiar? So for one reason or another most of us will be stuck with the basic PC paradigm for the next few years at least. We have no choice.
Every Big PC Network is Different
Of course it is - but the companies who sell PC management software don’t want to admit it! PC management is a recognised problem. The hardware is insecure and difficult to configure in bulk, and every new version and patch of Microsoft’s all-encompassing operating system comes with a new set of conflicts. You can add a few megabytes of management software to each workstation but this compounds the problem of proliferating proprietary software. The NetPC seems dead, although it was designed to solve this very problem. The lesson there is that even proprietary booting protocols are not acceptable!
Every corporate network is different, yet management software from all of the big names (Intel, HP, IBM, Fujitsu/ICL and the rest) expects the network to be redesigned to suit its own requirements. This is why the richest companies, such as banks, typically have a large team of system programmers for creating their own management solutions from scratch. For the rest of the IT world, administrators of hundreds or thousands of PC workstations must either give in to this software fascism or pick a toolset for constructing their own PC management system.
The PC Nightmare - Users in Control
The success of the PC has given rise to so many different hardware manufacturers and such a turnover of equipment that most large networks have many kinds of PCs. Even those that can afford to stay with a single manufacturer usually have a large range of BIOS types. BIOSes have different (sometimes no) means for securing the hardware, many of which have security flaws described in detail on the Internet. But even if a particular PC BIOS offers bulletproof security there is no way of implementing this protection across a network of miscellaneous PCs in a consistent and manageable way - how do you propagate password changes, or floppy access permissions, or activate the keyboards on all those print servers? There is no concept of networking built into the venerable PC BIOS, and attempts to bolt it on (such as the NetPC initiative) have completely failed to take over the market.
In most large networks anyone sitting down at a PC is in complete control of the hardware and can move programs, data and viruses to and from the hard disk. They can even boot from the floppy disk and from that point the hard disk is completely open no matter how carefully the operating system has been secured. Security-conscious sites should be nervous at the fact Windows NT stores the plain-text equivalent of all passwords on its hard disk. And that Windows 95 can’t be effectively secured at all. And that security vulnerabilities in Windows are being regularly discovered and published on the Internet - but even when there is a patch released, how can it be applied to every machine?
Nobody wants hackers or disgruntled employees taking advantage of these vulnerabilities but the majority of the daily problems on a PC network are much more mundane. They are also frustratingly complicated because of this assumption that a PC is only answerable to its user. Diagnosing hardware problems such as a failing hard disk, faulty network card, corrupted operating system or unreliable power supply take up a lot of helpdesk time, and similarly basic software maintenance accounts for much of the rest: a new version of a package is required, or an OS upgrade, or a reinstallation due to a mysterious corruption. Just isolating the problem takes time, and software maintenance is a painful process. And when a new PC arrives (or a replacement hard disk) the same two hour installation process has to be repeated every time. The network helpdesk is not a happy place to be!
Remoteboot Means What it Says
Remoteboot means booting under the initial control of a server remote to the workstation. It doesn’t mean a PC management package, although it often is a tool in management solutions. It doesn’t mean diskless either, although it is possible to use remoteboot to construct diskless workstations running DOS, Windows 95, Linux and most Intel versions of UNIX.

Remoteboot is a tool that gives total administrative control of a PC to a remote server as part of the hardware boot process.

There is no limit to what can be done after remoteboot takes over and before control is handed back to the user. Every single observation in the previous two paragraphs can be addressed, or perhaps just a simple authentication check made before the PC has finished its hardware boot process. Proprietary LAN remoteboot solutions are in fact much more than remoteboot - they attempt to be a complete management package, creating yet another way for network managers to be trapped into solutions that require specific servers such as Netware or Windows NT yet don’t address their problems. Remoteboot is merely a concept for how to start a workstation, and in these Internet-centric days it means "via TCP/IP".
Using TCP/IP remoteboot, administrators can build their own PC management solutions for any popular client type, and can use whatever server environment they prefer, from mainframes to Netware, Windows NT to UNIX or Linux.
The Sky is the Limit!
Pick your remoteboot OS, pick your tools, and away you go. Take it easy, you can introduce remoteboot a little at a time because all the changes are at the server end. Before your client PCs boot - before the boot sector is even looked at - what have you always wanted to do? Validate users, check for viruses, update the OS kernel, rewrite the boot sector, log the boot attempt centrally, reconfigure the OS boot software…
Now you can.
Remoteboot - How it Works
The TCP/IP BOOT-PROM is the heart of the system. Simply a 32k or 64k EPROM chip, it plugs into the slot provided on every reputable network card. Many large organisations burn third-party firmware images onto their own chips, saving time and cost while allowing basic customisation of the image. When the computer is switched on, all the cards are given a chance to execute their own BIOS before the boot continues, before any of the peripherals are listening to the user. The TCP/IP BOOT-PROM takes over and performs its own initialisation and this is why administrators can be so sure that they have absolute control over the PC. In the trivial case the TCP/IP BOOT-PROM can simply secure the floppy drive (prevent it from being the boot device, or make it write or read-only) and then boot from the hard disk. This is useful, but remoteboot really shines when used for interactive control over the boot process.
The first thing a TCP/IP BOOT-PROM normally does is initialise its TCP/IP stack in memory. It sounds slightly bizarre to have a working TCP/IP stack running at about the time you’d normally expect a startup beep, but this is the magic of remoteboot! The stack doesn’t know anything about itself (it can’t just look up a file on the hard disk, because the computer doesn’t know anything about its hard disk yet) but it can send out a Dynamic Host Configuration Protocol (DHCP) request. The request says “Help! This is my Ethernet address, I need IP information!” and is heard by any server which implements the DHCP Internet standard. The DHCP server sends back all the information relevant to that ethernet address, either calculated at the time or retrieved from a database. This information must include standard things like IP address and netmask, but can also contain any customised value.
The DHCP data also typically provides a boot server and boot image name. The TCP/IP BOOT-PROM loads its IP information and then uses its fully functioning TCP/IP stack to open a Trivial File Transfer Protocol (TFTP) file connection to the boot server. The file can be of any size from a few bytes to an upper limit of about 32MB and is one of two types, diskette images or directly executable programs.
Bootable Diskette Images
A diskette image is a single file containing byte-for-byte replicas of the information that is actually stored on a PC floppy disk, with tracks, sectors, a FAT and most importantly a boot record. You can think of it simply as an alternative way of storing floppies. There are many programs that allow these sorts of images to be maintained on an interactive or automated basis, often tools that have grown from a diskette archiving background. An image file is stored on the TFTP server in a location pointed to by the DHCP reply packet.
Before it downloads the image, the TCP/IP BOOT-PROM prepares the PC memory. It creates a ramdisk with such a good emulation of the hardware that an operating system is completely fooled into thinking it is the A: drive. The TCP/IP BOOT-PROM then TFTPs the image straight onto the ramdisk and starts executing the boot record. The operating system is on the boot image is started, under the impression that it has been booted from the A: floppy in the normal way. The TCP/IP BOOT-PROM has now done its job, and the field is open for the administrator to do giving limitless scope for (re)configuration before the PC is bootstrapped ready for the user.
Direct Execution - An OS Before the OS
Directly executable programs are downloaded and run immediately. But you won’t be able to run COMMAND.COM, QUAKE.EXE or even NTOSKRNL.EXE like this! Remember, there are no operating system services running at this point and the hardware initialisation may not even have been finished. Apart from ROM BIOS calls and basic networking facilities provided by the TCP/IP BOOT-PROM, every system routine must be present in the program. This sort of program is, in effect, a mini operating system that only takes a fraction of a second to download and start executing. Typical programs include menu systems for selecting the boot method for the PC (perhaps offering a selection of diskette images), password control and hard disk verification. Since none of this code or data is on the local workstation the configuration can be changed instantly by modifying the files or by changing the DHCP data.
A special case of directly executable programs is when the TCP/IP BOOT-PROM code itself needs to be updated. The latest image is downloaded and executed and the process started again (construct TCP/IP stack, send out DHCP request, etc.) Some ethernet cards have FLASH memory - but it comes to the same thing for network administrators. For an insignificant overhead they are completely protected against code obsolescence. Try that with your Windows management bloatware!
Applying Remoteboot
The general idea is to start an OS with remoteboot, run whatever customised scripts, batch files and programs are desired and then hand over to the real OS that the users will see running. The real OS may be the same as the remoteboot OS, or (for example) a Linux remoteboot image may be started first to do some efficient file updating on the hard disk, and then Windows 95 started once everything is in order.
Just about any operating system that will boot from floppy disk can be remotebooted DOS (or now DR DOS, for any serious use - see http://www.caldera.com) , Linux and Windows 95 being the most popular choices. DR DOS is an actively maintained version of the ancient MS DOS that is often used to start networking services such as Netware, LAN Manager or packet drivers that can access the LAN and run standard maintenance programs. The reasons DR DOS still makes sense in many situations is that it is simple, quick to download and boot, and has a very large range of software available for controlling the machine at any desired level.
Since remoteboot is just another tool administrators can build their own customised solutions around it. Here are some of the more common and uses. See http://www.bootix.com and examples for a range of white papers related to remoteboot on corporate networks.
Installation and repair There’s no need to worry what state the hard disk is in, or even if it has anything on it at all. There are some powerful tools that run under DOS and Linux which can detect the partitioning status of a disk and repartition it if desired. Then the standard filesystem can be downloaded from a network server. A damaged hard disk (e.g. one with a virus) will just need the changed bytes refreshed. Many sites install new workstations this way: if the remoteboot script detects a valid hard disk installation the very little is done, but if it detects an empty or invalid disk a complete fdisk/format, Windows NT install, service packs application and software package installation is done. Unattended.
Hardware fault reporting Remoteboot is in control and with networking enabled at the lowest level of the PC boot. This means that programs can be run to test for hardware not responding or being erratic and report them via the network to a central location. Since these tests only take a very short time they can be done at every boot without penalty.
Bullet-proof partitions The first one in wins! Because remoteboot is started first, it can run a memory-resident program to protect Windows 95 or DOS partitions. Using this technique a disk can be divided into non-writeable and writeable sections, with the operating system and applications stored on the non-writeable section. This is one way of avoiding the large security holes due to FAT having no concept of file permissions.
Modify OS before startup Windows NT is an example of an OS with some vital values often hardcoded and only changeable after a reboot. An example is the workstation name - an administrator often wants the workstation name to reflect the current user or its current position on the network. Using remoteboot the workstation name can be passed in the DHCP data or entered by the user using a directly run program and then passed to an NT driver to write into the registry as soon as the hard disk driver has been initialised.
Upgrading Application Software One of the most painful network management jobs is keeping PC applications up to date. The biggest and worst written of these packages can take a long time to install, and there are so many ways of installing them that no two client machines are ever quite the same. With remoteboot, it is possible to force an update of the software on the local hard disk from remote. A script is run and if the application is not present all the relevant registry keys are updated automatically and the application files copied. Every installation is guaranteed to be the same. And it happens automatically!
Onsite Troubleshooting It is extremely useful for a technician on the spot to be able to enter a password and be presented with all the tools needed to diagnose and repair a PC. Download and run a diskette image containing Nortons Utilities, or the network card configuration software, or a program to reload the BIOS parameters - and all in a few seconds, with no chance of a bad floppy or virus infection.
The Shape of Remoteboot to Come
Thanks to the Network Computer there is a whole new group of companies showing interest in developing and extending the ideas of Internet remoteboot into the future. Together with the existing PC remoteboot users there is no chance that this technology will again fall into disuse for the foreseeable future.
Common Internet File System
With several brands of Network Computer (http://www.nc.com) already showing leading the way, booting from the Common Internet File System (CIFS see http://www.microsoft.com/intdev/cifs) is likely to become a mainstay of corporate PC management. While TFTP has had a long and distinguished history, the Trivial part of it is no longer strictly necessary. The EPROMs on network cards are larger, and network filesystems of many sorts are much more common. TFTP, on the other hand, has remained specific to booting and servers are not setup by default on most operating systems.
CIFS is a misleadingly named protocol, being a recent descendant of the Server Message Block (SMB) protocol as implemented by Samba (http://samba.anu.edu.au), the Windows product range, IBM’s operating systems and many others. Any of these operating systems can share out files using Microsoft-compatible networking - think of it this way; if you can see it in the Windows Explorer then it’s a CIFS server. Booting via CIFS doesn’t deliver increased performance and it does require much more complex PROM code, but it does mean that any handy Windows or Samba machine can be used to store remoteboot images.
There are other advantages to having an embedded CIFS implementation in every PC. Authentication by means of firmware becomes possible, meaning that without changing any hardware at all networks have suddenly become as secure as their authentication database. A PC will not even boot unless a valid username and password is entered. A successful username and password can even be written into the registry configuration files so that the user never needs to enter it again.
No matter how the user authentication database is distributed in an organisation, the success of Windows guarantees that there is likely to be a CIFS interface to it. NIS, Kerberos and many other large-scale authentication schemes can be accessed via Samba; Netware has NT Workstation compatibility built-in and of course Windows NT domains are automatically compatible with CIFS.
IPv6
IPv6 (See http://playground.sun.com/pub/ipng/html/ipng-main.html) is the next generation of TCP/IP. For remoteboot it offers security improvements (DHCP broadcasts with sensitive information are potentially a security risk) better behaviour through routers and much more advanced multicast handling with more flexible group descriptions. There is also a new type of address, the anycast address, which may well take over from multicast for heavily loaded networks with many remoteboot clients. The mobile IP features may also be of interest, in those cases where machines are required to keep remotebooting through network rewiring projects or office shuffles.
Embedded networked devices
Embedded networking devices are becoming much more common. Modern buildings have large numbers of embedded computers, increasingly relying on high-speed computer networks to function instead of serial cables. Typically these systems boot from local storage (ROM, FLASH RAM or hard disk) but the dynamic nature of remoteboot makes it a natural choice when there are many similar systems involved. Climate control and energy savings systems are examples, with often hundreds of cooperating embedded processors. It is a major advantage being able to change the configuration of these processors from a central location without having to build in a complex communication protocol.
More bandwidth allowing better application distribution
The battle of the networking giants to bring large amounts of bandwidth to desktops can only be good for remoteboot, and perhaps will spark greater deployment of diskless workstations. Even at 10MB users often report that diskless workstations perform many operations faster and with 100MB, 155MB or even higher speeds available the network transfers will be substantially faster than even the theoretical limits of current hard disk technology. With the inclusion of diskless capability in Windows NT 5.0 (expected in 1999) those companies already using Windows 3.11 and Windows 95 diskless are likely to upgrade, and perhaps others will be tempted.