treewide: Mark Nix blocks in markdown as Nix
This should help us with highlighting and future formatting.
This commit is contained in:
Janne Heß
Valentin Gagarin
parent
3a1b8df5dc
commit
bc77c7a973
|
|
@ -243,7 +243,7 @@ This is a useful last-resort workaround for license restrictions that prohibit r
|
|||
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";
|
||||
|
|
@ -270,7 +270,7 @@ It produces packages that cannot be built automatically.
|
|||
|
||||
`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 {
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet:
|
|||
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: {
|
||||
|
|
@ -42,7 +42,7 @@ pkgs.writeCueValidator
|
|||
`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:
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@ the packages inside the `out` directory.
|
|||
$ 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"; })
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ $ sbcl
|
|||
|
||||
Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
|
||||
|
||||
```
|
||||
```nix
|
||||
let
|
||||
sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
|
||||
in mkShell {
|
||||
|
|
@ -55,7 +55,7 @@ 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
|
||||
''
|
||||
|
|
@ -173,7 +173,7 @@ into the package scope with `withOverrides`.
|
|||
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";
|
||||
|
|
@ -199,7 +199,7 @@ new package with different parameters.
|
|||
|
||||
Example of overriding `alexandria`:
|
||||
|
||||
```
|
||||
```nix
|
||||
sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
|
||||
version = "1.4";
|
||||
src = fetchFromGitLab {
|
||||
|
|
@ -225,7 +225,7 @@ vice versa.
|
|||
|
||||
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 ];
|
||||
|
|
@ -290,7 +290,7 @@ derivation.
|
|||
|
||||
This example wraps CLISP:
|
||||
|
||||
```
|
||||
```nix
|
||||
wrapLisp {
|
||||
pkg = clisp;
|
||||
faslExt = "fas";
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixp
|
|||
|
||||
A good example of all these things is zlib:
|
||||
|
||||
```
|
||||
```nix
|
||||
{ pkg-config, testers, ... }:
|
||||
|
||||
stdenv.mkDerivation (finalAttrs: {
|
||||
|
|
|
|||
|
|
@ -1197,7 +1197,7 @@ a good indication that the package is not in a valid state.
|
|||
Pytest is the most common test runner for python repositories. A trivial
|
||||
test run would be:
|
||||
|
||||
```
|
||||
```nix
|
||||
nativeCheckInputs = [ pytest ];
|
||||
checkPhase = ''
|
||||
runHook preCheck
|
||||
|
|
@ -1213,7 +1213,7 @@ sandbox, and will generally need many tests to be disabled.
|
|||
|
||||
To filter tests using pytest, one can do the following:
|
||||
|
||||
```
|
||||
```nix
|
||||
nativeCheckInputs = [ pytest ];
|
||||
# avoid tests which need additional data or touch network
|
||||
checkPhase = ''
|
||||
|
|
@ -1248,7 +1248,7 @@ when a package may need many items disabled to run the test suite.
|
|||
|
||||
Using the example above, the analogous `pytestCheckHook` usage would be:
|
||||
|
||||
```
|
||||
```nix
|
||||
nativeCheckInputs = [
|
||||
pytestCheckHook
|
||||
];
|
||||
|
|
@ -1273,7 +1273,7 @@ Using the example above, the analogous `pytestCheckHook` usage would be:
|
|||
This is especially useful when tests need to be conditionally disabled,
|
||||
for example:
|
||||
|
||||
```
|
||||
```nix
|
||||
disabledTests = [
|
||||
# touches network
|
||||
"download"
|
||||
|
|
@ -1298,7 +1298,7 @@ all packages have test suites that can be run easily, and some have none at all.
|
|||
To help ensure the package still works, [`pythonImportsCheck`](#using-pythonimportscheck) can attempt to import
|
||||
the listed modules.
|
||||
|
||||
```
|
||||
```nix
|
||||
pythonImportsCheck = [
|
||||
"requests"
|
||||
"urllib"
|
||||
|
|
@ -1307,7 +1307,7 @@ the listed modules.
|
|||
|
||||
roughly translates to:
|
||||
|
||||
```
|
||||
```nix
|
||||
postCheck = ''
|
||||
PYTHONPATH=$out/${python.sitePackages}:$PYTHONPATH
|
||||
python -c "import requests; import urllib"
|
||||
|
|
@ -1342,7 +1342,7 @@ pkg3>=1.0,<=2.0
|
|||
|
||||
we can do:
|
||||
|
||||
```
|
||||
```nix
|
||||
nativeBuildInputs = [
|
||||
pythonRelaxDepsHook
|
||||
];
|
||||
|
|
@ -1365,7 +1365,7 @@ pkg3
|
|||
Another option is to pass `true`, that will relax/remove all dependencies, for
|
||||
example:
|
||||
|
||||
```
|
||||
```nix
|
||||
nativeBuildInputs = [ pythonRelaxDepsHook ];
|
||||
pythonRelaxDeps = true;
|
||||
```
|
||||
|
|
@ -1392,7 +1392,7 @@ work with any of the [existing hooks](#setup-hooks).
|
|||
|
||||
`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
|
||||
];
|
||||
|
|
@ -1409,7 +1409,7 @@ using the popular Sphinx documentation generator.
|
|||
It is setup to automatically find common documentation source paths and
|
||||
render them using the default `html` style.
|
||||
|
||||
```
|
||||
```nix
|
||||
outputs = [
|
||||
"out"
|
||||
"doc"
|
||||
|
|
@ -1424,7 +1424,7 @@ The hook will automatically build and install the artifact into the
|
|||
`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"
|
||||
|
|
@ -1441,7 +1441,7 @@ for the artifacts of the `man` builder into the `man` target.
|
|||
Overwrite `sphinxRoot` when the hook is unable to find your
|
||||
documentation source root.
|
||||
|
||||
```
|
||||
```nix
|
||||
# Configure sphinxRoot for uncommon paths
|
||||
sphinxRoot = "weird/docs/path";
|
||||
```
|
||||
|
|
@ -1920,7 +1920,7 @@ The Python interpreters are by default not built with optimizations enabled, bec
|
|||
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 {
|
||||
|
|
|
|||
|
|
@ -458,7 +458,7 @@ function does not require a hash (unless git dependencies are used)
|
|||
and fetches every dependency as a separate fixed-output derivation.
|
||||
`importCargoLock` can be used as follows:
|
||||
|
||||
```
|
||||
```nix
|
||||
cargoDeps = rustPlatform.importCargoLock {
|
||||
lockFile = ./Cargo.lock;
|
||||
};
|
||||
|
|
@ -468,7 +468,7 @@ If the `Cargo.lock` file includes git dependencies, then their output
|
|||
hashes need to be specified since they are not available through the
|
||||
lock file. For example:
|
||||
|
||||
```
|
||||
```nix
|
||||
cargoDeps = rustPlatform.importCargoLock {
|
||||
lockFile = ./Cargo.lock;
|
||||
outputHashes = {
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ them, we need to make them writable.
|
|||
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
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
|
|||
|
||||
## Example flake usage {#sec-darwin-builder-example-flake}
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
inputs = {
|
||||
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-22.11-darwin";
|
||||
|
|
@ -153,7 +153,7 @@ you may use it to build a modified remote builder with additional storage or mem
|
|||
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 = [
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ Add `mesonEmulatorHook` to `nativeBuildInputs` conditionally on if the target bi
|
|||
|
||||
e.g.
|
||||
|
||||
```
|
||||
```nix
|
||||
nativeBuildInputs = [
|
||||
meson
|
||||
] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@ In addition to numerous new and upgraded packages, this release includes the fol
|
|||
|
||||
- `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"
|
||||
];
|
||||
|
|
|
|||
|
|
@ -1228,7 +1228,7 @@ Make sure to also check the many updates in the [Nixpkgs library](#sec-release-2
|
|||
- 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 {
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Use `services.pipewire.extraConfig` or `services.pipewire.configPackages` for Pi
|
|||
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" ];
|
||||
}
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ friendly input method user interface.
|
|||
|
||||
The following snippet can be used to configure IBus:
|
||||
|
||||
```
|
||||
```nix
|
||||
i18n.inputMethod = {
|
||||
enabled = "ibus";
|
||||
ibus.engines = with pkgs.ibus-engines; [ anthy hangul mozc ];
|
||||
|
|
@ -48,7 +48,7 @@ Available extra IBus engines are:
|
|||
methods, it must appear in the list of engines along with
|
||||
`table`. For example:
|
||||
|
||||
```
|
||||
```nix
|
||||
ibus.engines = with pkgs.ibus-engines; [ table table-others ];
|
||||
```
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ built-in Input Method Engine, Pinyin, QuWei and Table-based input methods.
|
|||
|
||||
The following snippet can be used to configure Fcitx:
|
||||
|
||||
```
|
||||
```nix
|
||||
i18n.inputMethod = {
|
||||
enabled = "fcitx5";
|
||||
fcitx5.addons = with pkgs; [ fcitx5-mozc fcitx5-hangul fcitx5-m17n ];
|
||||
|
|
@ -110,7 +110,7 @@ phonetic Korean characters (hangul) and pictographic Korean characters
|
|||
|
||||
The following snippet can be used to configure Nabi:
|
||||
|
||||
```
|
||||
```nix
|
||||
i18n.inputMethod = {
|
||||
enabled = "nabi";
|
||||
};
|
||||
|
|
@ -123,7 +123,7 @@ framework. Applications can use it through so-called bridges.
|
|||
|
||||
The following snippet can be used to configure uim:
|
||||
|
||||
```
|
||||
```nix
|
||||
i18n.inputMethod = {
|
||||
enabled = "uim";
|
||||
};
|
||||
|
|
@ -141,7 +141,7 @@ etc...
|
|||
|
||||
The following snippet can be used to configure Hime:
|
||||
|
||||
```
|
||||
```nix
|
||||
i18n.inputMethod = {
|
||||
enabled = "hime";
|
||||
};
|
||||
|
|
@ -153,7 +153,7 @@ Kime is Korean IME. it's built with Rust language and let you get simple, safe,
|
|||
|
||||
The following snippet can be used to configure Kime:
|
||||
|
||||
```
|
||||
```nix
|
||||
i18n.inputMethod = {
|
||||
enabled = "kime";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Digital Bitbox is a hardware wallet and second-factor authenticator.
|
|||
|
||||
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)),
|
||||
|
|
@ -21,7 +21,7 @@ For more information, see <https://digitalbitbox.com/start_linux>.
|
|||
|
||||
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
|
||||
];
|
||||
|
|
@ -31,13 +31,13 @@ environment.systemPackages = [
|
|||
|
||||
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 {
|
||||
|
|
|
|||
|
|
@ -12,6 +12,6 @@ palette provides a searchable list of of all menu items in the application.
|
|||
|
||||
To enable Plotinus, add the following to your
|
||||
{file}`configuration.nix`:
|
||||
```
|
||||
```nix
|
||||
programs.plotinus.enable = true;
|
||||
```
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ prompt themes.
|
|||
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;
|
||||
|
|
@ -33,7 +33,7 @@ environment variable for this which points to a directory with additional
|
|||
scripts.
|
||||
|
||||
The module can do this as well:
|
||||
```
|
||||
```nix
|
||||
{
|
||||
programs.zsh.ohMyZsh.custom = "~/path/to/custom/scripts";
|
||||
}
|
||||
|
|
@ -48,7 +48,7 @@ which bundles completion scripts and a plugin for `oh-my-zsh`.
|
|||
|
||||
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 = [
|
||||
|
|
@ -89,7 +89,7 @@ If third-party customizations (e.g. new themes) are supposed to be added to
|
|||
[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 {
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ A complete list of options for the Borgbase module may be found
|
|||
## 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 = {
|
||||
|
|
@ -59,7 +59,7 @@ ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAID78zmOyA+5uPG4Ot0hfAy+sLDPU1L4AiIoRYEIVbbQ/
|
|||
```
|
||||
|
||||
Add the following snippet to your NixOS configuration:
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.borgbackup.repos = {
|
||||
my_borg_repo = {
|
||||
|
|
@ -80,7 +80,7 @@ that you have stored a secret passphrasse in the file
|
|||
{file}`/run/keys/borgbackup_passphrase`, which should be only
|
||||
accessible by root
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.borgbackup.jobs = {
|
||||
backupToLocalServer = {
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ key-value store.
|
|||
|
||||
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
|
||||
```
|
||||
|
|
@ -109,7 +109,7 @@ default configuration. See below for more on scaling to increase this.
|
|||
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";
|
||||
```
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ directories.
|
|||
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" ];
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ PostgreSQL is an advanced, free relational database.
|
|||
## 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;
|
||||
```
|
||||
|
|
@ -35,7 +35,7 @@ alice=>
|
|||
-->
|
||||
|
||||
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";
|
||||
```
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ $ nix-instantiate --eval -A postgresql_13.psqlSchema
|
|||
"13"
|
||||
```
|
||||
For an upgrade, a script like this can be used to simplify the process:
|
||||
```
|
||||
```nix
|
||||
{ config, pkgs, ... }:
|
||||
{
|
||||
environment.systemPackages = [
|
||||
|
|
@ -256,7 +256,7 @@ postgresql_15.pkgs.pg_partman postgresql_15.pkgs.pgroonga
|
|||
```
|
||||
|
||||
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
|
||||
|
|
@ -265,7 +265,7 @@ services.postgresql.extraPlugins = ps: with ps; [
|
|||
```
|
||||
|
||||
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
|
||||
|
|
@ -275,7 +275,7 @@ self: super: {
|
|||
```
|
||||
|
||||
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 // {
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
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;
|
||||
```
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ By default, TigerBeetle will only listen on a local interface.
|
|||
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" ];
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Flatpak is a system for building, distributing, and running sandboxed desktop
|
|||
applications on Linux.
|
||||
|
||||
To enable Flatpak, add the following to your {file}`configuration.nix`:
|
||||
```
|
||||
```nix
|
||||
services.flatpak.enable = true;
|
||||
```
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ For the sandboxed apps to work correctly, desktop integration portals need to
|
|||
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";
|
||||
```
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ A complete list of options for the Athens module may be found
|
|||
## 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;
|
||||
|
|
@ -28,7 +28,7 @@ A very basic configuration for Athens that acts as a caching and forwarding HTTP
|
|||
|
||||
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;
|
||||
|
|
@ -39,7 +39,7 @@ If you want to prevent Athens from writing to disk, you can instead configure it
|
|||
|
||||
To use the local proxy in Go builds, you can set the proxy as environment variable:
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
environment.variables = {
|
||||
GOPROXY = "http://localhost:3000"
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
[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
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Enabling the `livebook` service creates a user
|
|||
[`systemd`](https://www.freedesktop.org/wiki/Software/systemd/) unit
|
||||
which runs the server.
|
||||
|
||||
```
|
||||
```nix
|
||||
{ ... }:
|
||||
|
||||
{
|
||||
|
|
@ -51,6 +51,6 @@ some features require additional packages. For example, the machine
|
|||
learning Kinos require `gcc` and `gnumake`. To add these, use
|
||||
`extraPackages`:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.livebook.extraPackages = with pkgs; [ gcc gnumake ];
|
||||
```
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ file {file}`configuration.nix` to make it contain:
|
|||
::: {.example #module-services-emacs-configuration-nix}
|
||||
### Custom Emacs in `configuration.nix`
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
environment.systemPackages = [
|
||||
# [...]
|
||||
|
|
@ -203,7 +203,7 @@ adding it to your {file}`~/.config/nixpkgs/config.nix` (see
|
|||
::: {.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; };
|
||||
|
|
@ -228,7 +228,7 @@ only use {command}`emacsclient`), you can change your file
|
|||
::: {.example #ex-emacsGtk3Nix}
|
||||
### Custom Emacs build
|
||||
|
||||
```
|
||||
```nix
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
let
|
||||
myEmacs = (pkgs.emacs.override {
|
||||
|
|
@ -262,7 +262,7 @@ with the user's login session.
|
|||
|
||||
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;
|
||||
```
|
||||
|
||||
|
|
@ -323,7 +323,7 @@ In general, {command}`systemd` user services are globally enabled
|
|||
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;
|
||||
```
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ an existing, securely configured Postfix setup, as it does not automatically con
|
|||
## 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;
|
||||
|
|
@ -50,7 +50,7 @@ necessary, but outside the scope of the Mailman module.
|
|||
## 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 = {
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ autoconfigure a new Pantalaimon instance, which will connect to the homeserver
|
|||
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;
|
||||
|
|
@ -78,7 +78,7 @@ uses across an entire homeserver.
|
|||
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; [
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ synapse server for the `example.org` domain, served from
|
|||
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}";
|
||||
|
|
@ -158,7 +158,7 @@ in an additional file like this:
|
|||
by `matrix-synapse`.
|
||||
- Include the file like this in your configuration:
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.matrix-synapse.extraConfigFiles = [
|
||||
"/run/secrets/matrix-shared-secret"
|
||||
|
|
@ -190,7 +190,7 @@ fill in the required connection details automatically when you enter your
|
|||
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;
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ unit which runs the sync server with an isolated user using the systemd
|
|||
`DynamicUser` option.
|
||||
|
||||
This can be done by enabling the `anki-sync-server` service:
|
||||
```
|
||||
```nix
|
||||
{ ... }:
|
||||
|
||||
{
|
||||
|
|
@ -27,7 +27,7 @@ This can be done by enabling the `anki-sync-server` service:
|
|||
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 = [
|
||||
{
|
||||
|
|
@ -50,7 +50,7 @@ you want to expose the sync server directly to other computers (not recommended
|
|||
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;
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ configure a webserver to proxy HTTP requests to the socket.
|
|||
|
||||
For instance, the following configuration could be used to use nginx as
|
||||
frontend proxy:
|
||||
```
|
||||
```nix
|
||||
services.nginx = {
|
||||
enable = true;
|
||||
recommendedGzipSettings = true;
|
||||
|
|
@ -35,7 +35,7 @@ The default state dir is `/var/gitlab/state`. This is where
|
|||
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";
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ This NixOS module also provides basic configuration integrating Sourcehut into l
|
|||
and `services.postgresql` services.
|
||||
|
||||
A very basic configuration may look like this:
|
||||
```
|
||||
```nix
|
||||
{ pkgs, ... }:
|
||||
let
|
||||
fqdn =
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ unit which runs the chat client in a detached
|
|||
session.
|
||||
|
||||
This can be done by enabling the `weechat` service:
|
||||
```
|
||||
```nix
|
||||
{ ... }:
|
||||
|
||||
{
|
||||
|
|
@ -30,7 +30,7 @@ allow your another user to attach to this session, the
|
|||
`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
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ for validating a server's configuration.
|
|||
|
||||
A minimal configuration looks like this:
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.goss = {
|
||||
enable = true;
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ One of the most common exporters is the
|
|||
[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;
|
||||
|
|
@ -35,7 +35,7 @@ configuration see `man configuration.nix` or search through
|
|||
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 = {
|
||||
# ...
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ example:
|
|||
`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 }:
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ example:
|
|||
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;
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ replication tool for SQLite.
|
|||
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" ];
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ The `config.exs` file can be further customized following the instructions on th
|
|||
## 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;
|
||||
|
|
@ -38,7 +38,7 @@ $ sudo -u postgres psql -f setup.psql
|
|||
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";
|
||||
|
|
@ -121,7 +121,7 @@ $ pleroma_ctl user new <nickname> <email> --admin --moderator --password <passw
|
|||
|
||||
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;
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ A good configuration to start with, including a
|
|||
[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" ];
|
||||
|
|
@ -57,7 +57,7 @@ certificate by leveraging the ACME
|
|||
|
||||
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;
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ self-arranging IPv6 network.
|
|||
### Simple ephemeral node {#module-services-networking-yggdrasil-configuration-simple}
|
||||
|
||||
An annotated example of a simple configuration:
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.yggdrasil = {
|
||||
enable = true;
|
||||
|
|
@ -39,7 +39,7 @@ An annotated example of a simple configuration:
|
|||
### 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";
|
||||
|
|
@ -90,7 +90,7 @@ in {
|
|||
|
||||
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".
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ c2FmZQ is an application that can securely encrypt, store, and share files,
|
|||
including but not limited to pictures and videos.
|
||||
|
||||
The service `c2fmzq-server` can be enabled by setting
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.c2fmzq-server.enable = true;
|
||||
}
|
||||
|
|
@ -17,7 +17,7 @@ In principle the server can be exposed directly on a public interface and there
|
|||
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;
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ modern and open source discussion platform.
|
|||
## 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";
|
||||
|
|
@ -34,7 +34,7 @@ the [](#opt-services.discourse.sslCertificate)
|
|||
and [](#opt-services.discourse.sslCertificateKey)
|
||||
options:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.discourse = {
|
||||
enable = true;
|
||||
hostname = "discourse.example.com";
|
||||
|
|
@ -80,7 +80,7 @@ A basic setup which assumes you want to use your configured
|
|||
[hostname](#opt-services.discourse.hostname) as
|
||||
email domain can be done like this:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.discourse = {
|
||||
enable = true;
|
||||
hostname = "discourse.example.com";
|
||||
|
|
@ -162,7 +162,7 @@ The following example sets the title and description of the
|
|||
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";
|
||||
|
|
@ -253,7 +253,7 @@ and [discourse-solved](https://github.com/discourse/discourse-solved)
|
|||
plugins, and disable `discourse-spoiler-alert`
|
||||
by default:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.discourse = {
|
||||
enable = true;
|
||||
hostname = "discourse.example.com";
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
## Basic usage {#module-services-grocy-basic-usage}
|
||||
|
||||
A very basic configuration may look like this:
|
||||
```
|
||||
```nix
|
||||
{ pkgs, ... }:
|
||||
{
|
||||
services.grocy = {
|
||||
|
|
@ -29,7 +29,7 @@ of the application.
|
|||
|
||||
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 = {
|
||||
|
|
@ -56,7 +56,7 @@ By default, the following settings can be defined in the NixOS-configuration:
|
|||
|
||||
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 ''
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ private, self-hosted video conferencing solution.
|
|||
## 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;
|
||||
|
|
@ -22,7 +22,7 @@ A minimal configuration using Let's Encrypt for TLS certificates looks like this
|
|||
## Configuration {#module-services-jitsi-configuration}
|
||||
|
||||
Here is the minimal configuration with additional configurations:
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.jitsi-meet = {
|
||||
enable = true;
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ should be set to. See the description of
|
|||
## Example configuration {#module-services-keycloak-example-config}
|
||||
|
||||
A basic configuration with some custom settings could look like this:
|
||||
```
|
||||
```nix
|
||||
services.keycloak = {
|
||||
enable = true;
|
||||
settings = {
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ to `true`, Nextcloud will automatically be configured to connect to it through
|
|||
socket.
|
||||
|
||||
A very basic configuration may look like this:
|
||||
```
|
||||
```nix
|
||||
{ pkgs, ... }:
|
||||
{
|
||||
services.nextcloud = {
|
||||
|
|
@ -130,7 +130,7 @@ settings `listen.owner` & `listen.group` in the
|
|||
[corresponding `phpfpm` pool](#opt-services.phpfpm.pools).
|
||||
|
||||
An exemplary configuration may look like this:
|
||||
```
|
||||
```nix
|
||||
{ config, lib, pkgs, ... }: {
|
||||
services.nginx.enable = false;
|
||||
services.nextcloud = {
|
||||
|
|
@ -205,7 +205,7 @@ If major-releases will be abandoned by upstream, we should check first if those
|
|||
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 {
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ $ openssl rand -base64 64
|
|||
```
|
||||
|
||||
After that, `plausible` can be deployed like this:
|
||||
```
|
||||
```nix
|
||||
{
|
||||
services.plausible = {
|
||||
enable = true;
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ If major-releases will be abandoned by upstream, we should check first if those
|
|||
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 {
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ All of the core apps, optional apps, games, and core developer tools from GNOME
|
|||
|
||||
To enable the GNOME desktop use:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.xserver.desktopManager.gnome.enable = true;
|
||||
services.xserver.displayManager.gdm.enable = true;
|
||||
```
|
||||
|
|
@ -23,7 +23,7 @@ The default applications used in NixOS are very minimal, inspired by the default
|
|||
|
||||
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;
|
||||
```
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ Note that this mechanism can only exclude core utilities, games and core develop
|
|||
|
||||
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;
|
||||
```
|
||||
|
|
@ -48,7 +48,7 @@ Note, however, that doing so is not supported and might break some applications.
|
|||
|
||||
You can install all of the GNOME games with:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.gnome.games.enable = true;
|
||||
```
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ services.gnome.games.enable = true;
|
|||
|
||||
You can install GNOME core developer tools with:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.gnome.core-developer-tools.enable = true;
|
||||
```
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ 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;
|
||||
```
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ It is also possible to create custom sessions that replace Metacity with a diffe
|
|||
|
||||
The following example uses `xmonad` window manager:
|
||||
|
||||
```
|
||||
```nix
|
||||
services.xserver.desktopManager.gnome.flashback.customSessions = [
|
||||
{
|
||||
wmName = "xmonad";
|
||||
|
|
@ -104,7 +104,7 @@ Some packages that include Shell extensions, like `gnome.gpaste`, don’t have t
|
|||
|
||||
You can install them like any other package:
|
||||
|
||||
```
|
||||
```nix
|
||||
environment.systemPackages = [
|
||||
gnomeExtensions.dash-to-dock
|
||||
gnomeExtensions.gsconnect
|
||||
|
|
@ -136,7 +136,7 @@ You can use `dconf-editor` tool to explore which GSettings you can set.
|
|||
|
||||
### Example {#sec-gnome-gsettings-overrides-example}
|
||||
|
||||
```
|
||||
```nix
|
||||
services.xserver.desktopManager.gnome = {
|
||||
extraGSettingsOverrides = ''
|
||||
# Change default background
|
||||
|
|
|
|||
|
|
@ -5,16 +5,16 @@ Pantheon is the desktop environment created for the elementary OS distribution.
|
|||
## 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`).
|
||||
|
|
@ -29,7 +29,7 @@ Wingpanel and Switchboard work differently than they do in other distributions,
|
|||
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
|
||||
|
|
@ -43,7 +43,7 @@ switchboard-with-plugs.override {
|
|||
};
|
||||
```
|
||||
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;
|
||||
|
|
|
|||
|
|
@ -39,12 +39,12 @@ For more complete documentation on how to generate a secret with clevis, see the
|
|||
|
||||
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;
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -564,7 +564,7 @@ We use jbidwatcher as an example for a discontinued project here.
|
|||
|
||||
For example in this case:
|
||||
|
||||
```
|
||||
```nix
|
||||
jbidwatcher = throw "jbidwatcher was discontinued in march 2021"; # added 2021-03-15
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ After that you can commit and submit the changes.
|
|||
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;
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ After that you can commit and submit the changes.
|
|||
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; [
|
||||
|
|
|
|||
Loading…
Reference in New Issue