In the web user interface, profiles are created and edited by clicking on the "Profiles" category icon. A profile is defined by a profile
top-level object.
The following timing control parameters apply :-
interval
: the interval between tests being performedtimeout
: the duration that the overall test must have been failing for before the profile state changes to Inactiverecover
: the duration that the overall test must have been passing for before the profile state changes to ActiveThe timeout
and recover
parameters do not apply to manually set profiles (see Section 9.2.4)
and those based on time-of-day (see Section 9.2.2.2).
'General' tests are provided for the following :-
fb105
attribute lists one or more FB105 tunnel names (see Section 11.2) - if
any of the specified tunnels are in the Active state, this tunnel-state test will passroute
attributes lists one or more IP addresses (full addresses, not CIDR prefix ranges) - only if
all the addresses are 'routeable' - i.e. there is an entry in the routing table that will match that address - will this test pass. Refer to
Chapter 8 for discussion of routing tables and the routing logic used by the FB6000dhcp
attributes lists one or more IPv4 addresses (full addresses, not CIDR prefix ranges) or names - if
any of the listed names or IPs has a current DHCP lease issued, then this test will passvrrp
attribute lists one or more Virtual Router group membership definitions (see Chapter 14) by name - if
the FB6000 is not the master device in any of these Virtual Routers, this test will failports
attribute lists one of more physical Ethernet ports. If any of these ports is up then the test passes.
If more than one of these general tests is selected (corresponding attribute specified), then they must all pass (along with all other tests defined) for the overall result to be pass.
Time and/or date tests are specified by date
and/or time
objects, which are
child objects of the profile
object.
You can define multiple date ranges via multiple date
objects - the date test will pass if the current date is within any
of the defined ranges. Similarly, you can define multiple time ranges via multiple time
objects - the time test will pass if the current time is within any
of the defined ranges.
Like time/date tests, a Ping test is specified by a ping
object, as a child of the profile
object.
At most one Ping test can be defined per profile - logical combinations of profiles can be used to combine Ping tests if necessary.
The tests described in the previous section are used to form an overall test result. Normally this overall result is used to determine the profile
state using the mapping Pass > Active and Fail > Inactive. By setting the invert
attribute to true
, the overall result
is inverted (Pass changed to Fail and vice-versa) first before applying the mapping.
You can manually override all tests, and force the profile state using the set
attribute - a value of true
forces the state to Active, and false
forces it to Inactive.
You can also configure the set
attribute with a value of control-switch
. This causes the profile to be set manually
based on a control switch which is not stored in the configuration itself.
The switch appears on the home web page and in the menu allowing it to be turned on or off with one click. It can also be changed from the command line.
You can restrict each switch to one or more specific users to define who has control of the switch. This control applies even if the user has no access to make configuration changes as the switch is not part of the config.
The switch state is automatically stored in the dynamic peristent data (along with DHCP settings, etc), so survives a power cycle / restart.
The control switch uses initial
as the initial state when first added to the config, but on boot it uses the state from the persistent data.
It is also possible to set the control-switch-locks config option to prevent the profile accidentally being toggled in the web UI.
These profiles can be used as simple on/off controls for configuration objects. The following shows an example of two fixed-state profiles and one control switch, expressed in XML :-
<profile name="Off" set="false"/> <profile name="On" set="true"/> <profile name="IT-Support" comment="Allow IT support company access to server" set="control-switch"/>
and
, or
and not
settings - these have the effect of forcing the control switch one way. E.g. if an and
profile is off then the control switch
is forced off. If it is on then the control switch can be manually set on or off as needed.Note that the value of the invert
attribute is ignored when manual override is requested.
If we add special case switched profiles that are used internally, these will be named starting with fb-
, so it is best not to name your own profiles starting fb-
.
An example of the ACME renewal control profile is given below.
control-switch
profile which has fb-
followed by the name of the CA certificate authority, e.g. fb-letsencrypt.org
will be activated at the start of the validation phase, and deactivated at the end. This profile can therefore be used to change firewall rules, etc, to allow ACME access to validate the certificate. You can set invert
to reverse the operation of the switch. Use with care.
As with many things in the FireBrick it is possible to script access to the control pages. The control profiles are a particularly useful example of this as it allows external scripts to control if a profile is active or inactive.
Obviously security is a concern, and it is possible to create a user allowed access only from some IP addresses, and even allowed NOBODY level access, but listed as a user allowed to set a specific control profile. This then allows a script using a username and password to control the profile from specific machines.
For example, setting a named profile:-
curl --silent --user name:pass 'http://1.2.3.4/profile?set=profilename'
And unsetting a named profile:-
curl --silent --user name:pass 'http://1.2.3.4/profile?unset=profilename'