Slashdot Mirror


Ask Slashdot: Linux Diskless Clients?

Graymalkin asks: "I was wondering if there is a Linux program (or many programs) that would let me have a single server on a LAN and then a bunch of diskless clients. I'd like to make the clients have a motherboard, memory, a processor, and a NIC and get all their info from the server. If possible I'd also like to have all the networked stuff loaded into the server's memory so there's as few disk read/writes as possible. Can I do this?"

9 of 80 comments (clear)

  1. Re:Thin Clients by John+Campbell · · Score: 2

    If you're using the client as not much more than a dumb terminal, you don't need much memory. It's possible to run a Linux machine in 8M of physical RAM and no swap at all... I've been doing it with a diskless 386-16 for quite a while now. If you want X, you'll need more RAM, of course, but for telnet/ssh, 8M is fine.

  2. Get your Boot Prom from Etherboot or Netboot Proj by markus · · Score: 3
    Diskless Linux clients have been possible for a few years now. There are two projects that enable you to do this Etherboot and Netboot. Both groups have written Boot Prom images for many popular NICs and they ship additional tools that you need to set up diskless machines.

    The differences between the two projects include 1) size of the images, 2) number of supported NICs, and 3) available features. Nonetheless, they aim for compatibility between each other and it is often worthwhile trying both and finding out which one works better for your particular configuration. (As a co-author of Etherboot, I am somewhat biased).

    Rather than asking your questions on Slashdot you probably stand a better changes getting answers to your technical questions, if you subscribed to the combined mailing list for the two projects. There also is an archive of all the messages ever posted on this list.

    Both Etherboot and Netboot allow to load the Boot Prom image from floppy disk while you are still testing your environment. Once everything works, you can decide to burn an EPROM and eliminate the need for the floppy disk. Of course, with modern NIC cards things are easier, because some of them already include a FlashPROM.

    Another very promising project is NILO. It has originally been started by one of the Etherboot authors and it is currently being written from scratch under commercial sponsorship (the entire project will is GPL'd). See the home page for all the details.

    Eventually NILO will probably obsolete Etherboot and Netboot for everything but very special purposes. It currently is under active development and while we would appreciate more alpha testers it isn't really very useable for real-world applications. There will be announcements on Freshmeat about the progress of this project.

  3. Re:cd-rom clients by tgd · · Score: 3

    I've done that too a half dozen times for servers.

    I burn the root system on a CD, boot from that. It mounts the CD as / (and /usr is sitting on /), /etc comes off a write-protected floppy disc, and everything else mounts from the drives in the system. Its a little slower to boot up, and a bit more of a pain to upgrade the core software, but at a buck a pop its nice to know that even in a worst-case scenario, I would be able to still use the system after a reboot. Upside was even a major problem on the system could usually be fixed with a reboot and restore from tape without having to get at the machine (they were colocated at the time...)

    So I'm sure it would work for workstations too. I ran across an overley filesystem a while back that I experimented with for embedded Linux applications, where a flash partition was mounted with the overlay filesystem, so files could still be "updated". Never got it working right, but I didn't spend a lot of time trying. Might be a good solution to a CD-Rom based install as well, I'm not sure if you can mount an overlay over NFS or another technique.

  4. Re:If Netware/Win3.1 can do it, I'm sure Linux can by IntlHarvester · · Score: 2

    Just as a footnote, your setup used to be extremely common in the late-80s, early-90s with DOS-client LANs. Even when the clients had hard disks (which weren't cheap), applications were run off the network because it made administration simpler. There usually was a boot menu that launched from the Novell login scripts that insulated the users from the DOS prompt.

    What killed this setup was Windows 3.1. Usually swapping over the network was extremely slow, and all of your Windows clients had to have exactly the same hardware for it to work (at least for the stuff it handled like video and mouse). Windows also did not like it's system directory marked read-only.
    --

    --
    Business. Numbers. Money. People. Computer World.
  5. I have some notes on diskless clients by Seb · · Score: 2
    As the name implies, it is a networked machine which doesn't have to have its own hard disk (but may have one). All files it needs it gets via NFS (Network FileSystem). If it hasn't local hard disk, how does it boot? One solution is booting by ROM plugged in the network adapter card, but you must have enough knowledge and access to EPROM burner to do it. The solution I describe is booting by floppy disk which contains Linux kernel image. Once loaded, kernel takes over the control of the diskless client and floppy is not needed anymore.

    ...

    Because I'm tired of writing it all over again, I put it on http://acs.lavsa.com/sskracic/diskless/.

    This describes one real-world setup and also sheds some light on motivation. In my experience, deploying diskless (Linux) clients led to significant decrease in hardware and software cost, and (most important!) greatly reduced admin time.

  6. This is supported in the kernel by Elladan · · Score: 2

    This is already supported in the kernel. You just need to export the server filesystems with NFS, and set up the clients to boot with NFS as the root filesystem.

    What you want is basically to just set up the server with the software for the clients exported over NFS, and a bootable area for the clients. IE, you'll set up a directory tree on the server which will work as a root directory for your clients (with some separate writable space for each client). You'll then probably end up making a boot disk for your clients (easier than getting your NICs to use a boot rom), with a linux kernel on it set up for booting with NFS as the root directory.

    Except for the little trivialities, like:

    • Setting up the server side root dir for the clients properly
    • Setting up the NFS root kernel and the boot disks

    this is a complete no-brainer. Nothing to it.

    A few tips:

    • Read the NFSROOT howto. This would be a good place to start. Also, Documentation/nfsroot.txt in the kernel distro.
    • You're going to want to format the boot disks with some sort of filesystem and put lilo on them, and pass the nfsroot kernel command line through lilo.
    • You'll want kernel DHCP for the room full of machines, but start with static ip's.
    • Start off with your boot sequence simple. Use a statically linked ash or something as your init command, and just get the client to actually boot. Then worry about making it do something useful.
    • Remember that each client needs some writable space of its own to use during booting. For example, they need to write to mtab, so they can mount filesystems correctly, and /var would be a good idea for storing some PID's etc. They can all share /bin, /sbin, /usr, /lib, /dev, /opt etc. It would be a good idea to give them separate /tmp directories as well.

    A couple other things:

    • The disk access on the server isn't a problem. The most recently used files on the disk are automatically cached. If you really want more control, you could use ram disks, but it would probably be less efficient.
    • One thing you may be concerned about is that you can't currently set up a swap file for each client over NFS. This means you may have a problem with running out of ram on the client machines. (There may be a patch available for this, or you might be able to use some other network file system) You could put a hard disk in each one for swapping, but that would obviously defeat the purpose of running them over the network. Make sure the clients have sufficient ram for normal operation.
    • Performance may not be the greatest, that sort of thing.
    • Remember to compile the client kernel right. You know, don't build the things you need to boot, such as, say, the NIC drivers, as modules, because that wouldn't work too well.
  7. Re:HowTos first by remande · · Score: 2

    I used to work for a company that was doing diskless workstations. The purpose that we had was to make the world's cheapest X servers/Java clients. We needed zero administration, because we kept our customer base computer-illiterate.

    --

    --The basis of all love is respect

  8. RTFM! by zmooc · · Score: 2

    Just read the Diskless-HOWTO. It should come with your linux-distribution; usually it's located in /usr/doc. btw I have a bootrom-burner, so if you need a custom bootrom, just mail me.

    --
    0x or or snor perron?!
  9. Diskless clients work and they are really great! by mlgm · · Score: 3

    Hi,

    we use a lot of diskless Linux clients here at several locations of our company and they work great.

    If you have a company environment with a central database and/or file server you depend on a central server anyway so it wont bother you if the clients dont work without the server.

    As for administration its the best thing to do. Its more like having ASCII terminals. You buy a new box, hook it on the network, make a few configuration entries on the server and as soon as you boot the new client it will have all the same software as the other clients, it will have an identical configuration and it will have access to all your personal files.

    And if you care for a good integrated network configuration (NIS, NFS, DNS, etc.) you can really say that as Sun puts it "the network is the computer". People would be able to log in from every workstation and have the same desktop and applications everywhere. No need for complex registry things, just a shared /home and /usr file system :-).

    Often people think a diskless client could be compared to X terminals or things like Microsoft Terminal Server, but this is not true! With a diskless clients each user has its own CPU and memory. They only share the disks. In times where every office application has animated cartoon characters talking to each other you need a lot of CPU power :-).

    Another misconception (in my belief) is, that a diskless client is a "thin client", meaning a cheap client. We use our diskless clients for Java and office applications. This cant be done with an old 486. This cant even be done with good performance with a JavaStation (at least the last one Ive seen). But it can be done with a Pentium III 500 Mhz. And theyre cheap enough (at least for serious company use and more so when you look at TCO). The main benefit with diskless clients is not saving the money for a disk drive, but easy system administration and less problems for the users!

    BTW, the performance is ok. Its a bit different from "normal" configurations. You might need to wait a little longer for the first load of a program after a reboot, but programs like Netscape or Applixware Office start in a couple of seconds and it will be faster the second time. After the initial loading you wont see any difference, at least if you dont have huge files as in image or audio processing.

    My recommendations for say 10 diskless clients with heavy workload would be (things may vary):

    Server:
    256 MB main memory (you cant have enough here)
    Pentium III 500 MHz (the current user-space NFS needs a lot of CPU Power)
    SCSI disks (with diskless clients parallelization is important)

    Clients:
    128 MB main memory (they shouldnt swap)
    Pentium III 500 MHz (could be less depending on your applications, we use Java)
    Floppy (we boot from a floppy)
    NIC (buy a good one with a stable driver, as every bit will go through here; we use DEC Tulip based PCI 10/100 NICs).

    Network:
    It might work ok with 10MBit, but you should really go for 100MBit.
    Buy a dual speed hub.

    Now to the Linux setup:

    First thing the client needs is a Linux kernel in his memory. You can use a boot PROM or start with a floppy which Id recommend. Just compile a kernel and dd it onto a floppy disk.

    The kernel should have drivers for your favorite NICs compiled in and it should have support for root file system on NFS and Bootp support. After building the kernel you have to use rdev to actually configure the root file system.

    After you start the kernel, it will ask a Bootp (DHCP) server for its IP address and root file system. This will then be mounted via NFS and the rest goes like any other Linux box.

    If you want a really integrated solution, you have to set up the following subsystems:

    * DNS Domain Name Server
    Have entries for the server and all clients. Better than /etc/hosts in the long range.

    * Mail
    Use the server as SMTP and POP3 server.

    * NIS/YP Network Information System
    Use NIS for a common login administration.

    * DHCP/Bootp
    Use DHCP for configuration of diskless clients.

    * Printer spooling
    This is a bit tricky with apsfilter, but having network printers or printserver helps.

    * NFS Network file system
    This is the base system for sharing files. You can share /home, /usr, /opt between server and clients and should have / and /var separate for each.

    For start make a copy of your Linux filesystem and name it say /clients/client1. Then compile a kernel with root NFS and setup DHCP or Bootp. With only a few changes on your server you should be able to boot a diskless client. The changes would be DHCP, an entry in /etc/hosts or DNS, and NFS server with exporting /clients/client1).

    I did this using a SuSE Linux 5.3 but it should work with every distribution (we still use this older version, because in a company environment you just cant change your OS every other day :-).

    Just try it out step after step: first boot the client and see if you get a Bootp request at the server. Then Bootp should give the client a new IP address. Both should be fairly easy. The tricky part might be getting a root file system from the NFS server. But then, you only have to get /etc/exports right. And then the client will boot and you can make adjustments in the root file system.

    Good luck and best wishes!

    Michael

    P.S.: I made my first Unix diskless client system about 10 years ago using DECstations running DECs Ultrix because our university had ordered several DECstations but only one disk because of a money shortage :-).

    I believe, that the ability to run on diskless clients is a huge advantage for Linux compared to Windows NT. As I said, the Microsoft Terminal Server is a different concept and its worse in performance because all users share a CPU.

    But on the other hand, if you push Linux so far and make heavy use of all daemons ranging from DHCP to LDAP, you will also see its limitations. Coming from different persons, different parts of the system might not work as good as possible with others. Examples include the integration of NIS. I mean, most things in Linux work, sort of, but it could be better. Does anybody know how RedHat scales in this area, as I never actually tried it.

    If you feel the need to criticize me for "Linux bashing" please make your own diskless client configuration first and install it in several companies with real users and real world problems and then come back. But to calm you: a large Linux installation is better than a large NT installation any day :-).