What is the kickstart in linux

How Kickstart Works

What is Kickstart?

Due to the need for automated installation, Red Hat has created the kickstart installation method. With this method, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical Red Hat interactive Linux installation.

Kickstart files can be kept on single server system, and read by individual computers during the installation. The kickstart installation method is powerful enough that often a single kickstart file can be used to install Red Hat Linux on multiple machines, making it ideal for network and system administrators.

Kickstart lets you automate most of a Red Hat Linux installation, including:

• Language selection
• Network configuration
• Keyboard selection
• Boot loader installation (LILO)
• Disk partitioning
• Mouse Selection
• X Window System configuration

Kickstart installations can only be performed using a local CD-ROM, a local hard drive, or NFS installation methods. FTP and HTTP installations cannot be automated using kickstart mode. (Starting with RedHat 7.0 and higher, FTP and HTTP are now supported)

To use kickstart mode, you must first create a kickstart file (ks.cfg), and make it available to the Red Hat Linux installation program.

Where to put a KickStart File:

A KickStart file must be placed in one of two locations.

• On a network
• On a bootdisk

To do a network-based KickStart installation, you must have a BOOTP/DHCP server on your network, and it must include configuration information for the machine on which you are attempting to install Red Hat Linux. The BOOTP/DHCP server will be used to give the client its networking information as well as the location of the KickStart file.

To perform a diskette-based KickStart installation, the KickStart file must be named ks.cfg, and reside in the boot disk’s top-level directory. Note that the RedHat Linux boot disks are in MS-DOS format, making it easy to copy the KickStart file under Linux using the mcopy command.

In the case of the KickStart-Tools package the we have put together it was decited that we would go with locating the ks.cfg file on the floppy bootdisk.
Even if we put the ks.cfg on the network somewhere, the client would still need to use a boot floppy to load the kernel so that it can ask the nework for the ks.cfg file. Since we have to use a boot floppy anyway, we figured it would be alot easier to just put the ks.cfg file on the floppy and not worry about changing the BOOTP/DHCP servers at all. As of RedHat Linux 7.0 there is now support for booting over the network using PXIE. However many of our systems don’t support PXIE so we decided to still stay with the floppy bootdisk method.

The Bootdisk accomplishes several things. It contains the Linux kernel which is booted so that it can run the KickStart process.
It also contains a configuration files that is used to tell KickStart what to do.
By default the «Redhat» bootdisk will do a regular interactive install.

If at the boot prompt you specify: linux ks=floppy the installer will switch into KickStart mode and install linux using the configuration recorded in the ks.cfg file on the floppy.

To simplify the creation of the boot disk a cgi was put together so that it would ask the user the pertinent questions, then create the ks.cfg file for them, and then create a batch/shell script that can be used to create the boot floppy.

Specifically, the batch file or shell script will create a basic boot floppy and then copy across 3 files. They are: syslinux.cfg, boot.msg, and the ks.cfg.

• syslinux.cfg is the file that is read before the kernel loads. It is similar in functionality to lilo.conf. We have modified syslinux.cfg so that it runs linux ks=floppy by default if you press enter at the boot prompt. If you want to do a regular interactive install using the floppy then you can just type linux at the boot prompt.
• boot.msg contains the text that is displayed at the boot prompt.
• ks.cfg is the KickStart configuration file.

The kernel that is on the standard bootnet.img bootdisk image has been designed to work specifically for desktop PC’s. It will not work with notebooks that require PCMCIA services in order to get onto the network. for that you need to use pcmcia.img.
The various bootdisk images can be found the images directory on the RedHat installation CD.

The KickStart Server

Once the bootdisk lauches the kernel, it looks in the ks.cfg file to figure out where it is going to get it’s root file system.
This is specified in the NFS line in ks.cfg. For example, here is the default nfs line:

nfs --server KickStart.cisco.com --dir /export/ftp/pub/linux/redhat/linux/7.0/en/os/i386

It specify’s the NFS server as well as the NFS export to be mounted from that server.

The directory /export/ftp/pub/linux/redhat/linux/7.0/en/os/i386 contains the following files and directories.

RPMS/ Location of the RPMS that get installed during KickStart.
base/ Location of RPMS database and comps file.
i386 File used to identify this directory is for the i386 architecture.
instimage/ Location of the files that get mounted as the root file system during KickStart.

