diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/administration/CLI_tasks/frontend.md | 2 | ||||
| -rw-r--r-- | docs/administration/updating.md | 2 | ||||
| -rw-r--r-- | docs/clients.md | 15 | ||||
| -rw-r--r-- | docs/configuration/cheatsheet.md | 49 | ||||
| -rw-r--r-- | docs/configuration/how_to_serve_another_domain_for_webfinger.md | 62 | ||||
| -rw-r--r-- | docs/configuration/howto_database_config.md | 2 | ||||
| -rw-r--r-- | docs/development/API/admin_api.md | 13 | ||||
| -rw-r--r-- | docs/development/API/differences_in_mastoapi_responses.md | 4 | ||||
| -rw-r--r-- | docs/installation/generic_dependencies.include | 2 | ||||
| -rw-r--r-- | docs/installation/migrating_from_source_otp_en.md | 2 | ||||
| -rw-r--r-- | docs/installation/nixos_en.md | 15 | ||||
| -rw-r--r-- | docs/installation/otp_en.md | 11 |
12 files changed, 145 insertions, 34 deletions
diff --git a/docs/administration/CLI_tasks/frontend.md b/docs/administration/CLI_tasks/frontend.md index d4a48cb56..4e9d9eecb 100644 --- a/docs/administration/CLI_tasks/frontend.md +++ b/docs/administration/CLI_tasks/frontend.md @@ -22,7 +22,7 @@ Currently, known `<frontend>` values are: - [kenoma](http://git.pleroma.social/lambadalambda/kenoma) - [pleroma-fe](http://git.pleroma.social/pleroma/pleroma-fe) - [fedi-fe](https://git.pleroma.social/pleroma/fedi-fe) -- [soapbox-fe](https://gitlab.com/soapbox-pub/soapbox-fe) +- [soapbox](https://gitlab.com/soapbox-pub/soapbox) You can still install frontends that are not configured, see below. diff --git a/docs/administration/updating.md b/docs/administration/updating.md index 01d3b9b0e..00eca36a0 100644 --- a/docs/administration/updating.md +++ b/docs/administration/updating.md @@ -17,7 +17,7 @@ su pleroma -s $SHELL -lc "./bin/pleroma_ctl migrate" ## For from source installations (using git) 1. Go to the working directory of Pleroma (default is `/opt/pleroma`) -2. Run `git pull` [^1]. This pulls the latest changes from upstream. +2. Run `git checkout <tagged release>` [^1]. e.g. `git checkout v2.4.5` This pulls the [tagged release](https://git.pleroma.social/pleroma/pleroma/-/releases) from upstream. 3. Run `mix deps.get` [^1]. This pulls in any new dependencies. 4. Stop the Pleroma service. 5. Run `mix ecto.migrate` [^1] [^2]. This task performs database migrations, if there were any. diff --git a/docs/clients.md b/docs/clients.md index 31d2d27c3..ad7eb7807 100644 --- a/docs/clients.md +++ b/docs/clients.md @@ -3,12 +3,6 @@ Note: Additional clients may be working but theses are officially supporting Ple Feel free to contact us to be added to this list! ## Desktop -### Roma for Desktop -- Homepage: <https://www.pleroma.com/#desktopApp> -- Source Code: <https://github.com/roma-apps/roma-desktop> -- Platforms: Windows, Mac, Linux -- Features: MastoAPI, Streaming Ready - ### Social - Source Code: <https://gitlab.gnome.org/World/Social> - Contact: [@brainblasted@social.libre.fi](https://social.libre.fi/users/brainblasted) @@ -19,7 +13,14 @@ Feel free to contact us to be added to this list! ### Whalebird - Homepage: <https://whalebird.social/> - Source Code: <https://github.com/h3poteto/whalebird-desktop> -- Contact: [@h3poteto@pleroma.io](https://pleroma.io/users/h3poteto) +- Contact: [@whalebird@pleroma.io](https://pleroma.io/users/whalebird) +- Platforms: Windows, Mac, Linux +- Features: MastoAPI, Streaming Ready + +### Fedistar +- Homepage: <https://fedistar.net> +- Source Code: <https://github.com/h3poteto/fedistar> +- Contact: [@fedistar@pleroma.io](https://pleroma.io/users/fedistar) - Platforms: Windows, Mac, Linux - Features: MastoAPI, Streaming Ready diff --git a/docs/configuration/cheatsheet.md b/docs/configuration/cheatsheet.md index 6e13b9622..bbdf30a0f 100644 --- a/docs/configuration/cheatsheet.md +++ b/docs/configuration/cheatsheet.md @@ -49,6 +49,7 @@ To add configuration to your config file, you can copy it from the base config. * `autofollowing_nicknames`: Set to nicknames of (local) users that automatically follows every newly registered user. * `attachment_links`: Set to true to enable automatically adding attachment link text to statuses. * `max_report_comment_size`: The maximum size of the report comment (Default: `1000`). +* `report_strip_status`: Strip associated statuses in reports to ids when closed/resolved, otherwise keep a copy. * `safe_dm_mentions`: If set to true, only mentions at the beginning of a post will be used to address people in direct messages. This is to prevent accidental mentioning of people when talking about them (e.g. "@friend hey i really don't like @enemy"). Default: `false`. * `healthcheck`: If set to true, system data will be shown on ``/api/v1/pleroma/healthcheck``. * `remote_post_retention_days`: The default amount of days to retain remote posts when pruning the database. @@ -65,6 +66,36 @@ To add configuration to your config file, you can copy it from the base config. * `cleanup_attachments`: Remove attachments along with statuses. Does not affect duplicate files and attachments without status. Enabling this will increase load to database when deleting statuses on larger instances. * `show_reactions`: Let favourites and emoji reactions be viewed through the API (default: `true`). * `password_reset_token_validity`: The time after which reset tokens aren't accepted anymore, in seconds (default: one day). +* `admin_privileges`: A list of privileges an admin has (e.g. delete messages, manage reports...) + * Possible values are: + * `:users_read` + * Allows admins to fetch users through the admin API. + * `:users_manage_invites` + * Allows admins to manage invites. This includes sending, resending, revoking and approving invites. + * `:users_manage_activation_state` + * Allows admins to activate and deactivate accounts. This also allows them to see deactivated users through the Mastodon API. + * `:users_manage_tags` + * Allows admins to set and remove tags for users. This can be useful in combination with MRF policies, such as `Pleroma.Web.ActivityPub.MRF.TagPolicy`. + * `:users_manage_credentials` + * Allows admins to trigger a password reset and set new credentials for an user. + * `:users_delete` + * Allows admins to delete accounts. Note that deleting an account is actually deactivating it and removing all data like posts, profile information, etc. + * `:messages_read` + * Allows admins to read messages through the admin API, including non-public posts and chats. + * `:messages_delete` + * Allows admins to delete messages from other users. + * `:instances_delete,` + * Allows admins to remove a whole remote instance from your instance. This will delete all users and messages from that remote instance. + * `:reports_manage_reports` + * Allows admins to see and manage reports. + * `:moderation_log_read,` + * Allows admins to read the entries in the moderation log. + * `:emoji_manage_emoji` + * Allows admins to manage custom emoji on the instance. + * `:statistics_read,` + * Allows admins to see some simple statistics about the instance. +* `moderator_privileges`: A list of privileges a moderator has (e.g. delete messages, manage reports...) + * Possible values are the same as for `admin_privileges` ## :database * `improved_hashtag_timeline`: Setting to force toggle / force disable improved hashtags timeline. `:enabled` forces hashtags to be fetched from `hashtags` table for hashtags timeline. `:disabled` forces object-embedded hashtags to be used (slower). Keep it `:auto` for automatic behaviour (it is auto-set to `:enabled` [unless overridden] when HashtagsTableMigrator completes). @@ -204,7 +235,7 @@ config :pleroma, :mrf_user_allowlist, %{ e.g., A value of 900 results in any post with a timestamp older than 15 minutes will be acted upon. * `actions`: A list of actions to apply to the post: * `:delist` removes the post from public timelines - * `:strip_followers` removes followers from the ActivityPub recipient list, ensuring they won't be delivered to home timelines + * `:strip_followers` removes followers from the ActivityPub recipient list, ensuring they won't be delivered to home timelines, additionally for followers-only it degrades to a direct message * `:reject` rejects the message entirely #### :mrf_steal_emoji @@ -777,7 +808,7 @@ Web Push Notifications configuration. You can use the mix task `mix web_push.gen * ``private_key``: VAPID private key ## :logger -* `backends`: `:console` is used to send logs to stdout, `{ExSyslogger, :ex_syslogger}` to log to syslog, and `Quack.Logger` to log to Slack +* `backends`: `:console` is used to send logs to stdout, `{ExSyslogger, :ex_syslogger}` to log to syslog An example to enable ONLY ExSyslogger (f/ex in ``prod.secret.exs``) with info and debug suppressed: ```elixir @@ -800,10 +831,10 @@ config :logger, :ex_syslogger, See: [logger’s documentation](https://hexdocs.pm/logger/Logger.html) and [ex_syslogger’s documentation](https://hexdocs.pm/ex_syslogger/) -An example of logging info to local syslog, but warn to a Slack channel: +An example of logging info to local syslog, but debug to console: ```elixir config :logger, - backends: [ {ExSyslogger, :ex_syslogger}, Quack.Logger ], + backends: [ {ExSyslogger, :ex_syslogger}, :console ], level: :info config :logger, :ex_syslogger, @@ -811,14 +842,12 @@ config :logger, :ex_syslogger, ident: "pleroma", format: "$metadata[$level] $message" -config :quack, - level: :warn, - meta: [:all], - webhook_url: "https://hooks.slack.com/services/YOUR-API-KEY-HERE" +config :logger, :console, + level: :debug, + format: "\n$time $metadata[$level] $message\n", + metadata: [:request_id] ``` -See the [Quack Github](https://github.com/azohra/quack) for more details - ## Database options diff --git a/docs/configuration/how_to_serve_another_domain_for_webfinger.md b/docs/configuration/how_to_serve_another_domain_for_webfinger.md new file mode 100644 index 000000000..5ae3e7943 --- /dev/null +++ b/docs/configuration/how_to_serve_another_domain_for_webfinger.md @@ -0,0 +1,62 @@ +# How to use a different domain name for Pleroma and the users it serves + +Pleroma users are primarily identified by a `user@example.org` handle, and you might want this identifier to be the same as your email or jabber account, for instance. +However, in this case, you are almost certainly serving some web content on `https://example.org` already, and you might want to use another domain (say `pleroma.example.org`) for Pleroma itself. + +Pleroma supports that, but it might be tricky to set up, and any error might prevent you from federating with other instances. + +*If you are already running Pleroma on `example.org`, it is no longer possible to move it to `pleroma.example.org`.* + +## Account identifiers + +It is important to understand that for federation purposes, a user in Pleroma has two unique identifiers associated: + +- A webfinger `acct:` URI, used for discovery and as a verifiable global name for the user across Pleroma instances. In our example, our account's acct: URI is `acct:user@example.org` +- An author/actor URI, used in every other aspect of federation. This is the way in which users are identified in ActivityPub, the underlying protocol used for federation with other Pleroma instances. +In our case, it is `https://pleroma.example.org/users/user`. + +Both account identifiers are unique and required for Pleroma. An important risk if you set up your Pleroma instance incorrectly is to create two users (with different acct: URIs) with conflicting author/actor URIs. + +## WebFinger + +As said earlier, each Pleroma user has an `acct`: URI, which is used for discovery and authentication. When you add @user@example.org, a webfinger query is performed. This is done in two steps: + +1. Querying `https://example.org/.well-known/host-meta` (where the domain of the URL matches the domain part of the `acct`: URI) to get information on how to perform the query. +This file will indeed contain a URL template of the form `https://example.org/.well-known/webfinger?resource={uri}` that will be used in the second step. +2. Fill the returned template with the `acct`: URI to be queried and perform the query: `https://example.org/.well-known/webfinger?resource=acct:user@example.org` + +## Configuring your Pleroma instance + +**_DO NOT ATTEMPT TO CONFIGURE YOUR INSTANCE THIS WAY IF YOU DID NOT UNDERSTAND THE ABOVE_** + +### Configuring Pleroma + +Pleroma has a two configuration settings to enable using different domains for your users and Pleroma itself. `host` in `Pleroma.Web.Endpoint` and `domain` in `Pleroma.Web.WebFinger`. When the latter is not set, it defaults to the value of `host`. + +*Be extra careful when configuring your Pleroma instance, as changing `host` may cause remote instances to register different accounts with the same author/actor URI, which will result in federation issues!* + +```elixir +config :pleroma, Pleroma.Web.Endpoint, + url: [host: "pleroma.example.org"] + +config :pleroma, Pleroma.Web.WebFinger, domain: "example.org" +``` + +- `domain` - is the domain for which your Pleroma instance has authority, it's the domain used in `acct:` URI. In our example, `domain` would be set to `example.org`. This is used in WebFinger account ids, which are the canonical account identifier in some other fediverse software like Mastodon. **If you change `domain`, the accounts on your server will be shown as different accounts in those software**. +- `host` - is the domain used for any URL generated for your instance, including the author/actor URL's. In our case, that would be `pleroma.example.org`. This is used in AP ids, which are the canonical account identifier in Pleroma and some other fediverse software. **You should not change this after you have set up the instance**. + +### Configuring WebFinger domain + +Now, you have Pleroma running at `https://pleroma.example.org` as well as a website at `https://example.org`. If you recall how webfinger queries work, the first step is to query `https://example.org/.well-known/host-meta`, which will contain an URL template. + +Therefore, the easiest way to configure `example.org` is to redirect `/.well-known/host-meta` to `pleroma.example.org`. + +With nginx, it would be as simple as adding: + +```nginx +location = /.well-known/host-meta { + return 301 https://pleroma.example.org$request_uri; +} +``` + +in example.org's server block. diff --git a/docs/configuration/howto_database_config.md b/docs/configuration/howto_database_config.md index ae1462f9b..e5af9097a 100644 --- a/docs/configuration/howto_database_config.md +++ b/docs/configuration/howto_database_config.md @@ -59,7 +59,7 @@ The configuration of Pleroma has traditionally been managed with a config file, Here is an example of a server config stripped down after migration: ``` - use Mix.Config + import Config config :pleroma, Pleroma.Web.Endpoint, url: [host: "cool.pleroma.site", scheme: "https", port: 443] diff --git a/docs/development/API/admin_api.md b/docs/development/API/admin_api.md index c46f83839..f6e9f7d2a 100644 --- a/docs/development/API/admin_api.md +++ b/docs/development/API/admin_api.md @@ -1064,7 +1064,6 @@ List of settings which support only full update by key: ```elixir @full_key_update [ {:pleroma, :ecto_repos}, - {:quack, :meta}, {:mime, :types}, {:cors_plug, [:max_age, :methods, :expose, :headers]}, {:auto_linker, :opts}, @@ -1084,18 +1083,18 @@ List of settings which support only full update by subkey: ] ``` -*Settings without explicit key must be sended in separate config object params.* +*Settings without explicit key must be sent in separate config object params.* ```elixir -config :quack, - level: :debug, - meta: [:all], +config :foo, + bar: :baz, + meta: [:data], ... ``` ```json { "configs": [ - {"group": ":quack", "key": ":level", "value": ":debug"}, - {"group": ":quack", "key": ":meta", "value": [":all"]}, + {"group": ":foo", "key": ":bar", "value": ":baz"}, + {"group": ":foo", "key": ":meta", "value": [":data"]}, ... ] } diff --git a/docs/development/API/differences_in_mastoapi_responses.md b/docs/development/API/differences_in_mastoapi_responses.md index 73c46fff8..4007c63c8 100644 --- a/docs/development/API/differences_in_mastoapi_responses.md +++ b/docs/development/API/differences_in_mastoapi_responses.md @@ -40,6 +40,10 @@ Has these additional fields under the `pleroma` object: - `parent_visible`: If the parent of this post is visible to the user or not. - `pinned_at`: a datetime (iso8601) when status was pinned, `null` otherwise. +The `GET /api/v1/statuses/:id/source` endpoint additionally has the following attributes: + +- `content_type`: The content type of the status source. + ## Scheduled statuses Has these additional fields in `params`: diff --git a/docs/installation/generic_dependencies.include b/docs/installation/generic_dependencies.include index 2dbd93e42..dcaacfdfd 100644 --- a/docs/installation/generic_dependencies.include +++ b/docs/installation/generic_dependencies.include @@ -1,7 +1,7 @@ ## Required dependencies * PostgreSQL 9.6+ -* Elixir 1.9+ +* Elixir 1.10+ * Erlang OTP 22.2+ * git * file / libmagic diff --git a/docs/installation/migrating_from_source_otp_en.md b/docs/installation/migrating_from_source_otp_en.md index e4a01d8db..f6f23400a 100644 --- a/docs/installation/migrating_from_source_otp_en.md +++ b/docs/installation/migrating_from_source_otp_en.md @@ -5,7 +5,7 @@ In this guide we cover how you can migrate from a from source installation to one using OTP releases. ## Pre-requisites -You will be running commands as root. If you aren't root already, please elevate your priviledges by executing `sudo su`/`su`. +You will be running commands as root. If you aren't root already, please elevate your privileges by executing `sudo su`/`su`. The system needs to have `curl` and `unzip` installed for downloading and unpacking release builds. diff --git a/docs/installation/nixos_en.md b/docs/installation/nixos_en.md new file mode 100644 index 000000000..f3c4988b1 --- /dev/null +++ b/docs/installation/nixos_en.md @@ -0,0 +1,15 @@ +# Installing on NixOS + +NixOS contains a source build package of pleroma and a NixOS module to install it. +For installation add this to your configuration.nix and add a config.exs next to it: +```nix + services.pleroma = { + enable = true; + configs = [ (lib.fileContents ./config.exs) ]; + secretConfigFile = "/var/lib/pleroma/secret.exs"; + }; +``` + +## Questions +The nix community uses matrix for communication: [#nix:nixos.org](https://matrix.to/#/#nix:nixos.org) + diff --git a/docs/installation/otp_en.md b/docs/installation/otp_en.md index 0861a8157..f2812346b 100644 --- a/docs/installation/otp_en.md +++ b/docs/installation/otp_en.md @@ -2,15 +2,16 @@ {! backend/installation/otp_vs_from_source.include !} -This guide covers a installation using an OTP release. To install Pleroma from source, please check out the corresponding guide for your distro. +This guide covers a installation using OTP releases as built by the Pleroma project, it is meant as a fallback to distribution packages/recipes which are the preferred installation method. +To install Pleroma from source, please check out the corresponding guide for your distro. ## Pre-requisites -* A machine running Linux with GNU (e.g. Debian, Ubuntu) or musl (e.g. Alpine) libc and `x86_64`, `aarch64` or `armv7l` CPU, you have root access to. If you are not sure if it's compatible see [Detecting flavour section](#detecting-flavour) below +* A machine you have root access to running Debian GNU/Linux or compatible (eg. Ubuntu), or Alpine on `x86_64`, `aarch64` or `armv7l` CPU. If you are not sure what you are running see [Detecting flavour section](#detecting-flavour) below * A (sub)domain pointed to the machine -You will be running commands as root. If you aren't root already, please elevate your priviledges by executing `sudo su`/`su`. +You will be running commands as root. If you aren't root already, please elevate your privileges by executing `sudo -i`/`su`. -While in theory OTP releases are possbile to install on any compatible machine, for the sake of simplicity this guide focuses only on Debian/Ubuntu and Alpine. +Similarly to other binaries, OTP releases tend to be only compatible with the distro they are built on, as such this guide focuses only on Debian/Ubuntu and Alpine. ### Detecting flavour @@ -19,7 +20,7 @@ Paste the following into the shell: arch="$(uname -m)";if [ "$arch" = "x86_64" ];then arch="amd64";elif [ "$arch" = "armv7l" ];then arch="arm";elif [ "$arch" = "aarch64" ];then arch="arm64";else echo "Unsupported arch: $arch">&2;fi;if getconf GNU_LIBC_VERSION>/dev/null;then libc_postfix="";elif [ "$(ldd 2>&1|head -c 9)" = "musl libc" ];then libc_postfix="-musl";elif [ "$(find /lib/libc.musl*|wc -l)" ];then libc_postfix="-musl";else echo "Unsupported libc">&2;fi;echo "$arch$libc_postfix" ``` -If your platform is supported the output will contain the flavour string, you will need it later. If not, this just means that we don't build releases for your platform, you can still try installing from source. +This should give your flavour string. If not this just means that we don't build releases for your platform, you can still try installing from source. ### Installing the required packages |