Diskless client
[int80h] You could use it for real work. You can put it on your CV.
[kocio] I am having lots of fun with it, too! :-)
About this section
Net-booting and diskless client issues are broad subjects involving technologies like pxe, bootp/dhcp, tftp, nfs and networking in general. Each of them is worth own section, but as you already have learned to learn, they won't be discussed here.
What is a diskless client?
It is a machine unable to be fully operational stand-alone. It needs another machine - the server - in order to boot and operate. Weird? But it is often an advantage, or even neccessity.
Common scenario is that a set of X-terminals or lower-end machines (called "thin clients") with no hard disks boot over the network from a high-end server. Or in reverse: low-end server and much stronger client, which usually runs other OS. This client, being turned into NetBSD box just by pressing one key during startup (no changes of its existing configuration, like disk partitioning, needed) allows then to run X-Window applications, compile jobs, etc. conveniently.
There could be mentioned three solutions, ordered below according to how much client's disk space is required:
- Really diskless.
This applies PXE technology or netboot ROM. You need a network interface card ("NIC") offering such capability. Many newer NICs can do that natively; others can be customized by placing an (E)EPROM memory chip containing appropriate software in the socket on the card.
Note: neither BIOS supporting option like "enable PXE boot vector", nor message like "Press Fn key to boot from network" displayed at startup ensure that appropriate hardware is already present onboard.
- Floppy disk only.
This is less "kosher" approach. Client initiates from the diskette enabling it to download and boot the final system. There is no need for a specialized NIC.
- Filesystem on the server.
Actually, it is not net-booting, but something between diskless client and regular workstation. Client has its kernel on local media, so it boots locally. But right then it mounts filesystem from the server.
In the documentation you will find much longer, but less distinctive list.
Once you manage to set up properly any of these, you will loose the right to call yoursef g00ber, to act like a g00ber, and even to pretend being g00ber.
You were warned.
Information resources
Following list, contrary to other lists in this document, can't be considered complete. From now on, you are on your own.
You need basic understanding of:
- TCP/IP networking
- NetBSD configuration files in /etc/
- TFTP (Trivial FTP)
- bootp or (better) DHCP
- NFS
Your primary reference is:
It contains references to other documentation you should pay attention to. Then, get acquainted with solution-specific issues, of your chosen implementation:
- PXE diskless client:
- PXE (Pre-boot eXecution Environment) specification, to be found on Intel's web pages (I put local copy here for your convenience, it's 0.5 MB PDF file). You don't need to read low-level details, but you must have a clear picture of entire idea and understand phases of communication between client and server(s).
- Booting with custom (E)EPROM on network card:
- Booting with diskette or hard disk:
- Linux Terminal Server Project may be of interest to you, too.
"Any system reference will require you to read it at least three times before you get a reasonable picture of what to do. If you need to read it more than three times, then there is probably some other information that you really should be reading first. If you are only reading a document once, then you are being too impatient with yourself."
Paul Sheer: Rute User's Tutorial and Exposition
If things went wrong
Don't be too proud if everything went well right away - you probably were just lucky. Don't be disappointed if it failed, either. It just shouldn't work the first time you try. Net-boot applies chain of technologies so that each and every must be properly configured.
[int80h] Have you enabled pxe server?
[kocio] err... Should I?
Fortunately, you can enable, configure and test each element independently. See raw checklist:
- Make sure the network is operational.
It includes checking physical link (NICs, cables, optionally hub) and proper configuration of both machines.
- Make sure the server runs every required service.
Check /etc/rc.conf, /etc/inetd.conf, other *.conf files required by choosen solution. Review syslog messages displayed on console and dumped into log files. Remember that service managed by inetd is started upon request, so you may not see it using `ps ax | grep <daemon_name>` command.
- Make sure that security settings do not block communication.
It includes firewall setting, tcpwrappers security mechanisms (thus, required services and clients should be listed in /etc/hosts.allow), individual services' configurations, and optionally /etc/ethers.
- Make sure NFS server works.
Just mount shared directories and try accessing files there.
- Make sure TFTP server works.
Being on your client machine, download the file your client should be able to download when net-boots.
- Make sure that other services, required by choosen solution, work.
- Use tools like `ifconfig`, `ping`, `netstat`, `tcpdump`, `nmap`, or their equivalents for your client's current operating system. Also, there are NFS, TFTP and DHCP clients avaliable for any OS, often boundled together (i.e. WinaXe package for Windows).
If all that failed, give yourself a few days rest.
Client's filesystem: fine-tuning configuration
Initially you don't have to pay too much attention to the client's filesystem residing on server. But once the client boots, you will probably see lots of error messages scrolling quickly on its console and/or system operating in single-user mode.
Tailoring filesystem depends heavily on the particular purposes your client(s) will serve, so there are no universal rules apart from one: don't spoil one system while configuring the other. Client's filesystem, from its point of view, must be complete - but it still remains a part of server's FS. As both filesystems are almost identical, it's easy to make mistakes.
The simplest way would be to make a copy (replica) of an entire NetBSD filesystem under exported directory. In my case, however, limited disk space was the issue. Also, as I am (almost) the only user of both machines, and each machine is sometimes server, sometimes workstation, I wanted to manage both as easily as possible - ideally as one box. A bit of consideration, `mv`, `ln` and editing both /etc/fstab files did the job.
Being on server, I moved /home/ under /export/client/root/ and linked it back to /. I did similar tricks to bin/, sbin/ and to many files and directories under etc/, /var/ and so on. Obviously some of them still had to be separated, because configurations of these two machines differ.
Finally, I gained another NetBSD box at almost no disk space trade-off. I can now run two different Apache configurations, while serving the same htdocs/ tree. I can compile and install new package on the faster box, and at once it appears registered and installed on the slower one (and vice versa). Users' accounts are shared, so moving back and forth between machines is comfortable.
|