The above layout is taken from what you would see on a RedHat Linux 6.2 CD. Starting with Redhat Linux 7.1 there is no longer an instimage directory. The instimage directory is now located in a file which is kept in the base directory.

The NFS server must be exported to the world so that KickStarts that are using DHCP address’s (and therefore are not in the netgroup file) will be able to mount the share point. That is only if you are using netgroups to restrict access.

The end of the ks.cfg file contains a %post section. This is where the postinstall commands are kept.
If we put all the postinstall commands here, the ks.cfg file would become rather large and might not fit on the floppy disk anymore.

So instead we install an RPM during the KickStart and in the %post section of the ks.cfg file we run a script in the RPM and pass it various options. The RPM is called postinstall and contains all the various things we want done during the postinstall. The last thing that the postinstall script does is removes the postinstall package.

Making better use of kickstart

Being able to do kickstarts is OK, but there are a few problems.

1. You may not want all the RPMS that RedHat provides
2. You may want to add your own RPMS.
3. If you list all the specific rpms you want in the %packages section of the ks.cfg then the ks.cfg file won’t fit on boot floppy.
4. If you put complex postinstall commands in the ks.cfg file then the file might not fit on the boot floppy.
5. There are updates available for some packages. You don’t won’t to install old ones that would then need to be upgraded.

So, what if you could choose exactly the RPM’s that were available for Kickstart? What if you could choose the grouping of RPM’s? What if you could pull out old RPM’s and replace them with newer versions?

Well, all of this is possible if you know how the inside of kickstart works and how to edit the files that kickstart uses. To make that much easier we have created some tools that do all of that for you.

Let me explain a few things about how the inside of kickstart works so that you understand what these new tools are doing for you.

The first thing you may want to do is replace some RPM’s from the RPMS directory with your own versions or updated versions or whatever. So you cd into the RPMS directory that is described above. You remove a few RPM’s and add a few.
If you tried to Kickstart now, it would fail because Kickstart knows exactly which RPM’s are in the RPMS directory and expects specific versions of RPM’s to be there. It keeps track of all the RPM headers for each RPM in a file called hdlist in the base directory. Therefore, you need to generate a new hdlist. This is done by running a command that comes with anaconda-runtime called genhdlist . You also need to edit the comps file. The comps file is the file that lists all the packages that should get installed based on a particular profile. For example, when you do an interactive install and select Networked Workstation, that is a package group listed in the comps file. If you want to create your own package groups or make some new packages part of an existing package group then you would list those packages in the comps file. The comps file is located in the base directory.

One thing to note about this file is that the package names listed in it do not include the version number. This means that you could not use this file as an authorative list of packages installed by kickstart since you would only know the package name and not the package version.

Now that you understand the basics of how to make changes to kickstart, you can forget it. Build_ks takes care of building the installer based on a configuration file that list all the rpms and what groups they should be in. It takes care of putting the correct RPM’s in the RPMS directory. In also creates a new comps file and hdlist.

What you need to do now is find out how to define a distribution .

Источник

Ubuntu Documentation

Content Cleanup Required
This article should be cleaned-up to follow the content standards in the Wiki Guide. More info.

Style Cleanup Required
This article does not follow the style standards in the Wiki Guide. More info.

Kickstart compatibility is available as of Hoary. Contact ColinWatson for help, requests for improvement, etc.

Ubuntu Kickstart documentation

What are Kickstart Installations?

Many system administrators would prefer to use an automated installation method to install Ubuntu on their machines. The preseeding feature of debian-installer answers this need, and is available in Hoary. However, some people want to deploy networks including other GNU/Linux distributions. Red Hat’s Kickstart tool is a popular system here. The goal of the Kickstart compatibility project is to allow Kickstart to be used as a layer on top of debian-installer preseeding.

Using Kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical Ubuntu installation. Kickstart files can be kept on a single server system, and read by individual computers during the installation. This installation method can support the use of a single kickstart file to install Ubuntu on multiple machines, making it ideal for network and system administrators.

Kickstart lets you automate most of an Ubuntu installation, including:

• Language selection
• Mouse configuration
• Keyboard selection
• Boot loader installation
• Disk partitioning
• Network configuration
• NIS, LDAP, Kerberos, Hesiod, and Samba authentication
• Firewall configuration
• Custom package selection
• X Window System configuration

