Automated Build Customization

Introduction

We now have a working build server. When we use yoda to build systems, we get consistent installations. The configuration of these systems is close to what. We want o minimize post-install customization to save time and improve quality.

Today we will customize our build process to:

• Automatically configure systems to use yoda as their YUM/DNF repo server
• Use the %post section of the Kickstart file to configure root's environment
• Specify a custom file system layout

Prerequisites:

Before you start this lab you must have:

• A working build server, yoda, from Lab 1
• The course VirtualBox appliance containing w01

Reference Materials:

• Kickstart Commands (from RH)
• Kickstart File Documentation

Part A: Create YUM repo files on yoda

Yoda is currently configured to use repositories from a local DVD. All the files from that DVD where copied to yoda's /var/www tree and published via http. In name of consistency, and to avoid "forgot to mound the DVD" errors, we will change yoda's repo files to point to yoda's published repositories.

1. Rename the BaseOS repo file

   cd /etc/yum.repos.d
   mv LocalBase.repo yodaBaseOS.repo
   

2. Edit yodaBaseOS.repo so that it looks like this:

   [yodaBaseOS]
   metadata_expire=-1
   name=yodaBaseOS
   baseurl=http://yoda/83/BaseOS
   enabled=1
   gpgcheck=1
   gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
   

3. Repeat this process for the LocalAppStream.repo (rename LocalAppStream.repo to yodaAppStream.repo, edit yodaAppStream.repo as required.)
4. Check our work. yum list should now show packages from the yodaBaseOS repo.

   yum clean all
   yum list | more
   

   we can use the "power of pipelines"© to see just the repo names

   yum list | tail -n +8 | awk '//{ print $3;}' | sort -u
   

   Why do some repo names start with @?
   Can you decipher the meaning of the @anaconda repo?
5. Check our work. We should now see packages from yodaAppStream

   yum clean all
   yum list | tail -n +8 | awk '//{ print $3;}' | sort -u
   

Part B: Patch yoda

yoda hosts a patch repo, miniUpdate, but needs a .repo file in order to access it.

1. Use what you learned in Part A to create a repo file named miniPatch.repo that points to the miniPatch repository on yoda.
2. Check our work. We should now see packages from miniPatch

   yum clean all
   yum list | tail -n +8 | awk '//{ print $3; }' | sort -u
   

3. Ooops. Looks like we forgot to change the baseurl from y01 to yoda in miniPatch.repo
   Please make that change now.
4. Check our work again...

   yum clean all
   yum list | tail -n +8 | awk '//{ print $3;}' | sort -u
   

5. Now that we can see the miniUpdate repo, it is time to patch yoda You should see updates for curl, libcurl, and sudo

   yum update
   

Part C: Getting our repo files on every new server

By default the installer sets up systems to use Red Hat's repositories from the open 'net. We want all of our servers to use only packages and patches we have tested. We will configure every server we build to use yoda for all repositories.

We need to modify our Kickstart file so that the repo files are created on each system. Kickstart does not have a command to do this. We will have to use shell commands in the %post section. We can use echo to create the files, or we can use curl to download them. We will use the curl strategy.

1. Make a directory under the http document root on yoda to host the repo files

   mkdir /var/www/html/yum.repos.d
   

Publish our repo files

cp -v /etc/yum.repos.d/*repo /var/www/html/yum.repos.d

2. Check our work by downloading with curl

   cd /tmp
   curl http://yoda/yum.repos.d/miniPatch.repo
   

3. Demonstrate the -O curl flag

   ls miniPatch.repo  # should result in No such file or directory
   curl -O http://yoda/yum.repos.d/miniPatch.repo
   cat miniPatch.repo
   

4. Create a backup of our working Kickstart file

   cp -a /var/www/html/Kickstart/default.ks /var/www/html/Kickstart/default.ks.working
   

5. Modify our Kickstart file by adding curl commands to the %post section. So that is looks like this..

   cd /etc/yum.repos.d
   curl -O http://10.1.1.100/yum.repos.d/miniPatch.repo
   curl -O http://10.1.1.100/yum.repos.d/yodaBaseOS.repo
   curl -O http://10.1.1.100/yum.repos.d/yodaAppStream.repo
   

Don't forget /etc/hosts

Our repo files refer to yoda by name not IP address. We need an entry for yoda in the hosts file of every server we build.

6. Modify default.ks so that every server built has an entry for yoda in /etc/hosts

Test our work

7. Build a new server from yoda
8. Can we see the repos?

   yum repolist
   

9. The install only pulled from the BaseOS and AppStream repositories. Meaning it needs to be patched! Patching should update: curl, and sudo

   yum update
   

Part D: I don't trust myself...

I don't trust myself to remember to run yum update to patch the system every time I build. Since we do not deploy unpatched systems, it makes sense to make patching part of the automated build.

We have a couple of choices. We could add yum update -y to the %post section of our Kickstart file. Or we could take advantage of YUM's ability to automatically select the latest available version of any package. This is the strategy we will use.

1. Two repos are referenced in our Kickstart file. Here's the line that tells the installer to also look in the AppStream repository. Add a repo command telling the installer to also look in miniPatch.

   repo --name="AppStream" --baseurl=http://10.1.1.100/83/AppStream
   

Part E: Custom file system layout

We have used a custom partitioning scheme for all our servers. We do this to isolate directories trees that are likely to grow. We do this to avoid running out of space on the root file system.

1. Increase the size of the /home file system from 200M to 400M in default.ks

Part F: Grading

1. Build a new server.
2. Set the hostname to s03
3. Configure a static IP address of: 10.1.1.30
4. Run the grading script, grade_build.sh, and submit the report to Canvas