The current build of livebook does not work with the new [Livebook
Teams](https://livebook.dev/teams/) features. The problem can be observed by
running the current version of livebook, adding a new team and going to the team
page. The process will crash and the team page will show a 500 error.
The base of the problem is that the escript build method is not officially
supported. This commit changes the livebook package to use the `mix release`
workflow, which is also the one used to build the official Docker container.
Unfortunately, the binary built with `mix release` does not support command line
arguments like the `escript` binary does. Instead, users need to pass in most of
the configuration as environment variables, as documented
[here](https://hexdocs.pm/livebook/readme.html#environment-variables). As a
result, this commit also changes the Livebook service to reflect this new way of
configuring Livebook.
Finally, the Livebook release configuration specifically excludes the
ERTS (Erlang Runtime System), which means that the resulting release cannot run
without Erlang installed.
I have tested the results (both of the package and the service) locally.
It is probably a good idea to talk about it and leave it to release editors to decide how they want to present this.
Hardware OPAL based is interesting for certain companies with compliance constraints.
There were several modules, critically including NetworkManager, which
were not prepared for this change. Most of the change was good,
however. Let's bring back the dependency and change the assertion to a
warning for now.
doc: add figure definition to bespoke syntax reference
doc: add example definition to bespoke syntax reference
doc: add footnote definition to beskpoke syntax reference
The usage of footnotes in the manuals is not the one documented
in markdown-it-py: https://python-markdown.github.io/extensions/footnotes/
doc: add inline comment definition to beskpoke syntax reference
doc: add typographic replacements to beskpoke syntax reference
doc: Fix rendering of bespoke syntax reference
doc: remove references to DocBook in the NixOS manual
doc: add entry on lack of HTML support
doc: Minor improvement
doc: update typographic replacements entry in beskpoke syntax reference
doc: add link reference definitions to beskpoke syntax reference
doc: fix footnote definition in beskpoke syntax reference
doc: Minor improvements from code review
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Previously we required network-online.target for multi-user.target. This
has made a lot of people very angry and has been widely regarded as a
bad move (or at least, very nonstandard):
15d761a525 (commitcomment-128564097)
This was done because of fragile tests and services declaring
dependencies on multi-user.target when they meant network-online.target.
Let's rip off the bandaid and fix our tests.
This is introduced and enabled by default because the config syntax for
the exporter changed with release 0.23.0.
This should make the breaking config change obvious before services are
deployed with an incompatible old config.
The check is based on the check present in the blackbox-exporter module.
Closes#169733
The issue is that Nextcloud fails to start up after a GC because the
symlink from `override.config.php` is stale.
I'm relatively certain that this is not a bug in the Nix GC - that
would've popped up somewhere else already in the past years - and one of
the reporters seems to confirm that: when they restarted
`nextcloud-setup.service` after the issue appeared, an
`override.config.php` pointing to a different hash was there.
This hints that on a deploy `nextcloud-setup` wasn't restarted properly
and thus replacing the symlink update was missed. This is relatively
hard to trigger due to the nature of the bug unfortunately (you usually
keep system generations for a few weeks and you'll need to change the
configuration - or stdenv - to get a different `override.config.php`),
so getting pointers from folks who are affected is rather complicated.
So I decided to work around this by using systemd-tmpfiles which a lot
of other modules already utilize for this use-case. Now,
`override.config.php` and the directory structure aren't created by
`nextcloud-setup`, but by `systemd-tmpfiles`.
With that, the structure is guaranteed to exist
* on boot, since tmpfiles are always created/applied then
* on config activation, since this is done before services are
(re)started which covers the case for new installations and existing
ones.
Also, the recursive `chgrp` was used as transition tool when we switched
from `nginx` as owning group to a dedicated `nextcloud` group[1][2], but
this was several releases ago, so I don't consider this relevant
anymore.
[1] fd9eb16b24
[2] ca916e8cb3