What Kickstart Options Does Ubuntu Support?

At this point the source code is the best reference. See this folder to see which Kickstart commands are being translated into preseed commands. As a general rule of thumb, if there is a handler file present for a command then, it is at least minimally supported. For specific command options, such as what auth options are supported, look into the handler file e.g. auth.sh.

Unsupported Options

This is a rough list of options that are known to be unsupported. Note that support may have been added since this was last edited, so the source code is your best reference. In general kickseed will leave a message in the Installation Logs if you try something unsupported.

Firewalling support. Only ‘firewall —disabled’ works for now

NFS installation. You can retrieve the Kickstart file over NFS using ‘ks=nfs: :/

‘, but booting with plain ‘ks’ doesn’t work, nor does retrieving the base system over nfs.

RAID/LVM partitioning isn’t handled

Partitioning has some bugs

Non-default authentication methods like NIS, LDAP, krb5, Hesiod, or Samba.

Bootloader passwords. UPDATE: bootloader passwords appear to work with 7.10

Only ks= and ksdevice= boot parameters are supported. No Anaconda-specific boot parameters are supported

How Do You Perform a Kickstart Installation?

Kickstart installations can be performed using a local CD-ROM, a local hard drive, or via NFS, FTP, or HTTP.

To use kickstart, you must:

1. Create a kickstart file. Ubuntu includes a graphical utility for creating kickstart files, in the package ‘system-config-kickstart’.
2. Create a boot disk with the kickstart file, or make the kickstart file available on the network.

Start the kickstart installation by specifying the boot parameter ks=. For example:

linux initrd=initrd.gz — ks=http://path/to/ks.cfg

Netboot on a machine with multiple NICs

If your machine has multiple network interfaces, you need to specify which interface should be used to retrieve the kickstart file. Here are some ways to do this in different scenarios

1. You know the name of the network interface

# Provide the ksdevice= boot paramter

linux initrd=initrd.gz — ks=http://path/to/ks.cfg ksdevice=eth0

2. You know the MAC address

# Provide the BOOTIF= boot parameter, and set ksdevice=bootif

linux initrd=initrd.gz — ks=http://path/to/ks.cfg ksdevice=bootif BOOTIF=01-18-03-73-0c-f2-51

3. You are using pxelinux or syslinux

Using a proxy / cache during the Kickstart

For HTTP proxy during the initial installation, use this inside your kickstart file (trusty onwards):

and also add the variable http_proxy=http:// :

:port to your boot configuration. You will need to give proxy configuration in both your kickstart file and the boot variable.

If installing from CD-Rom, this might work: Add the variable http_proxy=http://proxyhost:port to the file isolinux/isolinux.cfg with the parameter append e.g.

Installation Logs

If installation is successful, logs generated are stored at /var/log/installer/, such as /var/log/installer/syslog. If installation is not successful, then the logs exist in the locations they were created during installation, such as /var/log/syslog.

Syslog entries are tagged kickseed, and can be accessed as so

During installation, multiple terminals are active. Using Alt-Function keys lets you switch TTY’s (You can also hold Alt and use the left/right arrow keys). For Ubuntu/Debian, the various terminals during installation are as follows:

• Alt-F1: The installer dialog
• Alt-F2: A convenience shell prompt (busybox)
• Alt-F3: A convenience shell prompt (busybox)

Alt-F4: Output of syslog ( tail -f /var/log/syslog)

Note: These are different than the TTY’s used during a Red Hat installation.

Target Filesystems

When running a command outside of the chroot, the installation filesystem is located at /target. From within the chroot environment, the CD is mounted in /cdrom [Update: /media/cdrom in 14.04]. Guides for RHEL may mention /mnt/sysimage, but the correct path for Ubuntu is /target. The following example will place a new file on the installation filesystem.

Post Installation Scripts

The output of the postinstall script is shown in tty4. Also, read section on Target Filesystems.

Integration with Preseed

While Debian’s preseed can fully automate the entire Ubuntu installation, the official Red Hat kickstart language cannot. For this reason, Ubuntu kickstart includes a special command preseed which allows using preseed options inside a Kickstart file. Here is an example of mixing kickstart syntax with some preseed syntax.

Status update

This section is retained for historical purposes. See the installation manual links at the top of this page for current information.

