4. System¶

4.1. Information¶

System → Information displays general information about the TrueNAS^® system. An example is seen in Figure 4.1.1.

The information includes the hostname, the build version, type of CPU (platform), the amount of memory, the current system time, the system’s uptime, the number of users connected at the console or by serial, telnet, or SSH connections, and the current load average. On servers supplied or certified by iXsystems, an additional Serial Number field showing the hardware serial number is displayed.

To change the system’s hostname, click the Edit button, type in the new hostname, and click OK. The hostname must include the domain name. If the network does not use a domain name, add .local after the hostname.

Fig. 4.1.1 System Information Tab

4.2. General¶

System → General is shown in Figure 4.2.1.

Fig. 4.2.1 General Screen

Table 4.2.1 summarizes the settings that can be configured using the General tab:

After making any changes, click the Save button.

This screen also contains these buttons:

Factory Restore: reset the configuration database to the default base version. However, this does not delete user SSH keys or any other data stored in a user’s home directory. Since any configuration changes stored in the configuration database will be erased, this option is useful when a mistake has been made or to return a test system to the original configuration.

Save Config: save a backup copy of the current configuration database in the format hostname-version-architecture to the computer accessing the administrative interface. Saving the configuration after making any configuration changes is highly recommended. TrueNAS^® automatically backs up the configuration database to the system dataset every morning at 3:45. However, this backup does not occur if the system is shut down at that time. If the system dataset is stored on the boot pool and the boot pool becomes unavailable, the backup will also not be available. The location of the system dataset can be viewed or set using System → System Dataset.

There are two types of passwords. User account passwords for the base operating system are stored as hashed values, do not need to be encrypted to be secure, and are saved in the system configuration backup. Other passwords, like iSCSI CHAP passwords or Active Directory bind credentials, are stored in an encrypted form to prevent them from being visible as plain text in the saved system configuration. The key or seed for this encryption is normally stored only on the boot device. When Save Config is chosen, a dialog gives the option to Export Password Secret Seed with the saved configuration, allowing the configuration file to be restored to a different boot device where the decryption seed is not already present. Configuration backups containing the seed must be physically secured to prevent decryption of passwords and unauthorized access.

Upload Config: allows browsing to the location of a previously saved configuration file to restore that configuration. The screen turns red as an indication that the system will need to reboot to load the restored configuration.

NTP Servers: The network time protocol (NTP) is used to synchronize the time on the computers in a network. Accurate time is necessary for the successful operation of time sensitive applications such as Active Directory or other directory services. By default, TrueNAS^® is pre-configured to use three public NTP servers. If your network is using a directory service, ensure that the TrueNAS^® system and the server running the directory service have been configured to use the same NTP servers.

Available NTP servers can be found at https://support.ntp.org/bin/view/Servers/NTPPoolServers. For time accuracy, choose NTP servers that are geographically close to the TrueNAS^® system’s physical location.

NTP servers are added by clicking on NTP Servers → Add NTP Server to open the screen shown in Figure 4.2.2. Table 4.2.2 summarizes the options available when adding an NTP server. ntp.conf(5) explains these options in more detail.

Fig. 4.2.2 Add an NTP Server

4.3. Boot¶

TrueNAS^® supports a ZFS feature known as multiple boot environments. With multiple boot environments, the process of updating the operating system becomes a low-risk operation. The updater automatically creates a snapshot of the current boot environment and adds it to the boot menu before applying the update. If the update fails, reboot the system and select the previous boot environment from the boot menu to instruct the system to go back to that system state.

As seen in Figure 4.3.1, two boot environments are created when TrueNAS^® is installed. The system will boot into the default boot environment and users can make their changes and update from this version. The other boot environment, named Initial-Install can be booted into if the system needs to be returned to a pristine, non-configured version of the installation.

If the Wizard was used, a third boot environment called Wizard-date is also created, indicating the date and time the Wizard was run.

Fig. 4.3.1 Viewing Boot Environments

Each boot environment entry contains this information:

• Name: the name of the boot entry as it will appear in the boot menu.
• Active: indicates which entry will boot by default if the user does not select another entry in the boot menu.
• Created: indicates the date and time the boot entry was created.
• Keep: indicates whether or not this boot environment can be pruned if an update does not have enough space to proceed. Click the entry’s Keep button if that boot environment should not be automatically pruned.

