Make the config initialization script run in gitlab.service's PreStart
section into two new services, `gitlab-config.service` and
`gitlab-db-config.service`. Other services can then depend on the
config scripts they need instead of unnecessarily depending on
`gitlab.service`. This makes the reason for the configured service
dependencies much clearer and should also reduce the restart time of
the `gitlab` service quite a lot, when triggered manually.
Also, set up stricter service dependencies, using `bindsTo`, to ensure
that if a service fails or is stopped, its dependants are also
stopped. For example, if we're using the `postgresql` service and it's
stopped, `gitlab.service` and `gitlab-sidekiq.service`, which depend on
it to function, should also be stopped.
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.
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.
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?
The `--apis=` command line parameter passed to Jitsi Videobridge is
required to monitor a Jitsi Meet instance for example via the prometheus
exporter [jitsiexporter](https://git.xsfx.dev/prometheus/jitsiexporter).
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
Account for the fact that, when creating a lua package without the
"withPackages" helper, we dont get an extra "lua" attribute in the
package.
Therefore we need to distinguish between the "withPackages" case and the
direct ( or "empty" ) lua package.
For example with this nixos config:
```nix
{
services.httpd = {
enable = true;
package = pkgs.apacheHttpd.override {
luaSupport = true;
lua5 = pkgs.lua5_3.withPackages (ps: with ps; [ luafilesystem ] );
};
};
}
```
Here we say that we want to have apache to use a lua, packaged with the
`luafilesystem` module so that we can `require` that in scripts to
render http responses. There, the set that gets assigned to `lua5 ` does
not have a `luaversion` attribute, rather it has a `lua` attribute
wherein lies a `luaversion` attribute. If we dont package additional
modules, then we dont have that `lua` attribute in between and rather
directly have to use `luaversion` directly.
Fixes redirection after signing in when you use a single oauth2_proxy
instance for multiple domains.
X-Auth-Request-Redirect header is used to decide which URL to redirect
to after signing in. Specifying `request_uri` is enough in case you
need to redirect to the same domain that serves oauth2 callback
endpoint, but with multiple domains the you should include the scheme
and the host.
Thinkfan underwent some major changes and the config file
is now based on YAML. This commit contains a number of changes:
- rewrite the module to output the new format;
- add a `settings` option, following RFC 0042[1];
- add fancy type-checking for the most critical options
- use upstream systemd units (which fix the resume issue)
[1]: https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md
This is necessary for Librespot, which is spawned by snapserver in the
same cgroup. Librespot requires querying local ip links and addresses
for MDNS (Zeroconf/Avahi), and does so through NETLINK interface.
* Add 'librespot' (new name for 'spotify'), 'alsa', 'tcp'.
* Add a warning about the spotify -> librespot rename.
* Fix the deprecated example `mode = "listen"` for type 'pipe'.
* Update the tests to include a straightforward 'tcp' test.
