Wordpress bundles some non-essential plugins and themes, then pesters
users to upgrade them. As we make the whole webroot readonly, it is
not possible to trivially delete them. Instead we should have users
explicitly install plugins via the existing nixos module.
this converts meta.doc into an md pointer, not an xml pointer. since we
no longer need xml for manual chapters we can also remove support for
manual chapters from md-to-db.sh
since pandoc converts smart quotes to docbook quote elements and our
nixos-render-docs does not we lose this distinction in the rendered
output. that's probably not that bad, our stylesheet didn't make use of
this anyway (and pre-23.05 versions of the chapters didn't use quote
elements either).
also updates the nixpkgs manual to clarify that option docs support all
extensions (although it doesn't support headings at all, so heading
anchors don't work by extension).
In an effort to better encode version strings and use descriptive pnames
that do not conflict with top level pkgs, we currently use
wordpress-${type}-${pname} for pname. This is good for the nix store,
but when we synthesize the wordpress derivation in our module, we reuse
this pname for the output directory.
Internally wordpress can handle this fine, since plugins must register
via php, not directory. Unfortunately, many plugins like civicrm and
wpforms-lite are designed to rely upon the name of their install
directory for homing or discovery.
As such, we should follow both the upstream convention and
services.nextcloud.extraApps and use an attribute set for these options.
This allows us to not have to deal with the implementation details of
plugins and themes, which differ from official and third party, but also
give users the option to override the install location. The only issue
is that it breaks the current api.
`shell_interact()` is currently not nice to use. If you try to cancel
the socat process, it will also break the nixos test. Furthermore
ptpython creates it's own terminal that subprocesses are running in,
which breaks some of the terminal features of socat.
Hence this commit extends `shell_interact` to allow also to connect to
arbitrary servers i.e. tcp servers started by socat.
as far as we can tell nixos has only ever had a total of one olink, and
currently has no olinks at all. we can't currently represent olinks in
markdown docs, and if we re-add support for cross-document links they
will take a different form (and not use docbook, which will have to be
phased out before we re-add anything).
the olinkdb is thus unused and takes 10 seconds on our machine to build,
holding up the rest of the manual for no benefit.
Without this commit, unsetting any of the `services.kubo.settings` options does not reset the value back to the default. This commit gets rid of this statefulness.
This is achieved by generating the default config, applying the user specified config options to it and then patching the `Identity` and `Pinning` config options from the old config back in. This new config is then applied using `ipfs config replace`.
The only remaining stateful parts of the config are the `Identity` and `Pinning.RemoteServices` settings as those can't be changed with `ipfs config replace`. `Pinning.RemoteServices` also contains secrets that shouldn't be in the Nix store. Setting these options wasn't possible before as it would result in an error when the daemon tried to start. I added some assertions to guard against this case.
Trivial conflict in release notes, except that the xml/docbook parts
are horrible for (semi-)automatic conflict resolution.
Fortunately that's generated anyway.
Adds a new option to the virtualisation modules that enables specifying
explicitly named network interfaces in QEMU VMs. The existing
`virtualisation.vlans` is still supported for cases where the name of
the network interface is irrelevant.
`autosuspend` is a daemon that periodically runs user-defined checks to
verify whether the system should be suspended. It's already available
in nixpkgs. This adds a NixOS module which starts the daemon as a
systemd service.
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
following the plan in https://github.com/NixOS/nixpkgs/pull/189318#discussion_r961764451
also adds an activation script to print the warning during activation
instead of during build, otherwise folks using the new CLI that hides
build logs by default might never see the warning.
This commit fixes a papercut in nixos-rebuild where people wanting to
switch to a specialisation (or test one) were forced to manually figure
out the specialisation's path and run its activation script - since now,
there's a dedicated option to do just that.
This is a backwards-compatible change which doesn't affect the existing
behavior, which - to be fair - might still be considered sus by some
people, the painful scenario here being:
- you boot into specialisation `foo`,
- you run `nixos-rebuild switch`,
- whoops, you're no longer at specialisation `foo`, but you're rather
brought back to the base system.
(it's especially painful for cases where specialisation is used to load
extra drivers, e.g. Nvidia, since then launching `nixos-rebuild switch`,
while forgetting that you're inside a specialisation, can cause some
parts of your system to get accidentally unloaded.)
I've tried to mitigate that by improving specialisations so that they
create a dedicated file somewhere in `/run/current-system` containing
the specialisation's name (which `nixos-rebuild` could then use as the
default value for `--specialisation`), but I haven't been able to come
up with anything working (plus it would be a breaking change then).
Closes https://github.com/NixOS/nixpkgs/issues/174065
* Will make it so that GHC.Paths's docdir NIX_GHC_DOCDIR points to an
actual directory.
* Documentation of all packages in the environment is available in
`$out/share/doc`.
This has previously been attempted in #76842 and reverted in #77442,
since documentation can collide when the libraries wouldn't (thanks to
the hash in the lib filename). `symlinkJoin` allows collision, so this
solution should be akin to #77523 (minus `buildEnv`, one step at a
time). `installDocumentation = false` restores the old behavior.
Collision in the documentation only happen if the dependency closure of
the given packages has more than one different derivation for the same
library of the very same version. I'm personally inclined not to claim
that our infrastructure does anything sensible in this case.
Additionally, the documentation is likely largely the same in such
cases (unless it is heavily patched).
Resolves#150666.
Resolves#76837.
Closes#150968.
Closes#77523.
This is a followup of #148921, to allow local builds when
`--target-host` is used again. It also documents the change in
behavior, regarding the specialty of the `localhost` value.
By removing the special handling of an empty `buildHost` and non empty
`targetHost`, this change also slightly alters the behavior of
`nixos-rebuild`.
Originally by specifying `--target-host target --build-host ""`, the
now removed special case would transform those arguments to
`--target-host target --build-host target`.
Now the empty `--build-host` would result in a local build.
Added the RFC42-style added the posibility to use
`services.dokuwiki.sites.<name>.settings' instead of passing a plain
string to `<name>.extraConfig`. ´<name>.pluginsConfig` now also accepts
structured configuration.
Move the manpage-to-URL mapping to `doc/manpage-urls.json` so that we can
reuse that file elsewhere, and generate the `link-manpages.lua` filter from
that file.
Also modify the Pandoc filter so that it doesn't wrap manpages that are
already inside a link.
Keeping a Lua filter is essential for speed: a Python filter would
increase the runtime `md-to-db.sh` from ~20s to ~30s (but Python is not
to blame; marshalling Pandoc types to and from JSON is a costly operation).
Parsing in Lua seems tedious, so I went with the Nix way.
There should be no reason to use this package as it's a remnant of
non-modular X. Chances are you do not want every single library it
used to pull in:
freetype fontconfig xorg.xorgproto xorg.libX11 xorg.libXt
xorg.libXft xorg.libXext xorg.libSM xorg.libICE
Just pick the ones you really need instead.
`nixpkgs` does not have any users of `xlibsWrapper`.
Closes: https://github.com/NixOS/nixpkgs/issues/194054
- Extensive documentation in NixOS manual
- Deterministic mode that fixes various identifiers relative to disk
partitions and filesystems in ext4 case
- UEFI variable recording
This commit upgrades headscale to the newest version, 0.17.0 and updates
the module with the current breaking config changes.
In addition, the module is rewritten to conform with RFC0042 to try to
prevent some drift between the module and the upstream.
A new maintainer, Misterio77, is added as maintainer.
Signed-off-by: Kristoffer Dalby <kristoffer@tailscale.com>
Co-authored-by: Gabriel Fontes <hi@m7.rs>
Co-authored-by: Geoffrey Huntley <ghuntley@ghuntley.com>
* minio: add legacy fs version 2022-10-24T18-35-07Z
This allows users to migrate their data to versions that already removed
support for the legacy fs backend.
* Update nixos/doc/manual/release-notes/rl-2305.section.md
Co-authored-by: Florian Klink <flokli@flokli.de>
Document the `linux.override` way first, then `linuxManualConfig`.
Add a `linux.configEnv` passthru attribute for quickly getting a
`make nconfig`-ready shell.
Make "$out" more conformant to the bin/ lib/ share/ hirarchy
instead of messing up the user profile
with stuff like cmake/ config/ macros/ icons/ js/ tutorials/ ...
In this layout,
* `tutorials` is now under `share/doc/ROOT/tutorial`
* `cmake`, `font`, `icons`, `js` and `macro` is now under `share/root`
* `Makefile.comp` and `Makefile.config` in now under `etc/root`.
When running nixos-rebuild -I, the man page just said "-I path" which could be interpreted as
"just a path to nixpkgs", which in fact it actually has the same meaning as NIX_PATH.
This is now made clear in the manual, so that when grepping "-I" and "NIX_PATH" one quickly finds
the format of the option.
I don't know how to link to the "nix manual" as stated in the docbook, so I left that as it is.
Additionally, it wasn't clear to me how to actually build the man pages and view the changes I made.
That's now in the contributing-to-this-manual.chapter.md.
Avoids confusion: `vim-full`'s build-time features are configurable, but both
`vim` and `vim-full` are *customizable* (in the sense of user configuration).
I'm well aware that this issue is currently under discussion[1] and that
these things may change. Also, please don't misinterpret this as an
attempt to end the discussion.
This topic made it obvious that people are surprised by the way this
issue is handled and only finding out about this unwritten rule because
of asking is not a good state IMHO, so I decided to document the
following things:
* Right now we drop kernels as soon as they get out of maintenance (LTS
kernels even before the next stable NixOS that will exceed their
lifespan).
* The `latestCompatibleLinuxPackages` attribute from ZFS isn't
monotonic since latest only refers to the latest supported kernel.
* In fact `latestCompatibleLinuxPackages` doesn't seem to be documented
at all in the manual, so I also did that.
[1] https://discourse.nixos.org/t/aggressive-kernel-removal-on-eol-in-nixos/23097
Adds a new option for backup jobs `inhibitsSleep` which prevents
the system from going to sleep while a backup is in progress.
Uses `systemd-inhibit`, which holds a "lock" that prevents the
system from sleeping while the process it invokes is running.
This did require wrapping the existing backup script using
`writeShellScript` so that it could be run by `systemd-inhibit`.
When using the declarative shared folder configuration for resilio sync
it is now possible to pass a path from which to read the secret should
be read at runtime. The path will not be added to the nix store.
The 'secret' parameter to specify the secret directly is still
supported. This option will still store the secret in the nix store.
This commit follows the pattern described in this issue, for upstream
programs that do not provide support for setting a password using a
file: https://github.com/NixOS/nixpkgs/issues/24288
Add a section on ordering option definitions.
Also mention `mkDefault` in the section on `mkOverride`.
Clarify the code a bit by renaming `defaultPriority` to
`defaultOverridePriority` and introducing `defaultOrderPriority`.
The placement of this option under `nix` was misleading, as it is not
configuration of the Nix daemon, but rather configuration of the NixOS
boot process and how it mounts the Nix store. As such, make it an option
of `boot` to clarify what it actually affects, and imply that it will
only take effect on a reboot.
Since it no longer has the context of nix, adjust the name to include
it.
Packages built with `haskellPackages.callHackage` won't be rebuilt when
updating `all-cabal-hashes`.
The removed comment was keeping a reference to the `cabal2nix` call,
which itself depends on `all-cabal-hashes`, in order to keep this file
during a garbage collection.
The tradeoff is between:
- The current behavior: a mass rebuild, any change of `all-cabal-hashes`
triggers a rebuild of all the packages built with `callHackage` and
packages which depend on them. This can take hours, and may happen
after a "small" unrelated change (i.e. an user is bumping
`all-cabal-hashes` in order to use a new package from hackage). It
also have global impacts in a project (long rebuild in CI, new entries
in cache, developers need to fetch the new entries, ...). In this
context, `cabal2nix` entries are not garbage collected.
- The new behavior: No mass rebuild, but `cabal2nix` derivations need to
be recomputed after a garbage collection. This is usually fast (a few
seconds by call), linear with the number of calls and should not
happen a lot (i.e. users are not garbage collecting everyday).
See https://github.com/NixOS/nixpkgs/issues/194751 for details.
This also removes automatic enablement/mounting of instance store swap
devices and ext3 filesystems. This behaviour is strongly opinionated
and shouldn't be enabled by default.
The unionfs behaviour never took effect anyway, because the AMI
manifest path only exists for instance store-backed AMIs, which have
not been supported by nixpkgs since
84742e2293 (2019).
Enabling Wayland support by default prevents use of XWayland on Wayland
systems, while correctly falling back to X11 when Wayland is
unavailable in the current session.
With the current packaging many people unnecessarily rely on the
`firefox` attribute, which is suggested by nixos-generate-config, which
in turn makes their Firefox use XWayland, when it shouldn't, which
causes bugs with GNOME on Wayland:
https://discourse.nixos.org/t/firefox-all-black-when-first-launched-after-login/21143
Using the Wayland-enabled Firefox was tested on pure X11 systems by
contributors on the #nix-mozilla:nixos.org room and we are confident
this change will not cause severe regressions.
Even better, people can now toggle `MOZ_ENABLE_WAYLAND=<0|1>` in their
environment to override this decision, should they feel the need to do
so.
The `sparseCheckout` argument allows the user to specify directories or
patterns of files, which Git uses to filter files it should check-out.
Git expects a multi-line string on stdin ("newline-delimited list", see
`git-sparse-checkout(1)`), but within nixpkgs it is more consistent to
use a list of strings instead. The list elements are joined to a
multi-line string only before passing it to the builder script.
A deprecation warning is emitted if a (multi-line) string is passed to
`sparseCheckout`, but for the time being it is still accepted.
The nixos-generate-config command mentioned in the manual fails with error:
nixos-generate-config: no need to specify `/` with `--root`, it is the default
This was introduced in 611b8c4472
(#161034). Now, the command should be called without any arguments.
Relative paths are interpreted relative to the working directory, which
is currently unset and thus defaults to `/`. However we want to change
the working directory in a future release such that relative paths are
interpreted relative to `/var/lib/syncthing`.
Upon testing the change itself I realized that it doesn't build properly
because
* the `pname` of a php extension is `php-<name>`, not `<name>`.
* calling the extension `openssl-legacy` resulted in PHP trying to compile
`ext/openssl-legacy` which broke since it doesn't exist:
source root is php-8.1.12
setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c
patching sources
cdToExtensionRootPhase
/nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory
I didn't encounter that one before because I was mostly interested in
having a sane behavior for everyone not using this "feature" and the
documentation around this. My findings about the behavior with turning
openssl1.1 on/off are still valid because I tested this on `master` with
manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`.
To work around the issue I had to slightly modify the extension
build-system for PHP:
* The attribute `extensionName` is now relevant to determine the output
paths (e.g. `lib/openssl.so`). This is not a behavioral change for
existing extensions because then `extensionName==name`.
However when specifying `extName` in `php-packages.nix` this value is
overridden and it is made sure that the extension called `extName` NOT
`name` (i.e. `openssl` vs `openssl-legacy`) is built and installed.
The `name` still has to be kept to keep the legacy openssl available
as `php.extensions.openssl-legacy`.
Additionally I implemented a small VM test to check the behavior with
server-side encryption:
* For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix`
it's checked that OpenSSL 3 is used). With that the "default"
behavior of the module is checked.
* It is ensured that the PHP interpreter for Nextcloud's php-fpm
actually loads the correct openssl extension.
* It is tested that (encrypted) files remain usable when (temporarily)
installing OpenSSL3 (of course then they're not decryptable, but on a
rollback that should still be possible).
Finally, a few more documentation changes:
* I also mentioned the issue in `nextcloud.xml` to make sure the issue
is at least mentioned in the manual section about Nextcloud. Not too
much detail here, but the relevant option `enableBrokenCiphersForSSE`
is referenced.
* I fixed a few minor wording issues to also give the full context
(we're talking about Nextcloud; we're talking about the PHP extension
**only**; please check if you really need this even though it's
enabled by default).
This is because I felt that sometimes it might be hard to understand
what's going on when e.g. an eval-warning appears without telling where
exactly it comes from.
* s/NextCloud/Nextcloud/g
* `enableBrokenCiphersForSSE` should be enabled by default for any NixOS
installation from before 22.11 to make sure existing installations
don't run into the issue. Not the other way round.
* Update release notes to reflect on that.
* Improve wording of the warning a bit: explain which option to change
to get rid of it.
* Ensure that basic tests w/o `enableBrokenCiphersForSSE` run with
OpenSSL 3.
Allow building other than Legacy-BIOS-only Proxmox images.
Default is unchanged.
To build UEFI proxmox image use:
proxmox.qemuConf.bios = "ovmf";
(default is "seabios")
To build image bootable using both "seabios" and "ovmf" use:
partitionTableType = "hybrid";
BIOS can be switched in Proxmox between "seabios" and "ovmf" and VM still boots.
(GRUB2-only, systemd-boot does not boot under "seabios")
To build systemd-boot UEFI image:
proxmox.qemuConf.bios = "ovmf";
boot.loader.systemd-boot.enable = true;
Support will be dropped on 01 Jan 2023[1]. Normally we'd keep it around
until then, but considering that it's an LTS kernel it may be better to
do it before 22.11 to make sure there are no unpleasant surprises.
Closes#199933
[1] https://endoflife.date/linux
Percona Server for MySQL 5.6 is no more maintained due to the EOL of MySQL 5.6.
See https://www.percona.com/downloads/Percona-Server-5.6/LATEST/.
A bit hard to list all the potential security issues affecting it but CVE-2021-27928
should be one of them.
- Update download URLs
- Replace "USB stick"/"USB Drive" with "USB flash drive" as that seem more correct
https://en.wikipedia.org/wiki/USB_flash_drivehttps://elementary.io/docs/installation#choose-operating-system
- Don't mention CD as easiest option anymore,
as all modern systems should be able to boot from USB,
but many don't have a CD drive. Burning CDs is also usually wasteful as you
can't burn them again.
- Remove link to NixOS Wiki (Making_the_installation_media) as it is not needed
- Add Etcher and USBImager as graphical tools to create install drive
- Make dd command consistent and use block size of 4 MB for faster flashing
- More consistent text
- Add instructions for "Booting from the install medium"
Inspired by 9a91b0f495/docs/installation.md (booting-from-the-install-drive-booting-from-the-installation-medium-clear-float-2)
- Add instructions for "Graphical Installation"
- Restructure headings and anchors for "Manual Installation"
- Adding legacy anchors for "Manual Installation" to not break links
Co-authored-by: j-k <dev@j-k.io>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Robert Schütz <github@dotlambda.de>
Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>
Co-authored-by: Thiago Kenji Okada <thiagokokada@gmail.com>
This will add `passthru.schema_version` to be used as default value for
the adguardhome module.
It will also update the `update.sh` to keep the `schema_version` in sync
with the version by inspecting the sourcecode.
This might break existing configs, if they use deprecated values that don't
appear in newer schema_versions and schema_version wasn't set explicitly.
Explicit declarations of schema_version always have higher priority.
This also removes the `host` and `config` settings in favour of using the
appropriate `settings`.
Fixes#173938
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
- Previously PolyMC's removal was counted as a release highlight
- It probably shouldn't be, as it's more a notable change rather than a
highlight
- Thanks @Ma27 for noticing this
This commit refactors `services.grafana.provision.datasources` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
This commit refactors `services.grafana.provision.dashboards` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
- Previously PolyMC was the suggested replacement for MultiMC
- As PolyMC is marked as insecure and prismlauncher is a replacement,
this commit suggests using it instead
The actual p4 command is open-source software released under the
2-clause BSD license, so we can build it here (for pretty much every
architecture we support!) and include it in the cache.
This change removes the server-side commands from this package, but they
are now available as part of a separate p4d package instead. (The server
package remains unfree.)
As an added bonus, we can also include the libraries and headers for the
C/C++ API, which will allow us to package any software that uses
Perforce as a library in the future.
This binary was provided by the `cosign` package until now but it is in
the process of being removed, see https://github.com/sigstore/cosign/pull/2019
Since it might be removed during the 22.11 cycle we drop it
preventively. This will make possible security backports easier if we
need them.
Deprecate haskell.lib{,.compose}.generateOptparseApplicativeCompletion*
in favor of the newly added
haskell.packages.*.generateOptparseApplicativeCompletions (plural!)
which takes into account whether we are cross-compiling or not. If we
are, generating completions is disabled, since we can't execute software
built for a different platform.
The move is necessary, so we can receive the /same/ stdenv as the
package we are overriding in order to accurately check whether we can
execute produced binaries.
Resolves#174040.
Resolves#49648.
This caused too many downstream projects to break, so we are reverting
this change for now, until further transition fixes are in place.
See discussion in https://github.com/NixOS/nixpkgs/pull/191171
This reverts part of 6762de9a28
Optional functionality of AusweisApp2 requires an UDP port to be opened.
The module allows for convenient configuration and serves as documentation.
See also https://github.com/NixOS/nixpkgs/issues/136269
deprecate literalDocBook by adding a warning (that will not fire yet) to
its uses and other docbook literal strings by adding optional warning
message to mergeJSON.
Because of long standing bugs and stability issues & an
uncollaborative upstream there has been talk on the emacs-devel
mailing list to switch the default toolkit to
Lucid (https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00752.html).
The GTK build also has issues with Xinput2, something that both we and
upstream want to enable by default in Emacs 29.
This situation has prompted me to use both Lucid an no-toolkit (pure X11) Emacs
as a daily driver in recent weeks to evaluate what the
advantages/drawbacks are and I have concluded that, at least for me,
switching the toolkit to Lucid is strictly an upgrade.
It has resulted in better stability (there are far fewer tiny UX
issues that are hard to understand/identify) & a snappier UI.
On top of that the closure size is reduced by ~10%.
In the pure X11 build I noticed some unsharpness around fonts so this
is not a good default choice.
As with everything there is a cost, and that is uglier (I think most
would agree but of course this is subjective) menu bars for
those that use them and no GTK scroll bars.
For anyone who still wants to use GTK they could of course still
choose to do so via the new `emacs-gtk` attribute but I think this
is a bad default.
A note to Wayland users:
This does not affect Wayland compatibility in any way since that will
already need a PGTK build variant in the future.
- Replace misleading docs.
- Add new assertions to let configurations make more sense.
- Add clusterInit flag.
- Add some more docs about HA and non-HA modes setup.
- Improve multi-node tests for HA mode.
Fix https://github.com/NixOS/nixpkgs/issues/182085
This option is based on a recommendation from a page last updated in
2014 (see https://www.freedesktop.org/wiki/Software/Glamor/), and it
is not necessary anymore.
Also, it did the wrong thing: it forced DRI2, but Glamor should also
work with DRI3, that is a better option most of the time. So let's
remove this option, folks that still want to force this manually can do
so in other ways.
Enable keter module
Keter is an apploader which:
1. has the old app running on a port.
2. loads a new one, and wait for that to complete
3. switches the old with the new one once the new one finished loading.
It supports more functionality but this use case
is the primary one being used by supercede.
Adds keter as a module to nixos.
Currently keter is unusable with nix,
because it relies on bundeling of a tar and uploading that to a specific folder.
These expressions automate these devops tasks,
with especially nixops in mind.
This will work with versions above 1.8
The test seems to work.
This uses a new version of keter which has good
support for status code on error pages.
We're using this config at production at supercede
so it should be fine.
Squash log:
==========
mention keter in changelog
Update generated release notes
Always restart keter on failure
This is a little bit of extra stability in case keter crashes.
Which can happen under extreme conditions (DoS attacks).
Update nixos/doc/manual/release-notes/rl-2205.section.md
Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com>
Update nixos/modules/module-list.nix
Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com>
Remove sanitization
don't put domain in as a string
Update nixos/tests/keter.nix
Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com>
add jappie as module maintainer
Use type path instead of two seperate options
Fix generated docs
added test machinery to figure out why it's failing
Fix the test, use console output
run nixpkgs-fmt on all modules
Inline config file.
This get's rid of a lot of inderection as well.
Run nix format
remove comment
simplify executable for test
delete config file
add config for keter root
Remove after redis clause
set keter root by default to /var/lib/keter
Update nixos/modules/services/web-servers/keter/default.nix
Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com>
Update nixos/modules/services/web-servers/keter/default.nix
Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com>
Update nixos/modules/services/web-servers/keter/default.nix
Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com>
fix nit
add newlines
add default text and move description in a long description
Delete rather obvious comment
fix release db thing
remove longDescription and put it in a comment instead
change description of mkEnalbeOption
explain what keter does by using the hackage synopsis
set domain to keterDomain and same for executable
move comment to where it's happening
fix type error
add formatting better comment
try add seperate user for keter
Revert "try add seperate user for keter"
This reverts commit d3522d36c96117335bfa072e6f453406c244e940.
Doing this breaks the setup
set default to avoid needing cap_net_bind_service
remove weird comment
use example fields
eleborated on process leakage
Update nixos/modules/services/web-servers/keter/default.nix
Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com>
run nixpkgs-fmt
update docs
Fix formatting, set keter package by default
format our little nixexpr
replace '' -> " where possible
drop indent for multiline string
make description much shorter
regen docs database