Highlight an entry to view its configuration buttons. These configuration buttons are shown:

• Rename: used to change the name of the boot environment.
• Keep/Unkeep: used to toggle whether or not the updater can prune (automatically delete) this boot environment if there is not enough space to proceed with the update.
• Clone: used to create a copy of the highlighted boot environment.
• Delete: used to delete the highlighted entry, which also removes that entry from the boot menu. Since you cannot delete an entry that has been activated, this button will not appear for the active boot environment. If you need to delete an entry that is currently activated, first activate another entry, which will clear the On reboot field of the currently activated entry. Note that this button will not be displayed for the default boot environment as this entry is needed in order to return the system to the original installation state.
• Activate: only appears on entries which are not currently set to Active. Changes the selected entry to the default boot entry on next boot. Its status changes to On Reboot and the current Active entry changes from On Reboot, Now to Now, indicating that it was used on the last boot but will not be used on the next boot.

The buttons above the boot entries can be used to:

• Create: a manual boot environment. A pop-up menu prompts for entry of a Name for the boot environment. When entering the name, only alphanumeric characters, underscores, and dashes are allowed.
• Scrub Boot: can be used to perform a manual scrub of the boot devices. By default, the boot device is scrubbed every 7 days. To change the default interval, change the number in the Automatic scrub interval (in days) field. The date and results of the last scrub are also listed in this screen. The condition of the boot device should be listed as HEALTHY.
• Status: click this button to see the status of the boot devices. Figure 4.3.2, shows only one boot device, which is ONLINE.

Fig. 4.3.2 Viewing the Status of the Boot Device

If one of the boot devices has a Status of OFFLINE, click the device to replace, select the new replacement device, and click Replace Disk to rebuild the boot mirror.

Figure 4.3.3 shows a sample boot menu.

Fig. 4.3.3 Boot Environments in Boot Menu

The first entry is the active boot environment, or the one that the system has been configured to boot into. To boot into a different boot environment, press the spacebar to pause this screen, use the down arrow to select Boot Environment Menu, and press Enter. A menu displays the other available boot environments. Use the up/down arrows to select the desired boot environment and press Enter to boot into it. To always boot into that boot environment, go to System → Boot, highlight that entry, and click the Activate button.

4.4. Advanced¶

System → Advanced is shown in Figure 4.4.1. The configurable settings are summarized in Table 4.4.1.

Fig. 4.4.1 Advanced Screen

Click the Save button after making any changes.

This tab also contains this button:

Save Debug: used to generate a text file of diagnostic information. After the debug data is collected, the system prompts for a location to save the generated ASCII text file.

4.5. Email¶

An automatic script sends a nightly email to the root user account containing important information such as the health of the disks. Alert events are also emailed to the root user account. Problems with Scrubs are reported separately in an email sent at 03:00AM.

The administrator typically does not read email directly on the TrueNAS^® system. Instead, these emails are usually sent to an external email address where they can be read more conveniently. It is important to configure the system so it can send these emails to the administrator’s remote email account so they are aware of problems or status changes.

The first step is to set the remote address where email will be sent. Select Users → View Users, click on root to highlight that user, then click Change E-mail. Enter the email address on the remote system where email is to be sent, like admin@example.com.

Additional configuration is performed with System → Email, shown in Figure 4.5.1.

Fig. 4.5.1 Email Screen

Click the Send Test Mail button to verify that the configured email settings are working. If the test email fails, double-check the destination email address by clicking the Change E-mail button for the root account in Account → Users → View Users. Test mail cannot be sent unless the root email address has been set.

Configuring email for TLS/SSL email providers is described in Are you having trouble getting FreeNAS to email you in Gmail?.

4.6. System Dataset¶

System → System Dataset, shown in Figure 4.6.1, is used to select the pool which will contain the persistent system dataset. The system dataset stores debugging core files and Samba4 metadata such as the user/group cache and share level permissions. If the TrueNAS^® system is configured to be a Domain Controller, all of the domain controller state is stored there as well, including domain controller users and groups.

Fig. 4.6.1 System Dataset Screen

