This commit adds the following
* the uucp user
* options for HylaFAX server to control startup and modems
* systemd services for HylaFAX server processes
including faxgettys for modems
* systemd services to maintain the HylaFAX spool area,
including cleanup with faxcron and faxqclean
* default configuration for all server processes
for a minimal working configuration
Some notes:
* HylaFAX configuration cannot be initialized with faxsetup
(as it would be common on other Linux distributions).
The hylafaxplus package contains a template spool area.
* Modems are controlled by faxgetty.
Send-only configuration (modems controlled by faxq)
is not supported by this configuration setup.
* To enable the service, one or more modems must be defined with
config.services.hylafax.modems .
* Sending mail *should* work:
HylaFAX will use whatever is in
config.services.mail.sendmailSetuidWrapper.program
unless overridden with the sendmailPath option.
* The admin has to create a hosts.hfaxd file somewhere
(e.g. in /etc) before enabling HylaFAX.
This file controls access to the server (see hosts.hfaxd(5) ).
Sadly, HylaFAX does not permit account-based access
control as is accepts connections via TCP only.
* Active fax polling should work; I can't test it.
* Passive fax polling is not supported by HylaFAX.
* Pager transmissions (with sendpage) are disabled by default.
I have never tested or used these.
* Incoming data/voice/"extern"al calls
won't be handled by default.
I have never tested or used these.
This allows one to add rules which change a packet's routing table:
iptables -t raw -I PREROUTING 1 -m set --match-set myset src -j MARK --set-mark 2
ip rule add fwmark 2 table 1 priority 1000
ip route add default dev wg0 table 1
to the beginning of raw table PREROUTING chain, and still have rpfilter.
This allows the user to add `wpa_supplicant` config options not yet supported by Nix without having to write the entire `wpa_supplicant.conf` file manually.
First change is to override the nm-dispatcher systemd service so that
it puts coreutils (wc/env/...) and iproute in PATH.
Second change is to make sure userscripts have the execute bit.
This reverts a change applied in PR #18491. When interfaces are
configured by DHCP (typical in a cloud environment), ordering after
network.target cause trouble to applications expecting some network to
be present on boot (for example, cloud-init is quite brittle when
network hasn't been configured for `cloud-init.service`) and on
shutdown (for example, collectd needs to flush metrics on shutdown).
When ordering after network.target, we ensure applications relying on
network.target won't have any network reachability on boot and
potentially on shutdown.
Therefore, I think ordering before network.target is better.
`ocserv` is a VPN server which follows the openconnect protocol
(https://github.com/openconnect/protocol). The packaging is slightly
inspired by the AUR version
(https://aur.archlinux.org/packages/ocserv/).
This patch initializes the package written in C, the man pages and a
module for a simple systemd unit to run the VPN server. The package
supports the following authentication methods for the server:
* `plain` (mostly username/password)
* `pam`
The third method (`radius`) is currently not supported since `nixpkgs`
misses a packaged client.
The module can be used like this:
``` nix
{
services.ocserv = {
enable = true;
config = ''
...
'';
};
}
```
The option `services.ocserv.config` is required on purpose to
ensure that nobody just enables the service and experiences unexpected
side-effects on the system. For a full reference, please refer to the
man pages, the online docs or the example value.
The docs recommend to simply use `nobody` as user, so no extra user has
been added to the internal user list. Instead a configuration like
this can be used:
```
run-as-user = nobody
run-as-group = nogroup
```
/cc @tenten8401
Fixes#42594
This reverts commit 095fe5b43d.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
Having socket-activated epmd means that there always be only a single
instance managed centrally. Because Erlang also starts it
automatically if not available, and in worst case scenario 'epmd' can
be started by some Erlang application running under systemd. And then
restarting this application unit will cause complete loss of names in
'epmd' (if other Erlang system are also installed on this host).
E.g. see at which lengths RabbitMQ goes to recover from such
situations:
7741b37b1e/src/rabbit_epmd_monitor.erl (L36)
Having the only one socket-activated epmd completely solves this
problem.
This allows non-privileged users to configure local DNS
entries by editing hosts files read by NetworkManager's dnsmasq
instance.
Cherry-picked from e6c3d5a507909c4e0c0a5013040684cce89c35ce and
5a566004a2b12c3d91bf0acdb704f1b40770c28f.
The deep merge caused all the options to be unset when generating docs, unless quagga was enabled.
Using imports, instead, properly allows the documentation to be generated.
