8.2. Creating/editing profiles

8.2. Creating/editing profiles
	Chapter 8. Profiles

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.

8.2.1. Timing control

The following timing control parameters apply :-

interval : the interval between tests being performed
timeout : the duration that the overall test must have been failing for before the profile state changes to Inactive
recover : the duration that the overall test must have been passing for before the profile state changes to Active

The timeout and recover parameters do not apply to manually set profiles (see Section 8.2.4) and those based on time-of-day (see Section 8.2.2.2).

8.2.2. Tests

8.2.2.1. General tests

'General' tests are provided for the following :-

Routable addresses : the route 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 7 for discussion of routing tables and the routing logic used by the FB6000
DHCP addresses : the dhcp 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 pass
VRRP state : the vrrp attribute lists one or more Virtual Router group membership definitions (see Chapter 12) by name - if the FB6000 is not the master device in any of these Virtual Routers, this test will fail
Port state : the ports attribute lists one of more physical Ethernet ports. If any of these ports is up then the test passes.
Tip
You can also control port state with a profile, so you could have a port come up if another port is down to create a fallback arrangement.

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.

8.2.2.2. Time/date tests

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.

Tip

Unlike other tests, the change of state due to a date/time test takes effect immediately rather than waiting for several seconds to confirm it is still Saturday or some such.

8.2.2.3. Ping tests

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.

Note

A ping of IPv4 address 0.0.0.0 is a special case, which causes a ping of the gateway address.

8.2.3. Inverting overall test result

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.

8.2.4. Manual override

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.

8.2.4.1. Control Switches

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"/>

Note

The control switches ignore other tests, just like other manual settings, but can be combined with 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.

Note

There is a special case where profiles can be used to interact with the ACME certificate management. A 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.

8.2.5. Scripting

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'