Compare commits

...

1 Commits

Author SHA1 Message Date
Félix Baylac-Jacqué 47cca67b69
fixup! Update readme 2020-09-27 00:40:20 +02:00
1 changed files with 105 additions and 7 deletions

112
readme.md
View File

@ -8,20 +8,97 @@ it's readable by the `pleroma` user.
You can then use the following example to get started.
```
{ pkgs, ... }:
let
pleromaModuleSrc = builtins.fetchTarball {
url = "https://git.alternativebit.fr/NinjaTrappeur/pleroma-otp-nixos/archive/master.tar.gz";
sha256 = "0000000000000000000000000000000000000000000000000000";
};
in
{
imports = [ "${pleromaModuleSrc}/modules/pleroma.nix" ]
security.acme = {
email = "root@tld";
acceptTerms = true;
certs = {
"social.tld.com" = {
webroot = "/var/www/social.tld.com";
email = "root@tld";
group = "nginx";
};
};
};
services = {
pleroma.enable = true;
postgresql = {
enable = true;
package = pkgs.postgresql_12;
};
nginx = {
enable = true;
virtualHosts."social.tld.com" = {
addSSL = true;
sslCertificate = "/var/lib/acme/social.tld.com/fullchain.pem";
sslCertificateKey = "/var/lib/acme/social.tld.com/key.pem";
root = "/var/www/social.tld.com";
# ACME endpoint
locations."/.well-known/acme-challenge" = {
root = "/var/www/social.tld.com/";
};
locations."/" = {
proxyPass = "http://localhost:4000";
extraConfig = ''
# if you do not want remote frontends to be able to access your Pleroma backend
# server, remove these lines.
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Methods' 'POST, PUT, DELETE, GET, PATCH, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, Idempotency-Key' always;
add_header 'Access-Control-Expose-Headers' 'Link, X-RateLimit-Reset, X-RateLimit-Limit, X-RateLimit-Remaining, X-Request-Id' always;
if ($request_method = OPTIONS) {
return 204;
}
# stop removing lines here.
add_header X-XSS-Protection "1; mode=block";
add_header X-Permitted-Cross-Domain-Policies none;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy same-origin;
add_header X-Download-Options noopen;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
client_max_body_size 16m;
'';
};
};
};
};
}
```
## Pleroma Configuration Management
### File Configuration
Pleroma is expecting its configuration to be found at
`/etc/pleroma/config.exs`. This configuration file is containing some
secrets, making impossible for it to live in the Nix store.
secrets, the Nix store being world-readable, it seems like storing the
pleroma conf there is a pretty bad idea.
You'll have to create this file manually. Two options:
Meaning, this module won't handle this configuration file for you, you
have to do it manually. From here, two options:
1. You are migrating a src-based install (mix-based). You can re-use
your `$src_root/config/prod.secret.exs` file. Change the `use Mix.Config`
statement with `use Config`.
2. This is a new installation. In that case you can use
2. This is a brand new installation. In that case you can use
`pleroma_ctl instance gen --output config.exs --output-psql setup.psql`,
this will prompt you some questions and will generate both your
config file and database initial migration. Note: `pleroma_ctl`
@ -29,13 +106,34 @@ You'll have to create this file manually. Two options:
service. You can alternatively build it by building this repo's
`default.nix` derivation.
## Pleroma Database Init
### Database Configuration
If it's not already done, you need to seed your pleroma postgresql database.
If you created your brand new pleroma configuration with
`pleroma_ctl instance gen --output-psql seed.psql`, you can load the
`seed.psql` dump to the database with `sudo -u pleroma psql -f seed.psql`.
Using the `setup.psql` file generated in the previous section, you can
load the seed with `sudo -u postgres psql -f seed.psql`.
## Open Questions
- In this module, we decided not to try any kind of magical conf on
the Nginx-side. Web server configurations can quickly get pretty
custom, letting the admin handle it seems like the best thing to do
to me. On top of that, a lot of directives we're using are not
covered by the NixOS Nginx module, we have to make a heavy use of
`extraConfig`, making the whole config not easily overrideable.
**However**, the Nginx block config is quite huge, there's maybe
something smarter to do.
- The configuration file contains some secrets. On top of that, the
config file format is a pure Elixir file, making it poor candidate
for a
[RFC042](https://github.com/Infinisil/rfcs/blob/config-option/rfcs/0042-config-option.md)
-style `settings` attributeset. Because of that, I kinda chicken out
and decided to keep the conf file management 100% out of this
module. There's probably a better middle ground here. Something
allowing us to keep the secret part (db password, endpoint secret
key) out of the store while leveraging the module system for the
less secret configuration settings. Maybe the solution is to
leverage Elixir's import system?
## Update Pleroma to a New Version