Added here because it took much searching to retrieve this information! This is from a mailing list post by ColinWatson:

At the moment, (Kickstart compatibility is) in the unhappy state where the source is the best documentation; I intend to rectify this before the Hoary release. All the same, the system-config-kickstart package is in Hoary and can generate working Kickstart files for at least some configurations. You boot the installer with a «ks= » kernel argument, the same as with Red Hat. «ks=/

» all work and are convenient, although you can also put the Kickstart file on a CD or a floppy or whatever if you want.

Bug reports about Kickstart support would definitely be appreciated, the sooner the better. If there are particular unimplemented features you really need, I’d like to know about those too so that I can bump them up my priority list.

Links

Ideas

1. Maybe it would be possible to create near zero questions (apart from maybe some minimal hardware specifics) installer cds, to have specifics system needs tailored for certain organizations, uses, etc, specifically targetting special needs per usage domain: Almost automatic installer cd for libraries, schools, webhosting servers, router machines and other network appliances as some first examples. — SivanGreen

Response: This is the *whole point* of Kickstart and other similar automatic installation methods. «Ideas» shouldn’t be requests for documentation. Note that automatic installation scripts almost always need to be customized somewhat for the local environment. — ColinWatson

2. At a later stage, maybe create a special software piece that would be shipped with Ubuntu (or be part of the launchpad infrastructure) to allow people to use a user-friendly interface (Web??) to create their specific Kickstart Ubuntu installer cd , which would set up their specific system needs as per their organization, the system could possibley be also used for storage of such «System Templates» so whenever a sysadmin has finished installing a master copy of his desried configuration, and finished all adding extra packages and functionalities, he could store it in a «repository» of some sort, later to be used in data emergency situations, new hardware that is introduced into the organization etc. People who are willing to store their «System Templates» could be a helping hand to other clients of this system as they would be able to take other’s templates as a basing ground and build on it. —SivanGreen

Response: system-config-kickstart is a good start here, and sysadmins generally have their own arrangements for storing Kickstart files. It remains to be seen how derived distributions (which I assume you’re referring to by the Launchpad comment) will handle this; I suspect Kickstart will not really be appropriate for them, since it makes assumptions directed at fully automatic installations. — ColinWatson

3. Is it possible to make kickstart set up it’s NIS-configuration post packet-installation? As for now it hangs forever at package-configuration when auth —enablenis is selected because it tries to update the NIS-server when installing packages which adds additional users/groups. Also is it possible to make the %POST-script actually run after package-installation, now it runs after base-system is installed, but before package-installation. This makes it impossible to set up autofs in the %POST-section because autofs-installation (after reboot) will halt if /etc/auto.master etc. already exist. — Leitet

4. It would help to make kickstart able to make use of existing web and ftp proxies. According to Ubuntu’s Apt-Get HowTo, the line to add in apt.conf would be Acquire::http::Proxy «http://yourproxyaddress:proxyport»; — Lars Noodén

Response: You can accomplish this using the same preseed methodology in debian preseeds and it carries through to the OS. Add ‘preseed mirror/http/proxy string «http://proxy.example.com:8080″‘. — Tobin Davis (GrueMaster)

Feature Requests

1. We really need LVM functionality ASAP, (and to a lesser extent an option to create an unused parition). We want to install LVM by default on the machines we sell, but setting up our partitioning scheme each time is a hastle. Also, we want our customers to be able to reinstall without going through about 15 steps to do the partitioning during install. We have added a link to the link section that shows Red Hat kickstart LVM syntax. — Michael Pardee (groovix.com)

Response: Hi mate, why don’t you use a preseed file along the kickstart? This way you can remove the lvms and vgs during the installation without having to do it manually, and you can set up new lvms as redhat does. ( gettons )

2. The Ubuntu installer should generate a kickstart file similar to the /root/anaconda-ks.cfg generated by Anaconda. This helps a lot when you have to reproduce complex disk setups. You simply install a box by hand and then use the generated kickstart file on all the others.

Response: I am afraid it doesn’t generate any kickstart file at the end of the installation process. Is there any way to force it doing this? ( 08-06-10 )

KickstartCompatibility (последним исправлял пользователь gruemaster 2018-03-28 21:14:35)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

Читайте также:  Сбербанк для windows mobile