Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux Network Install Options? 45

Posted by michael from the click-and-drag dept.
verch writes "I work at a Large Corporation that is considering Linux as a competing platform to our large Solaris and Wintel install bases. One of the biggest concerns is how easily a large number of linux machines can be installed mostly unattended. For Solaris we mostly use jumpstart which allows us after minor preparation to simply remotely attach to the console of a machine and boot and install it over the network. x86 hardware tends not to be as nice, I don't know of any linux hardware that has remote console capabalities as nice as Sun's, and network boot options are limited (PXE?). Installation procedures that involve having to lood a CD or boot floppy into every machine could potentially be dealbreakers. So, what options exist for completely remote unattended installs of linux machines?" Had a similar question a while ago; have things improved since then?
This discussion has been archived. No new comments can be posted.

Linux Network Install Options? More

Linux Network Install Options?

Comments Filter:
  • Just finished installing RH 7.2, and it left a nice trail (not only a log) of what I did. So next time, I could just copy that file (kickstart) to an install floppy and it would bring it back to what I just installed. Be sure to check all the options (interactive or not, partionning, etc.).

    I know RH has always been installable n network (ftp, nfs). Probably some other ones too (Debian). It's before you start that your problem lies (booting the computer to start the install). Sorry, I don't see how you could just hook a new PC to the network and start installing without being at the console.

    Also, what do you use on the Wintel side? It works with your current hardware, right? Is it (or could it be made) enough OS agnostic to be used with Linux?
    • The current wintel solution is a boot floppy, the wintel guys are used to this, but the unix guys would find it pretty unacceptable. A PXE solution is being explored for XP, and I'm going to look into using PXE for linux, but PXE isn't as nice as say bootparams. Like you highlight, the network install part isn't actually all that difficult, its the nework boot piece where linux (due to HW limitations) seems to lag far behind.
      • Windows 2000 had a PXE install; only needed a boot disk if the computer wasn't PXE-boot capable. Of course, you needed to stand there and hit F11 or some such. If you had the appropriate GUIDs from the machines, you could even pre-load the active directory and it would go.
    • Booting the computer off a network share if it fails booting from the harddrive (bootp, tftp) will get it to step 1 with a known good ssh key and account.

      Step 2: is to dynamically (dhcp) assign it a static (internal) IP. Have ssh come up on a non-standard port.

      Login using the key to the IP and do your installation probably via a local ftp or nfs server.

      Step 3: is tricky. Mount the drives overtop of currently existing partitions (ie. Drop existing /usr, mount new /usr. Mount new / overtop of old /). Run daemon startup scripts for ssh (standard port, freshly installed copy).

      Step 4: Login via ssh on standard port to ensure it works and you have access. Now shutdown your old ssh connection, and stop the daemon on the non-standard port.

      Step 5: Configure away. Live IP (alias on card with DHCPd internal IP, or a seperate nic entirely), passwords, other basics.

      Step 6: Reboot.

      It'll boot from disk successfully, and go from there. You've already verified ssh works on the internal IP, so if there are problems you should be able to get in to fix them.

      If you prefer, you could setup the kernel of the network booted copy to load serial console support, as well as the freshly installed copy. I'd to ssh anyway, just in case.

      Did this with 5 boxes quite a while ago with early FreeBSD 3.x. May have been even earlier, so modify to suit current requirements.

      I never did figure out what to do if the box couldn't get to the point of console or network connection. The bios won't start a netboot then as it's found something on the harddrive, it just fails.

  • I hope this helps (Score:1, Informative)

    by Anonymous Coward
    I found the following site with google. It has a rough outline of booting intel hardware right off a network like a Sun machine. Good luck.

    http://www.linuxdevices.com/files/misc/pxe_boot_ st b-howto.html

  • System Installer Suite (Score:4, Informative)

    by grundy ( 151557 ) <explodingskull.gmail@com> on Tuesday April 02, 2002 @01:46PM (#3271259) Homepage
    System Installer Suite [sisuite.org] I can't say enough about how cool this project is. Plus the developers all hang out on irc.openprojects.net in #sisuite.
  • if linux had un-attended remote install capabilities, I would have installed it on every server that beat on my firewall after that last web virus.

  • See the Diskless-HOWTO (Score:4, Informative)

    by tshoppa ( 513863 ) on Tuesday April 02, 2002 @01:47PM (#3271270)
    Most of the questions you need to be asking at this point (especially "how do I boot a PC over the network?") are answered in this section of the Diskless-HOWTO [linuxdoc.org]. It discusses TFTP, BOOTP, and network boot ROM's.
  • I just installed Mandrake 8.1 and it has an option to create a auto-install boot disk for unattended installs. I believe you could make a CD with only the packages you need, and use it to create the auto-install boot disk, it would be fairly unattended (you would need to put the disk in and probably confirm the install)

  • It's not supposed to be that easy (Score:4, Informative)

    by Skapare ( 16644 ) on Tuesday April 02, 2002 @01:52PM (#3271318) Homepage

    If you can initiate a network install from the network, then you have a security problem. I'm glad it doesn't work like that. But PXE comes close, allowing a machine to boot from the network. Redhat supports this and the support code is available from them and Intel (who created PXE, which is found in their server grade network cards). There are also some machines that have serial consoles (like Sun). The Intel ISP-1100 rack mount servers have this, and I can control the BIOS and select the boot source this way.

    Tell me why installing from a CD is a deal breaker. Is it because you see it as an interactive thing, requiring you to sit at the keyboard for each machine? I'm working on the design of a CD-based headless non-interactive install system. It can either have the files to install on the CD, or on the network (uses DHCP or generates a 10.X.X.X IP address from the low 24 bits of the ethernet address). You make sure the machine is configure to boot from a CD, stick in the CD, press reset to reboot, and the CD boots up and does it's thing without any more interaction from you. You have to have pre-built your system tree (I've done this with Slackware as well as Linux From Scratch). Unfortunately, my work is still a work in progress.

    • A CD is fine for a few machines, doesn't scale out nicely to installing a 500 machine compute farm. Its also a pain when you want to make a change to your installation process (or add a new package or whatever) and need to cut a new mass of CDs. You could probably get around this by makinge the cd just the boot media. There is also the perception, which dumb or not does factor in to acceptance.. telling people they need to go stick a CD in the machine to install it will seem like a step back. Most of the SAs here probably haven't had to do that for 5 years easy. Makes something that is already hard to sell harder.
      • Don't think of the CD as a boot device, think of it as a boot rom. It should have the same stuff that the sun rom has (ie, not the kernel or any of the real OS).

        It is just a more easily replaced boot rom.

        (A floppy would work, but there may be reliability isses.)

        Joe
    • Sparc hardware and Solaris makes it easy, but secure. Once you put the effort in to build a Solaris Jumpstart server, installing any number of machines is trivial.

      My servers have Sun LOM/RSC serial consoles connected to a 'secure' (OpenBSD) serial console server, so forcing a re-install of the base OS is as simple as shuttting down, entering 'boot net - install' at the 'ok' prompt, and waiting 45 minutes or so. I can do this as easily from across the office or across the country.

      I routinely build, hack, and rebuild test servers several times a day. Others report doing 500 machine rollouts with little or no human intervention.

      Some of the features of the Sparc PROM and Jumpstart can be duplicated with a boot floppy, but many of the coolest features are not as easily imitated. The PC Weasel is a pale imitation of the boot PROM. APC remote power cycling doesn't come close to the functionality of Sun's Remote System Control. Linux 'netboot' is years behind Sun's Jumpstart software.

    • Tell me why installing from a CD is a deal breaker.

      • Because I want to install 100+ machines in an hour, and don't want to make 100 CDs or floppies?
      • Because I want to re-image a machine in the field office 3000 miles away, and I'd rather not talk a secretary through the procedure?
      Dude, the network IS the computer...
  • I think redhat has something they call kickstart. You basically have a file that tells it how to install RH and just boot the machine with the disk in then go away.

    Also there are a number of places that do stuff like this with Linux as they have networks of computers. Try going to linuxdoc.org and readding the howtoos... http://linuxdoc.org/HOWTO/HOWTO-INDEX/howtos.html

    Also read this howto http://linuxdoc.org/HOWTO/KickStart-HOWTO.html as it is about the RH kickstart. It talks about network installs and nfs install as well.

    • Re:kickstart (Score:2, Informative)

      by edyu ( 259748 )
      My company also need to network boot a large number of linux boxes. We use Redhat kickstart. It's one of the easiest way to install a large number of workstations.
  • Not a customer of real weasel, but try them [realweasel.com] with RH install scripts plus a boot PROM. Should do the trick. Just remember to check for a pre-existing install of RH before installation, or you'll wipe out your install at every boot.

    (Sorry if this is a repeat. Just had some browser weirdness)

  • The Solaris Jumpstart Design Notes [amorin.org] provide a fairly good outline of what would be needed to accomplish remote installation of linux boxes.

    Here's the overview from that document:

    1. Client sends a RARP for its IP address

    2. The Boot Server responds via RARPD (in.rarpd) with the IP address in /etc/ethers or the ethers NIS/NIS+ map depending on the ethers setting in /etc/nsswitch.conf

    3. The client sends a tftp request for a bootimage

    4. The server starts in.tftp from inetd and sends the small net kernel image

    5. The client then sends out a bootp request

    6. The server responds with the clients entry from /etc/bootparams

    7. The client NFS mount it's root partition from the install server

    8. The client then mounts the configuration server (/jumpstart) and runs "sysidtool".

    9. It then mounts the install image and runs Suninstall to begin the install process.

    It seems that Kickstart provides one, but not all, of the key components that are needed.

    Checking out the Kickstart Documentation it seems that no provisions are made for remote installations. You must insert a boot floppy and be at the console to handle special cases that will most assuredly arise.

    VNC may meet the need for the remote console component. Of course you would need to get a basic kernel and IP running on the box before you could even start up VNC. That mght present a chicken and egg scenario.

    There certainly would also be a fair amount of code required to glue it all together.

  • I remain to be convinced that anyone has actually had this working.

    I spent ages working with various combinations of dhcpd, tftpd, Solaris and Linux in a vain attempt to boot my laptop [aglet.net] off the network.

    In the end I cracked and bought a floppy drive for it.

    Could anyone that has a working config publish it, together with the version numbers and config files of all the servers installed? All the vendor-specific messing in the DNS, ick.

    • My mp3 player boots over the network using an eepro card using pxe...

      dhcpd --version
      Internet Software Consortium DHCPD $Name: V2-BETA-1 $
      Copyright 1995, 1996 The Internet Software Consortium.
      All rights reserved.
      Usage: dhcpd [-p ] [-d] [-f] [-cf config-file]
      [-lf lease-file] [if0 [...ifN]]
      exiting.

      (annoying that there's no version number...)

      dhcpd.conf:

      host music {
      hardware ethernet 00:02:b3:39:b5:8e;
      fixed-address 192.168.128.200;
      filename "/tftpboot/pxelinux.0";
      }

      (once again no version can be found for the tftp program)

      in inetd.conf (I think the blksize bit is important):

      tftp dgram udp wait root /usr/local/sbin/in.tftpd in.tftpd -r blksize /tftpboot

      And pxelinux grabs the kernel itself...
      http://syslinux.hackerdojo.com/pxe.php

      The mp3 player itself:
      http://audin.dyndns.org/camera/public/mp3 _player_4 /

      It has since been replaced with an audiotron, as I didn't feel like writing software for it.
  • System Imager [systemimager.org] can be used to automate remote installs, updates, software distribution and data distribution.

    To configure the system after the software installation there is System Config [sourceforge.net] which integrates into System Imager.

  • LTSP project and network booting (Score:1, Interesting)

    by Anonymous Coward
    The Linux Terminal Server Project (ltps.org) has some parts that could be used to create and automated network boot/install. Etherboot is used to enable an Intel arch. machine to load and boot a kernel from a network server. RARP and tftp are used much the same as Jumpstart. You would need to create a bootable mini-system that would install the OS and configure it to your specs.

  • Remote console (Score:2, Informative)

    by PinkFreud ( 51474 )
    http://www.dell.com/us/en/esg/topics/esg_pedge_rac kmain_servers_1_pedge_1650.htm [dell.com]

    I seem to recall these having decent serial consoles, supported by the BIOS (one can even configure the BIOS via serial console).
  • Slightly OT, but: while you're at it, check OpenBSD -
    http://www.openbsd.org - out, it is a very fine OS
    for desktop and server.

    Ok, now to your topic: for upgrading the Slowlaris
    boxen (for the Windoze it is possible, too, only
    the transfer way differs), first get some boot disc
    thingy of your new OS, whether it be GNU/Linux or
    BSD. Then you get that boot image, which preferably
    consists of a kernel, an initrd (for OpenBSD it's
    integrated into the kernel file) and a loader.
    Modify the initrd so it automatically gets IP
    address from DHCP, makes partitions, filesystems
    and untars some archive get over the network to
    the target root filesystem.
    Then prepare the archive, i.e. a complete install,
    and put it to the server.
    Put the initrd+kernel and loader somewhere to the
    hard disc where the next boot can find it, e.g.
    another partition, something available to GRUB,
    be improvisating. You'll find a way.
    For DOS, there is LoadLin.

    Then modify the next boot to load the new OS' loader
    instead of the old, or put a
    loadlin linux initrd=initdisk.gz
    in the autoexec.bat of the DOS boxen.
    Then reset the machine. All of this can be done
    remotely.

    The next boot should load the new OS, the initramdisc,
    partition the hard discs, make filesystems and popu-
    larize them. Then reboot, and voilá you got it.
  • I talked to some of these folks at LinuxWorld Expo, and it looked like they had things working. Somebody was even selling NICs and boot PROMs. They would be the logical starting point.

    Unfortunately, I don't have my bag 'o swag with me here at work, or I might even be able to find the docs.

    Also look at the Linux Journal article on LinuxBIOS
    [linuxjournal.com]
    http://linuxjournal.com/article.php?sid=4888

    [ltsp.org]
    http://ltsp.org Linux Terminal Server Project who were using NetBoot, if I remember correctly.

    [sourceforge.net]
    http://sourceforge.net/projects/netboot/

    and not sure if you got the netboot howto
    [linuxdoc.org]
    http://www.linuxdoc.org/HOWTO/DisklessHOWTO.html
    (netboot is linux based, etherboot is bsd based)

  • Kickstart (Score:3, Informative)

    by OrcSlicer ( 6630 ) on Tuesday April 02, 2002 @04:11PM (#3272355)
    RedHat and Mandrake's answer to jumpstart (wonder how they came up with the name :-) ). You have 1 server dedicated to being the jumpstart server, and then boot each machine off a specially made floppy. You can do multiple machines at once. The machines can be set to boot off dhcp after that, and you ssh in and tweak things out. You can set them with a static, but then the floppy has to be customized for each static address, which is a pain, and relatively or you can set them with a static, but then the floppy has to be customized for each static address, which is a pain, and relatively pointless for a mass installation

    I'm not sure if the machines can get an IP address through dhcp while loading packages, which would mean the floppies couldn't be clones of each other, but clones minorly modified. I think they can get from dhcp while loading, but I'm not certain.

    I've loaded 20 machines in one day using this.

    We never had them reboot automatically, because we needed to eject the floppies, but if you make CD images, you can probably figure a way to eject them and then they will load off the HD correctly on the reboot.

    You can also use the same jumpstart server with floppies customized for different machines if you have clusters of machines with different baseline package sets.

    Drawbacks: It works over nfs (not sure if there are other delivery methods), which you would want to firewal off at the router.

    Random nice things: you can put the passwd files on the floppy, which is more secure than having `them fly across the netowrk, methinks. It does mean you need to take care with the floppies, however.

    Rob
    • I've done this. You can boot strap the entire thing from a floppy or bootable CD, or PXE (net booting). You can have the floppy read it's configuration from the server (http), so if the servers smart enough it can hand out different config files for different machines. The machines can DHCP themselves addresses. This can work over NFS or HTTP (we do it over HTTP). It's dead simple, install a redhat machine the "usual" way, then cp the "~root/anaconda.ks" file onto a webserver, then boot a machine up and type "linux ks=http://url/to/anaconda.ks" and viola, you have one clone. It's trivial to hard code this into a bootable floppy (like we did) or to have this done entirely over PXE. It's fast too, you can have a machine installed in under 10 minutes.
  • One of the many negative experiences that soured me on ever using Linux for 'real work' was trying to network boot a SparcStation LX a couple of years ago.

    I had the process working perfectly with SunOS and NetBSD, but Debian was rumored to have the best support for the dBRI audio chipset...

    I tried Debian, I tried RedHat, I read the HOWTOs and FAQ files, but Linux just would not work with network booting a Sparc and mounting a NFS root. There's been orders of magnitude more effort put into NetBSD's netboot support, to the point that I have better luck booting Linux from the 64K NetBSD tftp bootloader than the Linux method of tftp'ing a 1.6M kernel.

    Eventually, I give up, and go back to NetBSD for these LX boxes. They boot, use NFS for root, and even swap to a file mounted on NFS. Works like a charm, boots fast and reliably, they just can't play music.

  • In '99 I started using the procedure below. This works really well if you need to support hardware that might vary from box to box. If you know you will be using the exact same hardware for every box, you might as well use dd or some drive imaging package.

    1) Figure out what you want your final image to look like, set up a test system, and configure it fully. Make note of all config files that you changed and all packages you have installed.
    2) Create an RPM containing all the config files you modified.
    3) copy RedHat CD 1 to the hard drive of an FTP server
    4) copy all CD 2 RPMS to the RPMS directory that was created when you copied the first CD
    5) replace all outdated RPMS with the update versions, and put the RPM you created in step 2 into this directory.
    6) install anaconda on the FTP server & run the genhdlist script.
    7) create a kickstart config file listing all the packages you want to install, including the RPM you created in step 2, and specifying the address of the FTP server.
    8) make as many boot disks with the above kickstart config file as machines you want to install at once.
    9) plug in as many machines at once as your network can handle, put a copy of the floppy in each, turn them on.
    10) go get some coffee while the install completes.
    11) yank the floppies and reboot the boxes. Your drives are partitioned, all packages installed, and all software configured. Proceed to the next batch of machines. I'm pretty sure there's a way to do this from a network-boot setup and just put the kickstart file on the FTP server, but it seemed to me like more hassle than it was worth given how easy it is to use floppies.
  • Check out PC Weasel [realweasel.com]. It's a VGA/MDA emulator board that adds a remote-control serial port, just like Alphaservers and other serious server boxen. You just throw this thing into a spare ISA or PCI slot and use your favorite terminal software to talk to it on the serial port. I've worked with them in the past and they work great, no quirks whatsoever.
  • Compaq has some nice offerings. I'm working with their blade servers which, because of stringent space requirement are very difficult to do a traditional installation. as a token url, here's a link [compaq.com] to some info on the subject from compaq. as a side note, compaq's blade aren't the most flexible in the world, but they look from a price/manageability perspective.
  • Depending on network equpiment you may beable to build some images that you send out via tftp at boot time that would do the trick. you just have to push the net boot button at the machine at boot time.

    I use tftp with ghost floppy images that automaticaly start the ghosting of machines at work all the time it works great. i just turn the box on wait a sec and hit n. walk away for 20 min and reboot and take care of ghostwalk stuff..
  • Regardless of how insulting this must sound: it seems as though you ask this question from the perspective of an NT administrator. It doesn't sound like you know what you want, just that you want it to be very, very simple, regardless of cost. In that case, hire a couple of college interns to install it for you.

    If, instead, you are willing to put in a certain amount of effort to reap the benefits in a large-scale installation, a week spent hacking RedHat's installer or writing your own scripts would be well spent. To get you started in the right direction: install linux on a computer, dd if=/dev/hda of=/nfs_mount_on_server/linux.image, reverse if and of to install on next computer, repeat. Better yet, install a small version of Linux on a partrition on each computer that simply updates the hard drive image from the server. Boot to that version of Linux whenever you need to upgrade.

    In Linux, there is no "pre-packaged" plug-and-play solution for ANYTHING, but EVERYTHING can be made to do exactly what you want. From what I hear, Norton Ghost works on Linux partitions, too.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close