treewide: Mark Nix blocks in markdown as Nix

This should help us with highlighting and future formatting.

Changed files
+143 -143
doc
nixos
doc
modules
i18n
input-method
programs
digitalbitbox
zsh
services
system
boot
pkgs
servers
nextcloud
packages
web-apps
wordpress
packages
+2 -2
doc/build-helpers/fetchers.chapter.md
···
If the requested file is present in the Nix store, the resulting derivation will not be built, because its expected output is already available.
Otherwise, the builder will run, but fail with a message explaining to the user how to provide the file. The following code, for example:
-
```
+
```nix
requireFile {
name = "jdk-${version}_linux-x64_bin.tar.gz";
url = "https://www.oracle.com/java/technologies/javase-jdk11-downloads.html";
···
`fetchtorrent` expects two arguments. `url` which can either be a Magnet URI (Magnet Link) such as `magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c` or an HTTP URL pointing to a `.torrent` file. It can also take a `config` argument which will craft a `settings.json` configuration file and give it to `transmission`, the underlying program that is performing the fetch. The available config options for `transmission` can be found [here](https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md#options)
-
```
+
```nix
{ fetchtorrent }:
fetchtorrent {
+2 -2
doc/languages-frameworks/cuelang.section.md
···
Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
Here is an example:
-
```
+
```nix
pkgs.writeCueValidator
(pkgs.writeText "schema.cue" ''
#Def1: {
···
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
Another example, given the following `validator.nix` :
-
```
+
```nix
{ pkgs ? import <nixpkgs> {} }:
let
genericValidator = version:
+1 -1
doc/languages-frameworks/dotnet.section.md
···
$ nuget-to-nix out > deps.nix
```
Which `nuget-to-nix` will generate an output similar to below
-
```
+
```nix
{ fetchNuGet }: [
(fetchNuGet { pname = "FosterFramework"; version = "0.1.15-alpha"; sha256 = "0pzsdfbsfx28xfqljcwy100xhbs6wyx0z1d5qxgmv3l60di9xkll"; })
(fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-x64"; version = "8.0.1"; sha256 = "1gjz379y61ag9whi78qxx09bwkwcznkx2mzypgycibxk61g11da1"; })
+6 -6
doc/languages-frameworks/lisp.section.md
···
Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
-
```
+
```nix
let
sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
in mkShell {
···
Such a Lisp can be now used e.g. to compile your sources:
-
```
+
```nix
buildPhase = ''
${sbcl'}/bin/sbcl --load my-build-file.lisp
''
···
A package defined outside Nixpkgs using `buildASDFSystem` can be woven into the
Nixpkgs-provided scope like this:
-
```
+
```nix
let
alexandria = sbcl.buildASDFSystem rec {
pname = "alexandria";
···
Example of overriding `alexandria`:
-
```
+
```nix
sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
version = "1.4";
src = fetchFromGitLab {
···
To package slashy systems, use `overrideLispAttrs`, like so:
-
```
+
```nix
ecl.pkgs.alexandria.overrideLispAttrs (oldAttrs: {
systems = oldAttrs.systems ++ [ "alexandria/tests" ];
lispLibs = oldAttrs.lispLibs ++ [ ecl.pkgs.rt ];
···
This example wraps CLISP:
-
```
+
```nix
wrapLisp {
pkg = clisp;
faslExt = "fas";
+1 -1
doc/languages-frameworks/pkg-config.section.md
···
A good example of all these things is zlib:
-
```
+
```nix
{ pkg-config, testers, ... }:
stdenv.mkDerivation (finalAttrs: {
+13 -13
doc/languages-frameworks/python.section.md
···
Pytest is the most common test runner for python repositories. A trivial
test run would be:
-
```
+
```nix
nativeCheckInputs = [ pytest ];
checkPhase = ''
runHook preCheck
···
To filter tests using pytest, one can do the following:
-
```
+
```nix
nativeCheckInputs = [ pytest ];
# avoid tests which need additional data or touch network
checkPhase = ''
···
Using the example above, the analogous `pytestCheckHook` usage would be:
-
```
+
```nix
nativeCheckInputs = [
pytestCheckHook
];
···
This is especially useful when tests need to be conditionally disabled,
for example:
-
```
+
```nix
disabledTests = [
# touches network
"download"
···
To help ensure the package still works, [`pythonImportsCheck`](#using-pythonimportscheck) can attempt to import
the listed modules.
-
```
+
```nix
pythonImportsCheck = [
"requests"
"urllib"
···
roughly translates to:
-
```
+
```nix
postCheck = ''
PYTHONPATH=$out/${python.sitePackages}:$PYTHONPATH
python -c "import requests; import urllib"
···
we can do:
-
```
+
```nix
nativeBuildInputs = [
pythonRelaxDepsHook
];
···
Another option is to pass `true`, that will relax/remove all dependencies, for
example:
-
```
+
```nix
nativeBuildInputs = [ pythonRelaxDepsHook ];
pythonRelaxDeps = true;
```
···
`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:
-
```
+
```nix
nativeCheckInputs = [
unittestCheckHook
];
···
It is setup to automatically find common documentation source paths and
render them using the default `html` style.
-
```
+
```nix
outputs = [
"out"
"doc"
···
`doc` output, if it exists. It also provides an automatic diversion
for the artifacts of the `man` builder into the `man` target.
-
```
+
```nix
outputs = [
"out"
"doc"
···
Overwrite `sphinxRoot` when the hook is unable to find your
documentation source root.
-
```
+
```nix
# Configure sphinxRoot for uncommon paths
sphinxRoot = "weird/docs/path";
```
···
the builds are in that case not reproducible. To enable optimizations, override the
interpreter of interest, e.g using
-
```
+
```nix
let
pkgs = import ./. {};
mypython = pkgs.python3.override {
+2 -2
doc/languages-frameworks/rust.section.md
···
and fetches every dependency as a separate fixed-output derivation.
`importCargoLock` can be used as follows:
-
```
+
```nix
cargoDeps = rustPlatform.importCargoLock {
lockFile = ./Cargo.lock;
};
···
hashes need to be specified since they are not available through the
lock file. For example:
-
```
+
```nix
cargoDeps = rustPlatform.importCargoLock {
lockFile = ./Cargo.lock;
outputHashes = {
+1 -1
doc/languages-frameworks/swift.section.md
···
A special function `swiftpmMakeMutable` is available to replace the symlink
with a writable copy:
-
```
+
```nix
configurePhase = generated.configure ++ ''
# Replace the dependency symlink with a writable copy.
swiftpmMakeMutable swift-crypto
+2 -2
doc/packages/darwin-builder.section.md
···
## Example flake usage {#sec-darwin-builder-example-flake}
-
```
+
```nix
{
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-22.11-darwin";
···
To do this, you just need to set the `virtualisation.darwin-builder.*` parameters as
in the example below and rebuild.
-
```
+
```nix
darwin-builder = nixpkgs.lib.nixosSystem {
system = linuxSystem;
modules = [
+1 -1
doc/stdenv/cross-compilation.chapter.md
···
e.g.
-
```
+
```nix
nativeBuildInputs = [
meson
] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
+1 -1
nixos/doc/manual/release-notes/rl-2211.section.md
···
- `services.github-runner` and `services.github-runners.<name>` gained the option `serviceOverrides` which allows overriding the systemd `serviceConfig`. If you have been overriding the systemd service configuration (i.e., by defining `systemd.services.github-runner.serviceConfig`), you have to use the `serviceOverrides` option now. Example:
-
```
+
```nix
services.github-runner.serviceOverrides.SupplementaryGroups = [
"docker"
];
+1 -1
nixos/doc/manual/release-notes/rl-2311.section.md
···
- CoreDNS may be built with external plugins now. This may be done by
overriding `externalPlugins` and `vendorHash` arguments like this:
-
```
+
```nix
services.coredns = {
enable = true;
package = pkgs.coredns.override {
+1 -1
nixos/doc/manual/release-notes/rl-2405.section.md
···
without perl). Previously, the NixOS activation depended on two perl scripts
which can now be replaced via an opt-in mechanism. To make your system
perlless, you can use the new perlless profile:
-
```
+
```nix
{ modulesPath, ... }: {
imports = [ "${modulesPath}/profiles/perlless.nix" ];
}
+7 -7
nixos/modules/i18n/input-method/default.md
···
The following snippet can be used to configure IBus:
-
```
+
```nix
i18n.inputMethod = {
enabled = "ibus";
ibus.engines = with pkgs.ibus-engines; [ anthy hangul mozc ];
···
methods, it must appear in the list of engines along with
`table`. For example:
-
```
+
```nix
ibus.engines = with pkgs.ibus-engines; [ table table-others ];
```
···
The following snippet can be used to configure Fcitx:
-
```
+
```nix
i18n.inputMethod = {
enabled = "fcitx5";
fcitx5.addons = with pkgs; [ fcitx5-mozc fcitx5-hangul fcitx5-m17n ];
···
The following snippet can be used to configure Nabi:
-
```
+
```nix
i18n.inputMethod = {
enabled = "nabi";
};
···
The following snippet can be used to configure uim:
-
```
+
```nix
i18n.inputMethod = {
enabled = "uim";
};
···
The following snippet can be used to configure Hime:
-
```
+
```nix
i18n.inputMethod = {
enabled = "hime";
};
···
The following snippet can be used to configure Kime:
-
```
+
```nix
i18n.inputMethod = {
enabled = "kime";
};
+4 -4
nixos/modules/programs/digitalbitbox/default.md
···
The `digitalbitbox` programs module may be installed by setting
`programs.digitalbitbox` to `true` in a manner similar to
-
```
+
```nix
programs.digitalbitbox.enable = true;
```
and bundles the `digitalbitbox` package (see [](#sec-digitalbitbox-package)),
···
The binaries, `dbb-app` (a GUI tool) and `dbb-cli` (a CLI tool), are available
through the `digitalbitbox` package which could be installed as follows:
-
```
+
```nix
environment.systemPackages = [
pkgs.digitalbitbox
];
···
The digitalbitbox hardware package enables the udev rules for Digital Bitbox
devices and may be installed as follows:
-
```
+
```nix
hardware.digitalbitbox.enable = true;
```
In order to alter the udev rules, one may provide different values for the
`udevRule51` and `udevRule52` attributes by means of overriding as follows:
-
```
+
```nix
programs.digitalbitbox = {
enable = true;
package = pkgs.digitalbitbox.override {
+1 -1
nixos/modules/programs/plotinus.md
···
To enable Plotinus, add the following to your
{file}`configuration.nix`:
-
```
+
```nix
programs.plotinus.enable = true;
```
+4 -4
nixos/modules/programs/zsh/oh-my-zsh.md
···
The module uses the `oh-my-zsh` package with all available
features. The initial setup using Nix expressions is fairly similar to the
configuration format of `oh-my-zsh`.
-
```
+
```nix
{
programs.zsh.ohMyZsh = {
enable = true;
···
scripts.
The module can do this as well:
-
```
+
```nix
{
programs.zsh.ohMyZsh.custom = "~/path/to/custom/scripts";
}
···
Rather than using a single mutable path for `ZSH_CUSTOM`,
it's also possible to generate this path from a list of Nix packages:
-
```
+
```nix
{ pkgs, ... }:
{
programs.zsh.ohMyZsh.customPkgs = [
···
[upstream repo.](https://github.com/robbyrussell/oh-my-zsh/tree/91b771914bc7c43dd7c7a43b586c5de2c225ceb7/plugins)
A derivation for `oh-my-zsh` may look like this:
-
```
+
```nix
{ stdenv, fetchFromGitHub }:
stdenv.mkDerivation rec {
+3 -3
nixos/modules/services/backup/borgbackup.md
···
## Basic usage for a local backup {#opt-services-backup-borgbackup-local-directory}
A very basic configuration for backing up to a locally accessible directory is:
-
```
+
```nix
{
opt.services.borgbackup.jobs = {
{ rootBackup = {
···
```
Add the following snippet to your NixOS configuration:
-
```
+
```nix
{
services.borgbackup.repos = {
my_borg_repo = {
···
{file}`/run/keys/borgbackup_passphrase`, which should be only
accessible by root
-
```
+
```nix
{
services.borgbackup.jobs = {
backupToLocalServer = {
+3 -3
nixos/modules/services/databases/foundationdb.md
···
To enable FoundationDB, add the following to your
{file}`configuration.nix`:
-
```
+
```nix
services.foundationdb.enable = true;
services.foundationdb.package = pkgs.foundationdb71; # FoundationDB 7.1.x
```
···
FoundationDB stores all data for all server processes under
{file}`/var/lib/foundationdb`. You can override this using
{option}`services.foundationdb.dataDir`, e.g.
-
```
+
```nix
services.foundationdb.dataDir = "/data/fdb";
```
···
For example, to create backups in {command}`/opt/fdb-backups`, first
set up the paths in the module options:
-
```
+
```nix
services.foundationdb.extraReadWritePaths = [ "/opt/fdb-backups" ];
```
+6 -6
nixos/modules/services/databases/postgresql.md
···
## Configuring {#module-services-postgres-configuring}
To enable PostgreSQL, add the following to your {file}`configuration.nix`:
-
```
+
```nix
services.postgresql.enable = true;
services.postgresql.package = pkgs.postgresql_15;
```
···
-->
By default, PostgreSQL stores its databases in {file}`/var/lib/postgresql/$psqlSchema`. You can override this using [](#opt-services.postgresql.dataDir), e.g.
-
```
+
```nix
services.postgresql.dataDir = "/data/postgresql";
```
···
"13"
```
For an upgrade, a script like this can be used to simplify the process:
-
```
+
```nix
{ config, pkgs, ... }:
{
environment.systemPackages = [
···
```
To add plugins via NixOS configuration, set `services.postgresql.extraPlugins`:
-
```
+
```nix
services.postgresql.package = pkgs.postgresql_12;
services.postgresql.extraPlugins = ps: with ps; [
pg_repack
···
```
You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function `.withPackages`. For example, creating a custom PostgreSQL package in an overlay can look like:
-
```
+
```nix
self: super: {
postgresql_custom = self.postgresql_12.withPackages (ps: [
ps.pg_repack
···
```
Here's a recipe on how to override a particular plugin through an overlay:
-
```
+
```nix
self: super: {
postgresql_15 = super.postgresql_15// {
pkgs = super.postgresql_15.pkgs // {
+2 -2
nixos/modules/services/databases/tigerbeetle.md
···
TigerBeetle is a distributed financial accounting database designed for mission critical safety and performance.
To enable TigerBeetle, add the following to your {file}`configuration.nix`:
-
```
+
```nix
services.tigerbeetle.enable = true;
```
···
To configure it to listen on a different interface (and to configure it to connect to other replicas, if you're creating more than one), you'll have to set the `addresses` option.
Note that the TigerBeetle module won't open any firewall ports automatically, so if you configure it to listen on an external interface, you'll need to ensure that connections can reach it:
-
```
+
```nix
services.tigerbeetle = {
enable = true;
addresses = [ "0.0.0.0:3001" ];
+2 -2
nixos/modules/services/desktops/flatpak.md
···
applications on Linux.
To enable Flatpak, add the following to your {file}`configuration.nix`:
-
```
+
```nix
services.flatpak.enable = true;
```
···
be installed. If you run GNOME, this will be handled automatically for you;
in other cases, you will need to add something like the following to your
{file}`configuration.nix`:
-
```
+
```nix
xdg.portal.extraPortals = [ pkgs.xdg-desktop-portal-gtk ];
xdg.portal.config.common.default = "gtk";
```
+3 -3
nixos/modules/services/development/athens.md
···
## Basic usage for a caching proxy configuration {#opt-services-development-athens-caching-proxy}
A very basic configuration for Athens that acts as a caching and forwarding HTTP proxy is:
-
```
+
```nix
{
services.athens = {
enable = true;
···
If you want to prevent Athens from writing to disk, you can instead configure it to cache modules only in memory:
-
```
+
```nix
{
services.athens = {
enable = true;
···
To use the local proxy in Go builds, you can set the proxy as environment variable:
-
```
+
```nix
{
environment.variables = {
GOPROXY = "http://localhost:3000"
+1 -1
nixos/modules/services/development/blackfire.md
···
[Blackfire](https://blackfire.io) is a proprietary tool for profiling applications. There are several languages supported by the product but currently only PHP support is packaged in Nixpkgs. The back-end consists of a module that is loaded into the language runtime (called *probe*) and a service (*agent*) that the probe connects to and that sends the profiles to the server.
To use it, you will need to enable the agent and the probe on your server. The exact method will depend on the way you use PHP but here is an example of NixOS configuration for PHP-FPM:
-
```
+
```nix
let
php = pkgs.php.withExtensions ({ enabled, all }: enabled ++ (with all; [
blackfire
+2 -2
nixos/modules/services/development/livebook.md
···
[`systemd`](https://www.freedesktop.org/wiki/Software/systemd/) unit
which runs the server.
-
```
+
```nix
{ ... }:
{
···
learning Kinos require `gcc` and `gnumake`. To add these, use
`extraPackages`:
-
```
+
```nix
services.livebook.extraPackages = with pkgs; [ gcc gnumake ];
```
+5 -5
nixos/modules/services/editors/emacs.md
···
::: {.example #module-services-emacs-configuration-nix}
### Custom Emacs in `configuration.nix`
-
```
+
```nix
{
environment.systemPackages = [
# [...]
···
::: {.example #module-services-emacs-config-nix}
### Custom Emacs in `~/.config/nixpkgs/config.nix`
-
```
+
```nix
{
packageOverrides = super: let self = super.pkgs; in {
myemacs = import ./emacs.nix { pkgs = self; };
···
::: {.example #ex-emacsGtk3Nix}
### Custom Emacs build
-
```
+
```nix
{ pkgs ? import <nixpkgs> {} }:
let
myEmacs = (pkgs.emacs.override {
···
To install and enable the {command}`systemd` user service for Emacs
daemon, add the following to your {file}`configuration.nix`:
-
```
+
```nix
services.emacs.enable = true;
```
···
by symlinks in {file}`/etc/systemd/user`. In the case where
Emacs daemon is not wanted for all users, it is possible to install the
service but not globally enable it:
-
```
+
```nix
services.emacs.enable = false;
services.emacs.install = true;
```
+2 -2
nixos/modules/services/mail/mailman.md
···
## Basic usage with Postfix {#module-services-mailman-basic-usage}
For a basic configuration with Postfix as the MTA, the following settings are suggested:
-
```
+
```nix
{ config, ... }: {
services.postfix = {
enable = true;
···
## Using with other MTAs {#module-services-mailman-other-mtas}
Mailman also supports other MTA, though with a little bit more configuration. For example, to use Mailman with Exim, you can use the following settings:
-
```
+
```nix
{ config, ... }: {
services = {
mailman = {
+2 -2
nixos/modules/services/matrix/mjolnir.md
···
set in [services.mjolnir.homeserverUrl](#opt-services.mjolnir.homeserverUrl) and Mjolnir itself
will be configured to connect to the new Pantalaimon instance.
-
```
+
```nix
{
services.mjolnir = {
enable = true;
···
To use the Antispam Module, add `matrix-synapse-plugins.matrix-synapse-mjolnir-antispam`
to the Synapse plugin list and enable the `mjolnir.Module` module.
-
```
+
```nix
{
services.matrix-synapse = {
plugins = with pkgs; [
+3 -3
nixos/modules/services/matrix/synapse.md
···
the host `myhostname.example.org`. For more information,
please refer to the
[installation instructions of Synapse](https://element-hq.github.io/synapse/latest/setup/installation.html) .
-
```
+
```nix
{ pkgs, lib, config, ... }:
let
fqdn = "${config.networking.hostName}.${config.networking.domain}";
···
by `matrix-synapse`.
- Include the file like this in your configuration:
-
```
+
```nix
{
services.matrix-synapse.extraConfigFiles = [
"/run/secrets/matrix-shared-secret"
···
Matrix Identifier. See
[Try Matrix Now!](https://matrix.org/docs/projects/try-matrix-now.html)
for a list of existing clients and their supported featureset.
-
```
+
```nix
{
services.nginx.virtualHosts."element.${fqdn}" = {
enableACME = true;
+3 -3
nixos/modules/services/misc/anki-sync-server.md
···
`DynamicUser` option.
This can be done by enabling the `anki-sync-server` service:
-
```
+
```nix
{ ... }:
{
···
It is necessary to set at least one username-password pair under
{option}`services.anki-sync-server.users`. For example
-
```
+
```nix
{
services.anki-sync-server.users = [
{
···
in most circumstances, because the sync server doesn't use HTTPS), then set the
following options:
-
```
+
```nix
{
services.anki-sync-server.host = "0.0.0.0";
services.anki-sync-server.openFirewall = true;
+2 -2
nixos/modules/services/misc/gitlab.md
···
For instance, the following configuration could be used to use nginx as
frontend proxy:
-
```
+
```nix
services.nginx = {
enable = true;
recommendedGzipSettings = true;
···
all data like the repositories and uploads will be stored.
A basic configuration with some custom settings could look like this:
-
```
+
```nix
services.gitlab = {
enable = true;
databasePasswordFile = "/var/keys/gitlab/db_password";
+1 -1
nixos/modules/services/misc/sourcehut/default.md
···
and `services.postgresql` services.
A very basic configuration may look like this:
-
```
+
```nix
{ pkgs, ... }:
let
fqdn =
+2 -2
nixos/modules/services/misc/weechat.md
···
session.
This can be done by enabling the `weechat` service:
-
```
+
```nix
{ ... }:
{
···
`screenrc` needs to be tweaked by adding
[multiuser](https://www.gnu.org/software/screen/manual/html_node/Multiuser.html#Multiuser)
support:
-
```
+
```nix
{
programs.screen.screenrc = ''
multiuser on
+1 -1
nixos/modules/services/monitoring/goss.md
···
A minimal configuration looks like this:
-
```
+
```nix
{
services.goss = {
enable = true;
+4 -4
nixos/modules/services/monitoring/prometheus/exporters.md
···
[node exporter](https://github.com/prometheus/node_exporter),
it provides hardware and OS metrics from the host it's
running on. The exporter could be configured as follows:
-
```
+
```nix
services.prometheus.exporters.node = {
enable = true;
port = 9100;
···
the [available options](https://nixos.org/nixos/options.html#prometheus.exporters).
Prometheus can now be configured to consume the metrics produced by the exporter:
-
```
+
```nix
services.prometheus = {
# ...
···
`nixos/modules/services/monitoring/prometheus/exporters/`
directory, which will be called postfix.nix and contains all exporter
specific options and configuration:
-
```
+
```nix
# nixpkgs/nixos/modules/services/prometheus/exporters/postfix.nix
{ config, lib, pkgs, options }:
···
Should an exporter option change at some point, it is possible to add
information about the change to the exporter definition similar to
`nixpkgs/nixos/modules/rename.nix`:
-
```
+
```nix
{ config, lib, pkgs, options }:
with lib;
+1 -1
nixos/modules/services/network-filesystems/litestream/default.md
···
Litestream service is managed by a dedicated user named `litestream`
which needs permission to the database file. Here's an example config which gives
required permissions to access [grafana database](#opt-services.grafana.settings.database.path):
-
```
+
```nix
{ pkgs, ... }:
{
users.users.litestream.extraGroups = [ "grafana" ];
+3 -3
nixos/modules/services/networking/pleroma.md
···
## Initializing the database {#module-services-pleroma-initialize-db}
First, the Postgresql service must be enabled in the NixOS configuration
-
```
+
```nix
services.postgresql = {
enable = true;
package = pkgs.postgresql_13;
···
In this section we will enable the Pleroma service only locally, so its configurations can be improved incrementally.
This is an example of configuration, where [](#opt-services.pleroma.configs) option contains the content of the file `config.exs`, generated [in the first section](#module-services-pleroma-generate-config), but with the secrets (database password, endpoint secret key, salts, etc.) removed. Removing secrets is important, because otherwise they will be stored publicly in the Nix store.
-
```
+
```nix
services.pleroma = {
enable = true;
secretConfigFile = "/var/lib/pleroma/secrets.exs";
···
In this configuration, Pleroma is listening only on the local port 4000. Nginx can be configured as a Reverse Proxy, for forwarding requests from public ports to the Pleroma service. This is an example of configuration, using
[Let's Encrypt](https://letsencrypt.org/) for the TLS certificates
-
```
+
```nix
security.acme = {
email = "root@example.net";
acceptTerms = true;
+2 -2
nixos/modules/services/networking/prosody.md
···
[Multi User Chat (MUC)](https://xmpp.org/extensions/xep-0045.html)
endpoint as well as a [HTTP File Upload](https://xmpp.org/extensions/xep-0363.html)
endpoint will look like this:
-
```
+
```nix
services.prosody = {
enable = true;
admins = [ "root@example.org" ];
···
Provided the setup detailed in the previous section, you'll need the following acme configuration to generate
a TLS certificate for the three endponits:
-
```
+
```nix
security.acme = {
email = "root@example.org";
acceptTerms = true;
+3 -3
nixos/modules/services/networking/yggdrasil.md
···
### Simple ephemeral node {#module-services-networking-yggdrasil-configuration-simple}
An annotated example of a simple configuration:
-
```
+
```nix
{
services.yggdrasil = {
enable = true;
···
### Persistent node with prefix {#module-services-networking-yggdrasil-configuration-prefix}
A node with a fixed address that announces a prefix:
-
```
+
```nix
let
address = "210:5217:69c0:9afc:1b95:b9f:8718:c3d2";
prefix = "310:5217:69c0:9afc";
···
A NixOS container attached to the Yggdrasil network via a node running on the
host:
-
```
+
```nix
let
yggPrefix64 = "310:5217:69c0:9afc";
# Again, taken from the output of "yggdrasilctl getself".
+2 -2
nixos/modules/services/web-apps/c2fmzq-server.md
···
including but not limited to pictures and videos.
The service `c2fmzq-server` can be enabled by setting
-
```
+
```nix
{
services.c2fmzq-server.enable = true;
}
···
are command line options to manage HTTPS certificates directly, but the module
is designed to be served behind a reverse proxy or only accessed via localhost.
-
```
+
```nix
{
services.c2fmzq-server = {
enable = true;
+5 -5
nixos/modules/services/web-apps/discourse.md
···
## Basic usage {#module-services-discourse-basic-usage}
A minimal configuration using Let's Encrypt for TLS certificates looks like this:
-
```
+
```nix
services.discourse = {
enable = true;
hostname = "discourse.example.com";
···
and [](#opt-services.discourse.sslCertificateKey)
options:
-
```
+
```nix
services.discourse = {
enable = true;
hostname = "discourse.example.com";
···
[hostname](#opt-services.discourse.hostname) as
email domain can be done like this:
-
```
+
```nix
services.discourse = {
enable = true;
hostname = "discourse.example.com";
···
Discourse instance and enables
GitHub login in the site settings,
and changes a few request limits in the backend settings:
-
```
+
```nix
services.discourse = {
enable = true;
hostname = "discourse.example.com";
···
plugins, and disable `discourse-spoiler-alert`
by default:
-
```
+
```nix
services.discourse = {
enable = true;
hostname = "discourse.example.com";
+3 -3
nixos/modules/services/web-apps/grocy.md
···
## Basic usage {#module-services-grocy-basic-usage}
A very basic configuration may look like this:
-
```
+
```nix
{ pkgs, ... }:
{
services.grocy = {
···
The configuration for `grocy` is located at `/etc/grocy/config.php`.
By default, the following settings can be defined in the NixOS-configuration:
-
```
+
```nix
{ pkgs, ... }:
{
services.grocy.settings = {
···
If you want to alter the configuration file on your own, you can do this manually with
an expression like this:
-
```
+
```nix
{ lib, ... }:
{
environment.etc."grocy/config.php".text = lib.mkAfter ''
+2 -2
nixos/modules/services/web-apps/jitsi-meet.md
···
## Basic usage {#module-services-jitsi-basic-usage}
A minimal configuration using Let's Encrypt for TLS certificates looks like this:
-
```
+
```nix
{
services.jitsi-meet = {
enable = true;
···
## Configuration {#module-services-jitsi-configuration}
Here is the minimal configuration with additional configurations:
-
```
+
```nix
{
services.jitsi-meet = {
enable = true;
+1 -1
nixos/modules/services/web-apps/keycloak.md
···
## Example configuration {#module-services-keycloak-example-config}
A basic configuration with some custom settings could look like this:
-
```
+
```nix
services.keycloak = {
enable = true;
settings = {
+3 -3
nixos/modules/services/web-apps/nextcloud.md
···
socket.
A very basic configuration may look like this:
-
```
+
```nix
{ pkgs, ... }:
{
services.nextcloud = {
···
[corresponding `phpfpm` pool](#opt-services.phpfpm.pools).
An exemplary configuration may look like this:
-
```
+
```nix
{ config, lib, pkgs, ... }: {
services.nginx.enable = false;
services.nextcloud = {
···
in NixOS for a safe upgrade-path before removing those. In that case we should keep those
packages, but mark them as insecure in an expression like this (in
`<nixpkgs/pkgs/servers/nextcloud/default.nix>`):
-
```
+
```nix
/* ... */
{
nextcloud17 = generic {
+1 -1
nixos/modules/services/web-apps/plausible.md
···
```
After that, `plausible` can be deployed like this:
-
```
+
```nix
{
services.plausible = {
enable = true;
+1 -1
nixos/modules/services/web-servers/garage.md
···
in NixOS for a safe upgrade-path before removing those. In that case we should keep those
packages, but mark them as insecure in an expression like this (in
`<nixpkgs/pkgs/tools/filesystem/garage/default.nix>`):
-
```
+
```nix
/* ... */
{
garage_0_7_3 = generic {
+9 -9
nixos/modules/services/x11/desktop-managers/gnome.md
···
To enable the GNOME desktop use:
-
```
+
```nix
services.xserver.desktopManager.gnome.enable = true;
services.xserver.displayManager.gdm.enable = true;
```
···
If you’d like to only use the GNOME desktop and not the apps, you can disable them with:
-
```
+
```nix
services.gnome.core-utilities.enable = false;
```
···
It is also possible to disable many of the [core services](https://github.com/NixOS/nixpkgs/blob/b8ec4fd2a4edc4e30d02ba7b1a2cc1358f3db1d5/nixos/modules/services/x11/desktop-managers/gnome.nix#L329-L348). For example, if you do not need indexing files, you can disable Tracker with:
-
```
+
```nix
services.gnome.tracker-miners.enable = false;
services.gnome.tracker.enable = false;
```
···
You can install all of the GNOME games with:
-
```
+
```nix
services.gnome.games.enable = true;
```
···
You can install GNOME core developer tools with:
-
```
+
```nix
services.gnome.core-developer-tools.enable = true;
```
···
GNOME Flashback provides a desktop environment based on the classic GNOME 2 architecture. You can enable the default GNOME Flashback session, which uses the Metacity window manager, with:
-
```
+
```nix
services.xserver.desktopManager.gnome.flashback.enableMetacity = true;
```
···
The following example uses `xmonad` window manager:
-
```
+
```nix
services.xserver.desktopManager.gnome.flashback.customSessions = [
{
wmName = "xmonad";
···
You can install them like any other package:
-
```
+
```nix
environment.systemPackages = [
gnomeExtensions.dash-to-dock
gnomeExtensions.gsconnect
···
### Example {#sec-gnome-gsettings-overrides-example}
-
```
+
```nix
services.xserver.desktopManager.gnome = {
extraGSettingsOverrides = ''
# Change default background
+5 -5
nixos/modules/services/x11/desktop-managers/pantheon.md
···
## Enabling Pantheon {#sec-pantheon-enable}
All of Pantheon is working in NixOS and the applications should be available, aside from a few [exceptions](https://github.com/NixOS/nixpkgs/issues/58161). To enable Pantheon, set
-
```
+
```nix
services.xserver.desktopManager.pantheon.enable = true;
```
This automatically enables LightDM and Pantheon's LightDM greeter. If you'd like to disable this, set
-
```
+
```nix
services.xserver.displayManager.lightdm.greeters.pantheon.enable = false;
services.xserver.displayManager.lightdm.enable = false;
```
but please be aware using Pantheon without LightDM as a display manager will break screenlocking from the UI. The NixOS module for Pantheon installs all of Pantheon's default applications. If you'd like to not install Pantheon's apps, set
-
```
+
```nix
services.pantheon.apps.enable = false;
```
You can also use [](#opt-environment.pantheon.excludePackages) to remove any other app (like `elementary-mail`).
···
to configure the programs with plugs or indicators.
The difference in NixOS is both these programs are patched to load plugins from a directory that is the value of an environment variable. All of which is controlled in Nix. If you need to configure the particular packages manually you can override the packages like:
-
```
+
```nix
wingpanel-with-indicators.override {
indicators = [
pkgs.some-special-indicator
···
};
```
please note that, like how the NixOS options describe these as extra plugins, this would only add to the default plugins included with the programs. If for some reason you'd like to configure which plugins to use exactly, both packages have an argument for this:
-
```
+
```nix
wingpanel-with-indicators.override {
useDefaultIndicators = false;
indicators = specialListOfIndicators;
+2 -2
nixos/modules/system/boot/clevis.md
···
In order to activate unattended decryption of a resource at boot, enable the `clevis` module:
-
```
+
```nix
boot.initrd.clevis.enable = true;
```
Then, specify the device you want to decrypt using a given clevis secret. Clevis will automatically try to decrypt the device at boot and will fallback to interactive unlocking if the decryption policy is not fulfilled.
-
```
+
```nix
boot.initrd.clevis.devices."/dev/nvme0n1p1".secretFile = ./nvme0n1p1.jwe;
```
+1 -1
pkgs/README.md
···
For example in this case:
-
```
+
```nix
jbidwatcher = throw "jbidwatcher was discontinued in march 2021"; # added 2021-03-15
```
+1 -1
pkgs/servers/nextcloud/packages/README.md
···
The apps will be available in the namespace `nextcloud25Packages.apps`.
Using it together with the Nextcloud module could look like this:
-
```
+
```nix
services.nextcloud = {
enable = true;
package = pkgs.nextcloud25;
+1 -1
pkgs/servers/web-apps/wordpress/packages/README.md
···
The plugins will be available in the namespace `wordpressPackages.plugins`.
Using it together with the Wordpress module could look like this:
-
```
+
```nix
services.wordpress = {
sites."blog.${config.networking.domain}" = {
plugins = with pkgs.wordpressPackages.plugins; [