generate a kickstart configuration file
validate it with ksvalidator part of the pykickstart package
end goal is for a full automated deployment
local files can only be pulled from the local media, so for netinst local files can't be used
you can split the config out and use the %include directive to pull the file in
so we have (for example) this directory layout on a remote server
kickstarts/
├── albert
│ ├── disk_layout_lvm.cfg
│ ├── kickstart.cfg
│ └── networking.cfg
├── base
│ ├── kickstart.cfg
│ └── networking.cfg
├── buildvm
├── common
│ ├── authentication.cfg
│ ├── authentication_rootpw.cfg
│ ├── bootloader.cfg
│ ├── disk_layout.cfg
│ ├── disk_layout_lvm.cfg
│ ├── firewall.cfg
│ ├── groups.cfg
│ ├── locale.cfg
│ ├── logging.cfg
│ ├── media_centos7_netboot.cfg
│ ├── networking.cfg
│ ├── packages.cfg
│ ├── post.cfg
│ ├── pre.cfg
│ ├── repo.cfg
│ ├── selinux.cfg
│ ├── services.cfg
│ ├── system_finalize.cfg
│ └── users.cfg
├── hal
│ ├── disk_layout_lvm.cfg
│ ├── kickstart.cfg
│ └── networking.cfg
├── README.md
├── tupper
│ ├── disk_layout_lvm.cfg
│ ├── kickstart.cfg
│ └── networking.cfg
└── xavier
├── disk_layout_lvm.cfg
├── kickstart.cfg
└── networking.cfg
the largest directory there is the common/ directory, this includes kickstarts shared across all servers, any can be overidden but creating a local copy of the file for the server and pointing the localised kickstart.cfg to the appropriate version of the file.
the deploy script (buildvm) identifies the server by name (we could use ip based configuration for auto identification and may look at that later) then reads the kickstart.cfg file
The kickstart.cfg file includes the other kickstarts as required for the server, so for example the kickstart.cfg for tupper is included below. You'll note that the disk_layout_lvm.cfg does not come from the common dir since it is specifc to the tupper deploy
%include http://<remote>/common/media_centos7_netboot.cfg %include http://<remote>/common/authentication.cfg %include http://<remote>/common/authentication_rootpw.cfg %include http://<remote>/common/logging.cfg %include http://<remote>/common/selinux.cfg %include http://<remote>/common/services.cfg %include http://<remote>/common/bootloader.cfg %include http://<remote>/common/disk_layout.cfg %include http://<remote>/tupper/disk_layout_lvm.cfg %include http://<remote>/tupper/networking.cfg %include http://<remote>/common/firewall.cfg %include http://<remote>/common/repo.cfg %include http://<remote>/common/locale.cfg %include http://<remote>/common/groups.cfg %include http://<remote>/common/users.cfg %include http://<remote>/common/system_finalize.cfg %pre %include http://<remote>/common/pre.cfg %end %packages %include http://<remote>/common/packages.cfg %end %post --erroronfail %include http://<remote>/common/post.cfg %end
As an example of the differences in the disk layouts, the sizes listed for each partition are for illustration purposes only.
commom/disk_layout_lvm.cfg
### PARTITIONING # LVM volgroup cl pv.01 logvol / --vgname=cl --fstype xfs --size=4096 --name=root logvol /home --vgname=cl --fstype xfs --size=512 --name=home logvol /tmp --vgname=cl --fstype xfs --size=512 --name=tmp logvol /swap --vgname=cl --fstype swap --size=512 --name=swap logvol /var --vgname=cl --fstype xfs --size=1 --name=var --grow --maxsize=512 logvol /var/log --vgname=cl --fstype xfs --size=512 --name=var-log
tupper/disk_layout_lvm.cfg
### PARTITIONING # LVM volgroup cl pv.01 logvol / --vgname=cl --fstype xfs --size=4096 --name=root logvol /home --vgname=cl --fstype xfs --size=512 --name=home logvol /tmp --vgname=cl --fstype xfs --size=512 --name=tmp logvol /swap --vgname=cl --fstype swap --size=512 --name=swap logvol /var --vgname=cl --fstype xfs --size=512 --name=var logvol /var/log --vgname=cl --fstype xfs --size=512 --name=var-log logvol /var/lib/docker --vgname=cl --fstype xfs --size=1 --name=var-lib-docker --grow