The system dataset can optionally be configured to also store the system log and Reporting information. If there are lots of log entries or reporting information, moving these to the system dataset will prevent /var/ on the device holding the operating system from filling up as /var/ has limited space.

Use the drop-down menu to select the ZFS volume (pool) to contain the system dataset. Whenever the location of the system dataset is changed, a pop-up warning indicates that the SMB service must be restarted, causing a temporary outage of any active SMB connections.

To store the system log on the system dataset, check the Syslog box.

To store the reporting information on the system dataset, check the Reporting Database box. Note that if this box is unchecked, the system will automatically create a RAM disk to prevent reporting information from filling up /var.

If you make any changes, click the Save button to save them.

If you change the pool storing the system dataset at a later time, TrueNAS^® will automatically migrate the existing data in the system dataset to the new location.

4.7. Tunables¶

System → Tunables can be used to manage the following:

1. FreeBSD sysctls: a sysctl(8) makes changes to the FreeBSD kernel running on a TrueNAS^® system and can be used to tune the system.
2. FreeBSD loaders: a loader is only loaded when a FreeBSD-based system boots and can be used to pass a parameter to the kernel or to load an additional kernel module such as a FreeBSD hardware driver.
3. FreeBSD rc.conf options: rc.conf(5) is used to pass system configuration options to the system startup scripts as the system boots. Since TrueNAS^® has been optimized for storage, not all of the services mentioned in rc.conf(5) are available for configuration. Note that in TrueNAS^®, customized rc.conf options are stored in /tmp/rc.conf.freenas.

Since sysctl, loader, and rc.conf values are specific to the kernel parameter to be tuned, the driver to be loaded, or the service to configure, descriptions and suggested values can be found in the man page for the specific driver and in many sections of the FreeBSD Handbook.

To add a loader, sysctl, or rc.conf option, go to System → Tunables → Add Tunable, to access the screen shown in seen in Figure 4.7.1.

Fig. 4.7.1 Adding a Tunable

Table 4.7.1 summarizes the options when adding a tunable.

Any added tunables are listed in System → Tunables. To change the value of an existing tunable, click its Edit button. To remove a tunable, click its Delete button.

Restarting the TrueNAS^® system after making sysctl changes is recommended. Some sysctls only take effect at system startup, and restarting the system guarantees that the setting values correspond with what is being used by the running system.

The GUI does not display the sysctls that are pre-set when TrueNAS^® is installed. TrueNAS^® 11.0 ships with the following sysctls set:

kern.metadelay=3
kern.dirdelay=4
kern.filedelay=5
kern.coredump=0
net.inet.carp.preempt=1
debug.ddb.textdump.pending=1
vfs.nfsd.tcpcachetimeo=300
vfs.nfsd.tcphighwater=150000
vfs.zfs.vdev.larger_ashift_minimal=0
net.inet.carp.senderr_demotion_factor=0
net.inet.carp.ifdown_demotion_factor=0

Do not add or edit these default sysctls as doing so may render the system unusable.

The GUI does not display the loaders that are pre-set when TrueNAS^® is installed. TrueNAS^® 11.0 ships with these loaders set:

autoboot_delay="2"
loader_logo="truenas-logo"
loader_menu_title="Welcome to TrueNAS"
loader_brand="truenas-brand"
loader_version=" "
kern.cam.boot_delay="10000"
debug.debugger_on_panic=1
debug.ddb.textdump.pending=1
hw.hptrr.attach_generic=0
ispfw_load="YES"
module_path="/boot/kernel;/boot/modules;/usr/local/modules"
net.inet6.ip6.auto_linklocal="0"
vfs.zfs.vol.mode=2
kern.geom.label.disk_ident.enable="0"
hint.ahciem.0.disabled="1"
hint.ahciem.1.disabled="1"
kern.msgbufsize="524288"
kern.ipc.nmbclusters="262144"
kern.hwpmc.nbuffers="4096"
kern.hwpmc.nsamples="4096"
hw.memtest.tests="0"
vfs.zfs.trim.enabled="0"
kern.cam.ctl.ha_mode=2
kern.geom.label.ufs.enable=0
kern.geom.label.ufsid.enable=0
hint.ntb_hw.0.config="ntb_nvdimm:1:4:0,ntb_transport"
hint.ntb_transport.0.config=":3"
hw.ntb.msix_mw_idx="-1"

