As part of our dive in to specific features of the FireBrick, in this article we are going to look at 'Profiles'.
The FireBrick manual describes profiles as:
A profile is a two-state control entity - it is either Active or Inactive ("On" or "Off", like a switch). Once a profile is defined, it can be referenced in various configuration objects where the profile state will control the behaviour of that object. - FireBrick Manual
Nearly every element in the configuration of a FireBrick can be controlled with a profile. Once a profile is configured, it will be shown in the 'profile' dropdown all over the configuration interface.
Profiles can be a manual control switch - and will then appear as a button on the FireBrick's web interface. You can then enable or disable parts of the configuration manually. These can even be controlled by external scripts.
A profile's state is determined by one or more defined tests, which are performed periodically. If multiple tests are specified, then the overall test result will be pass only if all the individual test results are pass. Assuming the profile's state is Active, then when the overall test result has been 'fail' for a specified duration, the profile transitions to Inactive. Similary, once the overall test result has been 'pass' for a specified duration, the profile transitions to Active. These two durations are controlled by attributes and provide a means to 'filter' out short duration 'blips' that are of little interest.
Profiles can be logically combined using familiar boolean terminology i.e. AND, OR and NOT, allowing for some complex profile logic to be defined that determines a final profile state from several conditions. When considering the state of another profile, it is the previous second's state that is considered - i.e. profile states are all updated in one go after considering all profiles.
By combining profiles with the FB2900's event logging facilities, they can also be used for automated monitoring and reporting purposes, where profile state changes can be e-mailed direct from the FB2900. For example, a profile using a Ping test can be used to alert you via e-mail when a destination is unreachable. The profile logic tests are also done based on the defined interval.
A profile can be based upon many things, and they can also be combined with AND, OR, NOT logic to make create more powerful functions.
A profile can be set by:
Most configuration elements can be controlled with a profile, and the status LED can be controlled too! If you want your LED to go blue and night and green during the day, then this is possible! More useful things can be controlled though.
This is not an exhaustive list, as there are lots of things, but here are the main elements that can be controlled with a profile:
Here is an example of a simple ICMP ping. We create a profile called PingGateway, set the IP we want to ping, and that's it. We can now see the status of the profile, and can use this profile in our configuration. Perhaps we can change the routing to use an alternative gateway if the ping stops and set the LED to be red.
Typically, profiles are used to create fail-over logic so that backup routes to the internet are used in the event of the main internet connection failing. As you can see, with profiles and your imagination, a lot of automated logic can be applied to make a FireBrick configuration dynamic and adapt to changes in it's environment.
As with many things in the FireBrick, it is possible to script access to profiles. The control switches are a particularly useful example of this as it allows external scripts to control if a profile is active or inactive.
Example:
curl --user name:pass 'http://1.2.3.4/profile?set=profilename'
Further information in the manuals.
