The system name, also called the hostname, is used in various aspects of the FB6000's functions, and so we recommend you set the hostname to something appropriate for your network.

The hostname is set using the name attribute.

The attributes shown in Table 4.3 allow you to specify general administrative details about the unit :-

The log and log-... attributes control logging of events related to the operation of the system itself. For details on event logging, please refer to Chapter 5, and for details on the logging control attributes on system object, please refer to Section 5.7.

The home page is the first page you see after logging in to the FB6000, or when you click the Home main-menu item. The home page displays the system name, and, if defined, the text specified by the intro attribute on the system object.

Additionally, you can define one or more web links to appear on the home page. These are defined using link objects, which are child objects of the system object.

To make a usable link, you must specify the following two attributes on the link object :-

Additionally, you can name a link, specify a comment, and make the presence of the link on the home page conditional on a profile.

The user settings on the firebrick have password control (as well as optional OTP). In the config this is entered as a simple password, but when accessed you will see that the password has been replaced with a hash.

The FireBrick supports a number of hash functions for passwords, but on any successful login may change and re-save the config to use the current preferred password hash function. This allows FireBrick to move to more secure password hash functions in future whilst maintaining backward compatibility.

If making a config file independantly you can generate the hashes yourself in most cases. The supported hash codings are as follows. For salted hashes, the salt is the additional bytes after the number of bytes for the hash.

The preferred hash is SHA256 with 15 bytes of salt.

The config also holds the OTP seed used for One Time Password authenticator codes. However, this is stored in an encrypted format so that the seed cannot be accessed.

You can enter a new OTP seed directing in to the otp-seed field if you wish. This should be a BASE32 string (which is the common format for usch strings). If the seed is for 60 second periods not the default 30 then append /30. If the seed is not for 6 digit codes, you can add a time (/30 or /60) and then /N where N is the number of digits (4-8). Once saved you will see the seed changes to a base64 coded string. If you do this you should immediately test the authenticator by logging in as the user. Until you do this the seed is not encrypted in the config and could be recovered.

The old OTP system used this field (called just otp) as the serial number of a separately stored OTP seed that was not held in the config. This is not longer supported, but if you have such a config you may see simply the serial number in this field until the user first logs in and it is replaced with the encrypted OTP seed.

Once encoded the format is a # followed by base64 coding of a series of bytes. It making a config file independantly then you can generate the seed data directly if you wish. The format is as follows.