public/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Added cross-references to NixOS manual

Browse Source
This commit is contained in:
Reuben D'Netto
2018-04-12 09:39:14 +10:00
parent a683d2cd00
commit 42a84598fb
39 changed files with 340 additions and 338 deletions
Download Patch File Download Diff File Expand all files Collapse all files
nixos/modules/security/acme.xml
+11 -11
View File
@@ -48,9 +48,9 @@ http {
<filename>configuration.nix</filename>:
<programlisting>
security.acme.certs."foo.example.com" = {
webroot = "/var/www/challenges";
email = "foo@example.com";
<xref linkend="opt-security.acme.certs"/>."foo.example.com" = {
<link linkend="opt-security.acme.certs._name_.webroot">webroot</link> = "/var/www/challenges";
<link linkend="opt-security.acme.certs._name_.email">email</link> = "foo@example.com";
};
</programlisting>
</para>
@@ -58,17 +58,17 @@ security.acme.certs."foo.example.com" = {
<para>The private key <filename>key.pem</filename> and certificate
<filename>fullchain.pem</filename> will be put into
<filename>/var/lib/acme/foo.example.com</filename>. The target directory can
be configured with the option <literal>security.acme.directory</literal>.
be configured with the option <xref linkend="opt-security.acme.directory"/>.
</para>
<para>Refer to <xref linkend="ch-options" /> for all available configuration
options for the <literal>security.acme</literal> module.</para>
options for the <link linkend="opt-security.acme.certs">security.acme</link> module.</para>
</section>
<section><title>Using ACME certificates in Nginx</title>
<para>NixOS supports fetching ACME certificates for you by setting
<literal>enableACME = true;</literal> in a virtualHost config. We
<literal><link linkend="opt-services.nginx.virtualHosts._name_.enableACME">enableACME</link> = true;</literal> 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 <literal>foo.example.com</literal> the config would
@@ -77,13 +77,13 @@ look like.
<programlisting>
services.nginx = {
enable = true;
virtualHosts = {
<link linkend="opt-services.nginx.enable">enable = true;</link>
<link linkend="opt-services.nginx.virtualHosts">virtualHosts</link> = {
"foo.example.com" = {
forceSSL = true;
enableACME = true;
<link linkend="opt-services.nginx.virtualHosts._name_.forceSSL">forceSSL</link> = true;
<link linkend="opt-services.nginx.virtualHosts._name_.enableACME">enableACME</link> = true;
locations."/" = {
root = "/var/www";
<link linkend="opt-services.nginx.virtualHosts._name_.locations._name_.root">root</link> = "/var/www";
};
};
};
nixos/modules/security/hidepid.xml
+6 -6
View File
@@ -8,9 +8,9 @@
<para>
Setting
<programlisting>
security.hideProcessInformation = true;
</programlisting>
<programlisting>
<xref linkend="opt-security.hideProcessInformation"/> = true;
</programlisting>
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
@@ -25,9 +25,9 @@
<para>
To allow a service <replaceable>foo</replaceable> to run without process information hiding, set
<programlisting>
systemd.services.<replaceable>foo</replaceable>.serviceConfig.SupplementaryGroups = [ "proc" ];
</programlisting>
<programlisting>
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.<replaceable>foo</replaceable>.serviceConfig</link>.SupplementaryGroups = [ "proc" ];
</programlisting>
</para>
</chapter>