Configuration File Template
Configuration File Template
The default configuration file template used by cdrouter-cli -new-config and cdrouter-cli -config XXX.conf -upgrade-config is
defined at the bottom of /usr/cdrouter/tests/config.dic with a
call to buddy::set_default_config_template. The template body is
Tcl script which is evaluated in a special namespace which ensures
that indentation and spacing is uniform and that testvar values are
quoted correctly (i.e. by wrapping them in double-quotes or braces as
necessary).
Sometimes it is helpful to include custom testvars defined by a custom
testpath in the configuration files generated by cdrouter-cli -new-config and cdrouter-cli -upgrade-config. This can be done
with a call to buddy::append_default_config_template at the bottom
of a testpath’s config.dic file. This call takes the same
configuration file template syntax as
buddy::set_default_config_template. For example, the following
config.dic file would define two custom testvars, myCustomTestvar
and myOtherCustomTestvar and append them to the default
configuration file template inside a section titled My Custom Section:
buddy::testvar_define myCustomTestvar {
type { word }
default someValue
}
buddy::testvar_define myOtherCustomTestvar {
type { word }
default someOtherValue
}
buddy::append_default_config_template {
SECTION "My Custom Section" {
.
testvar myCustomTestvar
testvar myOtherCustomTestvar
.
}
}
Template Commands
comment
comment TEXT
Appends a comment to the config containing the string TEXT. For
example:
comment "This is a comment"
comment "This is another comment"
would generate the following output:
# This is a comment
# This is another comment
. (period)
.
Inserts a blank line in the config template. For example:
comment "This is a comment"
.
.
comment "This is another comment"
would generate the following output:
# This is a comment
# This is another comment
testvar
testvar NAME...
Appends to the config a definition for testvar NAME with its current
value.
If NAME is a list of testvar names and the first name is a wildcard
testvar, all instances of those testvars will be appended.
Testvar definitions will be commented out unless the current value of the testvar is not the default value.
Testvars with a deprecated field in their status property will not
be printed.
For example, assume myFirstTestvar is set to its default value,
mySecondTestvar is not, and the myWildcard wildcard testvar set
has three instances set. Then the following script:
testvar myFirstTestvar
testvar mySecondTestvar
.
testvar {
myWildcardFoo
myWildcardBar
myWildcardQux
}
would generate the following output:
# testvar myFirstTestvar aDefaultValue
testvar mySecondTestvar aNonDefaultValue
testvar myWildcardFoo1 aNonDefaultValue
testvar myWildcardBar1 aNonDefaultValue
testvar myWildcardQux1 aNonDefaultValue
testvar myWildcardFoo2 aNonDefaultValue
testvar myWildcardBar2 aNonDefaultValue
testvar myWildcardQux2 aNonDefaultValue
testvar myWildcardFoo3 aNonDefaultValue
testvar myWildcardBar3 aNonDefaultValue
testvar myWildcardQux3 aNonDefaultValue
wildcard_ending
wildcard_ending
This command should only be used inside the SCRIPT argument of the
wildcard_testvars command. It returns the instance number
(i.e. 1, 2, 3, etc) of the wildcard testvar being appended to
the config.
wildcard_example
wildcard_example
This command should only be used inside the SCRIPT argument of the
wildcard_testvars command. It returns non-zero if the wildcard
testvar being appended to the config should be an example as opposed
to a user-defined instance from a config being upgraded.
wildcard_testvars
wildcard_testvars NAME SCRIPT
Evaluates SCRIPT for each instance of the master wildcard testvar
NAME. The wildcard_example and wildcard_ending commands can be
used along with all other template commands to append to the config
all testvars associated with each instance of the master wildcard
testvar.
This command can be used instead of passing a list of associated
wildcard testvars to the testvars command in instances where you
want greater control over how wildcard testvars are displayed in the
config file.
Below is an example that uses the wildcard_testvars,
wildcard_ending and wildcard_example commands. Note how we use
wildcard_example to determine if all the testvars should be printed
or only those for manual/IKE IPsec tunnels. We use a combination of
buddy::getvar and wildcard_ending to determine the type of IPsec
tunnel using the ipsecTunnelKeyType testvar so we can display only
testvars relevant to that type of tunnel.
wildcard_testvars ipsecTunnelEndpoint {
SECTION "IPsec Tunnel Configuration [ wildcard_ending ]" {
.
testvar ipsecTunnelKeyType
testvar ipsecTunnelEndpoint
testvar ipsecTunnelRemoteNetwork
testvar ipsecTunnelRemoteMask
testvar ipsecTunnelHost
.
if { [ wildcard_example ] ||
[ buddy::getvar ipsecTunnelKeyType[ wildcard_ending ] ] == "manual" } {
SECTION "Manual IPsec Tunnel Configuration" {
.
testvar ipsecTunnelOutboundSpi
testvar ipsecTunnelOutEncrypt
testvar ipsecTunnelOutEncryptKey
testvar ipsecTunnelOutAuth
testvar ipsecTunnelOutAuthKey
testvar ipsecTunnelInboundSpi
testvar ipsecTunnelInEncrypt
testvar ipsecTunnelInEncryptKey
testvar ipsecTunnelInAuth
testvar ipsecTunnelInAuthKey
.
}
}
if { [ wildcard_example ] } { . }
if { [ wildcard_example ] ||
[ buddy::getvar ipsecTunnelKeyType[ wildcard_ending ] ] == "ike" } {
SECTION "IKE IPsec Tunnel Configuration" {
.
testvar ipsecTunnelIkeEncrypt
testvar ipsecTunnelIkeAuth
testvar ipsecTunnelIkeGroup
testvar ipsecTunnelIkeLifetime
testvar ipsecTunnelEncrypt
testvar ipsecTunnelAuth
testvar ipsecTunnelPfsGroup
testvar ipsecTunnelLifetime
testvar ipsecTunnelPsk
testvar ipsecTunnelIkeMode
testvar ipsecTunnelUsesNat
.
}
}
.
}
}
When generating a new config (i.e. when wildcard_example will return
true), the above script would generate the following output:
SECTION "IPsec Tunnel Configuration [ wildcard_ending ]" {
# testvar ipsecTunnelKeyType1
# testvar ipsecTunnelEndpoint1
# testvar ipsecTunnelRemoteNetwork1
# testvar ipsecTunnelRemoteMask1
# testvar ipsecTunnelHost1
SECTION "Manual IPsec Tunnel Configuration" {
# testvar ipsecTunnelOutboundSpi1
# testvar ipsecTunnelOutEncrypt1
# testvar ipsecTunnelOutEncryptKey1
# testvar ipsecTunnelOutAuth1
# testvar ipsecTunnelOutAuthKey1
# testvar ipsecTunnelInboundSpi1
# testvar ipsecTunnelInEncrypt1
# testvar ipsecTunnelInEncryptKey1
# testvar ipsecTunnelInAuth1
# testvar ipsecTunnelInAuthKey1
}
SECTION "IKE IPsec Tunnel Configuration" {
# testvar ipsecTunnelIkeEncrypt1
# testvar ipsecTunnelIkeAuth1
# testvar ipsecTunnelIkeGroup1
# testvar ipsecTunnelIkeLifetime1
# testvar ipsecTunnelEncrypt1
# testvar ipsecTunnelAuth1
# testvar ipsecTunnelPfsGroup1
# testvar ipsecTunnelLifetime1
# testvar ipsecTunnelPsk1
# testvar ipsecTunnelIkeMode1
# testvar ipsecTunnelUsesNat1
}
}
However, if cdrouter-cli -upgrade-config is run on a config with the
following testvars defined:
testvar ipsecTunnelEndpoint1 5.0.0.1
testvar ipsecTunnelKeyType1 manual
testvar ipsecTunnelRemoteNetwork1 5.0.0.0
testvar ipsecTunnelRemoteMask1 255.255.255.0
testvar ipsecTunnelHost1 5.0.0.2
testvar ipsecTunnelOutboundSpi1 1000
testvar ipsecTunnelOutEncrypt1 des
testvar ipsecTunnelOutEncryptKey1 0102030405060708
testvar ipsecTunnelOutAuth1 md5-hmac
testvar ipsecTunnelOutAuthKey1 6262626262626262
testvar ipsecTunnelInboundSpi1 1001
testvar ipsecTunnelInEncrypt1 des
testvar ipsecTunnelInEncryptKey1 0102030405060708
testvar ipsecTunnelInAuth1 md5-hmac
testvar ipsecTunnelInAuthKey1 6262626262626262
testvar ipsecTunnelEndpoint2 5.0.0.1
testvar ipsecTunnelKeyType2 ike
testvar ipsecTunnelRemoteNetwork2 5.0.0.0
testvar ipsecTunnelRemoteMask2 255.255.255.0
testvar ipsecTunnelHost2 5.0.0.2
testvar ipsecTunnelIkeEncrypt2 des
testvar ipsecTunnelIkeAuth2 md5-hmac
testvar ipsecTunnelIkeGroup2 1
testvar ipsecTunnelIkeLifetime2 300
testvar ipsecTunnelEncrypt2 3des
testvar ipsecTunnelAuth2 sha1-hmac
testvar ipsecTunnelPfsGroup2 1
testvar ipsecTunnelLifetime2 120
testvar ipsecTunnelPsk2 qacafe123
testvar ipsecTunnelIkeMode2 main
testvar ipsecTunnelUsesNat2 no
then the above script would generate the following output:
SECTION "IPsec Tunnel Configurations" {
SECTION "IPsec Tunnel Configuration 1" {
# testvar ipsecTunnelKeyType1 manual
testvar ipsecTunnelEndpoint1 5.0.0.1
testvar ipsecTunnelRemoteNetwork1 5.0.0.0
testvar ipsecTunnelRemoteMask1 255.255.255.0
testvar ipsecTunnelHost1 5.0.0.2
SECTION "Manual IPsec Tunnel Configuration" {
testvar ipsecTunnelOutboundSpi1 1000
testvar ipsecTunnelOutEncrypt1 des
testvar ipsecTunnelOutEncryptKey1 0102030405060708
testvar ipsecTunnelOutAuth1 md5-hmac
testvar ipsecTunnelOutAuthKey1 6262626262626262
testvar ipsecTunnelInboundSpi1 1001
testvar ipsecTunnelInEncrypt1 des
testvar ipsecTunnelInEncryptKey1 0102030405060708
testvar ipsecTunnelInAuth1 md5-hmac
testvar ipsecTunnelInAuthKey1 6262626262626262
}
}
SECTION "IPsec Tunnel Configuration 2" {
testvar ipsecTunnelKeyType2 ike
testvar ipsecTunnelEndpoint2 5.0.0.1
testvar ipsecTunnelRemoteNetwork2 5.0.0.0
testvar ipsecTunnelRemoteMask2 255.255.255.0
testvar ipsecTunnelHost2 5.0.0.2
SECTION "IKE IPsec Tunnel Configuration" {
testvar ipsecTunnelIkeEncrypt2 des
testvar ipsecTunnelIkeAuth2 md5-hmac
testvar ipsecTunnelIkeGroup2 1
testvar ipsecTunnelIkeLifetime2 300
testvar ipsecTunnelEncrypt2 3des
testvar ipsecTunnelAuth2 sha1-hmac
testvar ipsecTunnelPfsGroup2 1
testvar ipsecTunnelLifetime2 120
testvar ipsecTunnelPsk2 qacafe123
testvar ipsecTunnelIkeMode2 main
testvar ipsecTunnelUsesNat2 no
}
}
}
SECTION
SECTION NAME SCRIPT
Appends a SECTION block NAME to the config, increasing indentation
by one unit while SCRIPT is evaluated. For example, assume the
testvars myFirstTestvar, mySecondTestvar and myThirdTestvar were
set to non-default values 1, 2 and 3, respectively. Then the
following script:
SECTION "My Example Section" {
.
testvar myFirstTestvar
testvar mySecondTestvar
testvar myThirdTestvar
.
}
would generate the following output:
SECTION "My Example Section" {
testvar myFirstTestvar 1
testvar mySecondTestvar 2
testvar myThirdTestvar 3
}
testvar_group
testvar_group NAME... SCRIPT
Appends to the config a definition for the testvar_groups in NAME,
evaluating SCRIPT as the template containing the testvars to show in
the testvar_group. Indentation is increased by one unit while
SCRIPT is evaluated. It will also append any additional
testvar_groups which haven’t already been printed that are defined
and match the pattern of NAME. For example, assume the
testvar_group myGroup is defined and the testvars
myFirstTestvar, mySecondTestvar and myThirdTestvar are set to
their default values. Then the following script:
testvar_group myGroup {
.
testvar myFirstTestvar
testvar mySecondTestvar
testvar myThirdTestvar
.
}
would generate the following output:
testvar_group myGroup {
# testvar myFirstTestvar 1
# testvar mySecondTestvar 2
# testvar myThirdTestvar 3
}
For an example of printing additional testvar_groups which match the
pattern of NAME, assume myGroup2, myGroup3 and myGroup4 are
all defined testvar_groups. Then the following script:
testvar_group myGroup2 {
.
testvar myTestvar
.
}
would generate the following output:
testvar_group myGroup2 {
# testvar myTestvar 1
}
testvar_group myGroup3 {
# testvar myTestvar 1
}
testvar_group myGroup4 {
# testvar myTestvar 1
}
If you wish to ensure multiple testvar_groups get printed even if a
group with that pattern is not defined, give NAME as a list of
testvar_groups. For example, if myGroup2 is defined but
myGroup3 is not defined, the following script:
testvar_group { myGroup2 myGroup3 } {
.
testvar myTestvar
.
}
would generate the following output:
testvar_group myGroup2 {
# testvar myTestvar 1
}
IGNORE testvar_group myGroup3 {
# testvar myTestvar 1
}
note that testvar_group myGroup3 was outputted with the IGNORE
keyword because it was not defined.
If a testvar_group being printed contains defined testvars which
have not been printed after SCRIPT is evaluated, they will be
printed in a “Miscellaneous Testvars” SECTION block at the bottom of
the testvar_group.
testvar_misc
testvar_misc [ GROUP ]
Appends to the config any testvars defined in testvar_group GROUP
that have not already by printed. If GROUP is not given and
testvar_misc is being evaluated as part of the SCRIPT of a
testvar_group invocation, GROUP will default to the name of
testvar_group currently being printed. Otherwise, GROUP will
default to main.
testvar_group_misc
testvar_group_misc
Appends to the config any defined testvar_groups that have not
already by printed.
pre_post_test_commands
Appends to the config all pre- and post-test commands defined by calls
to buddy::pre_test_command and buddy::post_test_command. Commands
are sorted by testcase name, with the pre-test command (if one exists)
coming before the post-test command for each testcase. For example,
the following commands:
buddy::pre_test_command cdrouter_basic_1 {
Event_wait_seconds 10
}
buddy::pre_test_command cdrouter_basic_2 {
Event_wait_seconds 10
}
buddy::pre_test_command cdrouter_basic_100 {
Event_wait_seconds 10
}
buddy::post_test_command cdrouter_basic_100 {
Event_wait_seconds 20
}
buddy::post_test_command cdrouter_basic_3 {
Event_wait_seconds 10
}
buddy::post_test_command cdrouter_basic_1 {
Event_wait_seconds 20
}
would generate the following output:
buddy::pre_test_command cdrouter_basic_1 {
Event_wait_seconds 10
}
buddy::post_test_command cdrouter_basic_1 {
Event_wait_seconds 20
}
buddy::pre_test_command cdrouter_basic_2 {
Event_wait_seconds 10
}
buddy::post_test_command cdrouter_basic_3 {
Event_wait_seconds 10
}
buddy::pre_test_command cdrouter_basic_100 {
Event_wait_seconds 10
}
buddy::post_test_command cdrouter_basic_100 {
Event_wait_seconds 20
}
