Without fcrontab being setuid, every attempt by an user in the fcron
group to edit their own crontab (via `fcrontab -e`) results in the
following error:
```
2018-05-06 11:29:07 ERROR could not change euid to 273: Operation not permitted
2018-05-06 11:29:07 ERROR fcron child aborted: this does not affect the main fcron daemon, but this may prevent a job from being run or an email from being sent.
```
Adding setuid by hand has resolved this issue and aligns with the way
fcrontab is installed on other distributions.
"batch" is a shell script so invoking it via setuid wrapper never worked
anyway. (The kernel drops perms on executables with shebang.) A previous
nixpkgs commit made "batch" invoke the NixOS setuid "at" wrapper to gain
needed privileges.
Thanks to @yesbox for noticing.
The rationale for disabling this is: 1) systemd timers are better; 2)
it gets rid of one usually unnecessary process, which makes containers
more light-weight.
Note that cron is still enabled if services.cron.systemCronJobs is
non-empty, so this only matters if you have no declarative cron jobs
but do have user cron jobs.
Currently the module hardcodes the systemd service user to "marathon".
With this change one would not need to create an extra systemd config to
override the user.
So why would one need to override the Marathon user? Some apps require
root access to run. You can't run those with Marathon unless you
override the default user to root. Marathon also provides a
`--mesos_user` command line flag which allows you to run apps using
arbitrary users. You need to run the framework as root to enable this
functionality.
Update chronos default port to match the one documented on
their website (http://airbnb.github.io/chronos). The one in
their repo (the current one) clashes with the marathon documented
one.
This allows you to configure extra files that should be appended to your
crontab. Implemented by writing to /etc/crontab when the cron service starts.
Would be nicer to use a cron that supports /etc/cron.d but that would require
us to patch vixie-cron.
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
That is, you can say
security.pam.services.sshd = { options... };
instead of
security.pam.services = [ { name = "sshd"; options... } ];
making it easier to override PAM settings from other modules.