The Console configuration file is the simplest of all the configuration files, and in general, you should not need to change it except for the password. It simply contains the information necessary to contact the Director or Directors.
For a general discussion of the syntax of configuration files and their resources including the data types recognized by Bacula, please see the Configuration chapter of this manual.
The following Console Resource definition must be defined:
The Director resource defines the attributes of the Director running on the network. You may have multiple Director resource specifications in a single Console configuration file. If you have more than one, you will be prompted to choose one when you start the Console program.
--
with-baseport option of the ./configure command. This port must be identical to the DIRport specified in the Director resource of the Director's configuration file. The default is 9101 so this directive is not normally specified.
Enable TLS support. If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.
Enable or Disable automatic TLS PSK support. TLS PSK is enabled by default between all Bacula components. The Pre-Shared Key used between the programs is the Bacula password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.
Require TLS or TLS-PSK encryption. This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required while TLS or TLS-PSK are enabled, then the Bacula component will connect with other components either with or without TLS or TLS-PSK
If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.
If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.
This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.
Example:
File Daemon configuration file (bacula-fd.conf), Director resource configuration has TLS Verify Peer = no:
Director { Name = bacula-dir Password = "password" Address = director.example.com # TLS configuration directives TLS Enable = yes TLS Require = yes TLS Verify Peer = no TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem TLS Key = /opt/bacula/ssl/keys/client1_key.pem }
Having TLS Verify Peer = no, means the File Daemon, server context, will not check Directorâs public certificate, client context. There is no need to specify TLS Certificate File neither TLS Key directives in the Client resource, director configuration file. We can have the below client configuration in bacula-dir.conf:
Client { Name = client1-fd Address = client1.example.com FDPort = 9102 Catalog = MyCatalog Password = "password" ... # TLS configuration directives TLS Enable = yes TLS Require = yes TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem }
In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default). For example, in bacula-fd.conf, Director resource definition:
Director { Name = bacula-dir Password = "password" Address = director.example.com # TLS configuration directives TLS Enable = yes TLS Require = yes # if TLS Verify Peer = no, then TLS Allowed CN will not be checked. TLS Verify Peer = yes TLS Allowed CN = director.example.com TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem TLS Key = /opt/bacula/ssl/keys/client1_key.pem }
In the case this directive is configured in a client side, the allowed CN list will always be checked.
Client { Name = client1-fd Address = client1.example.com FDPort = 9102 Catalog = MyCatalog Password = "password" ... # TLS configuration directives TLS Enable = yes TLS Require = yes # the Allowed CN will be checked for this client by director # the client's certificate Common Name must match any of # the values of the Allowed CN list TLS Allowed CN = client1.example.com TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem TLS Key = /opt/bacula/ssl/keys/director_key.pem }
If the client doesnât provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:
16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate verification failed. Peer certificate did not match a required commonName 16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at "192.168.100.2:9102".
To generate the parameter file, you may use openssl:
openssl dhparam -out dh4096.pem -5 4096
An actual example might be:
Director { Name = HeadMan address = rufus.cats.com password = xyz1erploit }
The ConsoleFont resource is available only in the GNOME version of the console. It permits you to define the font that you want used to display in the main listing window.
Font = "LucidaTypewriter 9"
Thanks to Phil Stracchino for providing the code for this feature.
An different example might be:
ConsoleFont { Name = Default Font = "Monospace 10" }
There are three different kinds of consoles, which the administrator or user can use to interact with the Director. These three kinds of consoles comprise three different security levels.
This second type of console begins with absolutely no privileges except those explicitly specified in the Director's Console resource. Note, the definition of what these restricted consoles can do is determined by the Director's conf file.
Thus you may define within the Director's conf file multiple Consoles with different names and passwords, sort of like multiple users, each with different privileges. As a default, these consoles can do absolutely nothing - no commands what so ever. You give them privileges or rather access to commands and resources by specifying access control lists in the Director's Console resource. This gives the administrator fine grained control over what particular consoles (or users) can do.
The Console resource is optional and need not be specified. However, if it is specified, you can use ACLs (Access Control Lists) in the Director's configuration file to restrict the particular console (or user) to see only information pertaining to his jobs or client machine.
You may specify as many Console resources in the console's conf file. If you do so, generally the first Console resource will be used. However, if you have multiple Director resources (i.e. you want to connect to different directors), you can bind one of your Console resources to a particular Director resource, and thus when you choose a particular Director, the appropriate Console configuration resource will be used. See the "Director" directive in the Console resource described below for more information.
Note, the Console resource is optional, but can be useful for restricted consoles as noted above.
If the two Bacula components (DIR, FD, SD, bconsole) have the comm line compression enabled, the line compression will be enabled. The default value is yes.
In many cases, the volume of data transmitted across the communications line can be reduced by a factor of three when this directive is enabled. In the case that the compression is not effective, Bacula turns it off on a record by record basis.
If you are backing up data that is already compressed the comm line compression will not be effective, and you are likely to end up with an average compression ratio that is very small. In this case, Bacula reports None in the Job report.
Enable TLS support. If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.
Enable or Disable automatic TLS PSK support. TLS PSK is enabled by default between all Bacula components. The Pre-Shared Key used between the programs is the Bacula password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.
Require TLS or TLS-PSK encryption. This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required while TLS or TLS-PSK are enabled, then the Bacula component will connect with other components either with or without TLS or TLS-PSK
If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.
If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.
This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.
Example:
File Daemon configuration file (bacula-fd.conf), Director resource configuration has TLS Verify Peer = no:
Director { Name = bacula-dir Password = "password" Address = director.example.com # TLS configuration directives TLS Enable = yes TLS Require = yes TLS Verify Peer = no TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem TLS Key = /opt/bacula/ssl/keys/client1_key.pem }
Having TLS Verify Peer = no, means the File Daemon, server context, will not check Directorâs public certificate, client context. There is no need to specify TLS Certificate File neither TLS Key directives in the Client resource, director configuration file. We can have the below client configuration in bacula-dir.conf:
Client { Name = client1-fd Address = client1.example.com FDPort = 9102 Catalog = MyCatalog Password = "password" ... # TLS configuration directives TLS Enable = yes TLS Require = yes TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem }
In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default). For example, in bacula-fd.conf, Director resource definition:
Director { Name = bacula-dir Password = "password" Address = director.example.com # TLS configuration directives TLS Enable = yes TLS Require = yes # if TLS Verify Peer = no, then TLS Allowed CN will not be checked. TLS Verify Peer = yes TLS Allowed CN = director.example.com TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem TLS Key = /opt/bacula/ssl/keys/client1_key.pem }
In the case this directive is configured in a client side, the allowed CN list will always be checked.
Client { Name = client1-fd Address = client1.example.com FDPort = 9102 Catalog = MyCatalog Password = "password" ... # TLS configuration directives TLS Enable = yes TLS Require = yes # the Allowed CN will be checked for this client by director # the client's certificate Common Name must match any of # the values of the Allowed CN list TLS Allowed CN = client1.example.com TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem TLS Key = /opt/bacula/ssl/keys/director_key.pem }
If the client doesnât provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:
16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate verification failed. Peer certificate did not match a required commonName 16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at "192.168.100.2:9102".
To generate the parameter file, you may use openssl:
openssl dhparam -out dh4096.pem -5 4096
The following configuration files were supplied by Phil Stracchino. For example, if we define the following in the user's bconsole.conf file (or perhaps the bwx-console.conf file):
Director { Name = MyDirector DIRport = 9101 Address = myserver Password = "XXXXXXXXXXX" # no, really. this is not obfuscation. } Console { Name = restricted-user Password = "UntrustedUser" }
Where the Password in the Director section is deliberately incorrect, and the Console resource is given a name, in this case restricted-user. Then in the Director's bacula-dir.conf file (not directly accessible by the user), we define:
Console { Name = restricted-user Password = "UntrustedUser" JobACL = "Restricted Client Save" ClientACL = restricted-client StorageACL = main-storage ScheduleACL = *all* PoolACL = *all* FileSetACL = "Restricted Client's FileSet" CatalogACL = DefaultCatalog CommandACL = run }
the user logging into the Director from his Console will get logged in as restricted-user, and he will only be able to see or access a Job with the name Restricted Client Save a Client with the name restricted-client, a Storage device main-storage, any Schedule or Pool, a FileSet named Restricted Client's FileSet, a Catalog named DefaultCatalog, and the only command he can use in the Console is the run command. In other words, this user is rather limited in what he can see and do with Bacula.
The following is an example of a bconsole conf file that can access several Directors and has different Consoles depending on the director:
Director { Name = MyDirector DIRport = 9101 Address = myserver Password = "XXXXXXXXXXX" # no, really. this is not obfuscation. } Director { Name = SecondDirector DIRport = 9101 Address = secondserver Password = "XXXXXXXXXXX" # no, really. this is not obfuscation. } Console { Name = restricted-user Password = "UntrustedUser" Director = MyDirector } Console { Name = restricted-user-2 Password = "A different UntrustedUser" Director = SecondDirector }
The second Director referenced at "secondserver" might look like the following:
Console { Name = restricted-user-2 Password = "A different UntrustedUser" JobACL = "Restricted Client Save" ClientACL = restricted-client StorageACL = second-storage ScheduleACL = *all* PoolACL = *all* FileSetACL = "Restricted Client's FileSet" CatalogACL = RestrictedCatalog CommandACL = run, restore WhereACL = "/" }
To use the same Console name on both Directors, you must create two bconsole.conf to store the two Director/Console groups.
For more details on running the console and its commands, please see the Bacula Console chapter of the Bacula Enterprise Console manual.
An example Console configuration file might be the following:
# # Bacula Console Configuration File # Director { Name = HeadMan address = "my_machine.my_domain.com" Password = Console_password }