Building a custom CentOS 7 kickstart disc, part 4

Note: this series of articles applies to CentOS 7; for CentOS 6, see
this series
.

Let’s make things really interesting with a postinstall script to do some custom
configuration.

The %post section

In your kickstart configuration file, you can have sections of commands that are
designated to run after the anaconda installer has done its work. These sections are
denoted with the %post directive.

Typically, you follow this directive with the bash shebang line and the contents of
a custom shell script. One thing to note is the filesystem organization at this point
during the installation. Your new system’s disk is mounted at /mnt/sysimage,
not at / the way it will be once the system is up and running
after installation.

By default, the commands in the %post
section are run in a chroot environment, where /mnt/sysimage appears as the
/ directory. This lets you use “normal” paths to
configuration files like /etc instead of
/mnt/sysimage/etc (if you didn’t chroot like
this, you wouldn’t be able to do things like install RPMs). The primary disadvantage is
that your install media is not visible in a chrooted environment.

We solve this problem by building our postinstall in two stages. In the first stage,
we tell anaconda not to chroot us; we then copy files from the CD to the hard
drive.

In our case, we’ve put all our postinstallation files into the postinstall
directory under the ~/kickstart_build/isolinux directory. Note that the
isolinux directory in our build environment
becomes the root of the install disc that we create, and the install disc is mounted
at /run/install/repo. So ~/kickstart_build/isolinux/postinstall
is available at /run/install/repo/postinstall.

We copy postinstall directory on the install disc to
/root/postinstall on the new system’s hard drive.

We’re now ready to run stage 2 of the postinstall, where we actually use the
postinstallation files.

Note that in both the stage1 and stage2 postinstall scripts, I redirect stdout to a
log file in root’s home directory. This is very helpful for diagnosing problems during
the kickstart postinstall. This comes in handy when you have many hundreds of lines of
postinstall that need to be tested and debugged.

The sky is the limit for what you can do in the postinstallation:

  • add users or groups
  • install non-CentOS applications from RPMs (see below for some good repos)
  • install non-CentOS applications from tarballs (I prefer RPMs where available, but
    sometimes you don’t have them handy)
  • set the runlevels for various system services
  • configure servers like apache, samba, sshd, and MySQL
  • configure the default behavior of the bash shell

and anything else you could imagine. In my ideal world, my machines are ready to
perform their designated tasks from the very first second I boot them up. I don’t want
to have a series of manual steps to complete the configuration.

Organizing the postinstall files

If I can offer any suggestions in terms of how you organize your
postinstall files, I would suggest breaking the files up
into directories like this:

Put your non-CentOS application RPMs and tarballs into
apps (with a subdirectory for each application), put
application configuration files and scripts into
appconfig (again with a subdirectory for each
application), put OS configuration files (like network config files) into
sysconfig, and put general-purpose libraries (those not
specifically required by any applications you’re installing) into
libs.

Of these strategies, the organization of
apps is by far the most important. When you install
applications that are not part of the CentOS distro, you’ll likely have to install
additional libraries or utilities to satisfy dependencies in those packages. When you
need to refresh your kickstart image, it is helpful to have each app and its
dependencies contained in a single directory. If you throw them all into a big
directory, you’ll never remember, for example, that mhash is in there because aide
requires it.

External repositories

I have found the following repositories to be reliable sources of packages that
aren’t included in the CentOS distro:

  • EPEL – Extra Packages for
    Enterprise Linux
  • repoforge – formerly RPMforge; DAG
    repository now redirects to this
  • ATrpms – good place to get ffmpeg rpms
  • ELrepo – source for hardware drivers

Good luck building your custom installation disc. I welcome any comments or
suggestions you might have for this guide!

Part 1
Part 2
Part 3
Part 4

Join the Conversation

9 Comments

  1. Good guide. I’m trying to find a way to make it autoupdate. So when there are updates it automatically put them on the installation iso.

  2. How is it possible to burn the custom iso to a USB stick? I tried to run ‘isohybrid custom.iso’, copied the file to a USB stick (dd…) and was able to boot from the stick. The problem is that the system is not able to find the kickstart file…

  3. Great article!

    This helped me put together a small set a media for rebuilding a couple racks.

    Thanks!

  4. First of all, thx for really usefull article.

    1. I’m found this way in chroot to work with installation media.
    # Mount CDROM
    mkdir /mnt/source
    mount /dev/cdrom /mnt/source

    2. Where i can find official notes about filesystem organization in kickstart environment?

    1. I don’t quite understand your point #1.

      As for official docs, I have not ever found much documentation on this stuff. Official Red Hat docs are a bit light on details. I have had to do a lot of experimentation to figure things out.

  5. Hi,

    I followed instructions to the letter… But on Centos 7.2 i’m presented with:

    ERR packaging: base repo (url/file:///run/install/repo) not valid — removing it

    Following with anaconda bombing out to a confirmation page asking me to specify a repo.

    Funny thing is, i’m not actually defining a repo in my ks.cfg. It should just be reading repodata.

    Any ideas?

  6. Firstly, this is a wonderful resource. I’ve been looking for something like this for ages without success.
    However, I find myself ultimately disappointed. I was hoping that the boot CD could be configured to install the OS without user intervention – not even having to type the ks one-liner or select a menu option. This would then allow VM creation and OS install using VBoxManage over ssh.
    Given that you don’t even mention this possibility I suspect that for some reason it is not physically possible. Is this correct? Or if possible, where would be a good place to start looking?
    Thanks again for a very clear tutorial

    1. If you have a look at isolinux.cfg, you’ll find the boot menu directives. One of the boot menu options is listed as “default”. If you set the timeout to a non-zero value, after timeout seconds have elapsed, the default option will automatically be selected. Maybe that will do what you’re looking for?

  7. Very useful guide that worked right out of the box. Until we encountered a newer laptop that refuses to boot from any internal drive unless it supports EFI Secure Boot. The default CentOS ISOs seem to support EFI off the shelf, but how to make this work for kickstart installations is missing from the instructions above. It would be helpful if instructions for this were added.

Leave a comment

Your email address will not be published. Required fields are marked *