···
1
-
<chapter xmlns="http://docbook.org/ns/docbook"
2
-
xmlns:xlink="http://www.w3.org/1999/xlink"
3
-
xmlns:xi="http://www.w3.org/2001/XInclude"
5
-
xml:id="module-services-foundationdb">
6
-
<title>FoundationDB</title>
8
-
<emphasis>Source:</emphasis>
9
-
<filename>modules/services/databases/foundationdb.nix</filename>
12
-
<emphasis>Upstream documentation:</emphasis>
13
-
<link xlink:href="https://apple.github.io/foundationdb/"/>
16
-
<emphasis>Maintainer:</emphasis> Austin Seipp
19
-
<emphasis>Available version(s):</emphasis> 5.1.x, 5.2.x, 6.0.x
22
-
FoundationDB (or "FDB") is an open source, distributed, transactional
25
-
<section xml:id="module-services-foundationdb-configuring">
26
-
<title>Configuring and basic setup</title>
1
+
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="module-services-foundationdb">
2
+
<title>FoundationDB</title>
29
-
To enable FoundationDB, add the following to your
30
-
<filename>configuration.nix</filename>:
32
-
services.foundationdb.enable = true;
33
-
services.foundationdb.package = pkgs.foundationdb52; # FoundationDB 5.2.x
4
+
<emphasis>Source:</emphasis>
5
+
<filename>modules/services/databases/foundationdb.nix</filename>
38
-
The <option>services.foundationdb.package</option> option is required, and
39
-
must always be specified. Due to the fact FoundationDB network protocols and
40
-
on-disk storage formats may change between (major) versions, and upgrades
41
-
must be explicitly handled by the user, you must always manually specify
42
-
this yourself so that the NixOS module will use the proper version. Note
43
-
that minor, bugfix releases are always compatible.
8
+
<emphasis>Upstream documentation:</emphasis>
9
+
<link xlink:href="https://apple.github.io/foundationdb/" role="uri">https://apple.github.io/foundationdb/</link>
47
-
After running <command>nixos-rebuild</command>, you can verify whether
48
-
FoundationDB is running by executing <command>fdbcli</command> (which is
49
-
added to <option>environment.systemPackages</option>):
51
-
<prompt>$ </prompt>sudo -u foundationdb fdbcli
12
+
<emphasis>Maintainer:</emphasis> Austin Seipp
15
+
<emphasis>Available version(s):</emphasis> 5.1.x, 5.2.x, 6.0.x
18
+
FoundationDB (or "FDB") is an open source, distributed,
19
+
transactional key-value store.
21
+
<section xml:id="module-services-foundationdb-configuring">
22
+
<title>Configuring and basic setup</title>
24
+
To enable FoundationDB, add the following to your
25
+
<filename>configuration.nix</filename>:
28
+
services.foundationdb.enable = true;
29
+
services.foundationdb.package = pkgs.foundationdb52; # FoundationDB 5.2.x
32
+
The <option>services.foundationdb.package</option> option is
33
+
required, and must always be specified. Due to the fact
34
+
FoundationDB network protocols and on-disk storage formats may
35
+
change between (major) versions, and upgrades must be explicitly
36
+
handled by the user, you must always manually specify this
37
+
yourself so that the NixOS module will use the proper version.
38
+
Note that minor, bugfix releases are always compatible.
41
+
After running <command>nixos-rebuild</command>, you can verify
42
+
whether FoundationDB is running by executing
43
+
<command>fdbcli</command> (which is added to
44
+
<option>environment.systemPackages</option>):
47
+
$ sudo -u foundationdb fdbcli
Using cluster file `/etc/foundationdb/fdb.cluster'.
The database is available.
Welcome to the fdbcli. For help, type `help'.
57
-
<prompt>fdb> </prompt>status
Using cluster file `/etc/foundationdb/fdb.cluster'.
···
75
-
<prompt>fdb></prompt>
80
-
You can also write programs using the available client libraries. For
81
-
example, the following Python program can be run in order to grab the
82
-
cluster status, as a quick example. (This example uses
83
-
<command>nix-shell</command> shebang support to automatically supply the
84
-
necessary Python modules).
86
-
<prompt>a@link> </prompt>cat fdb-status.py
74
+
You can also write programs using the available client libraries.
75
+
For example, the following Python program can be run in order to
76
+
grab the cluster status, as a quick example. (This example uses
77
+
<command>nix-shell</command> shebang support to automatically
78
+
supply the necessary Python modules).
81
+
a@link> cat fdb-status.py
#! /usr/bin/env nix-shell
#! nix-shell -i python -p python pythonPackages.foundationdb52
···
obj = json.loads(get_status(db))
print('FoundationDB available: %s' % obj['client']['database_status']['available'])
104
-
if __name__ == "__main__":
99
+
if __name__ == "__main__":
106
-
<prompt>a@link> </prompt>chmod +x fdb-status.py
107
-
<prompt>a@link> </prompt>./fdb-status.py
101
+
a@link> chmod +x fdb-status.py
102
+
a@link> ./fdb-status.py
FoundationDB available: True
109
-
<prompt>a@link></prompt>
114
-
FoundationDB is run under the <command>foundationdb</command> user and group
115
-
by default, but this may be changed in the NixOS configuration. The systemd
116
-
unit <command>foundationdb.service</command> controls the
117
-
<command>fdbmonitor</command> process.
121
-
By default, the NixOS module for FoundationDB creates a single SSD-storage
122
-
based database for development and basic usage. This storage engine is
123
-
designed for SSDs and will perform poorly on HDDs; however it can handle far
124
-
more data than the alternative "memory" engine and is a better default
125
-
choice for most deployments. (Note that you can change the storage backend
126
-
on-the-fly for a given FoundationDB cluster using
127
-
<command>fdbcli</command>.)
131
-
Furthermore, only 1 server process and 1 backup agent are started in the
132
-
default configuration. See below for more on scaling to increase this.
136
-
FoundationDB stores all data for all server processes under
137
-
<filename>/var/lib/foundationdb</filename>. You can override this using
138
-
<option>services.foundationdb.dataDir</option>, e.g.
140
-
services.foundationdb.dataDir = "/data/fdb";
145
-
Similarly, logs are stored under <filename>/var/log/foundationdb</filename>
146
-
by default, and there is a corresponding
147
-
<option>services.foundationdb.logDir</option> as well.
150
-
<section xml:id="module-services-foundationdb-scaling">
151
-
<title>Scaling processes and backup agents</title>
154
-
Scaling the number of server processes is quite easy; simply specify
155
-
<option>services.foundationdb.serverProcesses</option> to be the number of
156
-
FoundationDB worker processes that should be started on the machine.
160
-
FoundationDB worker processes typically require 4GB of RAM per-process at
161
-
minimum for good performance, so this option is set to 1 by default since
162
-
the maximum amount of RAM is unknown. You're advised to abide by this
163
-
restriction, so pick a number of processes so that each has 4GB or more.
167
-
A similar option exists in order to scale backup agent processes,
168
-
<option>services.foundationdb.backupProcesses</option>. Backup agents are
169
-
not as performance/RAM sensitive, so feel free to experiment with the number
170
-
of available backup processes.
173
-
<section xml:id="module-services-foundationdb-clustering">
174
-
<title>Clustering</title>
177
-
FoundationDB on NixOS works similarly to other Linux systems, so this
178
-
section will be brief. Please refer to the full FoundationDB documentation
179
-
for more on clustering.
183
-
FoundationDB organizes clusters using a set of
184
-
<emphasis>coordinators</emphasis>, which are just specially-designated
185
-
worker processes. By default, every installation of FoundationDB on NixOS
186
-
will start as its own individual cluster, with a single coordinator: the
187
-
first worker process on <command>localhost</command>.
191
-
Coordinators are specified globally using the
192
-
<command>/etc/foundationdb/fdb.cluster</command> file, which all servers and
193
-
client applications will use to find and join coordinators. Note that this
194
-
file <emphasis>can not</emphasis> be managed by NixOS so easily:
195
-
FoundationDB is designed so that it will rewrite the file at runtime for all
196
-
clients and nodes when cluster coordinators change, with clients
197
-
transparently handling this without intervention. It is fundamentally a
198
-
mutable file, and you should not try to manage it in any way in NixOS.
202
-
When dealing with a cluster, there are two main things you want to do:
208
-
Add a node to the cluster for storage/compute.
107
+
FoundationDB is run under the <command>foundationdb</command> user
108
+
and group by default, but this may be changed in the NixOS
109
+
configuration. The systemd unit
110
+
<command>foundationdb.service</command> controls the
111
+
<command>fdbmonitor</command> process.
213
-
Promote an ordinary worker to a coordinator.
114
+
By default, the NixOS module for FoundationDB creates a single
115
+
SSD-storage based database for development and basic usage. This
116
+
storage engine is designed for SSDs and will perform poorly on
117
+
HDDs; however it can handle far more data than the alternative
118
+
"memory" engine and is a better default choice for most
119
+
deployments. (Note that you can change the storage backend
120
+
on-the-fly for a given FoundationDB cluster using
121
+
<command>fdbcli</command>.)
219
-
A node must already be a member of the cluster in order to properly be
220
-
promoted to a coordinator, so you must always add it first if you wish to
225
-
To add a machine to a FoundationDB cluster:
231
-
Choose one of the servers to start as the initial coordinator.
124
+
Furthermore, only 1 server process and 1 backup agent are started
125
+
in the default configuration. See below for more on scaling to
236
-
Copy the <command>/etc/foundationdb/fdb.cluster</command> file from this
237
-
server to all the other servers. Restart FoundationDB on all of these
238
-
other servers, so they join the cluster.
129
+
FoundationDB stores all data for all server processes under
130
+
<filename>/var/lib/foundationdb</filename>. You can override this
131
+
using <option>services.foundationdb.dataDir</option>, e.g.
134
+
services.foundationdb.dataDir = "/data/fdb";
137
+
Similarly, logs are stored under
138
+
<filename>/var/log/foundationdb</filename> by default, and there
139
+
is a corresponding <option>services.foundationdb.logDir</option>
143
+
<section xml:id="module-services-foundationdb-scaling">
144
+
<title>Scaling processes and backup agents</title>
243
-
All of these servers are now connected and working together in the
244
-
cluster, under the chosen coordinator.
146
+
Scaling the number of server processes is quite easy; simply
147
+
specify <option>services.foundationdb.serverProcesses</option> to
148
+
be the number of FoundationDB worker processes that should be
149
+
started on the machine.
250
-
At this point, you can add as many nodes as you want by just repeating the
251
-
above steps. By default there will still be a single coordinator: you can
252
-
use <command>fdbcli</command> to change this and add new coordinators.
256
-
As a convenience, FoundationDB can automatically assign coordinators based
257
-
on the redundancy mode you wish to achieve for the cluster. Once all the
258
-
nodes have been joined, simply set the replication policy, and then issue
259
-
the <command>coordinators auto</command> command
263
-
For example, assuming we have 3 nodes available, we can enable double
264
-
redundancy mode, then auto-select coordinators. For double redundancy, 3
265
-
coordinators is ideal: therefore FoundationDB will make
266
-
<emphasis>every</emphasis> node a coordinator automatically:
270
-
<prompt>fdbcli> </prompt>configure double ssd
271
-
<prompt>fdbcli> </prompt>coordinators auto
275
-
This will transparently update all the servers within seconds, and
276
-
appropriately rewrite the <command>fdb.cluster</command> file, as well as
277
-
informing all client processes to do the same.
280
-
<section xml:id="module-services-foundationdb-connectivity">
281
-
<title>Client connectivity</title>
284
-
By default, all clients must use the current <command>fdb.cluster</command>
285
-
file to access a given FoundationDB cluster. This file is located by default
286
-
in <command>/etc/foundationdb/fdb.cluster</command> on all machines with the
287
-
FoundationDB service enabled, so you may copy the active one from your
288
-
cluster to a new node in order to connect, if it is not part of the cluster.
291
-
<section xml:id="module-services-foundationdb-authorization">
292
-
<title>Client authorization and TLS</title>
295
-
By default, any user who can connect to a FoundationDB process with the
296
-
correct cluster configuration can access anything. FoundationDB uses a
297
-
pluggable design to transport security, and out of the box it supports a
298
-
LibreSSL-based plugin for TLS support. This plugin not only does in-flight
299
-
encryption, but also performs client authorization based on the given
300
-
endpoint's certificate chain. For example, a FoundationDB server may be
301
-
configured to only accept client connections over TLS, where the client TLS
302
-
certificate is from organization <emphasis>Acme Co</emphasis> in the
303
-
<emphasis>Research and Development</emphasis> unit.
307
-
Configuring TLS with FoundationDB is done using the
308
-
<option>services.foundationdb.tls</option> options in order to control the
309
-
peer verification string, as well as the certificate and its private key.
313
-
Note that the certificate and its private key must be accessible to the
314
-
FoundationDB user account that the server runs under. These files are also
315
-
NOT managed by NixOS, as putting them into the store may reveal private
320
-
After you have a key and certificate file in place, it is not enough to
321
-
simply set the NixOS module options -- you must also configure the
322
-
<command>fdb.cluster</command> file to specify that a given set of
323
-
coordinators use TLS. This is as simple as adding the suffix
324
-
<command>:tls</command> to your cluster coordinator configuration, after the
325
-
port number. For example, assuming you have a coordinator on localhost with
326
-
the default configuration, simply specifying:
152
+
FoundationDB worker processes typically require 4GB of RAM
153
+
per-process at minimum for good performance, so this option is set
154
+
to 1 by default since the maximum amount of RAM is unknown. You're
155
+
advised to abide by this restriction, so pick a number of
156
+
processes so that each has 4GB or more.
159
+
A similar option exists in order to scale backup agent processes,
160
+
<option>services.foundationdb.backupProcesses</option>. Backup
161
+
agents are not as performance/RAM sensitive, so feel free to
162
+
experiment with the number of available backup processes.
165
+
<section xml:id="module-services-foundationdb-clustering">
166
+
<title>Clustering</title>
168
+
FoundationDB on NixOS works similarly to other Linux systems, so
169
+
this section will be brief. Please refer to the full FoundationDB
170
+
documentation for more on clustering.
173
+
FoundationDB organizes clusters using a set of
174
+
<emphasis>coordinators</emphasis>, which are just
175
+
specially-designated worker processes. By default, every
176
+
installation of FoundationDB on NixOS will start as its own
177
+
individual cluster, with a single coordinator: the first worker
178
+
process on <command>localhost</command>.
181
+
Coordinators are specified globally using the
182
+
<command>/etc/foundationdb/fdb.cluster</command> file, which all
183
+
servers and client applications will use to find and join
184
+
coordinators. Note that this file <emphasis>can not</emphasis> be
185
+
managed by NixOS so easily: FoundationDB is designed so that it
186
+
will rewrite the file at runtime for all clients and nodes when
187
+
cluster coordinators change, with clients transparently handling
188
+
this without intervention. It is fundamentally a mutable file, and
189
+
you should not try to manage it in any way in NixOS.
192
+
When dealing with a cluster, there are two main things you want to
195
+
<itemizedlist spacing="compact">
198
+
Add a node to the cluster for storage/compute.
203
+
Promote an ordinary worker to a coordinator.
208
+
A node must already be a member of the cluster in order to
209
+
properly be promoted to a coordinator, so you must always add it
210
+
first if you wish to promote it.
213
+
To add a machine to a FoundationDB cluster:
215
+
<itemizedlist spacing="compact">
218
+
Choose one of the servers to start as the initial coordinator.
223
+
Copy the <command>/etc/foundationdb/fdb.cluster</command> file
224
+
from this server to all the other servers. Restart
225
+
FoundationDB on all of these other servers, so they join the
231
+
All of these servers are now connected and working together in
232
+
the cluster, under the chosen coordinator.
237
+
At this point, you can add as many nodes as you want by just
238
+
repeating the above steps. By default there will still be a single
239
+
coordinator: you can use <command>fdbcli</command> to change this
240
+
and add new coordinators.
243
+
As a convenience, FoundationDB can automatically assign
244
+
coordinators based on the redundancy mode you wish to achieve for
245
+
the cluster. Once all the nodes have been joined, simply set the
246
+
replication policy, and then issue the
247
+
<command>coordinators auto</command> command
250
+
For example, assuming we have 3 nodes available, we can enable
251
+
double redundancy mode, then auto-select coordinators. For double
252
+
redundancy, 3 coordinators is ideal: therefore FoundationDB will
253
+
make <emphasis>every</emphasis> node a coordinator automatically:
256
+
fdbcli> configure double ssd
257
+
fdbcli> coordinators auto
260
+
This will transparently update all the servers within seconds, and
261
+
appropriately rewrite the <command>fdb.cluster</command> file, as
262
+
well as informing all client processes to do the same.
265
+
<section xml:id="module-services-foundationdb-connectivity">
266
+
<title>Client connectivity</title>
268
+
By default, all clients must use the current
269
+
<command>fdb.cluster</command> file to access a given FoundationDB
270
+
cluster. This file is located by default in
271
+
<command>/etc/foundationdb/fdb.cluster</command> on all machines
272
+
with the FoundationDB service enabled, so you may copy the active
273
+
one from your cluster to a new node in order to connect, if it is
274
+
not part of the cluster.
277
+
<section xml:id="module-services-foundationdb-authorization">
278
+
<title>Client authorization and TLS</title>
280
+
By default, any user who can connect to a FoundationDB process
281
+
with the correct cluster configuration can access anything.
282
+
FoundationDB uses a pluggable design to transport security, and
283
+
out of the box it supports a LibreSSL-based plugin for TLS
284
+
support. This plugin not only does in-flight encryption, but also
285
+
performs client authorization based on the given endpoint's
286
+
certificate chain. For example, a FoundationDB server may be
287
+
configured to only accept client connections over TLS, where the
288
+
client TLS certificate is from organization <emphasis>Acme
289
+
Co</emphasis> in the <emphasis>Research and Development</emphasis>
293
+
Configuring TLS with FoundationDB is done using the
294
+
<option>services.foundationdb.tls</option> options in order to
295
+
control the peer verification string, as well as the certificate
296
+
and its private key.
299
+
Note that the certificate and its private key must be accessible
300
+
to the FoundationDB user account that the server runs under. These
301
+
files are also NOT managed by NixOS, as putting them into the
302
+
store may reveal private information.
305
+
After you have a key and certificate file in place, it is not
306
+
enough to simply set the NixOS module options -- you must also
307
+
configure the <command>fdb.cluster</command> file to specify that
308
+
a given set of coordinators use TLS. This is as simple as adding
309
+
the suffix <command>:tls</command> to your cluster coordinator
310
+
configuration, after the port number. For example, assuming you
311
+
have a coordinator on localhost with the default configuration,
XXXXXX:XXXXXX@127.0.0.1:4500:tls
334
-
will configure all clients and server processes to use TLS from now on.
337
-
<section xml:id="module-services-foundationdb-disaster-recovery">
338
-
<title>Backups and Disaster Recovery</title>
341
-
The usual rules for doing FoundationDB backups apply on NixOS as written in
342
-
the FoundationDB manual. However, one important difference is the security
343
-
profile for NixOS: by default, the <command>foundationdb</command> systemd
344
-
unit uses <emphasis>Linux namespaces</emphasis> to restrict write access to
345
-
the system, except for the log directory, data directory, and the
346
-
<command>/etc/foundationdb/</command> directory. This is enforced by default
347
-
and cannot be disabled.
351
-
However, a side effect of this is that the <command>fdbbackup</command>
352
-
command doesn't work properly for local filesystem backups: FoundationDB
353
-
uses a server process alongside the database processes to perform backups
354
-
and copy the backups to the filesystem. As a result, this process is put
355
-
under the restricted namespaces above: the backup process can only write to
356
-
a limited number of paths.
360
-
In order to allow flexible backup locations on local disks, the FoundationDB
361
-
NixOS module supports a
362
-
<option>services.foundationdb.extraReadWritePaths</option> option. This
363
-
option takes a list of paths, and adds them to the systemd unit, allowing
364
-
the processes inside the service to write (and read) the specified
369
-
For example, to create backups in <command>/opt/fdb-backups</command>, first
370
-
set up the paths in the module options:
374
-
services.foundationdb.extraReadWritePaths = [ "/opt/fdb-backups" ];
318
+
will configure all clients and server processes to use TLS from
322
+
<section xml:id="module-services-foundationdb-disaster-recovery">
323
+
<title>Backups and Disaster Recovery</title>
325
+
The usual rules for doing FoundationDB backups apply on NixOS as
326
+
written in the FoundationDB manual. However, one important
327
+
difference is the security profile for NixOS: by default, the
328
+
<command>foundationdb</command> systemd unit uses <emphasis>Linux
329
+
namespaces</emphasis> to restrict write access to the system,
330
+
except for the log directory, data directory, and the
331
+
<command>/etc/foundationdb/</command> directory. This is enforced
332
+
by default and cannot be disabled.
335
+
However, a side effect of this is that the
336
+
<command>fdbbackup</command> command doesn't work properly for
337
+
local filesystem backups: FoundationDB uses a server process
338
+
alongside the database processes to perform backups and copy the
339
+
backups to the filesystem. As a result, this process is put under
340
+
the restricted namespaces above: the backup process can only write
341
+
to a limited number of paths.
344
+
In order to allow flexible backup locations on local disks, the
345
+
FoundationDB NixOS module supports a
346
+
<option>services.foundationdb.extraReadWritePaths</option> option.
347
+
This option takes a list of paths, and adds them to the systemd
348
+
unit, allowing the processes inside the service to write (and
349
+
read) the specified directories.
352
+
For example, to create backups in
353
+
<command>/opt/fdb-backups</command>, first set up the paths in the
357
+
services.foundationdb.extraReadWritePaths = [ "/opt/fdb-backups" ];
378
-
Restart the FoundationDB service, and it will now be able to write to this
379
-
directory (even if it does not yet exist.) Note: this path
380
-
<emphasis>must</emphasis> exist before restarting the unit. Otherwise,
381
-
systemd will not include it in the private FoundationDB namespace (and it
382
-
will not add it dynamically at runtime).
386
-
You can now perform a backup:
390
-
<prompt>$ </prompt>sudo -u foundationdb fdbbackup start -t default -d file:///opt/fdb-backups
391
-
<prompt>$ </prompt>sudo -u foundationdb fdbbackup status -t default
394
-
<section xml:id="module-services-foundationdb-limitations">
395
-
<title>Known limitations</title>
398
-
The FoundationDB setup for NixOS should currently be considered beta.
399
-
FoundationDB is not new software, but the NixOS compilation and integration
400
-
has only undergone fairly basic testing of all the available functionality.
360
+
Restart the FoundationDB service, and it will now be able to write
361
+
to this directory (even if it does not yet exist.) Note: this path
362
+
<emphasis>must</emphasis> exist before restarting the unit.
363
+
Otherwise, systemd will not include it in the private FoundationDB
364
+
namespace (and it will not add it dynamically at runtime).
367
+
You can now perform a backup:
370
+
$ sudo -u foundationdb fdbbackup start -t default -d file:///opt/fdb-backups
371
+
$ sudo -u foundationdb fdbbackup status -t default
374
+
<section xml:id="module-services-foundationdb-limitations">
375
+
<title>Known limitations</title>
406
-
There is no way to specify individual parameters for individual
407
-
<command>fdbserver</command> processes. Currently, all server processes
408
-
inherit all the global <command>fdbmonitor</command> settings.
377
+
The FoundationDB setup for NixOS should currently be considered
378
+
beta. FoundationDB is not new software, but the NixOS compilation
379
+
and integration has only undergone fairly basic testing of all the
380
+
available functionality.
382
+
<itemizedlist spacing="compact">
385
+
There is no way to specify individual parameters for
386
+
individual <command>fdbserver</command> processes. Currently,
387
+
all server processes inherit all the global
388
+
<command>fdbmonitor</command> settings.
393
+
Ruby bindings are not currently installed.
398
+
Go bindings are not currently installed.
403
+
<section xml:id="module-services-foundationdb-options">
404
+
<title>Options</title>
413
-
Ruby bindings are not currently installed.
406
+
NixOS's FoundationDB module allows you to configure all of the
407
+
most relevant configuration options for
408
+
<command>fdbmonitor</command>, matching it quite closely. A
409
+
complete list of options for the FoundationDB module may be found
410
+
<link linkend="opt-services.foundationdb.enable">here</link>. You
411
+
should also read the FoundationDB documentation as well.
414
+
<section xml:id="module-services-foundationdb-full-docs">
415
+
<title>Full documentation</title>
418
-
Go bindings are not currently installed.
417
+
FoundationDB is a complex piece of software, and requires careful
418
+
administration to properly use. Full documentation for
419
+
administration can be found here:
420
+
<link xlink:href="https://apple.github.io/foundationdb/" role="uri">https://apple.github.io/foundationdb/</link>.
423
-
<section xml:id="module-services-foundationdb-options">
424
-
<title>Options</title>
427
-
NixOS's FoundationDB module allows you to configure all of the most relevant
428
-
configuration options for <command>fdbmonitor</command>, matching it quite
429
-
closely. A complete list of options for the FoundationDB module may be found
430
-
<link linkend="opt-services.foundationdb.enable">here</link>. You should
431
-
also read the FoundationDB documentation as well.
434
-
<section xml:id="module-services-foundationdb-full-docs">
435
-
<title>Full documentation</title>
438
-
FoundationDB is a complex piece of software, and requires careful
439
-
administration to properly use. Full documentation for administration can be
440
-
found here: <link xlink:href="https://apple.github.io/foundationdb/"/>.
pyrox.dev