2

I'd like to make an universal automated install script using Kickstart, which would be placed on a CD and used in conjunction with standard DVD installer, i.e. the user of this script would need to append inst.ks=cdrom to boot options and then it'd install e.g. Fedora on the machine asking only for passwords.

It seems that standard practice is to generate Kickstart scripts with passwords (or password hashes) in them, which doesn't seem ideal if you intend to distribute the script to third parties. I also want to enable sshd service in the Kickstart script, which would make it possible for anyone on LAN with knowledge of default passwords to log in into the machine. Of course I can just disable password authentication in sshd but now it's getting messy, i.e. I'm trying to workaround public knowledge of default passwords (and I may very well be forgetting something).

I'm new to Kickstart, I'd like to make the install script to ask/prompt/input for site-specific passwords, and so far I figured out two options:

  1. Ask for passwords in %pre section and then generate e.g. accounts.ks with rootpw and user commands which will be included from main command section.
  2. Use static default passwords and run interactive script on first boot that'll force user to change default passwords. (Or possibly use chage in %post.)

My worry is that, based on my Google searches, no one is doing that, no one is even asking for that. :-) Everyone seem to be placing final passwords/hashes directly into Kickstart scripts. So this leaves me with making my own interactive script for both options, which, I fear, will end up bad. Or perhaps, I'm getting the whole concept of (semi-) automated installs with Kickstart wrong.

What is the standard practice for creating universal Kickstart scripts for scenarios like this, where you need to distribute the script and not force users to edit it?

1
  • 2
    Most people using kickstart are not distributing the kickstart or the installation media. The end users get the installed system. – Michael Hampton Dec 23 '18 at 14:23
1

If you do not provide an answer for something that is required, Anaconda will prompt the user for it.

I've verified this commenting out my user and rootpw lines in the Kickstart file. Upon installation everything else is pre-populated, but I am asked to create a root password and user. (user is optional)

In text mode, the installation will wait for user input before continuing. In graphical mode the installation will proceed while it allows for you to supply a password during package installation. Lastly, cmdline mode does not support user interaction and will halt.

Ex:

The previous Anaconda screens were skipped and installation went directly to package installation. At the end of installation, Anaconda waits for a root password to be selected and optionally, a user created.

Graphical Kickstart

0

(This might be a little late, and maybe a bit long, but this is exactly what I've done, which has taken me months/years to perfect).

All of the install information (eg, boot media/install tree, packages, scripts) are on a main server. The kickstart file is also there. BTW: I am using Fedora, but I don't think that makes any real difference for this method. See this link for more info on how to use pxe to boot and install for how fedora does it; it also includes very useful links for each step.

Without going into too much detail this is my process:

1) set up boot install from server via pxe. The default pxe file contains a menu list of the different installs you want to perform. they can be done thru NFS, FTP, or HTTP. Mine is via nfs,so the kickstart parameter defined where to get the file is:

inst.ks=nfs:[server ip]:/[path on server to kickstart file].

Use ip=[network settings] to specify network parameters to use from the server to the client; leave blank to use DHCP.

2) Create a kickstart file (see format and commands).

3) In the %pre section, write (with your favorite script language) instructions for the kickstart install for each type of machine install you have. You can create specific lists of packages to be included, as well as various install lines to also be included.

4) In the %post section write code to perform configuration of the installed system (note: these sections can be either run in either chroot or non-chroot environments, and also you can have multiple %post sections.

5) Finally, start up each machine to boot from network pxe, in the menu that will soon appear, select the machine type (or perhaps name) to install, hit enter, then get some coffee while the install runs automatically (unless an error in the script, or maybe something missing).

6) When complete, click on reboot, and voila

NB: you can access the boot command line via the file /proc/cmdline, so you could put extra information for the %pre (such as hostname). These are ignored by the installer.

NB (also): be aware that even though network access is available, the resolver isn't, so you'll have to use only ip addresses.

I hope this helps somebody to make this process very simple, and perhaps useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.