A function is more appropriate for this use. See
http://mywiki.wooledge.org/BashFAQ/050 for reference.
Also, we don't need to run the service as root: since we essentially
run all commands as `services.postgresql.superUser` anyway, the whole
service can just run as that user instead.
Change the default SMTP port to `25`, to better match the default
address `localhost`. This gets rid of some error outputs in the test,
where it fails to connect to localhost:465.
Also, don't enable postfix by default unless it's actually useful to
us.
This removes all the subdirectories in `config` on start.
From one version of GitLab to the next, the files in the `config`
directory changes. Since we're only overwriting the existing files
with ones from the repo, cruft sometimes gets left behind,
occationally causing issues.
Ideally, all configuration put in the `config` directory is declared
by NixOS options and we could just remove the whole directory on
start, but I'm not sure if that's the case. It would also require a
little bit of additional rework and testing. The subdirectories,
however, should seldom contain user configuration and the ones that
frequently does, `initializers`, is already removed on start.
ChangeLog: https://nextcloud.com/changelog/#latest21
* Packaged 21.0.0, test-deployed it to my personal instance and tested
the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file
management).
* Bumped the default version for unstable/21.05 to `nextcloud21`. Since
`nextcloud20` was added after the release of 20.09 (and thus the
default on 20.09 is still `nextcloud19`), it's now needed to upgrade
across two majors.
This is not a problem though since it's possible to upgrade to v20 on
20.09 already and if not, the module will guard the administrator
through the upgrade with eval warnings as it's the case since 20.03.
* Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
This allows Plymouth to show the “NixOS 21.03” label under the logo at
startup like it already does at shutdown.
Fixes#59992.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
It's a dull and boring day, it's cold outside and I'm stuck at home: let
me tell you the story of systemd-vconsole-setup.
In the beginnings of NixOS[1], systemd-vconsole-setup was a powerful
sysinit.target unit, installed and running at boot to set up fonts
keyboard layouts and even colors of the virtual consoles. If needed, the
service would also be restarted after a configuration change, consoles
were happy and everything was good, well, almost.
Since the service had no way to specify the dependency "ttys are ready",
modesetting could sometimes happen *after* systemd-vconsole-setup had
started, leaving the console in a broken state. So abbradar worked
around that by putting a systemd-udev-settle `After=`.
In the meanwhile, probably realizing their mistake, systemd added a
shiny udev rule to start the systemd-udev-settle at the right time[2].
However, the rule bypassed systemd by directly running the binary
`systemd-udev-settle`, and the service - though still installed - fell
into disuse.
Two years would pass before a good samaritan, seeing the poor jobless
systemd-udev-settle service, decided to give it the coup de grâs[3] by
unlisting it from the installed units.
This, combined with another bug, caused quite a commotion[4] in NixOS;
to see why remember the fact that `WantedBy=` in upstream units doesn't
work[5], so it had to be added manually in cc542110, but while systemd
removed it, the NixOS unit continued to install and restart the service,
making a lot of fuss when switching configuration.
After at least thee different tentative fixes, deedrah realised[6] what
the root cause was and fpletz put the final nail[7] in the coffin of
systemd-udev-settle. The service would never see the light of a boot
again, NixOS would not restart it all the time but thanks to udev
consoles would still get their pretty fonts and playful colors.
The En..
..no, wait! You should ask what came of systemd-udev-settle, first.
And why is the service even around if udev is doing all the work?
Udev-settle, like the deceitful snake that he is, laid hidden for years.
He looks innocuous doesn't it? A little hack. Only until it leaves his
den and a poor user[8] drops dead. Obviously, it serves no purpose, as
the service is not part of the boot process anymore, so let's remove it
for good!
About the service, it may not be useful at boot, but it can be started
to pick up changes in vconsole.conf and set the consoles accordingly.
But wait, this doesn't work anymore: the service is never started at
boot (remember f76d2aa6), so switch-to-configuration.pl will not restart
it. Fortunately it can be repaired: here I install a new unit which
does *nothing* on start, but restarts the real service when reloaded.
This perfectly reproduces the original behavior, hopefully without the
original bugs too.
The End?
[1]: cc54211069
[2]: f6ba8671d8 (diff-84849fddcef81458f69725dc18c6614aade5c4f41a032b6908ebcf1ee6740636)
[3]: 8125e8d38e
[4]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470
[5]: https://github.com/NixOS/nixpkgs/issues/81138
[6]: https://web.archive.org/web/20180603130107/https://github.com/NixOS/nixpkgs/issues/22470#issuecomment-330930456
[7]: f76d2aa6e3
[8]: https://github.com/NixOS/nixpkgs/issues/107341
Renaming an interface must be done in stage-1: otherwise udev will
report the interface as ready and network daemons (networkd, dhcpcd,
etc.) will bring it up. Once up the interface can't be changed and the
renaming will fail.
Note: link files are read directly by udev, so they can be used even
without networkd enabled.
Say this 10 times so I don't forget:
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
I'm sorry guys.
It was introduced in c10fe14 but removed in c4f910f.
It remained such that people with older generations in their boot
entries could still boot those. Given that the parameter hasn't had any
use in quite some years, it seems safe to remove now.
Fixes#60184
4255954d97 set the StateDirectory to 0750,
but nginx wasn't in the Mastodon group. This commit also deletes a line,
that probably was intended to serve this purpose, but makes no sense.
Why should the Mastodon user be added as an extraGroup to the nginx
user?
Ensure that the HyperV keyboard driver is available in the early
stages of the boot process. This allows the user to enter a disk
encryption passphrase or repair a boot problem in an interactive
shell.
