Scheduling BIG-IP Configuration Backups via the GUI with an iApp

Beginning with BIG-IP version 11, the idea of templates has not only changed in amazing and powerful ways, it has been extended to be far more than just templates. The replacement for templates is called iApp^TM. But to call the iApp^TM just a template would be woefully inaccurate and narrow. It does templates well, and takes the concept further by allowing you to re-enter a templated application and make changes. Previously, deploying an application via a template was sort of like the Ron Popeil rotisserie: “Set it, and forget it!” Once it was executed, the template process was over, it was up to you to track and potentially clean up all those objects. Now, the application service you create based on an iApp^TM template effectively “owns” all the objects it created, so any change to the deployment adds/changes/deletes objects as necessary. The other exciting change from the template perspective is the idea of strictness. Once an application service is configured, any object created that is owned by that service cannot be changed outside of the service itself. This means that if you want to add a pool member, it must be done within the application service, not within the pool. You can turn this off, but what a powerful protection of your services!

Update for v11.2 - https://devcentral.f5.com/s/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1090565/Archiving-BIG-IP-Configurations-with-an-iApp-in-v112.aspx

The Problem

I received a request from one of our MVPs that he’d really like to be able to allow his users to schedule configuration backups without dropping to the command line. Knowing that the iApp^TM feature was releasing soon with version 11, I started to see how I might be able to coax a command line configuration from the GUI. In training, I was told that “anything you can do in tmsh, you can do with an iApp^TM.” This is excellent, and the basis for why I think they are going to be incredibly popular for not only controlling and managing applications, but also for extending CLI functions to the GUI. Anyway, so in order to schedule a configuration backup, I need:

A backup script
A cron job to call said script

That’s really all there is to it.

The Solution

Thankfully, the background work is already done courtesy of a config backup codeshare entry by community user Colin Stubbs in the Advanced Design & Config Wiki. I did have to update the following bigpipe lines from the script:

bigpipe export oneline “${SCF_FILE}” to tmsh save /sys config one-line file “${SCF_FILE}”

bigpipe export “${SCF_FILE}” to tmsh save /sys config file "${SCF_FILE}"

bigpipe config save “${UCS_FILE}” passphrase “${UCS_PASSPHRASE}” to tmsh save /sys ucs "${UCS_FILE}" passphrase "${UCS_PASSPHRASE}"

bigpipe config save “${UCS_FILE}” to tmsh save /sys ucs "${UCS_FILE}"

Also, I created (according the script comments from the codeshare entry) a /var/local/bin directory to place the script and a /var/local/backups directory for the script to dump the backup files in. These are optional and can be changed as necessary in your deployment, you’ll just need to update the script to reflect your file system preferences. Now that I have everything I need to support a backup, I can move on to the iApp^TM template configuration.

iApp^TM Components

A template consists of three parts: implementation, presentation, and help. You can create an empty template, or just start with presentation or help if you like.

The implementation is tmsh script language, based on the Tcl language so loved by all of us iRulers. Please reference the tmsh wiki for the available tmsh extensions to the Tcl language.
The presentation is written with the Application Presentation Language, or APL, which is new and custom-built for templates. It is defined on the APL page in the iApp^TM wiki.
The help is written in HTML, and is used to guide users in the use of the template.

I’ll focus on the presentation first, and then the implementation. I’ll forego the help section in this article.

Presentation

The reason I’m starting with the presentation section of the template is that the implementation section’s Tcl variables reflect the presentation methods naming conventions. I want to accomplish a few things in the template presentation:

Ask users for the frequency of backups (daily, weekly, monthly)
If weekly, ask for the day of the week
If monthly, ask for the day of the month and provide a warning about days 29-31
For all frequencies, ask for the hour and minute the backup should occur

The APL code for this looks like this:

