SYSRUN is a tool used for configuring and automating the install of networks of computers. By default, it leverages existing tools such as ISC's dhcpd, PXELINUX, Anaconda/Kickstart, and Autoinst, but SYSRUN can easily be extended to use different tools depending on the user's preferences. SYSRUN requires a version control system and template engine in order to manage configuration versions.
Many organizations (or individuals) that are responsible for large numbers of hosts will find themselves installing, and re-installing operating systems again and again, which can be labor intensive without an automated system. In addition, installing machines by hand can be error-prone due to operator error. SYSRUN provides the tools to create standardized profiles that can be used to build machines in a way that is consistent and repeatable. After installation, SYSRUN can hand configuration off to a host configuration management system such as cfengine in order to manage post-installation configuration.
SYSRUN does not attempt to replace existing tools, but rather layers functionality on top of those tools in order to ensure consistency. There are already implementations of DHCP servers, TFTP servers, and OS installers that exist and when put together, can provide the automation necessary. However, configuring these services by hand can be labor intensive and error-prone. By using Autoinst as an underlying version repository, and providing a way to publish configurations to these other tools, SYSRUN provides the following additional functionality:
Version control of configurations - any previous state can be reproduced at any time. All changes are recorded and auditable.
Branching and tagging of configurations - version control branches allow others to work on tests, and tags ensure that a given symbolic revision can be retrieved at any time, making rollback and deployment much more reliable.
Template expansion - by using Autoinst's template system, this allows the user to configure templates only once for a given profile, and then have those templates automatically generate the appropriate configuration files depending on the runtime context. This cuts down on the amount of manual, error-prone configuration work on the central servers.
Re-usable groups and profiles - Autoinst provides the ability to organize hosts into groups, as well as create profiles that reprsent a set of configurations. Groups allow the user to group hosts together so that they all have the same configuration, and profiles allow the user to create a OS configuration to be installed onto multiple machines.
SYSRUN owes its concepts to a number of prior closed-source and open-source projects, as well as large scale production experience in private industry. The publicly accessible projects are:
xml2hostconf- provides a 'main.xml' configuration file from which boothost configuration files are generated. However, no version control system is provided, and for large installations, a single 'main.xml' configuration file can get very large and unwieldy without adding additional tools or databases to manage that file.
This section will cover how to install the SYSRUN software on a system.
When using the default settings, SYSRUN requires the following packages to be installed in order to operate:
Python - 2.x
Autoinst - 3.x
A TFTP server - for example the HPA TFTP server
A web server - for example the Apache HTTPD server
With the exception of Python, developers can extend SYSRUN to use alternate packages in order to accomodate local preferences and site-specific requirements.
The SYSRUN project is hosted on SourceForge, and the software can be obtained from the SourceForge project page.
First, make sure the prerequisites are installed. After obtaining the source, installing SYSRUN using setup.py:
[root@linux ~]# setup.py |
There are two types of machines in a SYSRUN installation:
boot servers - these are servers that have SYSRUN installed and respond to DHCP netboot requests, send kernel and initrd images, and provide packages for installation.
target servers - these are machines that are installed over the network, and do not require SYSRUN to be installed.
In general, a boot server can support the installation of multiple target servers on a given network. The total number of supported targets depends on the frequency of installs.
There are some important things to note when setting up a networked install server using SYSRUN.
If you are setting up a installer server on a shared network, be careful! If there are other DHCP servers on that network, you might interfere with them. And if a netboot default is configured in PXELINUX, machines that are configured to netboot by default might have their disks erased and reinstalled on boot!
In fact, it usually makes sense to create a separate subnet or VLAN specifically for testing SYSRUN, so that your boot server has exclusive control over DHCP requests.
Once SYSRUN is installed on a boot server, there are a number of steps required to configure it for your specific network. It is highly recommended that these configurations be version controlled using Autoinst, and then that repository backed up, so that recreating any version of a boot server can be done at any time.
In order for the boot server to install hosts on its network, some basic infrastructure needs to be established:
A DHCP server that will reply to hosts requesting to be booted over the network, and then direct those machines to a TFTP server in order to obtain a bootable image and configuration.
A TFTP server that will reply to machines and send them the requested boot image and configuration.
Kernels and initial ramdisks needed to boot the target machines and start an OS installer such as Anaconda, and send it a configuration file for automated install (such as Kickstart)
A repository needed by the OS installer. For example, Anaconda can use a HTTP, FTP, or NFS server to fetch RPM packages.
For the purposes of this document, we will setup a network that will work for a typical CentOS install.
Most Linux distributions provide a packaged DHCP server, the most common one being ISC dhcpd. On a CentOS system, install the package using rpm or yum:
[root@linux ~]# yum install dhcp |
Next, setup your DHCP server for your network. For example, you will need to configure an address range, which are addresses to be issued to machines requesting them. If we were issuing IP addresses between 192.168.1.10 and 192.168.1.100 in the 192.168.1.0/24 subnet, then the /etc/dhcpd.conf configuration may look like this:
authoritative;
ddns-update-stype none;
option ip-forwarding false;
option mask-supplier false;
option pxelinuxmagic code 208 = string;
option pxelinuxconfigfile code 209 = text;
option pxelinuxpathprefix code 210 = text;
option pxelinuxreboottime code 211 = unsigned integer 32;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;
option domain-name "example.com";
option domain-name-servers 192.168.1.1;
range dynamic-bootp 192.168.1.10 192.168.1.100;
default lease-time 21600;
max-lease-time 43200;
}
use-host-decl-names on; |
This configuration enables netbooting on hosts requesting to be netbooted. For now, don't worry about how machines will be configured, we will add an “include” statement later to include netboot profiles..
Most Linux distributions provide a packaged TFTP server, the most common one being H. Peter Anvin's tftpd. On a CentOS system, install the package using rpm or yum:
[root@linux ~]# yum install tftp-server |
Next, if using xinetd, configure it to respond to tftp queries by creating /etc/xinetd.d/tftp:
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -u nobody -s /tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
} |
And then restart xinetd:
[root@linux ~]# service xinetd restart |
This configures the TFTP server to respond to requests, sets the user ID to nobody, and confines the process to the /tftpboot directory.
In order to machines to startup their installers, they need bootloaders, kernels, and initial ramdisks. PXELINUX can provide the bootloader. On a CentOS system, install PXELINUX using rpm or yum:
[root@linux ~]# yum install syslinux-tftpboot |
This will install various files into /tftpboot on your machine. Next, in order to boot the installer, a kernel and ramdisk need to be installed. You can usually obtain this from the installation media. For example, to get the CentOS 5.2 kernel and ramdisk:
[root@linux ~]# wget -O /tftpboot/vmlinuz-centos-5.2.x86_64 \ http://mirror.centos.org/centos/5.2/os/x86_64/images/pxeboot/vmlinuz [root@linux ~]# wget -O /tftpboot/initrd-centos-5.2.x86_64 \ http://mirror.centos.org/centos/5.2/os/x86_64/images/pxeboot/initrd.img |
This will save the kernel and ramdisk into your /tftpboot directory. Note that we gave these files a different name than what's on the server. That's because if we want to add other kernel and ramdisk images in our /tftpboot directory, we need some way to distinguish them from each other.
In order for most automated OS installers to work, they depend on a repository that contains configurations, packages or other binaries needed to install the operating system on the machine. In the case of Anaconda, it can use a HTTP server to fetch a Kickstart configuration, and then can use a HTTP, FTP, or NFS server to fetch its binary packages. In this document, we will use an Internet mirror to fetch RPMs; for most production installs, it makes more sense to mirror the repository locally for performance reasons (as well as to be considerate of other's bandwidth). However, at a minimum, we still need a webserver on our boot server in order to host Kickstart configurations for each host, so on CentOS, install Apache using rpm or yum:
[root@linux ~]# yum install httpd |
This will set the DocumentRoot to /var/www/html. For now, let's create an empty directory where SYSRUN Kickstart profiles will be stored:
[root@linux ~]# mkdir /var/www/html/sysrun |
At this point, we should have a working DHCP server, a working TFTP server, a bootloader, a kernel, an initial ramdisk, and a working webserver. At this point, it is highly recommended that you do the following:
Store the configuration files in Autoinst. This will ensure that you can recreate a boot server again from scratch without editing any files by hand. It also means you will have revision control over your configurations files. If you're too lazy to do that, at least save them to a version control system like Subversion.
Backup everything in /tftpboot. If you need to build another boot server, you can simply restore that directory to the server.
Remember, one of the key principles when SYSRUN was created is consistency -- you want to be able to reconstruct your environment from revision control at any time, boot servers included.
If you are just using the defaults (which is probably OK), then to setup SYSRUN you can simply run the following:
[root@linux ~]# sysrun setup |
This will create /var/sysrun and two sub-directories 'dhcpd' and 'installer', as well as create a directory /tftpboot/sysrun.
If you want to override the default settings, you can create /etc/sysrun.conf. By default SYSRUN uses the following:
Save generated dhcpd configuration files in /var/sysrun/dhcpd
Generate a master dhcpd include file called sysrun.conf in the same path as the dhcpd configuration files
Save generated tftp files in /tftpboot/sysrun/pxelinux.cfg
Save generated installer configurations (e.g. Kickstart) in /var/sysrun/installer
Use Autoinst as the configuration repository
Use http://localhost/autoinst/api as the Autoinst API base URL with no username or password
Use 'mac.address' as the property to use to get a host's MAC address
Use 'sysrun.dhcpd' as the template name to generate dhcpd configurations
Use 'sysrun.tftp' as the template to generate TFTP configurations
Match installer templates using a regular expression of 'sysrun\.installer\..*'
Use the regular expression of 'sysrun\..*' to match Autoinst profiles
The format of the configuration file is as follows:
[dhcpd] dhcpd_path=/var/sysrun/dhcpd dhcpd_include=sysrun.conf [tftp] tftp_path=/tftpboot/sysrun/pxelinux.cfg [installer] installer_path=/var/sysrun/installer [repository] dist_url=http://localhost/autoinst/api dist_username= dist_password= repository_type=autoinst mac_property=mac.address dhcpd_template=sysrun.dhcpd tftp_template=sysrun.tftp installer_template_pattern=sysrun\.installer\..* profile_regex=sysrun\..* |
A DHCP configuration template is needed in order to generate dhcpd configurations on the fly. SYSRUN includes a template that is compatible with ISC's dhcpd, which creates a group configuration for each configuration profile in the system, as well as a file called sysrun.conf that includes all of the group configuration. Create a template in Autoinst using the command line tool:
[root@linux ~]# ai create -a sysrun.dhcpd
<?xml version="1.0"?>
<action version="3.0.0" name="sysrun.dhcpd" filename="/var/sysrun/dhcpd/dhcpd.conf" user="root" group="root" mode="0600" stylesheet="sysrun.dhcpd.xsl" method="text" encoding="UTF-8">
<properties>
<property name="pxelinux.filename">/pxelinux.0</property>
</properties>
<template>
group {
filename "<property name="pxelinux.filename"/>";
if exists dhcp-parameter-request-list {
# Always send the PXELINUX options (specified in hexadecimal)
option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list,d0,d1,d2,d3);
}
option pxelinuxmagic f1:00:74:7e;
option pxelinuxpathprefix "/";
<sysrun-dhcp-hosts/>
}
</template>
</action> |
Note that this template has a custom XML tag called 'sysrun-dhcp-hosts'. In order for Autoinst to process it, a stylesheet must be created in order to manage this logic:
[root@linux ~]# ai create -s sysrun.dhcpd
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<xsl:variable name="mac.address" select="/action/properties/property[@name='mac.address']"/>
<xsl:variable name="ip.address" select="/action/properties/property[@name='ip.address']"/>
<xsl:apply-templates select="/action/template"/>
</xsl:template>
<xsl:template match="property"><xsl:variable name="name" select="@name"/><xsl:value-of select="/action/properties/property[@name=$name]"/></xsl:template>
<xsl:template match="sysrun-dhcp-hosts">
<xsl:for-each select="/action/hosts/host">
<xsl:sort select="@name" order="ascending"/>
host <xsl:value-of select="@name"/> {
hardware ethernet <xsl:value-of select="translate(properties/property[@name= 'mac.address'],'-',':')"/>;
fixed-address <xsl:value-of select="properties/property[@name='ip.address']"/>;
option pxelinuxconfigfile "sysrun/pxelinux.cfg/<xsl:value-of select="translate(properties/property[@name='mac.address'],':','-')"/>";
}
</xsl:for-each>
</xsl:template>
<xsl:output method="text"/>
</xsl:stylesheet> |
This stylesheet replaces the SYSRUN custom XML tag with DHCP information for each host.
A TFTP configuration template is needed so that the correct bootloader, kernel, initial ramdisk, and installer parameters are sent to the host that is requesting the netboot. SYSRUN includes a template that is compatible with H. Peter Anvin's tftpd and PXELINUX. By default, for each MAC address in the system, a configuration is created in SYSRUN's /tftpboot/sysrun/pxelinux.cfg directory that contains the boot parameters for each host. So let's create a template for TFTP in Autoinst:
[root@linux ~]# ai create -a sysrun.tftp
<?xml version="1.0"?>
<action version="3.0.0" name="pxelinux" filename="/var/sysrun/netboot/pxelinux.cfg/default" user="root" group="root" mode="0644" stylesheet="default.xsl" method="text" encoding="UTF-8">
<properties>
<property name="hostname">localhost</property>
<property name="sysrun.netboot.kernel">/vmlinuz-centos5.x86_64</property>
<property name="sysrun.netboot.initrd">/initrd-centos5.img.x86_64</property>
<property name="sysrun.netboot.device">eth0</property>
</properties>
<template>
default local
prompt 1
timeout 50
display /sysrun/pxelinux.msg/sysrun.msg
label local
localboot 0
label install
kernel <property name="netboot.kernel"/>
append initrd=<property name="netboot.initrd"/> ks=http://boothost.example.com/sysrun/installer/<property name="hostname"/> device=<property name="netboot.device"/> ramdisk_size=9216 lang= devfs=nomount
</template>
</action> |
Replace 'boothost.example.com' with the DNS name of your boot host. Also you should create a text file in /tftpboot/sysrun/pxelinux.msg/sysrun.msg that will show something to the user, for example:
SYSRUN Enter "install" to install the OS on this host. |
Once the machine is booted, an installer template is needed in order to instruct the OS installer how to build this machine. SYSRUN includes a template that is compatible with Anaconda (Kickstart). Using this template, for each machine, a kickstart profile is created and a file saved in /var/sysrun/installer, named with the hostname of the machine. Use Autoinst to create a Kickstart template:
[root@linux ~]# ai create -a sysrun.installer.kickstart
<?xml version="1.0"?>
<action version="3.0.0" name="sysrun.installer.kickstart" filename="/var/sysrun/kickstart/kickstart.cfg" user="root" group="root" mode="0600" stylesheet="default.xsl" method="text" encoding="UTF-8">
<properties>
<property name="sysrun.installer.partitions">
part /boot --fstype ext3 --size=200 --ondisk sda
part pv.0 --size=1 --grow --ondisk sda
volgroup vg0 --pesize=32768 pv.0
logvol / --fstype ext3 --name=lv0 --vgname=vg0 --size=1 --grow
logvol swap --fstype swap --name=swap --vgname=vg0 --size=4096
</property>
<property name="sysrun.installer.packages">
@editors
@text-internet
@virtualization
@legacy-network-server
@dns-server
@gnome-desktop
@dialup
@core
@base
@ftp-server
@network-server
@base-x
@web-server
@smb-server
@mail-server
@server-cfg
@admin-tools
@news-server
kexec-tools
bridge-utils
device-mapper-multipath
</property>
</properties>
<template><![CDATA[
install lang en_US.UTF-8
keyboard us timezone --utc Etc/UTC rootpw blahblahblah reboot text
url --url http://mirror.centos.org/centos/5.2/os/x86_64/
#System bootloader configuration
bootloader --location=mbr
zerombr
clearpart --all --initlabel
# Disk partitioning information
>
#System authorization infomation
authconfig --enableshadow --enablemd5
#Network information
network --bootproto=dhcp --device=eth0
#Firewall configuration
firewall --enabled --port=22:tcp
skipx
#Package install information
%packages --resolvedeps
>
%post
exec > /sysrun.log 2>&1 chmod 600 /sysrun.log
#
# If an error occurs during installation,
# we want to immediately exit the installation.
# A non-zero exit from any of the commands stops
# the installation.
#set -e
#
# be a bit more verbose
set -x
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
mv /sysrun.log /var/log/sysrun.log
ntpdate tick.usno.navy.mil
|
SYSRUN installs machines based upon configuration profiles. Profiles are useful for ensuring the same OS, kernel, and packages are installed on hosts that reference the same profile. This is important so that hosts that are supposed to be the same are built consistently, and are useful so that you only have to build a profile once for multiple hosts that are meant to be the same. Some example profiles might be:
sysrun.centos5.x86_64 - a profile to install CentOS 5 onto 64-bit x86 systems
sysrun.freebsd6.i386 - a profile to install FreeBSD 6 into 32-bit x86 systems
By default, SYSRUN uses the 'sysrun.*' pattern to identify all of the profiles that belong to SYSRUN. So if you retain this convention, all the profiles you create should start with a string of 'sysrun.' Profiles need to reference the templates that were just created. By doing this, you are defining what a profile contains.
[root@linux ~]# ai create -p sysrun.centos5.x86_64
<?xml version="1.0"?>
<profile version="3.0.0" name="sysrun.centos5.x86_64">
<actions>
<action name="sysrun.tftp"/>
<action name="sysrun.dhcpd"/>
<action name="sysrun.installer.kickstart"/>
</actions>
<properties>
<property name="netboot.kernel">/vmlinuz-centos-5.2.x86_64</property>
<property name="netboot.initrd">/initrd-centos-5.2.img.x86_64</property>
</properties>
</profile> |
This profile references the 3 templates we created, meaning we should use the kickstart template, and the kernel and initial ramdisk are from CentOS, the images that we downloaded and installed earlier.
To test SYSRUN, simply run the following command:
[root@linux ~]# sysrun update |
If all goes well, it will generate various configuration files in /var/sysrun. However, the system is not quite usable, since we're missing a few things:
The DHCP server knows nothing of the generated configuration.
The web server cannot serve the generated installer templates.
We have not yet specified any hosts to be installed, so the generated DHCP and kickstart configurations are empty or missing.
In order for host installation to work, DHCPD must now include the configuration files generated by SYSRUN, and the installer configuration referenced by the TFTP configuration must be available for the host to retrieve. First let us re-configure DHCPD by editing dhcpd.conf and adding the following line to the end of the file:
include "/var/sysrun/dhcpd/sysrun.conf"; |
This directive will include the file into the DHCP configuration, and that file includes all of the profiles that SYSRUN has generated. Next, configure the web server to enable access to the generated installer configurations. If you are using Apache, add a line such as the following to your Apache configuration:
Alias /sysrun/installer /var/sysrun/installer |
You may have to modify your webserver's security settings to allow this.
Again, we want to make sure that if something happened to our boot host, that we could easily reconstruct it automatically and consistently, so that we don't need to take all of these manual steps again. So make sure to commit the new DHCPD and web server configuration to revision control, and take regular backups of the Autoinst repository and /tftpboot. It is highly recommended to use Autoinst and aiupdate to manage this process.
Now that the groundwork has been laid, now we can start to manage hosts using the profiles that have been created.
Let's say we have a machine called desktop.example.com that we want to install using SYSRUN. First, we have to create an entry in Autoinst, and assign it properties that are specific to this host:
[root@linux ~]# ai create -H desktop.example.com
<?xml version="1.0"?>
<host version="3.0.0" name="desktop.example.com">
<properties>
<property name="hostname">desktop.example.com</property>
<property name="mac.address">00-BC-1F-DE-91-25</property>
<property name="ip.address">10.11.21.11</property>
</properties>
</host> |
As you can see, the properties that are specific to this particular machine are the hostname, MAC address, and IP address. SYSRUN will look up the mac.address property in order to set the netboot configuration for this host.
Autoinst uses groups to identify sets of hosts. Profiles cannot be assigned directly to hosts, rather, they are assigned to groups. Groups can represent functional groupings (machines belonging to a single application) or environmental groupings (machines belonging to a particular location or layout). Let's create a group called “desktops”, add the machine desktop.example.com to it, and then assign the profile sysrun.centos5.x86_64 to it:
[root@linux ~]# ai create -g desktops
<?xml version="1.0"?>
<group version="3.0.0" name="desktops">
<hosts>
<host name="desktop.example.com"/>
</hosts>
<groups/>
<profiles>
<profile name="sysrun.centos5.x86_64"/>
</profiles>
<properties/>
</group> |
What this does is express that the machine desktop.example.com belongs to the group called “desktops”, and that all the machine in the “desktops” group should have the the same operating system profile installed on them, as configured in the “sysrun.centos5.x86_64” profile. All machines in this group should look the same, with the exception of the IP address, hostname, and MAC address. Just be aware:
If machines in a group will be of different architectures, create separate groups, for example, “desktops.i386” and “desktops.x86_64”. Then you can assign profiles to each of those groups, and create a meta-group called “desktops” that contains the two sub-groups.
Assigning two SYSRUN profiles to the same group will produce strange, undetermined results. Machines may not be consistent, and depending on which template executed first.
Now that we have a host in the system, we can run SYSRUN again to generate the configuration:
[root@linux ~]# sysrun update |
This will re-generate the dhcpd configuration, create a file with the MAC address of the host in /tftpboot/sysrun/pxelinux.cfg, and generate a kickstart file for our host. Now, we can try it out! Reboot the host, and if all goes well, you should see a boot prompt with the message you configured before. If you hit enter, the machine will attempt to boot locally, but if you type “install” and hit ENTER, the machine should boot into the installer, fetch the configuration from the installer repository, and start to install the OS on the host without any human intervention. WARNING: this will re-image this machine with a new operating system, so be sure you don't need anything on this host before restarting it!
Now that you have a basic CentOS installation done, you want to start tweaking SYSRUN to fit your needs, some of the changes that you may want to try are:
Use your favorite distribution - Debian, Ubuntu, SusE, Slackware, Gentoo, for example. By changing the installer template and installing a kernel and initial ramdisk in the TFTP server directory, this is relatively straightforward.
Install other operating systems - FreeBSD, OpenBSD, or even Solaris can be installed using SYSRUN, with a little additional effort. A bootable kernel and inital ramdisk will be needed, as well as new installer templates. There are likely configuration changes that need to be made to the DHCP server configuration as well as to the TFTP configuration (especially in the case of commercial systems such as Sun's Jumpstart). A NFS server may need to be setup in order to host binaries needed by the installer. Make sure that you save these configurations in version control, and backup your binary repositories so that you work is not lost with the machine.
Setup SYSRUN mirrors - if you have a very large installation, you are going to have more than one boot server, at least one per VLAN or subnet. To setup SYSRUN mirrors, build multiple boot servers and have them reference a central Autoinst repository so that they are all consistent. If you have a very busy Autoinst repository, you could even point your SYSRUN mirrors at a read-only mirror of the Autoinst repository to scale massively.
Configure automatic netbooting. With a little bit of work, you could reconfigure the TFTP settings to netboot by default instead of booting locally by default. Some very large installations prefer this so that a boot server contains the kernels for the entire network.
At this point it is recommended that you setup a configuration management system such as cfengine or Puppet that manages the system going forward. The recommended way to do this is to install the configuration management system as part of the installer. For example, when using Kickstart with cfengine, a basic configuration could be installed in the %post section of the kickstart template:
%post
# be a bit more verbose
set -x
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
mv /sysrun.log /var/log/sysrun.log
# setup cfengine
# first, generate keys
cfkey
# next, create update.conf
( cat <<'EOF'
control:
actionsequence = ( copy tidy )
domain = ( example.com )
policyhost = ( cfengine.example.com )
master_cfinput = ( /var/cfengine/dist/inputs )
workdir = ( /var/cfengine )
cf_install_dir = ( /usr/local/sbin )
copy:
$(master_cfinput) dest=$(workdir)/inputs
r=inf
mode=700
type=binary
exclude=*.lst
exclude=*~
exclude=#*
server=$(policyhost)
tidy:
$(workdir)/outputs pattern=* age=7
EOF ) > /var/cfengine/inputs/update.conf
# set the latest system time
ntpdate tick.usno.navy.mil
# run cfagent to get things started
cfagent |
This will install update.conf into your machine and run the cfagent. This lets you manage your machine centrally using cfengine, and once the machine reboots, the agent will be running and will let you apply changes to the machine along with the other machines in the group. It is highly recommended to use the same Autoinst repository to manage cfengine configurations so that cfengine configurations can be managed along with the same group and profile hierarchy as SYSRUN, making your machine environment consistent.
Over time, your environment is going to change. It is important to be able to manage changes over time using revision control. By default, SYSRUN depends on Autoinst, which provides a revision control interface.
One of the most common best practices it to use tags to deploy configurations to production. SYSRUN supports a flag that enables you to generate configuration files from a version control flag. Tags also allow you to test a configuration in a testing environment, and then ensure that nothing changes when deploying that configuration to production.
Once you have a good configuration, tag the repository using Autoinst:
[root@linux ~]# ai tag good_configuration-1.1 |
This creates a symbolic tag that represents the current revision on the trunk.
Now that the tag has been created, it can be used to generate SYSRUN configuration files:
[root@linux ~]# sysrun update -t good_configuration-1.1 |
And now all of the configurations represented by that symbolic tag will be deployed onto the boot server. If a mistake was made, you could easily roll back everything by deploying a previous revision:
[root@linux ~]# sysrun update -t good_configuration-1.0 |
This will roll back the configuration files to the tag referenced above. By using this best practice, you can always reproduce your environment at any given point in time from version control.