Director Resource
The Director resource defines the name and password of the Directors that are permitted to contact this Client.
There may be any number of Director resources in the Client configuration file. Each one specifies a Director that is allowed to connect to this Client.
The explanation on how to read the directive format:
Name: Contains the linked name of the directive.
Description: Explains what the directive does.
Value: Indicates what type of value to provide (e.g., <type-specification>).
Data Type: Specifies the type of data expected.
Values: Lists specific acceptable values.
Required: If present, indicates that the directive must be set by the user, there is no default value.
Default: If present, indicates that the directive has a predefined value that does not need to be set by the user, cannot be removed.
Comment: Additional important notes.
Example: Shows a usage example.
Director Start of the Director records.
Description: The name of the Director that may contact this Client.
Value(s):
<name>Data Type: string
Required: Yes
Comment: This name must be the same as the name specified on the Director resource in the Director’s configuration file. Note, the case (upper/lower) of the characters in the name are significant (i.e. S is not the same as s).
Description: Specifies the password that must be supplied for a Director to be authorized.
Value(s):
<password>Data Type: password
Required: Yes
Comment: This password must be the same as the password specified in the Client resource in the Director’s configuration file.
Description: Specifies the port to use to connect to the Director.
Value(s):
<number>Data Type: positive integer
Default: 9101
Comment: This port must be identical to the DIRport specified in the Director resource of the Director’s configuration file. The default 9101 is so this directive is not normally specified.
Description: The address is a host name, a fully qualified domain name, or a network address used to connect to the Director.
Value(s):
<address>Data Type: string
Comment: This directive is required when ConnectToDirector is enabled.
Description: When the
ConnectToDirectordirective is set totrue, the Client will contact the Director according to the rules.Value(s):
<yes|no>Data Type: boolean
Comment: If the Schedule directive is not set, the connection will be initiated when the file daemon starts. The connection will be reinitialized every ReconnectionTime. This directive can be useful if your File Daemon is behind a firewall that permits outgoing connections but not incoming connections.
Description: Time interval to pace the reinitialization of the connection initiated by the File Daemon to the Director
Value(s):
<time>Data Type: time
Default: 45 minutes
Description: Defines what schedule is to be used for Client to connect the Director if the directive is set to
true.Value(s):
<schedule-resource>Data Type: string
Comment: This directive is optional, and if left out, the Client will initiate a connection automatically at the start of the daemon. Although you may specify only a single Schedule resource for any resource, the resource may contain multiple Connect directives, which allow you to initiate the Client connection at many different times, and each Connect directive permits to set the Max Connect Time directive.
Description: Specifies the maximum allowed bandwidth in bytes per second that a job may use when started from this Director.
Value(s):
<speed>Data Type: positive integer
Comment: You may specify the following speed parameter modifiers: kb/s (1,000 bytes per second), k/s (1,024 bytes per second), mb/s (1,000,000 bytes per second), or m/s (1,048,576 bytes per second).
Description: Adds security to your File Daemon by disabling certain commands for the current Director.
Value(s):
<command>Data Type:
Comment: More information about the syntax can be found in the DisableCommand section.
Description: If set to no, this director will have full access to this Client.
Value(s):
<yes|no>Data Type: boolean
Comment: Note that if this director is being used by a Monitor, we highly recommend to set this directive to yes to avoid serious security problems.
Description: Lets the daemon control in which user’s context the Backup job is being run.
Value(s):
<username:groupname>Data Type: string
Comment: Can be expressed as uid:gid or username:groupname.
Description: Lets the daemon control in which user’s context the Restore job is being run.
Value(s):
<username:groupname>Data Type: string
Comment: Can be expressed as uid:gid or username:groupname. Overrides the Restore user set with
jobuserandjobgrouparguments for the bconsolerestorecommand.
Description: Defines Director a list of client’s directories per Director that are allowed to be backed up for a specific Director.
Value(s):
<directory-list>Data Type: string list
Comment: This directive is fully independent of the include/exclude part of the Fileset defined in the Director’s config file. Nothing is backed up if none of the files defined in the Fileset is inside FD’s allowed directory. This directive is not required. If it is not defined, every directory defined in the Fileset is allowed.
Description: Defines a list of client’s directories per Director that are excluded from the backup for specific Director.
Value(s):
<directory-list>Data Type: string list
Comment: This directive is fully independent of the include/exclude part of the Fileset defined in the Director’s config file. Nothing is backed up if all files defined in the Fileset are inside FD’s excluded directory.
Description: Defines a list of client’s directories per Director that are allowed to be used as a restore destination on a per-Director basis.
Value(s):
<directory-list>Data Type: string list
Description: Defines a list of client’s directories per Director which from the Director can execute client’s scripts and programs (e.g. using the Runscript feature or with the Fileset’s ‘File=’ directive).
Value(s):
<directory-list>Data Type: string list
Comment: Directive can be specified as a list of directories. When this directive is set, Bacula is also checking programs to be run against set of not-allowed characters. Full list of not-allowed characters:
$ ! ; \ & < > ` ( )Multiple Directors may be authorized to use this Client’s services. Each Director will have a different name, and normally a different password as well.
Example: The following is an example of multiple Director resource definitions:
# # List Directors who are permitted to contact the File daemon # Director { Name = HeadMan Password = very_good # password HeadMan must supply } Director { Name = Worker Password = not_as_good Monitor = Yes }
Description: Path to PEM encoded Diffie-Hellman parameter file.
Value(s):
<directory>Data Type: string
Comment: If this directive is specified, DH key exchange will be used for the ephemeral keying, allowing for forward secrecy of communications. DH key exchange adds an additional level of security because the key used for encryption/decryption by the server and the client is computed on each end and thus is never passed over the network if Diffie-Hellman key exchange is used. Even if DH key exchange is not used, the encryption/decryption key is always passed encrypted. This directive is only valid within a server context.
To generate the parameter file, you may use openssl:
openssl dhparam -out dh4096.pem -5 4096
Description: When TLS Authenticate is enabled, after doing the CRAM-MD5 authentication, Bacula will also do TLS authentication, then TLS encryption will be turned off, and the rest of the communication between the two Bacula components will be done without encryption. If TLS-PSK is used instead of the regular TLS, the encryption is turned off after the TLS-PSK authentication step.
Value(s):
<yes|no>Data Type: boolean
Comment: If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.
Description: Verify peer certificate. Instructs server to request and verify the client’s X.509 certificate.
Value(s):
<yes|no>Data Type: boolean
Default: yes
Comment: Any client certificate signed by a known-CA will be accepted. Additionally, the client’s X509 certificate Common Name must meet the value of the Address directive. If the TLSAllowedCN configuration option is used, the client’s x509 certificate Common Name must also correspond to one of the CN specified in the TLS Allowed CN directive. This directive is valid only for a server and not in client context. The default is yes.
Description: The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.
Value(s):
<filename>Data Type: string
Description: Enable or Disable automatic TLS PSK support.
Value(s):
<yes|no>Data Type: boolean
Default: yes
Comment: 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.
Description: Enable TLS support.
Value(s):
<yes|no>Data Type: boolean
Comment: 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.
Description: Common name attribute of allowed peer certificates.
Value(s):
<certificate-list>Data Type: string list
Comment: This directive is valid for a server and in a client context. If this directive is specified, the peer certificate will be verified against this list. In the case this directive is configured on a server side, the allowed CN list will not be checked if TLS Verify Peer is set to no (TLS Verify Peer is yes by default). This can be used to ensure that only the CN-approved component may connect. This directive may be specified more than once.
Example: 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).
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".
Description: Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name’s hash and an extension of .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer is set to no, and are always required in a client context.
Value(s):
<directory>Data Type: string
Description: Require TLS or TLS-PSK encryption.
Value(s):
<yes|no>Data Type: boolean
Comment: 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.
Description: The full path and filename specifying a PEM encoded TLS CA certificate(s).
Value(s):
<filename>Data Type: string
Comment: Multiple certificates are permitted in the file. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer (see above) is set to no, and are always required in a client context.
Description: The full path and filename of a PEM encoded TLS certificate.
Value(s):
<filename>Data Type: string
Comment: It will be used as either a client or server certificate, depending on the connection direction. PEM stands for Privacy Enhanced Mail, but in this context refers to how the certificates are encoded. This format is used because PEM files are base64 encoded and hence ASCII text based rather than binary. They may also contain encrypted information.
Example: 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), 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 }
Note
TLS Directives in the Director resource of bacula-fd.conf
Bacula has built-in network encryption code to provide secure network transport similar to that offered by stunnel or ssh . The Bacula TLS encryption applies only to information transmitted across a network, so the data written to Volumes by the Storage daemon is not encrypted by this code.
For more information how to enable TLS encryption, click here.
Go back to the File Daemon (Client) Resource Types page.
Go back to the Technical Reference for File Daemon.
Go back to the main Technical Reference page.