section time_select {

  choice day_select display "large" { "Daily", "Weekly", "Monthly" }

  optional ( day_select == "Weekly" ) {

    choice dow_select display "medium" { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" }

  optional ( day_select == "Monthly" ) {

    message dom_warning "The day of the month should be the 1st-28th.  Selecting the 29th-31st will result in missed backups on some months."

    choice dom_select display "medium" tcl {

      for { set x 1 } { $x < 32 } { incr x } {

        append dom "$x\n"

      return $dom

  choice hr_select display "medium" tcl {

    for { set x 0 } { $x < 24 } { incr x} {

      append hrs "$x\n"

    return $hrs

  choice min_select display "medium" tcl {

    for { set x 0 } { $x < 60 } { incr x } {

      append mins "$x\n"

    return $mins

text {

  time_select "Backup Schedule"

  time_select.day_select "Choose the frequency the backup should occur:"

  time_select.dow_select "Choose the day of the week the backup should occur:"

  time_select.dom_warning "WARNING: "

  time_select.dom_select "Choose the day of the month the backup should occur:"

  time_select.hr_select "Choose the hour the backup should occur:"

  time_select.min_select "Choose the minute the backup should occur:"

A few things to point out. First, the sections (which can’t be nested) provide a way to set apart functional differences in your form. I only needed one here, but it’s very useful if I were to build on and add options for selecting a UCS or SCF format, or specifying a mail address for the backups to be mailed to. Second, order matters. The objects will be displayed in the template as you define them. Third, the optional command allows me to hide questions that wouldn’t make sense given previous answers. If you dig into some of the canned templates shipping with v11, you’ll also see another use case for the optional command. Fourth, you can use Tcl commands to populate fields for you. This can be generated data like I did above, or you can loop through configuration objects to present in the template as well. Finally, the text section is where you define the language you want to appear with each of your objects. The nomenclature here is section.variable. To give you an idea what this looks like, here is a screenshot of a monthly backup configuration:

Once my template (f5.archiving) is saved, I can configure it in the Application Services section by selecting the template. At this point, I have a functioning presentation, but with no implementation, it’s effectively useless.

Implementation

Now that the presentation is complete, I can move on to an implementation. I need to do a couple things in the implementation:

Grab the data entered into the application service
Convert the day of week information from long name to the appropriate 0-6 (or 1-7) number for cron
Use that data to build a cron file (statically assigned at this point to /etc/cron.d/f5backups)

Here is the implementation section:

array set dow_map {
Sunday 0
Monday 1
Tuesday 2
Wednesday 3
Thursday 4
Friday 5
Saturday 6
}

set hr $::time_select__hr_select
set min $::time_select__min_select

set infile [open "/etc/cron.d/f5backups" "w" "0755"]

puts $infile "SHELL=\/bin\/bash"
puts $infile "PATH=\/sbin:\/bin:\/usr\/sbin:\/usr\/bin"
puts $infile "#MAILTO=user@somewhere"
puts $infile "HOME=\/var\/tmp\/"
if { $::time_select__day_select == "Daily" } {
puts $infile "$min $hr * * * root \/bin\/bash \/var\/local\/bin\/f5backup.sh 1>\/var\/tmp\/f5backup.log 2>\&1"
} elseif { $::time_select__day_select == "Weekly" } {
puts $infile "$min $hr * * $dow_map($::time_select__dow_select) root \/bin\/bash \/var\/local\/bin\/f5backup.sh 1>\/var\/tmp\/f5backup.log 2>\&1"
} elseif { $::time_select__day_select == "Monthly" } {
puts $infile "$min $hr $::time_select__dom_select * * root \/bin\/bash \/var\/local\/bin\/f5backup.sh 1>\/var\/tmp\/f5backup.log 2>\&1"
}

close $infile

A few notes:

The dow_map array is to convert the selected day (ie, Saturday) to a number for cron (6).
The variables in the implementation section reference the data supplied from the presentation like so:
1. $::<section>__<presentation variable name> (Note the double underscore between them. As such, DO NOT use double underscores in your presentation variables)
tmsh special characters need to be escaped if you’re using them for strings.

A succesful configuration of the application service results in this file configuration for /etc/cron.d/f5backups:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
#MAILTO=user@somewhere
HOME=/var/tmp/
54 15 * * * root /bin/bash /var/local/bin/f5backup.sh 1>/var/tmp/f5backup.log 2>&1

So this backup is scheduled to run daily at 15:54. This is confirmed with this directory listing on my BIG-IP:

[root@golgotha:Active] bin # ls -las /var/local/backups
total 2168
8 drwx------ 2 root root 4096 Aug 16 15:54 .
8 drwxr-xr-x 9 root root 4096 Aug 3 14:44 ..
1076 -rw-r--r-- 1 root root 1091639 Aug 15 15:54 f5backup-golgotha.test.local-20110815155401.tar.bz2
1076 -rw-r--r-- 1 root root 1092259 Aug 16 15:54 f5backup-golgotha.test.local-20110816155401.tar.bz2

Conclusion

This is just scratching the surface of what can be done with the new iApp^TM feature in v11. I didn’t even cover the ability to use presentation and implementation libraries, but that will be covered in due time. If you’re impatient, there are already several examples (including this one here) in the codeshare.

Related Articles

Published Aug 16, 2011

Version 1.0