I was just wondering how (or indeed if) people use the %include directive in Kickstart configuration files when building systems via NFS. I've been trying to modularise our Kickstart files a little to make things more readable, having generic defaults and role specific stuff split out into separate configs.
I've tried this configuration...
[root@archive kickstart]# cat centos4-install-ks.cfg # Kickstart to build default CentOS system # # $Id: centos4-install-ks.cfg,v 1.2 2006/03/13 14:21:32 root Exp root $ #
# Setup kickstart defaults (keyboard, NFS server etc.) %include /opt/kickstart/include/kickstart.cfg
# Setup partitions (mailstore specific) %include /opt/kickstart/include/disk.cfg
# Package list to install %packages %include /opt/kickstart/include/packages.cfg
%post
# Setup /etc/hosts with required ip/name mappings (mailstore specific) %include /opt/kickstart/include/hosts.cfg
# Setup CentOS Yum repository %include /opt/kickstart/include/centos4-yum.cfg
# Add CentOS GPG key used to sign their RPM packages rpm --import /usr/share/doc/centos-release-4/RPM-GPG-KEY-centos4
# Setup Dag repository %include /opt/kickstart/include/dag4-yum.cfg
# Setup users and their authorized_keys %include /opt/kickstart/include/users-and-keys.cfg
# Setup secure SSHD configuration %include /opt/kickstart/include/secure-sshd.cfg
# Setup Sudo %include /opt/kickstart/include/sudo.cfg
# Setup Nagios Remote Plugin Execution %include /opt/kickstart/include/nagios-nrpe.cfg
# Setup Bacula, /etc/bacula/bacula-fd.conf still needs to have the finalised # hostname entered manually :( (for now) %include /opt/kickstart/include/bacula.cfg
# Install "standard" additional components yum -y install keychain bash-completion multitail webmin
And a sample of one of the modular configs...
[root@archive kickstart]# cat include/secure-sshd.cfg # Lock down sshd_config to only accept SSH2 keybased auth mkdir -p /etc/ssh/RCS ci -t-"Main SSHD configuration file." -u /etc/ssh/sshd_config co -l /etc/ssh/sshd_config cat <<EOF > /etc/ssh/sshd_config # # Main SSHD configuration file. # # $Id$ # # FILE UNDER RCS, DO NOT EDIT WITHOUT CHECKING OUT!!!
Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key SyslogFacility AUTHPRIV PermitRootLogin without-password StrictModes yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys IgnoreRhosts yes PasswordAuthentication no X11Forwarding yes
EOF
ci -m"Kickstart: Secured SSH configuration, locked down to keys-only config." -u /etc/ssh/sshd_config
Which doesn't work, Anaconda runs and starting prompting for input as it would for a manual install. If I include everything pre-%post (IYSWIM) in the main Kickstart file then everything works as expected up till the %post %includes when Anaconda complains it can't find blah.cfg, presumably because it's not local.
I could live with the body of Kickstart config in the main file and then manually NFS mount and reference the modular configs, if I have to, but I wondered is there a better method?
I've Googled around a bit and found these threads from '02...
https://www.redhat.com/archives/kickstart-list/2002-May/msg00184.html
https://www.redhat.com/archives/anaconda-devel-list/2005-October/msg00080.ht...
Which clarify what's going on but not really how people deal with %include and NFS.
Will.
On Tue, Mar 14, 2006 at 09:27:18AM -0600, Rex Dieter enlightened us:
Will McDonald wrote:
I was just wondering how (or indeed if) people use the %include directive in Kickstart configuration files when building systems via NFS.
Wow, way cool. Is this %include magic actually documented anywere?
Yes, in the kickstart manual. Specifically in the kickstart-options section. See www.redhat.com/docs.
Matt
Quoting Will McDonald wmcdonald@gmail.com:
I was just wondering how (or indeed if) people use the %include directive in Kickstart configuration files when building systems via NFS. I've been trying to modularise our Kickstart files a little to make things more readable, having generic defaults and role specific stuff split out into separate configs.
The %include directives are parsed two times by Anaconda. First time before %pre scripts are executed, and then after %pre scripts are executed. The missing files are ignored on the first parsing of kickstart file. However, Anaconda will complain if they are missing when it parses the file for the second time (just after %pre scripts are executed). This allows you to create those files dynamically from the %pre scripts (or make them accessible if already stored somewhere). You must ensure that all files referenced by %include directives exist and are accessible by the time %pre scripts finish (for example, by creating the file in %pre script or by NFS mounting the directories where they live from %pre script).
If else fails, you can always copy the files locally using %pre script...
On 14/03/06, Aleksandar Milivojevic alex@milivojevic.org wrote:
Quoting Will McDonald wmcdonald@gmail.com:
I was just wondering how (or indeed if) people use the %include directive in Kickstart configuration files when building systems via NFS. I've been trying to modularise our Kickstart files a little to make things more readable, having generic defaults and role specific stuff split out into separate configs.
The %include directives are parsed two times by Anaconda. First time before %pre scripts are executed, and then after %pre scripts are executed. The missing files are ignored on the first parsing of kickstart file. However, Anaconda will complain if they are missing when it parses the file for the second time (just after %pre scripts are executed). This allows you to create those files dynamically from the %pre scripts (or make them accessible if already stored somewhere). You must ensure that all files referenced by %include directives exist and are accessible by the time %pre scripts finish (for example, by creating the file in %pre script or by NFS mounting the directories where they live from %pre script).
If else fails, you can always copy the files locally using %pre script...
Excellent, I hadn't thought of using %pre but from the sounds of it that'll allow me to keep all the configs broken out into sections.
Cheers Aleksandar.
Will.
On 3/14/06, Will McDonald wmcdonald@gmail.com wrote:
On 14/03/06, Aleksandar Milivojevic alex@milivojevic.org wrote:
Quoting Will McDonald wmcdonald@gmail.com:
I was just wondering how (or indeed if) people use the %include directive in Kickstart configuration files when building systems via NFS. I've been trying to modularise our Kickstart files a little to make things more readable, having generic defaults and role specific stuff split out into separate configs.
The %include directives are parsed two times by Anaconda. First time before %pre scripts are executed, and then after %pre scripts are executed. The missing files are ignored on the first parsing of kickstart file. However, Anaconda will complain if they are missing when it parses the file for the second time (just after %pre scripts are executed). This allows you to create those files dynamically from the %pre scripts (or make them accessible if already stored somewhere). You must ensure that all files referenced by %include directives exist and are accessible by the time %pre scripts finish (for example, by creating the file in %pre script or by NFS mounting the directories where they live from %pre script).
If else fails, you can always copy the files locally using %pre script...
Excellent, I hadn't thought of using %pre but from the sounds of it that'll allow me to keep all the configs broken out into sections.
Cheers Aleksandar.
Will. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Another useful trick is to pass options in via the kickstart command-line. Within your %pre and %post you can read these options from /proc/cmdline, then source them into your script. For example, we use this to configure static IPs without having to hard-code them.
Consider the following three lines: cat /proc/cmdline | sed 's/ /\ export /g' | grep '^export myemployer_' | grep = > /tmp/myemployer_cfg source /tmp/myemployer_cfg
If the kickstart command-line included 'myemployer_staticip=192.168.0.42 myemployer_foobar=exnage', the contents of myemployer_cfg would be: myemployer_staticip=192.168.0.42 myemployer_foobar=exnage
After you've source'd /tmp/myemployer_cfg, the variables $myemployer_staticip and $myemployer_foobar will be available to you.
-
Aleksandar Milivojevic -
Donald Murray, P.Eng. -
Matt Hyclak -
Rex Dieter -
Will McDonald