Do not add or edit the default tunables as doing so might make the system unusable.

The ZFS version used in 11.0 deprecates these tunables:

vfs.zfs.write_limit_override
vfs.zfs.write_limit_inflated
vfs.zfs.write_limit_max
vfs.zfs.write_limit_min
vfs.zfs.write_limit_shift
vfs.zfs.no_write_throttle

After upgrading from an earlier version of TrueNAS^®, these tunables are automatically deleted. Please do not manually add them back.

4.8. Update¶

TrueNAS^® has an integrated update system to make it easy to keep up to date.

4.8.2. Updates and Trains¶

TrueNAS^® is updated with signed update files. This provides flexibility in deciding when to upgrade the system with patches, new drivers, or new features. It also allows “test driving” an upcoming release. Combined with boot environments, new features or system patches can be tested while still being able to revert to a previous version of the operating system (see If Something Goes Wrong). Digital signing of update files eliminates the need to manually download both an upgrade file and the associated checksum to verify file integrity.

Figure 4.8.1 shows an example of the System → Update screen.

Fig. 4.8.1 Update Options

By default, the system automatically checks for updates and issues an alert when a new update becomes available. The automatic check can be disabled by unchecking Automatically check for updates.

This screen lists the URL of the official update server in case that information is needed in a network with outbound firewall restrictions. It also shows which software branch, or train, is being tracked for updates.

Several trains are available for updates.

Caution

Only Production trains are recommended for regular usage. Other trains are made available for pre-production testing and updates to legacy versions. Pre-production testing trains are provided only to permit testing of new versions before switching to a new branch. Before using a non-production train, be prepared to experience bugs or problems. Testers are encouraged to submit bug reports at https://redmine.ixsystems.com/projects/freenas/issues.

These trains are available:

For Production Use

• TrueNAS-11.0-STABLE (Recommended)

  After new fixes and features have been tested as production-ready, they are added to this train. It is recommended to follow this train and to apply any pending updates from it.

Legacy Versions

• TrueNAS-9.10-STABLE

  Maintenance-only updates for the previous branch of TrueNAS^®.

• TrueNAS-9.3-STABLE

  Maintenance-only updates for the older 9.3 branch of TrueNAS^®. Use this train only at the recommendation of an iX support engineer.

The Verify Install button verifies that the operating system files in the current installation do not have any inconsistencies. If any problems are found, a pop-up menu lists the files with checksum mismatches or permission errors.

4.8.9. Upgrading a ZFS Pool¶

In TrueNAS^®, ZFS pools can be upgraded from the graphical administrative interface.

Before upgrading an existing ZFS pool, be aware of these caveats first:

• the pool upgrade is a one-way street, meaning that if you change your mind you cannot go back to an earlier ZFS version or downgrade to an earlier version of the software that does not support those feature flags.
• before performing any operation that may affect the data on a storage disk, always back up all data first and verify the integrity of the backup. While it is unlikely that the pool upgrade will affect the data, it is always better to be safe than sorry.
• upgrading a ZFS pool is optional. Do not upgrade the pool if the the possibility of reverting to an earlier version of TrueNAS^® or repurposing the disks in another operating system that supports ZFS is desired. It is not necessary to upgrade the pool unless newer ZFS feature flags are required. If a pool is upgraded to the latest feature flags, it will not be possible to import that pool into another operating system that does not yet support those feature flags.

To perform the ZFS pool upgrade, go to Storage → Volumes → View Volumes and highlight the volume (ZFS pool) to upgrade. Click the Upgrade button as shown in Figure 4.8.2.

Note

If the Upgrade button does not appear, the pool is already at the latest feature flags and does not need to be upgraded.

Fig. 4.8.2 Upgrading a ZFS Pool

The warning serves as a reminder that a pool upgrade is not reversible. Click OK to proceed with the upgrade.

The upgrade itself only takes a few seconds and is non-disruptive. It is not necessary to stop any sharing services to upgrade the pool. However, it is best to upgrade when the pool is not being heavily used. The upgrade process will suspend I/O for a short period, but is nearly instantaneous on a quiet pool.

4.9. Cloud Credentials¶

