case sensitive systemd directives

article.md

@@ -25,16 +25,18 @@ In a nutshell, configuring systemd options for services on NixOS typically boils
 
 Alternatively, new configurations can be tested inside a QEMU VM clone of your system without affecting your running system configuration. `nixos-build build-vm` leaves a symlink `./result` in the current directory that contains the built VM. To run it, use `result/bin/run-<hostname>-vm`.
 
-Keep in mind that mutable operations like `systemd SERVICE enable` are useless, because they would deviate the system from declarative reproducible configuration and NixOS won't let or will stubbornly resist you doing so at the design level. And there is no need, since each permanent setting is in the hands of NixOS.
+Be aware that systemd directives (options) are case sensitive! But NixOS doesn't know whether systemd recognizes any directives or not, whereas systemd does not complain neither! So, once new configuration is applied, analyze output of these commands and compare with intended objectives:
+
+* `systemd cat <name>` - contents of a systemd unit file, generated by NixOS
+* `systemd show <name>` - actual properties of a systemd unit in use
+
+Also, keep in mind that mutable operations like `systemd SERVICE enable` are useless, because they would deviate the system from declarative reproducible configuration and NixOS won't let or will stubbornly resist you doing so at the design level. And there is no need, since each permanent setting is in the hands of NixOS.
 
 ## hardening
 
-### resources limits strategy
+NixOS provides many services, available as `services.<name>.*`, which already have more or less hardening implemented by the means of systemd. For example, `services.nginx`, `services.gitea`, `services.jitsi-meet`, `services.redis`. At least, these services run under specific system non-root users without access to spawn a shell.
 
-NixOS already provides more or less isolation for many services, which are available as `services.<name>.*` options.
-
-
-Btw, if your systemd service code gets large and you want to wrap it into something more esthetic, you [can](https://nixos.wiki/wiki/Extend_NixOS) [write your own NixOS service module](https://scvalex.net/posts/58/).
+There are, however, services like `services.dovecot2`, `services.postfix` and `services.nextcloud`, which use their own means to spawn sub-processes under a specific user by a master process. Such master process is run under `root`. For example, nextcloud uses `php:fpm` ([PHP FastCGI Process Manager](https://php-fpm.org/)). Obviously, shell can be spawned by such processes and a lot more, but they do not have network connections outside world and intended specifically for process/workers management and logging. Ideally, we would want them to be run under non-root user regardless, but usually [it's not easy to do](https://github.com/docker-library/php/issues/70#issuecomment-1386729923) and upstream might not expect such usage.
 
 ### blocking outgoing internet connections
 
@@ -53,6 +55,27 @@ networking.firewall = {
 };
 ```
 
+### resources limits strategy
+
+Systemd resource control settings allow you to limit the resources provided to a service. For example, if `MemoryMax` limit is exceeded, OOM killer gets invoked.
+```nix
+systemd.service = {
+  nginx = {
+    serviceConfig = {
+      CpuAccounting = true;
+      CpuQuota = "70%";
+      MemoryAccounting = true;
+      MemoryMax = "768M";
+      BlockIOWeigth = 10;
+    };
+  };
+}
+```
+
+`MemoryMax` is the absolute limit. It is recommended to use `MemoryHigh` as the main control mechanism, because it allows to go above the limit, but the processses are heavily slowed down and memory is taken away aggressively.
+
+_Btw, if your systemd service code gets large and you want to wrap it into something more esthetic, you [can](https://nixos.wiki/wiki/Extend_NixOS) [write your own NixOS service module](https://scvalex.net/posts/58/)._
+
 ### cgroups
 
 [`cgroup`](https://en.wikipedia.org/wiki/Cgroups) - control group.
@@ -79,7 +102,7 @@ DefaultIPAccounting=yes
 
 ### when trying systemd options alone
 
-You can manually test various systemd options without writing service files using `systemd-run`, for example:
+You can manually test various systemd options without writing service files with the help of `systemd-run`, for example:
 
 ```console
 $ ls -l /home