Default behavior is to continue executing the script even when one or
multiple steps fail. We want to abort early if any part of the
initialization fails to not run with a partially initialized state.
Default behavior also allows dereferencing non-existent variables,
potentially resulting in hard-to-find bugs.
On start, unicorn, sidekiq and other parts running ruby code emits
quite a few warnings similar to
/var/gitlab/state/config/application.rb:202: warning: already initialized constant Gitlab::Application::LOOSE_EE_APP_ASSETS
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/config/application.rb:202: warning: previous definition of LOOSE_EE_APP_ASSETS was here
/var/gitlab/state/lib/gitlab.rb:38: warning: already initialized constant Gitlab::COM_URL
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was here
This seems to be caused by the same ruby files being evaluated
multiple times due to the paths being different - sometimes they're
loaded using the direct path and sometimes through a symlink, due to
our split between config and package data. To fix this, we make sure
that the offending files in the state directory always reference the
store path, regardless of that being the real file or a symlink.
This reverts commit 2ee14c34ed.
This caused the initializers directory to be cleaned out while gitlab
was running in some instances. We clean out the directory on the
preStart stage already, so ensuring existance and permissions should
suffice.
Bumps `matrix-synapse` to version 1.4.0[1]. With this version the
following changes in the matrix-synapse module were needed:
* Removed `trusted_third_party_id_servers`: option is marked as deprecated
and ignored by matrix-synapse[2].
* Added `account_threepid_delegates` options as replacement for 3rdparty
server features[3].
* Added `redaction_retention_period` option to configure how long
redacted options should be kept in the database.
* Added `ma27` as maintainer for `matrix-synapse`.
Co-Authored-By: Notkea <pacien@users.noreply.github.com>
Co-authored-by: Maximilian Bosch <maximilian@mbosch.me>
[1] https://matrix.org/blog/2019/10/03/synapse-1-4-0-released
[2] https://github.com/matrix-org/synapse/pull/5875
[3] https://github.com/matrix-org/synapse/pull/5876
In fact, don't create them at all because Nix does that automatically.
Also remove modules/programs/shell.nix because everything it did is
now done automatically by Nix.
gitlab:db:configure prints the root user's password to stdout on
successful setup, which means it will be logged to the
journal. Silence this informational output. Errors are printed to
stderr and will thus still be let through.
The initializers directory is populated with files from the gitlab
distribution on start, but old files will be left in the state folder
even if they're removed from the distribution, which can lead to
startup failures. Fix this by always purging the directory on start
before populating it.
Since the preStart script is no longer running in privileged mode, we
reassign the files in the state directory and its config subdirectory
to the user we're running as. This is done by splitting the preStart
script into a privileged and an unprivileged part where the privileged
part does the reassignment.
Also, delete the database.yml symlink if it exists, since we want to
create a real file in its place.
Fixes#68696.
Since version 2.3 (https://github.com/NixOS/nix/pull/2949 which was
cherry-picked to master) Nix issues a warning when --no-net wasn't
passed and there is no network interface. This commit adds the --no-net
flag to the nix.conf check such that no warning is issued.
Make sure that we don't create a database if we're not going to
connect to it. Also, fix the assertion that usernames be equal to only
trig when peer authentication is used (databaseHost == "").
config.services.postgresql.package is only defined when the postgresql
service is activated, which means we fail to evaluate when
databaseCreateLocally == false. Fix this by using the default
postgresql package when the postgresql service is disabled.
The state path now, since the transition from initialization in
preStart to using systemd-tmpfiles, has the following restriction: no
parent directory can be owned by any other user than root or the user
specified in services.gitlab.user. This is a potentially breaking
change and the cause of the error isn't immediately obvious, so
document it both in the release notes and statePath description.
Adds the ability to make any parameter specified in extraConfig secret
by defining it an attrset containing the attr _secret, which in turn
is a path to a file containing the actual secret.
Use the postgresql module to provision a local db (if
databaseCreateLocally is true) instead of doing this locally.
Switch to using the local unix socket for db connections by default;
this is needed since dbs created by the postgresql module only support
peer authentication.
Instead of running the rake tasks db:schema:load, db:migrate and
db:seed_fu, run gitlab:db:configure, which in turn runs these tasks
when needed.
Solves issue #53852 for gitlab.
Add support for storing secrets in files outside the nix store, since
files in the nix store are world-readable and secrets therefore can't
be stored safely there.
The old string options are kept, since they can potentially be handy
for testing purposes, but their descriptions now state that they
shouldn't be used in production. The manual section is updated to use
the file options rather than the string options and the tests now test
both.
Since https://github.com/NixOS/nixpkgs/pull/61321, local-fs.target is
part of sysinit.target again, meaning units without
DefaultDependencies=no will automatically depend on it, and the manual
set dependencies can be dropped.
For some reason it doesn't seem to load things in the cache directory
properly without this slash.
Looks like this regression may have been introduced in:
commit 19851ec1fc
nixos/zoneminder: Fix nginx config check
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Peter Hoeg <peter@hoeg.com>
Signed-off-by: William Casarin <jb55@jb55.com>
We might be inside a NixOS container on a non-NixOS host, so instead of not
running at all inside a container, check if the nix-daemon socket is writable as
it will tell us if the store is managed from here or outside.
Fixes#63578
This commit adds new configuration options to the Lidarr module that
allows configuration of the user and group that Lidarr runs as; and to
open the firewall for the Lidarr port.
There are many support questions when people add a new binary cache
and they suddenly lose nixos substitutions.
Most of the users want to keep that, so we're doing a breaking change.
Previously to disable all binary caches one had to do:
nix.binaryCache = [];
Now the same is possible via:
nix.binaryCache = lib.mkForce;
following up #59148
I forgot the default case of the architectures which do not have minor brothers whose code they can run ("westmere" or any of of AMD)
Previously this module precluded use of storage backends other than
`filesystem`. It is now possible to configure another storage backend
manually by setting `services.dockerRegistry.storagePath` to `null` and
configuring the other backend via `extraConfig`.
* zoneminder: fix initial database creation
Move initialDatabases directive from the 'ensureUsers' scope to the correct outer 'mysql' one.
* zoneminder: Fix mysql username to match unix username
When database.createLocally is used, a mysql user is created with the ensureUsers directive.
It ensures that the unix user with the name provided exists and can connect to MySQL through socket.
Thus, the MySQL username used by php/perl scripts must match the unix user owning the server PID.
This patch sets the default mysql user to 'zoneminder' instead of 'zmuser'.
I think the bepasty nixos service has been broken since c539c02, since
bepasty changed from using python2.7 to python3.7. This updates the
nixos module to refer to the matching python version.
PlexPy was renamed to Tautulli.
This renames the module as well as the application accordingly.
Aliases are kept for backwards compatibility.
# Conflicts:
# nixos/modules/services/misc/tautulli.nix
* pr-55320:
nixos/release-notes: mention breaking changes with matrix-synapse update
nixos/matrix-synapse: reload service with SIGHUP
nixos/tests/matrix-synapse: generate ca and certificates
nixos/matrix-synapse: use python to launch synapse
pythonPackages.pymacaroons-pynacl: remove unmaintained fork
matrix-synapse: 0.34.1.1 -> 0.99.0
pythonPackages.pymacaroons: init at 0.13.0
* redmine: 3.4.8 -> 4.0.1
* nixos/redmine: update nixos test to run against both redmine 3.x and 4.x series
* nixos/redmine: default new installs from 19.03 onward to redmine 4.x series, while keeping existing installs on redmine 3.x series
* nixos/redmine: add comment about default redmine package to 19.03 release notes
* redmine: add aandersea as a maintainer
Although this can be added to `extraOptions` I figured that it makes
sense to add an option to explicitly promote this feature in our
documentation since most of the self-hosted gitea instances won't be
intended for common use I guess.
Also added a notice that this should be added after the initial deploy
as you have to register yourself using that feature unless the install
wizard is used.
These days build systems are more robust w.r.t. to concurrency.
Most users will have at least two cores in their machines.
Therefore I suggest to increase the number of cores used for building.
fixes#50376
hass will ignore the standard SIGTERM sent by systemd during stop/restart and we
then have to wait for the timeout after which systemd will forcefully kill the
process.
If instead if we send SIGINT, hass will shut down nicely.
There are many issues reported upstream about the inability to shut down/restart
and it is *supposed* to work with SIGTERM but doesn't.
- added package option to specify which version of redmine
- added themes option back in to allow specifying redmine themes
- added plugins option back in to allow specifying redmine plugins
- added database.socket option to allow mysql unix socket authentication
- added port option to allow specifying the port rails runs on
- cleaned up Gemfile so it is much less hacky
- switched to ruby version 2.4 by default as suggested by documentation http://www.redmine.org/projects/redmine/wiki/redmineinstall#Installing-Redmine
- fixed an annoyance (bug) in the service causing recursive symlinks
- fixed ownership bug on log files generated by redmine
- updates reflecting renames in nixos options
- added a nixos test
Previously you either had to set the setuid bit yourself or workaround
`isSystemUser = true` (for a loginable shell) to access the weechat
screen.
`programs.screen` shouldn't do this by default to avoid taking too much
assumptions about the setup, however `services.weechat` explicitly
requires tihs.
See #45728
environment.sessionVariables cannot refer to the values of env vars,
and as a result this has caused problems in a variety of scenarios.
One use for these is that they're injected into /etc/profile,
elewhere these are used to populate an 'envfile' for pam
(`pam 5 pam_env.conf`) which mentions use of HOME being
potentially problematic.
Anyway if the goal is to make things easier for users,
simply do the NIX_PATH modification as extraInit.
This fixes the annoying problems generated by the current approach
(#40165 and others) while hopefully serving the original goal.
One way to check if things are borked is to try:
$ sudo env | grep NIX_PATH
Which (before this change) prints NIX_PATH variable with
an unexpanded $HOME in the value.
-------
This does mean the following won't contain user channels for 'will':
$ sudo -u will nix-instantiate --eval -E builtins.nixPath
However AFAICT currently they won't be present either,
due to unescaped $HOME. Unsure if similar situation for other users
of sessionVariables (not sudo) work with current situation
(if they exist they will regress after this change AFAIK).
Introduced by 0f3b89bbed.
If services.nixosManual.showManual is enabled and
documentation.nixos.enable is not, there is no
config.system.build.manual available, so evaluation fails. For example
this is the case for the installer tests.
There is however an assertion which should catch exactly this, but it
isn't thrown because the usage of config.system.build.manual is
evaluated earlier than the assertions.
So I split the assertion off into a separate mkIf to make sure it is
shown appropriately and also fixed the installation-device profile to
enable documentation.nixos.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @oxij
This reverts commit 67c8c49177.
'nix run nixos.firefox' is *not* supposed to work - the Nix 2.x
interface attempts to standardize on nixpkgs.*, to get rid of the
nixos/nixpkgs confusion that existed with the channels interface. So
let's not bring that confusion back.
Because when I see "config.system.build.manual.manual" after I forgot
what it means I ask "Why do I need that second `.manual` there again?".
Doesn't happen with `config.system.build.manual.manualHTML`.
This adds several improvements the previously introduced
`services.weechat` module:
* Dropped `services.weechat.init` as the initialization script can now
be done on package-level since 2af41719bc using the `configure`
function.
* Added `sessionName` option to explicitly configure a name for the
`screen` session (by default: weechat-screen).
* Added `binary` option to configure the binary name (e.g.
`weechat-headless`).
* Added docs regarding `screen` session and `weechat.service`.
This fixes a regression introduced in commit
700e21d6da
nix needs ssh on path for the SSH substituter functionality,
not only the distributed builds functionality.
Signed-off-by: Niklas Hambüchen <mail@nh2.me>
This is the semantics as understood by `xdg-open`. Using these semantics
on a non-colon-separated variable works because it acts as if it was a
one element long list.
This fixes an issue where it would try to exec
`google-chrome-beta:google-chrome:chromium:firefox` on a system
configured with these semantics in mind.
This prevents issues when gitea adds new locales etc. And if they
change locale values in future versions. Or if you rollback to a
previous version of gitea it might be a good idea to use the previous
locale files.