TrueNAS^® can use cloud services for features like Cloud Sync. The credentials to provide secure connections with cloud services are entered here. Amazon S3, Azure Blob Storage, Backblaze B2, and Google Cloud Storage are supported.

Select System → Cloud Credentials → Add Cloud Credential to display the dialog shown in Figure 4.9.1.

Fig. 4.9.1 Adding Cloud Credentials

Enter a descriptive name for the cloud credential in the Account Name field, then select a provider. The remaining options vary by provider, and are shown in Table 4.9.1.

Additional fields are displayed after Provider is selected. For Amazon S3, Access Key and Secret Key are shown. These values can be can be found on the Amazon AWS website by clicking on the account name, then My Security Credentials and Access Keys (Access Key ID and Secret Access Key). Copy the Access Key value to the TrueNAS^® Cloud Credential Access Key field, then enter the Secret Key value saved when the key pair was created. If the Secret Key value is not known, a new key pair can be created on the same Amazon screen.

4.10. Alert Services¶

TrueNAS^® can use a number of methods to notify the administrator of system events that require attention. These events are system Alerts marked WARN or CRITICAL.

Currently available alert services:

• AWS-SNS
• Hipchat
• InfluxDB
• Slack
• Mattermost
• OpsGenie
• PagerDuty
• VictorOps

Select System → Alert Services to go to the Alert Services screen. Click Add Service to display the dialog shown in Figure 4.10.1.

Fig. 4.10.1 Add Alert Service

The Service Name drop-down menu is used to pick a specific alert service. The fields shown in the rest of the dialog change to those required by that service. Enter the required information, check the Enabled checkbox, then click OK to save the settings.

System alerts marked WARN or CRITICAL are sent to each alert service that has been configured and enabled.

Alert services can be deleted from this list by clicking them and then clicking the Delete button at the bottom of the window. To disable an alert service temporarily, click Edit and remove the checkmark from the Enabled checkbox.

4.11. CAs¶

TrueNAS^® can act as a Certificate Authority (CA). When encrypting SSL or TLS connections to the TrueNAS^® system, either import an existing certificate, or create a CA on the TrueNAS^® system, then create a certificate. This certificate will appear in the drop-down menus for services that support SSL or TLS.

For secure LDAP, the public key of an existing CA can be imported with Import CA, or a new CA created on the TrueNAS^® system and used on the LDAP server also.

Figure 4.11.1 shows the screen after clicking System → CAs.

Fig. 4.11.1 Initial CA Screen

If your organization already has a CA, the CA’s certificate and key can be imported. Click the Import CA button to open the configuration screen shown in Figure 4.11.2. The configurable options are summarized in Table 4.11.1.

Fig. 4.11.2 Importing a CA

To instead create a new CA, first decide if it will be the only CA which will sign certificates for internal use or if the CA will be part of a certificate chain.

To create a CA for internal use only, click the Create Internal CA button which will open the screen shown in Figure 4.11.3.

Fig. 4.11.3 Creating an Internal CA

The configurable options are described in Table 4.11.2. When completing the fields for the certificate authority, supply the information for your organization.

To instead create an intermediate CA which is part of a certificate chain, click the Create Intermediate CA button. This screen adds one more option to the screen shown in Figure 4.11.3:

• Signing Certificate Authority: this drop-down menu is used to specify the root CA in the certificate chain. This CA must first be imported or created.

Any CAs that you import or create will be added as entries in System → CAs. The columns in this screen indicate the name of the CA, whether it is an internal CA, whether the issuer is self-signed, the number of certificates that have been issued by the CA, the distinguished name of the CA, the date and time the CA was created, and the date and time the CA expires.

Clicking the entry for a CA causes these buttons to become available:

• Sign CSR: used to sign internal Certificate Signing Requests created using System → Certificates → Create Certificate Signing Request.
• Export Certificate: prompts to browse to the location to save a copy of the CA’s X.509 certificate on the computer being used to access the TrueNAS^® system.
• Export Private Key: prompts to browse to the location to save a copy of the CA’s private key on the computer being used to access the TrueNAS^® system. This option only appears if the CA has a private key.
• Delete: prompts for confirmation before deleting the CA.

4.12. Certificates¶

