[email protected]
I was first prompted to write this document after reading a request for such a document on the LDP suggestions page. I realised that this was within my area of expertise and approached the LDP about creating a new HOWTO document for the project. I took the LDP standard template and have modified that in order to come up with the structure of this document. Using both the template and a few SGML references, I have written the SGML source, that I have since found to be a particularly convenient type for converting into many different document formats.
About the author - I started working with Linux 2 years ago (at the time of writing) when I joined IBM ® in a Linux support role. I started IBM with no previous administration experience and learned my skills on the job. A year after I joined I was certified as a Redhat Expert (RHCE). During my second year I implemented a Linux network install server that I am still managing and from which I hope to draw my knowledge to write this document.
(C) Copyright IBM Corp. 2002.
This document is provided "AS IS," with no express or implied warranties. Use the information in this document at your own risk.
The following terms are registered trademarks of International Business Machines corporation in the United States and/or other countries: IBM. A full list of U.S. trademarks owned by IBM may be found at http://www.ibm.com/legal/copytrade.shtml.
Linux is a trademark of Linus Torvalds
Other company, produce, and service names may be trademarks or service marks of others.
Naming of particular products or brands should not be seen as endorsements.
This document may be reproduced or distributed in any form without prior permission provided the copyright notice is retained on all copies. Modified versions of this document may be freely distributed provided that they are cloearly identified as such, and this copyright is included intact.
You are strongly recommended to take a backup of your system before major installation, and backups at regular intervals.
I am always open to putting more names in this section so if you want to get in here then please send me feedback or write your own section for a different Linux ® distribution that is not included yet.
Thanks to my proof readers of version 0.9:
- Adrian Fewings
- Beth Carey
- Paul Milner
Currently this document is only available in English. If you would like to be a translator for it then please mail me.
You can always find the latest copy of this document at the Linux Documentation Project homepage.
V. | DATE | CHANGE |
0.1 | 27th July 2002 | Started writing the first draft |
Wrote the Introduction Section. | ||
0.2 | 2nd August 2002 | Finalised the document structure. |
Written the SuSE Server Setup. | ||
0.3 | 20th August 2002 | Tidied up source to work better with PDF docs |
Written SuSE Client Install | ||
0.4 | 21st August 2002 | Written Redhat Server Setup |
0.5 | 22nd August 2002 | Written Redhat Client Install |
0.6 | 23rd August 2002 | Written Debian Server Setup |
0.7 | 30th August 2002 | Written Debian Client Install |
0.8 | 1st September 2002 | Written Quick Install Section |
0.9 | 2nd September 2002 | Written Structure Section & Tidied up loose ends |
1.0 | 12th September 2002 | Proof read and made refinements |
Submit to the LDP | ||
This document is split up into various sections that are designed to make it easy to read and learn from. There are major sections that allow the reader to skip to parts of the HOWTO that will be relevant for them. The entire document is not designed to be relevant to every reader and you may wish to skip out entire major sections of it. Each major section will consist of a set of subsections, so if you think a major section is relevant to what you are reading this HOWTO for then please read ALL the subsections.
This HOWTO covers different distributions of Linux and I try to be generic across different versions of a particular distribution. It contains two basic high-level structures to it for each distribution that it contains, these are (a) sections on setting up Linux install server server machines, and (b) sections on setting up clients using an install server. In addition to these two types of main section there are also a few other sections that are designed for reference purposes to other documents, and how to use this document.
This is a rough list of points that you will need to follow in order to setup a Linux machine as a network install server. The HOWTO sections on setting up servers roughly adhere to this list:
This is a rough list of points that you will need to follow in order to install a Linux distribution from a network install server. The HOWTO sections on installing client machines roughly adhere to this list:
Although this is not the biggest reference guide in the world you can still help yourself for quicker reading by following the guidelines below. I have tried to write the HOWTO in such a way that it will be useful to all skill levels in Linux.
(aka the elite). If you are familiar with Linux as well as installation over networks then you will probably be able to do most of your setup using the quick guide section, you will also find some useful references in the appendices for further reading purposes. For distribution specific details of a network install then you should be able to reference the appropriate subsection.
(aka competent). If you are familiar with Linux but new to network installations then you should be able to make good use of the various distribution independent sections. Read carefully through the sections that you think are relevant for your purposes but you should be able to skip through the commands quite easily. You will also find good references in the appendices for further reading.
(mostly harmless). You will find some excellent installation references listed in the appendices that I would thoroughly recommend reading before attempting network installations. Make sure you are completely happy with a basic non-network Linux installation before you attempt networked installs. Once you think you are ready then read very thoroughly through the sections for the distribution you are interested in and make sure you read the non-distribution specific sections carefully too. You should find the command references in this HOWTO very helpful.
This chapter gives some overview information about installing Linux over a network. All examples and information here can be considered generic between different Linux distributions. If you want more specific information for a particular distribution then please read one of the following relevant chapters.
The following is a list of advantages and disadvantages of installing Linux over a network and the automatic installation features available with many distributions of Linux. The list is in no specific order:
This section briefly compares the differences between automatic (or unattended) installations with the more common manual installations available. This should give you a good idea of which system is right for your usage.
Automated or unattended installation is probably less used and less well known for installing systems than manual installation. This instantly gives rise to the challenges of trying to educate people about what it is and how to use it. Once you understand the basics of networked installation then automatic installation is a natural next step to take when installing and configuring your systems.
Automatic installation has the major drawback of a longer setup period required at the start of your process. This is to set up the install server (which you need to do for any network install environment) but you must also make up one or more configuration files for your install client to read. It is this setup time and slight added complexity that you must weigh up before deciding whether to do manual or automatic installations. Basically, as a rule of thumb, the more machines you have to install, the more time will be saved by using automatic installation techniques.
Automated installations are very easy to perform once you have the initial setup completed. You boot your client system in any way shape or form you like (usually by floppy disk) but you also provide access to your configuration file to the client at install time (usually either on the floppy disk or over the network connection). The configuration file contains all the required information that your client will need for installation, from what mouse/keyboard to use right through to the packages that you want installed on your system.
Another large bonus point of using the automated installation techniques is that most Linux distributions also provide means to add customised packages to the system at install time. This means that you can install packages that are not provided by the particular Linux distribution you are installing. There are normally also further configuration steps available such as the ability to write scripts for your installation that will get performed before, during, or after the install is complete. This all adds up to providing much faster installation of a complete system that is already setup in a customised way for your particular environment.
This is the method of Operating System (OS) installation that most people are used to. Commonly we install our base OS using CDROM disks and boot from CDROM or floppy disk before proceeding through a program of menus that allow us to customise certain options. This is probably the greatest benefit of Manual Installation i.e. most people are familiar with the process. However, it can bring other benefits too such as a quick/easy/simple installation and this method of installation is used more (therefore tested more) than other methods of installation so it might just be more reliable too.
The problems with manual installation come when you update your system very regularly, you are installing a large number of systems, or you want to have a particularly customised setup. Manual installation will not allow you to add extra programs to your OS at install time, you will have to install the OS then boot it before configuring the programs you want in the way that you would like. Also, this method can be quite time consuming if you are installing lots of systems, particularly if you only have a few sets of CDs.
Manual installation can still be done using a networked install environment. You can do this on any compatible OS that allows you to boot your client machine ready for installation before loading your network drivers and contacting your install server. All the data that would otherwise have been copied from CD images is now sent over the network instead.
You do not require any special hardware in order to install Linux over a network in either manual or automated mode. The basic requirements are:
Some examples where you might require specific hardware may be if you have a specialised network or if you need to attach more storage to your server, for example. In the example of attaching storage to your server, it does not matter in any way to the installation process where the install image is held, it can be on a local hard disk, in a RAID array, on a distributed filesystem or anywhere that the server machine can access reliably and quickly.
It goes without saying that if you don't have a network or your network is unreliable or slow then do not attempt network installations as they may fail or take a very long time to complete.
You will require a basic understanding of some of the services that run on a Linux based machine in order to setup your install server. These are services that make your install image available over your local network to the client machines that you want to install. In addition you will also need basic Linux administration skills in order to set up and maintain your server well.
Most Linux distributions have a network installation method that makes use of between one and three methods of transferring data cross a network. These services may or may not have an impact on the installation you are going to perform at the client end. The differences between the services will depend on the Linux distribution you are installing and any distinctions that this distribution makes between these services.
The three data transfer services are NFS (Network Filesystem), HTTP (Hypertext Transfer Protocol) and FTP (File Transfer Protocol). Each of these services is slightly different in the way that it operates, the function that it is designed for, and the way that you administrate it. Basic guidance is provided throughout this HOWTO about what these differences are but you are recommended to familiarise yourself with each of them so that you can manage your system responsibly and make informed choices about the services that you run.
This section gives a brief run down of setting up an install server for a 'general' Linux distribution. The terms and theory here are as general to all Linux distributions as they can be and are designed specifically to give you a very quick overview of what network installations involve. If you want to perform network installations on your own machines then you are advised to read the relevant sections of this HOWTO in full. If the HOWTO does not contain a section for the distribution that you want to install then you can either change the distribution you are installing over the network to match the HOWTO or use the following as a very rough guide on how to do it.
This section explains how to set up your server machine to be an install server for a generic Linux distribution. For most distributions you can use any other distribution as the install server. For example, you can install Redhat over your network using a server installed with SuSE.
This guide starts from the point where you have a machine installed with Linux which is already up and running and connected to your network. If you require help with installing Linux on your server then please consult the Further Information section of this HOWTO in Appendix A.
In order to set up an install server you will need to put on all the required data that will be needed to perform a full installation of the Linux distribution you are going to serve. For example, if you are used to installing Linux using CDs then you will need space on your server to copy ALL the contents of each CD onto your server.
So, before you even think about setting up your machine as an install server, you must check that you have the required space available. This sounds like a trivial thing to check but it is very important and easily forgotten when you're setting up.
A guide for the amount of space that you will require will be the amount of space on your install media that you are intending to copy from later. This might be one of the following approximate examples:
You will need the appropriate amount of space available to your system on some local filesystem. It does not matter what form this takes, whether it's a RAID device, local disk (either SCSI or IDE), etc. Ensure that the space you intend to use is formatted with your chosen filesystem and is mounted.
You can check this space with the command:
df -h
If this output shows you have enough space to copy your install media then great, you can continue installation. If not then it's time to think about an upgrade to your intended server machine!
Once you know you have enough space available it's time to start copying your install media to your chosen filesystem and directory. This might involve copying the entire contents of all your CDs to one install directory on your server or copying the data over the network by some method, etc.
Time to make your install data available to other machines on the network. Most distributions allow installation over the network using NFS, HTTP and FTP protocols. You can select which of these will be used at install time on the client. If one of the services is not setup on the machine then it will still be available for selection by the client but the install will not work. Therefore, it is either best to enable all three services on your server (so they all work on each client machine) or if you don't enable all three then advertise the fact very well and say which service should be used for your particular install server.
To install over NFS you need to meet certain conditions on the server:
To export your install directory edit the /etc/exports
file and add an
entry for your installation target directory to it. If you are not sure about
exporting filesystems then see your man page for the exports file at
exports (5).
To install over FTP you need to allow FTP access to the directory that you have setup on the server as the installation directory. This can be either anonymous FTP access or access through a named account with a password. Anonymous access is probably best unless you have a reason to protect your install server via a password.
If you want anonymous FTP to point to a different directory then you can use sym links to point to the directory that you have set up as the install directory on the server. This will allow FTP into a chrooted environment but still give you access to the install images in a different location.
If you have a web server running and want to enable HTTP access to your install server then add sym links from your document root to the install server directory and this will grant access. If you are not familiar with web servers or are not comfortable with this approach then leave out HTTP access from your install server as it provides no benefits over NFS or FTP installs which may be simpler to set up.
If you do choose to use HTTP then basically all you have to do is make the install directory visible to your web server by making it appear under the document root by some means.
You have now completed the basic setup of your install server. Different distributions will grant you different options for further customisation techniques of the installation process. The most commonly found customisation is the option to install packages that do not come as standard with the distribution you are installing. However, there may be further customisations you want to do on your particular server or that are available for your particular Linux distribution.
This section gives a brief run down of setting up a client machine using your install server. The terms and theory here are as general to all Linux distributions as I can be and are designed specifically to give you a very quick overview of what network installations involve. If you want to perform network installations on your own machines then you are advised to read the relevant sections of this HOWTO in full. If the HOWTO does not contain a section for the distribution that you want to install then you can either change the distribution you are installing over the network to match the HOWTO or use the following as a very rough guide on how to do it.
You only need to read/follow this section if you are intending to use an automated install process, if you intend to do a manual installation over your network then skip this section. Here we go through the process of creating configuration files that the installer will read in order to create the configuration of our client machines we are installing during an unattended network installation.
In order to start creating your config files you will need to install the relevant config file editor. Each distribution that is capable of installing in unattended mode over the network will provide some means of editing config files. Make sure you have these installed on some Linux machine that will allow you to create and save all the different configurations you might want to install on your network.
Once you have confirmed that you have the configuration program package installed, you can start to create configuration files. For most situations the basic configuration described here will be sufficient to perform your installations.
Start the configuration program that you have on your system. In most cases, you will now be presented with a window that allows you to configure most of your installation options as if you were installing a new machine or performing an upgrade. You can proceed through each menu, configuring your options for a particular system or set of similar systems that you wish to automatically install.
Once you have progressed through each configuration screen, you are ready to save out your configuration file to disk. Click the save button and choose a location on your system to store configuration files. If you are creating lots of different configurations then it might be worthwhile creating your own configuration repository - don't forget to name the files sensibly so you know which is which.
Before attempting advanced configuration please make sure that you have first created a valid basic configuration file as described above. It is perfectly possible to create your own configuration files from scratch but it is far easier to use the tools provided to do the job for you!
Once you have your configuration file saved, you can open it in your favourite text editor. You can use or modify any of the existing tags in your file, just so long as the tags, options, and syntax you use are legal. Once you have edited the file manually then save it back out in text format again. The best use of editing the configuration file manually is probably for adding your own customised packages to the installation.
The most common method of booting a client ready for installation over a network is to use a floppy disk.
dd if=your-file.img of=/dev/fd0
Don't forget that some distributions will allow you to boot from other media as well as floppy images to perform network installations. Also, each distribution normally has a set of extra boot options that you can use if the above method does not work on your hardware. These extra configuration options are normally for less common hardware but are provided to make sure you can perform network installs.
This section explains how to set up your server machine to be an install server for SuSE Linux. You can set up any Linux distribution to be a SuSE Linux install server, this machine does not necessarily have to be running SuSE Linux itself.
This guide starts from the point where you have a machine installed with Linux which is already up and running and connected to your network. If you require help with installing Linux on your server then please consult the Further Information section of this HOWTO in Appendix A.
In order for your server to act as a SuSE Network Install server you will need to put on all the required data that will be needed to perform a full installation of the SuSE version you are serving. For example, if you are used to installing SuSE using CDs then you will need space on your server to copy ALL the contents of each CD onto your server.
So, before you even think about setting up your machine as an install server, you must check that you have the required space available. This sounds like a trivial thing to check but it is very important and easily forgotten when you're setting up.
A guide for the amount of space that you will require will be the amount or space of install media that you are intending to copy from later. This might be one of the following examples:
You will need the appropriate amount of space available to your system on some local filesystem. It does not matter what form this takes, whether it's a RAID device, local disk (either SCSI or IDE), etc. Ensure that the space you intend to use is formatted with your chosen filesystem and is mounted.
You can check this space with the command:
df -h
If this output shows you have enough space to copy your install media then great, you can continue installation. If not then it's time to think about an upgrade to your intended server machine!
Once you know you have enough space available it's time to start copying your install media to your chosen filesystem and directory. For the purposes of this HOWTO we will use the following example to represent the directory from which our install server will be setup and running:
/install
Copy your install media to /install
. The following example shows you how to do
this for copying your SuSE CD images to /install
:
mount /mnt/cdrom
cp -av /mnt/cdrom /install
umount /mnt/cdrom
/install
Now you should have all you need in /install
but if you have copied
from CD then as far as SuSE is concerned the /install
directory still
represents a set of CD images that you have copied. You need to change this
such that the set of CD images appears as a single installation medium. Use
the following Perl command to do this:
perl -pi -e 's/InstPath:\t\d+/InstPath:\t01/' /install/suse/setup/descr/common.pkd
Time to make your install data available to other machines on the network.
SuSE is best installed over the network using NFS since support for the HTTP and FTP protocols is not necessarily supported during installation, even though later system updates may be applied over HTTP or FTP.
To install over NFS you need to meet certain conditions on the server:
To export your install directory edit the /etc/exports
file and add an
entry for /install
to it. In our example, we would use the folowing
line:
/install *(ro)When you have saved your exports file you must then get your NFS daemon to read its configuration file again in order to export the directory you just added. Do this by running the command:
exportfs -rThis gives us the most simple read-only export to all hosts on our network. If you want to include more advanced options in your export e.g. only exporting to certain hosts on the network or a certain subnet, etc then see your man page for the exports file at exports (5).
You have now completed the basic setup of your install server.
You can, if you wish, add your own packages to the SuSE distribution so that they are installed along with SuSE over the network when you install your clients. The advantage of this is that you don't have to spend time configuring each machine for packages that you may want installed that are not included with SuSE. Examples of this might be your own RPM packages that you have created or some specialised package.
Simply copy your RPM package files into the following directory
/install/suse/customNOTE: you may need to create this directory if it does not exist
Your custom RPM packages should now be available to the clients.
You should have already decided by now using the Quick Guide section of this HOWTO whether you are going to install your machine using the automated process or a manual process. The automated process under SuSE is known as AutoYaST and in short provides you with a configuration file for the machine that you are going to install so that you can perform unattended installs of client machines.
You only need to read/follow this section if you are intending to use an automated install process, if you intend to do a manual installation over your network then skip this section. Here we go through the process of creating configuration files that the installer will read in order to create the configuration of our client machine we are installing during an unattended network installation.
In order to start creating your config files you will need to install the AutoYaST module for YaST2 on your SuSE machine. You will need three RPMs for this, all of which are on your SuSE source media e.g. CDs. The three RPMs are:
Check to see if you already have them installed with the command:
rpm -q {rpm package name}
If these packages are not installed then install with the command:
rpm -Uvh {rpm package name}
Once you have confirmed that you have the AutoYaST packages installed on your system, you can now start to create configuration files. For most situations the basic configuration described here will be sufficient to perform your installations.
Start the YaST2 Autoinstall configuration GUI with the command:
yast2 autoyast
You will now be presented with a window that allows you to configure most of your installation options as if you were installing a new machine or performing an upgrade. You can proceed through the menu system configuring your options for a particular system or set of similar systems that you wish to automatically install. Alternatively, you can create class definitions which allows you to save different parts of the configuration setup and then use different classes for different sets of machines.
The use of classes is particularly good when you have a set of systems that are similar but that you would like installed in slightly different ways. For example, you could create a class definition for the hardware setup of all your client machines and create a separate class for the packages you want installed on them, whether they are server machines, test machines, workstations, etc. You can then choose which classes are used by which machines when they are installed. In our example here, all the machines would use the same hardware setup, but the workstation machines could install our workstation class of packages, test machines the test class, etc.
Once you have progressed through each configuration screen in the config setup GUI from YaST2 you are ready to save out your configuration file to disk. NOTE: it is outside the boundaries of this document to take you through each configuration option for installation, we are just concerned with the principles of network installs here. Please consult your SuSE documentation or the SuSE Website for this information.
When you save your configuration files they will be stored locally in two different locations depending on what file you have created as follows:
/var/lib/autoinstall/repository
/var/lib/autoinstall/classes
Before attempting advanced configuration please make sure that you have first created a valid basic configuration file as described above. It is perfectly possible to create your own configuration files from scratch but it is far easier to use the tools provided to do the job for you!
Once you have your configuration file saved, you can open it in your favourite text editor. The file is in XML format so it is particularly easy to follow and edit manually. You can use or modify any of the existing tags in your file, just so long as the tags, options, and syntax you use are legal. A full guide to the tags and their usage can be found in the AutoYaST manual, please see Appendix A of this guide for a reference.
The best use of editing the configuration file manually is probably for adding your own customised packages to the installation. Back in the SuSE Server Setup section we describe how to add your own customised packages to your install server. Here, we describe how to access those packages using the configuration file so they can be automatically installed with the rest of the system.
You should be able to locate a <software>
section in your basic
configuration file in your editor. You can use a sub-tag inside the software
section called the <extra_packages>
tag which can be used as in
the following example:
<software> <extra_packages> <package_location> custom </package_location> <packages config:type="list"> <package>{Your package name}</package> <package>{Another Package}</package> </packages> <extra_packages> <base>Default<base> <software>
The package location is written as custom
which describes the directory
under the suse
directory of you install server where you have put your
custom packages, in our example this would be /install/suse/custom
,
but you only need to write custom
here.
You can include as many package
tags under the packages
section as you wish. Use one package
tag for each custom package you
want to include in your config file and install on the client machine.
The base
tag at the bottom should be left as you configured it during
the basic configuration.
Save your modified configuration file from your text editor and it will then be ready to use in your installations as described below.
There are different situations during a network installation boot of one of your client systems that might mean that you wish to boot in one of the ways below. NOTE: you only need use one of the methods described for the particular usage for which it has been described.
If you skipped over the section above about creating AutoYaST config files then this is the way in which you should boot your client machines.
If you followed the section above about creating AutoYaST config files then this is the way in which you should boot your client machines.
Insert and mount a floppy disk cp /var/lib/autoinstall/repository/Your-File /dev/fd0/autoinst.xml Unmount the floppy disk
linux autoyast=floppy
This is an extension to the technique used to boot client machines for Automatic Installations as described above. You should try this method if you have tried and failed with the method above. This section should help you if you have had network connection problems during boot, for example, if you do not have a DHCP server on your network.
You can create what we call an "info" file to hold information about your clients network details. This can then be used more explicitly by the install process to contact your network. This is a plain text file in which you put certain keyword and value combinations that are recognised by the installer.
The list of keywords you can use is as follows:
Using the above keywords in an example info file, you might end up with something looking a little bit like this:
install: nfs://10.0.0.100/install/SuSE8.0 netdevice: eth0 server: 10.0.0.100 serverdir: /install/SuSE8.0 ip: 10.0.0.200 netmask: 255.0.0.0 gateway: 10.0.0.1 nameserver: 10.0.0.2 autoyast: floppy
Substitute the IP addresses above for relevant ones for your particular network
and save this file with filename info
in the root directory of your
floppy disk that contains your configuration file autoinst.xml
This section explains how to set up your server machine to be an install server for Redhat Linux. You can set up any Linux distribution to be a Redhat install server, this machine does not necessarily have to be running Redhat.
This guide starts from the point where you have a machine installed with Linux which is already up and running and connected to your network. If you require help with installing Linux on your server then please consult the Further Information section of this HOWTO in Appendix A.
In order for your server to act as a Redhat network install server you will need to put on all the required data that will be needed to perform a full installation of the Redhat version you are serving. For example, if you are used to installing Redhat using CDs then you will need space on your server to copy ALL the contents of each CD onto your server.
So, before you even think about setting up your machine as an install server, you must check that you have the required space available. This sounds like a trivial thing to check but it is very important and easily forgotten when you're setting up.
A guide for the amount of space that you will require will be the amount or space of install media that you are intending to copy from later. This might be one of the following examples:
You will need the appropriate amount of space available to your system on some local filesystem. It does not matter what form this takes, whether it's a RAID device, local disk (either SCSI or IDE), etc. Ensure that the space you intend to use is formatted with your chosen filesystem and is mounted.
You can check this space with the command:
df -h
If this output shows you have enough space to copy your install media then great, you can continue installation. If not then it's time to think about an upgrade to your intended server machine!
Once you know you have enough space available it's time to start copying your install media to your chosen filesystem and directory. For the purposes of this HOWTO we will use the following example to represent the directory from which our install server will be setup and running:
/install
Copy your install media to /install
. The following example shows you how to do
this for copying your Redhat CD images to /install
:
mount /mnt/cdrom
cp -av /mnt/cdrom /install
umount /mnt/cdrom
Time to make your install data available to other machines on the network. Redhat can be installed over the network using NFS, HTTP and FTP protocols. You can select which of these will be used at install time on the client. If one of the services is not setup on the machine then it will still be available for selection by the client but the install will not work. Therefore, it is either best to enable all three services on your server (so they all work on each client machine) or if you don't enable all three then advertise the fact very well and say which service should be used for your particular install server.
The NFS protocol is the only one which will work with the graphical install method of Redhat when installing your client machine. Therefore, if you want to do graphical (as opposed to text based) installations then you must enable this service on your server.
To install over NFS you need to meet certain conditions on the server:
To export your install directory edit the /etc/exports
file and add an
entry for /install
to it. In our example, we would use the folowing
line:
/install *(ro)When you have saved your exports file you must then get your NFS daemon to read its configuration file again in order to export the directory you just added. Do this by running the command:
exportfs -rThis gives us the most simple read-only export to all hosts on our network. If you want to include more advanced options in your export e.g. only exporting to certain hosts on the network or a certain subnet, etc then see your man page for the exports file at exports (5).
The FTP protocol will only allow text installs to be performed by your clients. This may or may not be ideal for your situation but bear it in mind.
To install over FTP you need to allow FTP access to the directory that you have setup on the server as the installation directory. This can be either anonymous FTP access or access through a named account with a password. Anonymous access is probably best unless you have a reason to protect your install server via a password.
If you want anonymous FTP to point to a different directory then you can use sym links to point to the directory that you have set up as the install directory on the server. This will allow FTP into a chrooted environment but still give you access to the install images in a different location.
Similarly to the FTP protocol, HTTP will only allow text installs on the client side. If you have a web server running and want to enable HTTP access to your install server then add sym links from your document root to the install server directory and this will grant access. If you are not familiar with web servers or are not comfortable with this approach then leave out HTTP access from your install server as it provides no benefits over NFS or FTP installs which may be simpler to set up.
If you do choose to use HTTP then basically all you have to do is make the install directory visible to your web server by making it appear under the document root by some means.
You have now completed the basic setup of your install server.
You can, if you wish, add your own packages to the Redhat distribution so that they are installed along with Redhat over the network when you install your clients. The advantage of this is that you don't have to spend time configuring each machine for packages that you may want installed that are not included with Redhat. Examples of this might be your own RPM packages that you have created or some specialised package.
Make sure you have the anaconda-runtime
package installed on your
server. This is normally installed if you're running Redhat but if you have
another distribution on the server then you should be able to install the
Redhat RPM without too much trouble. To check if you have the correct
package enter the command
rpm -q anaconda-runtimeIf the name of the package is returned then you have it installed, if nothing is returned the install the RPM as required.
Now simply copy your RPM package files into the following directory
/install/Redhat/RPMSThis is the directory that should already contain all the Redhat standard RPMS for the Redhat version you have setup on your install server.
Once you have copied your custom RPMS you need to regenerate Redhat's list of packages that it can install. Do this using the following command:
/usr/lib/anaconda-runtime/genhdlist /installThe directory used here of
/install
is the example directory we have
been using so far. Replace this with the directory where you copied the Redhat
CD images to. The directory should be the base directory of the Redhat CD set
i.e. the one that contains a subdirectory called Redhat
before the
directory called RPMS
Your custom RPM packages should now be available to the clients.
In addition to adding your own RPMS to Redhat you can also create RPM groups for the installation process. These will be similar to the standard groups offered by the Redhat install already such as the "Software Development" group which will install all packages for this purpose onto your system.
This allows quick installation of many RPMS for a specific purpose on your systems and the groups will become available like the normal Redhat groups (and are used in the same way) upon installation of the client.
To create your own groups you must edit a text file called the comps
file. In our example, this is located at:
/install/Redhat/base/comps
Copy the syntax for the groups that are already in the file and you can create
your own groupings. These can include both packages from the standard Redhat
install or any custom packages that you might have already added i.e. you can
include any package in the RPMS
directory.
Once you have edited the file then save it back out over the original (it might
be an idea to take a backup of the original but it will always be on your CD
images anyway if you need it). You must now run the genhdlist
command
again as explained above.
You should have already decided by now using the Quick Guide section of this HOWTO whether you are going to install your machine using the automated process or a manual process. The automated process under Redhat is known as Kickstart and in short provides you with a configuration file for the machine that you are going to install so that you can perform unattended installs of client machines.
You only need to read/follow this section if you are intending to use an automated install process, if you intend to do a manual installation over your network then skip this section. Here we go through the process of creating configuration files that the installer will read in order to create the configuration of our client machine we are installing during an unattended network installation.
In order to start creating your config files you will need to install the Kickstart Configurator on your Linux machine. You will need one of two RPMS for this depending on the version of Redhat you are using. These RPMS are available on your Redhat install CDs as follows:
redhat-config-kickstart
- for versions 8.x and aboveksconfig
- for earlier versionsCheck to see if you already have them installed with the command:
rpm -q {rpm package name}
If these packages are not installed then install with the command:
rpm -Uvh {rpm package name}
Once you have confirmed that you have the configurator packages installed, you can now start to create configuration files. For most situations the basic configuration described here will be sufficient to perform your installations.
Start the Kickstart configuration program that you have on your system. This
will be done with the command redhad-config-kickstart
for Redhat 8.x
systems and above (or if you have the redhat-config-kickstart RPM installed),
or the command ksconfig
for other Redhat systems (or if you have the
ksconfig RPM installed).
You will now be presented with a window that allows you to configure most of your installation options as if you were installing a new machine or performing an upgrade. You can proceed through each menu, configuring your options for a particular system or set of similar systems that you wish to automatically install.
Once you have progressed through each configuration screen, you are ready to
save out your configuration file to disk. NOTE: it is outside the
boundaries of this document to take you through each configuration option for
installation, we are just concerned with the principles of network installs
here. Please consult your Redhat documentation or
the
Redhat Website for this
information. Click the "save
" button and choose a location on
your system to store configuration files. If you are creating lots of different
configurations then it might be worthwhile creating your own configuration
repository - don't forget to name the files sensibly so you know which is which.
Before attempting advanced configuration please make sure that you have first created a valid basic configuration file as described above. It is perfectly possible to create your own configuration files from scratch but it is far easier to use the tools provided to do the job for you!
Once you have your configuration file saved, you can open it in your favourite text editor. You can use or modify any of the existing tags in your file, just so long as the tags, options, and syntax you use are legal. Once you have edited the file manually then save it back out in text format again.
The best use of editing the configuration file manually is probably for adding your own customised packages to the installation. Back in the Redhat Server Setup section we describe how to add your own customised packages to your install server. Here, we describe how to access those packages using the configuration file so they can be automatically installed with the rest of the system.
You should be able to locate a packages
section in your basic
configuration file in your editor. You can add extra packages by name as you
require to the end of this list of packages. Follow the format of the other
packages that you have listed in the file already from the basic configuration.
Packages that start with @
are package group names. You can use any
of the default Redhat package groups or you can use any custom groups you may
have created.
You can add as many packages and groups under the packages
section as
you wish. Just put one package on each line and follow the format already
provided.
Save your modified configuration file from your text editor and it will then be ready to use in your installations as described below.
It is simplest to use a floppy disk to boot your clients ready for installation. Everything you need is provided for you on the Redhat CDs as follows:
images/bootnet.img
images
directory on the CD copy the image to
your floppy disk (make sure you have one inserted in the drive, but not
mounted) using the following command:
dd if=bootnet.img of=/dev/fd0
mount /mnt/floppy
ks.cfg
cp /path/to/file /mnt/floppy
umount /mnt/floppy
linux ks=floppy
This is an extension to the technique used to boot client machines for automatic installations as described above. You should try this method if you have tried and failed with the method above. This section should help you if you have had network connection problems during boot, for example, if you do not have a network card supported by the floppy boot disk.
You can create a second floppy disk to use in the boot process which contains extra drivers for network cards. This can then be read on boot and the drivers loaded for your card from there instead. This is done as follows:
images
directory on your CD you should find a file called
drvnet.img
.images
directory on your CD, copy the file to a
different floppy disk with the command:
dd if=drvnet.img of=/dev/fd0Again, make sure your floppy disk is not mounted when you run this command.
dd
to your
command line.
linux dd ks=floppy
linux dd
YES
. Then swap
the boot disk for your driver disk and the extra drivers will load and detect
your network card.
This section explains how to set up your server machine to be an install server for Debian. You can set up any Linux distribution to be a Debian install server, this machine does not necessarily have to be running Debian. Don't forget that there are already plenty of Debian mirrors out there that provide free access to the Debian archive so unless you really need your own archive it might be best just to use one that already exists.
This guide starts from the point where you have a machine installed with Linux which is already up and running and connected to your network. If you require help with installing Linux on your server then please consult the Further Information section of this HOWTO in Appendix A.
In order for your server to act as a Debian network install server you will need to set up your machine to be a mirror of the Debian archives. Unlike most Linux distributions, Debian is commonly installed over the network, so you are not likely to have obtained a set of CD images containing Debian. A mirror system is provided that enables you to copy all the required data to your own server machine, for free.
Before you even think about setting up your machine as an install server, you must check that you have the required space available. This sounds like a trivial thing to check but it is very important and easily forgotten when you're setting up.
The entire Debian archives are roughly around 40Gb at the time of writing but if you are going to set up a full mirror then bear in mind that this will grow. It is possible for you to mirror only parts of the Debian archive and you can obviously mirror just the parts that you think you will require. For example, if you do not use a certain machine architecture then there may be little point in your mirroring this part of the archive.
The latest information about the size of the Debian archive is available from their website at http://www.debian.org/mirror/size.
You will need the appropriate amount of space available to your system on some local filesystem. It does not matter what form this takes, whether it's a RAID device, local disk (either SCSI or IDE), etc. Ensure that the space you intend to use is formatted with your chosen filesystem and is mounted.
You can check this space with the command:
df -h
If this output shows you have enough space then great, you can continue. If not then it's time to think about an upgrade to your intended server machine!
When you are confident that you have enough space for the data you want to mirror then you can move on to this step. If you are not sure you have enough space to mirror all the parts of the Debian archive that you want then you can always try this method, then if you run out of space, remove some parts of the archive from the mirror and try again.
Debian maintain their own guide on how to set up your own Debian mirror. You are welcome to view this at http://www.debian.org/mirror/ftpmirror. The list of steps below is based on the Debian instructions but is my own interpretation of them, designed to be easy to use and understand.
There are an awful lot of Debian sites out there that you could mirror from. It is best for you to choose one that is near your location or one that you know will have a good bandwidth to your location. Please remember, that if everybody uses the same sites for their own mirrors then things will get rather slow, so choose carefully.
A list of sites that you can choose to mirror from can be found at http://www.debian.org/misc/README.mirrors
I would recommend using a program called rsync
to copy the data from
your chosen server to your own server. This is a program that is ideally suited
to mirroring data from one system to another. If you want to find out more
information about rsync
itself then see the webpages or the man pages
for it.
Debian provide a well commented script at http://www.debian.org/mirror/anonftpsync that will perform the mirroring for you. Go to this site and download the script to your server machine, we will then need to set up the script to mirror the archive as you want it.
Now go through the entire script (it's not very long) and look at each line. Decide whether you want the line to be active in your script or not. If you don't know what a line does then it is probably best to leave it at it's default setting. However, you must set up the script with some minimal settings in order for it to work at all. These will include your chosen server, the location to put the archive on your machine, etc.
Once you have set up the script with all the required information requested in it then you are ready to run it and it will start copying data from the server you have chosen to your own server machine. Don't forget to change the permissions of the script so that it is executable and then run it from the command line.
The Debian archive is regularly updated and in order to maintain your own
archive and make sure it is up to date, you will need to periodically run the
script again to copy any changes made. NOTE: the script uses rsync which
is a one-way transaction, you can never copy from your machine to your chosen
server (as you don't have permission to do so!). It is probably best to
run the script daily, so you can edit your crontab to do this or put the script
in /etc/cron.d/cron.daily
if your Linux distribution has this set up.
Time to make your install data available to other machines on the network. Debian can be installed using NFS, HTTP and FTP protocols. You can select which of these will be used at install time on the client. If one of the services is not setup on the machine then it will still be available for selection by the client but the install will not work. Therefore, it is either best to enable all three services on your server (so they all work on each client machine) or if you don't enable all three then advertise the fact very well and say which service should be used for your particular install server.
To install over NFS you need to meet certain conditions on the server:
To export your install directory edit the /etc/exports
file and add an
entry for directory you have copied your Debian archive to. In our examples
throughout this HOWTO, we would use the folowing line:
/install *(ro)When you have saved your exports file you must then get your NFS daemon to read its configuration file again in order to export the directory you just added. Do this by running the command:
exportfs -rThis gives us the most simple read-only export to all hosts on our network. If you want to include more advanced options in your export e.g. only exporting to certain hosts on the network or a certain subnet, etc then see your man page for the exports file at exports (5).
To install over FTP you need to allow FTP access to the directory that you have setup on the server as the installation directory. This can be either anonymous FTP access or access through a named account with a password. Anonymous access is probably best unless you have a reason to protect your install server via a password.
If you want anonymous FTP to point to a different directory then you can use sym links to point to the directory that you have set up as the install directory on the server. This will allow FTP into a chrooted environment but still give you access to the install images in a different location.
If you have a web server running and want to enable HTTP access to your install server then add sym links from your document root to the install server directory and this will grant access. If you are not familiar with web servers or are not comfortable with this approach then leave out HTTP access from your install server as it provides no benefits over NFS or FTP installs which may be simpler to set up.
If you do choose to use HTTP then basically all you have to do is make the install directory visible to your web server by making it appear under the document root by some means. If you are using the Apache webserver then Debian recommend adding the following to your http.conf file
<directory /org/ftp.debian.org/ftp> IndexOptions NameWidth=* +SuppressDescription DirectoryIndex . </directory>
You have now completed the basic setup of your install server.
This version of the Network Install HOWTO does not include information about automatic installation of a Debian system, if this is what you need then please refer to the link in the Further Information section located in Appendix A. A later version of this HOWTO is likely to include details for this system.
There are many ways to boot your machine in order to install Debian, you can if you wish use a Debian CD 1 which contains all the floppy boot disks on one easy to use media to boot your system. However, it is more common to boot an install of Debian using floppy disks, these are provided by Debian on their mirror system.
Obtain the floppy boot images from your chosen mirror server from the directory
/debian/dists/stable/main/disks-hardware/current/images-1.44
where
disks-hardware
is the hardware type that you are going to install
Debian onto. Note that there are several different sets of floppy disk boot
images in this directory and you should be careful to choose one that is
suitable for your use. If you are not sure which to use then just use the ones
in the directory specified rather than any of it's subdirectories.
Copy each floppy disk image that you have downloaded from the server to a different floppy disk following the example below:
dd if=/path/to/image of=/dev/fd0
Do not mount the floppy disks when using this procedure to create floppy boot disks. Also, don't forget to check that the floppy disks you are going to use are (a) good floppy disks i.e. not broken, and (b) do not contain any data that you need as the entire disk will be overwritten with all data lost.
Once you have a set of boot disks you can boot your client system from them by inserting the first disk and turning on your system. You will be presented with a welcome screen with some instructions on which you should be able to press [ENTER] to continue the installation. A normal Debian installation can now take place, see the Further Information section for references to instructions on how to install Debian.
This page is an informal list of references in no particular order that I have found useful or that others have pointed out to me. If you have a suggested reference that is not listed here then please mail it to me and I will add it to the list.
These are intended as the primary starting points to get the background information as well as show you how to solve a specific problem.
These are the smaller free text relatives to the HOWTOs above.
There is a huge number of informative web pages out there and by their very nature they change quickly. I will attempt to keep the links below as valid as possible but they may become outdated.