diff --git a/nixos/doc/manual/configuration/linux-kernel.xml b/nixos/doc/manual/configuration/linux-kernel.xml
index 2f766f2b32f777..644d3a33ffd2c8 100644
--- a/nixos/doc/manual/configuration/linux-kernel.xml
+++ b/nixos/doc/manual/configuration/linux-kernel.xml
@@ -84,18 +84,17 @@ nixpkgs.config.packageOverrides = pkgs:
allowImportFromDerivation = true;
};
]]>
-
-You can edit the config with this snippet (by default make menuconfig won't work
- out of the box on nixos):
- make
+ menuconfig won't work out of the box on nixos):
+ {}; kernelToOverride.overrideAttrs (o: {nativeBuildInputs=o.nativeBuildInputs ++ [ pkgconfig ncurses ];})'
]]>
-
-
- or you can let nixpkgs generate the configuration.
- Nixpkgs generates it via answering the interactive kernel utility make config.
- The answers depend on parameters passed to pkgs/os-specific/linux/kernel/generic.nix
- (which you can influence by overriding extraConfig, autoModules, modDirVersion, preferBuiltin, extraConfig).
+ or you can let nixpkgs generate the configuration. Nixpkgs generates it via
+ answering the interactive kernel utility make config. The
+ answers depend on parameters passed to
+ pkgs/os-specific/linux/kernel/generic.nix (which you
+ can influence by overriding extraConfig, autoModules,
+ modDirVersion, preferBuiltin, extraConfig).
- You may need to find the correct path, replacing /tmp, * or machine.
+ You may need to find the correct path, replacing /tmp,
+ * or machine.
- Press "enter" to open up console and login as "root". After you're done, press "ctrl-q" to exit the console.
+ Press "enter" to open up console and login as "root". After you're done,
+ press "ctrl-q" to exit the console.
-
diff --git a/nixos/doc/manual/installation/installing-behind-a-proxy.xml b/nixos/doc/manual/installation/installing-behind-a-proxy.xml
index c59d073c61c73a..8f9baff44b51e3 100644
--- a/nixos/doc/manual/installation/installing-behind-a-proxy.xml
+++ b/nixos/doc/manual/installation/installing-behind-a-proxy.xml
@@ -5,28 +5,29 @@
xml:id="sec-installing-behind-proxy">
Installing behind a proxy
-
+
To install NixOS behind a proxy, do the following before running
nixos-install.
-
-
+
+
+
-
- Update proxy configuration in
- /mnt/etc/nixos/configuration.nix to keep the
- internet accessible after reboot.
-
-
+
+ Update proxy configuration in
+ /mnt/etc/nixos/configuration.nix to keep the internet
+ accessible after reboot.
+
+
networking.proxy.default = "http://user:password@proxy:port/";
networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";
-
- Setup the proxy environment variables in the shell where you are
- running nixos-install.
-
-
+
+ Setup the proxy environment variables in the shell where you are running
+ nixos-install.
+
+
# proxy_url="http://user:password@proxy:port/"
# export http_proxy="$proxy_url"
# export HTTP_PROXY="$proxy_url"
@@ -34,14 +35,14 @@ networking.proxy.noProxy = "127.0.0.1,localhost,internal.domain";
# export HTTPS_PROXY="$proxy_url"
-
+
-
-
- If you are switching networks with different proxy configurations, use the
- nesting.clone option in
- configuration.nix to switch proxies at runtime.
- Refer to for more information.
-
-
+
+
+ If you are switching networks with different proxy configurations, use the
+ nesting.clone option in
+ configuration.nix to switch proxies at runtime. Refer to
+ for more information.
+
+
diff --git a/nixos/doc/manual/installation/installing.xml b/nixos/doc/manual/installation/installing.xml
index 916384559e24b6..1366e8f9359602 100644
--- a/nixos/doc/manual/installation/installing.xml
+++ b/nixos/doc/manual/installation/installing.xml
@@ -327,8 +327,8 @@ Retype new UNIX password: ***
For unattended installations, it is possible to use
- nixos-install --no-root-passwd
- in order to disable the password prompt entirely.
+ nixos-install --no-root-passwd in order to disable the
+ password prompt entirely.
diff --git a/nixos/doc/manual/manual.xml b/nixos/doc/manual/manual.xml
index a5efde32885cf4..12f52e1997c8d2 100644
--- a/nixos/doc/manual/manual.xml
+++ b/nixos/doc/manual/manual.xml
@@ -17,8 +17,8 @@
If you encounter problems, please report them on the
Discourse
- or on the Discourse or
+ on the
#nixos channel on Freenode. Bugs should be
reported in
diff --git a/nixos/doc/manual/release-notes/rl-1509.xml b/nixos/doc/manual/release-notes/rl-1509.xml
index 4eb2f9aa0a9568..e500c9d6342242 100644
--- a/nixos/doc/manual/release-notes/rl-1509.xml
+++ b/nixos/doc/manual/release-notes/rl-1509.xml
@@ -435,11 +435,11 @@ system.autoUpgrade.enable = true;
system.stateVersion = "14.12";
- The new option ensures that
- certain configuration changes that could break existing systems (such as
- the sshd host key setting) will maintain compatibility
- with the specified NixOS release. NixOps sets the state version of
- existing deployments automatically.
+ The new option ensures that certain
+ configuration changes that could break existing systems (such as the
+ sshd host key setting) will maintain compatibility with
+ the specified NixOS release. NixOps sets the state version of existing
+ deployments automatically.
diff --git a/nixos/doc/manual/release-notes/rl-1809.xml b/nixos/doc/manual/release-notes/rl-1809.xml
index 5a565f08b2cb14..f0797b51340d3e 100644
--- a/nixos/doc/manual/release-notes/rl-1809.xml
+++ b/nixos/doc/manual/release-notes/rl-1809.xml
@@ -19,13 +19,13 @@
-
- Support for wrapping binaries using firejail has been
- added through programs.firejail.wrappedBinaries.
-
-
- For example
-
+
+ Support for wrapping binaries using firejail has been
+ added through programs.firejail.wrappedBinaries.
+
+
+ For example
+
programs.firejail = {
enable = true;
@@ -35,9 +35,10 @@ programs.firejail = {
};
};
-
- This will place firefox and mpv binaries in the global path wrapped by firejail.
-
+
+ This will place firefox and mpv
+ binaries in the global path wrapped by firejail.
+
@@ -75,16 +76,20 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
- The services.cassandra module has been reworked and
- was rewritten from scratch. The service has succeeding tests for
- the versions 2.1, 2.2, 3.0 and 3.11 of Apache Cassandra.
+ The services.cassandra module has been reworked and was
+ rewritten from scratch. The service has succeeding tests for the versions
+ 2.1, 2.2, 3.0 and 3.11 of
+ Apache
+ Cassandra.
- There is a new services.foundationdb module for deploying
- FoundationDB clusters.
+ There is a new services.foundationdb module for
+ deploying
+ FoundationDB
+ clusters.
@@ -97,24 +102,26 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
- services.strongswan-swanctl
- is a modern replacement for services.strongswan.
- You can use either one of them to setup IPsec VPNs but not both at the same time.
+ services.strongswan-swanctl is a modern replacement for
+ services.strongswan. You can use either one of them to
+ setup IPsec VPNs but not both at the same time.
- services.strongswan-swanctl uses the
- swanctl
- command which uses the modern
- vici
- Versatile IKE Configuration Interface.
- The deprecated ipsec command used in services.strongswan is using the legacy
- stroke configuration interface.
+ services.strongswan-swanctl uses the
+ swanctl
+ command which uses the modern
+ vici
+ Versatile IKE Configuration Interface. The deprecated
+ ipsec command used in
+ services.strongswan is using the legacy
+ stroke
+ configuration interface.
- The new services.elasticsearch-curator service
- periodically curates or manages, your Elasticsearch indices and snapshots.
+ The new services.elasticsearch-curator service
+ periodically curates or manages, your Elasticsearch indices and snapshots.
@@ -135,8 +142,8 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
- The deprecated services.cassandra module has
- seen a complete rewrite. (See above.)
+ The deprecated services.cassandra module has seen a
+ complete rewrite. (See above.)
@@ -186,41 +193,44 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
- services.munge now runs as user (and group) munge instead of root.
- Make sure the key file is accessible to the daemon.
+ services.munge now runs as user (and group)
+ munge instead of root. Make sure the key file is
+ accessible to the daemon.
- dockerTools.buildImage now uses null as default value for tag,
- which indicates that the nix output hash will be used as tag.
+ dockerTools.buildImage now uses null
+ as default value for tag, which indicates that the nix
+ output hash will be used as tag.
- The ELK stack: elasticsearch, logstash and kibana
- has been upgraded from 2.* to 6.3.*.
- The 2.* versions have been unsupported since last year
- so they have been removed. You can still use the 5.* versions under the names
- elasticsearch5, logstash5 and
- kibana5.
+ The ELK stack: elasticsearch,
+ logstash and kibana has been
+ upgraded from 2.* to 6.3.*. The 2.* versions have been
+ unsupported since
+ last year so they have been removed. You can still use the 5.*
+ versions under the names elasticsearch5,
+ logstash5 and kibana5.
- The elastic beats:
- filebeat, heartbeat,
- metricbeat and packetbeat
- have had the same treatment: they now target 6.3.* as well.
- The 5.* versions are available under the names:
+ The elastic beats: filebeat,
+ heartbeat, metricbeat and
+ packetbeat have had the same treatment: they now target
+ 6.3.* as well. The 5.* versions are available under the names:
filebeat5, heartbeat5,
metricbeat5 and packetbeat5
The ELK-6.3 stack now comes with
- X-Pack by default.
- Since X-Pack is licensed under the
- Elastic License
- the ELK packages now have an unfree license. To use them you need to specify
- allowUnfree = true; in your nixpkgs configuration.
+ X-Pack by
+ default. Since X-Pack is licensed under the
+ Elastic
+ License the ELK packages now have an unfree license. To use them
+ you need to specify allowUnfree = true; in your nixpkgs
+ configuration.
Fortunately there is also a free variant of the ELK stack without X-Pack.
@@ -231,20 +241,23 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
- Options
- boot.initrd.luks.devices.name.yubikey.ramfsMountPoint
- boot.initrd.luks.devices.name.yubikey.storage.mountPoint
- were removed. luksroot.nix module never supported more than one YubiKey at
- a time anyway, hence those options never had any effect. You should be able to remove them
- from your config without any issues.
+ Options
+ boot.initrd.luks.devices.name.yubikey.ramfsMountPoint
+ boot.initrd.luks.devices.name.yubikey.storage.mountPoint
+ were removed. luksroot.nix module never supported more
+ than one YubiKey at a time anyway, hence those options never had any
+ effect. You should be able to remove them from your config without any
+ issues.
- stdenv.system and system in nixpkgs now refer to the host platform instead of the build platform.
- For native builds this is not change, let alone a breaking one.
- For cross builds, it is a breaking change, and stdenv.buildPlatform.system can be used instead for the old behavior.
- They should be using that anyways for clarity.
+ stdenv.system and system in nixpkgs
+ now refer to the host platform instead of the build platform. For native
+ builds this is not change, let alone a breaking one. For cross builds, it
+ is a breaking change, and stdenv.buildPlatform.system
+ can be used instead for the old behavior. They should be using that
+ anyways for clarity.
@@ -298,26 +311,33 @@ $ nix-instantiate -E '(import <nixpkgsunstable> {}).gitFull'
- The pkgs argument to NixOS modules can now be set directly using nixpkgs.pkgs. Previously, only the system, config and overlays arguments could be used to influence pkgs.
+ The pkgs argument to NixOS modules can now be set
+ directly using nixpkgs.pkgs. Previously, only the
+ system, config and
+ overlays arguments could be used to influence
+ pkgs.
- A NixOS system can now be constructed more easily based on a preexisting invocation of Nixpkgs. For example:
-
+ A NixOS system can now be constructed more easily based on a preexisting
+ invocation of Nixpkgs. For example:
+
inherit (pkgs.nixos {
boot.loader.grub.enable = false;
fileSystems."/".device = "/dev/xvda1";
}) toplevel kernel initialRamdisk manual;
-
- This benefits evaluation performance, lets you write Nixpkgs packages that depend on NixOS images and is consistent with a deployment architecture that would be centered around Nixpkgs overlays.
+ This benefits evaluation performance, lets you write Nixpkgs packages that
+ depend on NixOS images and is consistent with a deployment architecture
+ that would be centered around Nixpkgs overlays.
- lib.traceValIfNot has been deprecated. Use
- if/then/else and lib.traceValSeq instead.
+ lib.traceValIfNot has been deprecated. Use
+ if/then/else and lib.traceValSeq
+ instead.
@@ -336,9 +356,9 @@ inherit (pkgs.nixos {
- lib.recursiveUpdateUntil was not acting according to its
- specification. It has been fixed to act according to the docstring, and a
- test has been added.
+ lib.recursiveUpdateUntil was not acting according to
+ its specification. It has been fixed to act according to the docstring,
+ and a test has been added.
@@ -408,11 +428,11 @@ inherit (pkgs.nixos {
-
- The Kubernetes package has been bumped to major version 1.11.
- Please consult the
- release notes
- for details on new features and api changes.
+
+ The Kubernetes package has been bumped to major version 1.11. Please
+ consult the
+ release
+ notes for details on new features and api changes.
@@ -432,8 +452,8 @@ inherit (pkgs.nixos {
- The option services.kubernetes.apiserver.address
- was renamed to services.kubernetes.apiserver.bindAddress.
+ The option services.kubernetes.apiserver.address was
+ renamed to services.kubernetes.apiserver.bindAddress.
Note that the default value has changed from 127.0.0.1 to 0.0.0.0.
@@ -445,76 +465,86 @@ inherit (pkgs.nixos {
- The option services.kubernetes.addons.dashboard.enableRBAC
- was renamed to services.kubernetes.addons.dashboard.rbac.enable.
+ The option
+ services.kubernetes.addons.dashboard.enableRBAC was
+ renamed to
+ services.kubernetes.addons.dashboard.rbac.enable.
The Kubernetes Dashboard now has only minimal RBAC permissions by default.
- If dashboard cluster-admin rights are desired,
- set services.kubernetes.addons.dashboard.rbac.clusterAdmin to true.
- On existing clusters, in order for the revocation of privileges to take effect,
- the current ClusterRoleBinding for kubernetes-dashboard must be manually removed:
- kubectl delete clusterrolebinding kubernetes-dashboard
+ If dashboard cluster-admin rights are desired, set
+ services.kubernetes.addons.dashboard.rbac.clusterAdmin
+ to true. On existing clusters, in order for the revocation of privileges
+ to take effect, the current ClusterRoleBinding for kubernetes-dashboard
+ must be manually removed: kubectl delete clusterrolebinding
+ kubernetes-dashboard
The programs.screen module provides allows to configure
- /etc/screenrc, however the module behaved fairly counterintuitive as
- the config exists, but the package wasn't available. Since 18.09 pkgs.screen
- will be added to environment.systemPackages.
+ /etc/screenrc, however the module behaved fairly
+ counterintuitive as the config exists, but the package wasn't available.
+ Since 18.09 pkgs.screen will be added to
+ environment.systemPackages.
- The module now uses WPA2 by default.
+ The module now uses WPA2 by
+ default.
- s6Dns, s6Networking,
- s6LinuxUtils and s6PortableUtils
- renamed to
- s6-dns, s6-networking,
- s6-linux-utils and s6-portable-utils respectively.
+ s6Dns, s6Networking,
+ s6LinuxUtils and s6PortableUtils
+ renamed to s6-dns, s6-networking,
+ s6-linux-utils and s6-portable-utils
+ respectively.
-
-
+
+
- The module option is now defaulted to true.
+ The module option is now defaulted to
+ true.
-
-
+
+
- The config activation script of nixos-rebuild now
- reloads
- all user units for each authenticated user.
+ The config activation script of nixos-rebuild now
+ reloads
+ all user units for each authenticated user.
-
-
+
+
- The default display manager is now LightDM.
- To use SLiM set services.xserver.displayManager.slim.enable
- to true.
+ The default display manager is now LightDM. To use SLiM set
+ services.xserver.displayManager.slim.enable to
+ true.
-
-
+
+
- NixOS option descriptions are now automatically broken up into individual
- paragraphs if the text contains two consecutive newlines, so it's no
- longer necessary to use </para><para> to start
- a new paragraph.
+ NixOS option descriptions are now automatically broken up into individual
+ paragraphs if the text contains two consecutive newlines, so it's no
+ longer necessary to use </para><para> to start a
+ new paragraph.
-
-
+
+
- Top-level buildPlatform, hostPlatform, and targetPlatform in Nixpkgs are deprecated.
- Please use their equivalents in stdenv instead:
- stdenv.buildPlatform, stdenv.hostPlatform, and stdenv.targetPlatform.
+ Top-level buildPlatform,
+ hostPlatform, and targetPlatform in
+ Nixpkgs are deprecated. Please use their equivalents in
+ stdenv instead:
+ stdenv.buildPlatform,
+ stdenv.hostPlatform, and
+ stdenv.targetPlatform.
-
+
diff --git a/nixos/modules/i18n/input-method/default.xml b/nixos/modules/i18n/input-method/default.xml
index ab918a9fb23e3f..117482fb0d57d9 100644
--- a/nixos/modules/i18n/input-method/default.xml
+++ b/nixos/modules/i18n/input-method/default.xml
@@ -3,32 +3,50 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-services-input-methods">
-
-Input Methods
-
-Input methods are an operating system component that allows any data, such
- as keyboard strokes or mouse movements, to be received as input. In this way
- users can enter characters and symbols not found on their input devices. Using
- an input method is obligatory for any language that has more graphemes than
- there are keys on the keyboard.
-
-The following input methods are available in NixOS:
-
-
- IBus: The intelligent input bus.
- Fcitx: A customizable lightweight input
- method.
- Nabi: A Korean input method based on XIM.
- Uim: The universal input method, is a library with a XIM
- bridge.
-
-
-IBus
-
-IBus is an Intelligent Input Bus. It provides full featured and user
- friendly input method user interface.
-
-The following snippet can be used to configure IBus:
+ Input Methods
+
+ Input methods are an operating system component that allows any data, such as
+ keyboard strokes or mouse movements, to be received as input. In this way
+ users can enter characters and symbols not found on their input devices.
+ Using an input method is obligatory for any language that has more graphemes
+ than there are keys on the keyboard.
+
+
+ The following input methods are available in NixOS:
+
+
+
+
+ IBus: The intelligent input bus.
+
+
+
+
+ Fcitx: A customizable lightweight input method.
+
+
+
+
+ Nabi: A Korean input method based on XIM.
+
+
+
+
+ Uim: The universal input method, is a library with a XIM bridge.
+
+
+
+
+ IBus
+
+
+ IBus is an Intelligent Input Bus. It provides full featured and user
+ friendly input method user interface.
+
+
+
+ The following snippet can be used to configure IBus:
+
i18n.inputMethod = {
@@ -37,57 +55,89 @@ i18n.inputMethod = {
};
-i18n.inputMethod.ibus.engines is optional and can be
- used to add extra IBus engines.
-
-Available extra IBus engines are:
-
-
- Anthy (ibus-engines.anthy): Anthy is a
- system for Japanese input method. It converts Hiragana text to Kana Kanji
- mixed text.
- Hangul (ibus-engines.hangul): Korean input
- method.
- m17n (ibus-engines.m17n): m17n is an input
- method that uses input methods and corresponding icons in the m17n
- database.
- mozc (ibus-engines.mozc): A Japanese input
- method from Google.
- Table (ibus-engines.table): An input method
- that load tables of input methods.
- table-others (ibus-engines.table-others):
- Various table-based input methods. To use this, and any other table-based
- input methods, it must appear in the list of engines along with
- table. For example:
+
+ i18n.inputMethod.ibus.engines is optional and can be used
+ to add extra IBus engines.
+
+
+
+ Available extra IBus engines are:
+
+
+
+
+
+ Anthy (ibus-engines.anthy): Anthy is a system for
+ Japanese input method. It converts Hiragana text to Kana Kanji mixed text.
+
+
+
+
+ Hangul (ibus-engines.hangul): Korean input method.
+
+
+
+
+ m17n (ibus-engines.m17n): m17n is an input method that
+ uses input methods and corresponding icons in the m17n database.
+
+
+
+
+ mozc (ibus-engines.mozc): A Japanese input method from
+ Google.
+
+
+
+
+ Table (ibus-engines.table): An input method that load
+ tables of input methods.
+
+
+
+
+ table-others (ibus-engines.table-others): Various
+ table-based input methods. To use this, and any other table-based input
+ methods, it must appear in the list of engines along with
+ table. For example:
ibus.engines = with pkgs.ibus-engines; [ table table-others ];
-
-
-
-To use any input method, the package must be added in the configuration,
- as shown above, and also (after running nixos-rebuild) the
- input method must be added from IBus' preference dialog.
-
-
- Troubleshooting
- If IBus works in some applications but not others, a likely cause of
- this is that IBus is depending on a different version of
- glib to what the applications are depending on. This can
- be checked by running nix-store -q --requisites <path> | grep
- glib, where <path> is the path of either
- IBus or an application in the Nix store. The glib
- packages must match exactly. If they do not, uninstalling and reinstalling
- the application is a likely fix.
-
-
-
-Fcitx
-
-Fcitx is an input method framework with extension support. It has three
- built-in Input Method Engine, Pinyin, QuWei and Table-based input
- methods.
-The following snippet can be used to configure Fcitx:
+
+
+
+
+
+ To use any input method, the package must be added in the configuration, as
+ shown above, and also (after running nixos-rebuild) the
+ input method must be added from IBus' preference dialog.
+
+
+
+ Troubleshooting
+
+ If IBus works in some applications but not others, a likely cause of this
+ is that IBus is depending on a different version of glib
+ to what the applications are depending on. This can be checked by running
+ nix-store -q --requisites <path> | grep glib,
+ where <path> is the path of either IBus or an
+ application in the Nix store. The glib packages must
+ match exactly. If they do not, uninstalling and reinstalling the
+ application is a likely fix.
+
+
+
+
+ Fcitx
+
+
+ Fcitx is an input method framework with extension support. It has three
+ built-in Input Method Engine, Pinyin, QuWei and Table-based input methods.
+
+
+
+ The following snippet can be used to configure Fcitx:
+
i18n.inputMethod = {
@@ -96,51 +146,89 @@ i18n.inputMethod = {
};
-i18n.inputMethod.fcitx.engines is optional and can be
- used to add extra Fcitx engines.
-
-Available extra Fcitx engines are:
-
-
- Anthy (fcitx-engines.anthy): Anthy is a
- system for Japanese input method. It converts Hiragana text to Kana Kanji
- mixed text.
- Chewing (fcitx-engines.chewing): Chewing is
- an intelligent Zhuyin input method. It is one of the most popular input
- methods among Traditional Chinese Unix users.
- Hangul (fcitx-engines.hangul): Korean input
- method.
- Unikey (fcitx-engines.unikey): Vietnamese input
- method.
- m17n (fcitx-engines.m17n): m17n is an input
- method that uses input methods and corresponding icons in the m17n
- database.
- mozc (fcitx-engines.mozc): A Japanese input
- method from Google.
- table-others (fcitx-engines.table-others):
- Various table-based input methods.
-
-
-
-Nabi
-
-Nabi is an easy to use Korean X input method. It allows you to enter
- phonetic Korean characters (hangul) and pictographic Korean characters
- (hanja).
-The following snippet can be used to configure Nabi:
+
+ i18n.inputMethod.fcitx.engines is optional and can be
+ used to add extra Fcitx engines.
+
+
+
+ Available extra Fcitx engines are:
+
+
+
+
+
+ Anthy (fcitx-engines.anthy): Anthy is a system for
+ Japanese input method. It converts Hiragana text to Kana Kanji mixed text.
+
+
+
+
+ Chewing (fcitx-engines.chewing): Chewing is an
+ intelligent Zhuyin input method. It is one of the most popular input
+ methods among Traditional Chinese Unix users.
+
+
+
+
+ Hangul (fcitx-engines.hangul): Korean input method.
+
+
+
+
+ Unikey (fcitx-engines.unikey): Vietnamese input method.
+
+
+
+
+ m17n (fcitx-engines.m17n): m17n is an input method that
+ uses input methods and corresponding icons in the m17n database.
+
+
+
+
+ mozc (fcitx-engines.mozc): A Japanese input method from
+ Google.
+
+
+
+
+ table-others (fcitx-engines.table-others): Various
+ table-based input methods.
+
+
+
+
+
+ Nabi
+
+
+ Nabi is an easy to use Korean X input method. It allows you to enter
+ phonetic Korean characters (hangul) and pictographic Korean characters
+ (hanja).
+
+
+
+ The following snippet can be used to configure Nabi:
+
i18n.inputMethod = {
enabled = "nabi";
};
-
+
+
+ Uim
-Uim
+
+ Uim (short for "universal input method") is a multilingual input method
+ framework. Applications can use it through so-called bridges.
+
-Uim (short for "universal input method") is a multilingual input method
- framework. Applications can use it through so-called bridges.
-The following snippet can be used to configure uim:
+
+ The following snippet can be used to configure uim:
+
i18n.inputMethod = {
@@ -148,8 +236,9 @@ i18n.inputMethod = {
};
-Note: The option can be
- used to choose uim toolbar.
-
-
+
+ Note: The option can be
+ used to choose uim toolbar.
+
+
diff --git a/nixos/modules/programs/digitalbitbox/doc.xml b/nixos/modules/programs/digitalbitbox/doc.xml
index a26653dda535fd..c63201628dbd7b 100644
--- a/nixos/modules/programs/digitalbitbox/doc.xml
+++ b/nixos/modules/programs/digitalbitbox/doc.xml
@@ -3,75 +3,64 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-programs-digitalbitbox">
-
- Digital Bitbox
-
-
- 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
-
+ Digital Bitbox
+
+ 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
= true;
-
- and bundles the digitalbitbox package (see digitalbitbox package (see
+ ), which contains the
- dbb-app and dbb-cli binaries,
- along with the hardware module (see dbb-app and dbb-cli binaries, along
+ with the hardware module (see
+ ) which sets up the
- necessary udev rules to access the device.
-
-
-
- Enabling the digitalbitbox module is pretty much the easiest way to
- get a Digital Bitbox device working on your system.
-
+ necessary udev rules to access the device.
+
+
+ Enabling the digitalbitbox module is pretty much the easiest way to get a
+ Digital Bitbox device working on your system.
+
+
+ For more information, see
+ .
+
+
+ Package
- For more information, see
- .
-
-
-
- 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:
-
+ 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:
= [
pkgs.digitalbitbox
];
-
-
-
-
-
- Hardware
-
-
- The digitalbitbox hardware package enables the udev rules for
- Digital Bitbox devices and may be installed as follows:
+
+
+
+ Hardware
+
+ The digitalbitbox hardware package enables the udev rules for Digital Bitbox
+ devices and may be installed as follows:
= 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:
+
+
+ In order to alter the udev rules, one may provide different values for the
+ udevRule51 and udevRule52 attributes
+ by means of overriding as follows:
programs.digitalbitbox = {
enable = true;
@@ -80,6 +69,6 @@ programs.digitalbitbox = {
};
};
-
-
+
+
diff --git a/nixos/modules/programs/plotinus.xml b/nixos/modules/programs/plotinus.xml
index 91740ee16ec2f5..902cd89e0c4927 100644
--- a/nixos/modules/programs/plotinus.xml
+++ b/nixos/modules/programs/plotinus.xml
@@ -3,23 +3,28 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-program-plotinus">
-
-Plotinus
-
-Source:modules/programs/plotinus.nix
-
-Upstream documentation:
-
-Plotinus is a searchable command palette in every modern GTK+ application.
-
-When in a GTK+3 application and Plotinus is enabled, you can press Ctrl+Shift+P to open the command palette. The command palette provides a searchable list of of all menu items in the application.
-
-To enable Plotinus, add the following to your configuration.nix:
-
+ Plotinus
+
+ Source:
+ modules/programs/plotinus.nix
+
+
+ Upstream documentation:
+
+
+
+ Plotinus is a searchable command palette in every modern GTK+ application.
+
+
+ When in a GTK+3 application and Plotinus is enabled, you can press
+ Ctrl+Shift+P to open the command palette. The command
+ palette provides a searchable list of of all menu items in the application.
+
+
+ To enable Plotinus, add the following to your
+ configuration.nix:
= true;
-
-
-
+
diff --git a/nixos/modules/programs/zsh/oh-my-zsh.xml b/nixos/modules/programs/zsh/oh-my-zsh.xml
index 6567d4a42facd6..5cf690c1a5606f 100644
--- a/nixos/modules/programs/zsh/oh-my-zsh.xml
+++ b/nixos/modules/programs/zsh/oh-my-zsh.xml
@@ -3,18 +3,20 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-programs-zsh-ohmyzsh">
-
-Oh my ZSH
-
-oh-my-zsh is a framework
-to manage your ZSH configuration
-including completion scripts for several CLI tools or custom prompt themes.
-
-Basic usage
-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.
-
+ Oh my ZSH
+
+ oh-my-zsh is a
+ framework to manage your ZSH
+ configuration including completion scripts for several CLI tools or custom
+ prompt themes.
+
+
+ Basic usage
+
+
+ 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.
{
programs.ohMyZsh = {
@@ -24,39 +26,50 @@ of oh-my-zsh.
};
}
-
-For a detailed explanation of these arguments please refer to the
-oh-my-zsh docs.
-
-The expression generates the needed
-configuration and writes it into your /etc/zshrc.
-
-
-Custom additions
-
-Sometimes third-party or custom scripts such as a modified theme may be needed.
-oh-my-zsh provides the
-ZSH_CUSTOM
-environment variable for this which points to a directory with additional scripts.
-
-The module can do this as well:
-
+ For a detailed explanation of these arguments please refer to the
+ oh-my-zsh
+ docs.
+
+
+
+ The expression generates the needed configuration and writes it into your
+ /etc/zshrc.
+
+
+
+ Custom additions
+
+
+ Sometimes third-party or custom scripts such as a modified theme may be
+ needed. oh-my-zsh provides the
+ ZSH_CUSTOM
+ environment variable for this which points to a directory with additional
+ scripts.
+
+
+
+ The module can do this as well:
{
programs.ohMyZsh.custom = "~/path/to/custom/scripts";
}
-
-
-Custom environments
-
-There are several extensions for oh-my-zsh packaged in nixpkgs.
-One of them is nix-zsh-completions
-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:
-
+
+
+
+ Custom environments
+
+
+ There are several extensions for oh-my-zsh packaged in
+ nixpkgs. One of them is
+ nix-zsh-completions
+ 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:
{ pkgs, ... }:
{
@@ -66,42 +79,59 @@ generate this path from a list of Nix packages:
];
}
-
-Internally a single store path will be created using buildEnv.
-Please refer to the docs of
-buildEnv
-for further reference.
-
-Please keep in mind that this is not compatible with programs.ohMyZsh.custom
-as it requires an immutable store path while custom shall remain mutable! An evaluation failure
-will be thrown if both custom and customPkgs are set.
-
-
-Package your own customizations
-
-If third-party customizations (e.g. new themes) are supposed to be added to oh-my-zsh
-there are several pitfalls to keep in mind:
-
-
-
- To comply with the default structure of ZSH the entire output needs to be written to
- $out/share/zsh.
-
-
- Completion scripts are supposed to be stored at $out/share/zsh/site-functions. This directory
- is part of the fpath
- and the package should be compatible with pure ZSH setups. The module will automatically link
- the contents of site-functions to completions directory in the proper store path.
-
-
- The plugins directory needs the structure pluginname/pluginname.plugin.zsh
- as structured in the upstream repo.
+ Internally a single store path will be created using
+ buildEnv. Please refer to the docs of
+ buildEnv
+ for further reference.
+
+
+
+ Please keep in mind that this is not compatible with
+ programs.ohMyZsh.custom as it requires an immutable store
+ path while custom shall remain mutable! An evaluation
+ failure will be thrown if both custom and
+ customPkgs are set.
+
+
+
+ Package your own customizations
+
+
+ If third-party customizations (e.g. new themes) are supposed to be added to
+ oh-my-zsh there are several pitfalls to keep in mind:
+
+
+
+
+
+ To comply with the default structure of ZSH the entire
+ output needs to be written to $out/share/zsh.
+
+
+
+
+ Completion scripts are supposed to be stored at
+ $out/share/zsh/site-functions. This directory is part
+ of the
+ fpath
+ and the package should be compatible with pure ZSH
+ setups. The module will automatically link the contents of
+ site-functions to completions directory in the proper
+ store path.
+
+
+
+
+ The plugins directory needs the structure
+ pluginname/pluginname.plugin.zsh as structured in the
+ upstream
+ repo.
-
-
+
+
-
-A derivation for oh-my-zsh may look like this:
+
+ A derivation for oh-my-zsh may look like this:
{ stdenv, fetchFromGitHub }:
@@ -120,6 +150,6 @@ stdenv.mkDerivation rec {
'';
}
-
-
+
+
diff --git a/nixos/modules/security/acme.xml b/nixos/modules/security/acme.xml
index b4cd83f6632c75..ef71fe53d0c7e5 100644
--- a/nixos/modules/security/acme.xml
+++ b/nixos/modules/security/acme.xml
@@ -3,23 +3,25 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-security-acme">
-
-SSL/TLS Certificates with ACME
-
-NixOS supports automatic domain validation & certificate
-retrieval and renewal using the ACME protocol. This is currently only
-implemented by and for Let's Encrypt. The alternative ACME client
-simp_le is used under the hood.
-
-Prerequisites
-
-You need to have a running HTTP server for verification. The server must
-have a webroot defined that can serve
-.well-known/acme-challenge. This directory must be
-writeable by the user that will run the ACME client.
-
-For instance, this generic snippet could be used for Nginx:
-
+ SSL/TLS Certificates with ACME
+
+ NixOS supports automatic domain validation & certificate retrieval and
+ renewal using the ACME protocol. This is currently only implemented by and
+ for Let's Encrypt. The alternative ACME client simp_le is
+ used under the hood.
+
+
+ Prerequisites
+
+
+ You need to have a running HTTP server for verification. The server must
+ have a webroot defined that can serve
+ .well-known/acme-challenge. This directory must be
+ writeable by the user that will run the ACME client.
+
+
+
+ For instance, this generic snippet could be used for Nginx:
http {
server {
@@ -37,43 +39,47 @@ http {
}
}
-
-
-
-
-Configuring
-
-To enable ACME certificate retrieval & renewal for a certificate for
-foo.example.com, add the following in your
-configuration.nix:
-
+
+
+
+ Configuring
+
+
+ To enable ACME certificate retrieval & renewal for a certificate for
+ foo.example.com, add the following in your
+ configuration.nix:
."foo.example.com" = {
webroot = "/var/www/challenges";
email = "foo@example.com";
};
-
-
-The private key key.pem and certificate
-fullchain.pem will be put into
-/var/lib/acme/foo.example.com. The target directory can
-be configured with the option .
-
-
-Refer to for all available configuration
-options for the security.acme module.
-
-
-
-Using ACME certificates in Nginx
-NixOS supports fetching ACME certificates for you by setting
- enableACME = true; in a virtualHost config. We
-first create self-signed placeholder certificates in place of the
-real ACME certs. The placeholder certs are overwritten when the ACME
-certs arrive. For foo.example.com the config would
-look like.
-
+
+
+
+ The private key key.pem and certificate
+ fullchain.pem will be put into
+ /var/lib/acme/foo.example.com. The target directory can
+ be configured with the option .
+
+
+
+ Refer to for all available configuration
+ options for the security.acme
+ module.
+
+
+
+ Using ACME certificates in Nginx
+
+
+ NixOS supports fetching ACME certificates for you by setting
+ enableACME
+ = true; in a virtualHost config. We first create self-signed
+ placeholder certificates in place of the real ACME certs. The placeholder
+ certs are overwritten when the ACME certs arrive. For
+ foo.example.com the config would look like.
+
services.nginx = {
@@ -89,5 +95,5 @@ services.nginx = {
};
}
-
+
diff --git a/nixos/modules/security/hidepid.xml b/nixos/modules/security/hidepid.xml
index d69341eb3cde18..5a17cb1da412c1 100644
--- a/nixos/modules/security/hidepid.xml
+++ b/nixos/modules/security/hidepid.xml
@@ -3,31 +3,26 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="sec-hidepid">
-
- Hiding process information
-
-
- Setting
+ Hiding process information
+
+ Setting
= true;
- ensures that access to process information is restricted to the
- owning user. This implies, among other things, that command-line
- arguments remain private. Unless your deployment relies on unprivileged
- users being able to inspect the process information of other users, this
- option should be safe to enable.
-
-
-
- Members of the proc group are exempt from process
- information hiding.
-
-
-
- To allow a service foo to run without process information hiding, set
+ ensures that access to process information is restricted to the owning user.
+ This implies, among other things, that command-line arguments remain private.
+ Unless your deployment relies on unprivileged users being able to inspect the
+ process information of other users, this option should be safe to enable.
+
+
+ Members of the proc group are exempt from process
+ information hiding.
+
+
+ To allow a service foo to run without process
+ information hiding, set
systemd.services.foo.serviceConfig.SupplementaryGroups = [ "proc" ];
-
-
+
diff --git a/nixos/modules/services/databases/foundationdb.xml b/nixos/modules/services/databases/foundationdb.xml
index 7883680d46cc3a..bf4b644c9b86aa 100644
--- a/nixos/modules/services/databases/foundationdb.xml
+++ b/nixos/modules/services/databases/foundationdb.xml
@@ -3,42 +3,50 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-services-foundationdb">
-
-FoundationDB
-
-Source:modules/services/databases/foundationdb.nix
-
-Upstream documentation:
-
-Maintainer: Austin Seipp
-
-Available version(s): 5.1.x, 5.2.x, 6.0.x
-
-FoundationDB (or "FDB") is an open source, distributed, transactional
-key-value store.
-
-Configuring and basic setup
-
-To enable FoundationDB, add the following to your
-configuration.nix:
-
+ FoundationDB
+
+ Source:
+ modules/services/databases/foundationdb.nix
+
+
+ Upstream documentation:
+
+
+
+ Maintainer: Austin Seipp
+
+
+ Available version(s): 5.1.x, 5.2.x, 6.0.x
+
+
+ FoundationDB (or "FDB") is an open source, distributed, transactional
+ key-value store.
+
+
+ Configuring and basic setup
+
+
+ To enable FoundationDB, add the following to your
+ configuration.nix:
services.foundationdb.enable = true;
services.foundationdb.package = pkgs.foundationdb52; # FoundationDB 5.2.x
-
-
-The option is required,
-and must always be specified. Due to the fact FoundationDB network protocols and
-on-disk storage formats may change between (major) versions, and upgrades must
-be explicitly handled by the user, you must always manually specify this
-yourself so that the NixOS module will use the proper version. Note that minor,
-bugfix releases are always compatible.
-
-After running nixos-rebuild, you can verify whether
-FoundationDB is running by executing fdbcli (which is added
-to ):
-
+
+
+
+ The option is required, and
+ must always be specified. Due to the fact FoundationDB network protocols and
+ on-disk storage formats may change between (major) versions, and upgrades
+ must be explicitly handled by the user, you must always manually specify
+ this yourself so that the NixOS module will use the proper version. Note
+ that minor, bugfix releases are always compatible.
+
+
+
+ After running nixos-rebuild, you can verify whether
+ FoundationDB is running by executing fdbcli (which is
+ added to ):
$ sudo -u foundationdb fdbcli
Using cluster file `/etc/foundationdb/fdb.cluster'.
@@ -66,14 +74,14 @@ Cluster:
fdb>
-
-
-You can also write programs using the available client libraries.
-For example, the following Python program can be run in order to grab the
-cluster status, as a quick example. (This example uses
-nix-shell shebang support to automatically supply the
-necessary Python modules).
-
+
+
+
+ You can also write programs using the available client libraries. For
+ example, the following Python program can be run in order to grab the
+ cluster status, as a quick example. (This example uses
+ nix-shell shebang support to automatically supply the
+ necessary Python modules).
a@link> cat fdb-status.py
#! /usr/bin/env nix-shell
@@ -100,255 +108,336 @@ a@link> ./fdb-status.py
FoundationDB available: True
a@link>
-
-
-FoundationDB is run under the foundationdb user and
-group by default, but this may be changed in the NixOS configuration. The
-systemd unit foundationdb.service controls the
-fdbmonitor process.
-
-By default, the NixOS module for FoundationDB creates a single
-SSD-storage based database for development and basic usage. This storage engine
-is designed for SSDs and will perform poorly on HDDs; however it can handle far
-more data than the alternative "memory" engine and is a better default choice
-for most deployments. (Note that you can change the storage backend on-the-fly
-for a given FoundationDB cluster using fdbcli.)
-
-Furthermore, only 1 server process and 1 backup agent are started in the
-default configuration. See below for more on scaling to increase this.
-
-FoundationDB stores all data for all server processes under
-/var/lib/foundationdb. You can override this using
-, e.g.
-
+
+
+
+ FoundationDB is run under the foundationdb user and group
+ by default, but this may be changed in the NixOS configuration. The systemd
+ unit foundationdb.service controls the
+ fdbmonitor process.
+
+
+
+ By default, the NixOS module for FoundationDB creates a single SSD-storage
+ based database for development and basic usage. This storage engine is
+ designed for SSDs and will perform poorly on HDDs; however it can handle far
+ more data than the alternative "memory" engine and is a better default
+ choice for most deployments. (Note that you can change the storage backend
+ on-the-fly for a given FoundationDB cluster using
+ fdbcli.)
+
+
+
+ Furthermore, only 1 server process and 1 backup agent are started in the
+ default configuration. See below for more on scaling to increase this.
+
+
+
+ FoundationDB stores all data for all server processes under
+ /var/lib/foundationdb. You can override this using
+ , e.g.
services.foundationdb.dataDir = "/data/fdb";
-
-
-
-Similarly, logs are stored under
-/var/log/foundationdb by default, and there is a
-corresponding as well.
-
-
-
-Scaling processes and backup agents
-
-Scaling the number of server processes is quite easy; simply specify
- to be the number of
-FoundationDB worker processes that should be started on the machine.
-
-FoundationDB worker processes typically require 4GB of RAM per-process at
-minimum for good performance, so this option is set to 1 by default since the
-maximum amount of RAM is unknown. You're advised to abide by this restriction,
-so pick a number of processes so that each has 4GB or more.
-
-A similar option exists in order to scale backup agent processes,
-. Backup agents are not
-as performance/RAM sensitive, so feel free to experiment with the number of
-available backup processes.
-
-
-
-Clustering
-
-FoundationDB on NixOS works similarly to other Linux systems, so this
-section will be brief. Please refer to the full FoundationDB documentation for
-more on clustering.
-
-FoundationDB organizes clusters using a set of
-coordinators, which are just specially-designated worker
-processes. By default, every installation of FoundationDB on NixOS will start
-as its own individual cluster, with a single coordinator: the first worker
-process on localhost.
-
-Coordinators are specified globally using the
-/etc/foundationdb/fdb.cluster file, which all servers and
-client applications will use to find and join coordinators. Note that this file
-can not be managed by NixOS so easily: FoundationDB is
-designed so that it will rewrite the file at runtime for all clients and nodes
-when cluster coordinators change, with clients transparently handling this
-without intervention. It is fundamentally a mutable file, and you should not
-try to manage it in any way in NixOS.
-
-When dealing with a cluster, there are two main things you want to
-do:
-
-
- Add a node to the cluster for storage/compute.
- Promote an ordinary worker to a coordinator.
-
-
-A node must already be a member of the cluster in order to properly be
-promoted to a coordinator, so you must always add it first if you wish to
-promote it.
-
-To add a machine to a FoundationDB cluster:
-
-
- Choose one of the servers to start as the initial coordinator.
-
- Copy the /etc/foundationdb/fdb.cluster file
- from this server to all the other servers. Restart FoundationDB on all of
- these other servers, so they join the cluster.
- All of these servers are now connected and working together
- in the cluster, under the chosen coordinator.
-
-
-At this point, you can add as many nodes as you want by just repeating
-the above steps. By default there will still be a single coordinator: you can
-use fdbcli to change this and add new coordinators.
-
-As a convenience, FoundationDB can automatically assign coordinators
-based on the redundancy mode you wish to achieve for the cluster. Once all the
-nodes have been joined, simply set the replication policy, and then issue the
-coordinators auto command
-
-For example, assuming we have 3 nodes available, we can enable double
-redundancy mode, then auto-select coordinators. For double redundancy, 3
-coordinators is ideal: therefore FoundationDB will make
-every node a coordinator automatically:
+
+
+
+ Similarly, logs are stored under /var/log/foundationdb
+ by default, and there is a corresponding
+ as well.
+
+
+
+ Scaling processes and backup agents
+
+
+ Scaling the number of server processes is quite easy; simply specify
+ to be the number of
+ FoundationDB worker processes that should be started on the machine.
+
+
+
+ FoundationDB worker processes typically require 4GB of RAM per-process at
+ minimum for good performance, so this option is set to 1 by default since
+ the maximum amount of RAM is unknown. You're advised to abide by this
+ restriction, so pick a number of processes so that each has 4GB or more.
+
+
+
+ A similar option exists in order to scale backup agent processes,
+ . Backup agents are
+ not as performance/RAM sensitive, so feel free to experiment with the number
+ of available backup processes.
+
+
+
+ Clustering
+
+
+ FoundationDB on NixOS works similarly to other Linux systems, so this
+ section will be brief. Please refer to the full FoundationDB documentation
+ for more on clustering.
+
+
+
+ FoundationDB organizes clusters using a set of
+ coordinators, which are just specially-designated
+ worker processes. By default, every installation of FoundationDB on NixOS
+ will start as its own individual cluster, with a single coordinator: the
+ first worker process on localhost.
+
+
+
+ Coordinators are specified globally using the
+ /etc/foundationdb/fdb.cluster file, which all servers and
+ client applications will use to find and join coordinators. Note that this
+ file can not be managed by NixOS so easily:
+ FoundationDB is designed so that it will rewrite the file at runtime for all
+ clients and nodes when cluster coordinators change, with clients
+ transparently handling this without intervention. It is fundamentally a
+ mutable file, and you should not try to manage it in any way in NixOS.
+
+
+
+ When dealing with a cluster, there are two main things you want to do:
+
+
+
+
+
+ Add a node to the cluster for storage/compute.
+
+
+
+
+ Promote an ordinary worker to a coordinator.
+
+
+
+
+
+ A node must already be a member of the cluster in order to properly be
+ promoted to a coordinator, so you must always add it first if you wish to
+ promote it.
+
+
+
+ To add a machine to a FoundationDB cluster:
+
+
+
+
+
+ Choose one of the servers to start as the initial coordinator.
+
+
+
+
+ Copy the /etc/foundationdb/fdb.cluster file from this
+ server to all the other servers. Restart FoundationDB on all of these
+ other servers, so they join the cluster.
+
+
+
+
+ All of these servers are now connected and working together in the
+ cluster, under the chosen coordinator.
+
+
+
+
+
+ At this point, you can add as many nodes as you want by just repeating the
+ above steps. By default there will still be a single coordinator: you can
+ use fdbcli to change this and add new coordinators.
+
+
+
+ As a convenience, FoundationDB can automatically assign coordinators based
+ on the redundancy mode you wish to achieve for the cluster. Once all the
+ nodes have been joined, simply set the replication policy, and then issue
+ the coordinators auto command
+
+
+
+ For example, assuming we have 3 nodes available, we can enable double
+ redundancy mode, then auto-select coordinators. For double redundancy, 3
+ coordinators is ideal: therefore FoundationDB will make
+ every node a coordinator automatically:
+
fdbcli> configure double ssd
fdbcli> coordinators auto
-This will transparently update all the servers within seconds, and
-appropriately rewrite the fdb.cluster file, as well as
-informing all client processes to do the same.
-
-
-
-Client connectivity
-
-By default, all clients must use the current
-fdb.cluster file to access a given FoundationDB cluster.
-This file is located by default in
-/etc/foundationdb/fdb.cluster on all machines with the
-FoundationDB service enabled, so you may copy the active one from your cluster
-to a new node in order to connect, if it is not part of the cluster.
-
-
-
-Client authorization and TLS
-
-By default, any user who can connect to a FoundationDB process with the
-correct cluster configuration can access anything. FoundationDB uses a
-pluggable design to transport security, and out of the box it supports a
-LibreSSL-based plugin for TLS support. This plugin not only does in-flight
-encryption, but also performs client authorization based on the given
-endpoint's certificate chain. For example, a FoundationDB server may be
-configured to only accept client connections over TLS, where the client TLS
-certificate is from organization Acme Co in the
-Research and Development unit.
-
-Configuring TLS with FoundationDB is done using the
- options in order to control the peer
-verification string, as well as the certificate and its private key.
-
-Note that the certificate and its private key must be accessible to the
-FoundationDB user account that the server runs under. These files are also NOT
-managed by NixOS, as putting them into the store may reveal private
-information.
-
-After you have a key and certificate file in place, it is not enough to
-simply set the NixOS module options -- you must also configure the
-fdb.cluster file to specify that a given set of coordinators
-use TLS. This is as simple as adding the suffix :tls to your
-cluster coordinator configuration, after the port number. For example, assuming
-you have a coordinator on localhost with the default configuration, simply
-specifying:
+
+ This will transparently update all the servers within seconds, and
+ appropriately rewrite the fdb.cluster file, as well as
+ informing all client processes to do the same.
+
+
+
+ Client connectivity
+
+
+ By default, all clients must use the current fdb.cluster
+ file to access a given FoundationDB cluster. This file is located by default
+ in /etc/foundationdb/fdb.cluster on all machines with the
+ FoundationDB service enabled, so you may copy the active one from your
+ cluster to a new node in order to connect, if it is not part of the cluster.
+
+
+
+ Client authorization and TLS
+
+
+ By default, any user who can connect to a FoundationDB process with the
+ correct cluster configuration can access anything. FoundationDB uses a
+ pluggable design to transport security, and out of the box it supports a
+ LibreSSL-based plugin for TLS support. This plugin not only does in-flight
+ encryption, but also performs client authorization based on the given
+ endpoint's certificate chain. For example, a FoundationDB server may be
+ configured to only accept client connections over TLS, where the client TLS
+ certificate is from organization Acme Co in the
+ Research and Development unit.
+
+
+
+ Configuring TLS with FoundationDB is done using the
+ options in order to control the
+ peer verification string, as well as the certificate and its private key.
+
+
+
+ Note that the certificate and its private key must be accessible to the
+ FoundationDB user account that the server runs under. These files are also
+ NOT managed by NixOS, as putting them into the store may reveal private
+ information.
+
+
+
+ After you have a key and certificate file in place, it is not enough to
+ simply set the NixOS module options -- you must also configure the
+ fdb.cluster file to specify that a given set of
+ coordinators use TLS. This is as simple as adding the suffix
+ :tls to your cluster coordinator configuration, after the
+ port number. For example, assuming you have a coordinator on localhost with
+ the default configuration, simply specifying:
+
XXXXXX:XXXXXX@127.0.0.1:4500:tls
-will configure all clients and server processes to use TLS from now
-on.
-
-
-
-Backups and Disaster Recovery
-
-The usual rules for doing FoundationDB backups apply on NixOS as written
-in the FoundationDB manual. However, one important difference is the security
-profile for NixOS: by default, the foundationdb systemd unit
-uses Linux namespaces to restrict write access to the
-system, except for the log directory, data directory, and the
-/etc/foundationdb/ directory. This is enforced by default
-and cannot be disabled.
-
-However, a side effect of this is that the fdbbackup
-command doesn't work properly for local filesystem backups: FoundationDB uses a
-server process alongside the database processes to perform backups and copy the
-backups to the filesystem. As a result, this process is put under the
-restricted namespaces above: the backup process can only write to a limited
-number of paths.
-
-In order to allow flexible backup locations on local disks, the
-FoundationDB NixOS module supports a
- option. This option
-takes a list of paths, and adds them to the systemd unit, allowing the
-processes inside the service to write (and read) the specified
-directories.
-
-For example, to create backups in /opt/fdb-backups,
-first set up the paths in the module options:
+
+ will configure all clients and server processes to use TLS from now on.
+
+
+
+ Backups and Disaster Recovery
+
+
+ The usual rules for doing FoundationDB backups apply on NixOS as written in
+ the FoundationDB manual. However, one important difference is the security
+ profile for NixOS: by default, the foundationdb systemd
+ unit uses Linux namespaces to restrict write access to
+ the system, except for the log directory, data directory, and the
+ /etc/foundationdb/ directory. This is enforced by default
+ and cannot be disabled.
+
+
+
+ However, a side effect of this is that the fdbbackup
+ command doesn't work properly for local filesystem backups: FoundationDB
+ uses a server process alongside the database processes to perform backups
+ and copy the backups to the filesystem. As a result, this process is put
+ under the restricted namespaces above: the backup process can only write to
+ a limited number of paths.
+
+
+
+ In order to allow flexible backup locations on local disks, the FoundationDB
+ NixOS module supports a
+ option. This
+ option takes a list of paths, and adds them to the systemd unit, allowing
+ the processes inside the service to write (and read) the specified
+ directories.
+
+
+
+ For example, to create backups in /opt/fdb-backups, first
+ set up the paths in the module options:
+
services.foundationdb.extraReadWritePaths = [ "/opt/fdb-backups" ];
-Restart the FoundationDB service, and it will now be able to write to
-this directory (even if it does not yet exist.) Note: this path
-must exist before restarting the unit. Otherwise, systemd
-will not include it in the private FoundationDB namespace (and it will not add
-it dynamically at runtime).
+
+ Restart the FoundationDB service, and it will now be able to write to this
+ directory (even if it does not yet exist.) Note: this path
+ must exist before restarting the unit. Otherwise,
+ systemd will not include it in the private FoundationDB namespace (and it
+ will not add it dynamically at runtime).
+
-You can now perform a backup:
+
+ You can now perform a backup:
+
$ sudo -u foundationdb fdbbackup start -t default -d file:///opt/fdb-backups
$ sudo -u foundationdb fdbbackup status -t default
-
-
-
-Known limitations
-
-The FoundationDB setup for NixOS should currently be considered beta.
-FoundationDB is not new software, but the NixOS compilation and integration has
-only undergone fairly basic testing of all the available functionality.
-
-
- There is no way to specify individual parameters for
- individual fdbserver processes. Currently, all server
- processes inherit all the global fdbmonitor settings.
-
- Ruby bindings are not currently installed.
- Go bindings are not currently installed.
-
-
-
-
-Options
-
-NixOS's FoundationDB module allows you to configure all of the most
-relevant configuration options for fdbmonitor, matching it
-quite closely. A complete list of options for the FoundationDB module may be
-found here. You should
-also read the FoundationDB documentation as well.
-
-
-
-Full documentation
-
-FoundationDB is a complex piece of software, and requires careful
-administration to properly use. Full documentation for administration can be
-found here: .
-
-
-
+
+
+ Known limitations
+
+
+ The FoundationDB setup for NixOS should currently be considered beta.
+ FoundationDB is not new software, but the NixOS compilation and integration
+ has only undergone fairly basic testing of all the available functionality.
+
+
+
+
+
+ There is no way to specify individual parameters for individual
+ fdbserver processes. Currently, all server processes
+ inherit all the global fdbmonitor settings.
+
+
+
+
+ Ruby bindings are not currently installed.
+
+
+
+
+ Go bindings are not currently installed.
+
+
+
+
+
+ Options
+
+
+ NixOS's FoundationDB module allows you to configure all of the most relevant
+ configuration options for fdbmonitor, matching it quite
+ closely. A complete list of options for the FoundationDB module may be found
+ here. You should
+ also read the FoundationDB documentation as well.
+
+
+
+ Full documentation
+
+
+ FoundationDB is a complex piece of software, and requires careful
+ administration to properly use. Full documentation for administration can be
+ found here: .
+
+
diff --git a/nixos/modules/services/databases/postgresql.xml b/nixos/modules/services/databases/postgresql.xml
index 1aaf339632454c..f89f0d65316437 100644
--- a/nixos/modules/services/databases/postgresql.xml
+++ b/nixos/modules/services/databases/postgresql.xml
@@ -3,36 +3,39 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-postgresql">
-
-PostgreSQL
-
+ PostgreSQL
-
-Source:modules/services/databases/postgresql.nix
-
-Upstream documentation:
-
+
+ Source:
+ modules/services/databases/postgresql.nix
+
+
+ Upstream documentation:
+
+
-
-PostgreSQL is an advanced, free relational database.
-
-Configuring
-
-To enable PostgreSQL, add the following to your
-configuration.nix:
-
+
+ PostgreSQL is an advanced, free relational database.
+
+
+
+ Configuring
+
+
+ To enable PostgreSQL, add the following to your
+ configuration.nix:
= true;
= pkgs.postgresql94;
-
-Note that you are required to specify the desired version of
-PostgreSQL (e.g. pkgs.postgresql94). Since
-upgrading your PostgreSQL version requires a database dump and reload
-(see below), NixOS cannot provide a default value for
- such as the most recent
-release of PostgreSQL.
+ Note that you are required to specify the desired version of PostgreSQL
+ (e.g. pkgs.postgresql94). Since upgrading your PostgreSQL
+ version requires a database dump and reload (see below), NixOS cannot
+ provide a default value for
+ such as the most recent
+ release of PostgreSQL.
+
-By default, PostgreSQL stores its databases in
-/var/db/postgresql. You can override this using
-, e.g.
-
+
+ By default, PostgreSQL stores its databases in
+ /var/db/postgresql. You can override this using
+ , e.g.
= "/data/postgresql";
-
-
-
-
-
-
-Upgrading
-
-FIXME: document dump/upgrade/load cycle.
-
-
-
-
-Options
-
- A complete list of options for the PostgreSQL module may be found here.
-
-
-
-
+
+
+
+ Upgrading
+
+
+ FIXME: document dump/upgrade/load cycle.
+
+
+
+ Options
+
+
+ A complete list of options for the PostgreSQL module may be found
+ here.
+
+
diff --git a/nixos/modules/services/desktops/flatpak.xml b/nixos/modules/services/desktops/flatpak.xml
index d9c8b711c450b8..8045d5fa14f8b8 100644
--- a/nixos/modules/services/desktops/flatpak.xml
+++ b/nixos/modules/services/desktops/flatpak.xml
@@ -3,51 +3,54 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-services-flatpak">
-
-Flatpak
-
-Source:modules/services/desktop/flatpak.nix
-
-Upstream documentation:
-
-Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux.
-
-
- To enable Flatpak, add the following to your configuration.nix:
-
-
+ Flatpak
+
+ Source:
+ modules/services/desktop/flatpak.nix
+
+
+ Upstream documentation:
+
+
+
+ Flatpak is a system for building, distributing, and running sandboxed desktop
+ applications on Linux.
+
+
+ To enable Flatpak, add the following to your
+ configuration.nix:
+ = true;
-
-
-
- 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 configuration.nix:
-
-
+
+
+ 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
+ configuration.nix:
+ = [ pkgs.xdg-desktop-portal-gtk ];
-
-
-
- Then, you will need to add a repository, for example, Flathub, either using the following commands:
-
-
+
+
+ Then, you will need to add a repository, for example,
+ Flathub,
+ either using the following commands:
+
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak update
-
- or by opening the repository file in GNOME Software.
-
-
-
+ or by opening the
+ repository
+ file in GNOME Software.
+
+
Finally, you can search and install programs:
-
-
+
flatpak search bustle
flatpak install flathub org.freedesktop.Bustle
flatpak run org.freedesktop.Bustle
-
Again, GNOME Software offers graphical interface for these tasks.
-
+
diff --git a/nixos/modules/services/editors/emacs.xml b/nixos/modules/services/editors/emacs.xml
index 94eb2e6a77bf51..6cf20cf4aa7e7e 100644
--- a/nixos/modules/services/editors/emacs.xml
+++ b/nixos/modules/services/editors/emacs.xml
@@ -3,150 +3,148 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
version="5.0"
xml:id="module-services-emacs">
-
- Emacs
-
-
+
+ Emacs is an
+ extensible, customizable, self-documenting real-time display editor — and
+ more. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp
+ programming language with extensions to support text editing.
+
+
+ Emacs runs within a graphical desktop environment using the X Window System,
+ but works equally well on a text terminal. Under
+ macOS, a "Mac port" edition is available, which
+ uses Apple's native GUI frameworks.
+
+
+ Nixpkgs provides a superior environment for
+ running Emacs. It's simple to create custom builds
+ by overriding the default packages. Chaotic collections of Emacs Lisp code
+ and extensions can be brought under control using declarative package
+ management. NixOS even provides a
+ systemd user service for automatically starting the Emacs
+ daemon.
+
+
+ Installing <application>Emacs</application>
- Emacs
- is an extensible, customizable, self-documenting real-time display
- editor — and more. At its core is an interpreter for Emacs Lisp, a
- dialect of the Lisp programming language with extensions to
- support text editing.
+ Emacs can be installed in the normal way for Nix (see
+ ). In addition, a NixOS
+ service can be enabled.
-
- Emacs runs within a graphical desktop environment using the X
- Window System, but works equally well on a text terminal. Under
- macOS, a "Mac port" edition is
- available, which uses Apple's native GUI frameworks.
-
+
+ The Different Releases of Emacs
+
+
+ Nixpkgs defines several basic Emacs packages.
+ The following are attributes belonging to the pkgs set:
+
+
+
+ emacs
+
+
+ emacs25
+
+
+
+ The latest stable version of Emacs 25 using the
+ GTK+ 2
+ widget toolkit.
+
+
+
+
+
+ emacs25-nox
+
+
+
+ Emacs 25 built without any dependency on X11 libraries.
+
+
+
+
+
+ emacsMacport
+
+
+ emacs25Macport
+
+
+
+ Emacs 25 with the "Mac port" patches, providing a more native look and
+ feel under macOS.
+
+
+
+
+
+
+
+ If those aren't suitable, then the following imitation Emacs editors are
+ also available in Nixpkgs:
+ Zile,
+ mg,
+ Yi.
+
+
-
- Nixpkgs provides a superior environment
- for running Emacs. It's simple to
- create custom builds by overriding the default packages. Chaotic
- collections of Emacs Lisp code and extensions can be brought under
- control using declarative package
- management. NixOS even provides a
- systemd user service for automatically
- starting the Emacs daemon.
-
+
+ Adding Packages to Emacs
-
- Installing <application>Emacs</application>
+
+ Emacs includes an entire ecosystem of functionality beyond text editing,
+ including a project planner, mail and news reader, debugger interface,
+ calendar, and more.
+
+
+ Most extensions are gotten with the Emacs packaging system
+ (package.el) from
+ Emacs Lisp Package Archive
+ (ELPA),
+ MELPA,
+ MELPA Stable, and
+ Org ELPA. Nixpkgs is
+ regularly updated to mirror all these archives.
+
+
+
+ Under NixOS, you can continue to use
+ package-list-packages and
+ package-install to install packages. You can also
+ declare the set of Emacs packages you need using the derivations from
+ Nixpkgs. The rest of this section discusses declarative installation of
+ Emacs packages through nixpkgs.
+
+
+
- Emacs can be installed in the normal way for Nix (see
- ).
- In addition, a NixOS service
- can be enabled.
+ This documentation describes the new Emacs packages framework in NixOS
+ 16.03 (emacsPackagesNg) which should not be confused
+ with the previous and deprecated framework
+ (emacs24Packages).
-
-
- The Different Releases of Emacs
-
-
- Nixpkgs defines several basic Emacs
- packages. The following are attributes belonging to the
- pkgs set:
-
-
-
- emacs
- emacs25
-
-
- The latest stable version of Emacs 25 using the GTK+ 2 widget
- toolkit.
-
-
-
-
- emacs25-nox
-
-
- Emacs 25 built without any dependency on X11
- libraries.
-
-
-
-
- emacsMacport
- emacs25Macport
-
-
- Emacs 25 with the "Mac port" patches, providing a more
- native look and feel under macOS.
-
-
-
-
-
-
-
- If those aren't suitable, then the following imitation Emacs
- editors are also available in Nixpkgs:
- Zile,
- mg,
- Yi.
-
-
-
-
- Adding Packages to Emacs
-
- Emacs includes an entire ecosystem of functionality beyond
- text editing, including a project planner, mail and news
- reader, debugger interface, calendar, and more.
-
-
-
- Most extensions are gotten with the Emacs packaging system
- (package.el) from Emacs Lisp Package Archive
- (ELPA),
- MELPA,
- MELPA Stable,
- and Org ELPA.
- Nixpkgs is regularly updated to mirror all these archives.
-
-
-
- Under NixOS, you can continue to use
- package-list-packages and
- package-install to install packages. You
- can also declare the set of Emacs packages you need using the
- derivations from Nixpkgs. The rest of this section discusses
- declarative installation of Emacs packages through nixpkgs.
-
-
-
-
- This documentation describes the new Emacs packages
- framework in NixOS 16.03
- (emacsPackagesNg) which should not be
- confused with the previous and deprecated framework
- (emacs24Packages).
-
-
-
-
- The first step to declare the list of packages you want in
- your Emacs installation is to create a dedicated
- derivation. This can be done in a dedicated
- emacs.nix file such as:
-
-
- Nix expression to build Emacs with packages (<filename>emacs.nix</filename>)
-
+
+
+
+ The first step to declare the list of packages you want in your Emacs
+ installation is to create a dedicated derivation. This can be done in a
+ dedicated emacs.nix file such as:
+
+ Nix expression to build Emacs with packages (<filename>emacs.nix</filename>)
+
/*
This is a nix expression to build Emacs and some Emacs packages I like
from source on any distribution where Nix is installed. This will install
@@ -181,119 +179,104 @@ in
pkgs.notmuch # From main packages set
])
-
-
-
-
-
- The first non-comment line in this file
- ({ pkgs ? ... })
- indicates that the whole file represents a function.
-
-
-
-
-
- The let expression below defines a
- myEmacs binding pointing to the current
- stable version of Emacs. This binding is here to separate the
- choice of the Emacs binary from the specification of the
- required packages.
-
-
-
-
-
- This generates an emacsWithPackages
- function. It takes a single argument: a function from a
- package set to a list of packages (the packages that will
- be available in Emacs).
-
-
-
-
-
- The rest of the file specifies the list of packages to
- install. In the example, two packages
- (magit and
- zerodark-theme) are taken from MELPA
- stable.
-
-
-
-
-
- Two packages (undo-tree and
- zoom-frm) are taken from MELPA.
-
-
-
-
- Three packages are taken from GNU ELPA.
-
-
-
-
- notmuch is taken from a nixpkgs derivation
- which contains an Emacs mode.
-
-
-
-
+
+
+
+
+ The first non-comment line in this file ({ pkgs ? ...
+ }) indicates that the whole file represents a function.
-
+
+
- The result of this configuration will be an
- emacs command which launches Emacs with all
- of your chosen packages in the load-path.
+ The let expression below defines a
+ myEmacs binding pointing to the current stable
+ version of Emacs. This binding is here to separate the choice of the
+ Emacs binary from the specification of the required packages.
-
+
+
- You can check that it works by executing this in a terminal:
-
+ This generates an emacsWithPackages function. It
+ takes a single argument: a function from a package set to a list of
+ packages (the packages that will be available in Emacs).
+
+
+
+
+ The rest of the file specifies the list of packages to install. In the
+ example, two packages (magit and
+ zerodark-theme) are taken from MELPA stable.
+
+
+
+
+ Two packages (undo-tree and
+ zoom-frm) are taken from MELPA.
+
+
+
+
+ Three packages are taken from GNU ELPA.
+
+
+
+
+ notmuch is taken from a nixpkgs derivation which
+ contains an Emacs mode.
+
+
+
+
+
+
+ The result of this configuration will be an emacs
+ command which launches Emacs with all of your chosen packages in the
+ load-path.
+
+
+
+ You can check that it works by executing this in a terminal:
$ nix-build emacs.nix
$ ./result/bin/emacs -q
+ and then typing M-x package-initialize. Check that you
+ can use all the packages you want in this Emacs instance. For example, try
+ switching to the zerodark theme through M-x load-theme <RET>
+ zerodark <RET> y.
+
- and then typing M-x package-initialize.
- Check that you can use all the packages you want in this
- Emacs instance. For example, try switching to the zerodark
- theme through
- M-x load-theme <RET> zerodark <RET> y.
-
-
-
-
- A few popular extensions worth checking out are: auctex,
- company, edit-server, flycheck, helm, iedit, magit,
- multiple-cursors, projectile, and yasnippet.
-
-
-
-
- The list of available packages in the various ELPA
- repositories can be seen with the following commands:
-
- Querying Emacs packages
-
+
+ A few popular extensions worth checking out are: auctex, company,
+ edit-server, flycheck, helm, iedit, magit, multiple-cursors, projectile,
+ and yasnippet.
+
+
+
+
+ The list of available packages in the various ELPA repositories can be seen
+ with the following commands:
+
+ Querying Emacs packages
+" -qaP -A emacsPackagesNg.elpaPackages
nix-env -f "" -qaP -A emacsPackagesNg.melpaPackages
nix-env -f "" -qaP -A emacsPackagesNg.melpaStablePackages
nix-env -f "" -qaP -A emacsPackagesNg.orgPackages
]]>
-
-
-
-
- If you are on NixOS, you can install this particular Emacs for
- all users by adding it to the list of system packages
- (see ). Simply
- modify your file configuration.nix to
- make it contain:
-
- Custom Emacs in <filename>configuration.nix</filename>
-
+
+
+
+ If you are on NixOS, you can install this particular Emacs for all users by
+ adding it to the list of system packages (see
+ ). Simply modify your file
+ configuration.nix to make it contain:
+
+ Custom Emacs in <filename>configuration.nix</filename>
+" -qaP -A emacsPackagesNg.orgPackages
];
}
]]>
-
-
+
+
-
- In this case, the next nixos-rebuild switch
- will take care of adding your emacs to the
- PATH environment variable
- (see ).
-
+
+ In this case, the next nixos-rebuild switch will take
+ care of adding your emacs to the PATH
+ environment variable (see ).
+
-
- If you are not on NixOS or want to install this particular
- Emacs only for yourself, you can do so by adding it to your
- ~/.config/nixpkgs/config.nix
- (see Nixpkgs manual):
-
- Custom Emacs in <filename>~/.config/nixpkgs/config.nix</filename>
-
+ If you are not on NixOS or want to install this particular Emacs only for
+ yourself, you can do so by adding it to your
+ ~/.config/nixpkgs/config.nix (see
+ Nixpkgs
+ manual):
+
+ Custom Emacs in <filename>~/.config/nixpkgs/config.nix</filename>
+
-
-
-
-
- In this case, the next
- nix-env -f '<nixpkgs>' -iA myemacs
- will take care of adding your emacs to the
- PATH environment variable.
-
-
-
-
- Advanced Emacs Configuration
+
+
-
- If you want, you can tweak the Emacs package itself from your
- emacs.nix. For example, if you want to
- have a GTK+3-based Emacs instead of the default GTK+2-based
- binary and remove the automatically generated
- emacs.desktop (useful is you only use
- emacsclient), you can change your file
- emacs.nix in this way:
-
+
+ In this case, the next nix-env -f '<nixpkgs>' -iA
+ myemacs will take care of adding your emacs to the
+ PATH environment variable.
+
+
-
- Custom Emacs build
-
+ Advanced Emacs Configuration
+
+
+ If you want, you can tweak the Emacs package itself from your
+ emacs.nix. For example, if you want to have a
+ GTK+3-based Emacs instead of the default GTK+2-based binary and remove the
+ automatically generated emacs.desktop (useful is you
+ only use emacsclient), you can change your file
+ emacs.nix in this way:
+
+
+
+ Custom Emacs build
+ {} }:
let
myEmacs = (pkgs.emacs.override {
@@ -370,161 +352,143 @@ let
});
in [...]
]]>
-
+
-
- After building this file as shown in ,
- you will get an GTK3-based Emacs binary pre-loaded with your
- favorite packages.
-
-
+
+ After building this file as shown in , you
+ will get an GTK3-based Emacs binary pre-loaded with your favorite packages.
+
-
-
+
+ Running Emacs as a Service
+
- NixOS provides an optional
- systemd service which launches
-
- Emacs daemon
-
- with the user's login session.
+ NixOS provides an optional
+ systemd service which launches
+
+ Emacs daemon with the user's login session.
- Source:
- modules/services/editors/emacs.nix
+ Source:
+ modules/services/editors/emacs.nix
- Enabling the Service
-
-
- To install and enable the systemd
- user service for Emacs daemon, add the following to your
- configuration.nix:
+ Enabling the Service
+
+ To install and enable the systemd user service for Emacs
+ daemon, add the following to your configuration.nix:
= true;
= import /home/cassou/.emacs.d { pkgs = pkgs; };
-
-
-
- The services.emacs.package option allows a
- custom derivation to be used, for example, one created by
- emacsWithPackages.
-
-
-
- Ensure that the Emacs server is enabled for your user's Emacs
- configuration, either by customizing the
- server-mode variable, or by adding
- (server-start) to
- ~/.emacs.d/init.el.
-
-
-
- To start the daemon, execute the following:
-
+
+
+
+ The services.emacs.package option allows a custom
+ derivation to be used, for example, one created by
+ emacsWithPackages.
+
+
+
+ Ensure that the Emacs server is enabled for your user's Emacs
+ configuration, either by customizing the server-mode
+ variable, or by adding (server-start) to
+ ~/.emacs.d/init.el.
+
+
+
+ To start the daemon, execute the following:
$ nixos-rebuild switch # to activate the new configuration.nix
$ systemctl --user daemon-reload # to force systemd reload
$ systemctl --user start emacs.service # to start the Emacs daemon
-
- The server should now be ready to serve Emacs clients.
-
-
+ The server should now be ready to serve Emacs clients.
+
- Starting the client
-
- Ensure that the emacs server is enabled, either by customizing
- the server-mode variable, or by adding
- (server-start) to
- ~/.emacs.
-
+ Starting the client
-
- To connect to the emacs daemon, run one of the following:
-
+ Ensure that the emacs server is enabled, either by customizing the
+ server-mode variable, or by adding
+ (server-start) to ~/.emacs.
+
+
+
+ To connect to the emacs daemon, run one of the following:
+
-
+
- Configuring the <varname>EDITOR</varname> variable
-
-
-
- If is
- true, the EDITOR variable
- will be set to a wrapper script which launches
- emacsclient.
-
-
-
- Any setting of EDITOR in the shell config
- files will override
- services.emacs.defaultEditor.
- To make sure EDITOR refers to the Emacs
- wrapper script, remove any existing EDITOR
- assignment from .profile,
- .bashrc, .zshenv or
- any other shell config file.
-
-
-
- If you have formed certain bad habits when editing files,
- these can be corrected with a shell alias to the wrapper
- script:
- alias vi=$EDITOR
-
+ Configuring the <varname>EDITOR</varname> variable
+
+
+
+
+ If is
+ true, the EDITOR variable will be set
+ to a wrapper script which launches emacsclient.
+
+
+
+ Any setting of EDITOR in the shell config files will
+ override services.emacs.defaultEditor. To make sure
+ EDITOR refers to the Emacs wrapper script, remove any
+ existing EDITOR assignment from
+ .profile, .bashrc,
+ .zshenv or any other shell config file.
+
+
+
+ If you have formed certain bad habits when editing files, these can be
+ corrected with a shell alias to the wrapper script:
+alias vi=$EDITOR
+
- Per-User Enabling of the Service
-
-
- In general, systemd user services
- are globally enabled by symlinks in
- /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:
+ Per-User Enabling of the Service
+
+ In general, systemd user services are globally enabled
+ by symlinks in /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:
= false;
= true;
-
-
-
- To enable the systemd user service for just
- the currently logged in user, run:
-
- systemctl --user enable emacs
-
- This will add the symlink
- ~/.config/systemd/user/emacs.service.
-
+
+
+
+ To enable the systemd user service for just the
+ currently logged in user, run:
+systemctl --user enable emacs
+ This will add the symlink
+ ~/.config/systemd/user/emacs.service.
+
-
-
-
+
+ Configuring Emacs
- The Emacs init file should be changed to load the extension
- packages at startup:
-
-
- Package initialization in <filename>.emacs</filename>
-
+ Package initialization in <filename>.emacs</filename>
+
-
+
- After the declarative emacs package configuration has been
- tested, previously downloaded packages can be cleaned up by
- removing ~/.emacs.d/elpa (do make a backup
- first, in case you forgot a package).
+ After the declarative emacs package configuration has been tested,
+ previously downloaded packages can be cleaned up by removing
+ ~/.emacs.d/elpa (do make a backup first, in case you
+ forgot a package).
-
- A Major Mode for Nix Expressions
+ A Major Mode for Nix Expressions
-
- Of interest may be melpaPackages.nix-mode,
- which provides syntax highlighting for the Nix language. This is
- particularly convenient if you regularly edit Nix files.
-
+
+ Of interest may be melpaPackages.nix-mode, which
+ provides syntax highlighting for the Nix language. This is particularly
+ convenient if you regularly edit Nix files.
+
- Accessing man pages
-
- You can use woman to get completion of all
- available man pages. For example, type M-x woman
- <RET> nixos-rebuild <RET>.
-
+ Accessing man pages
+
+
+ You can use woman to get completion of all available
+ man pages. For example, type M-x woman <RET> nixos-rebuild
+ <RET>.
+
- Editing DocBook 5 XML Documents
-
- Emacs includes nXML,
- a major-mode for validating and editing XML documents.
- When editing DocBook 5.0 documents, such as
- this one,
- nXML needs to be configured with the relevant schema, which is
- not included.
-
+ Editing DocBook 5 XML Documents
-
- To install the DocBook 5.0 schemas, either add
- pkgs.docbook5 to
- (
+ Emacs includes
+ nXML,
+ a major-mode for validating and editing XML documents. When editing DocBook
+ 5.0 documents, such as this one,
+ nXML needs to be configured with the relevant schema, which is not
+ included.
+
+
+
+ To install the DocBook 5.0 schemas, either add
+ pkgs.docbook5 to
+
+ (NixOS), or run
- nix-env -i pkgs.docbook5
- (Nix).
-
-
-
- Then customize the variable rng-schema-locating-files to include ~/.emacs.d/schemas.xml and put the following text into that file:
-
- nXML Schema Configuration (<filename>~/.emacs.d/schemas.xml</filename>)
- nix-env -i pkgs.docbook5
+ (Nix).
+
+
+
+ Then customize the variable rng-schema-locating-files to
+ include ~/.emacs.d/schemas.xml and put the following
+ text into that file:
+
+ nXML Schema Configuration (<filename>~/.emacs.d/schemas.xml</filename>)
+