TrueNAS^® can import existing certificates, create new certificates, and issue certificate signing requests so that created certificates can be signed by the CA which was previously imported or created in CAs.

Figure 4.12.1 shows the initial screen after clicking System → Certificates.

Fig. 4.12.1 Initial Certificates Screen

To import an existing certificate, click the Import Certificate button to open the configuration screen shown in Figure 4.12.2. When importing a certificate chain, paste the primary certificate, followed by any intermediate certificates, followed by the root CA certificate.

On TrueNAS^® High Availability (HA) systems, the imported certificate must include the IP addresses or DNS hostnames of both nodes and the CARP virtual IP address. These IP addresses or DNS hostnames can be placed in the Subject Alternative Name (SAN) x509 extension field.

The configurable options are summarized in Table 4.12.1.

Fig. 4.12.2 Importing a Certificate

To instead create a new self-signed certificate, click the Create Internal Certificate button to see the screen shown in Figure 4.12.3. The configurable options are summarized in Table 4.12.2. When completing the fields for the certificate authority, use the information for your organization. Since this is a self-signed certificate, use the CA that was imported or created with CAs as the signing authority.

Fig. 4.12.3 Creating a New Certificate

If you need to use a certificate that is signed by an external CA, such as Verisign, instead create a certificate signing request. To do so, click the Create Certificate Signing Request button. A screen like the one in Figure 4.12.3 opens, but without the Signing Certificate Authority field.

Certificates that are imported, self-signed, or for which a certificate signing request is created are added as entries to System → Certificates. In the example shown in Figure 4.12.4, a self-signed certificate and a certificate signing request have been created for the fictional organization My Company. The self-signed certificate was issued by the internal CA named My Company and the administrator has not yet sent the certificate signing request to Verisign so that it can be signed. Once that certificate is signed and returned by the external CA, it should be imported using the Import Certificate button so that is available as a configurable option for encrypting connections.

Fig. 4.12.4 Managing Certificates

Clicking an entry activates these configuration buttons:

• View: use this option to view or edit the contents of an existing certificate. These fields can be edited: Identifier (name), Certificate, and Private Key.
• Export Certificate saves a copy of the certificate or certificate signing request to the system being used to access the TrueNAS^® system. For a certificate signing request, send the exported certificate to the external signing authority so that it can be signed.
• Export Private Key saves a copy of the private key associated with the certificate or certificate signing request to the system being used to access the TrueNAS^® system.
• Delete is used to delete a certificate or certificate signing request.

4.13. Support¶

The TrueNAS^® Support tab, shown in Figure 4.13.1, is used to view or update the system’s license information. It also provides a built-in ticketing system for generating support requests.

Fig. 4.13.1 Support Tab

In this example, the system has a valid license which indicates the hardware model, system serial number, support contract type, licensed period, customer name, licensed features, and additional supported hardware.

If the license expires or additional hardware, features, or contract type are required, contact your iXsystems support engineer. Once you have the new license string, click the Update License button, paste in the new license, and click OK. The new details will be displayed.

To generate a support ticket, fill in the fields:

• Name is the name of the person the iXsystems Support Representative should contact to assist with the issue.
• E-mail is the email address of the person to contact.
• Phone is the phone number of the person to contact.
• Category is a drop-down menu to select whether the ticket is to report a software bug, report a hardware failure, ask for assistance in installing or configuring the system, or request assistance in diagnosing a performance bottleneck.
• Environment is a drop-down menu to indicate the role of the affected system. Choices are Production, Staging, Test, Prototyping, or Initial Deployment/Setup.
• Criticality is a drop-down menu to indicate the criticality level. Choices are Inquiry, Loss of Functionality, or Total Down.
• Attach Debug Info allows an overview of the system hardware and configuration to be automatically generated and included with the ticket. It is recommended to leave this box checked.
• Subject is a descriptive title for the ticket.
• Description is a one- to three-paragraph summary of the issue that describes the problem, and if applicable, steps to reproduce it.
• Attachments is an optional field where configuration files or screenshots of any errors or tracebacks can be included.

After completing the fields, click the Submit button to generate and send the support ticket to iXsystems. A pop-up menu provides a clickable URL to view the status of or add additional information to that support ticket. When not already logged into the iXsystems Support page, clicking this URL prompts for a login, or to register a new login.

4.14. Proactive Support¶

The Proactive Support feature can notify iXsystems by email when hardware conditions on the system require attention.

Fig. 4.14.1 Proactive Support Tab

The Proactive Support fields are:

• Enable automatic support alerts to iXsystems allows enabling or disabling Proactive Support emails to iXsystems. It is recommended to enable this automatic reporting.
• Name of Primary Contact is the name of the first person to be contacted by iXsystems Support to assist with issues.
• Title is the title of the primary contact person.
• E-mail is the email address of the primary contact person.
• Phone is the phone number of the primary contact person.
• Name of Secondary Contact is the name of the person to be contacted when the primary contact person is not available.
• Secondary Title is the title of the secondary contact person.
• SecondaryE-mail is the email address of the secondary contact person.
• Secondary Phone is the phone number of the secondary contact person.

To enable Proactive Support, complete the fields, make sure the Enable automatic support alerts to iXsystems box is checked, then click Save.

4.15. Failover¶

If the TrueNAS^® array has been licensed for High Availability (HA), a Failover tab is added to System. HA-licensed arrays use the Common Address Redundancy Protocol (CARP) to provide high availability and failover. CARP was originally developed by the OpenBSD project and provides an open source, non patent-encumbered alternative to the VRRP and HSRP protocols. TrueNAS^® uses a two-unit active/standby model and provides an HA synchronization daemon to automatically monitor the status of the active node, synchronize any configuration changes between the active and the standby node, and failover to the standby node should the active node become unavailable.

To configure HA, turn on both units in the array. Use the instructions in the Console Setup Menu to log into the graphical interface for one of the units (it does not matter which one). If this is the first login, the Upload License screen is automatically displayed. Otherwise, click System → Support → Upload License.

Paste the HA license received from iXsystems and press OK to activate it. The license contains the serial numbers for both units in the chassis. After the license is activated, the Failover tab is added to System and some fields are modified in Network so that the peer IP address, peer hostname, and virtual IP can be configured. An extra IPMI (Node A/B) tab will also be added so that IPMI can be configured for the other unit.

To configure HA networking, go to Network → Global Configuration. The Hostname field is replaced by two fields:

• Hostname (Node A/B): enter the hostname to use for the other node.
• Hostname (This Node): enter the hostname to use for this node.

Next, go to Network → Interfaces → Add Interface. The HA license adds several fields to the usual Interfaces screen:

• IPv4 Address (Node A/B): if the other node will use a static IP address, rather than DHCP, set it here.
• IPv4 Address (This Node): if this node will use a static IP address, rather than DHCP, set it here.
• Virtual IP: enter the IP address to use for administrative access to the array.
• Virtual Host ID: the Virtual Host ID (VHID) must be unique on the broadcast segment of the network. It can be any unused number between 1 and 255.
• Critical for Failover: check this box if a failover should occur when this interface becomes unavailable. How many seconds it takes for that failover to occur depends upon the value of the Timeout, as described in Table 4.15.1. This checkbox is interface-specific, allowing you to have different settings for a management network and a data network. Note that checking this box requires the Virtual IP to be set and that at least one interface needs to be set as Critical for Failover to configure failover.
• Group: this drop-down menu is grayed out unless the Critical for Failover checkbox is checked. This box allows grouping multiple, critical-for-failover interfaces. In this case, all of the interfaces in a group must go down before failover occurs. This can be a useful configuration in a multipath scenario.

After the network configuration is complete, log out and log back in, this time using the Virtual IP address. Volumes and shares can now be configured as usual and configuration automatically synchronizes between the active and the standby node. A HA Enabled icon is added after the Alert icon on the active node. The passive or standby node indicates the virtual IP address that is used for configuration management. The standby node also has a red Standby icon and no longer accepts logins as all configuration changes must occur on the active node.

When HA has been disabled by the system administrator, the status icon changes to HA Disabled. If the standby node is not available because it is powered off, still starting up, or is disconnected from the network, or if failover has not been configured, the status icon changes to HA Unavailable.

The options available in System → Failover are shown in Figure 4.15.1: and described in Table 4.15.1.

Fig. 4.15.1 Example Failover Screen